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

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