Git checkout preserve timestamp?

Git checkout preserve timestamp?

[Bill Lear]

I often find myself in branch A, with everything checked in and
compiled, wanting to look at something on branch B.  I hop to branch
B, look, and come back to branch A.  Unfortunately, when I then do a
make, files that differed between A and B will be recompiled, as well as
any further dependencies.

I wonder if it would be possible or desirable to have a config flag
that told git to restore the timestamps across branch checkouts in
order to prevent this perturbation.

So, when git does a checkout of a branch, it would look to see which
files in the current branch are changed, tuck away the timestamps for
those, and switch to the new branch.  On return to the former, the
same would be done for the new branch, then after the changed files
were restored, the timestamps would be reset.

One thing this would enable is to be able to hold the compilation
products of multiple branches at the same time in the same working
tree, switch back and forth between branches, and only have to compile
code that you actually modify.  Currently, we store compilation
products in a directory that is composed of the architecture, compiler,
compiler options, and so forth, among which also could be the branch
name.

Anyway, just an idea I thought worth batting about.


Bill

Re: Git checkout preserve timestamp?

[Alex Riesen]

On 3/1/07, Bill Lear <rael@zopyra.com> wrote:
> I wonder if it would be possible or desirable to have a config flag
> that told git to restore the timestamps across branch checkouts in
> order to prevent this perturbation.

Almost every SCM has such a flag. And every one of them warn
against using it.

> So, when git does a checkout of a branch, it would look to see which
> files in the current branch are changed, tuck away the timestamps for
> those, and switch to the new branch.  On return to the former, the
> same would be done for the new branch, then after the changed files
> were restored, the timestamps would be reset.

For instance, timestamp of which machine do you want to restore?
How do you know if they are synchronized?

> One thing this would enable is to be able to hold the compilation
> products of multiple branches at the same time in the same working
> tree, switch back and forth between branches, and only have to compile
> code that you actually modify.  Currently, we store compilation
> products in a directory that is composed of the architecture, compiler,
> compiler options, and so forth, among which also could be the branch
> name.

Usually, you will just screw up the build process beyond all repair.

> Anyway, just an idea I thought worth batting about.

Consider separating build and working repositories.
Merge things into build repo, switch the branches
freely in your working repo. Works just fine for me.

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

Hi Bill,

On Thu, 1 Mar 2007, Bill Lear wrote:

> I often find myself in branch A, with everything checked in and 
> compiled, wanting to look at something on branch B.

I did that, too, until git-show learnt about the nice ":" syntax.

For example, if I want to know what is in branch B, I do

	$ git show B:

which shows the root directory of the revision "B" (this is in line with 
<commit>:<pathspec> if you interpret "" as the root path). The subtrees 
are all identified by trailing slashes. Then you can say

	$ git show B:Documentation/Makefile

If you want to know the differences to the file "doc/GNUMakefile" in your 
current working tree, do

	$ git diff B:Documentation/Makefile -- doc/GNUMakefile

No need to switch branches.

And if you _do_ need to switch branches, why not make a local clone, 
sharing the object database:

	$ git clone -l -s . test-directory

This is _very_ fast, since it basically checks out the branches in 
test-directory/. Right now, you have to go to the test-directory, and 
switch the branches manually (I think), but talk has been that you may be 
able to tell git-clone which branch you really want.

Hth,
Dscho

Re: Git checkout preserve timestamp?

[Linus Torvalds]

On Thu, 1 Mar 2007, Bill Lear wrote:
>
> I often find myself in branch A, with everything checked in and
> compiled, wanting to look at something on branch B.  I hop to branch
> B, look, and come back to branch A.  Unfortunately, when I then do a
> make, files that differed between A and B will be recompiled, as well as
> any further dependencies.
> 
> I wonder if it would be possible or desirable to have a config flag
> that told git to restore the timestamps across branch checkouts in
> order to prevent this perturbation.

I think you're much better off just using multiple repositories instead, 
if this is something common.

Messing with timestamps is not going to work in general. It's just going 
to guarantee you that "make" gets confused in a really bad way, and does 
not recompile *enough* instead of recompiling *too much*.

Git does make it possible to do your "check the other branch out" thing  
very easily, in many different ways.

You could create some trivial script that does any of the following 
(ranging from the trivial to the more exotic):

 - just create a new repo:

	git clone old new
	cd new
	git checkout origin/<branch>

   and there you are. The old timestamps are fine in your old repo, and 
   you can work (and compile) in the new one, without affectign the old 
   one at all.

   Use the flags "-n -l -s" to "git clone" to basically make this 
   instantaneous. For lots of files (eg big repos like the kernel), it's 
   not going to be as fast as just switching branches, but havign a second 
   copy of the working tree can be quite powerful.

 - do the same thing with just a tar-ball instead, if you want to

	git archive --format=tar --prefix=new-tree/ <branchname> |
		(cd .. ; tar xvf -)

   which is really quite fast, if you just want a snapshot.

 - get used to "git show", and just look at individual files.

   This is actually *really* useful at times. You just do

	git show otherbranch:filename

   in one xterm window, and look at the same file in your current branch 
   in another window. In particular, this should be trivial to do with 
   scriptable editors (ie GNU emacs), where it should be possible to 
   basically have a whole "dired mode" for other branches within the 
   editor, using this. For all I know, the emacs git mode already offers 
   something like this (I'm not an emacs user)

 - and in the extreme example of that "virtual directory" thing, there was 
   at least somebody working on a git plugin for FUSE, ie you could 
   literally just have virtual directories showing *all* your branches.

and I'm sure any of the above are better alternatives than playing games 
with file timestamps.

		Linus

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

Hi,

On Thu, 1 Mar 2007, Linus Torvalds wrote:

>  - and in the extreme example of that "virtual directory" thing, there 
>    was at least somebody working on a git plugin for FUSE, ie you could
>    literally just have virtual directories showing *all* your branches.

You mean http://www.sfgoth.com/~mitch/linux/gitfs/? Funny, it came up on 
IRC a few days ago. gitster said he'd issue "mkdir" instead of "git 
checkout -b" by mistake somtimes...

Ciao,
Dscho

Re: Git checkout preserve timestamp?

[Karl Hasselström]

On 2007-03-01 15:36:25 -0600, Bill Lear wrote:

> I often find myself in branch A, with everything checked in and
> compiled, wanting to look at something on branch B. I hop to branch
> B, look, and come back to branch A. Unfortunately, when I then do a
> make, files that differed between A and B will be recompiled, as
> well as any further dependencies.

Like others have already recommended, I usually just use separate
repositories to work around this problem. Of course, the proper fix is
to use a make-like tool that uses content hashes as well as timestamps
to decide if a file has been updated ...

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Git checkout preserve timestamp?

[Bill Lear]

On Friday, March 2, 2007 at 10:14:26 (+0100) Karl Hasselström writes:
>                                     .... Of course, the proper fix is
>to use a make-like tool that uses content hashes as well as timestamps
>to decide if a file has been updated ...

I like this idea...


Bill

Re: Git checkout preserve timestamp?

[Bart Trojanowski]

* Bill Lear <rael@zopyra.com> [070302 08:28]:
> On Friday, March 2, 2007 at 10:14:26 (+0100) Karl Hasselström writes:
> >                                     .... Of course, the proper fix is
> >to use a make-like tool that uses content hashes as well as timestamps
> >to decide if a file has been updated ...
> 
> I like this idea...

If the content is C, you can use ccache.  Which is pretty close to the
"proper fix".

-Bart

-- 
				WebSig: http://www.jukie.net/~bart/sig/

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

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

Hi,

On Fri, 2 Mar 2007, Bill Lear wrote:

> On Friday, March 2, 2007 at 10:14:26 (+0100) Karl Hasselström writes:
> >                                     .... Of course, the proper fix is
> >to use a make-like tool that uses content hashes as well as timestamps
> >to decide if a file has been updated ...
> 
> I like this idea...

I don't like it at all. The proper fix is to _not_ change the contents of 
the current working directory, if you don't want to change them to begin 
with.

Ciao,
Dscho

Re: Git checkout preserve timestamp?

[Karl Hasselström]

On 2007-03-02 16:18:41 +0100, Johannes Schindelin wrote:

> On Fri, 2 Mar 2007, Bill Lear wrote:
>
> > On Friday, March 2, 2007 at 10:14:26 (+0100) Karl Hasselström
> > writes:
>
> > > Of course, the proper fix is to use a make-like tool that uses
> > > content hashes as well as timestamps to decide if a file has
> > > been updated ...
> >
> > I like this idea...
>
> I don't like it at all. The proper fix is to _not_ change the
> contents of the current working directory, if you don't want to
> change them to begin with.

Well, in a sense, yes. Not overwriting the current state when all you
want to do is peek at some other state is obviously the better fix of
the two.

However, given that your file timestamps have been bumped (without
file content changes), it's a performance bug in your make tool if
this causes it to needlessly rebuild half the known universe. (Fixing
the bug by using content hashes to detect changes may or may not be a
good trade-off, depending on your workflow.)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

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

Hi,

On Fri, 2 Mar 2007, Karl Hasselström wrote:

> However, given that your file timestamps have been bumped (without file 
> content changes),

There were changes. Only that they have been taken back, but that is 
_another_ change.

> it's a performance bug in your make tool if this causes it to needlessly 
> rebuild half the known universe. (Fixing the bug by using content hashes 
> to detect changes may or may not be a good trade-off, depending on your 
> workflow.)

Getting dependencies right is sometimes not very easy. I participate in 
projects which have _seriously_ broken dependencies. In these cases, I do 
a quick "touch source.c" to force a recompilation.

You'd break this workaround.

Ciao,
Dscho

P.S.: yes, I know I could possibly find the object file and remove that, 
too. But finding the source is often easier.

Re: Git checkout preserve timestamp?

[Karl Hasselström]

On 2007-03-02 20:21:17 +0100, Johannes Schindelin wrote:

> On Fri, 2 Mar 2007, Karl Hasselström wrote:
>
> > However, given that your file timestamps have been bumped (without
> > file content changes),
>
> There were changes. Only that they have been taken back, but that is
> _another_ change.

Since the content is exactly the same as before, I'd be of the strong
opinion that nothing has changed as far as the make system should be
concerned. But this is getting off-topic, so I'll just agree to
disagree if you do. :-)

