5 ms·

We had a similar rotation on Chrome team for merges from WebKit (pre fork), and it was similarly a lot of work and clunky tooling! A few times in my career (in

by evmar 4y ago

We had a similar rotation on Chrome team for merges from WebKit (pre fork), and it was similarly a lot of work and clunky tooling! A few times in my career (including this one) I have thought, "We are sure going to a lot of effort to maintain a modified copy of that code while also preserving our changes atop it as we sync, and this is exactly the kind of workflow that Git was designed to enable." Like, the Linux kernel dev workflow is all about different maintainers maintaining different branches and merging between them, and that is where Git comes from. So in a setting other than Chrome I have tried out using Git to try to manage these sorts of situation. I have found in practice many engineers aren't comfortable enough with Git to have it end up helping them out tooling-wise. This is disappointing but also not too unexpected given Git's UI.

taberiand 4y ago
I don't understand any developer's that aren't willing to put in the time to learn how to use Git - to me, it's the single greatest tool available to enable productivity and confidence in changing code. There's no shame in using any one of the many GUI interfaces for Git that make the process simple and intuitive but even with the CLI, there are only a small handful of commands that I regularly need to use to do all the work of managing branches, merges, rebases and resets; and a lot of the time, there's more than one way to do any particular operation.
- evmar 4y ago
  To be clear, I think many developers are comfortable enough with the small handful of commands most regularly use. For the more advanced case of maintaining a fork of a high-velocity codebase like WebKit, it's likely you'll need a deeper understanding of remotes and how to manage complex rebases, especially in the presence of lots of conflicts. And possibly some fancier tools like git-subtree. In particular in WebKit my recollection was it was common to patch something locally and eventually take it upstream, but after upstream's requested modifications the patch would eventually come back around and conflict with itself.
- solarkraft 4y ago
  I'm totally willing to learn the magic of advanced merging, but most "tell me more about Git" talks/articles rather want to tell me more about its general internal structure, which I find very far removed from actually using it. So what's the best resource for learning more about using Git?
  - rascul 4y ago
    https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2
  - LegionMammal978 4y ago
    Personally, I found https://learngitbranching.js.org/ https://learngitbranching.js.org/ surprisingly helpful for getting a mental model of Git usage, even though I had already been using Git for a couple years. As always with learning resources, YMMV.
- saagarjha 4y ago
  > I don't understand any developer's that aren't willing to put in the time to learn how to use Git Other version control systems exist. Why learn Git if you’ve already got one that works?
  - acdha 4y ago
    In this case, was it really working? It sounds like they had enough friction to make considering alternatives reasonable. In general, I agree with your point but I think there's a very pragmatic argument that the open source world heavily converging on Git means it's worth knowing even if it's not your primary tool. In the 2000s that was spread out more with CVS, SVN, Mercurial, etc. also being good candidates depending on what communities you worked in but it's been quite a while since I've seen even Mercurial being used in the wild.
- filmgirlcw 4y ago
  > I don't understand any developer's that aren't willing to put in the time to learn how to use Git It’s not like git invented version control or even distributed version control. Stuff predated git and git wasn’t even the only solution that was coded together when BitKeeper changed license terms (personally, I wish Mercurial had won because it has a much better interface, but what won won and I’m happy enough with git to not really care). Putting all that aside, systems and codebases have their own workflows for a reason. I’m sure the reason WebKit was on SVN for so long wasn’t because the committers weren’t willing to use git (we’ve seen in this comment thread revelations by former Apple engineers who admit that they maintained a shadow git-based codebase internally), I’m sure almost everyone involved uses git. But for whatever reason, there were blockers to migrating (and some of those are explained in the WebKit blog). Now, as an outsider, I might think that waiting this long to migrate to git, a solid decade after it made sense to do so, is odd. But I don’t have the context. I don’t know the reasons why, and for what it’s worth, the git-svn mirrors seemed to be working well for the people working on the project. WordPress, a much more active open source project, at least in terms of outside contributors, is also still on SVN. Like WebKit, most contributors work on the git mirrors rather than using SVN. As an outsider, I can also think that it’s ridiculous for that project to still be on SVN, but again, I don’t know the context. I don’t know the blockers, I don’t know the workflow considerations. But I do feel confident that none of these decisions (or lack of decisions) were made because developers weren’t willing to learn git.
- tambourine_man 4y ago
  I use the bare minimum of it and am not happy. I’m sure it’s a great fit for the Linux kernel, but for a sole developer or small team, not so much. I’d rather just have several independent file system snapshots of a particular folder + logs. I’d like to rewrite history easily. But that ship has long sailed.
- eyelidlessness 4y ago
  > I don't understand any developer's that aren't willing to put in the time to learn how to use Git I can effectively use, I don’t know, probably the about 5% of git that I need to do my job. It could maybe benefit me to learn 5% more? The rest feels like a trivia rabbit hole, I have shit to do, and I already have a lot of difficulty with cognitive load and far too many yaks to shave daily. With that said, I have no strong disagreement with you, but I do want to add a bit of nuance: “learn how to use git” is extraordinarily open-ended, and one of the most challenging parts is to know where to even start. Or continued learning has any practical benefit. A little less nuanced: I encourage everyone who will listen, even experienced devs, to use a GUI frontend. Not just because GUIs do ~90% of what you’ll normally need in a daily workflow (which is especially good for noobs who learn which things are important to know first). Also because the GUIs generally have really obvious cues for how to unfuck a mistake, which is the most difficult thing for people who aren’t already well adjusted to git. I use a git GUI for almost all of my version control tasks, and I’m much more effective for it. I’ve learned more how to use the git CLI for an art project than I’ve ever needed to know for normal work processes. (Self nit: bullshit made up approximately educated guess percentages)
  - js2 4y ago
    > “learn how to use git” is extraordinarily open-ended, and one of the most challenging parts is to know where to even start. It's not really. It seems like it is because it has a baroque CLI with a ton of commands and those commands all have a ton of switches and the same commands can do lots of different things. But under that atrocious CLI git is very elegant and simple conceptually. Once you understand the underlying concepts (blobs, trees, commits, refs, index/stage) the rest flows naturally. Now I've been working with it since its earliest days including contributing to it here and there, but I never really found it very hard to grok. "Git from the bottom up" is dated but git hasn't changed conceptually since then. "Git for computer scientists" is another good one. But any of the tutorials that start with git's low-level concepts and build from there are where I'd start.
    - eyelidlessness 4y ago
      > It's not really. It seems like it is because it has a baroque CLI with a ton of commands and those commands all have a ton of switches and the same commands can do lots of different things.
- dekhn 4y ago
  ... and that's how I ended up with a detached head.
- brundolf 4y ago
  The problem is that you spend 95% of the time using it on the golden path; add, commit, push, maybe click a merge button somewhere. At least in my experience So it can be hard to learn the hard parts by doing, because by the time you need to do them again, you've forgotten what you learned last time
- rtpg 4y ago
  I feel like you do need a bit of rigor, especially because rebases and the like often don't do what you intuitively want, leading to merge conflicts over and over again when trying to clean things up. Even small stuff like not knowing to enable rerere means that rebases have incidental complexity compared to, for example, outright recreating commits in another spot. I disagree with most people about mercurial being "better" (I love my staging area), but doing stuff with git in practice can be super duper fiddly. I've found it's much nicer to do the right thing with stuff like magit though. I bet there is a great UI that is yet to be built for most people that makes it easier to do stuff like "updating old commits" or other things that you end up having to do through rebases.
- girvo 4y ago
  The amount of developers who don’t know about “bisect” alone makes me sad. Such a powerful tool especially when you’ve got a good replication of a bug in some kind of test-like thing you can run.
danudey 4y ago
We've been working on a migration from SVN to Git (since 2019, still going strong!) and, since our workflows are all built around SVN assumptions and SVN workflows, it has served only to make everything more complicated and more finicky than it would have been. I'm looking forward to doing more modernizing of things over time, but for now most of our work is trying to map SVN semantics and structures onto Git, and dealing with weird tooling issues. Case in point, the Git SCM branch source that the Jenkins multibranch plugin uses; all we need to filter on is branch name, which you can get from `git ls-remote <remote>`, but because of the way it's designed it actually clones the entire repository (between 4 and 12 GB) and then checks the branch list. Nightmareish. Still, a lot of stuff works a lot better, and now we have more and more developers and teams testing out or using Gitlab's features, like merge requests, and more and more projects trying to modernize their approach with CI builds and the like. It's a very exciting time.
js2 4y ago
I worked at Rockmelt from 2009 till it was acquired by Yahoo. You've never heard of it, but we had a browser built on-top of Chromium that had built-in integration with Facebook, Twitter, Posterous, RSS feeds, everything social of the day: https://imag.malavida.com/mvimgbig/download-fs/rockmelt-8383-1.jpg https://imag.malavida.com/mvimgbig/download-fs/rockmelt-8383... I was our build/release engineer. One of my jobs was keeping our code rebased on-top of Chromium. It wasn't terribly painful but I could always tell when a new engineer joined Chromium because they'd inevitably rewrite some major component and there'd go my day porting our code onto the rewrite. (I did more than just resolve merge conflicts. I also took a first pass at updating our code before handing it off to the rest of the team.) We were using git from the beginning. Chromium was using svn then, but Google had an official git-svn mirror and I worked from that. It's been a while, but I recall that I switched us from working off the tip-of-trunk to working off of release branches. That became feasible when Chromium switched to its more frequent release schedule (2 weeks I think?).
- lawik 4y ago
  No I've heard of it. It had some hype in the early social and app days.
- AdriaanvRossum 4y ago
  I remember it having a logo from the earth globe and some cracks in it [1]. Funny how our perspective on a browser and social media changed. [1] https://is4-ssl.mzstatic.com/image/thumb/Purple30/v4/9e/0c/3d/9e0c3ddd-b71d-0748-1b34-86da0905e732/source/512x512bb.jpg https://is4-ssl.mzstatic.com/image/thumb/Purple30/v4/9e/0c/3...
- jyz 4y ago
  Oh wow. I remember using that browser and going to your meetups getting swags!

by evmar 4y ago

taberiand 4y ago

I don't understand any developer's that aren't willing to put in the time to learn how to use Git - to me, it's the single greatest tool available to enable productivity and confidence in changing code. There's no shame in using any one of the many GUI interfaces for Git that make the process simple and intuitive but even with the CLI, there are only a small handful of commands that I regularly need to use to do all the work of managing branches, merges, rebases and resets; and a lot of the time, there's more than one way to do any particular operation.

evmar 4y ago
To be clear, I think many developers are comfortable enough with the small handful of commands most regularly use. For the more advanced case of maintaining a fork of a high-velocity codebase like WebKit, it's likely you'll need a deeper understanding of remotes and how to manage complex rebases, especially in the presence of lots of conflicts. And possibly some fancier tools like git-subtree. In particular in WebKit my recollection was it was common to patch something locally and eventually take it upstream, but after upstream's requested modifications the patch would eventually come back around and conflict with itself.
solarkraft 4y ago
I'm totally willing to learn the magic of advanced merging, but most "tell me more about Git" talks/articles rather want to tell me more about its general internal structure, which I find very far removed from actually using it. So what's the best resource for learning more about using Git?
- rascul 4y ago
  https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2
- LegionMammal978 4y ago
  Personally, I found https://learngitbranching.js.org/ https://learngitbranching.js.org/ surprisingly helpful for getting a mental model of Git usage, even though I had already been using Git for a couple years. As always with learning resources, YMMV.
saagarjha 4y ago
> I don't understand any developer's that aren't willing to put in the time to learn how to use Git Other version control systems exist. Why learn Git if you’ve already got one that works?
- acdha 4y ago
  In this case, was it really working? It sounds like they had enough friction to make considering alternatives reasonable. In general, I agree with your point but I think there's a very pragmatic argument that the open source world heavily converging on Git means it's worth knowing even if it's not your primary tool. In the 2000s that was spread out more with CVS, SVN, Mercurial, etc. also being good candidates depending on what communities you worked in but it's been quite a while since I've seen even Mercurial being used in the wild.
filmgirlcw 4y ago
> I don't understand any developer's that aren't willing to put in the time to learn how to use Git It’s not like git invented version control or even distributed version control. Stuff predated git and git wasn’t even the only solution that was coded together when BitKeeper changed license terms (personally, I wish Mercurial had won because it has a much better interface, but what won won and I’m happy enough with git to not really care). Putting all that aside, systems and codebases have their own workflows for a reason. I’m sure the reason WebKit was on SVN for so long wasn’t because the committers weren’t willing to use git (we’ve seen in this comment thread revelations by former Apple engineers who admit that they maintained a shadow git-based codebase internally), I’m sure almost everyone involved uses git. But for whatever reason, there were blockers to migrating (and some of those are explained in the WebKit blog). Now, as an outsider, I might think that waiting this long to migrate to git, a solid decade after it made sense to do so, is odd. But I don’t have the context. I don’t know the reasons why, and for what it’s worth, the git-svn mirrors seemed to be working well for the people working on the project. WordPress, a much more active open source project, at least in terms of outside contributors, is also still on SVN. Like WebKit, most contributors work on the git mirrors rather than using SVN. As an outsider, I can also think that it’s ridiculous for that project to still be on SVN, but again, I don’t know the context. I don’t know the blockers, I don’t know the workflow considerations. But I do feel confident that none of these decisions (or lack of decisions) were made because developers weren’t willing to learn git.
tambourine_man 4y ago
I use the bare minimum of it and am not happy. I’m sure it’s a great fit for the Linux kernel, but for a sole developer or small team, not so much. I’d rather just have several independent file system snapshots of a particular folder + logs. I’d like to rewrite history easily. But that ship has long sailed.
eyelidlessness 4y ago
> I don't understand any developer's that aren't willing to put in the time to learn how to use Git I can effectively use, I don’t know, probably the about 5% of git that I need to do my job. It could maybe benefit me to learn 5% more? The rest feels like a trivia rabbit hole, I have shit to do, and I already have a lot of difficulty with cognitive load and far too many yaks to shave daily. With that said, I have no strong disagreement with you, but I do want to add a bit of nuance: “learn how to use git” is extraordinarily open-ended, and one of the most challenging parts is to know where to even start. Or continued learning has any practical benefit. A little less nuanced: I encourage everyone who will listen, even experienced devs, to use a GUI frontend. Not just because GUIs do ~90% of what you’ll normally need in a daily workflow (which is especially good for noobs who learn which things are important to know first). Also because the GUIs generally have really obvious cues for how to unfuck a mistake, which is the most difficult thing for people who aren’t already well adjusted to git. I use a git GUI for almost all of my version control tasks, and I’m much more effective for it. I’ve learned more how to use the git CLI for an art project than I’ve ever needed to know for normal work processes. (Self nit: bullshit made up approximately educated guess percentages)
- js2 4y ago
  > “learn how to use git” is extraordinarily open-ended, and one of the most challenging parts is to know where to even start. It's not really. It seems like it is because it has a baroque CLI with a ton of commands and those commands all have a ton of switches and the same commands can do lots of different things. But under that atrocious CLI git is very elegant and simple conceptually. Once you understand the underlying concepts (blobs, trees, commits, refs, index/stage) the rest flows naturally. Now I've been working with it since its earliest days including contributing to it here and there, but I never really found it very hard to grok. "Git from the bottom up" is dated but git hasn't changed conceptually since then. "Git for computer scientists" is another good one. But any of the tutorials that start with git's low-level concepts and build from there are where I'd start.
  - eyelidlessness 4y ago
    > It's not really. It seems like it is because it has a baroque CLI with a ton of commands and those commands all have a ton of switches and the same commands can do lots of different things.
dekhn 4y ago
... and that's how I ended up with a detached head.
brundolf 4y ago
The problem is that you spend 95% of the time using it on the golden path; add, commit, push, maybe click a merge button somewhere. At least in my experience So it can be hard to learn the hard parts by doing, because by the time you need to do them again, you've forgotten what you learned last time
rtpg 4y ago
I feel like you do need a bit of rigor, especially because rebases and the like often don't do what you intuitively want, leading to merge conflicts over and over again when trying to clean things up. Even small stuff like not knowing to enable rerere means that rebases have incidental complexity compared to, for example, outright recreating commits in another spot. I disagree with most people about mercurial being "better" (I love my staging area), but doing stuff with git in practice can be super duper fiddly. I've found it's much nicer to do the right thing with stuff like magit though. I bet there is a great UI that is yet to be built for most people that makes it easier to do stuff like "updating old commits" or other things that you end up having to do through rebases.
girvo 4y ago
The amount of developers who don’t know about “bisect” alone makes me sad. Such a powerful tool especially when you’ve got a good replication of a bug in some kind of test-like thing you can run.

danudey 4y ago

We've been working on a migration from SVN to Git (since 2019, still going strong!) and, since our workflows are all built around SVN assumptions and SVN workflows, it has served only to make everything more complicated and more finicky than it would have been. I'm looking forward to doing more modernizing of things over time, but for now most of our work is trying to map SVN semantics and structures onto Git, and dealing with weird tooling issues. Case in point, the Git SCM branch source that the Jenkins multibranch plugin uses; all we need to filter on is branch name, which you can get from `git ls-remote <remote>`, but because of the way it's designed it actually clones the entire repository (between 4 and 12 GB) and then checks the branch list. Nightmareish. Still, a lot of stuff works a lot better, and now we have more and more developers and teams testing out or using Gitlab's features, like merge requests, and more and more projects trying to modernize their approach with CI builds and the like. It's a very exciting time.

js2 4y ago

I worked at Rockmelt from 2009 till it was acquired by Yahoo. You've never heard of it, but we had a browser built on-top of Chromium that had built-in integration with Facebook, Twitter, Posterous, RSS feeds, everything social of the day: https://imag.malavida.com/mvimgbig/download-fs/rockmelt-8383-1.jpg https://imag.malavida.com/mvimgbig/download-fs/rockmelt-8383... I was our build/release engineer. One of my jobs was keeping our code rebased on-top of Chromium. It wasn't terribly painful but I could always tell when a new engineer joined Chromium because they'd inevitably rewrite some major component and there'd go my day porting our code onto the rewrite. (I did more than just resolve merge conflicts. I also took a first pass at updating our code before handing it off to the rest of the team.) We were using git from the beginning. Chromium was using svn then, but Google had an official git-svn mirror and I worked from that. It's been a while, but I recall that I switched us from working off the tip-of-trunk to working off of release branches. That became feasible when Chromium switched to its more frequent release schedule (2 weeks I think?).

lawik 4y ago
No I've heard of it. It had some hype in the early social and app days.
AdriaanvRossum 4y ago
I remember it having a logo from the earth globe and some cracks in it [1]. Funny how our perspective on a browser and social media changed. [1] https://is4-ssl.mzstatic.com/image/thumb/Purple30/v4/9e/0c/3d/9e0c3ddd-b71d-0748-1b34-86da0905e732/source/512x512bb.jpg https://is4-ssl.mzstatic.com/image/thumb/Purple30/v4/9e/0c/3...
jyz 4y ago
Oh wow. I remember using that browser and going to your meetups getting swags!