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

["SZEDER Gábor" <szeder.dev@gmail.com>]

On Fri, Jan 31, 2020 at 04:59:15PM +0100, Marc-André Lureau wrote:
> Hi
> 
> On Fri, Jan 31, 2020 at 4:52 PM SZEDER Gábor <szeder.dev@gmail.com> wrote:
> >
> > 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@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.
> >
> > 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?