5 ms·

All visual git tools I've used suck and wound up eventually corrupting the repo. Also I've noticed that all of my colleagues who learned git using these visual

by oauea 5y ago

All visual git tools I've used suck and wound up eventually corrupting the repo. Also I've noticed that all of my colleagues who learned git using these visual tools didn't actually learn git, and have no idea how to anything other than add/commit/push. I say "just rebase your branch" and I can see the panic grow in their eyes.

toxik 5y ago
For these people, I think a manual backup is what they actually want. “If I fuck up so bad I have to roll back.” I don’t think it’s wrong necessarily either, and GitHub actually encourages this behavior with the easy Web file uploads. Many repositories are now 99% automatically created commits by drag and drop. I think these people would be better served by a backup system where you can pin snapshots. They don’t really want to use VCSs like they’re meant to be.
- Nursie 5y ago
  How are version control systems meant to be used, if not as a history of the work? If not as a remote backup of work in progress? I get the whole “we should have a neat history of feature commits” argument, but that’s really only one facet of a good source control system. The fact that these goals appear to conflict shows me there’s some sort of lack in git. For all its (many, many) problems, uber-complex source control system ClearCase at least allowed you to specify a view, so you could see both types of information depending on your use-case.
  - jen20 5y ago
    They’re not really in conflict at all. The workflow I’ve been using for ~11 years is: - Make a branch for my work. - Commit early, often and with often meaningless commit messages like “WIP” or “try x” or “nope x doesn’t work, do y instead” - in other words, what the work was. - Push this branch to a remote (either personal or shared depending on policy) largely to synchronise between machines, but also as a backup. - When ready to integrate, interactively rebase into a set of cohesive units which are independently buildable and have detailed commit messages which explain why the work was done, not what the works was. - Push _this_ as a pull request, Gerrit change set, or email patch, depending on policy. This approach gives you the best of both worlds: fast, easy backup and easy unwind when doing work, and a clean history for the benefit of future developers on the project.
    - Nursie 5y ago
      You still lose your real commit history though, and I’ve found it useful to have that in the past. A dead end or experimental avenue that turned out not to have use at the time turns out to be a real timesaver later. I’m fact I’ve found that far more useful than a well curated history. Having both would be a good thing. Having both in a not-ridiculously overcomplex system even better… I wonder if there even is a sweet spot.
      - jen20 5y ago
        I agree that having both would be preferable - and to some extent GitHub gives you that (via the "squash and merge" button). Unfortunately it doesn't appear that workflow is usable in a lot of cases since the commit message cannot be reviewed independently in this model, unlike in Gerrit. You can always keep your working branches on a personal remote, or interesting sets of changes in gists, however.
        Nursie 5y ago
        > You can always keep your working branches on a personal remote This kinda defeats the point again, to my view. I’m not familiar enough with gists to know if they would solve this.
- oauea 5y ago
  Too bad for them, because they're (supposedly) professional software developers hired to work on this project and the project uses git.
