git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Arnauld Van Muysewinkel <arnauldvm@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [QUESTION] or [BUG] Could not stash new bin files
Date: Mon, 19 Apr 2010 04:35:23 -0500	[thread overview]
Message-ID: <20100419093523.GA26342@progeny.tock> (raw)
In-Reply-To: <p2rc8485ef11004190119q590aea5dy516bdc3d222ebb51@mail.gmail.com>

Hi Arnauld,

Arnauld Van Muysewinkel wrote:

>     $ git add -N XXX/src/jrxml/*.xls
>     $ git stash save --keep-index "Improving performance of views"
>     XXX/src/jrxml/SubCellMatrixCompared-EXPLAIN-new.xls: not added yet
>     XXX/src/jrxml/SubCellMatrixCompared-EXPLAIN-old.xls: not added yet
>     fatal: git-write-tree: error building trees

Yes, this is a known problem [1].

To explain this requires a bit of a digression into how ‘git stash’
works.  It is a neat script (in commit f2c66ed1, when it was added, it
was only 160 lines or so), especially because it uses ordinary git
commits and reflogs to maintain its data.  You have probably seen what
it looks like in gitk.  A particular stashed version looks like this:

                        index
                       /     \
  history ... --- HEAD ------- work tree

and these are all ordinary commits.

An unsolved problem with this data structure is that it does not store
information that can be stored in the index but not a commit.  This is
the case for the CE_INTENT_TO_ADD bit [2], and that it cannot be used
in commits is very deliberate: trying to commit immediately after an
add -N is almost certainly a sign of a mistake.  See 331fcb598 (git
add --intent-to-add: do not let an empty blob be committed by
accident, 2008-11-28) and the preceding commits for more on this.

One workaround is to make sure the intent-to-add bit is not set when
stashing from such a state.  For example, you can ‘git add’ the file,
or ‘git rm --cached’ it [3].

I suspect the correct fix would be to use the commit message for the
index commit to record the intent to add.

[...]
> Specificities:
> 
> * I have a file in the index that I do not want to stash

Could you explain this further?  The stash currently saves everything
about the current state (except files not in the index nor HEAD).

> * The two new files are binary files

Hope that helps,
Jonathan

[1] See, for example, this discussion:
http://thread.gmane.org/gmane.comp.version-control.git/127290

[2] CE_VALID and CE_SKIP_WORKTREE also, but I suspect no one is
worried about making stash track them.

[3] If you use git rm and then stash, watch out for the following bug.
http://thread.gmane.org/gmane.comp.version-control.git/145228

  reply	other threads:[~2010-04-19  9:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-19  8:19 [QUESTION] or [BUG] Could not stash new bin files Arnauld Van Muysewinkel
2010-04-19  9:35 ` Jonathan Nieder [this message]
2010-04-19 12:41   ` Jeff King

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=20100419093523.GA26342@progeny.tock \
    --to=jrnieder@gmail.com \
    --cc=arnauldvm@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).