`git cl patch` doesn't set issue number for the current branch on incomplete merge |
|||||
Issue descriptionChrome Version: (copy from chrome://version) OS: (e.g. Win7, OSX 10.9.5, etc...) What steps will reproduce the problem? (1) Patch a CL with a minor merge conflict against ToT What is the expected result? Either the change is applied to the repo AND the issue number is attached to the branch. What happens instead? The code lands, but there is no commit and the the issue number is not attached. I then have to fix up and add the missing commit (which requires copying the CL description into the commit message manually, since this is different from e.g. a git-native rebase/cherry-pick), and always forget the issue number. That results in an confusing duplicate CL if I don't notice the slight difference from a routine patch upload. In my head, "code from an issue is in the branch" <=> the issue number is set. jparent@, can you help me triage this as a feature request against the build tools?
,
Mar 14 2017
(Please don't assign an owner directly, new issues won't be picked up appropriately by our triage process if they have owner)
,
Mar 14 2017
,
Mar 14 2017
> (Please don't assign an owner directly, new issues won't be picked up appropriately by our triage process if they have owner) Mmkay, but if that results in new bugs going untriaged for months again I reserve the right to assign to people. ;-) On topic: If this behaviour is controversial or difficult to implement correctly, a clear warning line would be a useful cue.
,
Mar 15 2017
> if that results in new bugs going untriaged for months It's true that the Infra>SDK component doesn't have a defined triage process. That said, please only directly assign bugs which aren't getting attention; don't preemptively assign bugs when you first file them, especially when they're Pri-3. But anyway, this one is super easy, so fix here: https://chromium-review.googlesource.com/456039
,
Mar 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/tools/depot_tools/+/d343c63519c179f158c522f27f332e129d27a26c commit d343c63519c179f158c522f27f332e129d27a26c Author: Aaron Gable <agable@chromium.org> Date: Wed Mar 15 20:49:27 2017 git-cl patch: set metadata before (failing to) apply patch If the commit or cherry-pick command fails, git automatically drops the user into a state where they can try to manually fix it. That's great. But with the old call order, it would also leave the metadata unset. This sets the issue and patchset number before doing the potentially-failing heavy lifting, so that the branch will be in a consistent state after the user finishes fixing up the failed command. BUG= 701130 Change-Id: I792b9fb9e61ba62626c19aa1837d21f8cd8f594e Reviewed-on: https://chromium-review.googlesource.com/456039 Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org> Commit-Queue: Aaron Gable <agable@chromium.org> [modify] https://crrev.com/d343c63519c179f158c522f27f332e129d27a26c/tests/git_cl_test.py [modify] https://crrev.com/d343c63519c179f158c522f27f332e129d27a26c/git_cl.py
,
Mar 15 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by lgar...@chromium.org
, Mar 13 2017