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

From: Steffen Prohaska <prohaska@zib.de>
Date: Oct 25, 2007, 06:02 UTC
Message-ID: <79366145-3C91-4417-B62C-FFF9EC452076@zib.de>
In-Reply-To: <Pine.LNX.4.64.0710250021430.25221@racer.site>

On Oct 25, 2007, at 1:28 AM, Johannes Schindelin wrote:

Show 26 quoted lines

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

But these two types of branches already behave differently when I call "git pull". There is already some kind of "illusion" that some local branches are more tightly connected to remote branches than others.

"git pull" could help to make the illusion even better. The illusion would be better if it was easier to keep the heads of the local branches near to the heads of branches they automatically merge from, as long as this is easily possible.

Show 7 quoted lines

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

[1] http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html

Show 10 quoted lines

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

Show 14 quoted lines

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

>>> 	git push origin master

I'd like to see "git push" here. But to make this work without error you'd need to _delete_ master after you pushed. Otherwise it could happen that you later work on a different shared branch and "git push" would complain about master. "git push" would recommend to do a "git pull" and we're back where the discussion started.

Or do you propose to delete master at this point? That is do you propose to _never_ have remote branches checked out locally. Except for a very short period when you do

     git branch -m <shared_branch>
     git push origin <shared_branch>
     git checkout do-not-work-here
     git branch -D <shared_branch>

Show 22 quoted lines

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

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). It would only do more work automatically in the future and report appropriate warnings or errors if it runs into a problem.

	Steffen