On Wed, Feb 25, 2009 at 01:26:11AM -0800, Junio C Hamano wrote: > Of course. "Encouraging a behaviour" means just that. A better workflow > and a better use of branches. I don't agree that it is necessarily a better workflow. > > When you think about "is my current branch ready to push?" there is no > > reason for you to think of that other long-running branch that you > > haven't seen for days. > > Sorry, I have to disagree with that. > > We are talking about people to whom the "push matching refs" is a problem, > and that means they are using a branch with the same name with other > people (either from a shared central repository or his own publishing > branch) to house long-running, intermediate, uncooked state. I do this all the time by making "wip" commits on top of my topic branches. I push the topic branches to a networked repo so they are accessible and backed up. Then when I work, I do something like: (1) git checkout jk/existing-topic (2) hack hack hack (3) # oops, must sleep on this topic (4) git commit -a -m wip (5) sleep sleep sleep (6) # oops, I need to work on something else this morning (6) git checkout -b jk/new-topic master (7) # ok, master is ready (8) git push origin HEAD I don't want my WIP commit pushed; it is a purely local and temporary placeholder. It seems that you are suggesting that I should never put such uncooked state onto a branch that has already been pushed. Which means I should replace (4) with "git checkout -b jk/topic-subtopic". This is a pain. When I come back to the topic, I want to: git checkout jk/existing-topic gitk origin.. ;# where was I? Oh right, a WIP. I think where I am leaving your mental model is that my published branches are not necessarily "long running" in the same way that you think. I publish them so I can pick them up elsewhere, and maybe even so other people can see what I'm working on. But they really are topic branches. -Peff -- 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
