Re: git-union-merge proposal

[Joey Hess <joey@kitenet.net>]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

Jonathan Nieder wrote:
> Does the GitRepo module that it uses come from git-annex?
> 
> If the prototype were self-contained, I would encourage you to submit
> it for inclusion under contrib/ so it can evolve and eventually
> graduate out of there.  Cc-ing Johan (who has no doubt thought through
> these things in the context of "git notes") in case he has thoughts on
> it.

Yes, this was written in the context of git-annex. I would probably not want
to submit the haskell implementation to contrib/, but a shell implementation
could be done that would be perhaps less robust, but also less unusual in
the context of git's code base.

Johan Herland wrote:
> I must confess that my Haskell skills are exactly nil, but AFAICS the script 
> depends on the filename as the only criteria to identify files that need a 
> line-level merge. How does the script deal with renamed and copied files?
> 
> If you depend on the filename only, this script simply will not work for 
> notes.

It simply depends on filenames. I saw there was additional complexity
in notes and I don't see how a general purpose merger can handle that.
(I wish I could just use notes for my application, but I have data that
is not tied to any one object in git.)

Although, this is an obvious extension that would add some flexability
to handle for files that cannot be merged with a naive union:

git union-merge foo origin/foo refs/heads/foo -c "sort * | uniq"

Where the files would be passed in as temp files.

Hmm, that makes it look not unlike git-filter-branch, except
it's generating a new commit at the tip. I *think* that filter-branch
can't do this.

-- 
see shy jo

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]