From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: Holger Hellmuth <hellmuth@ira.uka.de>
Cc: Junio C Hamano <gitster@pobox.com>,
kusmabite@gmail.com, Git Mailing List <git@vger.kernel.org>
Subject: Re: git add -p and unresolved conflicts
Date: Thu, 29 Mar 2012 09:26:55 +0200 [thread overview]
Message-ID: <vpqvclnhnpc.fsf@bauges.imag.fr> (raw)
In-Reply-To: <4F737027.5020503@ira.uka.de> (Holger Hellmuth's message of "Wed, 28 Mar 2012 22:10:15 +0200")
Holger Hellmuth <hellmuth@ira.uka.de> writes:
>> And you miss the most usefull (to me at least): "choose the version in
>> the worktree".
>>
>
> But the conflicted chunks are of the form "<<<< our ... ||||||||||
> theirs >>>>>>" in your work tree. So there are two cases:
>
> a) You have removed the markers thereby removing the conflict -> this
> means the chunk will not be offered to you as a conflicting chunk
If you have removed the markers, then the file is still marked as
conflicted in the index, and the user may still want to see the combined
diff.
My use-case is actually quite simple: I see "git add -p" both as a way
to make partial commits, and as a way to manually validate what I'm
about to commit. I review the diff, validate them with "y", and if I see
something wrong, I quit "git add -p", fix the issue, and next "git add
-p" won't show it again. This flow could work also with conflicts:
$ git add -p
# see an unresolved diff for file foo.txt
n
# see a resolved diff for file bar.txt
y <-- the "missing" possibility for me
$ edit foo.txt
$ git add -p
# see resolution for file foo.txt
y
$ git commit
The "'git reset $path' before 'add -p'" workaround is not really handy
there: it requires typing the path, while my workflow with "git add -p"
does not, and it wouldn't show the combined diff, which is usually the
best tool to see if a merge has been resolved properly.
The current behavior is not that bad for me: I see the combined diff in
the output, I just have one extra "git add $path" to type. Being able to
just say "y" instead would be handy, but not fundamentally different.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
next prev parent reply other threads:[~2012-03-29 7:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-28 9:51 git add -p and unresolved conflicts Erik Faye-Lund
2012-03-28 15:10 ` Junio C Hamano
2012-03-28 15:21 ` Matthieu Moy
2012-03-28 19:14 ` Holger Hellmuth
2012-03-28 19:19 ` Junio C Hamano
2012-03-28 19:52 ` Holger Hellmuth
2012-03-29 6:08 ` Jeff King
2012-03-29 10:19 ` Holger Hellmuth
2012-03-28 19:38 ` Matthieu Moy
2012-03-28 19:54 ` Junio C Hamano
2012-03-28 20:10 ` Holger Hellmuth
2012-03-28 20:50 ` Junio C Hamano
2012-03-28 22:50 ` Holger Hellmuth
2012-03-28 23:01 ` Junio C Hamano
2012-03-28 23:05 ` Junio C Hamano
2012-03-29 1:32 ` Holger Hellmuth
2012-03-29 7:26 ` Matthieu Moy [this message]
2012-03-29 21:08 ` Junio C Hamano
2012-03-30 8:11 ` Matthieu Moy
2012-03-28 15:33 ` Erik Faye-Lund
2012-03-28 17:17 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vpqvclnhnpc.fsf@bauges.imag.fr \
--to=matthieu.moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hellmuth@ira.uka.de \
--cc=kusmabite@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.