4 ms·

But the PRs aren't part of your git repository? IMO a git repository should be self contained and not require a hosted provide to give context. It lets you mana

But the PRs aren't part of your git repository? IMO a git repository should be self contained and not require a hosted provide to give context. It lets you manage your work with superior local tooling and without a browser running. Basically I take the exact opposite approach where my PRs are always just a short summary of the commit messages and provides a place for me to put the github specific things like the "Fixes #..". But I make sure my commits are a clean artifact of the changeset by themselves (ie. I do any squashing, etc, on them outside of the PR).

mwt 5y ago
GitHub (by default) uses the name of the PR as the merge commit message and also includes the commit message of each commit in the log. Having whitespace-altering "Dummy commit to trigger CI, ugh!" commits in a git history isn't good but it still clutters the `git log` with stock squash+merge GitHub use. I can't speak for everybody, but if GitHub goes down completely and I only had access to my git logs, I'd struggle to recreate ~20% of the information scattered across issues and PRs. This issue is external to merging preferences, but it's definitely not solved by squash-merges and descriptive merge messages.
- shagie 5y ago
  > Having whitespace-altering "Dummy commit to trigger CI, ugh!" `git commit --allow-empty` may be sufficient for that "there is a new commit" trigger in many cases. If so, that may be preferable to whitespace changes as those clutter up the blame. As an aside, my initial commit on a repo is an empty one so that I can branch from a completely empty repo to do radical rewrites and yet maintain a history relationship with that initial empty commit (which I feel is preferable to an orphan branch and then a merge with unrelated histories ... though those tell slightly different stories in the log).
  - stormbrew 5y ago
    > As an aside, my initial commit on a repo is an empty one so that I can branch from a completely empty repo to do radical rewrites and yet maintain a history relationship with that initial empty commit (which I feel is preferable to an orphan branch and then a merge with unrelated histories ... though those tell slightly different stories in the log). Oh cool, I thought I was literally the only person on the planet to do this lol. I'd do it for branchpoints too except git rebase by default acts very poorly with empty commits in the edited history (deletes them). I wish this was normalized (ie. there was a flag to `git init` to add a commit message for a root commit).
    - rectang 5y ago
      Starting a repo with an empty commit is a cool idea. My first commit has been "Add empty README" since forever, but I like your way better and I'm going to start doing that.
  - mwt 5y ago
    Yep, `--allow-empty` is my preferred solution. It's unfortunately not up to me how other people choose to do this
- stormbrew 5y ago
  > Having whitespace-altering "Dummy commit to trigger CI, ugh!" commits in a git history isn't good but it still clutters the `git log` with stock squash+merge GitHub use. The frustrating thing about this is that this "omg minor commits on a merged branch clutter up the log!" is entirely a UI problem created by github's naive view of history where it shows things in a bafflingly obtuse linear order instead of letting you do something like `--first-parent` like the command line client lets you do. Git itself has more than enough tools to give you that 'squashed' view without actually squashing anything, github just has no interest in providing it to you for whatever reason. Also yes to the sibling comment that if you want to make something happen with a commit use `--allow-empty` and not "bump number" or "add random whitespace". Please.
  - slaymaker1907 5y ago
    It would also help if people were better about keeping a clean commit history for PRs. Ideally, a new commit should only get pushed to a branch per change relevant for reviewers. If the CI is causing the error, people should work on a temporary branch and resolve it there first before cherry picking things over into the PR branch (after rebasing the intermediate commits on the temp branch). Rebasing is a really nice tool, though I think the UI is really lacking. A simple GUI for interactive rebasing would help a lot. Most clients I've used (which isn't a ton since I generally prefer the CLI) don't even have an option for rebasing at all.
    - gregmac 5y ago
      GitKracken and Fork both have an excellent rebase UI.
    - travbrack 5y ago
      Love the sub-branch idea. I'm going to use that.
  - mwt 5y ago
    > github's naive view of history where it shows things in a bafflingly obtuse linear This hits home, it pretty much describes how I visualize logs in my head (compared to the visualizations I see that are more 2-D, branching off and merging together, etc.). I have a hard time working with some of the more advanced features because of this, and it'll probably always be an uphill battle to shift my thinking from linear to not-so-linear ...
- mewse 5y ago
  Wait, can people really not just go into their CI systems and click a “build again” button? People actually insert ‘dummy’ commits to trigger builds? I’ve been using Concourse to run my CI for years and years and just sort of assumed that “build again” was such basic functionality that every other CI system would also have it.
mdoms 5y ago
I do 99% of my coding at work. At work we have Gitlab, Confluence and Jira and these all already contains mountains of context for all of our work. Pretending this context doesn't exist and storing it all in a Git repository isn't helpful.
- lelandbatey 5y ago
  I also do my coding at work, with Gitlab/Github, Confluence and Jira. And yet, due to various leadership decisions and technical migrations over the years, we have lost huge piles of records due to migrating work trackers, document stores, and VCS hosts (e.g. Unknown -> Jira -> Pivotal Tracker -> Jira). Due to these crappy migrations, we don't have old merge requests, old wiki documents, and even some old repositories. Sure, it's possible to find those in old archives sitting in an S3 bucket if I were to take a couple days, but they're not 'at my fingertips'. What is at my fingertips though? All the git commits of every repository that we still have. Which means that the only thing that's actually endured has been the commits. So, on behalf of folks 5-20 years from now who'll be scrutinizing your work, please put the context into the repo directly since it's the only thing that'll stick around.
