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
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 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
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
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
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
6 matches
Mail list logo