mtimes of working files

mtimes of working files

[Yakov Lerner]

How difficult is it to have script (or maybe existing git option)
that would make mtimes of all working files equal to time of last commit ?

Thanks
Yakov

Re: mtimes of working files

[Johannes Schindelin]

Hi,

On Wed, 11 Jul 2007, Yakov Lerner wrote:

> How difficult is it to have script (or maybe existing git option) that 
> would make mtimes of all working files equal to time of last commit ?

I wonder if there was a secret alien invasion three days ago, with an evil 
mental virus weapon?  It seems that this question has been asked three 
times in the last three days, twice on IRC, and once here.

So now, I really, really, really, (repeat that 97 more times in your head, 
please) want to know why?

There must be some super uber-cool application of that, that people 
_insist_ on having it.  And I do not want to be left out.  Please tell me 
how I could use that feature to make my workflow better.

Please, please, please.

Ciao,
Dscho

P.S.: I know how to do it, too.  And no, it does not help to try insulting 
me (unsuccessfully), even in a private chat.

Re: mtimes of working files

[Yakov Lerner]

On 7/11/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 11 Jul 2007, Yakov Lerner wrote:
>
> > How difficult is it to have script (or maybe existing git option) that
> > would make mtimes of all working files equal to time of last commit ?
>
> I wonder if there was a secret alien invasion three days ago, with an evil
> mental virus weapon?  It seems that this question has been asked three
> times in the last three days, twice on IRC, and once here.
>
> So now, I really, really, really, (repeat that 97 more times in your head,
> please) want to know why?
>
> There must be some super uber-cool application of that, that people
> _insist_ on having it.  And I do not want to be left out.

I gave you my reason on IRC, you ignored it. And you continued with
"You must defend your reason. Until you defend your reason, I do not give
you the solution, although I know it". That sounded rude. If you are *curious*,
try to speak not from position of "punishing authority", but as curious people
would normally speak.

> P.S.: I know how to do it, too.  And no, it does not help to try insulting
> me (unsuccessfully), even in a private chat.

If modifying mtimes of working file breaks the git, you should have
mentioned that.

I think  it does not break anything in git.  If this is so you should
have said so
and to give the solution (which you said you know).  I am lost in guesses
as to what makes you keep your monopolistic solution secret.
Hope I can figure it without you.

In the chat, you told me that you know the answer but won't tell me.

I have to tell you that demanding from me that I tell you why other
people asked this, and to withhold the answer on the ground that
I must mind-read them and tell you their mind ... I think this is stupid
attitude on yous part.

Yakov

Re: mtimes of working files

[Johannes Schindelin]

Hi list,

> > > How difficult is it to have script (or maybe existing git option) 
> > > that would make mtimes of all working files equal to time of last 
> > > commit ?

Now I slowly get really curious.  Does _anybody_ know a scenario where 
this makes sense?

(No, Eric, there are enough corner cases where your example of a clustered 
webserver breaks down, so I am not fully convinced that this is a useful 
case.)

Anybody enlighten me?

Ciao,
Dscho

Re: mtimes of working files

[Jan Hudec]

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

On Wed, Jul 11, 2007 at 19:42:10 +0100, Johannes Schindelin wrote:
> Hi list,
> 
> > > > How difficult is it to have script (or maybe existing git option) 
> > > > that would make mtimes of all working files equal to time of last 
> > > > commit ?
> 
> Now I slowly get really curious.  Does _anybody_ know a scenario where 
> this makes sense?
> 
> (No, Eric, there are enough corner cases where your example of a clustered 
> webserver breaks down, so I am not fully convinced that this is a useful 
> case.)
> 
> Anybody enlighten me?

I don't see any case where it would be useful, though I know some version
control systems that provide that feature. I think it is supposed to just be
used for checking which view has newer version.

I first thought the idea had something to do with make, but it will actually
promptly break most build tools, because change to earlier version is
a change too, but they wouldn't detect it.

However I am getting really curious about different thing -- the solution.
Because I think the arguments from keyword expansion discussion apply here
that prevent any *reliable* (you can have unreliable ones just as you can
have unreliable keyword expansion) solution.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

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

Re: mtimes of working files

