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 it?
I may have forgotten to say this, but we were helped by the logic
that makes sure we can read what we need to carry out the operation
and nothing more in the then-current (which is the same as current)
code that was written before we added --include-untracked. If the
check were enforcing that a stash-like must be a two parent merge,
which may have seemed reasonable back when the stash-like logic was
written, it would have been more painful to add three parent
possibility while still allowing people to use different vintage of
Git in the same repository.
Insisting on the i-commit and w-commit to have exactly the same
parent would mean that somebody who wants to improve create-stash
has one less option---even when the easiest and/or cleanest way to
improve create-stash for the particular goal were to record these
two commits based on a different parents, the requirement the patch
is trying to add here will prevent her from doing so and force her
to work around the pointless (read: not necessary when the current
code shows or applies the stash) check.
>> Is it worth it?
> Is it worth what? What are we losing?
The risk of actually closing the door for future developers. That
is a downside of this patch, if we were to apply it.
And having to spend braincycles to worry about what door we may be
unintentionally closing. That's a downside of even discussing this
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html