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:
signature.asc
Description: Digital signature