5 ms·

> Using git can be daunting at first. Like my good friend Chris once said, "everyone knows the happy path but the minute it gets hairy we're all screwed". Soun

> Using git can be daunting at first. Like my good friend Chris once said, "everyone knows the happy path but the minute it gets hairy we're all screwed". Sounds familiar. Lots of people just learn a few template use-cases, but don’t take the time to learn/study the tool. You might argue you shouldn’t need to but Git isn’t intuitive and does require investment. It comes with its own terminology; there’s no point just guessing what a branch is for e.g.. Like all powerful *nix cli tools, if you don’t you’ll shoot yourself in the foot one day. Even if you want to use a GUI interface, it’s no substitute for learning how git works behind the scenes. Sometimes when I offer to help a colleague that’s got themselves into knots the sad thing is often they can’t even explain the problem they got into.

KronisLV 5y ago
> Like all powerful *nix cli tools, if you don’t you’ll shoot yourself in the foot one day. Surely we can do better than this? A tool being powerful should be no excuse for it having footguns! For example, see "Why SQLite Does Not Use Git": https://sqlite.org/whynotgit.html https://sqlite.org/whynotgit.html In my eyes it addresses many of the problematic bits of Git and offers alternatives to them. Admittedly, it was sad to see other VCSes like SVN die out, since there were some things that they did more clearly than Git (e.g. revision numbers), despite their other shortcomings. Currently, for many Git is essentially forced upon them and they have to learn commands that they don't understand to use it, much like you said. If version control were easier and more intuitive, then more people would adopt it and the ones using it would be more efficient with it, rather than people messing up their repositories and others blaming them for it - even though they'd be right, that sort of elitism also doesn't help much, since clearly some mistakes are easier to make than others. I think that most of the systems out there will eventually be improved or rewritten until finally they are both powerful and usable, even Git probably isn't immune to this. Whether the incentives to do that are there now (since GitHub, GitLab and others are already de facto within the industry) will only affect whether this is done in the next 50 or 100 years. Here's an issue that we ran into this week: - at work, we have a "main" branch and a "development" branch - a new "feature" must be based off of "main", but eventually moved into "development", since that's what the test environments are configured against - thus, we have a "feature-development" branch, into which we merge "feature", to not sacrifice our ability to put "feature" back into "main" without the "development" changes, if ever needed - then, we merge the "development" branch into the "feature-development" branch to solve any conflicts or do any refactoring that we need to ensure that those two branches play together nicely, before merging "feature-development" into "development" - this week, someone did the opposite, they merged "feature-development" back into "feature", thus moving all of the "development" changes into "feature", which we can't allow - the solution? who knows, one option would be to force push the earlier position of a branch, thus erasing the merge commit, but force pushes are considered a bad practice - what we opted for in the end was having another commit that reverts the merge (through the GitLab UI), however now the history still shows that "feature" has 100+ commits in it - the problem that we might run into down the road now is that when we merge "feature" into "feature-development", we'll probably also carry over the revert commit, which we'll then need to revert or do something so that the "feature-development" branch doesn't have all of the "development" changes essentially removed (which may or may not be true) All of that pain, essentially caused by one bad merge, whereas other colleagues are now also asking me about rebasing. I don't feel like i know Git well enough to be the "go to guy" and would rather just write the code i need for the features, rather than worry about the branching strategies and what colleagues have done and weird client requirements for what branches must be used as a base since there are not enough test environments. Furthermore, GitLab not having an easy way to say "i want this commit gone" is equally annoying. If they offer you to do reverts, surely they can also ensure the equivalent of a force push? Then again, chances are that it's too early for me to say anything vaguely accurate and even so someone out there probably can solve all of it in a line or two. Nonetheless, it feels to me that an easy to use tool would expose solutions for the most common problems in an approachable way.
- masklinn 5y ago
  > Surely we can do better than this? A tool being powerful should be no excuse for it having footguns! Of course we can but they all lost the vcs wars so we’re left with git, a chainsaw you can’t shut down with hooked spikes bolted to the handle and an old “handle with care” sticker long gone unstuck and slipped under one of the shop’s cabinets.
  - leokennis 5y ago
    Fantastic analogy. Personally I am not interested to learn "proper git". It's plumbing and not an end goal. When I start working on something, I do a pull and then create a branch. Then I make edits to the files I need and save a copy of them locally. If then something goes awry with my commit/push/MR/whatever, I delete the repo, clone it, create a new branch, using human intelligence re-apply my changes from the local copies and try again.
