Re: [PATCH] stash: tighten IS_STASH_LIKE logic

2013-04-19 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: My patch is not solving an end-user problem. Think of it as a source code comment: to answer the question what kind of commit does stash create make?, There already is sufficient comment that explains how a stash commit is constructed, isn't

Re: [PATCH] stash: tighten IS_STASH_LIKE logic

2013-04-19 Thread Ramkumar Ramachandra
Junio C Hamano wrote: The risk of actually closing the door for future developers. That is a downside of this patch, if we were to apply it. Okay, no issues. Drop it. Consider documenting the fact that IS_STASH_LIKE is merely a contextual synonym for IS_MERGE_COMMIT somewhere though. -- To

Re: [PATCH] stash: tighten IS_STASH_LIKE logic

2013-04-19 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: The risk of actually closing the door for future developers. That is a downside of this patch, if we were to apply it. Okay, no issues. Drop it. Consider documenting the fact that IS_STASH_LIKE is merely a contextual

[PATCH] stash: tighten IS_STASH_LIKE logic

2013-04-18 Thread Ramkumar Ramachandra
Currently, 'git stash show' and 'git stash apply' can show/apply any merge commit, as the test for setting IS_STASH_LIKE simply asserts if the commit is a merge. Improve the situation by asserting if the index_commit and the worktree_commit are based off the same commit, by checking that $REV^1

Re: [PATCH] stash: tighten IS_STASH_LIKE logic

2013-04-18 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: Currently, 'git stash show' and 'git stash apply' can show/apply any merge commit, as the test for setting IS_STASH_LIKE simply asserts if the commit is a merge. Improve the situation by asserting if the index_commit and the worktree_commit are

Re: [PATCH] stash: tighten IS_STASH_LIKE logic

2013-04-18 Thread Ramkumar Ramachandra
Junio C Hamano wrote: [...] I'm curious. Why are you going back on what you said just one day ago? What changed? In a previous email, you wrote: You are free to try to think of a way to tighten the implemention to reject a random two-or-three parent merge commit that is not a product of