> > it's a performance bug in your make tool if this causes it to
> > needlessly rebuild half the known universe. (Fixing the bug by
> > using content hashes to detect changes may or may not be a good
> > trade-off, depending on your workflow.)
>
> Getting dependencies right is sometimes not very easy. I participate
> in projects which have _seriously_ broken dependencies. In these
> cases, I do a quick "touch source.c" to force a recompilation.
>
> You'd break this workaround.
>
> P.S.: yes, I know I could possibly find the object file and remove
> that, too. But finding the source is often easier.

Well, all you'd need is a way to tell the make system to flush its
caches for source.c (or some larger portion of the build, as
necessary). Such as "make-tool --flush-cache source.c".

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

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

Hi,

On Mon, 5 Mar 2007, Karl Hasselström wrote:

> On 2007-03-02 20:21:17 +0100, Johannes Schindelin wrote:
> 
> > On Fri, 2 Mar 2007, Karl Hasselström wrote:
> >
> > > However, given that your file timestamps have been bumped (without
> > > file content changes),
> >
> > There were changes. Only that they have been taken back, but that is
> > _another_ change.
> 
> Since the content is exactly the same as before, I'd be of the strong
> opinion that nothing has changed as far as the make system should be
> concerned.

You are missing an important point here: there _was_ a change.

Ciao,
Dscho

Re: Git checkout preserve timestamp?

[Karl Hasselström]

On 2007-03-05 12:32:07 +0100, Johannes Schindelin wrote:

> On Mon, 5 Mar 2007, Karl Hasselström wrote:
>
> > Since the content is exactly the same as before, I'd be of the
> > strong opinion that nothing has changed as far as the make system
> > should be concerned.
>
> You are missing an important point here: there _was_ a change.

But I don't want my make tool to care! I want it to rebuild if and
only if the file contents now are different from the file contents as
of the last rebuild.

Just like if I change a git-tracked file, then change it back, git
will _not_ claim that the file has changed; it will compute its sha1,
see that it is identical to what's in HEAD, and from there on consider
that file not changed even thogh its timestamp was changed.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Git checkout preserve timestamp?

[Bill Lear]

On Monday, March 5, 2007 at 12:32:07 (+0100) Johannes Schindelin writes:
>Hi,
>
>On Mon, 5 Mar 2007, Karl Hasselström wrote:
>
>> On 2007-03-02 20:21:17 +0100, Johannes Schindelin wrote:
>> 
>> > On Fri, 2 Mar 2007, Karl Hasselström wrote:
>> >
>> > > However, given that your file timestamps have been bumped (without
>> > > file content changes),
>> >
>> > There were changes. Only that they have been taken back, but that is
>> > _another_ change.
>> 
>> Since the content is exactly the same as before, I'd be of the strong
>> opinion that nothing has changed as far as the make system should be
>> concerned.
>
>You are missing an important point here: there _was_ a change.

Physically, yes, the bits were changed, but logically nothing has
changed, at least in the scenario I outlined.


Bill

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

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

Hi,

On Mon, 5 Mar 2007, Bill Lear wrote:

> On Monday, March 5, 2007 at 12:32:07 (+0100) Johannes Schindelin writes:
>
> >On Mon, 5 Mar 2007, Karl Hasselström wrote:
> >
> >> On 2007-03-02 20:21:17 +0100, Johannes Schindelin wrote:
> >> 
> >> > On Fri, 2 Mar 2007, Karl Hasselström wrote:
> >> >
> >> > > However, given that your file timestamps have been bumped (without
> >> > > file content changes),
> >> >
> >> > There were changes. Only that they have been taken back, but that is
> >> > _another_ change.
> >> 
> >> Since the content is exactly the same as before, I'd be of the strong
> >> opinion that nothing has changed as far as the make system should be
> >> concerned.
> >
> >You are missing an important point here: there _was_ a change.
> 
> Physically, yes, the bits were changed,

Yeah, I know people, who would like to change laws of physics, too.

> but logically nothing has changed, at least in the scenario I outlined.

But it could! Even in the scenario you outlined. If somebody (might be 
even you yourself) pushes into your repo, under the name of the branch to 
which you switch back to right after that. Bingo. Files changed.

See? That is what happens if you don't fix things the right way, you keep 
getting problems. Yes, you can solve them in another tacky way, but you'll 
only get different problems, then.

Ciao,
Dscho

Re: Git checkout preserve timestamp?

[Bill Lear]

On Monday, March 5, 2007 at 20:16:35 (+0100) Johannes Schindelin writes:
>Hi,
>
>On Mon, 5 Mar 2007, Bill Lear wrote:
>
>> On Monday, March 5, 2007 at 12:32:07 (+0100) Johannes Schindelin writes:
>>
>> >On Mon, 5 Mar 2007, Karl Hasselström wrote:
>> >
>> >> On 2007-03-02 20:21:17 +0100, Johannes Schindelin wrote:
>> >> 
>> >> > On Fri, 2 Mar 2007, Karl Hasselström wrote:
>> >> >
>> >> > > However, given that your file timestamps have been bumped (without
>> >> > > file content changes),
>> >> >
>> >> > There were changes. Only that they have been taken back, but that is
>> >> > _another_ change.
>> >> 
>> >> Since the content is exactly the same as before, I'd be of the strong
>> >> opinion that nothing has changed as far as the make system should be
>> >> concerned.
>> >
>> >You are missing an important point here: there _was_ a change.
>> 
>> Physically, yes, the bits were changed,
>
>Yeah, I know people, who would like to change laws of physics, too.
>
>> but logically nothing has changed, at least in the scenario I outlined.
>
>But it could! Even in the scenario you outlined. If somebody (might be 
>even you yourself) pushes into your repo, under the name of the branch to 
>which you switch back to right after that. Bingo. Files changed.