[Eric Wong]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi list,
> 
> > > > How difficult is it to have script (or maybe existing git option) 
> > > > that would make mtimes of all working files equal to time of last 
> > > > commit ?
> 
> Now I slowly get really curious.  Does _anybody_ know a scenario where 
> this makes sense?
> 
> (No, Eric, there are enough corner cases where your example of a clustered 
> webserver breaks down, so I am not fully convinced that this is a useful 
> case.)

I'll have to admit that most of my git usage is via git-svn, so I
mostly deal with linear history and some branching, but no real merges
in a git sense.

This is what I whipped up the other night:

http://yhbt.net/git-set-file-times

-----------------------------------8<-----------------------------------------
#!/usr/bin/perl -w
use strict;

# sets mtime and atime of files to the latest commit time in git
#
# This is useful for serving static content (managed by git)
# from a cluster of identically configured HTTP servers.  HTTP
# clients and content delivery networks can get consistent
# Last-Modified headers no matter which HTTP server in the
# cluster they hit.  This should improve caching behavior.
#
# This does not take into account merges, but if you're updating
# every machine in the cluster from the same commit (A) to the
# same commit (B), the mtimes will be _consistent_ across all
# machines if not necesarily accurate.
#
# THIS IS NOT INTENDED TO OPTIMIZE BUILD SYSTEMS SUCH AS 'make'
# YOU HAVE BEEN WARNED!

my %ls = ();
my $commit_time;

$/ = "\0";
open FH, 'git ls-files -z|' or die $!;
while (<FH>) {
	chomp;
	$ls{$_} = $_;
}
close FH;


$/ = "\n";
open FH, "git log -r --name-only --no-color --pretty=raw -z @ARGV |" or die $!;
while (<FH>) {
	chomp;
	if (/^committer .*? (\d+) (?:[\-\+]\d+)$/) {
		$commit_time = $1;
	} elsif (s/\0\0commit [a-f0-9]{40}$//) {
		my @files = delete @ls{split(/\0/, $_)};
		@files = grep { defined $_ } @files;
		next unless @files;
		utime $commit_time, $commit_time, @files;
	}
	last unless %ls;

}
close FH;
-----------------------------------8<-----------------------------------------

-- 
Eric Wong

Re: mtimes of working files

[Andy Parkins]

On Wednesday 2007 July 11, Jan Hudec wrote:

> I first thought the idea had something to do with make, but it will
> actually promptly break most build tools, because change to earlier version
> is a change too, but they wouldn't detect it.

I've found git's mtime setting to be the best where make is concerned so I 
would hate to see it changed.  Even when switching branches or rebasing or 
whatever, only the changed files get rebuilt.  The only time you get an 
unnecessary rebuild is if you do

 git checkout branch1
 git checkout branch2
 git checkout branch1

But we can hardly expect git to be responsible for that.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: mtimes of working files

[Randal L. Schwartz]

>>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:

Eric> open FH, "git log -r --name-only --no-color --pretty=raw -z @ARGV |" or die $!;

This breaks needlessly on @ARGV names that contain spaces.  You want:

  open FH, "-|", qw(git log -r --name-only --no-color --pretty=raw -z), @ARGV or die $!;

But that sounds familiar.... I think there's a function somewhere included in
the git distro that does this.  I'm old and senile though. :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: mtimes of working files

[David Woodhouse]

On Thu, 2007-07-12 at 08:57 +0100, Andy Parkins wrote:
> The only time you get an unnecessary rebuild is if you do
> 
>  git checkout branch1
>  git checkout branch2
>  git checkout branch1
> 
> But we can hardly expect git to be responsible for that. 

Indeed. That's a user error. Git makes it cheap and easy to have
separate _trees_. Just use them -- branches are just another mental
hangover from CVS which we should try to cure ourselves of :)

-- 
dwmw2

Re: mtimes of working files

[Eric Wong]

"Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
> 
> Eric> open FH, "git log -r --name-only --no-color --pretty=raw -z @ARGV |" or die $!;
> 
> This breaks needlessly on @ARGV names that contain spaces.  You want:
> 
>   open FH, "-|", qw(git log -r --name-only --no-color --pretty=raw -z), @ARGV or die $!;
> 
> But that sounds familiar.... I think there's a function somewhere included in
> the git distro that does this.  I'm old and senile though. :)

Yep, I added that @ARGV at the last second and didn't care enough to fix
it.  I didn't want to link this into the git build system so that it
could find Git.pm, either.

