On Monday, March 5, 2007 at 13:50:45 (-0800) Linus Torvalds writes:
quoted text
>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.

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

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

quoted text
>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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html