Yes, they change, and so would the timestamp.  So what?

>See? That is what happens if you don't fix things the right way, you keep 
>getting problems. Yes, you can solve them in another tacky way, but you'll 
>only get different problems, then.

I never said git was "broken".  I describe a usage scenario I would
personally find useful.


Bill

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

Hi,

On Mon, 5 Mar 2007, Bill Lear wrote:

> On Monday, March 5, 2007 at 20:16:35 (+0100) Johannes Schindelin writes:
>
> >If somebody (might be even you yourself) pushes into your repo, under 
> >the name of the branch to which you switch back to right after that. 
> >Bingo. Files changed.
> 
> Yes, they change, and so would the timestamp.  So what?

Think about it. Why would the timestamp change? Because Git wrote the 
file? But that was exactly the behaviour you were complaining about.

Ciao,
Dscho

Re: Git checkout preserve timestamp?

[Bill Lear]

On Monday, March 5, 2007 at 21:44:26 (+0100) Johannes Schindelin writes:
>Hi,
>
>On Mon, 5 Mar 2007, Bill Lear wrote:
>
>> On Monday, March 5, 2007 at 20:16:35 (+0100) Johannes Schindelin writes:
>>
>> >If somebody (might be even you yourself) pushes into your repo, under 
>> >the name of the branch to which you switch back to right after that. 
>> >Bingo. Files changed.
>> 
>> Yes, they change, and so would the timestamp.  So what?
>
>Think about it. Why would the timestamp change? Because Git wrote the 
>file? But that was exactly the behaviour you were complaining about.

Not because git wrote the file, but because git notices that content
changes, and writes the file (and timestamps it) "smartly".  If
someone writes into the repo, the timestamp stored becomes invalidated
and the write of the file just creates the timestamp at the time of
the checkout.  If no write into the repo index occurs, the stored
timestamp is applied after the file is checked out.


Bill

Re: Git checkout preserve timestamp?

[Linus Torvalds]

On Mon, 5 Mar 2007, Bill Lear wrote:
> 
> Not because git wrote the file, but because git notices that content
> changes, and writes the file (and timestamps it) "smartly".  If
> someone writes into the repo, the timestamp stored becomes invalidated
> and the write of the file just creates the timestamp at the time of
> the checkout.  If no write into the repo index occurs, the stored
> timestamp is applied after the file is checked out.

But Bill, don't you realize that restoring the timestamp is *WRONG*?

There's no way that git can know whether you did a "make" in between 
switching back and forth between branches. That's true on a very 
fundamental level, but it's doubly true when anybody uses a separate 
object directory (which doesn't leave any information *at*all* in the 
source tree about the fact that somebody did a "make").

So stop even asking for this. We'd have to be totally and utterly 
incompetent to do what you ask for. We're simply not that stupid. 

We already pointed out how you can do what you want to do *other* ways 
that are *not* idiotic and incompetent. I don't think you even answered.

			Linus

Re: Git checkout preserve timestamp?

[Matthieu Moy]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> We already pointed out how you can do what you want to do *other* ways 
> that are *not* idiotic and incompetent. I don't think you even answered.

In particular, "ccache" which has precisely been designed for this
kind of situation, cited above.

-- 
Matthieu

Re: Git checkout preserve timestamp?

[Bill Lear]

On Monday, March 5, 2007 at 13:50:45 (-0800) Linus Torvalds writes:
>On Mon, 5 Mar 2007, Bill Lear wrote:
>> 
>> Not because git wrote the file, but because git notices that content
>> changes, and writes the file (and timestamps it) "smartly".  If
>> someone writes into the repo, the timestamp stored becomes invalidated
>> and the write of the file just creates the timestamp at the time of
>> the checkout.  If no write into the repo index occurs, the stored
>> timestamp is applied after the file is checked out.
>
>But Bill, don't you realize that restoring the timestamp is *WRONG*?

Maybe, maybe not.  Each argument I've seen doesn't convince me.  Sure,
it may be MESSY.  It may be UGLY, and therefore undesirable, but I
don't think any of the arguments have conclusively shown that it
is WRONG or INFEASIBLE in any way.

>There's no way that git can know whether you did a "make" in between 
>switching back and forth between branches. ...

Why should I care whether git knows this?  I never said it should.  As
I said, if I have make products in separate, per-branch directories (a
minor extension to my current make system), I don't see how this would
be confusing in the least.  Git should only care if the content of the
file in the index changes.  It shouldn't care in the least about my
make products.

>                                      .... That's true on a very 
>fundamental level, but it's doubly true when anybody uses a separate 
>object directory (which doesn't leave any information *at*all* in the 
>source tree about the fact that somebody did a "make").

Here's the flow.  Perhaps I'm fundamentally confused, and I'll be
the first to admit that is true in plenty of ways:

I edit sourcefile.c, compile it, then commit it with
N=timestamp(sourcefile.c) on master.  N is <
timestamp(.master/sourcefile.o).  I then switch to branchX.  N is
stored by git for master:sourcefile.c.  No stored timestamp are on
this branch, so the file gets the timestamp it gets on checkout
M=timestamp(sourcefile.c).  I compile the file again, all is well.  I
move back to master branch.  Git stores M as branchX:sourcefile.c Git
checks out the file, and stamps it with N.  I do a make.  No
recompilation happens.  I switch back to branchX, the file is checked
out and stamped with timestamp M.  I do a make.  No recompilation
happens.  Happy happy, joy joy.  If someone pushes into my repo,
as Johannes suggested (how that would work, being a non-bare
repo, is beyond me, but whatever), the timestamp for that file
on that branch would be invalidated, and the file would get
whatever timestamp it got when it was written to disk.

Now, all of this may be DISTASTEFUL, UGLY, POOR DESIGN, etc., but I
don't see how it is WRONG.  As someone who has professed the motto
"actually useful is a lot better than clean, but not as useful",
I fail to see what has gotten you so exercised about this.

>So stop even asking for this. We'd have to be totally and utterly 
>incompetent to do what you ask for. We're simply not that stupid. 
>
>We already pointed out how you can do what you want to do *other* ways 
>that are *not* idiotic and incompetent. I don't think you even answered.

I am not asking for this, I'm just arguing the point, waiting for a
convincing argument rather than having someone call me "idiotic and
incompetent" and "stupid" for asking for it in the first place and
carrying on in the spirit of discovery and open learning.