So I'll just go with this 5.8-ism.  I didn't really intend for that
script to go anywhere, maybe somebody who wants it badly enough can make
the ls-files call respect any path limiting intended in @ARGV but still
allow revision ranges to be passed (my original intention of supporting
@ARGV was only revision ranges).

-- 
Eric Wong

Re: mtimes of working files

[Theodore Tso]

On Thu, Jul 12, 2007 at 06:27:26PM +0100, David Woodhouse wrote:
> On Thu, 2007-07-12 at 08:57 +0100, Andy Parkins wrote:
> > The only time you get an unnecessary rebuild is if you do
> > 
> >  git checkout branch1
> >  git checkout branch2
> >  git checkout branch1
> > 
> > But we can hardly expect git to be responsible for that. 
> 
> Indeed. That's a user error. Git makes it cheap and easy to have
> separate _trees_. Just use them -- branches are just another mental
> hangover from CVS which we should try to cure ourselves of :)

Personally, I just use branches a huge amount, and I will often do

git checkout branch1
<hack hack hack>
git commit --amend
<build, test>
git checkout branch2
<hack hack hack>
git commit
<build, test>
git checkout branch1
<build>

Rebuilding isn't a problem, because I use ccache.  :-)

I could use separate trees, I suppose, but then I have to keep
multiple copies of the .o files around in all of those separate trees,
and it's cheaper and more efficient to keep them in the ccache cache
IMHO.  And with 7200 RPM laptop drives and dual core processors
combined with ccache, I hardly notice the rebuild/relink time.

	     	       	      	     - Ted

Re: mtimes of working files

[David Woodhouse]

On Thu, 2007-07-12 at 20:37 -0400, Theodore Tso wrote:
> I could use separate trees, I suppose, but then I have to keep
> multiple copies of the .o files around in all of those separate trees,
> and it's cheaper and more efficient to keep them in the ccache cache
> IMHO.  And with 7200 RPM laptop drives and dual core processors
> combined with ccache, I hardly notice the rebuild/relink time. 

I'm not entirely sure why it would be cheaper and more efficient to keep
your object files in ccache rather than in the build tree. It takes time
for ccache to do the preprocessing and fetch them, and it takes even
more time to redo the linking.

Disk space is cheap too, and you can always 'make clean' or even remove
all the source files too, if you really care.

Not that I'm presuming to suggest that there's anything _wrong_ with
your choice of workflow, of course -- it just doesn't really make much
sense to me.

Branches just seem like a source of complexity and hence pain. Using git
was just starting to become sensible for newbies, and now when people
are forced to deal with multiple branches it's all horribly painful
again.

-- 
dwmw2

Re: mtimes of working files

[Linus Torvalds]

On Sat, 14 Jul 2007, David Woodhouse wrote:
> 
> Branches just seem like a source of complexity and hence pain. Using git
> was just starting to become sensible for newbies, and now when people
> are forced to deal with multiple branches it's all horribly painful
> again.

Why would anybody force you to do that?

The "switch between branchs in the same repo" is really convenient. But 
nobody *forces* you to do it.

			Linus

Re: mtimes of working files

[David Woodhouse]

On Fri, 2007-07-13 at 16:18 -0700, Linus Torvalds wrote:
> Why would anybody force you to do that?
> 
> The "switch between branchs in the same repo" is really convenient.
> But nobody *forces* you to do it. 

This is true. I already mirror a bunch of CVS and SVN repositories into
git so that I can use them without too much pain¹, and I can do the same
for git trees which use branches too; mirroring them into a bunch of
separate trees for easy access.

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 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.

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.

But I didn't really mean to start an argument; it's just my opinion.

-- 
dwmw2

¹ and I'd do the same for Hg if I could get hg2git to work.

Re: mtimes of working files

[Linus Torvalds]

On Sat, 14 Jul 2007, David Woodhouse wrote:
> 
> On the occasions I actually try to _use_ branches, I find it very
> suboptimal.

This seems to be very personal.

I tend to use just temporary branches, but I love just going on another 
branch, fixing something up, and working on that without having to set up 
a whole new tree. It's *much* faster to just switch branches than to do 
even a local clone, because I usually would work on something that is 
pretty close to the HEAD anyway, so the cost of rewriting a few hundred 
files is much less than checking out the 22,000 files all over again.

But I literally tend to just use branches for something small. I don't 
personally tend to have any long-term live branches (apart from the remove 
ones, obviously). I create a branch, do something in it, merge it, and 
go back to master.

