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

191–200 of 294 posts

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

#191

Post by littlestymaar »

dboreham wrote: post #179
3minus1 wrote: post #139

Earlier quoted context omitted.

Does anyone who's downvoting this comment care to explain why?

Because git dies not have good documentation. Perhaps that's unfair to the documentation in that it does a good job of detailing commands and their options, but is urinating into a hurricane as far as trying to convey any notion of conceptual integrity for a piece of software that has none.

What about https://git-scm.com/doc ?

I wish all the software I use had a documentation half as good as this one.

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

#192

Post by imtringued »

majewsky wrote: post #102
__david__ wrote: post #68

Earlier quoted context omitted.

Sometimes I find myself doing "git stash; git stash apply" just so I have a checkpoint of what I'm working on. That plus "git stash list -p" lets me go back through tons of non-checked in junk to find (say) that one line of debugging code that turned out to be pretty useful…

You can do small temporary commits on a branch, and once you want to do an actual commit which will then be pushed, you go onto the master branch and `git merge --squash `.

Microtutorial for git:

`git clone https://repository.url` (download repository)

`git checkout -b issue_XXX` (create new branch with the name 'issue_XXX')

`vim README.MD` (edit a file)

`git add README.MD` (mark the file to be committed, `git reset README.MD` to unmark)

`git status` (see list of changed/marked files)

`git commit -m "Add Readme"` (create commit based on marked files)

`vim README.MD`

`git add README.MD`

`git commit -m "Fix Typo"`

`git checkout master` (switch to branch with name 'master')

`git merge --squash issue_XXX` (merge branch with name 'issue_XXX' into current branch (master), but stop before committing)

`git commit -m "Add Readme.MD"` (create a new commit)

`git push` (upload changes)

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

#193

Post by CSMastermind »

taeric wrote: post #22

If you requested save in your favorite GUI application, text editor, etc and it popped open a select the changes you would like to save dialog, you would rightly think just save all my changes already, dammit I'm sympathetic to what this is asking, but I have to feel that this would lead to much better practices for many people. I'd wager a ton of folks would be more "why in the world does it think I changed that?" t…

On source control anti-pattern I've run into is people thinking a commit is a 'save'. It's not. A commit should move you from one working state of your code to another. Compare that to saving my files which I do compulsively every 5 minutes or so regardless of the state the file is in.

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

#194

Post by AlexCoventry »

mschaef wrote: post #142
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…

> I don't think it's as appreciated that git's complexity generally discourages people from trying things out. For me, at least, the underlying model actually makes it easier to try things out. As long as my work is in commits and I have refs that point to those commits, I can be pretty sure that I'm not going to lose anything. I also take a fair amount of comfort in the fact that (unlike, say, SVN), any remote actio…

> I don't think it's as appreciated that git's complexity generally discourages people from trying things out.

Personally, I'm not shy about recursively copying the entire repository on disk to run potentially destructive experiments in a duplicated environment.

Also, once you understand how to pull things out of the reflog, it's usually not hard to restore to a sane state.

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

#195

Post by jononor »

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. Commit your changes and mark it. For instance by creating a branch.

git commit -a git checkout -b before-complex-operation ...

To get back to where you were, git checkout before-complex-operation

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

#196

Post by radarsat1 »

qznc wrote: post #113
sharp11 wrote: post #20

Lots of food for thought in this article, but the part I find most interesting is his distinction between "soft" and "hard" forks. (Viz., are you "forking" in order to collaborate or in order to go your own way?) If collaborate, it would be nice to lower the barrier to participation ... more like Wikipedia. I know that I often don't bother to submit a PR for small changes bc of the overhead of setup. Whereas I fairly…

I don't know why Github does not make this easier. What I would like to do is: git clone https://github.com/mozilla/DeepSpeech [... edit & commit ...] git push # Github automatically creates and pushes to a branch called qznc/master [ one more click to open a pull request ] All this assuming I have no write access to the repo and without creating a repo at https://github.com/qznc/DeepSpeech .

Absolutely. I've never understood the reason for requiring you to make a fork, just add my changes to the PR (in an anonymous branch for example) and be done with it! I don't want to 'fork' your repository to propose a spelling mistake fix.

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

#197

Post by jononor »

CSMastermind wrote: post #193
taeric wrote: post #22

If you requested save in your favorite GUI application, text editor, etc and it popped open a select the changes you would like to save dialog, you would rightly think just save all my changes already, dammit I'm sympathetic to what this is asking, but I have to feel that this would lead to much better practices for many people. I'd wager a ton of folks would be more "why in the world does it think I changed that?" t…

On source control anti-pattern I've run into is people thinking a commit is a 'save'. It's not. A commit should move you from one working state of your code to another. Compare that to saving my files which I do compulsively every 5 minutes or so regardless of the state the file is in.

I agree, but... It is nice that one can compulsively (or automatically) save, with full history. And then when things are in a nice working state, be able to distill this into one or more clean changesets.

`git rebase -i` makes this relatively easy/nice. I think even better tools for this would make it way more realistic to get away from the staging area as step in the default 'commit' process.

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

#198

Post by imtringued »

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.

Create a new branch for each issue where you create broken untested garbage commits with meaningless messages like "Fix".

When you're done:

git checkout master

git merge --squash

git commit -m ""

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

#199

Post by jwilk »

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.

You probably want "git add -N"; otherwise "git diff" won't work as expected.

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

#200

Post by jononor »

CJefferson wrote: post #130
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.

My problem with the staging area is it produces commits which never "exist" (that is, that code was probably never compiled/tested in isolation). I'd be happier if the staging area was handled at the filesystem level, give me a directory which at all times contains the staging area, so I can test it.

Your CI system can test those commits in isolation. I frequently push supposed-to-be-stable commits like that alone to my working branch on Github, so Travis CI can tell me if I have a problem. Though I'm quite picky about commits, that each merge point into mainline (master) is tested is what is most important to me. Github PRs with Travis CI for instance enforce that pretty OK. If I don't bother to do a PR, and the changes as a linear set upon master, I like to use git merge --no-ff master to force a merge commit.
Post reply on HN