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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html