For your information, I did in fact answer, politely, thanking the
poster for pointing our hash-based "stamps" that could do this sort of
thing.  I downloaded the software pointed to and tried it out,
unsuccessfully, as it will require redoing our make system (not
that I'm opposed to that, just that it will take time).

So ... thanks.


Bill

Re: Git checkout preserve timestamp?

[Linus Torvalds]

On Mon, 5 Mar 2007, Bill Lear wrote:
>
> Maybe, maybe not.  Each argument I've seen doesn't convince me.  Sure,
> it may be MESSY.  It may be UGLY, and therefore undesirable, but I
> don't think any of the arguments have conclusively shown that it
> is WRONG or INFEASIBLE in any way.

I'm sorry. If you don't see how it's WRONG to seta datestamp back to 
something that will make a simple "make" *miscompile* your source tree, I 
don't know what defintiion of "wrong" you are talking about.

It's WRONG. 

It's STUPID.

And it's totally INFEASIBLE to implement.

> Why should I care whether git knows this?  I never said it should.  As
> I said, if I have make products in separate, per-branch directories (a
> minor extension to my current make system), I don't see how this would
> be confusing in the least.  Git should only care if the content of the
> file in the index changes.  It shouldn't care in the least about my
> make products.

But Bill, the content in the index *does* change. It's that simple. It 
changes every time you check out another branch. And if it doesn't change, 
git already avoids changing mtime (because git already avoids changing the 
file).

> Here's the flow.  Perhaps I'm fundamentally confused, and I'll be
> the first to admit that is true in plenty of ways:
> 
> I edit sourcefile.c, compile it, then commit it with
> N=timestamp(sourcefile.c) on master.  N is <
> timestamp(.master/sourcefile.o).  I then switch to branchX.  N is
> stored by git for master:sourcefile.c.  No stored timestamp are on
> this branch, so the file gets the timestamp it gets on checkout
> M=timestamp(sourcefile.c).  I compile the file again, all is well.  I
> move back to master branch.  Git stores M as branchX:sourcefile.c Git
> checks out the file, and stamps it with N.  I do a make.  No
> recompilation happens.

WHICH IS WRONG! You need to recompile, since the compile you did on the 
other branch DOES NOT MATCH in "sourcefile.c" any more. 

And if sourcefile.c _does_ match in the two branches, then git *already* 
won't have changed it at all, so git already does the obvious 
optimization.

The thing is, "ccache" actually does this right. You could arguably 
integrate ccache with more git integration, and let ccache just use the 
SHA1's that git already caches and knows about. But the real issue is that 
what _you_ suggest is crazy. It doesn't work.

		Linus

Re: Git checkout preserve timestamp?

[Bill Lear]

On Monday, March 5, 2007 at 14:37:15 (-0800) Linus Torvalds writes:
>On Mon, 5 Mar 2007, Bill Lear wrote:
>> I edit sourcefile.c, compile it, then commit it with
>> N=timestamp(sourcefile.c) on master.  N is <
>> timestamp(.master/sourcefile.o).  I then switch to branchX.  N is
>> stored by git for master:sourcefile.c.  No stored timestamp are on
>> this branch, so the file gets the timestamp it gets on checkout
>> M=timestamp(sourcefile.c).  I compile the file again, all is well.  I
>> move back to master branch.  Git stores M as branchX:sourcefile.c Git
>> checks out the file, and stamps it with N.  I do a make.  No
>> recompilation happens.
>
>WHICH IS WRONG! You need to recompile, since the compile you did on the 
>other branch DOES NOT MATCH in "sourcefile.c" any more. 

Well, I'll let it drop after this, but I think you're wrong.  I do NOT
need it to recompile when I do the third make above.  The time stamps
match up perfectly with the make products, the make system is NOT
confused, the appropriate rebuilds occurs WHEN I want them to, and my
make products are thereafter a model of wholesome sanity and blissful
unity.

Again, this may be violating a sacred rule of "thou shalt not f~ck
with timestamps", but I'm not religious on that point.

I share the desire of never getting make products when I should not,
and appreciate the desire to never, ever, NOT recompile something when
it must, which is what the above example does.  I also understand
there are better ways than having git do this with timestamps, it's
just that I'm not understanding your logical argument, even with all
caps emphasizing your points.  Perhaps I'll build a prototype, have it
blow up in my face, and then understand ...

>And if sourcefile.c _does_ match in the two branches, then git *already* 
>won't have changed it at all, so git already does the obvious 
>optimization.

I'll let this drop.  It appears we are not communicating, which you
seem to be translating and signaling (in all caps, no less) as "you
are stupid".  That's ok, I've felt that way about others from time to
time, so I understand and sympathize with your frustration.

I do thank you (all) for pointing out the much less invasive
alternatives, using git (right now) and still, despite this rather
heated exchange, think git is a very cool and thoughtfully put
together collection of software.


Bill

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

Hi,

On Mon, 5 Mar 2007, Bill Lear wrote:

> On Monday, March 5, 2007 at 14:37:15 (-0800) Linus Torvalds writes:
> >On Mon, 5 Mar 2007, Bill Lear wrote:
> >> I edit sourcefile.c, compile it, then commit it with
> >> N=timestamp(sourcefile.c) on master.  N is <
> >> timestamp(.master/sourcefile.o).  I then switch to branchX.  N is
> >> stored by git for master:sourcefile.c.  No stored timestamp are on
> >> this branch, so the file gets the timestamp it gets on checkout
> >> M=timestamp(sourcefile.c).  I compile the file again, all is well.  I
> >> move back to master branch.  Git stores M as branchX:sourcefile.c Git
> >> checks out the file, and stamps it with N.  I do a make.  No
> >> recompilation happens.
> >
> >WHICH IS WRONG! You need to recompile, since the compile you did on the 
> >other branch DOES NOT MATCH in "sourcefile.c" any more. 
> 
> Well, I'll let it drop after this, but I think you're wrong.  I do NOT
> need it to recompile when I do the third make above.

Bill, maybe you don't want to hear it, but for all those following this 
thread, here is why you are wrong:

"make" does _not_ match the time stamps of xyz.c and xyz.o. After you 
"make", the only thing which is guaranteed is that if xyz.c is _newer_ 
than xyz.o, the compiler is started.

Example:

00:05 you pull upstream into your master branch, which has a newer xzy.c
00:07 you type make. xyz.o is built, because make sees that xyz.c is 
      newer than xyz.o
00:12 you checkout your side branch, xyz.c is updated.
00:13 you type make, and again xzy.o is built, because xyz.c is newer than 
      xyz.o
00:25 you switch back to your master branch.

Now, if your wish would be granted, and xyz.c has the same timestamp as 
before, then it _still_ is older than xyz.o. So make will not rebuild it.

BUT xyz.o is actually compiled from the side branch's version of xyz.c!

Hth,
Dscho

Re: Git checkout preserve timestamp?

[Bill Lear]

On Tuesday, March 6, 2007 at 00:32:28 (+0100) Johannes Schindelin writes:
>...
>Bill, maybe you don't want to hear it, but for all those following this 
>thread, here is why you are wrong:

An actual demonstration of my stupidity is much, much preferable
to a mere assertion of it, so I read the following with relish.

>"make" does _not_ match the time stamps of xyz.c and xyz.o. After you 
>"make", the only thing which is guaranteed is that if xyz.c is _newer_ 
>than xyz.o, the compiler is started.
>
>Example:
>
>00:05 you pull upstream into your master branch, which has a newer xzy.c
>00:07 you type make. xyz.o is built, because make sees that xyz.c is 
>      newer than xyz.o
>00:12 you checkout your side branch, xyz.c is updated.
>00:13 you type make, and again xzy.o is built, because xyz.c is newer than 
>      xyz.o
>00:25 you switch back to your master branch.
>
>Now, if your wish would be granted, and xyz.c has the same timestamp as 
>before, then it _still_ is older than xyz.o. So make will not rebuild it.
>
>BUT xyz.o is actually compiled from the side branch's version of xyz.c!

No, I think you missed my point.  There are two xyz.o's:

One in .master/xyz.o, and one in .branchX/xyz.o.  So, you're example
becomes:

00:05 you pull upstream into your master branch, which has a newer xzy.c
00:07 you type make. .master/xyz.o is built, because make sees that xyz.c is 
      newer than .master/xyz.o
00:12 you checkout your side branch, xyz.c is updated.
00:13 you type make, and .branchX/xzy.o is built, because xyz.c is newer than 
      .branchX/xyz.o
00:25 you switch back to your master branch.
00:26 you type make, and nothing happens, as it should not.  You are
      happy, and thank the git community for all of their heroic efforts.

Now, I'm really going to go: the family is hungry and I've got
dinner to prepare, so if you want to flame me for opening my mouth
further, feel free.


Bill

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

Hi,

On Mon, 5 Mar 2007, Bill Lear wrote:

> No, I think you missed my point.  There are two xyz.o's:
> 
> One in .master/xyz.o, and one in .branchX/xyz.o.

Why not put the two xyz.c's into .master/ and .branchX/ as well (surely, 
the source files are small compared to the object files)? And just to make 
sure, the Makefile, too (some Makefile targets depend on the timestamp of 
this, too).

And to make sure that if we're switching to a third branch, let's put the 
files there, even when the side branch does not change them, otherwise 
A->B->C->A might fail.

And while at it, we could put the information about which branch this is 
into the corresponding directories, too! Otherwise, we could rename the 
directory by mistake, and the system would stop working.

And the corresponding refs. They could be there, too.

Hth,
Dscho

P.S.: Google for the complicator's gloves.

Re: Git checkout preserve timestamp?

[Michael Poole]

Johannes Schindelin writes:

