9 ms·

The Biggest and Weirdest Commits in Linux Kernel Git History (2017)

326 points by swsieber 8y ago

zwkrt 8y ago
The article was very interesting, but as a nit the best fit curves in the graphs were questionable. "everything is linear if plotted log-log with a fat magic marker"
- IshKebab 8y ago
  Check the legend.
bipson 8y ago
Now I wonder if the warning suggested by Linus in the linked mail was ever implemented. Did also not know git would not even complain. Does anyone know? (Am on phone, slightly difficult to check).
- ushi 8y ago
  yes. its implemented: --allow-unrelated-histories By default, git merge command refuses to merge histories that do not share a common ancestor. This option can be used to override this safety when merging histories of two projects that started their lives independently. As that is a very rare occasion, no configuration variable to enable this by default exists and will not be added.
  - jwilk 8y ago
    This option was added in git v2.9.0, released on 2016-06-13.
  - gaius 8y ago
    I have used this many times while taking the opportunity to reorganise repos while migrating earlier version control systems to Git. I still need a crib sheet every time tho’!
  - Programmatic 8y ago
    See also the relevant lines in the function he proposed a patch for: https://github.com/git/git/blob/master/builtin/merge.c#L1401 https://github.com/git/git/blob/master/builtin/merge.c#L1401
- superflyguy 8y ago
  What might have happened had you waited until you were off the phone?
  - komali2 8y ago
    He might have forgotten to check, or ask. This reminds me of the last interaction I had on #lesswrong - I openly speculated about the UI of a system I didn't have access to, because I wanted to chat about it with people I generally respected. But some of those people just weren't in a good mood and lambasted me for not simply "googling it for the answer." Never mind that the answer isn't easily found, and never mind that that completely invalidates my whole reason for interpersonal interaction anyway...
    - lainga 8y ago
      Interpersonal interaction on #lesswrong is just wasted time that you could have spent praising the coming machine-god so it won't kill you.
    - kchr 8y ago
      I can relate. Seems that people today has no time for the social part of conversation and the creative effects of speculation. I often stop my friends when they reach for their smartphones in an argument or discussion, so that we can converse without proving facts.
ghostly_s 8y ago
(2017)
- sctb 8y ago
  Thanks! Updated.
