Re: [PATCH] branch: let '--edit-description' default to rebased branch during rebase

> > > > > > > > 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.
> > > >
> > >
> > >
> > > If we take that simple example:
> > >
> > > * (my-branch)
> > > *
> > > * bisect bad
> > > *
> > > * (HEAD)
> > > * bisect good
> > > *
> > >
> > > It makes a lot of sense to me to edit my-branch description by
> > > default, even if the range good-bad happen to exist in other branches.
> >
> > I still don't understand why it would make sense.
> >
> > Furthermore, how do you think you could avoid choosing an obviously
> > bad branch to default to?
> 
> It uses the same branch that git status displays. In your example:
> 
> You are currently bisecting, started from branch 'unrelated-history'.

> So it's not completely off to pick that branch by default for
> --edit-description.
> 
> But again, I think you are focusing on a rather rare case, please
> consider the most common case.