On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
IOW, it's not actually transferring them and saving them, since a simple
delete of the origin branch will basically make them unreachable.
Fine. At least it works the same way as fetch, then. But it's still a huge
mistake, because it really does mean that it is technically no different
at all to just mentioning the SHA1 in the commit message, the way we
already do for backports.
The "origin" link has no _meaning_ for git, in other words.
It carries along information that is worthless and meaningless and hidden.
I refuse to touch such an obviously braindamaged design. It has no sane
_semantics_. If it doesn't have semantics, it shouldn't exist, certainly
not as some architected feature.
Nobody has shown any actual sane meaning for it. The only ones that have
been mentioned have been for things like avoiding re-picking commits
during a "git rebase", but (a) the patch SHA1 does that already for things
that are truly identical an (b) since that information isn't reliable
_anyway_, and since it's apparently a user choice, it's just "random".
I'm sorry, but "good design" is a hell of a lot more important than some
made-up use case that isn't even reliable, and doesn't match any actual
real problems that anybody can explain.
Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html