Re: [RFC] New kind of upstream branch: base branch

[Ramkumar Ramachandra <artagnon@gmail.com>]

Kevin Bracey wrote:
> What I'll often be doing is creating a topic branch based on master or
> origin/master. (I would hardly ever be updating master or pushing to
> origin/master myself, so I probably should be just doing origin/master, but
> I tend to create a local master just to save typing on all those "git rebase
> origin/master").

branch.<name>.merge was designed primarily for pull and merge.  I use
operations like git diff origin.., git log origin.., git rebase [-i]
origin.  Ofcourse, rebase is a bit of a special case because it
defaults to operating on branch.<name>.merge by default: this is
useful to me when I want to rebase against what I just fetched
(central workflows: we're slowly getting triangular workflows).
Abusing branch.<name>.merge because you want a different default for
rebase means we're doing something wrong.  Perhaps we should get a
rebase.defaultUpstream = @{u}|origin|... -- @{u} being the current
default.  In my opinion, branch.<name>.base is a huge overkill.

> During work, to give others visibility, and the possibility to tinker with
> the topic branch during development (as we don't have full inter-site
> sharing of work areas), I would push the topic branch up to the central
> "origin" server, often with a "kbracey/" prefix, partially for namespacing,
> and partially to indicate it's currently "private" work and subject to
> rebasing.  I guess I could create the topic branch as "kbracey/topic"
> locally, but I'd rather not have to.

All we have to do for this is to allow the user to set a custom
refspec using remote.<name>.push.  The refspecs you get now are
limited to the ones set by the different modes of push.default (see
builtin/push.c to see what refspec each of them set).  We discussed
branch.<name>.push too on another thread, but I'm not convinced that
we need it.

> (Although I'm not much of a puller - I tend to fetch then rebase manually).

pull needs to be fixed.  I've partially fixed the rebasing pull thing
with rebase.autostash (still in pu), but there's a lot of work to be
done there.

> And it would be ideal if the initial base and push tracking information
> could be set up automatically on the first "git checkout -b"/"git branch"
> and "git push". (For one, I've always found it odd that there's an asymmetry
> - if you check out a topic branch from the server to work on or use it, you
> get a local copy with upstream set by default. But if you create a topic
> branch yourself then push it, the upstream isn't set by default - you need
> the -u flag. This seems odd to me, and I've seen others confused by this).

It happens because @{u} doesn't exist before the first push.  We
should definitely fix git checkout -b to inherit branch.<name>.remote
and infer branch.<name>.merge.

To sum it up, lots of work to be done.