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

141–150 of 550 posts

Re: New in Git: switch and restore

#141

Post by lobocinza »

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

Vim has some plugins that make it a lot easier/quicker.

Re: New in Git: switch and restore

#142

Post by sdesol »

jeltz wrote: post #71
vnorilo wrote: post #60

Earlier quoted context omitted.

Complexity is like body odor: you generally don't mind your own.

Git has not been Linus's project for many years.

Here is his contribution in the last 5 years

https://public-001.gitsense.com/insights/github/repos?p=comm...

The changes were mostly pretty small as well, which would make sense given he has been hands off for quite some time now.

Re: New in Git: switch and restore

#144

Post by mberning »

cerved wrote: post #118
snarfy wrote: post #105

Earlier quoted context omitted.

We are all using git only because Linus wrote it. The cargo cult is real and very much alive in our industry, I think precisely because we are all here to write specialist software. Too busy in our domain to worry about version control nuances so we just go with what is popular and don't think about it too much. It's not just version control, it's libraries, frameworks, languages, all of it. If it's not popular it's…

we use it because it's blazing fast, stable and extremely versatile

It’s not very fast when you account for all the time and productivity wasted on getting “unstuck” all the time.

Re: New in Git: switch and restore

#145

Post by tkuraku »

I think sublime merge is pretty close to the optimal git GUI, https://www.sublimemerge.com/. It uses standard git commands and terminology and allows you to add custom git commands to the GUI. Unlike Sourcetree is cross platform for Windows/Linux/Mac and includes a merge tool. I think command line git and Sublime Merge git translate back and pretty easily.

Re: New in Git: switch and restore

#146

Post by vanviegen »

the_biot wrote: post #69
kzrdude wrote: post #37

It is unfortunate that: + git switch is documented as "EXPERIMENTAL" + git --help lists git switch but not git checkout as an important command This is a documentation inconsistency. It can't be both the canonical interface to use and experimental at the same time.

So send in a patch.

Your preferred solution to this inconsistency is for a random bystander to flip a coin?

Re: New in Git: switch and restore

#147

Post by jamesmontalvo3 »

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.

If I need to visualize the network of commits I use this alias in .gitconfig:

network = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all

Re: New in Git: switch and restore

#148

Post by jen20 »

Nursie wrote: post #121
toxik wrote: post #99

Earlier quoted context omitted.

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

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.

Re: New in Git: switch and restore

#149

Post by jen20 »

cerved wrote: post #118
snarfy wrote: post #105

Earlier quoted context omitted.

We are all using git only because Linus wrote it. The cargo cult is real and very much alive in our industry, I think precisely because we are all here to write specialist software. Too busy in our domain to worry about version control nuances so we just go with what is popular and don't think about it too much. It's not just version control, it's libraries, frameworks, languages, all of it. If it's not popular it's…

we use it because it's blazing fast, stable and extremely versatile

I’d add another reason to that: we’re using Git because BitKeeper wasn’t free (as in beer) at the time for general purpose use. Had it been, we’d all be using BitKeeper instead.

Re: New in Git: switch and restore

#150

Post by larusso »

intellix wrote: post #83
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 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

Same for me. I switched from SVN to git professionally in 2013 and used git via Sourcetree on personal smaller projects. I had to switch to the CLI git because so used SVN also on CLI only and could not transfer the documentation to the buttons of Sourcetree. Whenever I help out other coworkers with git do it via commandline. Doesn‘t matter if windows or Unix. What drives me nuts with programs like Sourcetree is the fact that they apply their own default behaviors to make it „easier“ to use git. Like initializing submodules by default. I had a project with a sparse checkout scheme that could not be cloned via Sourcetree because of this. Our submodules where an optional compiler for a 3rd party platform.
Post reply on HN