> Hi,
>
> On Mon, 5 Mar 2007, Bill Lear wrote:
>
>> No, I think you missed my point.  There are two xyz.o's:
>> 
>> One in .master/xyz.o, and one in .branchX/xyz.o.
>
> Why not put the two xyz.c's into .master/ and .branchX/ as well (surely, 
> the source files are small compared to the object files)? And just to make 
> sure, the Makefile, too (some Makefile targets depend on the timestamp of 
> this, too).
>
> And to make sure that if we're switching to a third branch, let's put the 
> files there, even when the side branch does not change them, otherwise 
> A->B->C->A might fail.
>
> And while at it, we could put the information about which branch this is 
> into the corresponding directories, too! Otherwise, we could rename the 
> directory by mistake, and the system would stop working.
>
> And the corresponding refs. They could be there, too.

This all sounds a lot like git-clone's "alternate" code.

Does a repository cloned with the -s or --references flag have some
setting to make fetch and push work with the same remote repositories
as the local origin, or do the remotes have to be manually propagated
between the two local copies?  If I git-fetch in the local clone, does
it write the new objects to the local origin?

My own work habits are very similar to Bill Lear's, but my projects'
build times are small enough that it's less pain to rebuild half the
project than to propagate changes recorded under $GIT_DIR between
local branches.  I have not found a git workflow that makes me
entirely happy, but I suspect I just don't know the magic words.

Michael Poole

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

Hi,

On Mon, 5 Mar 2007, Michael Poole wrote:

> I have not found a git workflow that makes me entirely happy, but I 
> suspect I just don't know the magic words.

So, what do you want to do?

Ciao,
Dscho

Re: Git checkout preserve timestamp?

[Michael Poole]

Johannes Schindelin writes:

> Hi,
>
> On Mon, 5 Mar 2007, Michael Poole wrote:
>
>> I have not found a git workflow that makes me entirely happy, but I 
>> suspect I just don't know the magic words.
>
> So, what do you want to do?

I want to have several local directories -- including build products
and configuration files that are neither build products nor revision
controlled -- that correspond to certain branches of one project.
(Sometimes I have several trees for a single branch, to handle
compile-time alternatives.)  I do not much care whether there is a
separate source tree for each of these or not.

When I switch from working on one branch to another, I do not want
file timestamps to be any later than the corresponding object was
changed in the repository.

When I change configuration options (including which branch(es) go to
which remote(s)), I want to make that change in one $GIT_DIR rather
than in one $GIT_DIR for each branch.

As a lower priority, I would like a fetch on any of the branches to
have results that are visible to all my local copies without more
network traffic.

The first two goals are neatly solved by having several local clones.
The third and fourth are where I get lost.

Michael Poole

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

Hi,

On Mon, 5 Mar 2007, Michael Poole wrote:

> When I change configuration options (including which branch(es) go to 
> which remote(s)), I want to make that change in one $GIT_DIR rather than 
> in one $GIT_DIR for each branch.

This can be solved by symlinking the config to one designated repo (let's 
call it the "master" repo).

> As a lower priority, I would like a fetch on any of the branches to have 
> results that are visible to all my local copies without more network 
> traffic.

I'd just make a small script which I'd run from the "master" repo instead 
of saying "git pull":

-- snip --
git pull || exit
for branch in branch1 branch2 branch3; do
	cd $branch && git pull .. $branch && cd .. || exit
done
-- snap --

This assumes that you have named the side branches "branch1", "branch2" 
and "branch3", and that they are checked out in the subdirectories of the 
same name.

Hth,
Dscho

Re: Git checkout preserve timestamp?

[Junio C Hamano]

Michael Poole <mdpoole@troilus.org> writes:

> This all sounds a lot like git-clone's "alternate" code.
> ...
> My own work habits are very similar to Bill Lear's, but my projects'
> build times are small enough that it's less pain to rebuild half the
> project than to propagate changes recorded under $GIT_DIR between
> local branches.  I have not found a git workflow that makes me
> entirely happy, but I suspect I just don't know the magic words.

These days I use a few working trees that are connected to my
primary repository (which also has a working tree).  The primary
repository is in /src/git, and other ones look like this:

: gitster git.wk0; ls -l .git/
total 120
drwxrwsr-x  3 junio src  4096 Mar  5 16:22 ./
drwxrwsr-x 15 junio src 16384 Mar  5 16:23 ../
-rw-rw-r--  1 junio src    41 Mar  5 16:22 HEAD
lrwxrwxrwx  1 junio src    27 Mar  3 22:53 config -> /src/git/.git/config
lrwxrwxrwx  1 junio src    26 Mar  3 22:53 hooks -> /src/git/.git/hooks/
-rw-rw-r--  1 junio src 82455 Mar  5 16:22 index
lrwxrwxrwx  1 junio src    25 Mar  3 22:53 info -> /src/git/.git/info/
drwxrwsr-x  3 junio src  4096 Mar  3 22:59 logs/
lrwxrwxrwx  1 junio src    28 Mar  3 22:53 objects -> /src/git/.git/objects/
lrwxrwxrwx  1 junio src    32 Mar  3 22:53 packed-refs -> /src/git/.git/packed-refs
lrwxrwxrwx  1 junio src    25 Mar  3 22:53 refs -> /src/git/.git/refs/
lrwxrwxrwx  1 junio src    28 Mar  3 22:53 remotes -> /src/git/.git/remotes/
lrwxrwxrwx  1 junio src    29 Mar  3 22:53 rr-cache -> /src/git/.git/rr-cache/

It shares everything other than HEAD and the index (the reflog
for branches are also shared by a symlink .git/logs/refs
pointing at the one in the primary repository).

This risks confusion for an uninitiated if you update a ref that
is checked out in another working tree, but modulo that caveat
it works reasonably well.

We might want to add an option to 'git-clone' to create
something like this, but I am somewhat worried about the newbie
confusion factor.  Perhaps...

$ git clone --i-know-what-i-am-doing-give-me-an-alternate-working-tree \
  /src/git /src/git.wk0

Re: Git checkout preserve timestamp?

[Sergio Callegari]

Junio C Hamano <junkio <at> cox.net> writes:

> 
> Michael Poole <mdpoole <at> troilus.org> writes:
> 
> > This all sounds a lot like git-clone's "alternate" code.
> > ...
> > My own work habits are very similar to Bill Lear's, but my projects'
> > build times are small enough that it's less pain to rebuild half the
> > project than to propagate changes recorded under $GIT_DIR between
> > local branches.  I have not found a git workflow that makes me
> > entirely happy, but I suspect I just don't know the magic words.
> 
> These days I use a few working trees that are connected to my
> primary repository (which also has a working tree).  The primary
> repository is in /src/git, and other ones look like this:
> 
> : gitster git.wk0; ls -l .git/
> total 120
> drwxrwsr-x  3 junio src  4096 Mar  5 16:22 ./
> drwxrwsr-x 15 junio src 16384 Mar  5 16:23 ../
> -rw-rw-r--  1 junio src    41 Mar  5 16:22 HEAD
> lrwxrwxrwx  1 junio src    27 Mar  3 22:53 config -> /src/git/.git/config
> lrwxrwxrwx  1 junio src    26 Mar  3 22:53 hooks -> /src/git/.git/hooks/
> -rw-rw-r--  1 junio src 82455 Mar  5 16:22 index
> lrwxrwxrwx  1 junio src    25 Mar  3 22:53 info -> /src/git/.git/info/
> drwxrwsr-x  3 junio src  4096 Mar  3 22:59 logs/
> lrwxrwxrwx  1 junio src    28 Mar  3 22:53 objects -> /src/git/.git/objects/
> lrwxrwxrwx  1 junio src    32 Mar  3 22:53 packed-refs ->
/src/git/.git/packed-refs
> lrwxrwxrwx  1 junio src    25 Mar  3 22:53 refs -> /src/git/.git/refs/
> lrwxrwxrwx  1 junio src    28 Mar  3 22:53 remotes -> /src/git/.git/remotes/
> lrwxrwxrwx  1 junio src    29 Mar  3 22:53 rr-cache -> /src/git/.git/rr-cache/
> 
> It shares everything other than HEAD and the index (the reflog
> for branches are also shared by a symlink .git/logs/refs
> pointing at the one in the primary repository).
> 
> This risks confusion for an uninitiated if you update a ref that
> is checked out in another working tree, but modulo that caveat
> it works reasonably well.
> 
> We might want to add an option to 'git-clone' to create
> something like this, but I am somewhat worried about the newbie
> confusion factor.  Perhaps...
> 
> $ git clone --i-know-what-i-am-doing-give-me-an-alternate-working-tree \
>   /src/git /src/git.wk0
> 
> 


