Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New in Git: switch and restore

banterly.net

Post reply on HN
Print view View original

121–130 of 550 posts

Re: New in Git: switch and restore

#121

Post by Nursie »

toxik wrote: post #99
oauea wrote: post #82

Earlier quoted context omitted.

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.

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 real…

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.

Re: New in Git: switch and restore

#122

Post by res0nat0r »

akamoonknight wrote: post #104
aetherspawn wrote: post #73

A lot of comments along the lines of ‘why do people use instead of learning the commands’. For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time. My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or…

I will agree that visually seeing the tree is such a useful tool to have access to. I know that's not the true desire of your use case, but in case it's useful, I will add what is obviously the best git alias, 'git lg': https://coderwall.com/p/euwpig/a-better-git-log git lg --all is probably my most used command in terminals and I think it gives me a better view of how projects are flowing on the whole.

I exclusively use git via the cli because guis are too confusing for me to keep track of what is going on, I also like to use tig to browse the commit history like above.

Re: New in Git: switch and restore

#123

Post by bspammer »

yunohn wrote: post #78
thecupisblue wrote: post #36

Earlier quoted context omitted.

> but I'm seriously falling behind due to jetbrains integration This IntelliJ integration is the source of quite a lot of git problems in teams I worked with. I'm quite flabbergasted by this - devs claim to know git on their CV, come in and know what "commit" is and how to use the IntelliJ UI, but don't even understand what its doing. And everyone is acting like it's OK and learning git is a "hard thing ill never nee…

This is an unnecessarily antagonistic rant, which boils down to “I know git from scratch, I’m so smart, why isn’t everyone else doing this”. Git is a very complicated, bloated command line. Frankly, most of the day-to-day can easily be done with a high level understanding and a GUI. There is no shame in not knowing the minutiae of git. The goal of being a programmer is to produce cool things, not to duel with your to…

The irony with git is that the underlying data model is far simpler than the user interface implies. People assume git is complicated because the user interface is complicated, but it really is very simple under the hood.

So much so that you can write your own basic version of git in a couple of hours: https://wyag.thb.lt/

Re: New in Git: switch and restore

#124

Post by gallier2 »

akamoonknight wrote: post #104
aetherspawn wrote: post #73

A lot of comments along the lines of ‘why do people use instead of learning the commands’. For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time. My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or…

I will agree that visually seeing the tree is such a useful tool to have access to. I know that's not the true desire of your use case, but in case it's useful, I will add what is obviously the best git alias, 'git lg': https://coderwall.com/p/euwpig/a-better-git-log git lg --all is probably my most used command in terminals and I think it gives me a better view of how projects are flowing on the whole.

and the ultimate option for git lg is --reflog. Seeing all branches, even the old ones that do not exist anymore is a eye opening event in discovering the true nature of git: it never changes a commit, ever.

Re: New in Git: switch and restore

#125

Post by gallier2 »

oauea wrote: post #82
aetherspawn wrote: post #73

A lot of comments along the lines of ‘why do people use instead of learning the commands’. For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time. My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or…

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.

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

Re: New in Git: switch and restore

#126

Post by V-2 »

gallier2 wrote: post #125
oauea wrote: post #82

Earlier quoted context omitted.

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.

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

Fork has its advantages too (and a slicker UI if that matters for you)

Re: New in Git: switch and restore

#127

Post by gallier2 »

emsy wrote: post #80
aetherspawn wrote: post #73

A lot of comments along the lines of ‘why do people use instead of learning the commands’. For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time. My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or…

I completely agree. It always baffles me how something so simple (yes, simple!) as version control can end up as the abomination that is git. After controlling for popularity, you don’t see nearly as much posts explaining subversion in detail, and subversion being centralized is neither the only nor the biggest reason for that.

No, version control is not simple, never was. git was the first vcs that didn't suck because it was the first tool that understood the nature of the problem. All others were ass backward and instead of solving the problem stood in the way and actively made things worse.

Re: New in Git: switch and restore

#128

Post by nicoburns »

agilob wrote: post #116
intellix wrote: post #83

Earlier quoted context omitted.

I wouldn't say I'm an expert but I've got about 10 years experience using git via CLI and whenever a noob does something weird and he's using an IDE I'm like... Sorry I have zero idea what this is trying to do and cannot help you

I feel you. I was recently hired to help with svn to git migration and Java upgrades from 5-7 to 8 (due to my previous experience with such migrations). When I joined they already had a plan. They told me no one will be using command line. They are currently discussing which GUI to use and everyone will have this GUI installed by default, git command will be discouraged as non-standard approach, windows users will no…

Sublime merge would have been a good suggestion in this scenario. It's UI uses standard git terminology and concepts, so you'd have been sneakily trainig them in the command line whilst they used the UI!

Re: New in Git: switch and restore

#129

Post by yunohn »

thecupisblue wrote: post #109
yunohn wrote: post #78

Earlier quoted context omitted.

This is an unnecessarily antagonistic rant, which boils down to “I know git from scratch, I’m so smart, why isn’t everyone else doing this”. Git is a very complicated, bloated command line. Frankly, most of the day-to-day can easily be done with a high level understanding and a GUI. There is no shame in not knowing the minutiae of git. The goal of being a programmer is to produce cool things, not to duel with your to…

I don't know git from scratch, never written it or dived into source code itself. Yes, you can write C without understanding poinnters, you can paint without understanding colors and how they mix, draw without knowing difference between 3H and 2B, use a drill without knowing which type of head is for what. But try doing it long term and you either gotta learn those things or your output will be limited and clear expr…

> I'm advocating for understanding - not low level, at least high level.

It sounds a lot like you mean low-level, not high-level, though?

There’s more than enough to be achieved by just knowing the tree concept of git, and using a GUI to visualize it while running the basics - checkout, commit, branch, rebase, etc.

Re: New in Git: switch and restore

#130

Post by SOLAR_FIELDS »

quietbritishjim wrote: post #100
oauea wrote: post #82

Earlier quoted context omitted.

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.

> 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.)…

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.

Post reply on HN