fredley 8y ago
I had never heard of Octopus merges, and wondered if they're the reason why the GitHub mascot is Octocat. Turns out they are! http://cameronmcefee.com/work/the-octocat/ http://cameronmcefee.com/work/the-octocat/
- swsieber 8y ago
  I actually found this while researching octopus merge (mostly looking for background info - I'm working on a tool that traverses and replicates modified git repositories), and I realized that it was actually pretty interesting.
- blattimwind 8y ago
  Yet Github never creates octopus merges.
  - hinkley 8y ago
    They have one octopus and don’t want any more?
- cup-of-tea 8y ago
  Yeah it's quite funny given the popularity of github how few people know about octopus merges. I only know about them because I built my own git graph GUI. I was about to hard code in two parents and then wondered if there could be more.
- captn3m0 8y ago
  The mascot was from a stock illustration GitHub used on their 404 page iirc. It grew too popular and GitHub licensed it soon for exclusive use.
teagoat 8y ago
From previous reading of Linus rants, it sounds like they're pretty particular about keeping source code and git history clean. Why didn't they go back and reverse the new root created by the README.md repo?
- cesarb 8y ago
  His rants are also pretty particular about not rewriting published history. As he said on the linked message, "[...] I didn't notice the history screw-up until too late, [...]", so he probably already had pushed to the public "master" branch on the git.kernel.org servers. Once it's there, other kernel developers might already have pulled from it, so trying to rewrite the git history to remove the commit would only lead to an unholy mess (and the offending commit coming back) the next time he merges from them.
  - digi_owl 8y ago
    Honestly his attitude in general seems to be "once live, it stays", no matter if it is git commits, "broken" APIs, or anything really (just check out his recent opinion on the C standard).
  - cesarb 8y ago
    For a sampling of his rants about git history rewriting, see here: https://yarchive.net/comp/linux/git_rebase.html https://yarchive.net/comp/linux/git_rebase.html
  - bostik 8y ago
    I have spent the last 2-3 years educating auditors and after quite some effort, they have learned to appreciate git. To the point where they are now starting to ask some of their other clients why _they_ are not doing something similar. Auditors LOVE immutability. To be fair, git doesn't provide that, but it provides the next-best alternative: tamper detection. If anyone rewrites history, git will show that. The gitrefs between two points in time will not match if anyone has modified data or commits in the meantime. The auditors also have no problem looking at previous years' documents where they have recorded the relevant gitrefs at the time. This has gone so far that this year's policy review was a breeze. Our compliance documentation is maintained in a git repo, with all documents as markdown files. The final documents are simply compiled PDF and HTML artifacts. In 2016, the auditors asked if we can provide snapshots of previous policy versions. In 2017, they already understood that we have everything in git, and knew to ask for clarifications as to when a particular change was done and who had signed it off. This year our auditors literally asked for the latest compliance documentation bundle from CI, all the individual commits, and the overall diff over the year. Wall time spent for policy review: ~20 minutes.
ezoe 8y ago
I probably will never do octopus merge in my entire career.
- y4mi 8y ago
  The giflow concept requires one to verify if a branch can be merged into both targets hotfix/${version} needs to go into develop and master, so you need that tiny octopus merge to verify before starting the process but yeah, incredibly rare.
rraval 8y ago
My startup's monorepo has 2 root commits as well. When the company was first starting out, my co-founder and I created independent git repos. I was writing OCR type research-y code and he was doing more traditional CRUD REST webserver things. When it came time to pull things together, we thought it'd be fun to try and maintain the histories. So I added his repo as a remote and simply merged his unrelated history into mine. Fast forward and now we offer hoodies as swag to anyone who contributes to the repo. We personalize the hoodie with your git username, the truncated commit hash of your first commit, and the number of parent commits to your first commit. Having 2 root commits means that both my cofounder and I have hoodies with a large 0 as number of parent commits. Just a nice way to commemorate this accident of history :)
- kirubakaran 8y ago
  That's a fantastic idea. Do you have any photos of the hoodies?
  - rraval 8y ago
    Yep, here's one: https://i.imgur.com/LEI4BAA.jpg https://i.imgur.com/LEI4BAA.jpg It makes for a great conversation piece, even around non-tech crowds.
- BillinghamJ 8y ago
  My company got to ~20 services in separated repos prior to moving them all into one monorepo, so we've ended up with 20 root commits and an enormous commit graph around the time where it all converged together. We did do them all separately though - rather than as an octopus merge. Has been particularly interesting to balance the different languages in the same repo. Few painful bits, but overall has worked out really well. We also build the entire thing into a single Docker container containing every service. You just start the particular one you want via the command (the entrypoint is a little shell script to invoke the correct executable).
  - cup-of-tea 8y ago
    What's the advantage of having all that in one repository? And what's the advantage of provisioning every container with functionality it will never need?
focal-point 8y ago
I'd love to read a book on git wizardry that goes beyond the git book. Manishearth, a Mozillian and Rust contributor, wrote this post on splitting apart a repo. He's good at explaining all sorts of things. https://manishearth.github.io/blog/2017/03/05/understanding-git-filter-branch/ https://manishearth.github.io/blog/2017/03/05/understanding-...
hartator 8y ago
Despite having used Git on a daily basis since more than 5 years, I still have trouble using it, and have to Google things almost everytime I need something a but out of the ordinary.
- noir_lord 8y ago
  About the same length of time and I still have to google it. While technically git is great, usability wise its not (for me). I've joke it's the source control version of stockholm syndrome before.
  - jexah 8y ago
    I know I'm not contributing to the discussion (sue me), but I just had to let you know that that last sentence made me chuckle.
