Theodore TsoOn Wed, Nov 15, 2006 at 08:21:36PM -0800, Junio C Hamano wrote:
Show 15 quoted lines
> Theodore Tso <tytso@mit.edu> writes:
> > So with Bitkeeper, with "bk pull" there was never any question about
> > which branch ("line of development") you would be merging into after
> > doing a "bk pull", since there was only one LOD, and given that BK had
> > the rule that a within a LOD only one tip was allowed, a "bk pull"
> > _had_ to do do a merge operation.
>
> I've never used Bk and I really appreciate your comments here.
>
> > If you are operating on your local development branch, the reality is
> > that merging is probably not the right answer in the general case,
>
> I agree, but I wonder why you are pulling/fetching (with or
> without merge) if you are operating on your local development
> branch (implying that you are in the middle of something else).Well, when I was using BitKeeper, I never would. Bitkeeper has what Linus calls the broken "repository == branch" model. So normally I would have one repository where I would track the upstream branch, and only do bk pull into that branch. I would do my hacking in another repository (i.e., branch), and periodically keep track wha was going on in mainline by cd'ing to the mainline repository and doing the bk pull there.
The challenge when you put multiple branches into a single repository, is you have to keep track of which branch you happen to be in. In the BK world, this was obvious because it would show up in my shell prompt:
<tytso@candygram> {/usr/src/linux-2.6} 2%
(OK, obviously I'm in the Linux 2.6 upstream repository)
In a system where you need to keep track of what branch you are in via an SCM-specific local state information, it's easy to get confused and do a pull when you are in the "wrong" branch, or while you have local state in your working directory.
What I currently do (and I'm sure I'm being really horrible and need to be say 100 "Hail, Linus"'es for penance for not adhering staying in the one true distributed state of grace) is that I keep an entirely separate Linux 2.6 git repository just to make sure I never get confused about what branch I might happen to be in when I do the "git pull" --- and yeah, I could have used "git fetch", but 3+ years of BK usage plus Hg usage is hard to get away from. I'm sure this is where Linus would say that use of BK and Hg, causes permanent brain damage, ala's Dijkstra's ofted quoted comment about use of Basic inducing brain damage....
Show 7 quoted lines
> I have to disagree with this. In the simplest CVS-like central > repository with single branch setup in which many "novice users" > start out with, there is almost no need for "git fetch" nor > tracking branch. You pull, resolve conflicts, attempt to push > back, perhaps gets "oh, no fast forward somebody pushed first", > pull again, then push back. So I am not sure where "you really > do not want to use pull. trust me" comes from.
I think the problem is the people who have had years of BK or Hg experience. Maybe it's more of a documentation problem; perhaps a "git for BK" or "git for Hg" users is what's needed. The problem though is that while use of BK is definitely legacy, there are going to be a lot of people who need to use both BK and Hg.
Show 7 quoted lines
> It is a different story for people who _know_ git enough to know > what is going on. They may be using multiple branches and > interacting with multiple remote branches, and there are times > you would want fetch and there are other times you would want > pull. But for them, I do think the suggestion would never end > with "trust me" -- they would understand what the differences > are.
Well, I think this is where git's learning curve challenges are. Yes, for users that are doing the stupidest, most simplistic usage models, git is quite easy to use. And I am willing to grant that for people who are using the deepest, most complicated and most distributed development, who understand multiple branches and the index, and all of the deep git plumbing, there's also no problem.
The challenge is in between; to use a car analogy, git has a great automatic transmision, and an extremely powerful "racing clutch". But for someone where the automatic transmission isn't good enough, when as they start to learn how to use the manual transmission, git's extremely touchy "racing clutch" is much more difficult master --- especially in comparison to people who have learned to drive other, more pedestrian "standard transmission" cars. So people who try to use git's racing clutch keep stalling out the car, and some give up in frustration.
And maybe the problem is one that should be addressed only by lots of training, but at the moment, that's the reason why I believe a number of projects have chosen Hg instead of git; they need more than the "stupid simple" git usage, but if they don't need the extreme power of git, Hg is simpler for people to learn how to use. The problem, of course, comes when later on, the project finds out they really want git's power, and now they have to deal with the repository conversion as well as retraining their entire development community.
But hey, maybe this isn't a problem the git community wants to solve; clearly git is optimized for the Linux kernel development, and maybe it's too much to ask that it also work well for somewhat less extremely distributed development models. But in any case, that's why I chose Hg for e2fsprogs. At the time when I made my choice, git was just too painful to learn how to use its more esoteric features, and Hg was much closer to BK's model. (Since then, Hg has added more functionality, including better multiple branches in a repository support, and it's gotten more complicated, but it's still much simper to teach someone how to use Hg than git.)
Regards,