- zibzab 5y ago
  > the solution? who knows, one option would be to force push the earlier position of a branch, thus erasing the merge commit, but force pushes are considered a bad practice This is definitely a better solution and the _only_ time force push is okay. (Well unless this is a big public repo that have since moved on)
- beermonster 5y ago
  > Surely we can do better than this? A tool being powerful should be no excuse for it having footguns! I agree. In fact I’d even say they exist but yet they didn’t win. I have often wondered why a tool that sits atop of git doesn’t exist. One that exposes some basic opinionated operations.
  - KronisLV 5y ago
    > I have often wondered why a tool that sits atop of git doesn’t exist. Well, some software like SourceTree allows making certain workflows, like Gitflow easier: https://weaintplastic.github.io/web-development-field-guide/Collaboration/Working_with_Git/Git_Workflow/Gitflow_with_Sourctree.html https://weaintplastic.github.io/web-development-field-guide/... and https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow https://www.atlassian.com/git/tutorials/comparing-workflows/... Of course, that workflow is now considered a bit dated at this point and is only good for some projects, as a way to manage their complexities. Now, my memory might be failing me, but i actually recall GitKraken having a lot of nice functionality, like being able to get rid of bad branch merges with ctrl+z, much like one would undo a bad text edit in other software, which seemed really intuitive and functional: https://www.gitkraken.com/ https://www.gitkraken.com/ Personally i'm only aware of such small, yet nice improvements in the GUI space, like how GitHub Desktop also attempted simplifying working with Git (within their platform) somewhat: https://desktop.github.com/ https://desktop.github.com/ I guess that perhaps a larger amount of people who use the Git CLI are okay with it or just tolerate it, rather than the ones in the Git UI app space, where new apps pop up every now and then?
jareklupinski 5y ago
> "everyone knows the happy path but the minute it gets hairy we're all screwed". Sounds familiar. "Everybody has a plan until they get punched in the mouth." -Mike Tyson

KronisLV 5y ago

> Like all powerful *nix cli tools, if you don’t you’ll shoot yourself in the foot one day. Surely we can do better than this? A tool being powerful should be no excuse for it having footguns! For example, see "Why SQLite Does Not Use Git": https://sqlite.org/whynotgit.html https://sqlite.org/whynotgit.html In my eyes it addresses many of the problematic bits of Git and offers alternatives to them. Admittedly, it was sad to see other VCSes like SVN die out, since there were some things that they did more clearly than Git (e.g. revision numbers), despite their other shortcomings. Currently, for many Git is essentially forced upon them and they have to learn commands that they don't understand to use it, much like you said. If version control were easier and more intuitive, then more people would adopt it and the ones using it would be more efficient with it, rather than people messing up their repositories and others blaming them for it - even though they'd be right, that sort of elitism also doesn't help much, since clearly some mistakes are easier to make than others. I think that most of the systems out there will eventually be improved or rewritten until finally they are both powerful and usable, even Git probably isn't immune to this. Whether the incentives to do that are there now (since GitHub, GitLab and others are already de facto within the industry) will only affect whether this is done in the next 50 or 100 years. Here's an issue that we ran into this week: - at work, we have a "main" branch and a "development" branch - a new "feature" must be based off of "main", but eventually moved into "development", since that's what the test environments are configured against - thus, we have a "feature-development" branch, into which we merge "feature", to not sacrifice our ability to put "feature" back into "main" without the "development" changes, if ever needed - then, we merge the "development" branch into the "feature-development" branch to solve any conflicts or do any refactoring that we need to ensure that those two branches play together nicely, before merging "feature-development" into "development" - this week, someone did the opposite, they merged "feature-development" back into "feature", thus moving all of the "development" changes into "feature", which we can't allow - the solution? who knows, one option would be to force push the earlier position of a branch, thus erasing the merge commit, but force pushes are considered a bad practice - what we opted for in the end was having another commit that reverts the merge (through the GitLab UI), however now the history still shows that "feature" has 100+ commits in it - the problem that we might run into down the road now is that when we merge "feature" into "feature-development", we'll probably also carry over the revert commit, which we'll then need to revert or do something so that the "feature-development" branch doesn't have all of the "development" changes essentially removed (which may or may not be true) All of that pain, essentially caused by one bad merge, whereas other colleagues are now also asking me about rebasing. I don't feel like i know Git well enough to be the "go to guy" and would rather just write the code i need for the features, rather than worry about the branching strategies and what colleagues have done and weird client requirements for what branches must be used as a base since there are not enough test environments. Furthermore, GitLab not having an easy way to say "i want this commit gone" is equally annoying. If they offer you to do reverts, surely they can also ensure the equivalent of a force push? Then again, chances are that it's too early for me to say anything vaguely accurate and even so someone out there probably can solve all of it in a line or two. Nonetheless, it feels to me that an easy to use tool would expose solutions for the most common problems in an approachable way.