This looks very much like the .gitlink approach that was previously proposed on
the list, I think...

In that proposal, rather than having many symlinks in the .git repo, you would
have a single .gitlink one...  (plus, obviously a live index and HEAD). 
Possibly, the .gitlink approach could be better, since in case the *real* repo
needs for some reason to be moved, then you just need to update a single link
rather than many of them (this might also be safer... just imagine a scenario
where one updates the links by hand and forgets to update one of them... and
more friendly to OSes disliking symbolic links).

You mention the fact that the only possible confusion here is if a ref that is
checked out in another working tree gets updated... Something like I update
master on WT A, but another WT B has master checked out, so the status of the WT
in B gets old with regard to the new branch tip... I guess that in this case
committing in WT B could be a disaster...

However, if in HEAD we stored not just the branch-ref, but also its commit ID
this case could become very easy to spot... and we could start behaving as if we
were headless... (possibly safer)... or am I completely wrong?

Sergio

Re: Git checkout preserve timestamp?

[Jakub Narebski]

Junio C Hamano wrote:

> Michael Poole <mdpoole@troilus.org> writes:
> 
>> This all sounds a lot like git-clone's "alternate" code.
>> ...
>> My own work habits are very similar to Bill Lear's, but my projects'
>> build times are small enough that it's less pain to rebuild half the
>> project than to propagate changes recorded under $GIT_DIR between
>> local branches.  I have not found a git workflow that makes me
>> entirely happy, but I suspect I just don't know the magic words.
> 
> These days I use a few working trees that are connected to my
> primary repository (which also has a working tree).  The primary
> repository is in /src/git, and other ones look like this:
> 
> : gitster git.wk0; ls -l .git/
> total 120
> drwxrwsr-x  3 junio src  4096 Mar  5 16:22 ./
> drwxrwsr-x 15 junio src 16384 Mar  5 16:23 ../
> -rw-rw-r--  1 junio src    41 Mar  5 16:22 HEAD
> lrwxrwxrwx  1 junio src    27 Mar  3 22:53 config -> /src/git/.git/config
> lrwxrwxrwx  1 junio src    26 Mar  3 22:53 hooks -> /src/git/.git/hooks/
> -rw-rw-r--  1 junio src 82455 Mar  5 16:22 index
> lrwxrwxrwx  1 junio src    25 Mar  3 22:53 info -> /src/git/.git/info/
> drwxrwsr-x  3 junio src  4096 Mar  3 22:59 logs/
> lrwxrwxrwx  1 junio src    28 Mar  3 22:53 objects -> /src/git/.git/objects/
> lrwxrwxrwx  1 junio src    32 Mar  3 22:53 packed-refs -> /src/git/.git/packed-refs
> lrwxrwxrwx  1 junio src    25 Mar  3 22:53 refs -> /src/git/.git/refs/
> lrwxrwxrwx  1 junio src    28 Mar  3 22:53 remotes -> /src/git/.git/remotes/
> lrwxrwxrwx  1 junio src    29 Mar  3 22:53 rr-cache -> /src/git/.git/rr-cache/

By the way, doing something like this, but not by using lots of symlinks,
but a kind of symref was idea behind Josef Weidendorfer .gitlink idea
(search for '[RFC] Light-weight checkouts via ".gitlink"')

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Git checkout preserve timestamp?

[Bill Lear]

On Tuesday, March 6, 2007 at 00:50:16 (+0100) Johannes Schindelin writes:
>On Mon, 5 Mar 2007, Bill Lear wrote:
>> No, I think you missed my point.  There are two xyz.o's:
>> 
>> One in .master/xyz.o, and one in .branchX/xyz.o.
>
>Why not put the two xyz.c's into .master/ and .branchX/ as well (surely, 
>the source files are small compared to the object files)? And just to make 
>sure ...

So, be resorting to snide sarcasm, I can see you concede my point,
finally.  Thank you.


Bill

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

Hi,

On Mon, 5 Mar 2007, Bill Lear wrote:

> On Tuesday, March 6, 2007 at 00:50:16 (+0100) Johannes Schindelin writes:
> >On Mon, 5 Mar 2007, Bill Lear wrote:
> >> No, I think you missed my point.  There are two xyz.o's:
> >> 
> >> One in .master/xyz.o, and one in .branchX/xyz.o.
> >
> >Why not put the two xyz.c's into .master/ and .branchX/ as well (surely, 
> >the source files are small compared to the object files)? And just to make 
> >sure ...
> 
> So, be resorting to snide sarcasm, I can see you concede my point,
> finally.

If you would have cared to actually read and try to understand my reply 
here:

http://article.gmane.org/gmane.comp.version-control.git/41136
(This was 5 days and a very long thread ago)

you would have seen long ago that I actually see your problem, and want 
the something similar myself. This is what I "concede". Always have. Only 
that I use a sane method to achieve it. And that was my point you 
consistently refused to accept.

Whatever.

> Thank you.

You don't have to thank me, as you clearly chose to ignore my help.

Ciao,
Dscho

Re: Git checkout preserve timestamp?

[Bill Lear]

On Tuesday, March 6, 2007 at 02:34:27 (+0100) Johannes Schindelin writes:
>On Mon, 5 Mar 2007, Bill Lear wrote:
>> On Tuesday, March 6, 2007 at 00:50:16 (+0100) Johannes Schindelin writes:
>> >On Mon, 5 Mar 2007, Bill Lear wrote:
>> >> No, I think you missed my point.  There are two xyz.o's:
>> >> 
>> >> One in .master/xyz.o, and one in .branchX/xyz.o.
>> >
>> >Why not put the two xyz.c's into .master/ and .branchX/ as well (surely, 
>> >the source files are small compared to the object files)? And just to make 
>> >sure ...
>> 
>> So, be resorting to snide sarcasm, I can see you concede my point,
>> finally.
>
>If you would have cared to actually read and try to understand my reply 
>here:

Which I did, your baseless presumption to the contrary
notwithstanding.

>you would have seen long ago that I actually see your problem, and want 
>the something similar myself. This is what I "concede". Always have. Only 
>that I use a sane method to achieve it. And that was my point you 
>consistently refused to accept.
>...
>You don't have to thank me, as you clearly chose to ignore my help.

Your presumption is again false: your point was that my logic was
confused, that the entire dependency scheme I sketched out was
"stupid", and you and another expended considerable effort to show how
stupid this was, which now is clearly wrong --- my explanation and
example wasn't stupid after all.  I was merely trying to convey WHAT I
wanted to have happen, and HOW, logically speaking, it could.  What I
got from you and one other ON THIS PART was that my logic was STUPID,
IDIOTIC, etc., though to their credit, several others merely chimed in
with their opinion and helped the discussion along by presenting
argument, example, and not invective and mere assertion that my
logic was very much beneath contempt.

I saw and appreciated your earlier explanation, and will be trying to
work with it, and those the others suggested.  My guess is that it
will not be as buttery-smooth as I would have hoped, but it will
probably do well enough.

Your petulance and quick temper to dismiss someone as stupid merely
because he pursues a line of discussion that you yourself admittedly
confuse, not to mention your name-calling --- both explicit and veiled
--- really is not helpful, though your suggestions on how to use git
better certainly are, and I do very much appreciate them here, and
elsewhere.


Bill

Re: Git checkout preserve timestamp?

[Martin Langhoff]

