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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: May 18, 2013, 18:14 UTC
Message-ID: <CALkWK0nQVkmq+OdhWhM2EnZKmHxzLQonhd2tUeUvqJNf27GCXA@mail.gmail.com>
In-Reply-To: <51979065.4060609@bracey.fi>

Kevin Bracey wrote:

Show 5 quoted lines

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

Show 7 quoted lines

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

Show 7 quoted lines

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