Bill Lear <rael@xxxxxxxxxx> wrote: > On Thursday, February 15, 2007 at 17:09:18 (-0500) Shawn O. Pearce writes: > >... > >Lets say you patch git-clone to create these branches under > >refs/heads, and also under refs/remotes/origin. Now someone else > >modifies one of those branches, and you do a git-fetch to get the > >latest. The tracking branch under refs/remotes/origin would update, > >but not the one in refs/heads. Which means "jumping right in" may > >actually cost you a lot more time, because you are now starting on > >something that is several days old. > > Granted, but this would be the same as creating the branch by hand, > then going rock-climbing over the weekend, while my colleagues toiled, > and coming back on Monday to find 15 checkins on that branch, right? Yes. Although if you pull something like that, your colleagues may also be muttering things about you near the water cooler... So Git may be the least of your problems. ;-) > At which point I could .... rebase? Do a pull? Rebase or pull, either would work. Rebase would clutter the history less (no merge) but also tosses some history (no merge). Its a tossup. All I was trying to say was this may be more likely to happen, as you will clone, work in that repository for a couple of weeks, then get told to look at the `frotz` branch, as it has all the cool stuff you were looking for. You peek at refs/heads/frotz, and it has some cool stuff, but its 2 weeks out of date. Unless you remember to pull `origin/frotz` to `frotz` first, you might spend a while looking at stale code. -- Shawn. - 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