7 ms·

Note the qualifier "for a Git user interface". The average git command is along the lines of "git ph-nglui --mglw=nafh Cthulhu...R'lyeh -- wgah^nagl fhtagn"

kazinator 7y ago
That cute rhetoric will not fool anyone. Common git workflows use fairly succinct git commands: git diff git commit -p git rebase -i HEAD~3 The command quoted in my original comment is just this we strip away the SHA256 garbage: git log abac87a..f787cac (Or maybe it is: git log abac87a^..f787cac^ I cannot guess whether the ^ operator still has the same meaning or whether it is part of this ^{sha...} notation.) The hashes will typically be copy and pasted, so you type just the git log, .. and spaces. The fixed parts of convoluted git syntax can be hidden behind shell functions and aliases. But notations for referencing objects are not fixed; they will end up as arguments.
- jolmg 7y ago
  > I cannot guess whether the ^ operator still has the same meaning or whether it is part of this ^{sha...} notation.) This isn't the first ^{...} notation. The manpage gitrevisions(7) also mentions <rev>^{/<text>} for referencing a commit based on a regular expression of its commit message, like git checkout 'add-search^{/finished query builder}' Though, this new notation is probably more in-line with the notation <rev>^{<type>}, which lets you disambiguate what you put in <rev> as in deadbeef^{tag}, so that it's not confused with deadbeef^{commit}. EDIT: The article doesn't mention it, but I imagine one interpretation would take precedence and cause git to issue a warning when it's ambiguous. Right now, if I tag a commit with the hash of another commit, its interpretation as a tag takes precedence and I get a warning at the top, "warning: refname '368bc6e' is ambiguous." That would mean you'd only ever write ^{sha256} when the provided part of a sha256 hash is ambiguous with an existing sha1 hash or something else like a tag. That's also vice versa with ^{sha1}.
- allover 7y ago
  You are now ignoring the fact that in the initial quote you objected to was the intentionally tongue-in-cheek: > 'For a Git user interface this is relatively straightforward and concise'. It kinda looks like you missed the joke and are now doubling-down on your disagreement. The author does not think the proposed example is reasonable. You're in agreement.
  - kazinator 7y ago
    Since git is something that I rely on for everyday use, and long-term data stroage, and its development is being threatened by the inclusion of moronic changes I completely disagree with, I'm completely unreceptive to jokes. This is no laughing matter.
    - allover 7y ago
      I agree, things shouldn't be this bad. But unless you're going to take this up with Linus, you're just yelling at your fellow disappointed spectators.
  - hinkley 7y ago
    And the responder makes a pretty unsubtle allusion to Lovecraft. Anyone who compares the git CLI to being driven insane by Elder Gods is not defending the git CLI.
    - allover 7y ago
      Not sure if the HN thread or my comment has thrown you, but I'm replying to 'kazinator'. I know he's not defending it. What I said is that he (kazinator) is inadvertently attacking somebody that's also not defending it (the author).
