git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

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