| Issue 254: | Pushing an old commit to a change marks the change as merged | |
| 2 people starred this issue and may be notified of changes. | Back to list |
Reported by Michael Poole <mdpoole@troilus.org> on Tue Jul 28 11:18:29 PDT 2009 Source: JIRA GERRIT-255 Affected Version: 2.0.17 Gerrit allows an already-submitted commit to be pushed as a new change. This shows up as a new patch set for the commit, which is less than optimal, but also marks the patch as "Merged" -- which is even less desirable. To reproduce: git checkout master # Make and locally commit a change. git push origin HEAD:refs/for/master # Assume that the change number is 1234. git checkout origin/master # Make a different change, but forget to commit it. git push origin HEAD:refs/patches/1234 # Now change 1234 has moved to "Merged".
Sep 24, 2009
#1
code-rev...@gtempaccount.com
Sep 24, 2009
Update by Shawn Pearce <sop@google.com> on Tue Jul 28 11:22:07 PDT 2009
Status:
WontFix
Sep 24, 2009
Comment by Michael Poole <mdpoole@troilus.org> on Tue Jul 28 12:50:18 PDT 2009 My concern -- the mistake that I made -- is that the user can accidentally replace the change with an ancestor of the existing change. This seems like an awkward way to abandon the change. Could Gerrit reject that specific (attempted) operation without affecting the feature from GERRIT-54?
Sep 24, 2009
Comment by Shawn Pearce <sop@google.com> on Tue Jul 28 12:55:35 PDT 2009 Oh, that's a good point. Replacing a change with an ancestor of an existing patch set is likely to be an error if the replacement commit is already merged into the branch. I'll reopen this and look at implementing that sanity check.
Sep 24, 2009
Update by Shawn Pearce <sop@google.com> on Tue Jul 28 12:55:38 PDT 2009
Status:
New
Sep 24, 2009
(No comment was entered for this change.)
Owner:
s...@google.com
Sep 24, 2009
(No comment was entered for this change.)
Status:
Accepted
Cc: mdpo...@troilus.org
Nov 21, 2009
(No comment was entered for this change.)
Owner:
s...@google.com
|
|
| ► Sign in to add a comment |