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

81–90 of 294 posts

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

#81

Post by __david__ »

cjhanks wrote: post #40
xyzzy_plugh wrote: post #39

Earlier quoted context omitted.

> And when I have to work with them, I really would prefer if git had something like `git save`. Which in the backend kept doing something like `git commit -a --amend`. This works fine, but it encourages squashing all your changes into a single commit, rater than providing you the opportunity to build a series of commits. Instead of `git commit -a` I have gotten into the habit of `git add -p` followed by `git commit`…

> I think, as you and others in this thread describe, the pain is that forming these lightweight commits is cognitively expensive -- but like all things, with experience and practice it becomes nothing at all. A person can only control their own behavior. :)

You can disable pushes to the master branch and (politely) refuse to merge bad commits.

Bad when I used darcs we used to give everyone permission to push to the main repo, but we'd aggressively unpull patches from the server that were bad.

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

#82

Post by shaan7 »

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…

Just keep a copy of the `.git` dir before you try the complex operation. If you screw it up, restore it back and voila!

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

#83

Post by popopopo »

lucideer wrote: post #80
popopopo wrote: post #64

Earlier quoted context omitted.

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…

If this is the "correct" way to learn, the problems are not with the user. A well designed ui should be learnable while being used - creating a fresh learning repo for dedicated learning for fear of losing data while using the tool in your "real" repo is the ultimate red flag in terms of usability.

a still, while people cry about UI (which is irrelevant part), other people just take time and learn git. by whatever measures.

PS. throwing out things you test on. isn't that how every programming tutorial works? write code NOT in your main repository, test things out, throw it away (or keep it, whatever)?

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

#84

Post by posterboy »

klodolph wrote: post #11

It's clear that there will be a successor to Git some day, in the sense that Git is a successor to SVN (yes, I know Linus's viewpoints on SVN). But the successor won't be a "better Git" just like Git isn't a "better SVN". The driving features of Git's successor will be unrelated to Git UI gripes. If Git's UI gripes were important enough, people would just be using Mercurial (which has it's own quirks). The biggest pr…

you could work in branches and merge after feature freeze, or you could, you know, colaborate and communicate intent before beginning to edit.

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

#85

Post by nhaehnle »

phillco wrote: post #19

Anecdotally, being able to commit anywhere, without needing a branch name, is one of the biggest conceptual differences when we teach new hires Mercurial at Facebook.

As a convinced Git user, this is the one aspect of the article that I found genuinely interesting. I mean, you can commit anywhere in Git, too (and I occasionally do for some advanced use cases), but it tends to not be well supported by Git.

(And, I might add, probably not by Hg either if it requires enabling an extension...)

Anyway, hg show work looks like an interesting thing. It's perhaps a bit more magic than Git usually goes for, since you can't just show all DAG sinks (it would get messy really quickly with amends and rebases). And I don't think I'd benefit too much from it, since I've come to prefer having all my work-in-progress on a single branch. But I can see how someone could appreciate the feature.

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

#86

Post by klodolph »

mikeyjk wrote: post #42
klodolph wrote: post #23

Earlier quoted context omitted.

Then it won't make it into production.

- "submit your changes and go home" - "production" The merge should happen far before it hits production. Maybe I'm taking you too literally or something. Do you have a CI/CD pipeline?

Workflow for the team I’m on right now:

* Make changes

* Run tests

* Code review

* Submit changes

CI pipeline will run larger integration tests, make releases, and deploy to production. We can cherry pick commits to fix bugs at this point. The pipeline will roll out releases to the development environment on a nightly schedule and to production on a weekly using canaries.

You can’t submit if your changes don’t merge cleanly. You’ll need to fix the changes and re-run tests (can be slow) at the minimum.

If you don’t submit by end of Wednesday you have to wait another week.

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

#87

Post by [deleted] »

nhaehnle wrote: post #59
carussell wrote: post #35

Earlier quoted context omitted.

Partial commits through piecemeal staging is great as a poweruser's tool, like rebase. But it's beyond weird that anyone thought it was a good idea to make people deal with staging for every commit. It doesn't even have to go away. (And on that note, I'm bummed that the conclusion in the article is to do that, especially because everytime this comes up, there's an uproar.) But, jeez. Just tuck it away so futzing with…

Git doesn't actually make people deal with staging for every commit, though. It's quite common to tell newcomers to always `git commit -a`, and `git add` for adding new files. That's pretty much exactly where SVN is/was, and nobody complained about that being complicated or onerous either.

[deleted]

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

#88

Post by _pmf_ »

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…

> when you accidentally kick a corner of a furniture, that does not make that furniture "dangerous".

When the piece of furniture has a serrated corner that cuts deep into your toe, you'll probably reevaluate the appropriateness of your metaphor.

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

#89

Post by sigjuice »

shaan7 wrote: post #82
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…

Just keep a copy of the `.git` dir before you try the complex operation. If you screw it up, restore it back and voila!

No. This does not safeguard any uncommitted files.

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

#90

Post by kazagistar »

xenomachina wrote: post #63
gumby wrote: post #12

I'm surprisedly the staging-area hate. Does it really violate peoples' assumptions? I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.

How do you test the thing you're actually committing without everything else in your working tree contaminating your test? There are ways to do this using stash but if you stash before you commit, you get merge conflicts when you pop the stash. The workaround I've seen is to commit before you stash, but that means you're also committing before you've actually tested that change, which seems pretty broken, IMHO.

Commits are just a bit of local data. Until you push it out somewhere public, it's all just a big mushy pallette to do with as you will.
Post reply on HN