- eikenberry 5y ago
  I'm speaking of coding in a larger context then... Where it can exist outside of the limits of a single company and a single team. In those sort of cases no, it doesn't really matter where you keep the history. It is a business decision and it is up to the business to decide to switch providers and absorb the loss. I'm speaking of code that others will read. Maybe it is free software, maybe it is proprietary but shared by a larger team, maybe you are writing for customers... any way about it, if the code is to be maintained and read again over time the development history should be captured by a revision management tool like git.

mwt 5y ago

GitHub (by default) uses the name of the PR as the merge commit message and also includes the commit message of each commit in the log. Having whitespace-altering "Dummy commit to trigger CI, ugh!" commits in a git history isn't good but it still clutters the `git log` with stock squash+merge GitHub use. I can't speak for everybody, but if GitHub goes down completely and I only had access to my git logs, I'd struggle to recreate ~20% of the information scattered across issues and PRs. This issue is external to merging preferences, but it's definitely not solved by squash-merges and descriptive merge messages.

shagie 5y ago
> Having whitespace-altering "Dummy commit to trigger CI, ugh!" `git commit --allow-empty` may be sufficient for that "there is a new commit" trigger in many cases. If so, that may be preferable to whitespace changes as those clutter up the blame. As an aside, my initial commit on a repo is an empty one so that I can branch from a completely empty repo to do radical rewrites and yet maintain a history relationship with that initial empty commit (which I feel is preferable to an orphan branch and then a merge with unrelated histories ... though those tell slightly different stories in the log).
- stormbrew 5y ago
  > As an aside, my initial commit on a repo is an empty one so that I can branch from a completely empty repo to do radical rewrites and yet maintain a history relationship with that initial empty commit (which I feel is preferable to an orphan branch and then a merge with unrelated histories ... though those tell slightly different stories in the log). Oh cool, I thought I was literally the only person on the planet to do this lol. I'd do it for branchpoints too except git rebase by default acts very poorly with empty commits in the edited history (deletes them). I wish this was normalized (ie. there was a flag to `git init` to add a commit message for a root commit).
  - rectang 5y ago
    Starting a repo with an empty commit is a cool idea. My first commit has been "Add empty README" since forever, but I like your way better and I'm going to start doing that.
- mwt 5y ago
  Yep, `--allow-empty` is my preferred solution. It's unfortunately not up to me how other people choose to do this
stormbrew 5y ago
> Having whitespace-altering "Dummy commit to trigger CI, ugh!" commits in a git history isn't good but it still clutters the `git log` with stock squash+merge GitHub use. The frustrating thing about this is that this "omg minor commits on a merged branch clutter up the log!" is entirely a UI problem created by github's naive view of history where it shows things in a bafflingly obtuse linear order instead of letting you do something like `--first-parent` like the command line client lets you do. Git itself has more than enough tools to give you that 'squashed' view without actually squashing anything, github just has no interest in providing it to you for whatever reason. Also yes to the sibling comment that if you want to make something happen with a commit use `--allow-empty` and not "bump number" or "add random whitespace". Please.
- slaymaker1907 5y ago
  It would also help if people were better about keeping a clean commit history for PRs. Ideally, a new commit should only get pushed to a branch per change relevant for reviewers. If the CI is causing the error, people should work on a temporary branch and resolve it there first before cherry picking things over into the PR branch (after rebasing the intermediate commits on the temp branch). Rebasing is a really nice tool, though I think the UI is really lacking. A simple GUI for interactive rebasing would help a lot. Most clients I've used (which isn't a ton since I generally prefer the CLI) don't even have an option for rebasing at all.
  - gregmac 5y ago
    GitKracken and Fork both have an excellent rebase UI.
  - travbrack 5y ago
    Love the sub-branch idea. I'm going to use that.
- mwt 5y ago
  > github's naive view of history where it shows things in a bafflingly obtuse linear This hits home, it pretty much describes how I visualize logs in my head (compared to the visualizations I see that are more 2-D, branching off and merging together, etc.). I have a hard time working with some of the more advanced features because of this, and it'll probably always be an uphill battle to shift my thinking from linear to not-so-linear ...
mewse 5y ago
Wait, can people really not just go into their CI systems and click a “build again” button? People actually insert ‘dummy’ commits to trigger builds? I’ve been using Concourse to run my CI for years and years and just sort of assumed that “build again” was such basic functionality that every other CI system would also have it.

mdoms 5y ago

I do 99% of my coding at work. At work we have Gitlab, Confluence and Jira and these all already contains mountains of context for all of our work. Pretending this context doesn't exist and storing it all in a Git repository isn't helpful.

lelandbatey 5y ago
I also do my coding at work, with Gitlab/Github, Confluence and Jira. And yet, due to various leadership decisions and technical migrations over the years, we have lost huge piles of records due to migrating work trackers, document stores, and VCS hosts (e.g. Unknown -> Jira -> Pivotal Tracker -> Jira). Due to these crappy migrations, we don't have old merge requests, old wiki documents, and even some old repositories. Sure, it's possible to find those in old archives sitting in an S3 bucket if I were to take a couple days, but they're not 'at my fingertips'. What is at my fingertips though? All the git commits of every repository that we still have. Which means that the only thing that's actually endured has been the commits. So, on behalf of folks 5-20 years from now who'll be scrutinizing your work, please put the context into the repo directly since it's the only thing that'll stick around.
eikenberry 5y ago
I'm speaking of coding in a larger context then... Where it can exist outside of the limits of a single company and a single team. In those sort of cases no, it doesn't really matter where you keep the history. It is a business decision and it is up to the business to decide to switch providers and absorb the loss. I'm speaking of code that others will read. Maybe it is free software, maybe it is proprietary but shared by a larger team, maybe you are writing for customers... any way about it, if the code is to be maintained and read again over time the development history should be captured by a revision management tool like git.