git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Catalin Marinas <catalin.marinas@gmail.com>, git <git@vger.kernel.org>
Subject: StGIT refreshes all added files - limitation of git-write-tree?
Date: Tue, 14 Feb 2006 23:42:08 -0500	[thread overview]
Message-ID: <1139978528.28292.41.camel@dv> (raw)

Hello!

Current StGIT would refresh all added files on "stg refresh", even if
they are not specified on the command line.  I believe the same is true
for removed files.

That's when it can hurt.  I apply a large patch that modifies and adds
several files.  I want to split the patch into several StGIT patches by
selecting which files belong to which patch.  All files that need to be
modified are already modifies.  It's natural that I add new files using
"stg add" at this stage.  To me, adding files looks very similar to
modifying them.  However, then I create a patch by "stg new" and commit
_some_ files to it using "stg refresh" with those files on the command
line, I discover that _all_ added files have been refreshed.

The only workaround seems to be to add only those files that will be
included in the current patch.  The same should be true for renamed
files.

Debugging StGIT shows that it builds correct lists of the files to be
included in the current patch (update_cache in git.py), but they are
never used.  Instead, StGIT runs "git-write-tree" without arguments
(commit in git.py).  While StGIT is careful to only add user-specified
modified files to the directory cache, it does nothing to the added
files, which are in the cache already.

Purely StGIT way of handling this problem would be to remove added files
from the directory cache if they are not being committed.  The problem
is, "stg add" uses the cache, so this would undo "stg add" on files
unused in the current operation.  Either StGIT should restore files in
the cache after the refresh, or there should be a separate StGIT cache
that "stg add" would work on.  The former is potentially unreliable
(what if refresh is interrupted), the later creates an extra layer,
another directory cache no less, this reducing usability of the pure git
commands.

Another approach would be to get rid of "stg add" and "stg rm" and use
"stg refresh --add" and "stg refresh --rm" to add files to the current
patch or to remove them.  It does feel like removal of a useful feature,
since "stg diff" without arguments will no longer show added or removed
files.  Adding and removing files would be too immediate compared to
modifying them.

What I really hope to hear is that there is or there will be a git based
solution.  Either git-write-tree could be changed to only process files
specified on the command line, or there should be some other command
doing that.

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.

-- 
Regards,
Pavel Roskin

             reply	other threads:[~2006-02-15  4:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-15  4:42 Pavel Roskin [this message]
2006-02-15  6:20 ` StGIT refreshes all added files - limitation of git-write-tree? Junio C Hamano
2006-02-15  9:06   ` Pavel Roskin
2006-02-15  6:28 ` Shawn Pearce

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=1139978528.28292.41.camel@dv \
    --to=proski@gnu.org \
    --cc=catalin.marinas@gmail.com \
    --cc=git@vger.kernel.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).