Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued

> 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 I think I have to drive my message home again: if what you 
> > > > desire becomes reality, you take away the clear distinction 
> > > > between local and remote branches.  In fact, those branches are 
> > > > neither local (because the next pull will automatically update 
> > > > them with remote changes, but _only_ if they fast-forward) nor 
> > > > remote (because you plan to work on them locally).
> > > 
> > > Exactly, because I do not work on those branches alone. These are 
> > > _shared_ branches. I can work on such a branch with a group of 
> > > developers. I'm willing to accept this bit of chaos.
> > 
> > It is not just a chaos.  I see a serious problem here.  On _your_ 
> > computer, you do _not_ have a shared branch.  Which is visible _even_ 
> > in your modified work flow when you have unpushed changes.
> > 
> > So your desired illusion that your local branches are anything but 
> > local branches will never be perfect enough.
> 
> Ok, there is not a fundamental difference between local branches
> that automatically merge from remotes and local branches that
> are purely local and _never_ merge anything automatically. Both
> are only local branches.

> > > Your rebase workflow is not possible if more than one dev wants to 
> > > work on the topic branch together.
> > 
> > Why not?  I do it all the time.  CVS users do it all the time, for 
> > that matter.
> 
> You're right. You can rebase your local changes on top of the new shared 
> remote head. And this is probably the best thing you can do to get a 
> clean history. Maybe it should be easier.

> So, do I understand correctly, what you propose is:
> - never merge but only rebase
> - Due to lacking support for this in "git pull", never use
>  git pull when working with shared branches but instead _always_ use
>  "git fetch; git rebase origin/<branch_I'm_on>".
> 
> So you say that one of the first messages in "git for CVS users", "The 
> equivalent of cvs update is git pull origin" [1], is wrong. I don't 
> think I'm able to sell your proposed workflow with the current 
> documentation. But maybe I try if I'm absolutely convinced that it is 
> superior.

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

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

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