Hi, On Wed, 24 Oct 2007, Steffen Prohaska wrote: > 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. > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
