[jgit-dev] Re: WorkingTreeIterator - the writing side

[Christian Halstrick <christian.halstrick@xxxxxxxxx>]

Hi,

On Wed, Aug 25, 2010 at 04:22, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote:
...
> This isn't fully generic.  One of the things I don't like
> is writeEntryBlob is defined in terms of an ObjectLoader.
> That is intentional because the implementation can invoke
> ObjectLoader.copyTo(OutputStream) and possibly avoid some unnecessary
> copying during output.  However its awkward to use for your merge
> code for example, its a tad difficult to write out a conflicted
> file contents.

Not sure how big the problem is. Whenever merge produces new
conflict-free content there is theoretically no need to directly write
it to the working tree. The new content has to be dumped to the
object-database which will produce the content-sha1 and that sha1 goes
into the index. When merge has processed all pathes I finally update
the working tree and all the content may come from the object-database
through ObjectLoader's.
One example for this strategy is when the merge algorithm chooses the
content from "THEIRS": I don't touch the working tree in the moment we
decide to take "THEIRS". I just remember the path to be checked out
and which blob ID to be checked out. When the merge is done and I know
it will succeed (maybe even with conflicts) then there is a big loop
to checkout out all those files.

The problem is mainly on files with conflicts because those content
does not go into the object database and therefore I have to write it
in the moment the conflict is detected.

One idea for a solution: The use-case that while iterating over the
working tree I want to modify it and see the effects of this
modification during the walk is not needed. Why don't we teach the
working tree iterator to write new content always into .tmp files
beside the original files. For all modifications without new content
(deletions, tree creations, etc) we store the metadata in lists. In
the end we have something like a "commit()" which renames the .tmp
files, deletes files and creates folders. This would even move the
task of .tmp-file handling from multiple places in jgit into a central
place.

> If you have the contents as a byte[], you can hand it off to
> ObjectLoader.SmallObject and let that be the argument.  Or,
> implement ObjectLoader yourself and use ObjectStream.Filter and
> pass in a normal InputStream.

When I do a content merge I deal with a MergeFormatter which currently
expects me to specify a OutputStream (and not a byte[]). Ideally the
WorkingTreeIterator also gives me the possibility to retrieve an
OutputStream for an object.

Ciao
  chris