On Thu, Jan 30, 2020 at 10:37:38PM +0100, Marc-André Lureau wrote: > Hi > > On Fri, Jan 24, 2020 at 11:41 PM SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote: > > > > On Sun, Jan 12, 2020 at 08:59:04PM -0500, Eric Sunshine wrote: > > > On Sun, Jan 12, 2020 at 7:14 AM SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote: > > > > On Sat, Jan 11, 2020 at 08:27:11PM -0500, Eric Sunshine wrote: > > > > > Taking a deeper look at the code, I'm wondering it would make more > > > > > sense to call wt_status_get_state(), which handles 'rebase' and > > > > > 'bisect'. Is there a reason that you limited this check to only > > > > > 'rebase'? > > > > > > > > What branch name does wt_status_get_state() return while bisecting? > > > > The branch where I started from? Because that's what 'git status' > > > > shows: > > > > But am I really on that branch? Does it really makes sense to edit > > > > the description of 'mybranch' by default while bisecting through an > > > > old revision range? I do not think so. > > > > > > It's not clear what downside you are pointing out; i.e. why would it > > > be a bad thing to be able to set the branch description even while > > > bisecting -- especially since `git status` affirms that it knows the > > > branch? > > > > No, during a bisect operation 'git status' knows the branch where I > > _was_ when I started bisecting, and where a 'git bisect reset' will > > eventually bring me back when I'm finished, and that has no relation > > whatsoever to the revision range that I'm bisecting. > > > > Consider this case: > > > > $ git checkout --orphan unrelated-history > > Switched to a new branch 'unrelated-history' > > $ git commit -m "test" > > [unrelated-history (root-commit) 639b9d1047] test > > <...> > > $ git bisect start v2.25.0 v2.24.0 > > Bisecting: 361 revisions left to test after this (roughly 9 steps) > > [7034cd094bda4edbcdff7fad1a28fcaaf9b9a040] Sync with Git 2.24.1 > > $ git status > > HEAD detached at 7034cd094b > > You are currently bisecting, started from branch 'unrelated-history'. > > (use "git bisect reset" to get back to the original branch) > > > > nothing to commit, working tree clean > > > > I can't possible be on branch 'unrelated-history' during that > > bisection. > > > > > > OTOH, while during a rebase we are technically on a detached HEAD as > > well, that rebase operation is all about constructing the new history > > of the rebased branch, and once finished that branch will be updated > > to point to the tip of the new history, thus it will include all the > > commits created while on the detached HEAD. Therefore, it makes sense > > conceptually to treat it as if we were on the rebased branch. That's > > why it makes sense to display the name of the rebased branch in the > > Bash prompt, and that's why I think it makes sense to default to edit > > the description of the rebased branch without explicitly naming it. > > > > With bisect that just doesn't make sense. > > If the range you are bisecting belongs or lead to the current branch, > that still makes sense. And it's probably most of the time. So, I am > not sure your objection is valid enough here. I'm not sure what you mean with "belongs or lead to" a branch. Do you mean that the range is reachable from the branch that just so happened to be checked out when the bisection was started? Well, I have over 30 branches from where v2.25.0 is reachable, and all of them are obviously bad candidates for editing their descriptions by default while bisecting a totally unrelated issue.