The last example of this for me was just re-doing a pull by Ingo, because 
he had created some really strange commit in his tree, so I fetched his 
stuff, re-created his branch locally without the thing, and then merged 
it. And then I just deleted the branch.

> But having to rebuild (even with ccache) after changing branches is a 
> PITA.

I don't even use ccache, and I don't care. Probably because most of the 
time the rebuild time really isn't that long for me, and for the kernel, 
the much more painful part is actually the rebooting part.

But the place where branches *really* rock is when you don't even switch 
to them, but use the data from them locally (cherry-picking from them, 
or doing something like "git show origin/pu:builtin-blame.c" etc).

And for that to work, you have to get used to having multiple branches in 
the tree, even if you don't check them out - and once you do that, 
switching between them isn't really that confusing any more, because it's 
already part of your "mind map" of how the repo works.

			Linus

Re: mtimes of working files

[David Woodhouse]

On Fri, 2007-07-13 at 17:10 -0700, Linus Torvalds wrote:
> 
> On Sat, 14 Jul 2007, David Woodhouse wrote:
> > 
> > On the occasions I actually try to _use_ branches, I find it very
> > suboptimal.
> 
> This seems to be very personal.

Yeah, much of it. Although I've also seen other people trying to get to
grips with git and tripping up over branches recently. It _was_ getting
easier, for a while :)

> But I literally tend to just use branches for something small. I don't 
> personally tend to have any long-term live branches (apart from the remove 
> ones, obviously). I create a branch, do something in it, merge it, and 
> go back to master.

I don't usually bother with that. I just do something in HEAD and then
reset (possibly after pushing it to some tree elsewhere for posterity).

> I don't even use ccache, and I don't care. Probably because most of the 
> time the rebuild time really isn't that long for me, and for the kernel, 
> the much more painful part is actually the rebooting part.

I can usually find some other machine to reboot than the machine I'm
working on. Don't these people send you enough toys? :)

I've also spent most of the last year travelling and hence working on my
laptop, which isn't the beefiest build machine I've ever had the
pleasure of using. Changing branches, when I've done it, really has been
a pain.

> But the place where branches *really* rock is when you don't even switch 
> to them, but use the data from them locally (cherry-picking from them, 
> or doing something like "git show origin/pu:builtin-blame.c" etc).

You can achieve much of that just by sharing object directories, and
I'll admit that sometimes I do set up temporary branches just for the
purpose of cherry-picking by name ('foo^^' etc.) without having to paste
sha1sums from the other tree.

> And for that to work, you have to get used to having multiple branches in 
> the tree, even if you don't check them out - and once you do that, 
> switching between them isn't really that confusing any more, because it's 
> already part of your "mind map" of how the repo works.

I'm sure it's true that if I persist I'll get used to it, as will the
newbies who have trouble with branches. But mostly I suspect that I'll
get used to it by learning how best to work around it and keep separate
trees of my own, even when people persist in having multiple branches on
their servers. And while today's set of newbies will get used to it,
tomorrow's set of newbies will also find it troubling.

Nothing really prevents you from using branches _locally_ if you want
to, but still keeping separate trees on the _servers_. I just think that
might be a more cunning way forward. But as you correctly point out,
that's just my personal viewpoint.

-- 
dwmw2

Re: mtimes of working files

[J. Bruce Fields]

On Sat, Jul 14, 2007 at 01:36:33AM +0100, David Woodhouse wrote:
> Yeah, much of it. Although I've also seen other people trying to get to
> grips with git and tripping up over branches recently.

Could you give any details?  What specifically was it they were having
trouble with?

--b.

Re: mtimes of working files

[David Woodhouse]

On Fri, 2007-07-13 at 20:44 -0400, J. Bruce Fields wrote:
> On Sat, Jul 14, 2007 at 01:36:33AM +0100, David Woodhouse wrote:
> > Yeah, much of it. Although I've also seen other people trying to get
> > to grips with git and tripping up over branches recently.
> 
> Could you give any details?  What specifically was it they were having
> trouble with? 

Just conversations on IRC where stuff had to be explained. People not
understanding that they'd actually cloned _multiple_ branches and they
needed to select the one they wanted, making the same kind of stupid
mistakes I did with committing to the wrong place, etc. Nothing specific
stands out as being fixable, certainly.

