Re: git-bug: Distributed bug tracker embedded in git

From: Elijah Newren <newren@gmail.com>
Date: Aug 19, 2018, 02:06 UTC
Message-ID: <CABPp-BE+zfWOqQQoO0mvJPefODW3fDsfYuC6OzBzSD5fe1xarg@mail.gmail.com>
In-Reply-To: <20180818225052.GE144170@aiede.svl.corp.google.com>

On Sat, Aug 18, 2018 at 3:50 PM Jonathan Nieder <jrnieder@gmail.com> wrote:

> (cc-ing Elijah Newren for the points about merging)

Show 15 quoted lines

> [...]
> > Git doesn't provide a low-level command to rebase a branch onto
> > another without touching the index.
>
> Thanks for pointing this out.  There's been some recent work to make
> Git's merge code (also used for cherry-pick) less reliant on the index
> and worktree.  See https://crbug.com/git/12 for some references.
> There's also been some heavy refactoring of "git rebase" code to be in
> C and be able to make use of library functions instead of being a
> shell script.
>
> That's all to say that we're in a pretty good place to consider
> introducing commands like
>
>   git cherry-pick --onto=<branch> <revisions>

Yes, indeed, after the merge refactoring/rewriting stuff is complete, this is one thing already on my list that I wanted to do with it. Another thing I'd like to investigate with it is how much "in-memory" merges could speed up interactive rebases, as suggested by Dscho[1]. Once we do "in-memory" merges for interactive rebases for performance reasons, we're pretty close to having a rebase-without-touching-index-or-worktree that we can make accessible to other scripts like git-bug. However, we have to have a pretty good answer about what to do when we hit conflicts.

[1] https://public-inbox.org/git/nycvar.QRO.7.76.6.1806100006000.77@tvgsbejvaqbjf.bet/