5 ms·

Email isn't the only way Git is used. In fact, email is explicitly external to Git; Got just cooperates well with it. You know what else Git cooperates with be

Email isn't the only way Git is used. In fact, email is explicitly external to Git; Got just cooperates well with it. You know what else Git cooperates with better? Push, pull, rebase, squash, a whole world of branching strategies etc. GitHub's PR model is artificially gimped against many useful features of git, to the point where I suspect they actively hate users creating commits and want themselves to be the only ones who can make them. Their PR model actively fights any kind of commit-based review; to the point of erasing access to old, rewritten commits. Even their diff model is proprietary — and inadequate. You can only diff individual files against previous pushes, and that too only if you manually marked each file as 'viewed'. Diff two tips (read: heads)? Forget about it. You can't have it. Do it out dumbed-down PR way, with a pileup of correction commits you can't squash properly, and be happy you were given the privilege.

noway421 5y ago
You can diff two tips like so: https://github.com/{org}/{repo}/compare/{commitish1}..{commitish2} https://github.com/{org}/{repo}/compare/{commitish1}..{commi... Example: https://github.com/facebook/react-native/compare/0.65-stable..0.66-stable https://github.com/facebook/react-native/compare/0.65-stable...
- pritambaral 5y ago
  Those are refs. Not commits. GitHub removes access to the old commits of a branch when the branch is force-pushed (say, after a rebase). I'm interested in comparing the branch in its current state against it's previous state.
  - JelteF 5y ago
    tl;dr you can put commit hashes in the place where the parent comment put tags, and your exact use case actually has a dedicated link on the PR page. The PR interface actually exposes this for force-pushes, but the UI discovery for this is horrible. It turns out that the "force-pushed" part in the little message in the github UI is actually a link. This link points to the diff between the old and the new HEAD of the branch. As an example you can look at this PR: https://github.com/JelteF/derive_more/pull/161 https://github.com/JelteF/derive_more/pull/161 It has this little message somewhere down the page: Monadic-Cat force-pushed the add-unwrap branch from e130dbe to 25235aa 4 months ago If you then click "force-pushed" in that message you go to the "compare" page, which shows the diff between the two commits: https://github.com/JelteF/derive_more/compare/e130dbe6b2a42939245106e9f6934bd903d882ca..25235aaf7714897111969a79f8b63f2c3f8f574e https://github.com/JelteF/derive_more/compare/e130dbe6b2a429... Disclaimer: I'm a Micrsoft employee, but don't work on Github. I'm a daily user of Github though.
    - pritambaral 5y ago
      I have been told this multiple times, and I've tried this too. Maybe it works for public repos, but it doesn't work for private repos.
      - JelteF 5y ago
        Pressing the "force-pushed" link works fine for me on private repos too. It could be that they fixed this recently, I only found out about this feature ~a month ago. If it still does not work on private repos for you, maybe try reaching out for support. It could be that there's some bug you're hitting.
Too 5y ago
Do you have any suggestion for alternative systems, which uses this supposedly "real" git flow, paired with reviews? All the git operations you listed work perfectly fine locally on a repo from github, it's only once you want to push to main you have to go through the review-gate and that's configurable. Gitlab works mostly the same as Github, and for both of them you can configure the merge-strategy and PR requirements per repo. Next competitor in line would be Gerrit with a quite different approach, which is more based on single commits rather than branches and pull-requests, but in a way their refs/for/master is very similar to a PR except it doesn't have a branch-name and you don't need to fork the repo first, but under the hood you could say a patchset on a change is the same as a commit on a branch sent for PR. In the end, they are all the same and you learn to work with it. None of them really fight against the core of git.
- lozenge 5y ago
  Reviewable is an example of a product that put in the extra work to support rebase. Its interface is more complex than GitHub s but that's partly from the rebase support and partly just the decision of their designer.
