Re: GIT vs Other: Need argument

Junio C Hamano wrote:

How do you propose to detect that?  We do not record the
conflicted semi-merged state we leave the user to sort out
anywhere else, and I do not think we would want to stash away a
hidden duplicates of all unmerged files somewhere only for this
application.  That feels too wasteful and messy.  You also need
to worry about how to garbage collect such copies if you go that
route.
  

We wouldn't need to store duplicates. Just the SHA1s of the semi-merged 
files would suffice. Actually, just the modification times would 
probably suffice, but the hashes are cheap to compute and slightly more 
robust. We could put those in a single file (the same place we'd record 
the fact that the user is in the middle of a conflicted pull) which is 
removed by --continue or --abort.

Alternately, we could rerun the merge that produced the semi-merged 
files in the first place; presumably it will produce exactly the same 
results it did the first time and we can compare that against the 
working copy. But I like storing the hashes better since it's cheaper 
and less convoluted.

By the way, I've been wondering if giving "git add" an ability
to do "git commit -a" without actual committing.

	$ edit edit edit
        $ git add -u

would run "git add" for all modified (and deleted) files.
  

I'm not sure I'd ever use this, personally. Pretty much the only time I 
find the "add everything" functionality useful is when I'm about to 
commit, and commit -a covers that case fine. But other people might find 
it helpful.

-Steve