Hi,

On Wed, 24 Oct 2007, Steffen Prohaska wrote:

quoted text
> On Oct 24, 2007, at 11:28 PM, Peter Baumann wrote:
> 
> > You can't check what got added in your pull, e.g you can't review the 
> > new code with something like
> > 
> > 	gitk next..origin/next
> 
> You're not forced to pull. Just use "git fetch" if you want to do this. 
> Or is something missing if you'd be limited to "git fetch"?

I am more concerned about having very fuzzy meanings of our nomenclature. 
As of now, "pull = fetch + merge".  You want to change that, and I am sure 
that it is harder to explain, Andreas' insistence on my being wrong 
notwithstanding.

Whenever I told people "pull = fetch + merge", they got it.  Often I would 
start a talk about git by introducing distributed development.  By stating 
that working in a working directory is already forking, only without 
commiting.  Then I'd go into details, by saying that there are multiple 
repositories, and that you can update local copies of the remote branches 
by "git fetch".  And you can merge by "git merge".  And then I would write 
down on the blackboard -- the first written thing in my talk! -- pull = 
fetch + merge.

My "pupils" _always_ liked the preciseness of the nomenclature.  And they 
made many less mistakes because they had a clear mental model of what is 
remote, and what is local.  And that local branches are always forks.

quoted text
> > I often do something like this, just to see what got changed. So at 
> > least in my opinion you have to add a third point:
> > 
> >  * the branch has no modifications what so ever
> >  * the branch is set up to auto-merge with the particular branch
> >    fetched from the particular remote
> > 				AND
> >  * the user set a config option to always autofastfoward if the above
> >    conditions are true! This could be implemented as a global option with
> >    a per branch overwrite.
> 
> I (and, as I understood, Andreas, too) want to change the default. 
> Because we believe that git would be easier to use in workflows based on 
> a shared repository.

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

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.

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.

Ciao,
Dscho

-
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