Junio C Hamano [off-list ref] writes:
I mildly suspect nobody would come up with a sane behaviour, but what
would I know...
Designing a per-hunk behavior would clearly be very tricky.
But a simple way to deal with this would be to show the whole-file
patch, and ask "stage this file (yes/no)?".
My fingers are used to typing
git add -p
y
y
y
git commit
and they would appreciate if it worked in the presence of conflicts.
Most of the time, I have small conflicts, so a whole-file behavior
wouldn't be disturbing, but I like seeing the changes before commiting
them.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On 28.03.2012 17:21, Matthieu Moy wrote:
Junio C Hamano[off-list ref] writes:
quoted
I mildly suspect nobody would come up with a sane behaviour, but what
would I know...
Designing a per-hunk behavior would clearly be very tricky.
I don't think it's that tricky:
For a conflicted file show any conflicted hunks first(!) and only
provide the following options for them:
q - quit, do not stage...
d - do not stage this hunk nor any of the remaining hunks in the file
e - manually edit the current hunk
? - print help
and additionally the following three options:
b - choose the base version
< - choose our version
> - choose their version
< and > correspond to the conflict markers, alternatives would be o and t
The user now has the option to remove the conflicts (through editing or
choosing one of the versions) or abort adding the file.
The tricky part might be sorting the hunks so that conflicts are first
(depending on how the code works now), choosing the right version in a
hunk (the three new options) should be relatively easy.