On Mon, Jul 4, 2022 at 5:56 AM Derrick Stolee <derrickstolee@xxxxxxxxxx> wrote:
>
> On 7/1/22 3:20 PM, Elijah Newren wrote:
> >> +/*
> >> + * For each 'pick' command, find out if the commit has a decoration in
> > Is this really limited to picks? If someone uses --autosquash and has
> > a fixup or squash in the list, wouldn't this apply as well, or does
> > all of this apply before the transformations to fixup/squash? Also,
> > what if the user is doing --rebase-merges and there's a merge commit
> > with a branch pointing at the merge. Would that be included?
> >
> >> + * refs/heads/. If so, then add a 'label for-update-refs/' command.
> >> + */
>
> This is limited to picks (for now) mostly for the reason that the
> fixup! and squash! commits are probably getting reordered, even if
> they exist at the tip of some refs.
>
> The workflow I am optimizing for is to create fixup! and squash!
> commits at the tip of a long multi-topic series, and then those
> get reordered into the list. In that case, the only ref that is
> pointing at one of those commits is also the HEAD branch, so that
> is not updated using this mechanism.
>
> This is a case where I'm very interested in alternatives here, and
> maybe I should clearly mark this option as experimental so we can
> work out cases like this based on use.
So my question was that if I had the following `git log --oneline
origin/main..` output:
555555 (HEAD -> branch2) fixup! second commit
444444 fourth commit
333333 third commit
222222 (branch1) second commit
111111 first commit
and I run `git rebase -i --autosquash --update-refs origin/main`, what
would I get? Is branch1 updated to the rebase of 222222, or does it
include the amending from squashing 555555 into the rebased 222222?
Does branch2 get "left behind" because it wasn't a pick commit at the
tip of history, leading us to not update branch2 at all? Or does it
get correctly pointed at the rebased version of 444444?
Actually, I checked out ds/rebase-update-ref just now to try it, and
it seems like it does the right thing:
pick 111111 first commit
pick 222222 second commit
fixup 555555 fixup! second commit
update-ref refs/heads/branch1
pick 333333 third commit
pick 444444 fourth commit
# Ref refs/heads/branch2 checked out at '...'
The last line was very disorienting to me at first and made me think
we had a bug, but the update-refs stuff is built on top of the normal
rebase mechanism and branch2 will be updated by that logic rather than
by the special update-refs handling. If I add another branch with a
few commits on top of branch2, then branch2 is indeed updated and
after the pick of 444444 (and the additional branch, say branch3,
would be updated by the normal rebase logic instead of by the
update-refs handling). So it all works correctly, but users might get
worried or confused along the way wondering whether it will function
correctly.
Another part that users might find disorienting is that at the end,
the rebase reports:
Successfully rebased and updated refs/heads/branch2.
which is correct but totally ignores the fact that it *also* rebased
and updated other branches.
