Re: [QUESTION] or [BUG] Could not stash new bin files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]