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

251–260 of 352 posts

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

#251

Post by sergiosgc »

leejo wrote: post #43
Illniyar wrote: post #7

Actually the easiest thing is simply not to care about how your log looks. If you don't then there are ry only two things you need to know how to do: If you didn't push to origin do an ammend. If you did, revert soft and commit the previous code to revert it (you can also put a stash or patch to apply it back). Which frankly is what the article does, basically.

> Actually the easiest thing is simply not to care about how your log looks. You need to expand on this because i don't quite understand what you mean, are you talking about "fix typo" commits or are we getting to the level of just committing away until things work and then not cleaning up the work later on? The linked article doesn't cover rebasing or squashing commits, which can be pretty powerful when used correct…

Develop on feature branches, merge with master only when the feature is done. Always merge with --no-ff. Then, when reviewing history, on the master branch you can use either "git log" or "git log --first-parent master". The first log is the complete log, with exploratory development, mistakes, backtracks and such. The second is the clean log people keep rewriting history to obtain.

You get your cake and you can eat it too.

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

#252

Post by busterarm »

eyelidlessness wrote: post #34

I can't believe no one has responded yet with "use a GUI". After gaining a basic understanding of how branches and merges work, and I do mean basic , I've never been able to screw up a local repo with a GUI client enough that I haven't been able to recover with the same GUI tools. I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs pro…

I've worked with a guy who only uses GUI tools for Git and he's supposed to be a senior dev and doesn't know how to resolve a simple merge conflict and regularly wipes out other peoples' work with whatever he's doing with the tool.

No thanks.

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

#253

Post by exDM69 »

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.

> 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 inconsistent UI in Git, but the damage is already done. There's no point in making major changes now (some renaming for consistency might be alright, though), it would be breaking existing workflows and scripts.

I find the best explanation of how Git works is... the first commit of Git[0] itself.

[0] https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...

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

#254

Post by pmoriarty »

I've heard advice from #git on freenode not to use "git commit --amend", especially on shared repos.

I wish I still had a log of the conversation or remembered the exact problem that led up to it, but it involved a simple amend totally screwing up my repo, and I've avoided it since.

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

#255

Post by ewjordan »

wkd wrote: post #65
ewjordan wrote: post #58

Earlier quoted context omitted.

"Not the friendliest of beasts" is putting it mildly. Git is basically Linus in a nutshell: abrasive, unforgiving, and behaving like an absolute asshole to any non-expert struggling user. Sure, engineers should probably get to know its quirks and learn to work around them because it's now ubiquitous in the field, but let's not pretend that there's something virtuous about it. This is a piece of truly terrible softwar…

I'm struggling to see which VCS you deem superior, I'm assuming you are not referring to SVN, Mercurial maybe? The learning curve to git is not great but as far as I know nobody has publicly released an option that's improved enough over git to motivate the cost of switching technology. If it's not working for you the only advice I can give is either learn it until it is actually working for you rather than being in…

Yep, Mercurial's the one. It's a shame that it lost the war, they actually seemed to care about providing a good experience to their users. There are, of course, a few technical differences between it and git, but I personally never felt like they were troublesome enough to make up for the vast difference in usability.

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

#256

Post by nchelluri »

pmoriarty wrote: post #254

I've heard advice from #git on freenode not to use "git commit --amend", especially on shared repos. I wish I still had a log of the conversation or remembered the exact problem that led up to it, but it involved a simple amend totally screwing up my repo, and I've avoided it since.

I upvoted and am hopefully awaiting a response from someone who can chime in and explain why this is a problem.

Amend after push, I could see. You commit, push, amend, push, but after your first push someone else pushes... then you have two heads. I could see that, but I'm guessing you'd mention that if it were the case.

If one were to attempt avoiding amend you could always make all changes in a feature branch and rebase this branch onto your target afterwards, squashing commits.

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

#257

Post by maw »

pmoriarty wrote: post #254

I've heard advice from #git on freenode not to use "git commit --amend", especially on shared repos. I wish I still had a log of the conversation or remembered the exact problem that led up to it, but it involved a simple amend totally screwing up my repo, and I've avoided it since.

It's much like rebasing, with a similar set of benefits and drawbacks.

Once other people can be expected to have done work based on your amended or rebased work, you can expect some annoyances (or worse). If you haven't pushed yet (or if you're really, really sure nobody's basing further work on something you've recently pushed), I say go crazy and amend and rebase to your heart's content.

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

#258

Post by ewjordan »

brusch64 wrote: post #69
ewjordan wrote: post #58

Earlier quoted context omitted.

"Not the friendliest of beasts" is putting it mildly. Git is basically Linus in a nutshell: abrasive, unforgiving, and behaving like an absolute asshole to any non-expert struggling user. Sure, engineers should probably get to know its quirks and learn to work around them because it's now ubiquitous in the field, but let's not pretend that there's something virtuous about it. This is a piece of truly terrible softwar…

What are the superior foes in your opinion ? I don't know any of the other distributed version control systems. The only other version control system I have much (too much) experience with is Subversion and it can't hold a candle against Git. In my opinion Git is the C language of version control systems. If you are careless it's not the tool for you. Otherwise you have a really great tool with lots of power.

People have already mentioned it, but since I made the original comment, I'll pile on and say that Mercurial was (well, still is, but it's out of fashion now) awesome. It matches Git on most axes and blows it out of the water when it comes to usability and "don't shoot yourself in the foot"-ishness.

Brushing aside some relatively minor differences, Mercurial is very similar to Git, except that it was designed by people that don't have an all-consuming disdain for all of humankind.

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

#260

Post by ewjordan »

Singletoned wrote: post #73
ewjordan wrote: post #58

Earlier quoted context omitted.

"Not the friendliest of beasts" is putting it mildly. Git is basically Linus in a nutshell: abrasive, unforgiving, and behaving like an absolute asshole to any non-expert struggling user. Sure, engineers should probably get to know its quirks and learn to work around them because it's now ubiquitous in the field, but let's not pretend that there's something virtuous about it. This is a piece of truly terrible softwar…

> Git is basically Linus in a nutshell: abrasive, unforgiving, and behaving like an absolute asshole to any non-expert struggling user. You forgot "brilliant".

Fair point. For all my whining, I use both Git and Linux every day, they are incredible pieces of technology, especially compared to what came before.
Post reply on HN