Phillip Wood [off-list ref] writes:
On 02/08/17 23:29, Junio C Hamano wrote:
...
quoted
The
latter makes it more in line with how "am -3" followed by "am --no-3
--continue" behaves.
I'm a bit confused about what am does when you pass extra options to
--continue. It looks like they do not persist if there's another
conflict and may only apply to the first patch that is applied when
resuming - I'd need to spend more time looking at the code or run a test
to be sure.
I think you got what "am" wants to do.
The idea is that the user would say she does not trust the three-way
fallback when she starts to apply many patches in an mbox, i.e.
$ git am mbox
Upon seeing a message that does not apply, she would examine the
patch that caused _this_ stoppage, and then decide that it is safe
to apply _this_ patch (but not necessarily later ones) with
three-way fallback and move on:
$ git am -3 --continue
I have not thought too deeply if the parallel applies to
multi-commit pick, though.
"am" (rather, its underlying machinery "apply") is designed to be
all-or-none, so a failed --no-3way application would leave the index
and the working tree intact. "-3 --continue" can retry the failed
step, with "--3way" processing turned on for only one message, from
that state.
But a multi-commit cherry-pick/revert would stop _after_ it munges
the conflicted paths in the index into an unmerged state and writes
the conflicted state into the working tree files. For "--continue
--rerere-autoupdate" to work more like "am --continue -3", it would
have to learn to reset to the state before the failed cherry-pick
first, before re-attempting the failed cherry-pick with the auto
update enabled only for the single commit and keep going. So it may
not as trivial as "am --continue", even though it sounds doable.
On 03/08/17 18:19, Junio C Hamano wrote:
Phillip Wood [off-list ref] writes:
quoted
On 02/08/17 23:29, Junio C Hamano wrote:
...
quoted
The
latter makes it more in line with how "am -3" followed by "am --no-3
--continue" behaves.
I'm a bit confused about what am does when you pass extra options to
--continue. It looks like they do not persist if there's another
conflict and may only apply to the first patch that is applied when
resuming - I'd need to spend more time looking at the code or run a test
to be sure.
I think you got what "am" wants to do.
The idea is that the user would say she does not trust the three-way
fallback when she starts to apply many patches in an mbox, i.e.
$ git am mbox
Upon seeing a message that does not apply, she would examine the
patch that caused _this_ stoppage, and then decide that it is safe
to apply _this_ patch (but not necessarily later ones) with
three-way fallback and move on:
$ git am -3 --continue
I have not thought too deeply if the parallel applies to
multi-commit pick, though.
"am" (rather, its underlying machinery "apply") is designed to be
all-or-none, so a failed --no-3way application would leave the index
and the working tree intact. "-3 --continue" can retry the failed
step, with "--3way" processing turned on for only one message, from
that state.
But a multi-commit cherry-pick/revert would stop _after_ it munges
the conflicted paths in the index into an unmerged state and writes
the conflicted state into the working tree files. For "--continue
--rerere-autoupdate" to work more like "am --continue -3", it would
have to learn to reset to the state before the failed cherry-pick
first, before re-attempting the failed cherry-pick with the auto
update enabled only for the single commit and keep going. So it may
not as trivial as "am --continue", even though it sounds doable.
Thanks for explaining that, as you say having cherry-pick take
'--rerere-autoupadate' with '--continue' sounds more complicated than
the am case. Also I'm not sure it would be as helpful to toggle
'--rerere-autoupdate' with cherry-pick as it is to toggle '--3way' with
am as it's not that hard for the user to stage the merged files
themselves. If you're happy with the way it is currently implemented I'm
not inclined to change it.
Thanks
Phillip