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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

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.

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

> Eventually you can linearize such a topic branch using rebase. But you 
> need to agree first that everyone else needs to delete the branch.

No, you can linearize your branch already while cleaning up your local 
branch before continuing to work on the topic.

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

> > 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
> > 	git push origin master
> > 
> > If you should not be ready to push by the end of the day, no need to
> > worry.  Just stay on that topic branch, and before pushing, do
> > 
> > 	git fetch
> > 	git rebase origin/master
> > 
> > In _every_ case where I explained git, I found that people appreciated the
> > two-step procedures (like you will find in the examples I showed you
> > above): one git command to work locally, and one to push/fetch to/from
> > origin.
> 
> Maybe. I know git quite well now and in a shared workflow "git pull"
> with auto-fast-forward would help me. I often need to run "for each
> local branch: git checkout ; git merge" to get rid of the errors
> reported by "git push".

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.

Ciao,
Dscho