Re: mtimes of working files

[Jan Hudec <bulb@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 3589 bytes --]

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@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]