quietbritishjim 5y ago
> I say "just rebase your branch" and I can see the panic grow in their eyes. The irony of that is that resolving conflicts in a complicated multi-commit rebase is much more easily/efficiently done in a good GUI than on the command line. Not all GUIs support it though (I think SourceTree gives up if there's a conflict), in fact it's a bit of an acid test for a Git GUI. The Jetbrains IDEs (PyCharm, CLion, IDEA, etc.) work very well. (So does TortoiseHg but obviously not for Git!)
- Lio 5y ago
  I would say that depends on your background. This is just me but I’m quite happy viewing the graph via CLI and doing interactive rebases to fix issues. I have no problems with other people preferring a GUI but all I’ve tried have been confusing for me.
- cerved 5y ago
  A combination of git diff, git checkout --ours/theirs . && git add and git mergetool works well in my experience
- SOLAR_FIELDS 5y ago
  My experience also supports this. I think resolving complicated merge conflicts is the best argument for using an IDE with Git. My experience of having to maintain a fork of a code base where there was frequently a lot of conflicts showed that I would reach for IntelliJ to resolve complicated conflicts even if it wasn’t Java files. The 3 window visualization they use is just great for seeing conflicts in large files that span hundreds of lines of code. I use the terminal commands for everything else though.
- lobocinza 5y ago
  Vim has some plugins that make it a lot easier/quicker.
- pkulak 5y ago
  Sublime Merge’s three-way merge is so good. It’s totally spoiled me.
gallier2 5y ago
The only visual git tool I really like is gitextensions for windows.
- V-2 5y ago
  Fork has its advantages too (and a slicker UI if that matters for you)

by oauea 5y ago

toxik 5y ago

For these people, I think a manual backup is what they actually want. “If I fuck up so bad I have to roll back.” I don’t think it’s wrong necessarily either, and GitHub actually encourages this behavior with the easy Web file uploads. Many repositories are now 99% automatically created commits by drag and drop. I think these people would be better served by a backup system where you can pin snapshots. They don’t really want to use VCSs like they’re meant to be.

Nursie 5y ago
How are version control systems meant to be used, if not as a history of the work? If not as a remote backup of work in progress? I get the whole “we should have a neat history of feature commits” argument, but that’s really only one facet of a good source control system. The fact that these goals appear to conflict shows me there’s some sort of lack in git. For all its (many, many) problems, uber-complex source control system ClearCase at least allowed you to specify a view, so you could see both types of information depending on your use-case.
- jen20 5y ago
  They’re not really in conflict at all. The workflow I’ve been using for ~11 years is: - Make a branch for my work. - Commit early, often and with often meaningless commit messages like “WIP” or “try x” or “nope x doesn’t work, do y instead” - in other words, what the work was. - Push this branch to a remote (either personal or shared depending on policy) largely to synchronise between machines, but also as a backup. - When ready to integrate, interactively rebase into a set of cohesive units which are independently buildable and have detailed commit messages which explain why the work was done, not what the works was. - Push _this_ as a pull request, Gerrit change set, or email patch, depending on policy. This approach gives you the best of both worlds: fast, easy backup and easy unwind when doing work, and a clean history for the benefit of future developers on the project.
  - Nursie 5y ago
    You still lose your real commit history though, and I’ve found it useful to have that in the past. A dead end or experimental avenue that turned out not to have use at the time turns out to be a real timesaver later. I’m fact I’ve found that far more useful than a well curated history. Having both would be a good thing. Having both in a not-ridiculously overcomplex system even better… I wonder if there even is a sweet spot.
    - jen20 5y ago
      I agree that having both would be preferable - and to some extent GitHub gives you that (via the "squash and merge" button). Unfortunately it doesn't appear that workflow is usable in a lot of cases since the commit message cannot be reviewed independently in this model, unlike in Gerrit. You can always keep your working branches on a personal remote, or interesting sets of changes in gists, however.
      - Nursie 5y ago
        > You can always keep your working branches on a personal remote This kinda defeats the point again, to my view. I’m not familiar enough with gists to know if they would solve this.
oauea 5y ago
Too bad for them, because they're (supposedly) professional software developers hired to work on this project and the project uses git.

quietbritishjim 5y ago

> I say "just rebase your branch" and I can see the panic grow in their eyes. The irony of that is that resolving conflicts in a complicated multi-commit rebase is much more easily/efficiently done in a good GUI than on the command line. Not all GUIs support it though (I think SourceTree gives up if there's a conflict), in fact it's a bit of an acid test for a Git GUI. The Jetbrains IDEs (PyCharm, CLion, IDEA, etc.) work very well. (So does TortoiseHg but obviously not for Git!)

Lio 5y ago
I would say that depends on your background. This is just me but I’m quite happy viewing the graph via CLI and doing interactive rebases to fix issues. I have no problems with other people preferring a GUI but all I’ve tried have been confusing for me.
cerved 5y ago
A combination of git diff, git checkout --ours/theirs . && git add and git mergetool works well in my experience
SOLAR_FIELDS 5y ago
My experience also supports this. I think resolving complicated merge conflicts is the best argument for using an IDE with Git. My experience of having to maintain a fork of a code base where there was frequently a lot of conflicts showed that I would reach for IntelliJ to resolve complicated conflicts even if it wasn’t Java files. The 3 window visualization they use is just great for seeing conflicts in large files that span hundreds of lines of code. I use the terminal commands for everything else though.
lobocinza 5y ago
Vim has some plugins that make it a lot easier/quicker.
pkulak 5y ago
Sublime Merge’s three-way merge is so good. It’s totally spoiled me.

gallier2 5y ago

The only visual git tool I really like is gitextensions for windows.

V-2 5y ago
Fork has its advantages too (and a slicker UI if that matters for you)