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

Oh shit, git: Getting myself out of bad situations

ohshitgit.com

Post reply on HN
Print view View original

351–360 of 520 posts

Re: Oh shit, git: Getting myself out of bad situations

#351

Post by rdiddly »

pc86 wrote: post #152
taoistextremist wrote: post #45

Earlier quoted context omitted.

We SSH onto a server to do work and it seems we just make folders wherever for our individual projects. They do (nightly, I think) backups which is sort of a rudimentary version control. And while I'm told it exists, it seems the "dev" version of their website isn't used, so they just kind of add in their changes live; definitely a risky environment. They've had a small team for a while and most of their applications…

Yeah the "right way" to do VCS is definitely a lot of overhead for a team like that, but by the time you need to scale up (and by "up" I mean 3-6 people total who are committing code multiple times daily?) the business is likely so busy it's a HUGE uphill battle to implement something like that, especially since most of the people who let an environment like that happen will likely not be super familiar with Git/hg/T…

I dunno if I'd agree that it's a lot of overhead, for what you get back. Hell I'm a one-man team right now and I'm using source control. Some of my little experiments go horribly awry. Some of my deletions are a bit too aggressive/arrogant. Sometimes you need to diff shit. Version control frees me to be bold.

Re: Oh shit, git: Getting myself out of bad situations

#352

Post by dhimes »

satish-setty wrote: post #278
trevor-e wrote: post #196

I think Git would be way more approachable if things were named better. A key part of Git is whether a file is untracked/unstaged/staged, yet the terminology around this is very confusing. Why aren't commands simply `git stage`, `git unstage`, `git add` (to track files), `git remove` (to untrack), `git undo`, etc? Not to mention the overloaded command names like `git checkout`, how is `git checkout -- someFile` intui…

This is precisely one reason I like Mercurial over Git. Hg has commands which are more meaningful than those of git.

+1 hg. I see it mentioned so seldom here that I'm actually worried it may go away.

Re: Oh shit, git: Getting myself out of bad situations

#353

Post by dhimes »

teilo wrote: post #51

I stubbornly stuck with Mercurial for a long time because of the complexity of git's UI. But when one moves beyond a few developers, the available tooling and extensive ecosystem for git makes it inevitable.

Still with hg. You've frightened me.

Re: Oh shit, git: Getting myself out of bad situations

#355

Post by ksk »

mmmpop wrote: post #86
lwansbrough wrote: post #42

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…

> I think anyone who uses the CLI is either trying too hard Why do you think it's okay to share this opinion?

The problem of course is the question - What gives anyone a right to do anything? What gives you the right to police the comments? What gives me the right to question your questioning? Meta-discussions always get sidetracked..

Re: Oh shit, git: Getting myself out of bad situations

#356

Post by lmm »

sirmarksalot wrote: post #328
Nullabillity wrote: post #209

Earlier quoted context omitted.

You already have git-revert, for reverting commits without rewriting history.

Git revert has undesired side effects for merges. If you have a merge-only workflow (GitFlow, for example), and your pull request breaks something, a revert commit will not help you. After a revert, all the commits that were merged, are still merged, but then they're deleted. The next time you pull, git will delete the changes in your working branch. In a merge workflow, you have to either fail forward (fix the probl…

Create a feature branch, revert the revert, and then fix the problem. It sounds a little weird but it works fine.

Re: Oh shit, git: Getting myself out of bad situations

#357

Post by sfink »

You could also use an alternative CLI for git. My preferred one is hg-git.

I'm sort of kidding, but not really. By using it, I can operate on a git repo using the mercurial CLI, which I am more comfortable with and have built tooling around.

Once you have the extension installed, it's a matter of prepending 'git+' to the beginning of eg a github url to clone it, and then you can use native mercurial commands.

Obviously, this is an extra layer with all of the problems that involves (eg you're going to be managing git branches through an hg interface. Which works surprisingly well most of the time.) So this makes NO SENSE WHATSOEVER unless (1) you are comfortable with the hg interface, (2) you aren't that comfortable with the git interface, and (3) you don't need to do complex operations that would require thinking through the layers of what is happening.

Honestly, though, if I want to contribute to a github repo, this gives me everything I need 95% of the time. So far, the only time I ran into trouble was when the active branch was renamed in the github repo. Things got very tangled up, and I had to re-clone and import my patch stack. Judging by the number of people talking about making "backups" of git repos in this comment section, it doesn't sound like that's an unexpected operation in git-land. With mercurial's immutable and append-only nature, I very very rarely need to do this, so it felt kind of awful.

(Admittedly, my main hg repo that I work on is 6GB and I'm normally near the limit of my disk space, so my habits don't really match your typical megabyte-sized github repo in some noncompiled language.)

Re: Oh shit, git: Getting myself out of bad situations

#358

Post by lmm »

swalsh wrote: post #261
Nullabillity wrote: post #209

Earlier quoted context omitted.

You already have git-revert, for reverting commits without rewriting history.

You're misunderstanding the purpose i'm describing. Imagine 100 commits a day, maybe more. (I worked at a company that averaged 500 or more commits a day to the master branch. There were 1000 developers working in a monorepo). Some code is out in production, and suddenly we realize a specific commit is causing a problem. The idea here is to revert the commit as soon as you can, and then spend your time fixing it. Whe…

> But to enable this "revert-first" culture, you have to design your commits to basically be super easy to revert. That means no merges in the master branch, you want to keep your revision history as clean as possible.

How are these concepts related to each other? Merges don't make reverting any harder.

Re: Oh shit, git: Getting myself out of bad situations

#359

Post by falsedan »

mmmpop wrote: post #337
Angostura wrote: post #119

Earlier quoted context omitted.

What makes you think it is not?

It's not constructive, who cares what you think about CLI users? The fact I'm being downvoted says a lot about the state of this forum.

Your comment was also trolling: I would have avoided the leading question and just commented on the probable negative interpretation the some CLI users might make of the comment.

Re: Oh shit, git: Getting myself out of bad situations

#360

Post by ryanbrunner »

DougBTX wrote: post #335
ryanbrunner wrote: post #99

Earlier quoted context omitted.

To be fair, git is the first VCS I've ever used where there was any real learning curve at all for normal, everyday use. I don't recall anyone ever really teaching me subversion, outside of maybe 5 minutes walking through the GUI. With git I feel like it probably took a few months of regular use before I felt comfortable with it. That doesn't mean that I'd go back to subversion, but I don't think it's fair to say it'…

I remember trying to do merges in SVN years ago, it was so hard my team agreed to just never make new branches. Git it so much easier to use, it seems hard to compare.

For branching / administration you're probably right. Typically though, subversion workflows would involve administrators doing most of the heavy lifting of branching / merging and everyone else working against those - for those users Subversion was absolutely easier.
Post reply on HN