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

161–170 of 352 posts

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

#161

Post by mhw »

One of the nice workflows that's already built in to the git command line tools is this one. When you're working on a branch and realise that a commit you made a few commits back has a mistake in it:

    # Make correcting change
    git commit --all --fixup=
    # Continue working on branch, then at some point
    git rebase --interactive --autosquash
The --fixup option creates commits with subjects formatted like 'fixup! previous commit subject'. --autosquash uses these subjects when building the interactive rebase list.

Handy enough that I set rebase.autoSquash to true in my ~/.gitconfig so 'git rebase -i' always works like this.

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

#162

Post by Zardoz84 »

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 feel more comfortable and faster using git commands that a GUI.

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

#163

Post by majewsky »

Waterluvian wrote: post #145
jimktrains2 wrote: post #144

If the owner is here: with javascript disabled the code is unreadable.

I'm curious, what would you say the % of sites you visit is where they're still useful without JS?

That question is not very useful the way it's written down. Some sites legimitately require JS (everything in the "web apps" territory; just try to imagine Grafana without JS), so I would ignore these (which I hope is in line with your intentions).

Of the sites that are mostly static content, I would estimate around 60%. There's a small chunk of sites that are just blank with JS disabled, and there's a larger chunk that will load images only when JS is enabled.

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

#164

Post by majewsky »

mcv wrote: post #140
ZeroGravitas wrote: post #97

Earlier quoted context omitted.

Ah, interesting. I'd noticed this behaviour but hadn't conciously thought about it. The docs say: All changes made by commits in the current branch but that are not in are saved to a temporary area. This is the same set of commits that would be shown by git log ..HEAD

If they're not in upstream but they are in another branch, it's still dangerous.

Well yeah, sometimes this power is needed. For example, I might need to do a rebase over published history to remove a patch that was found to be a copyright infringement.

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

#165

Post by apk17 »

Annatar wrote: post #54
mathieuh wrote: post #20

I absolutely love git now. I'm still at uni (at a highly ranked but actually crap university where we don't learn git properly) and this year was my 'year in industry' as we call it in the UK, and my first proper experience with git, aside from `git init` at the end of my project and pushing it to a repo. I've become so much more confident with git. Seriously, with one caveat (i.e., you haven't pushed your changes to…

it is almost impossible to break irrevocably. This tells me you still don't get the point about using a revision control system: the whole point is NOT that you can hack the revision control system's database every which way, but that you can never, as in ever, break something in a repository, because you can always revert the previous commit and do a new commit of that revert . Keeping it simple since January 1st, 1…

And? You will have some kind of 'blessed' repo anyway. In git you disable non-fast-forward pushes there (aka prevent commits from ever being removed) there, and implemented your 'point'.

See also 'svn obliterate'.

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

#166

Post by majewsky »

pluma wrote: post #112
brusch64 wrote: post #69

Earlier quoted context omitted.

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.

I've heard a lot of people who seem to know their stuff say that Mercurial is superior to Git in almost every way, especially when it comes to integrating with other tooling (i.e. Mercurial seems to have an API whereas automating Git boils down to spawning shell commands). This also seems to be why Facebook switched from Git to Mercurial: they needed to be able to check out individual folders from a branch and Git si…

What's so bad about spawning shell commands?

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

#167

Post by jerf »

majewsky wrote: post #158
chungy wrote: post #154

Earlier quoted context omitted.

git fsck

This. Also, hold on to the commit before you started refactoring (preferably by placing a temporary branch there, in order to avoid premature garbage collection). Then after your refactoring is done, `git fsck` and `git diff --stat $old_branch..HEAD` to verify that you did not lose any important content during the refactoring.

That is true in general. However, in the context of bfg-repo-cleaner, that doesn't help, because the purpose of the bfg-repo-cleaner is to completely remove commits that match the criteria you give it. I say this not to "correct" you per se, because you are correct, but to ensure that people using bfg-repo-cleaner do not believe that this will help them.

The "correct" course of action prior to using the bfg-repo-cleaner is to make a complete copy of the target .git directory. I've used it many times and it seems quite reliable, but if nothing else, that's a good defense against terminating it halfway through accidentally or something. (Of course even without that, you shouldn't be operating on the only copy of your .git repo anyhow since it is almost certainly somewhere else, too, or you wouldn't be having the problem bfg-repo-cleaner is designed to solve in the first place. But losing your own local branches and work is still a pain.)

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

#168

Post by dboreham »

ewjordan wrote: post #58
noufalibrahim wrote: post #12

I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves problem Y" will always break down. Version control systems are an important part of the programmers toolkit and it's worth investing a little time to get the fundamentals right. Sure git is not the friendliest of beasts but what it lacks in interface, it more than m…

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

First time I've wanted to upvote twice!

I think besides a PR battle (there's PR people for RCS'es??) I think Git won out because "the server was free". Competitors at the time needed a big (if there were large numbers of committers) server that someone had to pay for. By that I mean the hardware to host the server -- Git needs either none, or a very lightweight machine for a server.

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

#169

Post by totallymike »

zubspace wrote: post #67
wfunction wrote: post #15

Surprised there was nothing on messed-up merges or rebases. They're some of the worst to get out of when you're not totally comfortable with git yet.

Any points on how to continue from there? Been in a few "I give up" conditions during rebases that I completely stopped trusting git it any way. The thing is, some repositories on github require you to commit only after proper rebasing. But I can never in my life remember how and need to google it...

If you ever get yourself in a situation during a rebase, or find that a rebase went wrong, have a look at `git reflog`.

Running it gives you a log of all the things `HEAD` has ever pointed at, meaning you can find what you had before a rebase and check that out.

    git reflog
    git checkout HEAD@{10}
And you're usually good to go.

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

#170

Post by inopinatus »

hacksonx wrote: post #35
keyanp wrote: post #31

Earlier quoted context omitted.

For posterity, `rmdir` will only remove empty directories. The author presumably should have used `rm -rf`.

I think the command we're looking for is 'rm -R name_of_directory'

Honestly, the proper command is not rm at all, because you can then have an "oh shit I forgot something" moment. I have learned (the hard way) to retain even an horribly broken repo, but shove it out of the way. Because disk is cheap, repeating work is expensive.

So that example should have been:

    cd ..
    mv fucking-git-repo-dir fucking-git-repo-dir.archived.$(date +%s)
    git clone https://some.github.url/fucking-git-repo-dir.git
Post reply on HN