- Maakuth 8y ago
  I recommend having a frontend like SourceTree for git - it uses bare git underneath so the end result and even the state in your working copy will be just the same, but you'll have better picture of what is happening. As the working copy changes in identical way to the use of the command line git, it neatly works as a scaffolding for your learning. You can use the command line client for the stuff you are comfortable with and then resort to the GUI when you get into trouble. This way you can shortcut your learning, provided that you want to learn to use the command line git. Nothing wrong with staying with the GUI forever though.
  - jexah 8y ago
    I use GitKracken, I love it. SourceTree kept crashing :( Anyway, my comment is that I still need to use CLI for some things, ie. Git merge squash, so while the GUI apps are good learning tools for git in general, you still need to Google things for CLI consumption if the GUI doesn't support it and you're not a git expert.
  - Zigurd 8y ago
    Toolchains are plagued by pseudo-GUIs - graphical overlays that don't actually abstract a CLI. Git is perhaps the most resistant thing ever to GUI-izing. I don't believe it can be done in a way that doesn't disappoint.
ericfrederich 8y ago
Visualization of octopus merge with 66 parents: https://imgur.com/gallery/oiWeZmm https://imgur.com/gallery/oiWeZmm Run this: git log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' 2cde51fbd0f3
djsumdog 8y ago
I find rebasing can get so insane that most of the times, when I'm ready to submit a pull/merge request to master, I create a whole new branch from master, cherry-pick all my commits in order, rebase -i and squash them if I need to, and then push the branch/create a PR/MR. I find this looks a lot cleaner in tools like Gitlab/Bitbucket as well.
- philsnow 8y ago
  Sounds like you're duplicating work? "git rebase -i master" does pretty much that: starting from master, cherry picks all the commits (in order by default but because you're doing -i you can reorder them, likewise you can omit or amend) and then changes the ref of the branch you were working on to point at the resulting tip commit. I don't think you need to explicitly check out a new branch and then cherry pick.
  - kazinator 8y ago
    I.e. you already have not only a "whole new branch from master" but two of them: a remote tracking branch origin/master, and a local master related to it. You don't need a third one.
