All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Kristoffer Haugsbakk <code@khaugsbakk.name>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/1] rebase: teach `--exec` about `GIT_REBASE_BRANCH`
Date: Sun, 03 Mar 2024 15:24:48 -0800	[thread overview]
Message-ID: <xmqqo7buuce7.fsf@gitster.g> (raw)
In-Reply-To: <4140fca4f454310d215df8bdac237caeb5c38521.1709495964.git.code@khaugsbakk.name> (Kristoffer Haugsbakk's message of "Sun, 3 Mar 2024 21:03:37 +0100")

Kristoffer Haugsbakk <code@khaugsbakk.name> writes:

> The command fed to `--exec` might need some contextual information from
> the branch name. But there is no convenient access to the branch name
> that we were on before starting the rebase; rebase operates in detached
> HEAD mode so we cannot ask for it directly. This means that we need to
> parse something like this from the first line of `git branch --list`:
>
>     (no branch, rebasing <branch>)
>
> This is a moderate amount of effort for something that git-rebase(1) can
> store for us.
>
> To that end, teach `--exec` about an env. variable which stores the
> branch name for the rebase-in-progress, if applicable.

You seem to be saying that `git branch --list` output already
contains the necessary information but it is shown in a hard to use
format.  Is the information given at least always accurate and
reliable?

Assuming it is, do you know where "git branch --list" gets that
information when it says "(no branch, rebasing <branch>)"?

git-rebase(1) is already storing information sufficient to let "git
branch --list" to produce that information, and there are other ways
to inspect that state ("git status" gives the same information but
it also is in a "meant for humans" format).

So, isn't it just the matter of surfacing the information that we
are already recording and is already available in a fashion that is
easier to use?  For example, if "git status --porcelain=[version]"
does not give the information, perhaps you can add a line or two to
it, instead of duplicating the same information in two places?

It comes from wt-status.c:wt_status_check_rebase() where state->branch
is assigned to, by reading "$GIT_DIR/rebase-{apply,merge}/head-name".



  reply	other threads:[~2024-03-03 23:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-03 20:03 [PATCH 0/1] rebase: teach `--exec` about `GIT_REBASE_BRANCH` Kristoffer Haugsbakk
2024-03-03 20:03 ` [PATCH 1/1] " Kristoffer Haugsbakk
2024-03-03 23:24   ` Junio C Hamano [this message]
2024-03-04  9:56     ` Phillip Wood
2024-03-07 15:18     ` Kristoffer Haugsbakk

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

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

  git send-email \
    --in-reply-to=xmqqo7buuce7.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=code@khaugsbakk.name \
    --cc=git@vger.kernel.org \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.