From: Steven Grimm <koreth@midwinter.com>
Date: Fri, 20 Apr 2007 16:42:22 GMT
Subject: Re: GIT vs Other: Need argument
Message-ID: <4628ED6E.6060101@midwinter.com>
In-Reply-To: <7vzm531ly3.fsf@assigned-by-dhcp.cox.net>

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