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

> Hi
> 
> On Fri, Jan 24, 2020 at 11:41 PM SZEDER Gábor <szeder.dev@gmail.com> 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@gmail.com> 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.