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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html