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

Some bad Git situations and how I got myself out of them

ohshitgit.com

Post reply on HN
Print view View original

321–330 of 352 posts

Re: Some bad Git situations and how I got myself out of them

#321

Post by steveklabnik »

fizzbatter wrote: post #269

I've been debating starting a section of my personal site for stuff like this. Unfortunately it's a bit embarrassing, but i figure anything i have to google to learn, it would be beneficial to help others learn it as well. Everything from programming languages (lots of Rust errors are foreign to me, for example), to git issues. I've often had the thought that if everyone did this it could have potential to be quite t…

Please file bugs for bad errors in Rust. We have an entire tag dedicated to them, and have been doing a lot of work to make them better. A non-understandable error is a bug.

Re: Some bad Git situations and how I got myself out of them

#322

Post by Nemcue »

chousuke wrote: post #305
dep_b wrote: post #236

Somebody proposed to use a GUI. That doesn't solve the usability issues of Git. There's this triangle of what the user tries to do, what the commands and options are called and what they actually do. None of them really align, though with some careful use you can actually make Git do what you want - eventually. I would like to understand what's the yearly damage of such an important tool being so difficult to use. Pe…

I feel like people's opinion of git's usability is lower than what it actually is. Certainly, it's got a lot of different switches and stuff, but since its data model is so simple, you can always understand what it's doing to your data. So you can read a description of what a switch does, and then understand exactly what will happen when you use it. (The exception to this is automatic merge conflict resolution with r…

Except very few actually take the time to understand the data model..

Re: Some bad Git situations and how I got myself out of them

#323

Post by shandor »

ThatGeoGuy wrote: post #315
shandor wrote: post #246

Earlier quoted context omitted.

This is why rebase is so, so much better than merge. And it's infinitely better for bisecting, too. Simple, completely linear history for origin/master is just so powerful in many that aspects that I'm constantly baffled why merging seems to be the flow mostly being talked about. Now someone usually comes and says that merges are superior for long running branches. Which may be true in some aspects, but when you have…

For those of us who are uneducated / haven't seen this before: how do you use rebase to merge a separate branch? Are you suggesting you just `git rebase my-branch` from master / develop? How do you coordinate this with multiple team members. Merges appear to work better when you have multiple team members with separate feature branches that may have some overlap (conflicts may occur, but those can be handled as they…

Yes, just rebase your whole feature branch on top of origin/master. Long-running branches with huge amounts of commits are bad anyway for multiple reasons, so it's not like you're bringing too many commits at once with any given rebase.

I'm not sure why you think this is worse to coordinate than merge commits? I think encouraging rebase-heavy workflow where feature branches are put into origin/master as often as possible actually improves the coordination quite a lot. When working that way, origin/master is always pretty recent, and anyone starting a new feature branch from top of it has really small risk of missing any big change sets from coworkers. On the other hand, I feel that merge-heavy workflow encourages people to have long-running branches other than origin/master, which hides commits from others.

Re: Some bad Git situations and how I got myself out of them

#324

Post by OJFord »

V-2 wrote: post #185
OJFord wrote: post #151

Earlier quoted context omitted.

This looks like an awesome way to learn git, and many would probably love to continue with it - but many others too would prefer to move to the CLI. I used to use a GUI for git, but now I just find them cumbersome; by their nature requiring me to switch window for less.

For commands maybe, but nothing beats a graphical history tree. It's hard for a human to imagine a complex branch history without a good visual aid

I agree, and often use a `log --bunch -of --options` alias to view this - but slightly prettier rendering isn't going to make me switch window and back again.

Re: Some bad Git situations and how I got myself out of them

#325

Post by jogjayr »

BeetleB wrote: post #282
exDM69 wrote: post #253

Earlier quoted context omitted.

> The sad thing is mercurial has like 95% of git's power and is waaay easier to understand Mercurial has a clean and simple UI, especially if you come from a SVN background. But Git's internals are simpler and the concept is much easier to understand, especially if you start looking at a handful of the most popular Mercurial extensions, some of which will be "must have" sooner or later. This is no excuse for an incon…

>But Git's internals are simpler and the concept is much easier to understand, I'm only an occasional Git user, but am a heavy Mercurial user. I have never needed to understand Mercurial's internals. Are you suggesting a Git user will eventually need to understand it? That's a strike against Git already. From my observation over the years, people who use Git get "stuck" more often, because they are trying to leverage…

> Are you suggesting a Git user will eventually need to understand it? That's a strike against Git already.

I try to learn about git internals just for the pleasure of it.

Re: Some bad Git situations and how I got myself out of them

#326

Post by nhaehnle »

Chromozon wrote: post #320
nhaehnle wrote: post #245

Earlier quoted context omitted.

People complain, but what's the alternative? Non-distributed VCS clearly don't cut it for many use cases, and of the other DVCS I've tried, none were really better than Git in my opinion. Sure, it depends on your workflow. But if part of your workflow is authoring sequences of commits that make sense in hindsight, then I honestly haven't seen an alternative. The point of Git is that it gets the underlying data model…

Many large companies use Perforce. Its UI is great. It's very easy to learn, so the cost of teaching new employees is low. It's hard to screw up, and when you do screw up, it doesn't require an expert to come in and fix things with obscure commands.

I'm genuinely curious if this isn't an effect of biased in favour of what you know (on both sides, possibly). I found Perforce to be terribly opaque. Perhaps this is because the good stuff is buried amidst enterprise nonsense, but compare the experience of going to git-scm.com versus perforce.com if your goal is to learn.

(Not to mention the fact that Perforce as I know it simply doesn't cover the distributed use cases that Git does. Obviously adding distributed features makes any VCS more complex, but that is the inherent complexity of the problem space as opposed to artificial complexity. If your problem is conceptually easier, you can make the solution appear easier.)

Re: Some bad Git situations and how I got myself out of them

#327

Post by hobarrera » 

    git add .
Ugh, no, never do this, never recommend to users to BLINDLY ADD ALL THE CHANGES FROM THE WORKING COPY. I honestly can't think of any worse git usage than this.

Add the single change you missed, or even better, `git add -p`, to add chunks manually.

Re: Some bad Git situations and how I got myself out of them

#328

Post by Hello71 »

jlebar wrote: post #262
overgard wrote: post #240

Earlier quoted context omitted.

God, it's probably billions. I love git but its user interface is borderline criminal. The sad thing is mercurial has like 95% of git's power and is waaay easier to understand, but it never took off in a big way.

$ hg clone https://bitbucket.org/eigen/eigen/ $ cd eigen $ time hg grep CUDA > /dev/null real 0m16.661s user 0m16.097s sys 0m0.531s $ git clone https://github.com/RLovelett/eigen.git $ cd eigen $ time git grep CUDA > /dev/null real 0m0.019s user 0m0.035s sys 0m0.057s Never looked back.

this is a highly misleading comparison. something slightly more accurate (although this time somewhat more hg-biased):

    $ time taskset -c 2 hg grep CUDA >/dev/null
    taskset -c 2 hg grep CUDA > /dev/null  25.04s user 0.46s system 99% cpu 25.514 total

    $ time taskset -c 2 sh -c 'git grep --cached -l CUDA | xargs -n 1 git blame >/dev/null'
    taskset -c 2 sh -c   4.85s user 0.13s system 97% cpu 5.097 total

Re: Some bad Git situations and how I got myself out of them

#329

Post by hobarrera »

overgard wrote: post #240
dep_b wrote: post #236

Somebody proposed to use a GUI. That doesn't solve the usability issues of Git. There's this triangle of what the user tries to do, what the commands and options are called and what they actually do. None of them really align, though with some careful use you can actually make Git do what you want - eventually. I would like to understand what's the yearly damage of such an important tool being so difficult to use. Pe…

God, it's probably billions. I love git but its user interface is borderline criminal. The sad thing is mercurial has like 95% of git's power and is waaay easier to understand, but it never took off in a big way.

Mercurial was a lot harder to understand for me, and had no staging index -- stuff is committed directly. I found that this made it incredibly hard to use, especially coming from git.

Re: Some bad Git situations and how I got myself out of them

#330

Post by hobarrera »

jlebar wrote: post #262
overgard wrote: post #240

Earlier quoted context omitted.

God, it's probably billions. I love git but its user interface is borderline criminal. The sad thing is mercurial has like 95% of git's power and is waaay easier to understand, but it never took off in a big way.

$ hg clone https://bitbucket.org/eigen/eigen/ $ cd eigen $ time hg grep CUDA > /dev/null real 0m16.661s user 0m16.097s sys 0m0.531s $ git clone https://github.com/RLovelett/eigen.git $ cd eigen $ time git grep CUDA > /dev/null real 0m0.019s user 0m0.035s sys 0m0.057s Never looked back.

The biggest differences for me are:

* Network effect. Almost any dev can use git, so it's our "common language". * Staging area. Mercurial doesn't have one, which I find is enough to make me never look back.

Post reply on HN