Peter Karlsson wrote:
quoted text
> Randal L. Schwartz:
> 
>> That's not a job for a source code manager to do.  It's a job for your 
>> build/install tool.
> 
> Since there is no build step involved (my web site is just a CVS checkout at 
> the moment), it's a job for the checkout step. I'd really want to avoid 
> having a separate copy of the web site just so that I can do a "make 
> install". That would sort of negate the savings in disk space I hope seeing 
> by moving from CVS to Git.

The problem is that asking for the "last commit that changed a file" is
one of those features which comes out of the wash with proper merge
support.  There is often no clear answer to that question.

Here's an example.  Say two people apply a patch on their own branches,
which are subsequently merged.  The file was the same on both branches;
the commits may have exactly the same date, but different committers.

Now, consider what happens as you are switching branches.  Instead of
just being able to check the file identity in the tree, the system has
to somehow know that the (derived) ancestry of the file is different,
and now the content has to change.  That makes something that was
extremely fast, slow.

It's the sort of thing that's possible to arrange to work using hooks
(with whatever arbitrary decisions you choose to make for the areas
where it would be ambiguous), but no-one bothered because people
realised that it probably means you're trying to encapsulate the
information in the wrong place.

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