Re: An alternate model for preparing partial commits
- From
Wincent Colaiuta <win@wincent.com>
- Date
- Jun 28, 2008, 17:23 UTC
- Message-ID
- <7E75E8FC-FC46-49BC-9610-7F62A3623576@wincent.com>
- In-Reply-To
- <willow-jeske-01l7ZyqpFEDjC=91ms>
El 27/6/2008, a las 22:45, David Jeske escribió:
Show 5 quoted lines
> - 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ó:
Show 9 quoted lines
> 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