5 ms·

Mercurial is the same except: 0) you forgot to explain git's index. Mercurial doesn't have the index, it works how you described git. 2) data (blobs, revsets

by krupan 8y ago

Mercurial is the same except: 0) you forgot to explain git's index. Mercurial doesn't have the index, it works how you described git. 2) data (blobs, revsets, whatever) in the repo actually can never be lost, there is no automatic gc 3) no need for some different tool/viewer to view commits that don't have refs Technically there are several ways to remove data from the repo, but it never ever happens automatically behind your back.

chousuke 8y ago
The mental model helps me with git because it maps pretty closely to what data actually exists. The index is just a useful thing to help me put stuff into a repository in a controlled manner. I've never attained a similar transparent understanding of mercurial. I think I've asked this before, but what exactly are mercurial's branches? In git, they are a "physical" feature of the repository as it represents a set of lineages, not an actual repository object. As such, any reference to a commit uniquely identifies a branch, so the concept of a "named line of development" is simply implemented as a reference that gets updated as you make more commits. When you "delete" a branch in git, it goes nowhere. Only its name is removed. What sort of structure does mercurial use to represent its branches? I know they are not just an emergent thing like in git.
- deleted 8y ago
  [deleted]
- krupan 8y ago
  Mercurial uses a DAG just like git. It has facilities for embedding a branch name in each commit, or for not doing that and having anonymous branches. It also has a feature similar to git's "branches" Two articles that might help if you really want to dig into it: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... https://bryan-murdock.blogspot.com/2013/06/git-branches-are-not-branches.html https://bryan-murdock.blogspot.com/2013/06/git-branches-are-...
  - chousuke 8y ago
    Hmm, so the branch names are part of the commit's metadata. I'm not sure I agree with that, but I guess it's a valid choice. The first article also states that unnamed branches are useful for small, temporary diversions, and notes that git has to name branches, but I think that's somewhat misrepresenting git since you can throw away names as soon as they are no longer useful. To me it seems kind of silly to have unnamed branches, given that names are free and much easier to remember than commit hashes.

by krupan 8y ago

chousuke 8y ago

The mental model helps me with git because it maps pretty closely to what data actually exists. The index is just a useful thing to help me put stuff into a repository in a controlled manner. I've never attained a similar transparent understanding of mercurial. I think I've asked this before, but what exactly are mercurial's branches? In git, they are a "physical" feature of the repository as it represents a set of lineages, not an actual repository object. As such, any reference to a commit uniquely identifies a branch, so the concept of a "named line of development" is simply implemented as a reference that gets updated as you make more commits. When you "delete" a branch in git, it goes nowhere. Only its name is removed. What sort of structure does mercurial use to represent its branches? I know they are not just an emergent thing like in git.

deleted 8y ago
[deleted]
krupan 8y ago
Mercurial uses a DAG just like git. It has facilities for embedding a branch name in each commit, or for not doing that and having anonymous branches. It also has a feature similar to git's "branches" Two articles that might help if you really want to dig into it: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... https://bryan-murdock.blogspot.com/2013/06/git-branches-are-not-branches.html https://bryan-murdock.blogspot.com/2013/06/git-branches-are-...
- chousuke 8y ago
  Hmm, so the branch names are part of the commit's metadata. I'm not sure I agree with that, but I guess it's a valid choice. The first article also states that unnamed branches are useful for small, temporary diversions, and notes that git has to name branches, but I think that's somewhat misrepresenting git since you can throw away names as soon as they are no longer useful. To me it seems kind of silly to have unnamed branches, given that names are free and much easier to remember than commit hashes.