Re: What actually is a branch?

[Sergey Organov <sorganov@gmail.com>]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Sergey Organov wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> 
>> > Since this is not strictly related to the topic of `git switch` I
>> > renamed the thread.
>> >
>> > Sergey Organov wrote:
>> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> >> > Sergey Organov wrote:

[...]

>> >> As for branch tail, I do have convention of marking start of a
>> >> long-standing branch with corresponding tag, where branch "foo" has
>> >> corresponding "foo-bp" tag marking its "branch point". Recently I
>> >> started to mark start of feature branch with yet another branch "foo-bp"
>> >> rather than tag, "foo" being set to track "foo-bp", that allows to
>> >> automate rebasing of "foo" against correct base.
>> >
>> > So foo-bp is the upstream of foo, and you do basically:
>> >
>> >   git rebase foo@{upstream}
>> 
>> Yep, but essential feature to me is that I in fact use tools that simply
>> run bare
>> 
>>    git rebase
>> 
>> and that "just works" (tm).
>
> I typed the revision explicitly, but `git rebase` would work just
> fine.

Sorry, I don't follow. Did you change semantic of `git rebase`? With
current mainstream Git, as far as I can tell,

  git rebase

essentially is:

  git rebase --fork-point @{upstream}

How introduction of @{tail} changes this, exactly?

>
>> > This is works if your base (or tail, or whatever) is static, but many
>> > branches jump around, and that's where @{tail} comes in handy.
>> 
>> Yeah, I see. When I need to make a branch jump around, I do need to
>> manually move my references, but that's fortunately very rare use-case
>> for me. Having direct support for that is still a win.
>> 
>> >
>> > You can do this:
>> >
>> >   git rebase --onto foo@{upstream} foo@{tail}
>> >
>> > This will always rebase the right commits (no need to look into the
>> > reflog). So you can say that the branch is foo@{tail}..foo.
>> 
>> I see where and when it's useful, but for a feature branch 99% of times
>> I don't want to rebase it onto some true upstream. I rather want to just
>> fiddle with the branch in place, and I prefer to setup things the way
>> that ensures that bare "git rebase" does "the right thing".
>
> But that's precisely the point: when you do `git rebase` you don't have
> to type the base or --onto anymore. It's done automatically.
>
> Not just for your long-standing branches, but for *any* branch.
>
>> Probably that could be solved by a branch-local configuration that makes
>> "git rebase" become "git rebase @{tail}" for the branch instead of "git
>> rebase @{upstream}"
>
> No. @{upstream} is where you want to rebase *to*, @{tail} is where you
> want to rebase *from*.

My point is that for feature branch I rather want to rebase from @{tail}
to @{tail} 99% of times.

>
> When you do:
>
>   git rebase foo@{upstream}
>
> This is basically the same as:
>
>   git checkout foo@{upstream}^0
>   git cherry-pick --right-only foo@{upstream}...foo

Yes, but you probably meant foo@{upstream}..foo (2 dots, not 3) here.

> git is smart enough to figure out what commits are already part of
> foo@{upstream}, and those are skipped, but at no point was any "base"
> calculated (at least not from `git rebase`).
>
> Most of the time `git rebase` works fine, because there aren't too many
> commits to figure out where they should go, but it's definitely not
> efficient, and there's many corner-cases (see a Linux kernel maintaner
> baffled by what the hell `git rebase` is doing [1]).

Once again, how exactly the foo@{tail} fits in this picture?

>
>> > Another advantage of having this notion is that `git rebase`
>> > automatically updates the tail (in this case to foo@{upstream}).
>> 
>> Yep, looks useful. Is it all local to given repo, or else?
>
> I implented it as 'refs/tails' (as opposed to 'refs/heads'), so it's
> local to a given repo, but could easily be exported.

Do I get it right that now `git switch br1; git rebase --onto br2` will
likely have different outcome in the repository where "br1" has been
created compared to any other repository, as "br1@{tail}" will only
exist in that exact repo?

Thanks,
-- 
Sergey Organov