From: Steffen Prohaska Date: Thu, 25 Oct 2007 12:04:40 GMT Subject: Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued Message-ID: <8C2ADF84-2E35-46D3-B894-68341CF26A81@zib.de> In-Reply-To: On Oct 25, 2007, at 12:27 PM, Johannes Schindelin wrote: > Hi, > > On Thu, 25 Oct 2007, Steffen Prohaska wrote: > >> On Oct 25, 2007, at 1:28 AM, Johannes Schindelin wrote: >> >>> On Thu, 25 Oct 2007, Steffen Prohaska wrote: >>> >>>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote: [...] >>>>> But here is a proposal which should make you and your developers >>>>> happy, _and_ should be even easier to explain: >>>>> >>>>> Work with topic branches. And when you're done, delete them. >>>> >>>> Again, if you want to share the topic branch the situation gets >>>> more >>>> complex. >>> >>> Hardly so. In my proposed solution to your problem, there is >>> nothing >>> which prevents you from working off of another branch than "master". >> >> Well if you have several local branches checked out that are >> shared with others you run into the "git push" problem again ... >> (see below at git push origin master). > > Do the same as I, always say "git push origin master" (of course, you > should exchange "master" with whatever branch you want to push). Be > precise. Well, I'm lazy. git already knows everything. It knows that the current branch is associated with a specific remote and it pushes matching branches by default. And I took care to not pollute the namespace. All my branches are named identical in all repositories I'm dealing with. It's reasonable to want "git push" to do the right thing. >>>>> So the beginning of the day could look like this: >>>>> >>>>> git fetch >>>>> git checkout -b todays-topic origin/master >>>>> >>>>> [hack hack hack] >>>>> [test test test] >>>>> [debug debug debug] >>>>> [occasionally commit] >>>>> [occasionally git rebase -i origin/master] >>>>> >>>>> and the end of the topic >>>>> >>>>> git branch -M master >> >> Isn't this a bit dangerous? It forces to overwrite master no matter >> what's on it. You don't see diffstats nor a fast forward message that >> confirms what you're doing. > > Yeah, I should have said something like "git branch -m master" > (implicitely assuming that you have no current "master" branch). > >>>>> git push origin master >> >> I'd like to see "git push" here. > > I think it is not asking too much for the user to be a bit more > precise. > If you really do not trust your developers to be capable of that, > point > them to git gui. Well I was more precise and got lazy over time. Now the most I do is "git push --dry-run" and if it looks good I do "git push". Most of the time I just say "git push". As I pointed out earlier, "git push origin " can create a new branch on the remote. "git push" never creates a new branch. I believe "git push" is safer. >> git branch -m >> git push origin >> git checkout do-not-work-here >> git branch -D > > Actually, the last two commands would better be > > git checkout HEAD^{commit} > git branch -d Wow, looks weird (not too me but to someone who doesn't know git). >>> The problem I see here: you know git quite well. Others don't, and >>> will be mightily confused why pull updates local branches sometimes, >>> and sometimes not. >> >> But it already happens now. "git pull" sometimes merges a remote >> branch >> (--track) and sometimes it reports an error that is fails to do so >> (--no-track). > > If there really is an inconsistent behaviour, then we'll have to > fix that. > We should not introduce inconsistent behaviour on top of that. It's not inconsistent. It's an option of a branch. Git supports two flavours of local branches. Some branches automatically merge and other don't. Steffen