On 28/03/2019 11:04, Duy Nguyen wrote:
On Wed, Mar 27, 2019 at 5:24 PM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote:
On 26/03/2019 15:48, Elijah Newren wrote:
On Tue, Mar 26, 2019 at 8:24 AM Duy Nguyen <pclouds@xxxxxxxxx> wrote:
On Tue, Mar 26, 2019 at 10:01 PM Elijah Newren <newren@xxxxxxxxx> wrote:
Yeah.. --ignore-in-process does not necessarily mean aborting
something when you just want to get out to examine some other commit.
And I agree doing nothing seems like the best (or least
confusing/surprising) option.
There will be some funny thing. Like if you commit after switching
away and MERGE_HEAD is there, I think you will be creating a merge
commit.
Yes, and in the middle of a cherry-pick with a range you've added some
commits to one branch and some to another. In the middle of a revert
you're doing similar. It sounds like crazytown to me (and maybe we
shouldn't provide the --ignore-in-process flag unless users clamor for
it
I missed this part in my last reading. I think if we could safely
switch away and get back to resume, then --ignore-in-process could
still be useful.
If we can get back safely then that makes sense, I'm not sure about
switching while there are conflicts or staged changes though, it feels
like there's more potential for things to go wrong there.
I sometimes switch to another commit to check out
stuff then back. For interactive rebase with "edit" command for
example, it's quite safe to do so. (yes the other option is "git
worktree add", but that could be a heavy hammer sometimes) >
I think that could be the way to go for merges and cherry-picks, or
Just so we're clear, what is your "the way" to go? to remove
CHERRY_HEAD_PICK and MERGE_HEAD (and other MERGE_* as well) if
--ignore-in-process is specified? Or to leave MERGE_* and
CHERRY_PICK_HEAD alone and delete other stuff?
I was agreeing with Elijah about dropping --ignore-in-progress unless
there's a demand for it or at least restricting it so that it requires
--discard-changes and aborts in-progress merges and single in-progress
cherry-picks/reverts. (I'm worried about people switching branches when
cherry-picking more than one commit, though as you say it can make sense
during a rebase.)
Best Wishes
Phillip
possibly require --discard-changes as well. The only time I use checkout
like this is during a rebase if I want to rewind it - I edit the todo
list with the output of 'git log --pretty="pick %h %s" --reverse' and do
'git checkout' followed by 'git rebase --continue' Though these days I
could add a 'reset' line to the todo list and skip the checkout.
