On Sat, Jul 14, 2007 at 00:46:54 +0100, David Woodhouse wrote: > On the occasions I actually try to _use_ branches, I find it very > suboptimal. Perhaps it's just because I'm stupid. I'm sure that's why I > ended up committing changes to the wrong branch. But having to rebuild > (even with ccache) after changing branches is a PITA. Just changing > branches at all is a PITA if you have uncommitted changes (which I > usually do because I've usually tested _some_ random patch in a build > tree for the hardware which is closest to hand). Pulling a whole bunch > of unwanted changes on the 'development' branch while on GPRS, when all > I really needed was a single commit from the 'stable' branch also didn't > amuse me, although I'm sure if I had the time to play with it I'd have > been able to avoid that. I have to say it's the exact oposite for me. I used to have branches checked out separately, with arch and than bzr, and I find the git way much easier in the end. Exactly because I don't need the multiple checkouts. Often, each of them needed to contain some local stuff (like test data or some configuration for building) and rebuilding in one of them does not help the others (usually they are very close to each other). For uncommited changes, git makes it possible (yes, I agree it is an extra command one might want to avoid) to commit them and them uncommit or amend the commit when you get back to them. Pulling something into the wrong place can happen quite as likely, at least to me, with separate checkouts as with switching in one place. And than git actually makes it much easier to fix it when you are in a single tree. Until you publish, you git allows fixing anything with commit --amend and/or reset. > I can, and do, mirror stuff from all kinds of suboptimal version control > systems into single-branch git trees. And I include multi-branched git > trees in my definition of 'suboptimal'. My ability to do that doesn't > really help the newbies who are expected with branches, though. For newbies, the bzr approach is much easier to grasp, even though I really find that the git one is actually a little nicer to work with. > I just wish people would make stuff available on the _servers_ in > separate trees rather than in branches -- if some people prefer branches > locally then that's their option; at the moment we kind of force people > into it. They _could_ avoid it but they'd have to know what they're > doing. You can treat the servers as separate trees! When cloning and/or pulling, you can set up to pull just the one branch you are interested in. Having them as separate trees would either be inefficient (the data would not be shared), or would bring it's own class of problems. I would like, if git could have something like "checkouts". The idea is, that a checkout would contain the working tree, .git/HEAD saying what revision it is at and .git/index and everything else would be linked from the repository it is checked out from. That would allow you to have different branches checked out at different places, while not only sharing all the data, but also all of them available in all the checkouts and commands like pull updating it in all of them. It would be IMHO possible to symlink all the stuff in .git except HEAD and index, except for one problem. This is if you have two checkouts from the same branch and check out of them, the other one needs to know, that it's head should now be detached to stay where it was. -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
