3 ms·

Commits are not directories. I don't know why you would want to muddle the two concepts, but doing so would make git's UI more inconsistent and would break the

by Crito 13y ago

Commits are not directories. I don't know why you would want to muddle the two concepts, but doing so would make git's UI more inconsistent and would break the principle of least suprise moreso than it is right now. Just because Mercurial does it, doesn't mean that it is thought out or makes sense.

jordigh 13y ago
Of course commits are not directories, but it's a good UI analogy. In any context where hg accepts a revision number, it doesn't also accept a path, so there's no possible ambiguity, but git's UI requires lots of ambiguous parsing. An example of this is how many git users get in the habit of cargo-culting "--" to separate paths from options.
- Crito 13y ago
  > Of course commits are not directories, but it's a good UI analogy Why is it a good analogy? Directories are doubly linked trees^, each directory containing references to all child directories and a single parent directory, with some spacial implications (it makes sense to talk about directories being in or containing other directories). Commits make up singly linked DAGs, with each commit only having references to potentially many parent commits but no child commits, with strong temporal implications (it makes sense to talk about commits preceding or following other commits, with distant simultaneity frequently making an appearance). These two concepts really have very little overlap, other than both being graphs. Even if we just decided that "HEAD"->"." anyway, we can't keep that up for long. What the hell would ".." become? "HEAD^" might seem like the obvious answer, but you would be left to figure out what the "directory equivalent" of "HEAD^2" is. "HEAD~2^2"? The Unix relative directory language is not expressive enough for git, even if you want to force the analogy for some reason. Directories could be a good analogy for git's tree objects, but you operate on those through the high-level porcelain. There are certainly problems with git's porcelain, and there are obvious improvements to be made, but this is not one of them. ^barring symbolic links, which we can ignore unless we want to open a whole 'Unix Haters Handbook'-esque can of worms...
  - jordigh 13y ago
    >> Of course commits are not directories, but it's a good UI analogy > Why is it a good analogy? Because it has associations "here" and "now" and "current". It doesn't fit all of the other meanings of "current directory", but it does fit the the "nowness" of it (just like git's trees don't have clorophyll or bark, that doesn't mean that calling them trees is a bad analogy).
    - Crito 13y ago
      This is absurd; VCR remote controls have concepts that can be loosely mapped to "here"/"now"/"current" (hell, VCRs are better for this since they at least relate to recording state and the temporal relationship of different pieces of data!), but you're not going to get much utility out of designing your VCS UI with a VCR in mind. Git trees are called trees because they are directed graphs without cycles. Directed graphs without cycles are called "trees" because they look mildly like them, but the name that you give them is of little consequence. That name does not really represent any sort of "UI".

by Crito 13y ago

jordigh 13y ago

Of course commits are not directories, but it's a good UI analogy. In any context where hg accepts a revision number, it doesn't also accept a path, so there's no possible ambiguity, but git's UI requires lots of ambiguous parsing. An example of this is how many git users get in the habit of cargo-culting "--" to separate paths from options.

Crito 13y ago
> Of course commits are not directories, but it's a good UI analogy Why is it a good analogy? Directories are doubly linked trees^, each directory containing references to all child directories and a single parent directory, with some spacial implications (it makes sense to talk about directories being in or containing other directories). Commits make up singly linked DAGs, with each commit only having references to potentially many parent commits but no child commits, with strong temporal implications (it makes sense to talk about commits preceding or following other commits, with distant simultaneity frequently making an appearance). These two concepts really have very little overlap, other than both being graphs. Even if we just decided that "HEAD"->"." anyway, we can't keep that up for long. What the hell would ".." become? "HEAD^" might seem like the obvious answer, but you would be left to figure out what the "directory equivalent" of "HEAD^2" is. "HEAD~2^2"? The Unix relative directory language is not expressive enough for git, even if you want to force the analogy for some reason. Directories could be a good analogy for git's tree objects, but you operate on those through the high-level porcelain. There are certainly problems with git's porcelain, and there are obvious improvements to be made, but this is not one of them. ^barring symbolic links, which we can ignore unless we want to open a whole 'Unix Haters Handbook'-esque can of worms...
- jordigh 13y ago
  >> Of course commits are not directories, but it's a good UI analogy > Why is it a good analogy? Because it has associations "here" and "now" and "current". It doesn't fit all of the other meanings of "current directory", but it does fit the the "nowness" of it (just like git's trees don't have clorophyll or bark, that doesn't mean that calling them trees is a bad analogy).
  - Crito 13y ago
    This is absurd; VCR remote controls have concepts that can be loosely mapped to "here"/"now"/"current" (hell, VCRs are better for this since they at least relate to recording state and the temporal relationship of different pieces of data!), but you're not going to get much utility out of designing your VCS UI with a VCR in mind. Git trees are called trees because they are directed graphs without cycles. Directed graphs without cycles are called "trees" because they look mildly like them, but the name that you give them is of little consequence. That name does not really represent any sort of "UI".