El 27/6/2008, a las 22:45, David Jeske escribió:
- I could supercede 2-commits with 1, effectively making the bad-
commit
disappear in the linear history. Users who already have the history,
however,
would be unaffected, because the start/end endpoints are the same.
You can't do that. The start might be the same but the end point would
not, even if the file contents happened to be the same as they were
before. This is because each commit is identified by its SHA-1 hash,
and changing any ancestor anywhere in the DAG will have a trickle-down
effect to all subsequent commits which stem from it, changing their
SHA-1 hashes too. So you wind up with a different end point. This is
by design (see below).
El 27/6/2008, a las 22:51, David Jeske escribió:
What git can't do, is let me "supercede" the old DAG-subset, so
people I shared
them with can get my new changes without hurting their world.
Currently git
seems to rely on the idea that "if you accept changes into your tree
that will
be later rebased, it's up to you to figure it out". I don't see why
that is the
case.
It has to be this way because it is the only way to do distributed
SCM. Imagine for a minute that one developer has a commit "feedface",
fetched from another repo. If the commit or any parent (grand parent,
great grandparent etc) is changed then the hash _has_ to be different.
Otherwise you would have the untenable situation that two developers,
two repos, could refer to a particular commit "feedface" and it
wouldn't actually be the same thing. Distributed development would be
unworkably flakey if you couldn't rely on the stability of each
commit's SHA-1 hash, and that fact that it embodies not just that
particular state in the history, but all prior states too.
It's a totally basic, fundamental, central, non-negotiable concept to
Git's design. And not just an idiosyncrasy either; if you do a review
of other distributed SCMs out there you'll find that _all_ of them
have a similar underlying precept, as it's literally the only way to
do working distributed SCM.
Wincent
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
