Hi Phillip, On Thu, Mar 28, 2019 at 9:23 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: > 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: > >>> 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 really like that way of putting it; I think that makes it much clearer. Note, though that staged changes and conflicts could happen with any of rebase, merge, cherry-pick, or revert, so this problem is not limited to a subset of those operations. > > 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.) I understand the desire to prevent mis-uses, and I agree that if there are staged changes or conflicts it's really likely things will go sideways. But I think we should instead check for those situations rather than use e.g. rebase vs. merge as a proxy for whether those problems could be present. I am especially concerned with the idea of having something like "git switch --ignore-in-progress --discard-changes" being used to quit merges or cherry-picks or reverts or even rebases. In my opinion, doing so is creating flags to combine uncommon pairs of git commands (git <operation> --quit + git switch) in a way that is far less clear. I think that's a bad route to go down, and we should keep the commands orthogonal (if I could start all over, I'd also make reset and checkout and everything else stop modifying any in-progress state). Instead, I would either: * Drop `--ignore-in-progress` for now. (Although Duy had a meaningful usecase) OR * Make `git switch --ignore-in-progress <branch>` leave all process state in place and switch branches, if we would otherwise be able to switch branches (i.e. there isn't dirty or conflicted changes in the way). BUT, make sure to also: * Make '--ignore-in-progress' incompatible with both '-m' and '--discard-changes'; if folks try to use either of those additional options with --ignore-in-progress, tell people to use `<operation> --quit` first. Do NOT provide an override. (Alternatively, refer to `<operation> --quit` as the override, since it is). Elijah
