Re: [jgit-dev] RFC: Resolving conflicts using DirCacheEditor

["Shawn O. Pearce" <spearce@xxxxxxxxxxx>]

"Lay, Stefan" <stefan.lay@xxxxxxx> wrote:
> We implemented a new add command in the jgit porcelain API
> (http://egit.eclipse.org/r/#change,1036).
> 
> We had tried to make use of the DirCacheEditor in case of conflicts but
> we failed. (Now we use DirCacheBuilder instead.)
> 
> With the code below the new entry was in stage 1 but not in stage 0.
> Before the edit there were entries in stage 1, 2 and 3.
> Is it possible to use DirCacheEditor to resolve conflicts?

Arrgh.  This is an ugly bug in DirCacheEditor's API.  The correct
code to resolve stages down to 0 would be a DeletePath followed by
an EditPath:

	DirCacheEditor e = dc.editor();
	e.add(new DeletePath(filepath));
	e.add(new PathEdit(filepath) {
		@Override
		public void apply(DirCacheEntry ent) {
			ent.setFileMode(repo.getFS().canExecute(file) ? FileMode.EXECUTABLE_FILE
					: FileMode.REGULAR_FILE);
			ent.setLastModified(file.lastModified());
			ent.setLength((int) file.length());
			ent.setObjectId(id);
		}
	});
	e.commit();

With the EditPath by itself, its run once for each stage in the
index, which is why you saw the change occur in stage 1.  With the
DeletePath, it removes all stages for the given file.  By putting
DeletePath before EditPath, we'll prune the stages away, and then
construct a new DirCacheEntry for stage 0.

Maybe it makes sense to add have PathEdit check for non-zero stages
and kill them?

Patch http://egit.eclipse.org/r/1043 does this, but its completely
untested and offered only as a proof-of-concept idea...

-- 
Shawn.