Ramkumar Ramachandra 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 synonym f
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
Ramkumar Ramachandra 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 it?
I may have
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
Ramkumar Ramachandra 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 based off the
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 is
6 matches
Mail list logo