- pritambaral 5y ago
  > Do you have any suggestion for alternative systems, which uses this supposedly "real" git flow, paired with reviews? GitLab (I know it works, because I set up this workflow in my company). Before GitLab: Phabricator, Gerrit. > All the git operations you listed work perfectly fine locally on a repo from github ... Irrelevant. GitHub needs to be compatible with Git, not the other way around. This subthread began with the assertion that GitHub wants to break that dependence. > Gitlab works mostly the same as Github False. GitLab lets me compare different versions of the same MR against each other. Without extra work. It's right there in the MR diff UI. That's literally what I wanted. > ... for both of them you can configure the merge-strategy and PR requirements per repo. Some configuration allowed. Not the same kinds. GitLab's squash-and-merge strategy actually works, even lets me set the commit message! GitHub built their incomplete implementation of sth similar only recently, to catch up with GitLab, but also stopped half-way. That last bit is what gives rise to the suspicion that started this thread: that GitHub doesn't really want to be Git-compatible and doesn't care about Git. GitLab, OTOH, introduced this feature, a long time ago, because it saw people were already using Git this way. I couldn't accept doing development in my company without some kind of auto-squash support. > which is more based on single commits rather than branches and pull-requests, but in a way their refs/for/master is very similar to a PR except it doesn't have a branch-name Gerrit has branch names, I don't know what you're talking about. In fact, it has better support than GitHub. I can push a locally created branch and ask for the branch to be reviewed, all from the `git` CLI. I can even change the branch name, push the new branch, delete the old branch (on remote, from local `git` CLI) and all of my changes and their reviews remain intact! The equivalent on GitHub would require me to close my current PR and open a whole new one! > and you don't need to fork the repo first This is a good thing. `git clone` is already a fork. I shouldn't have to make two forks, one of them through some external interface, and another through the `git` CLI, just to be able to work on sth. Git's branches are already excellent, there's no need for yet another way to keep separate versions of a repo. > but under the hood you could say a patchset on a change is the same as a commit on a branch sent for PR. No. I think your understanding not Git derives almost entirely, if not predominantly, from GitHub. And this is exactly what we're talking about in this thread. GitHub would like to impose their way of doing things on everyone, irrespective not what better ways exist (and have existed since before GitHub was born). In Gerrit, each change is a commit on a branch. There are versions of commits, each of which is a patchset. This is good and desirable, because it leads to cleaner branches. I like this, I want this, and I've been using this since before GitHub was launched. GitHub's only supported way is to create a commit for every tiny edit, irrespective of whether it's significant enough to be enshrined forever in the final branch as an independent commit of its own. This adds noise. Buncha commits with just the message 'Typo'. Ugh. Imagine running into one of these in a git blame, months later. Imagine looking at a git log. Just ugh. And what's the alternative with GitHub? Squash all commits in a PR into a single one. So now I can't have more than one significant commit in the same PR. Okay, fine, whatever; can I at-least make one PR dependent on another one, like a commit that has a parent? Nope! > In the end, they are all the same and you learn to work with it. As I show above, they're not all the same. Can't learn to work with sth you need that's missing. > None of them really fight against the core of git. If I can just git push and git pull and get all my work done with just that, then yeah, none of them really fight against the core of git. But then why would I use them instead of a headless SSH server? They all fight against Git, in different ways, when they decide to build custom UX for one workflow or the other. They're telling you what workflows they support. If your workflow can't fit into them, well then they can't do the job you want them to. This is why both Gerrit and GitLab were built the way they are today: their users needed a certain workflow (feature) and they cared enough about those users that they grew to support such features. GitHub has ... other users ... it cares about more. Not the power users. But power users also are more likely to be defiant, to resist control.

noway421 5y ago

You can diff two tips like so: https://github.com/{org}/{repo}/compare/{commitish1}..{commitish2} https://github.com/{org}/{repo}/compare/{commitish1}..{commi... Example: https://github.com/facebook/react-native/compare/0.65-stable..0.66-stable https://github.com/facebook/react-native/compare/0.65-stable...

pritambaral 5y ago
Those are refs. Not commits. GitHub removes access to the old commits of a branch when the branch is force-pushed (say, after a rebase). I'm interested in comparing the branch in its current state against it's previous state.
- JelteF 5y ago
  tl;dr you can put commit hashes in the place where the parent comment put tags, and your exact use case actually has a dedicated link on the PR page. The PR interface actually exposes this for force-pushes, but the UI discovery for this is horrible. It turns out that the "force-pushed" part in the little message in the github UI is actually a link. This link points to the diff between the old and the new HEAD of the branch. As an example you can look at this PR: https://github.com/JelteF/derive_more/pull/161 https://github.com/JelteF/derive_more/pull/161 It has this little message somewhere down the page: Monadic-Cat force-pushed the add-unwrap branch from e130dbe to 25235aa 4 months ago If you then click "force-pushed" in that message you go to the "compare" page, which shows the diff between the two commits: https://github.com/JelteF/derive_more/compare/e130dbe6b2a42939245106e9f6934bd903d882ca..25235aaf7714897111969a79f8b63f2c3f8f574e https://github.com/JelteF/derive_more/compare/e130dbe6b2a429... Disclaimer: I'm a Micrsoft employee, but don't work on Github. I'm a daily user of Github though.
  - pritambaral 5y ago
    I have been told this multiple times, and I've tried this too. Maybe it works for public repos, but it doesn't work for private repos.
    - JelteF 5y ago
      Pressing the "force-pushed" link works fine for me on private repos too. It could be that they fixed this recently, I only found out about this feature ~a month ago. If it still does not work on private repos for you, maybe try reaching out for support. It could be that there's some bug you're hitting.

