git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git stash apply usability issues

From
Steven Grimm <koreth@midwinter.com>
Date
Oct 18, 2007, 14:12 UTC
Message-ID
<471769D3.4080908@midwinter.com>
In-Reply-To
<47171A21.9030003@viscovery.net>
Johannes Sixt wrote:
Show 9 quoted lines
> (2) when 'git stash apply' runs merge-recursive, it treats the current 
> state as 'ours' and the stash as 'theirs'. IMHO it should be the other 
> way round: I have stashed away changes to a binary file. Then 
> committed a different modification to it, and now want to apply the 
> stash. This results in a conflict that leaves the current state in the 
> working tree, but I had preferred that the stashed binary file were in 
> the working tree now.
>
> What do other git-stash users think about changing the order?

Seems right to me. I'd expect to get the stashed version in the working tree in that case.

-Steve
Previous: Johannes SixtNext: Shawn O. Pearce
Message 2 of 8 in “git stash apply usability issues”
  1. Johannes SixtOct 18, 2007
  2. Steven GrimmOct 18, 2007
  3. Shawn O. PearceOct 19, 2007
  4. Karl HasselströmOct 19, 2007
  5. David KastrupOct 19, 2007
  6. Avoid invoking diff drivers during git-stashShawn O. Pearce, Oct 19, 2007
  7. Johannes SixtOct 19, 2007
  8. Shawn O. PearceOct 19, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.