This project is mirrored from Pull mirroring updated .
  1. 21 May, 2011 6 commits
  2. 07 Apr, 2011 1 commit
  3. 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, 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 <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Jeff King's avatar
      stash: fix accidental apply of non-existent stashes · 59d418fe
      Jeff King authored
      Once upon a time, "git rev-parse [email protected]{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
      A few days later, e6eedc31 (rev-parse: exit with non-zero
      status if [email protected]{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 "[email protected]"
      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 [email protected]{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 <[email protected]>
      Acked-by: Jon Seymour's avatarJon Seymour <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  4. 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 <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • 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 <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  5. 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 <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  6. 13 Oct, 2010 1 commit
  7. 29 Sep, 2010 2 commits
  8. 27 Sep, 2010 1 commit
  9. 22 Aug, 2010 7 commits
    • Jon Seymour's avatar
      detached-stash: simplify git stash show · a9bf09e1
      Jon Seymour authored
      This commit refactors git stash show to make use of the assert_stash_like function.
      git show now dies if the presented argument is non-stash-like.
      Previous behaviour was to tolerate commits that were not even stash-like.
      Previously, git stash show would accept stash-like arguments, but
      only if there was a stash on the stack.
      Now, git stash accepts stash-like arguments always and only fails
      if no stash-like argument is specified and there is no stash stack.
      Signed-off-by: Jon Seymour's avatarJon Seymour <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Jon Seymour's avatar
      detached-stash: simplify git stash branch · fb433dc9
      Jon Seymour authored
      This patch teaches git stash branch to tolerate stash-like arguments.
      In particular, a stash is only required if an argument isn't specified
      and the stash is only dropped if a stash entry reference was
      specified or implied.
      The implementation has been simplified by taking advantage of
      assert_stash_like() and the variables established by
      Signed-off-by: Jon Seymour's avatarJon Seymour <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Jon Seymour's avatar
      detached-stash: refactor git stash pop implementation · f276872d
      Jon Seymour authored
      git stash pop is abstracted into its own implementation function - pop_stash.
      The behaviour is changed so that git stash pop fails early if the
      the specified stash reference does not exist or does not refer to
      an extant entry in the reflog of the reference stash.
      This fixes the case where the apply succeeds, but the drop fails.
      Previously this caused caused git stash pop to exit with a non-zero exit code
      and a dirty tree.
      Now, git stash pop fails with a non-zero exit code, but the working
      tree is not modified.
      Signed-off-by: Jon Seymour's avatarJon Seymour <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Jon Seymour's avatar
      detached-stash: simplify stash_drop · 92e39e44
      Jon Seymour authored
      Previously, git stash drop would fail noisily while executing git reflog
      delete if the specified revision was not a stash reference.
      Now, git stash drop fails with an error message which more precisely
      indicates the reason for failure.
      Furthermore, git stash drop will now fail with a non-zero status code
      if [email protected]{n} specifies a stash log entry that does not actually exist.
      This change in behaviour is achieved by delegating argument parsing
      to the common parse_flags_and_rev() function (via a call to
      Signed-off-by: Jon Seymour's avatarJon Seymour <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Jon Seymour's avatar
      detached-stash: simplify stash_apply · 064ed100
      Jon Seymour authored
      The implementation of stash_apply() is simplified to take
      advantage of the common parsing function parse_flags_and_rev().
      Signed-off-by: Jon Seymour's avatarJon Seymour <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Jon Seymour's avatar
      detached-stash: work around git rev-parse failure to detect bad log refs · b0f0ecd9
      Jon Seymour authored
      This commit is required because git rev-parse in 1.7.2 does not correctly
      indicate invalid log references using a non-zero status code.
      We use a proxy for the condition (non-empty error output) as
      a substitute. This commit can be reverted when, and if, rev-parse
      is fixed to indicate invalid log references with a status code.
      Signed-off-by: Jon Seymour's avatarJon Seymour <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Jon Seymour's avatar
      detached-stash: introduce parse_flags_and_revs function · ef763129
      Jon Seymour authored
      Introduce parse_flags_and_revs. This function requires that
      there is at most one stash-like revision parameter and
      zero or more flags.
      It knows how to parse -q,--quiet and --index flags, but leaves
      other flags parsed.
      Specified revisions are checked to see that they are at
      least stash-like (meaning: they look like something created
      by git stash save or git stash create).
      If this is so, then IS_STASH_LIKE is initialized to a non-empty value.
      If the specified revision also looks like a stash log entry reference,
      then IS_STASH_REF is initialized to a non-empty value.
      References of the form [email protected]{spec} are required to precisely identify
      an individual commit.
      If no reference is specified, [email protected]{0} is assumed.
      Once the specified reference is validated to be at least stash_like
      an ensemble of derived variables, (w_commit, w_tree, b_commit, etc)
      is initialized with a single call to git rev-parse.
      Repeated calls to parse_flags_and_rev() avoid repeated calls
      to git rev-parse if the specified arguments have already been
      Subsequent patches in the series modify the existing
      git stash subcommands to make use of these functions
      as appropriate.
      An ensemble of supporting functions that make use of the state
      established by parse_flags_and_rev(). These are described below:
      The ancillary functions are:
      is_stash_like(): which can be used to test
      whether a specified commit looks like a commit created with
      git stash save or git stash create.
      assert_stash_like(): which can be used by
      commands that misbehave unless their arguments stash-like.
      is_stash_ref(): which checks whether an argument
      is valid stash reference(e.g. is of the form
      assert_stash_ref(): which can be used by commands
      that misbehave unless their arguments are both stash-like and
      refer to valid stash entries.
      Signed-off-by: Jon Seymour's avatarJon Seymour <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  10. 18 Apr, 2010 1 commit
    • CB Bailey's avatar
      stash: Don't overwrite files that have gone from the index · 7aa5d43c
      CB Bailey authored
      The use of git add -u in create_stash isn't always complete. In
      particular, if a file has been removed from the index but changed in the
      work tree it will not be added to the stash's saved work tree tree
      object. When stash then resets the work tree to match HEAD, any changes
      will be lost.
      To be complete, any work tree file which differs from HEAD needs to be
      saved, regardless of whether it still appears in the index or not.
      This is achieved with a combination of a diff against HEAD and a call to
      update-index with an explicit list of paths that have changed.
      Signed-off-by: CB Bailey's avatarCharles Bailey <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  11. 09 Apr, 2010 1 commit
    • Jeff King's avatar
      script with rev-list instead of log · b0e621ad
      Jeff King authored
      Because log.decorate now shows decorations for --pretty=oneline,
      we must explicitly turn it off when scripting. Otherwise,
      users with log.decorate set will get cruft like:
        $ git stash
        Saved working directory and index state WIP on master:
          2c1f7f5 (HEAD, master) commit subject
      Instead of adding --no-decorate to the log command line,
      let's just use the rev-list plumbing interface instead,
      which does the right thing.
      git-submodule has a similar call. Since it just counts the
      commit lines, nothing is broken, but let's switch it, too,
      for the sake of consistency and cleanliness.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  12. 17 Mar, 2010 1 commit
  13. 07 Mar, 2010 1 commit
  14. 16 Feb, 2010 1 commit
    • Thomas Rast's avatar
      stash pop: remove 'apply' options during 'drop' invocation · 460ccd0e
      Thomas Rast authored
      The 'git stash pop' option parsing used to remove the first argument
      in --index mode.  At the time this was implemented, this first
      argument was always --index.  However, since the invention of the -q
      option in fcdd0e92 (stash: teach quiet option, 2009-06-17) you can
      cause an internal invocation of
        git stash drop --index
      by running
        git stash pop -q --index
      which then of course fails because drop doesn't know --index.
      To handle this, instead let 'git stash apply' decide what the future
      argument to 'drop' should be.
      Warning: this means that 'git stash apply' must parse all options that
      'drop' can take, and deal with them in the same way.  This is
      currently true for its only option -q.
      Signed-off-by: default avatarThomas Rast <[email protected]>
      Acked-by: default avatarStephen Boyd <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  15. 02 Jan, 2010 1 commit
  16. 20 Oct, 2009 2 commits
  17. 02 Sep, 2009 1 commit
    • Matthieu Moy's avatar
      stash: simplify defaulting to "save" and reject unknown options · 3c2eb80f
      Matthieu Moy authored
      With the earlier DWIM patches, certain combination of options defaulted
      to the "save" command correctly while certain equally valid combination
      did not.  For example, "git stash -k" were Ok but "git stash -q -k" did
      not work.
      This makes the logic of defaulting to "save" much simpler. If there are no
      non-flag arguments, it is clear that there is no command word, and we
      default to "save" subcommand.  This rule prevents "git stash -q apply"
      from quietly creating a stash with "apply" as the message.
      This also teaches "git stash save" to reject an unknown option.  This is
      to keep a mistyped "git stash save --quite" from creating a stash with a
      message "--quite", and this safety is more important with the new logic
      to default to "save" with any option-looking argument without an explicit
      comand word.
      [jc: this is based on Matthieu's 3-patch series, and a follow-up
      discussion, and he and Peff take all the credit; if I have introduced bugs
      while reworking, they are mine.]
      Signed-off-by: default avatarMatthieu Moy <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  18. 15 Aug, 2009 3 commits
  19. 31 Jul, 2009 1 commit
  20. 23 Jul, 2009 1 commit
  21. 18 Jun, 2009 1 commit
  22. 09 Jun, 2009 1 commit
    • SZEDER Gábor's avatar
      Documentation: mention 'git stash pop --index' option explicitly · f39d6ee2
      SZEDER Gábor authored
      'git stash pop' supports the '--index' option since its initial
      implementation (bd56ff54, git-stash: add new 'pop' subcommand,
      2008-02-22), but its documentation does not mention it explicitly.
      Moreover, both the usage shown by 'git stash -h' and the synopsis
      section in the man page imply that 'git stash pop' does not have an
      '--index' option.
      First, this patch corrects the usage and the synopsis section.
      Second, the patch moves the description of the '--index' option to the
      'git stash pop' section in the documentation, and refers to it from
      the 'git stash apply' section.  This way it follows the intentions of
      commit d1836637 (Documentation: teach stash/pop workflow instead of
      stash/apply, 2009-05-28), as all 'git stash pop'-related documentation
      will be in one place without references to 'git stash apply'.
      Signed-off-by: default avatarSZEDER Gábor <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  23. 08 Dec, 2008 1 commit