In 89d750bf6fa025edeb31ad258cdd09a27a5c02fa I got a little too
aggressive with changing "git diff" to "git diff-tree". This is
shown to the user, who expects to see a full diff on their console,
and will want to see the output of their custom diff drivers (if
any) as the whole point of this call site is to show the diff to
the end-user.
Noticed by Johannes Sixt <j.sixt@viscovery.net>.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-stash needs to restrict itself to plumbing when running automated
diffs as part of its operation as the user may have configured a
custom diff driver that opens an interactive UI for certain/all
files. Doing that during scripted actions is very unfriendly to
the end-user and may cause git-stash to fail to work.
Reported by Johannes Sixt
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There was no newline at the end of the index commit message, putting
the shell prompt at its end after a 'git cat-file commit $id'. This is
similar to what was fixed in 843103d69388a5c74ed99753e1c162a66835b04d.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Originally, "apply --index" codepath was bolted on to the
"update working tree files and index, but then revert the
changes we make to the index except for added files so that we
do not forget about them" codepath, almost as an afterthought.
Because "apply --index" first prepares the final index state
upfront, "revert except the added paths" postprocessing does not
have to be done.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Two bugs that made the command practically unusable were fixed
with this.
- A stash created with a clean index does not have any
difference between the base tree and the index tree.
Trying to apply the diff between them to the index would
error out with "No changes". Even when the user asked to
unstash with --index, do not bother with --index action if
the base tree and the index tree match.
- After successfully performing the working tree merge, the
index was reloaded from an earlier state of unstashed index
with "read-tree"; this left all the paths cache dirty. By
moving the call to git-status after this read-tree, match the
cached stat information in the index.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier commit 7ab3cc70 fixed "stash clear" but broke save_stash,
because it forgot to make sure the reflog file exists before saving.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We say "SUBDIRECTORY_OK" but we did not chdir to toplevel; this
is fine as long as everything we use can be started from a
subdirectory, but unfortunately "merge-recursive" is not one of
the programs you can safely use from a subdirectory.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier when we read a tree into a temporary index, we read it
from scratch. Start from the current index and use read-tree -m
to preserve cached stat information as much as possible, in
order to speed up "git add -u". This makes "git stash" usable
in a source tree of nontrivial size.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When given this subcommand, git-stash will try to merge the stashed
index into the current one. Only trivial merges are possible, since
we have no index for the index ;-) If a trivial merge is not possible,
git-stash will bail out with a hint to skip the --index option.
For good measure, finally include a test case.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows you to say:
$ git stash starting to implement X
while creating a stash, and the resulting "stash list entry
would read as:
$ git stash list
stash@{0}: On master: starting to implement X
instead of the default message which talks about the commit the
stash happens to be based on (hence does not have much to do
with what the stashed change is trying to do).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A stash is about a change on top of an existing commit, and not
about that commit that happened to be on which the change was
created. Match the message we see in "git stash list" with the
commit log message to make this clear.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
If I do
git cat-file commit $commitid
for a commit created by stash, the next prompt starts directly after the
shortlog of HEAD.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, the git-log invocation would complain if a repo
had not had any stashes created in it yet:
$ git-init
$ git-stash
fatal: ambiguous argument 'refs/stash': unknown revision or
path not in the working tree.
Use '--' to separate paths from revisions
Instead, we only call git-log if we actually have a
refs/stash. We could alternatively create the ref when any
stash command is called, but it's better for the 'list'
command to not require write access to the repo.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When my boss has something to show me and I have to update, for some
reason I am always in the middle of doing something else, and git pull
command refuses to work in such a case.
I wrote this little script to save the changes I made, perform the
update, and then come back to where I was, but on top of the updated
commit.
This is how you would use the script:
$ git stash
$ git pull
$ git stash apply
[jc: with a few fixlets from the list]
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