- spockz 8y ago
  Is there a way so you can rebase and push without breaking everyone who already pulled your repo? I have this issue continuously when using rebase on branches that have gitlab or github merge/pull requests. I need to create a different branch all of the time.
  - ereyes01 8y ago
    You can always define a new branch pointing to your new rebased ref and push/PR that to avoid having to force-push and messing everyone up.
  - cesarb 8y ago
    You aren't supposed to rewrite history (which is what rebase does) on which other people are basing work. If people have merge/pull requests on your branch, then people are basing work on your branch, and you shouldn't rewrite it. The best approach (which is what git.git itself uses) is to do the work on a separate branch, which is rebased often; once it's moved to the master branch, it's "frozen" and won't be rebased anymore. All pull requests are based on the master branch, so aren't affected by the constant rebases on the development branch. (Actually, all the work is done on topic branches, what's often rebased/rewritten is a sequence of merges of these topic branches into the master branch.)
chx 8y ago
> (Update: it was an accident, which Linus responded to in his usual fashion.) This jab at Linus is unfounded, he have replied calmly and professionally.
- LukeShu 8y ago
  As I wrote the last time this came up: ---- Those who only know Linus from his rants might be surprised that here "his usual fashion" means: - Acknowledging that the root cause was Github's documentation being misleading. - Not blaming the contributor for being mislead by Github: "I can see why that documentation would make you think it's the right thing to do." - Admit that the ease with which the accident happened is a deficiency in Git's UI. - CC the Git maintainer to discuss improving Git to make it harder to do this by accident. (Which eventually lead to the --allow-unrelated-histories flag being needed to do this kind of merge.)
- ajuc 8y ago
  Calling calm and professional response "his usual fashion" isn't a jab :)
  - chx 8y ago
    All too often people call Linus' rare passionate rants "his usual fashion".
    - hermitdev 8y ago
      I had the photo of Linus flipping the bird to NVIDIA as my desktop wallpaper for quite a while at a previous job. Used it as a reminder not to commit something stupid (not to Linux - the internal project I was working on at the time).
    - jlarocco 8y ago
      > rare passionate rants Wow, that's a really charitable way of spinning them.
- bambataa 8y ago
selljamhere 8y ago
>> It's pulled, and it's fine, but there's clearly a balance between "octopus merges are fine" and "Christ, that's not an octopus, that's a Cthulhu merge". This made me chuckle.
thefifthsetpin 8y ago
I had a modular laravel app where each laravel module was a git submodule. Eventually we put all of those submodules into the same git repository, so we then had had n+1 root commits for our n module laravel project. It worked well until someone ran an accidental `git merge` of one of the submodules into the main project which sewed a bunch of confusion. After that point the practice was banned where I worked. Nice to know that git added a flag to prevent that, though at this point git have also added a subtree command which I think removes the need for our hack.
- carapace 8y ago
  *sow
  - thefifthsetpin 8y ago
    Thanks.
YeGoblynQueenne 8y ago
If I may- I think the first graph would look better as a histogram, with a smooth polynomial on top. It's hard to see the long-tailed shape in a scatter plot.
chrismorgan 8y ago
Just recently I started doing octopus merges regularly, though they won’t ever make it onto master. The situation is where you deploy from a particular ref in git, and have a beta environment; I’ll often want to have unrelated things that are sitting on beta for a while, either because they’re long-running work or because I’ve fixed something but the change hasn’t been reviewed and merged yet. My beta branch is then just an octopus merge of all the feature branches I’m working on at present and want included in the beta environment. That way I am not limited to just one thing on beta at a time, or worrying about maintaining a beta branch as well as the feature branch. It has been very liberating. I’ve built a fairly simple tool that tracks which branches to merge into my beta branch and automates its regeneration, and I’m polishing it up so it is distributable and can just be a regular Git subcommand, git-managed-branch. What I have already is useful to me, and I think it’d be useful for many others as well. The essence of the work of the script I have at present boils down to this: git stash # (if necessary) git checkout --no-track -B origin/master staging git merge --no-edit feature1 feature2 fix3 fix4 git push --force git checkout - git stash pop # (if necessary)

326 points by swsieber 8y ago

The article was very interesting, but as a nit the best fit curves in the graphs were questionable. "everything is linear if plotted log-log with a fat magic marker"

IshKebab 8y ago
Check the legend.

bipson 8y ago

Now I wonder if the warning suggested by Linus in the linked mail was ever implemented. Did also not know git would not even complain. Does anyone know? (Am on phone, slightly difficult to check).

ushi 8y ago
yes. its implemented: --allow-unrelated-histories By default, git merge command refuses to merge histories that do not share a common ancestor. This option can be used to override this safety when merging histories of two projects that started their lives independently. As that is a very rare occasion, no configuration variable to enable this by default exists and will not be added.
- jwilk 8y ago
  This option was added in git v2.9.0, released on 2016-06-13.
- gaius 8y ago
  I have used this many times while taking the opportunity to reorganise repos while migrating earlier version control systems to Git. I still need a crib sheet every time tho’!
- Programmatic 8y ago
  See also the relevant lines in the function he proposed a patch for: https://github.com/git/git/blob/master/builtin/merge.c#L1401 https://github.com/git/git/blob/master/builtin/merge.c#L1401
superflyguy 8y ago
What might have happened had you waited until you were off the phone?
- komali2 8y ago
  He might have forgotten to check, or ask. This reminds me of the last interaction I had on #lesswrong - I openly speculated about the UI of a system I didn't have access to, because I wanted to chat about it with people I generally respected. But some of those people just weren't in a good mood and lambasted me for not simply "googling it for the answer." Never mind that the answer isn't easily found, and never mind that that completely invalidates my whole reason for interpersonal interaction anyway...
  - lainga 8y ago
    Interpersonal interaction on #lesswrong is just wasted time that you could have spent praising the coming machine-god so it won't kill you.
  - kchr 8y ago
    I can relate. Seems that people today has no time for the social part of conversation and the creative effects of speculation. I often stop my friends when they reach for their smartphones in an argument or discussion, so that we can converse without proving facts.

ghostly_s 8y ago

(2017)

sctb 8y ago
Thanks! Updated.

fredley 8y ago

I had never heard of Octopus merges, and wondered if they're the reason why the GitHub mascot is Octocat. Turns out they are! http://cameronmcefee.com/work/the-octocat/ http://cameronmcefee.com/work/the-octocat/

swsieber 8y ago
I actually found this while researching octopus merge (mostly looking for background info - I'm working on a tool that traverses and replicates modified git repositories), and I realized that it was actually pretty interesting.
blattimwind 8y ago
Yet Github never creates octopus merges.
- hinkley 8y ago
  They have one octopus and don’t want any more?
cup-of-tea 8y ago
Yeah it's quite funny given the popularity of github how few people know about octopus merges. I only know about them because I built my own git graph GUI. I was about to hard code in two parents and then wondered if there could be more.
captn3m0 8y ago
The mascot was from a stock illustration GitHub used on their 404 page iirc. It grew too popular and GitHub licensed it soon for exclusive use.

teagoat 8y ago

From previous reading of Linus rants, it sounds like they're pretty particular about keeping source code and git history clean. Why didn't they go back and reverse the new root created by the README.md repo?

cesarb 8y ago
His rants are also pretty particular about not rewriting published history. As he said on the linked message, "[...] I didn't notice the history screw-up until too late, [...]", so he probably already had pushed to the public "master" branch on the git.kernel.org servers. Once it's there, other kernel developers might already have pulled from it, so trying to rewrite the git history to remove the commit would only lead to an unholy mess (and the offending commit coming back) the next time he merges from them.
- digi_owl 8y ago
  Honestly his attitude in general seems to be "once live, it stays", no matter if it is git commits, "broken" APIs, or anything really (just check out his recent opinion on the C standard).
- cesarb 8y ago
  For a sampling of his rants about git history rewriting, see here: https://yarchive.net/comp/linux/git_rebase.html https://yarchive.net/comp/linux/git_rebase.html
- bostik 8y ago
  I have spent the last 2-3 years educating auditors and after quite some effort, they have learned to appreciate git. To the point where they are now starting to ask some of their other clients why _they_ are not doing something similar. Auditors LOVE immutability. To be fair, git doesn't provide that, but it provides the next-best alternative: tamper detection. If anyone rewrites history, git will show that. The gitrefs between two points in time will not match if anyone has modified data or commits in the meantime. The auditors also have no problem looking at previous years' documents where they have recorded the relevant gitrefs at the time. This has gone so far that this year's policy review was a breeze. Our compliance documentation is maintained in a git repo, with all documents as markdown files. The final documents are simply compiled PDF and HTML artifacts. In 2016, the auditors asked if we can provide snapshots of previous policy versions. In 2017, they already understood that we have everything in git, and knew to ask for clarifications as to when a particular change was done and who had signed it off. This year our auditors literally asked for the latest compliance documentation bundle from CI, all the individual commits, and the overall diff over the year. Wall time spent for policy review: ~20 minutes.

ezoe 8y ago

I probably will never do octopus merge in my entire career.

y4mi 8y ago
The giflow concept requires one to verify if a branch can be merged into both targets hotfix/${version} needs to go into develop and master, so you need that tiny octopus merge to verify before starting the process but yeah, incredibly rare.

rraval 8y ago

My startup's monorepo has 2 root commits as well. When the company was first starting out, my co-founder and I created independent git repos. I was writing OCR type research-y code and he was doing more traditional CRUD REST webserver things. When it came time to pull things together, we thought it'd be fun to try and maintain the histories. So I added his repo as a remote and simply merged his unrelated history into mine. Fast forward and now we offer hoodies as swag to anyone who contributes to the repo. We personalize the hoodie with your git username, the truncated commit hash of your first commit, and the number of parent commits to your first commit. Having 2 root commits means that both my cofounder and I have hoodies with a large 0 as number of parent commits. Just a nice way to commemorate this accident of history :)

kirubakaran 8y ago
That's a fantastic idea. Do you have any photos of the hoodies?
- rraval 8y ago
  Yep, here's one: https://i.imgur.com/LEI4BAA.jpg https://i.imgur.com/LEI4BAA.jpg It makes for a great conversation piece, even around non-tech crowds.
BillinghamJ 8y ago
My company got to ~20 services in separated repos prior to moving them all into one monorepo, so we've ended up with 20 root commits and an enormous commit graph around the time where it all converged together. We did do them all separately though - rather than as an octopus merge. Has been particularly interesting to balance the different languages in the same repo. Few painful bits, but overall has worked out really well. We also build the entire thing into a single Docker container containing every service. You just start the particular one you want via the command (the entrypoint is a little shell script to invoke the correct executable).
- cup-of-tea 8y ago
  What's the advantage of having all that in one repository? And what's the advantage of provisioning every container with functionality it will never need?

focal-point 8y ago

I'd love to read a book on git wizardry that goes beyond the git book. Manishearth, a Mozillian and Rust contributor, wrote this post on splitting apart a repo. He's good at explaining all sorts of things. https://manishearth.github.io/blog/2017/03/05/understanding-git-filter-branch/ https://manishearth.github.io/blog/2017/03/05/understanding-...

hartator 8y ago

Despite having used Git on a daily basis since more than 5 years, I still have trouble using it, and have to Google things almost everytime I need something a but out of the ordinary.

noir_lord 8y ago
About the same length of time and I still have to google it. While technically git is great, usability wise its not (for me). I've joke it's the source control version of stockholm syndrome before.
- jexah 8y ago
  I know I'm not contributing to the discussion (sue me), but I just had to let you know that that last sentence made me chuckle.
Maakuth 8y ago
I recommend having a frontend like SourceTree for git - it uses bare git underneath so the end result and even the state in your working copy will be just the same, but you'll have better picture of what is happening. As the working copy changes in identical way to the use of the command line git, it neatly works as a scaffolding for your learning. You can use the command line client for the stuff you are comfortable with and then resort to the GUI when you get into trouble. This way you can shortcut your learning, provided that you want to learn to use the command line git. Nothing wrong with staying with the GUI forever though.
- jexah 8y ago
  I use GitKracken, I love it. SourceTree kept crashing :( Anyway, my comment is that I still need to use CLI for some things, ie. Git merge squash, so while the GUI apps are good learning tools for git in general, you still need to Google things for CLI consumption if the GUI doesn't support it and you're not a git expert.
- Zigurd 8y ago
  Toolchains are plagued by pseudo-GUIs - graphical overlays that don't actually abstract a CLI. Git is perhaps the most resistant thing ever to GUI-izing. I don't believe it can be done in a way that doesn't disappoint.

ericfrederich 8y ago

Visualization of octopus merge with 66 parents: https://imgur.com/gallery/oiWeZmm https://imgur.com/gallery/oiWeZmm Run this: git log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' 2cde51fbd0f3

djsumdog 8y ago

I find rebasing can get so insane that most of the times, when I'm ready to submit a pull/merge request to master, I create a whole new branch from master, cherry-pick all my commits in order, rebase -i and squash them if I need to, and then push the branch/create a PR/MR. I find this looks a lot cleaner in tools like Gitlab/Bitbucket as well.

philsnow 8y ago
Sounds like you're duplicating work? "git rebase -i master" does pretty much that: starting from master, cherry picks all the commits (in order by default but because you're doing -i you can reorder them, likewise you can omit or amend) and then changes the ref of the branch you were working on to point at the resulting tip commit. I don't think you need to explicitly check out a new branch and then cherry pick.
- kazinator 8y ago
  I.e. you already have not only a "whole new branch from master" but two of them: a remote tracking branch origin/master, and a local master related to it. You don't need a third one.
spockz 8y ago
Is there a way so you can rebase and push without breaking everyone who already pulled your repo? I have this issue continuously when using rebase on branches that have gitlab or github merge/pull requests. I need to create a different branch all of the time.
- ereyes01 8y ago
  You can always define a new branch pointing to your new rebased ref and push/PR that to avoid having to force-push and messing everyone up.
- cesarb 8y ago
  You aren't supposed to rewrite history (which is what rebase does) on which other people are basing work. If people have merge/pull requests on your branch, then people are basing work on your branch, and you shouldn't rewrite it. The best approach (which is what git.git itself uses) is to do the work on a separate branch, which is rebased often; once it's moved to the master branch, it's "frozen" and won't be rebased anymore. All pull requests are based on the master branch, so aren't affected by the constant rebases on the development branch. (Actually, all the work is done on topic branches, what's often rebased/rewritten is a sequence of merges of these topic branches into the master branch.)

chx 8y ago

> (Update: it was an accident, which Linus responded to in his usual fashion.) This jab at Linus is unfounded, he have replied calmly and professionally.

LukeShu 8y ago
As I wrote the last time this came up: ---- Those who only know Linus from his rants might be surprised that here "his usual fashion" means: - Acknowledging that the root cause was Github's documentation being misleading. - Not blaming the contributor for being mislead by Github: "I can see why that documentation would make you think it's the right thing to do." - Admit that the ease with which the accident happened is a deficiency in Git's UI. - CC the Git maintainer to discuss improving Git to make it harder to do this by accident. (Which eventually lead to the --allow-unrelated-histories flag being needed to do this kind of merge.)
ajuc 8y ago
Calling calm and professional response "his usual fashion" isn't a jab :)
- chx 8y ago
  All too often people call Linus' rare passionate rants "his usual fashion".
  - hermitdev 8y ago
    I had the photo of Linus flipping the bird to NVIDIA as my desktop wallpaper for quite a while at a previous job. Used it as a reminder not to commit something stupid (not to Linux - the internal project I was working on at the time).
  - jlarocco 8y ago
    > rare passionate rants Wow, that's a really charitable way of spinning them.
bambataa 8y ago

selljamhere 8y ago

>> It's pulled, and it's fine, but there's clearly a balance between "octopus merges are fine" and "Christ, that's not an octopus, that's a Cthulhu merge". This made me chuckle.

thefifthsetpin 8y ago

I had a modular laravel app where each laravel module was a git submodule. Eventually we put all of those submodules into the same git repository, so we then had had n+1 root commits for our n module laravel project. It worked well until someone ran an accidental `git merge` of one of the submodules into the main project which sewed a bunch of confusion. After that point the practice was banned where I worked. Nice to know that git added a flag to prevent that, though at this point git have also added a subtree command which I think removes the need for our hack.

carapace 8y ago
*sow
- thefifthsetpin 8y ago
  Thanks.

YeGoblynQueenne 8y ago

If I may- I think the first graph would look better as a histogram, with a smooth polynomial on top. It's hard to see the long-tailed shape in a scatter plot.

chrismorgan 8y ago

Just recently I started doing octopus merges regularly, though they won’t ever make it onto master. The situation is where you deploy from a particular ref in git, and have a beta environment; I’ll often want to have unrelated things that are sitting on beta for a while, either because they’re long-running work or because I’ve fixed something but the change hasn’t been reviewed and merged yet. My beta branch is then just an octopus merge of all the feature branches I’m working on at present and want included in the beta environment. That way I am not limited to just one thing on beta at a time, or worrying about maintaining a beta branch as well as the feature branch. It has been very liberating. I’ve built a fairly simple tool that tracks which branches to merge into my beta branch and automates its regeneration, and I’m polishing it up so it is distributable and can just be a regular Git subcommand, git-managed-branch. What I have already is useful to me, and I think it’d be useful for many others as well. The essence of the work of the script I have at present boils down to this: git stash # (if necessary) git checkout --no-track -B origin/master staging git merge --no-edit feature1 feature2 fix3 fix4 git push --force git checkout - git stash pop # (if necessary)