From: Shawn Pearce <spearce@spearce.org>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: [PATCH] cogito: Avoid slowness when timewarping large trees.
Date: Fri, 24 Mar 2006 11:43:52 -0500 [thread overview]
Message-ID: <20060324164352.GA20684@spearce.org> (raw)
In-Reply-To: <20060324112246.GA5220@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Fri, Mar 24, 2006 at 03:01:35AM -0800, Junio C Hamano wrote:
>
> > > git-read-tree --reset "$base"
> > Exactly. That's what I meant. Thanks.
>
> Hmm. That doesn't actually work, though. If I have a history like this:
>
> $ cg-init -m "initial"
> $ cg-tag initial
> $ echo contents >file
> $ cg-add file
> $ cg-commit -m "added file"
>
> and I try this:
> $ echo changes >file
> $ git-read-tree --reset master
> $ git-read-tree -m -u master initial
>
> I get this:
> fatal: Entry 'file' not uptodate. Cannot merge.
>
> If I do an update-index before the second read-tree, then I simply get:
> fatal: Entry 'file' would be overwritten by merge. Cannot merge.
>
> Is there something I'm missing, or is a 'git reset --hard' really what
> we want here (in that case, the fact that git reset changes the HEAD
> might be a problem)?
This is sort of what I'm doing in pg-reset-tree, which is kind
of like 'git-reset --hard' but I think it is faster when $force
is unset:
# Remove files left over from merge conflicts and files which are
# somehow modified. If this makes a directory empty it may have
# been a new directory so delete that too.
#
(git-ls-files -z \
--others \
--ignored \
--exclude='*#1' \
--exclude='*#2' \
--exclude='*#3' \
--exclude='*.rej'
git-diff-index --name-only -z HEAD
) | perl -n0e 'chomp; unlink; 1 while (s,/[^/]*$,, && rmdir)'
# Rebuild the index and working directory. We'll only checkout the
# files which don't exist. This resets the modified files we deleted
# just above; remaining files will have their stat information updated
# in the index.
#
git-read-tree --reset HEAD &&
git-checkout-index --index --all $force \
|| die "Can't reset index and working directory."
# Now that the working directory is clean we can safely merge it to
# to our target tree, $new_base.
#
git-read-tree -m -u HEAD $new_base
The $force in git-checkout-index may or may not be set to
'--force'; its usually not set as its not usually necessary.
Unfortunately I've got a case where I'm mounting a directory
exported by SAMBA onto a Windows 2000 system and if I don't include
--force during git-checkout-index it doesn't work right about 1/3
of the time. (It appears to be bad stat information coming from
Cygwin/Windows/SAMBA/Solaris.)
You can't skip the git-checkout-index step (I've tried) as the
ls-files/diff-index above causes the modified files (in your test
above 'changes') to disappear from the working directory and the
read-tree may not bring it back.
Now that I think about it isn't this sort of where you were before
in cg-seek?
--
Shawn.
next prev parent reply other threads:[~2006-03-24 16:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-24 8:44 [PATCH] cogito: Avoid slowness when timewarping large trees Jeff King
2006-03-24 10:21 ` Junio C Hamano
2006-03-24 10:55 ` Jeff King
2006-03-24 11:01 ` Junio C Hamano
2006-03-24 11:22 ` Jeff King
2006-03-24 16:43 ` Shawn Pearce [this message]
2006-03-25 9:36 ` Jeff King
2006-03-25 9:39 ` [PATCH] " Jeff King
2006-03-26 18:05 ` Petr Baudis
2006-03-25 19:55 ` [PATCH] cogito: " Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060324164352.GA20684@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.