Branches have their place, and some people seem very happy with them as
part of their local workflow. I just wonder if we have to have them on
the servers too; that's all.

-- 
dwmw2

Re: mtimes of working files

[Jakub Narebski]

David Woodhouse wrote:

> Branches have their place, and some people seem very happy with them as
> part of their local workflow. I just wonder if we have to have them on
> the servers too; that's all.
 
Multiple branches in one [public] repository help sharing data. While you
can do similar with sharing object database (via alternates mechanism)
the second solution has drawbacks the multiple branches didn't have.

IIRC multiple branches was not something _planned_ by Linus when creating
git; users requested this feature, and it turned out to be useful.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: mtimes of working files

[Julian Phillips]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2437 bytes --]

On Sat, 14 Jul 2007, David Woodhouse wrote:

> On Fri, 2007-07-13 at 16:18 -0700, Linus Torvalds wrote:
>> Why would anybody force you to do that?
>>
>> The "switch between branchs in the same repo" is really convenient.
>> But nobody *forces* you to do it.
>
> This is true. I already mirror a bunch of CVS and SVN repositories into
> git so that I can use them without too much pain¹, and I can do the same
> for git trees which use branches too; mirroring them into a bunch of
> separate trees for easy access.
>
> 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 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.

You can flatten a multi-branched git repo without mirroring into multiple 
single-branch repos - The ability to pull out branches into separate trees 
from a single repository was what the git-new-workdir script in contrib 
was written for.

While I find branches quite a natural concept having used the for the past 
few years in Subversion and CVS before that (and after that branches in 
git are a delight to use), I still like to have access to all of the 
branches that I am working on as separate trees.

git-new-workdir allowed me to do that by scripting an approach described 
by Junio.  Though maybe it has been superseeded by some built-in feature? 
I haven't been following things that closely recently, and ISTR that there 
was talk of a feature that would make the script obsolete.

-- 
Julian

  ---
You're at Witt's End.

Re: mtimes of working files

[Robin Rosenberg]

lördag 14 juli 2007 skrev David Woodhouse:
> On Fri, 2007-07-13 at 20:44 -0400, J. Bruce Fields wrote:
> > On Sat, Jul 14, 2007 at 01:36:33AM +0100, David Woodhouse wrote:
> > > Yeah, much of it. Although I've also seen other people trying to get
> > > to grips with git and tripping up over branches recently.
> > 
> > Could you give any details?  What specifically was it they were having
> > trouble with? 
> 
> Just conversations on IRC where stuff had to be explained. People not
> understanding that they'd actually cloned _multiple_ branches and they
> needed to select the one they wanted, making the same kind of stupid
> mistakes I did with committing to the wrong place, etc. Nothing specific
> stands out as being fixable, certainly.

That's why there are scripts that modify the bash prompt to show the current branch.
I made one for stacked git (it works with plain git too). The git completion scripts have 
something also I think

It helps a lot for those of us with bad memory implants.

> Branches have their place, and some people seem very happy with them as
> part of their local workflow. I just wonder if we have to have them on
> the servers too; that's all.

Branches are bad if you don't need them as is any feature you don't need is bad, it is
just that many people need branches. Branches are a pain to manage with many SCM
tools, except git, which solves most of the problems with branches.

-- robin

Re: mtimes of working files

[Jan Hudec]

[-- 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 --]

Re: mtimes of working files

[Julian Phillips]

On Sun, 15 Jul 2007, Jan Hudec wrote:

> 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.

You basically just described what the git-new-workdir script in 
contrib/workdir does ... it doesn't address the issue of reference 
updating.

-- 
Julian

  ---
Most people's favorite way to end a game is by winning.

Re: mtimes of working files

[Daniel Barkalow]

On Sat, 14 Jul 2007, Julian Phillips wrote:

> On Sun, 15 Jul 2007, Jan Hudec wrote:
> 
> > 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.
> 
> You basically just described what the git-new-workdir script in
> contrib/workdir does ... it doesn't address the issue of reference updating.

That's where keeping the index's parents in the index would help. Various 
people have implemented it at various times, but it's never quite become 
sufficiently important to people to have the correct behavior worked out 
and put into mainline. IIRC, not too long ago Junio had an implementation 
in pu, but ended up dropping it because almost nobody would see a difference, 
and the people who did see a difference only had it interfere with what 
they were trying to do.

	-Daniel
*This .sig left intentionally blank*