Re: GIT vs Other: Need argument

From: Steven Grimm <koreth@midwinter.com>
Date: Apr 20, 2007, 16:42 UTC
Message-ID: <4628ED6E.6060101@midwinter.com>
In-Reply-To: <7vzm531ly3.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 8 quoted lines

> 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.

Show 8 quoted lines

> 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