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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).