On 3/6/07, Bill Lear <rael@zopyra.com> wrote:
> No, I think you missed my point.  There are two xyz.o's:
>
> One in .master/xyz.o, and one in .branchX/xyz.o.  So, you're example
> becomes:

For most users, there are no dedicated branch-specific build
directories. In any situation where there _are_ such
branch/arch/config-option specific builddirs, someone has crafted a
neat multi-<factor> build system.

Now, if you have such a build system, it's trivial to have a separate
checkout for each branch. Trying to push this bit of complexity into
git means that git would have an option that lets most users shoot
themselves in the foot, big time.

So - your ideas are OK, but just do all the trickery and magic for the
super-build-system _in_ the super-build-system. You don't need any GIT
changes, just take advantage of the really fast and lightweight "local
clone".

I guess that's the definition of "WRONG" above. It's wrong and
error-prone for most users, and for the handsome few that could take
advantage of it, there are better ways of doing it.

cheers,


martin

Re: Git checkout preserve timestamp?

[Theodore Tso]

On Mon, Mar 05, 2007 at 05:38:07PM -0600, Bill Lear wrote:
> 
> No, I think you missed my point.  There are two xyz.o's:
> 
> One in .master/xyz.o, and one in .branchX/xyz.o.  So, you're example
> becomes:

Are you assuming that the makefile will automatically figure out which
branch you are on, and then redirect the .o to the right
<.branch-name> directory?  That's the only thing that makes sense,
since if you are using VPATH and depending on the developer being
cd'ed into .master when the current branch is master, and cd'ed into
.branchX when the current branch is branchX, and the developer types
make at when they are in the .master directory but the current branch
is branchX, the result will be a huge, confusing mess.

But of course, the Makefile is under source control itself, and if at
a previous point in time the Makefile didn't have the magic .git
directives, then you could do the build and have the the wrong thing
happen.

So it seems to be a very fragile solution compared to using multiple
working directories, or using ccache.  It could be a tad bit more
efficient than using ccache or multiple directories, but the real
question is whether it really is worth the effort, and potential
support difficulties if some confused user turns on this feature with
the proper git magic in their makefiles, and then the git mailing list
gets the support burden.


That being said, I have often wished that there was some way I could
use all of those autogenerated html and man pages to spead up the
"make doc" process in git.  Ccache doesn't work because it doesn't
understand asciidoc or xmlto, and there are all of these conveniently
generated output files in the origin/man and origin/html, but unless
we are building exactly the same git release as described in the log
message in the origin/man or origin/html branch.  

