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

High-Level Problems with Git and How to Fix Them

gregoryszorc.com

Post reply on HN
Print view View original

141–150 of 294 posts

Re: High-Level Problems with Git and How to Fix Them

#141

Post by jhasse »

jcranmer wrote: post #53
taeric wrote: post #22

If you requested save in your favorite GUI application, text editor, etc and it popped open a select the changes you would like to save dialog, you would rightly think just save all my changes already, dammit I'm sympathetic to what this is asking, but I have to feel that this would lead to much better practices for many people. I'd wager a ton of folks would be more "why in the world does it think I changed that?" t…

In my experience, the benefit you get is from giving you an editor to edit the commit message, which has a list of files changed, and can be cancelled in some way to abort the commit. Both hg and git can do this, so it's not necessary to have a separate command and staging area just to do it.

Also you still haven't pushed the commit and could undo it.

Re: High-Level Problems with Git and How to Fix Them

#142

Post by mschaef »

jcranmer wrote: post #52

One personal anecdote: In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. Even nowadays, where I'm more or less forcing myself to use git [1], I'm incredibly hesitant to try any sort of complex…

> I don't think it's as appreciated that git's complexity generally discourages people from trying things out.

For me, at least, the underlying model actually makes it easier to try things out. As long as my work is in commits and I have refs that point to those commits, I can be pretty sure that I'm not going to lose anything. I also take a fair amount of comfort in the fact that (unlike, say, SVN), any remote actions can be deferred until I know things are correct locally.

This sort of robustness in the data model makes it a bunch easier for me to forgive the (very real) usability issues in the command line UI. (And, after years of work, the command line is getting more familiar, aside from some of the more complex rebase operations.)

Re: High-Level Problems with Git and How to Fix Them

#143

Post by Philipp__ »

I was holding to that famous UNIX mentality for many years, since I started programming almost... Use many programs that do one single thing, pipe the data, print it on the main output etc etc. That’s how I used git too, writing 160 chars wide commands... I tried playing with Emacs year and a half ago, and it was big cultural shock, for first year of using it I still couldn’t adopt kitchensink philosophy. But after barely scratching what emacs had to offer I went back to my unix terminal workflow it felt clunkier than ever.

Takeaway from this story can be Magit. It totally changed my perception of git, and felt like more robust and semantically better way to use/understand git. Maybe it was like that because of few years of terminal git usage, don’t know how will complete beginner react to magit. But what shocked me the most was how my approach to git changed with dofferent interface. GUIs never appealed to me, but magit represented the middle ground of GUI like functionality with terminal like interface that got many things semantically right.

Re: High-Level Problems with Git and How to Fix Them

#144

Post by saltedmd5 »

zegl wrote: post #129
saltedmd5 wrote: post #114

Earlier quoted context omitted.

"I try to keep my git workflow simple," and yet I see 'git rebase' but no 'git merge' in that list.

`rebase` is simpler than `merge` in larger teams/projects, as the history will be much cleaner.

Rebase is not simpler in any context - rebase rewrites history, which, if branches have been pushed to remotes, then necessitates force pushes, which in turn breaks any other instances of the same branch. By using rebase to "keep history clean" you are largely undermining git's power as a DVCS.

Rebase as a tool is not inherently bad but it is definitely not simpler than merge - it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing and in my experience most teams that are using it as a core part of their workflow are doing so for the wrong reasons (generally because of a fundamental misunderstanding of how branching and merging works in git and why it works that way).

Re: High-Level Problems with Git and How to Fix Them

#145

Post by globuous »

Philipp__ wrote: post #143

I was holding to that famous UNIX mentality for many years, since I started programming almost... Use many programs that do one single thing, pipe the data, print it on the main output etc etc. That’s how I used git too, writing 160 chars wide commands... I tried playing with Emacs year and a half ago, and it was big cultural shock, for first year of using it I still couldn’t adopt kitchensink philosophy. But after b…

TD;DR: Magit is a lesson of UX.

+1 for Magit. When I discovered it is when I discovered git. I assume tig must be similar although I've never looked into it but...

With magit, from my editor, I can easily check: my git status, choose which hunks to stage or unstage, commit easily. I can switch branches with less than 10 keystrokes. etc. But to me, what's coolest about it is that I can easily see commit histories and graps for branches, files, and the repo. With less than 5 keystrokes. And I can navigate these histories easily. Finally !!! Same story for pushing, pulling, merging, rebasing.

Which all of this you can do in CLI obviously. But Magit makes it easy, and because now I have everything I need with regards to git just a few keystrokes away, I can interact with git easily. So I do it.

Re: High-Level Problems with Git and How to Fix Them

#146

Post by yoodenvranx »

In the beginning I tried to use git exclusively through command line because I thought that's how real men do it.

But after using gitkraken (or similar products) I will never go back to using git through its command line interface. Being able to see the whole repo structure is just so much more convenient and it helps to resolve most merging problems much faster. git guis all have their own problems, but overall using a git gui for me is the better choice in 95% of all use cases.

Re: High-Level Problems with Git and How to Fix Them

#147

Post by michaelgrafl »

yoodenvranx wrote: post #146

In the beginning I tried to use git exclusively through command line because I thought that's how real men do it. But after using gitkraken (or similar products) I will never go back to using git through its command line interface. Being able to see the whole repo structure is just so much more convenient and it helps to resolve most merging problems much faster. git guis all have their own problems, but overall usin…

I always have both open. Gitkraken for having a broad overview of local and remote branches, stashes, and for staging chunks of code. And the command line for everything else. Some things just confuse me in any GUI Frontend or don't work as fast as on the CLI.

Re: High-Level Problems with Git and How to Fix Them

#148

Post by golergka »

popopopo wrote: post #64
jcranmer wrote: post #52

One personal anecdote: In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. Even nowadays, where I'm more or less forcing myself to use git [1], I'm incredibly hesitant to try any sort of complex…

wow. > I'm incredibly hesitant to try any sort of complex git operation because of the risk that I might lose my in-progress commits. correct way of learning git is every time you want to use a "complex"/dangerous commands in git, you `cd /tmp` and create a git repository there. then create some commits, branches and experiment. you will NOT lose anything, but you will learn a lot. I did and do this every time I have…

> correct way of learning git is every time you want to use a "complex"/dangerous commands in git, you `cd /tmp` and create a git repository there. then create some commits, branches and experiment. you will NOT lose anything, but you will learn a lot.

What if your repo with full history is about 30gb?

Re: High-Level Problems with Git and How to Fix Them

#149

Post by golergka »

jcranmer wrote: post #52

One personal anecdote: In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. Even nowadays, where I'm more or less forcing myself to use git [1], I'm incredibly hesitant to try any sort of complex…

> In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much.

I have used git for a long time, but never arrived at such a state, apart from when I was converting existing SVN repo to git (where starting the process anew after 10 minutes of experimenting was faster than restoring refs). How did you manage to do it?

Post reply on HN