Re: What actually is a branch?

> 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.

>
>> > 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*.

>
> 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

> 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]).

>
>> > 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.