Jeff King p...@peff.net writes:
It seems like applying a stash made with -k is fundamentally
misdesigned in the current code. We would want to apply to the working
tree the difference between the index and the working tree, but instead
we try to apply the difference between the HEAD and the
Jeff King p...@peff.net writes:
So I am trying to figure out what the use case here is. Clearly the
above is a toy case, but why is stash -k followed by a quick pop
useful in general? Certainly I use stash (without -k) and a quick
pop all the time, and I think that is what stash was designed
On Wed, Jun 10, 2015 at 12:16:25PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
So I am trying to figure out what the use case here is. Clearly the
above is a toy case, but why is stash -k followed by a quick pop
useful in general? Certainly I use stash (without -k) and a
On Wed, Jun 10, 2015 at 03:19:41PM -0300, bär wrote:
On Sun, Jun 7, 2015 at 9:40 AM, Jeff King p...@peff.net wrote:
Hrm. The new protection in v2.4.2 is meant to prevent you from losing
your index state during step 4 when we run into a conflict. But here you
know something that git
On Sun, Jun 7, 2015 at 9:40 AM, Jeff King p...@peff.net wrote:
Hrm. The new protection in v2.4.2 is meant to prevent you from losing
your index state during step 4 when we run into a conflict. But here you
know something that git doesn't: that we just created the stash based on
this same
On Wed, Jun 10, 2015 at 4:27 PM, Jeff King p...@peff.net wrote:
I dunno. With respect to the original patch, I am OK if we just want to
revert it. This area of stash seems a bit under-designed IMHO, but if
people were happy enough with it before, I do not think the safety
benefit from ed178ef
On Thu, Jun 04, 2015 at 08:43:00PM -0400, Jonathan Kamens wrote:
I'm writing about the patch that Jeff King submitted on April 22, in
20150422193101.gc27...@peff.net, in particular,
https://github.com/git/git/commit/ed178ef13a26136d86ff4e33bb7b1afb5033f908 .
It appears that this patch was
On Sun, Jun 07, 2015 at 08:40:01AM -0400, Jeff King wrote:
Are you running flake8 across the whole tree, or just on the files with
proposed changes? Does it need to see the whole tree? If you can get
away with feeding it single files, then it should be very efficient to
loop over the output
Hi folks,
I'm not sure how to respond to a particular mail [1] while keeping
this new one in the same thread, being that I just subscribed to the
list and I can't find a Message-ID in [1][2] either, so please forgive
me.
I bumped to 2.4.2 and I'm experiencing the very same issue Jonathan
Kamens
I'm writing about the patch that Jeff King submitted on April 22, in
20150422193101.gc27...@peff.net, in particular,
https://github.com/git/git/commit/ed178ef13a26136d86ff4e33bb7b1afb5033f908
. It appears that this patch was included in git 2.4.2, and it breaks my
workflow.
In particular, I
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
11 matches
Mail list logo
