From: Scott McPeak <smcpeak@coverity.com>
To: <git@vger.kernel.org>
Subject: git stash while pending merge should not be allowed
Date: Thu, 6 Jun 2013 23:52:33 -0700 [thread overview]
Message-ID: <51B18331.6060302@coverity.com> (raw)
A colleague of mine who is well-intentioned and fairly knowledgeable
about git recently caused havoc with our repository while merging
changes on the main line branch into a feature branch. The reason is
that, along the way, he tried to use "git stash" while the merge was
pending. A few commands later, this severely polluted the history of
all the files involved.
The command sequence started as follows:
$ git checkout feature-branch
$ git merge mainline-branch
(conflicts; merge pending)
$ git mergetool
(resolve all conflicts; takes a while as there are many)
$ make && make testsuite
(oops, tests don't pass)
At this point, the user notices that the fix to the tests is in the
next commit on mainline-branch, which wasn't present when it was first
merged. Not wanting to have a commit in the history whose tests do
not pass, and not wanting to redo all the conflict resolution work
involved in starting over with a different merge parent, he tries to
cherry pick it:
$ git fetch
$ git cherry-pick commit-with-fix
(error: can't cherry pick while merge pending)
Ok, he thinks, git stash has worked in the past as a way to temporarily
move aside some work in progress. So:
$ git stash
$ git cherry-pick commit-with-fix
$ git stash pop
All seems well, so:
$ git commit
Unfortunately, this does *not* do what was intended. You see,
unbeknownst to this developer, git stash does not save the MERGE_HEAD!
So the commit shows up as an enormous single-parent commit on top of
feature-branch, referring to none of the merged commits from
mainline-branch in its ancestry. Consequently, "git annotate" and
friends regard all the merged changes as having been made by the
developer alone and all at once, distorting the file histories to the
point of being nearly useless. Furthermore, git still doesn't think
mainline-branch has been merged, so there is more fun to be had
sorting that out when the next merge from mainline happens.
We are now in the middle of an expensive and risky project to repair
the damage, since people pulled and pushed afterward, before the
problem was noticed.
I suggest that this problem could easily have been avoided if "git
stash" refused to run with a pending merge (present MERGE_HEAD file),
since this is crucial repository state that it does not save. This
seems similar to what "git cherry-pick" does.
-Scott
next reply other threads:[~2013-06-07 6:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-07 6:52 Scott McPeak [this message]
2013-06-07 18:47 ` git stash while pending merge should not be allowed Junio C Hamano
2013-06-13 23:59 ` Scott McPeak
2013-06-14 8:30 ` John Keeping
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=51B18331.6060302@coverity.com \
--to=smcpeak@coverity.com \
--cc=git@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).