On 17/05/2013 22:51, Junio C Hamano wrote:
Kevin Bracey <ke...@bracey.fi> writes:
On 15/05/2013 23:34, Felipe Contreras wrote:
I think I'm using 'upstream' for something it was not intended to,
and
I think the current 'upstream' behavior should be split into
'upstream' and 'base'.
I found myself thinking the same thing. It's really convenient being
able to set your topic branch's upstream to another local branch, so
What is that "another local branch"? ... And if that is your workflow, setting
push.default to "current" (and setting remote.pushdefault to your
publishing repository) should be a sufficient interim solution, and
you do not need to set branch.$name.push to each and every branch
you intend to push out, I think.
I agree that using "push.default current" covers some cases - I hadn't
really considered it - tended to just stick with "upstream". "current"
nearly does the job, but I will sometimes be wanting different names.
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").
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.
So I'd like "git rebase (-i)" to move my topic branch up
(origin/)master. And I'd like "git push (-f)" to send it to
"origin/kbracey/topic". And by extension, I suppose "git pull --rebase"
to update origin/master and rebase. (Although I'm not much of a puller -
I tend to fetch then rebase manually).
The final releasing procedure for the topic branch would be to hand that
branch over to an integrator, who would then merge/rebase it into master.
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).
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
