On Tue, 19 Apr 2005, Linus Torvalds wrote:
>
> The real expense right now of a merge is that we always forget all the
> stat information when we do a merge (since it does a read-tree). I have a
> cunning way to fix that, though, which is to make "read-tree -m" read in
> the old index state like
On Tue, 19 Apr 2005, Petr Baudis wrote:
>
> I'd actually prefer, if:
>
> (i) checkout-cache simply wouldn't touch files whose stat matches with
> what is in the cache; it updates the cache with the stat informations
> of touched files
Run "update-cache --refresh" _before_ doing the "checkout-c
Dear diary, on Tue, Apr 19, 2005 at 03:00:14PM CEST, I got a letter
where Paul Mackerras <[EMAIL PROTECTED]> told me that...
> Is there a way to check out a tree without changing the mtime of any
> files that you have already checked out and which are the same as the
> version you are checking out?
* David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-04-19 at 23:00 +1000, Paul Mackerras wrote:
> > Is there a way to check out a tree without changing the mtime of any
> > files that you have already checked out and which are the same as the
> > version you are checking out? It seems th
On Tue, 2005-04-19 at 23:00 +1000, Paul Mackerras wrote:
> Is there a way to check out a tree without changing the mtime of any
> files that you have already checked out and which are the same as the
> version you are checking out? It seems that checkout-cache -a doesn't
> overwrite any existing f
Is there a way to check out a tree without changing the mtime of any
files that you have already checked out and which are the same as the
version you are checking out? It seems that checkout-cache -a doesn't
overwrite any existing files, and checkout-cache -f -a overwrites all
files and gives the
6 matches
Mail list logo