- wyoung2 7y ago
  > That cute rhetoric will not fool anyone. Well, let's see, the Fossil equivalents are: 1. Do nothing at all for a conversion from the SHA-1 to SHA-3 — yes, 3, not 2 as in Git! — because it's automatic for months now and dead easy going back 3 years now. (https://www.fossil-scm.org/fossil/doc/trunk/www/hashpolicy.wiki https://www.fossil-scm.org/fossil/doc/trunk/www/hashpolicy.w...) 2. "fossil diff" 3. "fossil ci" 4. Why are you rebasing in the first place, again? https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.m...
  - danShumway 7y ago
    Articles like this are eye opening to me, in a bad way. Every once in a while, I get really curious about giving Fossil a try, because it does have some legitimately cool ideas, and then I see the documentation saying things like: > Rebasing is the same as lying And I think, "Holy crud do I not want to be part of this community." The nice thing about Git is that (within reason) once I understood it, I was able to use it in very flexible ways. It's really common for different projects I manage to range all over the place from the extreme "commits as literal history" perspective all the way to the "commits as literature/guide" perspective. Sometimes I don't rebase at all, sometimes I rebase a lot. Sometimes I commit everything, all the time, sometimes I refuse to commit any code that isn't a deployable feature. Sometimes I leave branches as historical artifacts, sometimes I don't care about history and I'm just trying to coordinate developers across timelines. That's not to say that Git isn't opinionated about some things -- nearly all good tools have at least a few strong opinions. But Git passes the (IMO extremely low) bar of not conflating a workflow decision with a moral failing. Over the years as a software engineer, I've learned to be somewhat skeptical of programming/workflow heuristics advertised as rules, and to be very skeptical of heuristics advertised as ideologies. I really don't understand the perspective of someone who can't think of even one good reason why they would ever want to edit history. You've never accidentally committed a password to repo, or had to respond to a takedown request?
    - wyoung2 7y ago
      > sometimes I don't care about history and I'm just trying to coordinate developers across timelines The fact that Fossil preserves history does not prevent you from coordinating with people across timelines. It is rather the whole point of a DVCS. > conflating a workflow decision with a moral failing I think it's fairer to say that we don't think a data repository is any place for lies of any sort, even white lies. > I've learned to be somewhat skeptical of programming/workflow heuristics advertised as rules, and to be very skeptical of heuristics advertised as ideologies. Sure, flexible tools are often better than inflexible ones, but you also have to consider the cost of the flexibility. Here, it means someone can say "this happened at some point in the past," and it's just plain wrong. That isn't always an important thing. Most filesystems and databases operate on the same principle, presenting only the current truth, not any past truth. Yet, we also have snapshotting in DBMSes and filesystems, because it's often very useful to be able to say, "This was the state of the system as of 2020.02.04." You don't need a snapshotting filesystem for everything, and you don't need Fossil for everything, but it sure is nice to have ready access to both when needed. > You've never accidentally committed a password to repo, or had to respond to a takedown request? Fossil has shunning for that: https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki And no, shunning is nothing at all like rebase, which should be clear from the article. Fossil also has the `amend` command: http://fossil-scm.org/fossil/help?cmd=amend http://fossil-scm.org/fossil/help?cmd=amend And no, it is also not like rebase, because it only adds to the project history, it never destroys information.
- deleted 7y ago
  [deleted]
- microtherion 7y ago
  As others have pointed out, there already is precedent for ^{...}, so if you're comfortable with the other uses, I'm not sure why you should NOT be comfortable with this new addition.

kazinator 7y ago

That cute rhetoric will not fool anyone. Common git workflows use fairly succinct git commands: git diff git commit -p git rebase -i HEAD~3 The command quoted in my original comment is just this we strip away the SHA256 garbage: git log abac87a..f787cac (Or maybe it is: git log abac87a^..f787cac^ I cannot guess whether the ^ operator still has the same meaning or whether it is part of this ^{sha...} notation.) The hashes will typically be copy and pasted, so you type just the git log, .. and spaces. The fixed parts of convoluted git syntax can be hidden behind shell functions and aliases. But notations for referencing objects are not fixed; they will end up as arguments.

jolmg 7y ago
> I cannot guess whether the ^ operator still has the same meaning or whether it is part of this ^{sha...} notation.) This isn't the first ^{...} notation. The manpage gitrevisions(7) also mentions <rev>^{/<text>} for referencing a commit based on a regular expression of its commit message, like git checkout 'add-search^{/finished query builder}' Though, this new notation is probably more in-line with the notation <rev>^{<type>}, which lets you disambiguate what you put in <rev> as in deadbeef^{tag}, so that it's not confused with deadbeef^{commit}. EDIT: The article doesn't mention it, but I imagine one interpretation would take precedence and cause git to issue a warning when it's ambiguous. Right now, if I tag a commit with the hash of another commit, its interpretation as a tag takes precedence and I get a warning at the top, "warning: refname '368bc6e' is ambiguous." That would mean you'd only ever write ^{sha256} when the provided part of a sha256 hash is ambiguous with an existing sha1 hash or something else like a tag. That's also vice versa with ^{sha1}.
allover 7y ago
You are now ignoring the fact that in the initial quote you objected to was the intentionally tongue-in-cheek: > 'For a Git user interface this is relatively straightforward and concise'. It kinda looks like you missed the joke and are now doubling-down on your disagreement. The author does not think the proposed example is reasonable. You're in agreement.
- kazinator 7y ago
  Since git is something that I rely on for everyday use, and long-term data stroage, and its development is being threatened by the inclusion of moronic changes I completely disagree with, I'm completely unreceptive to jokes. This is no laughing matter.
  - allover 7y ago
    I agree, things shouldn't be this bad. But unless you're going to take this up with Linus, you're just yelling at your fellow disappointed spectators.
