git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Marc-André Lureau" <marcandre.lureau@gmail.com>
To: "SZEDER Gábor" <szeder.dev@gmail.com>
Cc: Eric Sunshine <sunshine@sunshineco.com>, Git List <git@vger.kernel.org>
Subject: Re: [PATCH] branch: let '--edit-description' default to rebased branch during rebase
Date: Fri, 31 Jan 2020 16:59:15 +0100	[thread overview]
Message-ID: <CAJ+F1CLtDET6L-CGo=j0Yj0aPVSbec=57MPgaGrhr3L8dpCSSQ@mail.gmail.com> (raw)
In-Reply-To: <20200131155228.GF10482@szeder.dev>

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.

-- 
Marc-André Lureau

  reply	other threads:[~2020-01-31 15:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-11 12:35 [PATCH] branch: let '--edit-description' default to rebased branch during rebase marcandre.lureau
2020-01-11 13:26 ` Eric Sunshine
2020-01-11 14:54   ` Marc-André Lureau
2020-01-12  1:27     ` Eric Sunshine
2020-01-12  6:44       ` Marc-André Lureau
2020-01-12 12:14       ` SZEDER Gábor
2020-01-13  1:59         ` Eric Sunshine
2020-01-24 22:41           ` SZEDER Gábor
2020-01-30 21:37             ` Marc-André Lureau
2020-01-31 15:52               ` SZEDER Gábor
2020-01-31 15:59                 ` Marc-André Lureau [this message]
2020-01-31 16:16                   ` SZEDER Gábor
2020-02-06 22:26                     ` Marc-André Lureau
2020-02-07 10:02                       ` SZEDER Gábor
2020-02-07 14:16                         ` Marc-André Lureau
2020-02-07 18:57                           ` Junio C Hamano
2020-02-07 19:09                             ` Marc-André Lureau
2020-02-07 19:12                               ` Junio C Hamano
2020-02-07 19:29                                 ` Eric Sunshine
2020-02-07 20:14                                   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ+F1CLtDET6L-CGo=j0Yj0aPVSbec=57MPgaGrhr3L8dpCSSQ@mail.gmail.com' \
    --to=marcandre.lureau@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sunshine@sunshineco.com \
    --cc=szeder.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).