masklinn 5y ago
> Surely we can do better than this? A tool being powerful should be no excuse for it having footguns! Of course we can but they all lost the vcs wars so we’re left with git, a chainsaw you can’t shut down with hooked spikes bolted to the handle and an old “handle with care” sticker long gone unstuck and slipped under one of the shop’s cabinets.
- leokennis 5y ago
  Fantastic analogy. Personally I am not interested to learn "proper git". It's plumbing and not an end goal. When I start working on something, I do a pull and then create a branch. Then I make edits to the files I need and save a copy of them locally. If then something goes awry with my commit/push/MR/whatever, I delete the repo, clone it, create a new branch, using human intelligence re-apply my changes from the local copies and try again.
zibzab 5y ago
> the solution? who knows, one option would be to force push the earlier position of a branch, thus erasing the merge commit, but force pushes are considered a bad practice This is definitely a better solution and the _only_ time force push is okay. (Well unless this is a big public repo that have since moved on)
beermonster 5y ago
> Surely we can do better than this? A tool being powerful should be no excuse for it having footguns! I agree. In fact I’d even say they exist but yet they didn’t win. I have often wondered why a tool that sits atop of git doesn’t exist. One that exposes some basic opinionated operations.
- KronisLV 5y ago
  > I have often wondered why a tool that sits atop of git doesn’t exist. Well, some software like SourceTree allows making certain workflows, like Gitflow easier: https://weaintplastic.github.io/web-development-field-guide/Collaboration/Working_with_Git/Git_Workflow/Gitflow_with_Sourctree.html https://weaintplastic.github.io/web-development-field-guide/... and https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow https://www.atlassian.com/git/tutorials/comparing-workflows/... Of course, that workflow is now considered a bit dated at this point and is only good for some projects, as a way to manage their complexities. Now, my memory might be failing me, but i actually recall GitKraken having a lot of nice functionality, like being able to get rid of bad branch merges with ctrl+z, much like one would undo a bad text edit in other software, which seemed really intuitive and functional: https://www.gitkraken.com/ https://www.gitkraken.com/ Personally i'm only aware of such small, yet nice improvements in the GUI space, like how GitHub Desktop also attempted simplifying working with Git (within their platform) somewhat: https://desktop.github.com/ https://desktop.github.com/ I guess that perhaps a larger amount of people who use the Git CLI are okay with it or just tolerate it, rather than the ones in the Git UI app space, where new apps pop up every now and then?

jareklupinski 5y ago

> "everyone knows the happy path but the minute it gets hairy we're all screwed". Sounds familiar. "Everybody has a plan until they get punched in the mouth." -Mike Tyson