- hinkley 7y ago
  And the responder makes a pretty unsubtle allusion to Lovecraft. Anyone who compares the git CLI to being driven insane by Elder Gods is not defending the git CLI.
  - allover 7y ago
    Not sure if the HN thread or my comment has thrown you, but I'm replying to 'kazinator'. I know he's not defending it. What I said is that he (kazinator) is inadvertently attacking somebody that's also not defending it (the author).
wyoung2 7y ago
> That cute rhetoric will not fool anyone. Well, let's see, the Fossil equivalents are: 1. Do nothing at all for a conversion from the SHA-1 to SHA-3 — yes, 3, not 2 as in Git! — because it's automatic for months now and dead easy going back 3 years now. (https://www.fossil-scm.org/fossil/doc/trunk/www/hashpolicy.wiki https://www.fossil-scm.org/fossil/doc/trunk/www/hashpolicy.w...) 2. "fossil diff" 3. "fossil ci" 4. Why are you rebasing in the first place, again? https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.m...
- danShumway 7y ago
  Articles like this are eye opening to me, in a bad way. Every once in a while, I get really curious about giving Fossil a try, because it does have some legitimately cool ideas, and then I see the documentation saying things like: > Rebasing is the same as lying And I think, "Holy crud do I not want to be part of this community." The nice thing about Git is that (within reason) once I understood it, I was able to use it in very flexible ways. It's really common for different projects I manage to range all over the place from the extreme "commits as literal history" perspective all the way to the "commits as literature/guide" perspective. Sometimes I don't rebase at all, sometimes I rebase a lot. Sometimes I commit everything, all the time, sometimes I refuse to commit any code that isn't a deployable feature. Sometimes I leave branches as historical artifacts, sometimes I don't care about history and I'm just trying to coordinate developers across timelines. That's not to say that Git isn't opinionated about some things -- nearly all good tools have at least a few strong opinions. But Git passes the (IMO extremely low) bar of not conflating a workflow decision with a moral failing. Over the years as a software engineer, I've learned to be somewhat skeptical of programming/workflow heuristics advertised as rules, and to be very skeptical of heuristics advertised as ideologies. I really don't understand the perspective of someone who can't think of even one good reason why they would ever want to edit history. You've never accidentally committed a password to repo, or had to respond to a takedown request?
  - wyoung2 7y ago
    > sometimes I don't care about history and I'm just trying to coordinate developers across timelines The fact that Fossil preserves history does not prevent you from coordinating with people across timelines. It is rather the whole point of a DVCS. > conflating a workflow decision with a moral failing I think it's fairer to say that we don't think a data repository is any place for lies of any sort, even white lies. > I've learned to be somewhat skeptical of programming/workflow heuristics advertised as rules, and to be very skeptical of heuristics advertised as ideologies. Sure, flexible tools are often better than inflexible ones, but you also have to consider the cost of the flexibility. Here, it means someone can say "this happened at some point in the past," and it's just plain wrong. That isn't always an important thing. Most filesystems and databases operate on the same principle, presenting only the current truth, not any past truth. Yet, we also have snapshotting in DBMSes and filesystems, because it's often very useful to be able to say, "This was the state of the system as of 2020.02.04." You don't need a snapshotting filesystem for everything, and you don't need Fossil for everything, but it sure is nice to have ready access to both when needed. > You've never accidentally committed a password to repo, or had to respond to a takedown request? Fossil has shunning for that: https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki And no, shunning is nothing at all like rebase, which should be clear from the article. Fossil also has the `amend` command: http://fossil-scm.org/fossil/help?cmd=amend http://fossil-scm.org/fossil/help?cmd=amend And no, it is also not like rebase, because it only adds to the project history, it never destroys information.
deleted 7y ago
[deleted]
microtherion 7y ago
As others have pointed out, there already is precedent for ^{...}, so if you're comfortable with the other uses, I'm not sure why you should NOT be comfortable with this new addition.