Too 5y ago

Do you have any suggestion for alternative systems, which uses this supposedly "real" git flow, paired with reviews? All the git operations you listed work perfectly fine locally on a repo from github, it's only once you want to push to main you have to go through the review-gate and that's configurable. Gitlab works mostly the same as Github, and for both of them you can configure the merge-strategy and PR requirements per repo. Next competitor in line would be Gerrit with a quite different approach, which is more based on single commits rather than branches and pull-requests, but in a way their refs/for/master is very similar to a PR except it doesn't have a branch-name and you don't need to fork the repo first, but under the hood you could say a patchset on a change is the same as a commit on a branch sent for PR. In the end, they are all the same and you learn to work with it. None of them really fight against the core of git.

lozenge 5y ago
Reviewable is an example of a product that put in the extra work to support rebase. Its interface is more complex than GitHub s but that's partly from the rebase support and partly just the decision of their designer.
pritambaral 5y ago
> Do you have any suggestion for alternative systems, which uses this supposedly "real" git flow, paired with reviews? GitLab (I know it works, because I set up this workflow in my company). Before GitLab: Phabricator, Gerrit. > All the git operations you listed work perfectly fine locally on a repo from github ... Irrelevant. GitHub needs to be compatible with Git, not the other way around. This subthread began with the assertion that GitHub wants to break that dependence. > Gitlab works mostly the same as Github False. GitLab lets me compare different versions of the same MR against each other. Without extra work. It's right there in the MR diff UI. That's literally what I wanted. > ... for both of them you can configure the merge-strategy and PR requirements per repo. Some configuration allowed. Not the same kinds. GitLab's squash-and-merge strategy actually works, even lets me set the commit message! GitHub built their incomplete implementation of sth similar only recently, to catch up with GitLab, but also stopped half-way. That last bit is what gives rise to the suspicion that started this thread: that GitHub doesn't really want to be Git-compatible and doesn't care about Git. GitLab, OTOH, introduced this feature, a long time ago, because it saw people were already using Git this way. I couldn't accept doing development in my company without some kind of auto-squash support. > which is more based on single commits rather than branches and pull-requests, but in a way their refs/for/master is very similar to a PR except it doesn't have a branch-name Gerrit has branch names, I don't know what you're talking about. In fact, it has better support than GitHub. I can push a locally created branch and ask for the branch to be reviewed, all from the `git` CLI. I can even change the branch name, push the new branch, delete the old branch (on remote, from local `git` CLI) and all of my changes and their reviews remain intact! The equivalent on GitHub would require me to close my current PR and open a whole new one! > and you don't need to fork the repo first This is a good thing. `git clone` is already a fork. I shouldn't have to make two forks, one of them through some external interface, and another through the `git` CLI, just to be able to work on sth. Git's branches are already excellent, there's no need for yet another way to keep separate versions of a repo. > but under the hood you could say a patchset on a change is the same as a commit on a branch sent for PR. No. I think your understanding not Git derives almost entirely, if not predominantly, from GitHub. And this is exactly what we're talking about in this thread. GitHub would like to impose their way of doing things on everyone, irrespective not what better ways exist (and have existed since before GitHub was born). In Gerrit, each change is a commit on a branch. There are versions of commits, each of which is a patchset. This is good and desirable, because it leads to cleaner branches. I like this, I want this, and I've been using this since before GitHub was launched. GitHub's only supported way is to create a commit for every tiny edit, irrespective of whether it's significant enough to be enshrined forever in the final branch as an independent commit of its own. This adds noise. Buncha commits with just the message 'Typo'. Ugh. Imagine running into one of these in a git blame, months later. Imagine looking at a git log. Just ugh. And what's the alternative with GitHub? Squash all commits in a PR into a single one. So now I can't have more than one significant commit in the same PR. Okay, fine, whatever; can I at-least make one PR dependent on another one, like a commit that has a parent? Nope! > In the end, they are all the same and you learn to work with it. As I show above, they're not all the same. Can't learn to work with sth you need that's missing. > None of them really fight against the core of git. If I can just git push and git pull and get all my work done with just that, then yeah, none of them really fight against the core of git. But then why would I use them instead of a headless SSH server? They all fight against Git, in different ways, when they decide to build custom UX for one workflow or the other. They're telling you what workflows they support. If your workflow can't fit into them, well then they can't do the job you want them to. This is why both Gerrit and GitLab were built the way they are today: their users needed a certain workflow (feature) and they cared enough about those users that they grew to support such features. GitHub has ... other users ... it cares about more. Not the power users. But power users also are more likely to be defiant, to resist control.