From: Shawn Pearce <spearce@spearce.org>
To: Pavel Roskin <proski@gnu.org>
Cc: Catalin Marinas <catalin.marinas@gmail.com>, git <git@vger.kernel.org>
Subject: Re: StGIT refreshes all added files - limitation of git-write-tree?
Date: Wed, 15 Feb 2006 01:28:14 -0500 [thread overview]
Message-ID: <20060215062814.GA26632@spearce.org> (raw)
In-Reply-To: <1139978528.28292.41.camel@dv>
Pavel Roskin <proski@gnu.org> wrote:
> Or maybe git-write-tree and other utilities could be changed to work on
> a copy of the index file? I would prefer not to move the
> actual .git/index away, but to make a copy for the current "stg refresh"
> operation.
git-write-tree pays attention to the GIT_INDEX_FILE environment
variable; if this, GIT_DIR and GIT_OBJECT_DIRECTORY are set you can
redirect git-write-tree to look at a different index. One way to
create a tree from a mixture of your current index and the current
HEAD's tree is to set GIT_INDEX_FILE to a temporary file name
(which doesn't exist), use git-read-tree to load the current tree
unmodified into that index, copy the modified records of interest
from the current index to the temporary index, then git-write-tree
from the temporary index. But now you need to update your current
index with the real SHA1s of the written files.
Somewhat convoluted. I think that git-commit.sh and cg-commit.sh
play such games to do partial commits based on what the user has
passed on the command line or modified in their editor (which is
actually a rather cool feature of Cogito). I'm using a similar
trick in pg to load binary objects from a patch directory (for a
specific use case that I have). git-am.sh uses a similar trick
to perform a 3 way merge if git-apply fails.
--
Shawn.
prev parent reply other threads:[~2006-02-15 6:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-15 4:42 StGIT refreshes all added files - limitation of git-write-tree? Pavel Roskin
2006-02-15 6:20 ` Junio C Hamano
2006-02-15 9:06 ` Pavel Roskin
2006-02-15 6:28 ` Shawn Pearce [this message]
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=20060215062814.GA26632@spearce.org \
--to=spearce@spearce.org \
--cc=catalin.marinas@gmail.com \
--cc=git@vger.kernel.org \
--cc=proski@gnu.org \
/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).