What would be really cool would be some way of generating some kind of
database that mapped the SHA1 hash of the SHA1 hash of the
dependencies of a particular output file to the SHA1 hash of the glob
of the generated output file as found in origin/man and origin/html.
This would basically be a way of integrating ccache functionality into
git, but for the HTML and man page outputs, which delta compress
nicely and therefore makes a lot of sense to include in a git
repository like Junio is doing already.  I'm not sure how much sense
this would make for storing the .o globs in the git repository
(although there are some SCM's, like Clearcase who do this), but in
theory it could be used for that as well.  The case is much more
compelling with the generated documentation files, though.

					- Ted

Re: Git checkout preserve timestamp?

[Matthieu Moy]

Bill Lear <rael@zopyra.com> writes:

> I move back to master branch. Git stores M as branchX:sourcefile.c
> Git checks out the file, and stamps it with N. I do a make. No
> recompilation happens.

Are you not describing a situation where git would modify a file
("move back to branchX"), and no recompilation happens (whereas it
should)?

-- 
Matthieu

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

Hi,

On Mon, 5 Mar 2007, Bill Lear wrote:

> On Monday, March 5, 2007 at 13:50:45 (-0800) Linus Torvalds writes:
> >On Mon, 5 Mar 2007, Bill Lear wrote:
> >> 
> >> Not because git wrote the file, but because git notices that content
> >> changes, and writes the file (and timestamps it) "smartly".  If
> >> someone writes into the repo, the timestamp stored becomes invalidated
> >> and the write of the file just creates the timestamp at the time of
> >> the checkout.  If no write into the repo index occurs, the stored
> >> timestamp is applied after the file is checked out.
> >
> >But Bill, don't you realize that restoring the timestamp is *WRONG*?
> 
> Maybe, maybe not.  Each argument I've seen doesn't convince me.  Sure,
> it may be MESSY.  It may be UGLY, and therefore undesirable, but I
> don't think any of the arguments have conclusively shown that it
> is WRONG or INFEASIBLE in any way.

It may not be infeasible.

But it is wrong. It "fixes" a totallc clear idiom, namely that every time 
a file is written into, the timestamp changes. And guess what, "touch 
<file>" is the best proof that sometimes, you want that this happens, even 
if the content stays the same.

> If someone pushes into my repo, as Johannes suggested (how that would 
> work, being a non-bare repo, is beyond me, but whatever),

Of course this works. That is a fundamental feature of Git: if you strip a 
non-bare repo of its working directory, then it becomes a bare repo.

> the timestamp for that file on that branch would be invalidated, and the 
> file would get whatever timestamp it got when it was written to disk.

This approach is so fragile! It is invasive, easy to get wrong (count the 
ways how to invalidate the timestamp), and serves only an obscure use 
case, which is better solved otherwise to begin with.

> >So stop even asking for this. We'd have to be totally and utterly 
> >incompetent to do what you ask for. We're simply not that stupid. 

FWIW I have to agree here. I saw quite a few projects go wrong, because 
management insisted on abolishing a perfectly good design, just because 
they had this pet idea.

> >We already pointed out how you can do what you want to do *other* ways 
> >that are *not* idiotic and incompetent. I don't think you even 
> >answered.
> 
> I am not asking for this, I'm just arguing the point, waiting for a
> convincing argument rather than having someone call me "idiotic and
> incompetent" and "stupid" for asking for it in the first place and
> carrying on in the spirit of discovery and open learning.
> 
> For your information, I did in fact answer, politely, thanking the
> poster for pointing our hash-based "stamps" that could do this sort of
> thing.

No. This is not what Linus was referring to (unless I am really wrong 
here, which I refuse to believe).

We pointed out, in several ways, how much easier it is to create a 
throw-away working directory.

It is easy, robust, and can be done _right now_ with Git.

Ciao,
Dscho

Re: Git checkout preserve timestamp?

[Bill Lear]

On Monday, March 5, 2007 at 23:56:02 (+0100) Johannes Schindelin writes:
>...
>It may not be infeasible.
>
>But it is wrong. It "fixes" a totallc clear idiom, ...

A very valid point.  I dislike breaking clear idioms also.

>> the timestamp for that file on that branch would be invalidated, and the 
>> file would get whatever timestamp it got when it was written to disk.
>
>This approach is so fragile! It is invasive, easy to get wrong (count the 
>ways how to invalidate the timestamp), and serves only an obscure use 
>case, which is better solved otherwise to begin with.

More very valid points.

>> >So stop even asking for this. We'd have to be totally and utterly 
>> >incompetent to do what you ask for. We're simply not that stupid. 
>
>FWIW I have to agree here. I saw quite a few projects go wrong, because 
>management insisted on abolishing a perfectly good design, just because 
>they had this pet idea.

This is not my "pet idea".  I could care less about it: I have other
alternatives.  I was just engaging in what I hoped would be a friendly
exchange about this, but it seems to have touched a nerve, and then
invective with unsubtle charges of STUPID was loaded into the
catapult and flung across the sea ...

I loathe politics getting in the way of something clean, robust, and
useful.  I would be the last to advocate it: besides were I really
convinced that git MUST have this or die, I would try to write it
myself --- I was just hoping for an argument showing why it was such a
lame-brained idea from a logical, not implementation, standpoint.

Thanks again for your time.


Bill

Re: Git checkout preserve timestamp?

[Johannes Schindelin]

Hi,

On Mon, 5 Mar 2007, Bill Lear wrote:

> Not because git wrote the file, but because git notices that content
> changes, and writes the file (and timestamps it) "smartly".

You know why you put that in quotes? I know. Because it is not smart to do 
that.

Ciao,
Dscho

Re: Git checkout preserve timestamp?

[Bill Lear]

On Monday, March 5, 2007 at 23:02:04 (+0100) Johannes Schindelin writes:
>On Mon, 5 Mar 2007, Bill Lear wrote:
>> Not because git wrote the file, but because git notices that content
>> changes, and writes the file (and timestamps it) "smartly".
>
>You know why you put that in quotes? I know. Because it is not smart to do 
>that.

The tone on this list is usually pretty civil, and I have benefited a
lot from the discussions here, and greatly appreciate the effort put
in by all concerned, but this sort of tone --- implying that I am
stupid to even query about this --- is really not very helpful, and
quite rude and childish.


Bill

Re: Git checkout preserve timestamp?

[Andy Parkins]

On Friday 2007 March 02 16:21, Karl Hasselström wrote:

> However, given that your file timestamps have been bumped (without
> file content changes), it's a performance bug in your make tool if

Actually, git is as good as it could reasonably get in this regard.

Let's say you did this:

 git checkout branch1
 git checkout branch2
 git checkout branch1

Git will only touch the timestamps of files that are different between the 
branches.  If the same file is in both branches, then that one remains 
untouched in your working tree (it's tricks like this that make git so 
blindingly fast).

The fact that you've changed back from branch2 to branch1 is the bone of 
contention - how is git meant to know that you haven't done a compilation 
while you were on branch2 and hence changed the files that untracked files 
depend on?  The /only/ sane thing it can do is, in both cases, update changed 
files to have the current time.

Perhaps an example would make it clearer:

 git checkout branch1
 # sourcefile.c changes, so git touches the timestamp
 # make would rebuild sourcefile.o
 git checkout branch2
 # sourcefile.c changes, so git touches the timestamp
 # make would rebuild sourcefile.o
 git checkout branch1
 # sourcefile.c changes, so git touches the timestamp
 # make would rebuild sourcefile.o

That's all exactly right, make knows in each case the the ".o" file is out of 
date because it has a timestamp earlier than sourcefile.c

Now take the suggestion that timestamps from the repository version should be 
restored and do the same thing:

 git checkout branch1
 # sourcefile.c changes, git sets the timestamp to $timestamp1
 # make would rebuild sourcefile.o (setting its timestamp to $now)
 git checkout branch2
 # sourcefile.c changes, so sets the timestamp to $timestamp2
 # make wouldn't rebuild sourcefile.o because $timestamp2 < $now
 git checkout branch1
 # sourcefile.c changes, so git sets the timestamp to $timestamp1
 # make wouldn't rebuild sourcefile.o because $timestamp1 < $now

All very wrong; in two out of the three builds, the wrong sourcefile.o ends up 
in the final object.

What git does now is absolutely the right thing.  It keeps unnecessary 
rebuilds to the safest minimum.



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

Re: Git checkout preserve timestamp?

[Karl Hasselström]

On 2007-03-05 12:13:50 +0000, Andy Parkins wrote:

> On Friday 2007 March 02 16:21, Karl Hasselström wrote:
>
> > However, given that your file timestamps have been bumped (without
> > file content changes), it's a performance bug in your make tool if
>
> Actually, git is as good as it could reasonably get in this regard.

I know.

> Let's say you did this:
>
>  git checkout branch1
>  git checkout branch2
>  git checkout branch1
>
> Git will only touch the timestamps of files that are different
> between the branches.

Yes.

> The fact that you've changed back from branch2 to branch1 is the
> bone of contention - how is git meant to know that you haven't done
> a compilation while you were on branch2 and hence changed the files
> that untracked files depend on? The /only/ sane thing it can do is,
> in both cases, update changed files to have the current time.

Yes, that's the only sane thing.

My point isn't that _git_ should know that I haven't compiled stuff.
My point is that my make tool should realize that even though the
file's timestamp has changed since last rebuild, the contents haven't
changed (or, to be precise, they're identical to what they were), and
so there's no need to rebuild.

Now, obviously "make" isn't such a make tool, since it goes only by
timestamps.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Git checkout preserve timestamp?

[Andy Parkins]

On Monday 2007 March 05 12:33, Karl Hasselström wrote:

> Now, obviously "make" isn't such a make tool, since it goes only by
> timestamps.

Perhaps this will help you:

http://kolpackov.net/pipermail/notes/2004-September/000011.html


Andy

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

Re: Git checkout preserve timestamp?

[Karl Hasselström]

On 2007-03-05 13:19:15 +0000, Andy Parkins wrote:

> On Monday 2007 March 05 12:33, Karl Hasselström wrote:
>
> > Now, obviously "make" isn't such a make tool, since it goes only
> > by timestamps.
>
> Perhaps this will help you:
>
> http://kolpackov.net/pipermail/notes/2004-September/000011.html

Thanks for the pointer; I hadn't seen that technique before. But it
isn't really worth it. The make tool going by hash rather than
timestamp is a nice-to-have, not a must-have (for those projects I've
been involved in anyway), so the cost of the solution proposed in that
message is too high.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Git checkout preserve timestamp?

[Bill Lear]

On Monday, March 5, 2007 at 12:13:50 (+0000) Andy Parkins writes:
>...
>Now take the suggestion that timestamps from the repository version should be 
>restored and do the same thing:
>
> git checkout branch1
> # sourcefile.c changes, git sets the timestamp to $timestamp1
> # make would rebuild sourcefile.o (setting its timestamp to $now)
> git checkout branch2
> # sourcefile.c changes, so sets the timestamp to $timestamp2
> # make wouldn't rebuild sourcefile.o because $timestamp2 < $now
> git checkout branch1
> # sourcefile.c changes, so git sets the timestamp to $timestamp1
> # make wouldn't rebuild sourcefile.o because $timestamp1 < $now
>
>All very wrong; in two out of the three builds, the wrong
>sourcefile.o ends up in the final object.

All very wrong if you ignore what I wrote as part of my original note:
keep compilation products separated by branch name, not in the same
place.  This is essential to my request: without it, it is indeed very
wrong.  We currently separate out by compiler, options, machine
architecture, and adding the branch to that is trivial.


Bill

Re: Git checkout preserve timestamp?

[Andy Parkins]

On Monday 2007 March 05 14:46, Bill Lear wrote:

> All very wrong if you ignore what I wrote as part of my original note:
> keep compilation products separated by branch name, not in the same

I realise why it's causing you troubles.  However, I was hoping that that 
little example shows why it can never be right to use the timestamp out of 
the repository.

> place.  This is essential to my request: without it, it is indeed very
> wrong.  We currently separate out by compiler, options, machine
> architecture, and adding the branch to that is trivial.

I'm afraid that the unnecessary recompile is just a by-product of that 
organisation.  I still say that git is correct to touch the file dates.

[blatent plug]: perhaps my poorman's submodule support will get you by until 
real submodule support is implemented?

http://lists.zerezo.com/git/msg334639.html

I doubt it though - as you would probably want automatic checkout in your 
situation.



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

Re: Git checkout preserve timestamp?

[Bill Lear]

On Monday, March 5, 2007 at 16:01:45 (+0000) Andy Parkins writes:
>On Monday 2007 March 05 14:46, Bill Lear wrote:
>
>> All very wrong if you ignore what I wrote as part of my original note:
>> keep compilation products separated by branch name, not in the same
>
>I realise why it's causing you troubles.  However, I was hoping that that 
>little example shows why it can never be right to use the timestamp out of 
>the repository.

I don't understand then.  If the timestamp is stored per-branch, as it
must be, then no effective change takes place whatsoever, and all
products are compiled properly, and in their proper place.

If master:source.c compiles to .master/source.o and has a timestamp
.master/source.c.timestamp, switching to branch1 and back, and
restoring the timestamp does not do anything wrong.  It just prevents
a recompilation.

>I'm afraid that the unnecessary recompile is just a by-product of that 
>organisation.  I still say that git is correct to touch the file dates.

Well, git is certainly correct for those who want the standard behavior.

I don't think the current submodule support will help, but I am keen
to see submodules for other reasons.


Bill