![]() I'm only talking about the logical semantics. Yes, and this is exactly why I declared this to be a fundamental flaw in git's model.ĭiffs are an implementation concern, which I don't care about. > Being able to take a sequence of commits and insert them into a repository just is not a thing that makes sense in git's model. My entire point was that a commit shouldn't represent the entire state of a repository. Yes, of course I realize that's the reason. > I think the reason for why the commit hash has to change is that a commit represents the entire state of a repository, not just the change made in the commit. This would (among other things) let you re-write the history structure without rewriting the commits themselves and causing other people to have to reset their repos, which seems insanely useful to me. By default, I think the identity of a commit should be defined by a hash of its contents only, but independent of its history. Of course it seems fine to have a hash that depends on the history, and it's very likely useful for many purposes, but that shouldn't be the primary mechanism for identifying commits. If I later discover a ZIP backup of the tree that I forgot to commit, and I want to insert it into the history, it shouldn't suddenly completely break the entire repo. I simply do not understand why this has to be the case. I feel (but could be potentially convinced otherwise?) that there is one very deep fundamental flaw in the semantic model, and that is the fact that the identity of a commit depends on its history. (Although really, my DVCS UI of choice is Magit, which I use for 99.9% of git stuff, to the point where I almost never need to actually run git myself on the command line.) When I first started with DVCS, I started with hg since it seemed easier to learn. Personally, I prefer the git UI because it has a more direct mapping onto manipulating a DAG of commits, but obviously not everyone feels that way, and I don't expect them to. hg more strongly discouraging history rewriting is part UI, part culture). hg has "bookmarks" that work like git's branches I don't think git has any equivalent of hg-style branches.įor the most part, you can do anything with either one that you could do with the other, and the practical differences are mostly just in the UI, as well as a cultural component (e.g. Git branches are mutable pointers that don't get recorded in the commit history, while in hg each commit records the branch it was committed to. The repository formats are different, of course, but it's easy enough to convert from one to the other. I don't believe hg has an equivalent of the git index, although there are other ways to get similar functionality if you want it. This hides it so effectively that I've seen several people complaining that they can't turn on red, not noticing that they do it every day. You can, but the existence of slip lanes everywhere its allowed mean you don't actually face the red light when doing so. Kinda like how people from the US think you can't turn left on red in Australia (equivalent of right on red in the US). My opinion is that defaulting to including changes from all files previously committed is such a sensible default that it makes the feature so seamless that people forget it exists even whilst using it. It's my impression that loads of people use this feature and somehow don't notice it exists, and will openly agree that mercurial lacks a staging area. I admit I have no idea how it works on the command line, but in tortoisehg I can select individual files and hunks thereof to add to a commit (screenshot: ). I'm sure someone will dispute that it is the same as the staging area, but mercurial does have the ability to only include some things in commits, and I use it daily. If you push the rebase remotely to a repository that previously had the original, Mercurial will tell people that changesets based on the original also need to be rebased when they pull it, and the history information will let them use the regular rebase flow to do it. The other fun feature is changeset evolution: when you rebase a changeset, Mercurial will keep the original changeset around with a link between the old and new versions of it. You can also configure whether or not remote repositories are public or not. There's also a "secret" phase, which Mercurial will refuse to push to a public repository. But when you push to (or pull from) a public repository, it becomes a "public" commit, and Mercurial will refuse to edit those commits. ![]() By default, all local commits are "draft" commits, which can have history edited. ![]() > the notion of committing locally and pushing remotely would be fundamentally different the notion of having an index and staging area would be fundamentally different (or absent)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |