1. 15 Jun, 2015 1 commit
    • Jeff King's avatar
      Revert "stash: require a clean index to apply" · 19376104
      Jeff King authored
      This reverts commit ed178ef1.
      
      That commit was an attempt to improve the safety of applying
      a stash, because the application process may create
      conflicted index entries, after which it is hard to restore
      the original index state.
      
      Unfortunately, this hurts some common workflows around "git
      stash -k", like:
      
          git add -p       ;# (1) stage set of proposed changes
          git stash -k     ;# (2) get rid of everything else
          make test        ;# (3) make sure proposal is reasonable
          git stash apply  ;# (4) restore original working tree
      
      If you "git commit" between steps (3) and (4), then this
      just works. However, if these steps are part of a pre-commit
      hook, you don't have that opportunity (you have to restore
      the original state regardless of whether the tests passed or
      failed).
      
      It's possible that we could provide better tools for this
      sort of workflow. In particular, even before ed178ef1, it
      could fail with a conflict if there were conflicting hunks
      in the working tree and index (since the "stash -k" puts the
      index version into the working tree, and we then attempt to
      apply the differences between HEAD and the old working tree
      on top of that). But the fact remains that people have been
      using it happily for a while, and the safety provided by
      ed178ef1 is simply not that great. Let's revert it for now.
      In the long run, people can work on improving stash for this
      sort of workflow, but the safety tradeoff is not worth it in
      the meantime.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      19376104
  2. 20 May, 2015 2 commits
    • Jeff King's avatar
      stash: recognize "--help" for subcommands · 5ba28313
      Jeff King authored
      If you run "git stash --help", you get the help for stash
      (this magic is done by the git wrapper itself). But if you
      run "git stash drop --help", you get an error. We
      cannot show help specific to "stash drop", of course, but we
      can at least give the user the normal stash manpage.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      5ba28313
    • Jeff King's avatar
      stash: complain about unknown flags · d6cc2df5
      Jeff King authored
      The option parser for git-stash stuffs unknown flags into
      the $FLAGS variable, where they can be accessed by the
      individual commands. However, most commands do not even look
      at these extra flags, leading to unexpected results like
      this:
      
        $ git stash drop --help
        Dropped refs/stash@{0} (e6cf6d80faf92bb7828f7b60c47fc61c03bd30a1)
      
      We should notice the extra flags and bail. Rather than
      annotate each command to reject a non-empty $FLAGS variable,
      we can notice that "stash show" is the only command that
      actually _wants_ arbitrary flags. So we switch the default
      mode to reject unknown flags, and let stash_show() opt into
      the feature.
      Reported-by: default avatarVincent Legoll <vincent.legoll@gmail.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d6cc2df5
  3. 22 Apr, 2015 1 commit
    • Jeff King's avatar
      stash: require a clean index to apply · ed178ef1
      Jeff King authored
      If you have staged contents in your index and run "stash
      apply", we may hit a conflict and put new entries into the
      index. Recovering to your original state is difficult at
      that point, because tools like "git reset --keep" will blow
      away anything staged.  We can make this safer by refusing to
      apply when there are staged changes.
      
      It's possible we could provide better tooling here, as "git
      stash apply" should be writing only conflicts to the index
      (so we know that any stage-0 entries are potentially
      precious). But it is the odd duck; most "mergy" commands
      will update the index for cleanly merged entries, and it is
      not worth updating our tooling to support this use case
      which is unlikely to be of interest (besides which, we would
      still need to block a dirty index for "stash apply --index",
      since that case _would_ be ambiguous).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ed178ef1
  4. 19 Sep, 2014 1 commit
  5. 02 Sep, 2014 1 commit
  6. 07 Aug, 2014 1 commit
    • Jeff King's avatar
      stash: default listing to working-tree diff · 288c67ca
      Jeff King authored
      When you list stashes, you can provide arbitrary git-log
      options to change the display. However, adding just "-p"
      does nothing, because each stash is actually a merge commit.
      
      This implementation detail is easy to forget, leading to
      confused users who think "-p" is not working. We can make
      this easier by defaulting to "--first-parent -m", which will
      show the diff against the working tree. This omits the
      index portion of the stash entirely, but it's simple and it
      matches what "git stash show" provides.
      
      People who are more clueful about stash's true form can use
      "--cc" to override the "-m", and the "--first-parent" will
      then do nothing. For diffs, it only affects non-combined
      diffs, so "--cc" overrides it. And for the traversal, we are
      walking the linear reflog anyway, so we do not even care
      about the parents.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      288c67ca
  7. 23 May, 2014 1 commit
  8. 23 Apr, 2014 1 commit
  9. 26 Feb, 2014 1 commit
  10. 07 Jan, 2014 1 commit
  11. 14 Aug, 2013 1 commit
  12. 01 Jul, 2013 1 commit
    • Petr Baudis's avatar
      git stash: avoid data loss when "git stash save" kills a directory · a7365313
      Petr Baudis authored
      "stash save" is about saving the local change to the working tree,
      but also about restoring the state of the last commit to the working
      tree.  When a local change is to turn a non-directory to a directory,
      in order to restore the non-directory, everything in the directory
      needs to be removed.
      
      Which is fine when running "git stash save --include-untracked",
      but without that option, untracked, newly created files in the
      directory will have to be discarded, if the state you are restoring
      to has a non-directory at the same path as the directory.
      
      Introduce a safety valve to fail the operation in such case, using
      the "ls-files --killed" which was designed for this exact purpose.
      
      The "stash save" is stopped when untracked files need to be
      discarded because their leading path ceased to be a directory, and
      the user is required to pass --force to really have the data
      removed.
      Signed-off-by: Petr Baudis's avatarPetr Baudis <pasky@ucw.cz>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a7365313
  13. 17 Jun, 2013 2 commits
  14. 17 Aug, 2012 1 commit
  15. 14 Apr, 2012 1 commit
  16. 01 Jan, 2012 1 commit
    • Jonathon Mah's avatar
      stash: Don't fail if work dir contains file named 'HEAD' · 44df2e29
      Jonathon Mah authored
      When performing a plain "git stash" (without --patch), git-diff would fail
      with "fatal: ambiguous argument 'HEAD': both revision and filename". The
      output was piped into git-update-index, masking the failed exit status.
      The output is now sent to a temporary file (which is cleaned up by
      existing code), and the exit status is checked. The "HEAD" arg to the
      git-diff invocation has been disambiguated too, of course.
      
      In patch mode, "git stash -p" would fail harmlessly, leaving the working
      dir untouched. Interactive adding is fine, but the resulting tree was
      diffed with an ambiguous 'HEAD' argument.
      
      Use >foo (no space) when redirecting output.
      
      In t3904, checks and operations on each file are in the order they'll
      appear when interactively staging.
      
      In t3905, fix a bug in "stash save --include-untracked -q is quiet": The
      redirected stdout file was considered untracked, and so was removed from
      the working directory. Use test path helper functions where appropriate.
      Signed-off-by: default avatarJonathon Mah <me@JonathonMah.com>
      Acked-by: default avatarThomas Rast <trast@student.ethz.ch>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      44df2e29
  17. 27 Aug, 2011 2 commits
  18. 08 Aug, 2011 1 commit
  19. 26 Jun, 2011 1 commit
    • David Caldwell's avatar
      stash: Add --include-untracked option to stash and remove all untracked files · 78751302
      David Caldwell authored
      The --include-untracked option acts like the normal "git stash save" but
      also adds all untracked files in the working directory to the stash and then
      calls "git clean --force --quiet" to restore the working directory to a
      pristine state.
      
      This is useful for projects that need to run release scripts. With this
      option, the release scripts can be from the main working directory so one
      does not have to maintain a "clean" directory in parallel just for
      releasing. Basically the work-flow becomes:
      
         $ git tag release-1.0
         $ git stash --include-untracked
         $ make release
         $ git clean -f
         $ git stash pop
      
      "git stash" alone is not enough in this case--it leaves untracked files
      lying around that might mess up a release process that expects everything to
      be very clean or might let a release succeed that should actually fail (due
      to a new source file being created that hasn't been committed yet).
      Signed-off-by: default avatarDavid Caldwell <david@porkrind.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      78751302
  20. 21 May, 2011 9 commits
  21. 07 Apr, 2011 1 commit
  22. 06 Apr, 2011 2 commits
    • Jeff King's avatar
      stash: drop dirty worktree check on apply · e0e2a9cb
      Jeff King authored
      Before we apply a stash, we make sure there are no changes
      in the worktree that are not in the index. This check dates
      back to the original git-stash.sh, and is presumably
      intended to prevent changes in the working tree from being
      accidentally lost during the merge.
      
      However, this check has two problems:
      
        1. It is overly restrictive. If my stash changes only file
           "foo", but "bar" is dirty in the working tree, it will
           prevent us from applying the stash.
      
        2. It is redundant. We don't touch the working tree at all
           until we actually call merge-recursive. But it has its
           own (much more accurate) checks to avoid losing working
           tree data, and will abort the merge with a nicer
           message telling us which paths were problems.
      
      So we can simply drop the check entirely.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      e0e2a9cb
    • Jeff King's avatar
      stash: fix accidental apply of non-existent stashes · 59d418fe
      Jeff King authored
      Once upon a time, "git rev-parse ref@{9999999}" did not
      generate an error. Therefore when we got an invalid stash
      reference in "stash apply", we could end up not noticing
      until quite late.  Commit b0f0ecd9 (detached-stash: work
      around git rev-parse failure to detect bad log refs,
      2010-08-21) handled this by checking for the "Log for stash
      has only %d entries" warning on stderr when we validated the
      ref.
      
      A few days later, e6eedc31 (rev-parse: exit with non-zero
      status if ref@{n} is not valid., 2010-08-24) fixed the
      original issue. That made the extra stderr test superfluous,
      but also introduced a new bug. Now the early call to:
      
        git rev-parse --symbolic "$@"
      
      fails, but we don't notice the exit code. Worse, its empty
      output means we think the user didn't provide us a ref, and
      we try to apply stash@{0}.
      
      This patch checks the rev-parse exit code and fails early in
      the revision parsing process. We can also get rid of the
      stderr test; as a bonus, this means that "stash apply" can
      now run under GIT_TRACE=1 properly.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Acked-by: Jon Seymour's avatarJon Seymour <jon.seymour@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      59d418fe
  23. 17 Mar, 2011 2 commits
    • Johannes Sixt's avatar
      stash: copy the index using --index-output instead of cp -p · 3ba2e865
      Johannes Sixt authored
      'git stash create' must operate with a temporary index. For this purpose,
      it used 'cp -p' to create a copy. -p is needed to preserve the timestamp
      of the index file. Now Jakob Pfender reported a certain combination of
      a Linux NFS client, OpenBSD NFS server, and cp implementation where this
      operation failed.
      
      Luckily, the first operation in git-stash after copying the index is to
      call 'git read-tree'. Therefore, use --index-output instead of 'cp -p'
      to write the copy of the index.
      
      --index-output requires that the specified file is on the same volume as
      the source index, so that the lock file can be rename()d. For this reason,
      the name of the temporary index is constructed in a way different from the
      other temporary files. The code path of 'stash -p' also needs a temporary
      index, but we do not use the new name because it does not depend on the
      same precondition as --index-output.
      Signed-off-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3ba2e865
    • Johannes Sixt's avatar
      stash: fix incorrect quoting in cleanup of temporary files · 23a32ffe
      Johannes Sixt authored
      The * was inside the quotes, so that the pattern was never expanded and the
      temporary files were never removed. As a consequence, 'stash -p' left a
      .git-stash-*-patch file in $GIT_DIR. Other code paths did not leave files
      behind because they removed the temporary file themselves, at least in
      non-error paths.
      Signed-off-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      23a32ffe
  24. 14 Mar, 2011 1 commit
    • Piotr Krukowiecki's avatar
      git stash: show status relative to current directory · 26b59b48
      Piotr Krukowiecki authored
      git status shows modified paths relative to current directory, so it's
      possible to copy&paste them directly, even if you're in a subdirectory.
      
      But "git stash apply" always shows status from root of git repository.
      This is misleading because you can't use the paths without modifications.
      
      This is caused by changing directory to root of repository at the
      beginning of git stash.
      
      This patch makes git stash show status relative to current directory.
      Instead of removing the "cd to toplevel", which would affect whole
      script and might have other side-effects, the fix is to change directory
      temporarily back to original dir just before displaying status.
      Signed-off-by: default avatarPiotr Krukowiecki <piotr.krukowiecki@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      26b59b48
  25. 13 Oct, 2010 1 commit
  26. 29 Sep, 2010 2 commits