6 ms·

Thing is most of these can simply be fixed using an alias, its not that hard to remember '-b' creates a new branch, but 'gcb' followed by the branch name I want

Thing is most of these can simply be fixed using an alias, its not that hard to remember '-b' creates a new branch, but 'gcb' followed by the branch name I want is probably easier, however maybe someone wants 'gcob' or just 'cob', thats what Alias is for.

CydeWeys 7y ago
It'd be better to not have to do these things at all, i.e. if the commands just made sense out of the box. These are problems that every single person learning git has to figure out and then come up with their own solutions for.
- glennpratt 7y ago
  I use git with no aliases and have forever. I came from SVN, and myself and the entire team I worked with at the time enjoyed the transition and had very few issues. So much of this drama seems propped up on things that just aren't that difficult.
weberc2 7y ago
I don’t think those examples were meant to be an exhaustive list of git’s UI warts. There are many that are harder to remember and creating aliases and functions for each of them require building a full alternative UI. For example, how do you see all of the changes in a branch (IIRC the equivalent of ‘hg diff -b branch-name’)? How do you see the changes for just one commit (I.e., ‘hg diff -c $commit’). These things are all feasible in git, but I can never remember the incantation, so I have to Google every time. I haven’t used hg in 5 years and I still have an easier time remembering those commands.
- samatman 7y ago
  The changes for just one commit are `git diff $commit`, while the changes for a branch are `git diff $branch`. While there are a metric ton of things which are confusing about git, this was perhaps not the greatest example.
  - jcranmer 7y ago
    `git diff <commit>' is the set of changes since that commit, not the changes of that commit (the distinction between hg diff -r and hg diff -c). Similarly, `git diff <branch>' is the diff between that branch and the current HEAD, not the diff of the branch itself. So perhaps it's a great example if you've gotten it wrong?
    - weberc2 7y ago
      /u/samatman is definitely mistaken, and I think you are correct (although I'm not sure about "the set of changes since that commit"). As far as I can tell, `git diff <commit>` and `git diff <branch>` both just diff your current workspace against the commit/branch respectively. In the case of the branch, the correct result is something like "what has changed since my branch diverged from its parent"--basically what you see in a PR. I think this is unnecessarily obscure in Git because a "branch" isn't really a branch in the git data model; rather it's something like "the tip of the branch". I don't think I've ever wanted to compare my workspace against a branch, but clearly diffing the branch is useful (as evidenced by PRs). Similarly, I'm much less inclined to diff my workspace against a particular commit, but I often want to see the contents of an individual commit (another common operation in the Github UI). In essence, if Github is any indicator, Git's data model is a subpar fit for the VCS use case.
    - samatman 7y ago
      That's fair, insofar as I'm unfamiliar with the mercurial commands. It's unfair insofar as it does what I expect it to, which is to diff between what I'm curious about, and where I am. In other words, if you elide the second argument, it defaults to wherever HEAD is. The point being, this is not something I personally need to look up. I'd venture a guess that your familiarity with hg is interfering because the conventions are different.
      - jcranmer 7y ago
        That brings up a deeper issue with git's philosophy. Git's UI is largely geared to introspecting the repository history only insofar as it exists to the currently existing checkout--commands that interact with history without concerning themselves with the current checkout are far more inscrutable, confusing, and difficult to find. By contrast, Mercurial's UI makes the repository history a more first-class citizen, and it is very easy to answer basic questions about the history of the repository itself. If you're doing any sort of source code archaeology, that functionality is far more valuable than comparing it to the current state: I don't want to know what changed since this 5-year-old patch, I want to know what this 5-year-old patch itself changed to fix an issue.
- u801e 7y ago
  > How do you see the changes for just one commit (I.e., ‘hg diff -c $commit’). git show <commitish> will show the log message and the diff from the parent commit tree.

CydeWeys 7y ago

It'd be better to not have to do these things at all, i.e. if the commands just made sense out of the box. These are problems that every single person learning git has to figure out and then come up with their own solutions for.

glennpratt 7y ago
I use git with no aliases and have forever. I came from SVN, and myself and the entire team I worked with at the time enjoyed the transition and had very few issues. So much of this drama seems propped up on things that just aren't that difficult.

weberc2 7y ago

I don’t think those examples were meant to be an exhaustive list of git’s UI warts. There are many that are harder to remember and creating aliases and functions for each of them require building a full alternative UI. For example, how do you see all of the changes in a branch (IIRC the equivalent of ‘hg diff -b branch-name’)? How do you see the changes for just one commit (I.e., ‘hg diff -c $commit’). These things are all feasible in git, but I can never remember the incantation, so I have to Google every time. I haven’t used hg in 5 years and I still have an easier time remembering those commands.

samatman 7y ago
The changes for just one commit are `git diff $commit`, while the changes for a branch are `git diff $branch`. While there are a metric ton of things which are confusing about git, this was perhaps not the greatest example.
- jcranmer 7y ago
  `git diff <commit>' is the set of changes since that commit, not the changes of that commit (the distinction between hg diff -r and hg diff -c). Similarly, `git diff <branch>' is the diff between that branch and the current HEAD, not the diff of the branch itself. So perhaps it's a great example if you've gotten it wrong?
  - weberc2 7y ago
    /u/samatman is definitely mistaken, and I think you are correct (although I'm not sure about "the set of changes since that commit"). As far as I can tell, `git diff <commit>` and `git diff <branch>` both just diff your current workspace against the commit/branch respectively. In the case of the branch, the correct result is something like "what has changed since my branch diverged from its parent"--basically what you see in a PR. I think this is unnecessarily obscure in Git because a "branch" isn't really a branch in the git data model; rather it's something like "the tip of the branch". I don't think I've ever wanted to compare my workspace against a branch, but clearly diffing the branch is useful (as evidenced by PRs). Similarly, I'm much less inclined to diff my workspace against a particular commit, but I often want to see the contents of an individual commit (another common operation in the Github UI). In essence, if Github is any indicator, Git's data model is a subpar fit for the VCS use case.
  - samatman 7y ago
    That's fair, insofar as I'm unfamiliar with the mercurial commands. It's unfair insofar as it does what I expect it to, which is to diff between what I'm curious about, and where I am. In other words, if you elide the second argument, it defaults to wherever HEAD is. The point being, this is not something I personally need to look up. I'd venture a guess that your familiarity with hg is interfering because the conventions are different.
    - jcranmer 7y ago
      That brings up a deeper issue with git's philosophy. Git's UI is largely geared to introspecting the repository history only insofar as it exists to the currently existing checkout--commands that interact with history without concerning themselves with the current checkout are far more inscrutable, confusing, and difficult to find. By contrast, Mercurial's UI makes the repository history a more first-class citizen, and it is very easy to answer basic questions about the history of the repository itself. If you're doing any sort of source code archaeology, that functionality is far more valuable than comparing it to the current state: I don't want to know what changed since this 5-year-old patch, I want to know what this 5-year-old patch itself changed to fix an issue.
u801e 7y ago
> How do you see the changes for just one commit (I.e., ‘hg diff -c $commit’). git show <commitish> will show the log message and the diff from the parent commit tree.