On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:

quoted text
> And here I have to disagree strongly.  In a workflow based on a shared
> repository, you do not want to merge.  You want to rebase.  First  
> thing
> you do when switching to another branch is fetch + rebase (that's  
> why I
> want an option to "pull --rebase" other branches).
>
> But _even if_ you merge instead of rebase, I fail to see how the  
> current
> situation is different from CVS (which many people maintain is  
> _easier_
> than gi), where first thing you do is to "cvs update".  Just for  
> git it is
> "git pull".
>
> 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.

Your rebase workflow is not possible if more than one dev wants
to work on the topic branch together.

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



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

I absolutely agree that for purely local work topic branches that
are deleted before pushing are a good solution.


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

	Steffen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html