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

Git is too hard

changelog.com

Post reply on HN
Print view View original

651–660 of 821 posts

Re: Git is too hard

#651

Post by usr1106 »

rleigh wrote: post #465
simiones wrote: post #438

Earlier quoted context omitted.

How can you pull without using stash? Do you always commit everything before pulling? You also need the log daily to know things like "what changes made it into this build", or almost everytime I fix a merge conflict, to understand why something is the way it is. I can grant that cherry-pick & blame are more rarely used, though blame is often on by default in many editors, and cherry-pick is something my team does da…

I rarely use "git pull". Why would you? More typically, I will "git fetch origin" to fetch the current integration branches, then "git checkout -b origin/master" to start a new feature branch from a given integration branch, then push that once the change is completed. If I need to update a local copy of an integration branch, then I might well use "git pull". But I would never have any local changes made there which…

I basically never use git pull. I use git fetch and then I check (using git diff, git log or in confusing cases gitk) what I want to do. That could be merge (fast forward), rebase, ignore or either branch because the other one is just better. Of course often pull might do what you want, but when it doesn't people start to complain. So better avoiding surprises from the beginning.

Re: Git is too hard

#652

Post by weaksauce »

rjmunro wrote: post #212

The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…

I wish it wasn't coupled so tightly to emacs but magit is a phenomenal gui for git even for the more advanced use cases. if you know vim then spacemacs wraps it up in a more palatable package.

Re: Git is too hard

#653

Post by harrisonjackson »

simiones wrote: post #554
harrisonjackson wrote: post #496

Earlier quoted context omitted.

Small frequent commits will limit the need for stash. That's a good practice anyway. The others I'd say could be completely excluded from daily/weekly/yearly use. If you are using cherry or blame daily then there is probably something wrong :D

Why is small frequent commits a good practice? What is to be gained from committing a change to a file, then a commit to undo the previous one if you decide the change wasn't useful/needed? Also, cherry is often needed daily in short bursts around releases. Blame is rarer, absolutely, but I don't think you're using your version control to anywhere near its full potential if you don't use blame (and log) while investi…

The most important reason imo is making code reviews easier. Enormous PRs = less confidence in merging code on a team. If you are pushing small commits then it is easier for the team to follow the changes and review them.

- easier to merge and ship small incremental changes than large ones

- easier to revert small commits

- better commit messages since you can summarize the smaller change instead of "coded a lot of things"

- if you have a messy commit history in a PR you can squash them when merging upstream

I'm not sure what your git methodology is but I tend to avoid cherry.

We've got a clean production/master branch that we merge develop into on releases. We merge feature branches into develop. Very very rarely we may hotfix something on develop. I don't think I've used cherry in 6 or 7 years on repos with 2-30 active devs.

What are you using cherry for daily around releases?

Re: Git is too hard

#654

Post by markstos »

Darcs has a great UX. Please to use and still powerful. It inspired some small parts of the Git UX like the `--patch` mode for `git commit`.

The author of Darcs, David Roundy realized that Git was going to dominate so started a "best of both worlds" project that used the storage format of Git but the UX of darcs. That was called `iolaus` and never really launched as a usable project before was abandoned:

https://github.com/droundy/iolaus

That's still my preference for what a rethink of the Git UX should be.

By this point I've learned many of the pain points of Git. By having experienced Darcs, it's frustrating to teach Git to newcomers knowing the experience and ease of use could be so much better.

More context:

   * https://mark.stosberg.com/blog/2008/11/darcs_vs_git_annoyances_push_-dry-run.html
   * https://mark.stosberg.com/blog/2008/11/darcs_vs_git_annoyances_pushing_specific_patches.html

Re: Git is too hard

#655

Post by bmn__ »

StavrosK wrote: post #559
baq wrote: post #305

Earlier quoted context omitted.

let me tell you about gitk --all PS. git gui allows you to stage changes line-by-line, not just by hunk

What's `git gui`? It tells me the command wasn't found (though I use lazygit for that).

It's part of the Git release. Maybe your distro split this optional part out into a separate package, try installing `git-gui`.

Re: Git is too hard

#656

Post by [deleted] »

cesarb wrote: post #502
thaumasiotes wrote: post #254

Earlier quoted context omitted.

You really believe that git stores -- in full -- every version of a tracked file? Every commit that deletes the whitespace from an otherwise empty line in a 30KB file is another 30KB of hard drive space gone?

> You really believe that git stores -- in full -- every version of a tracked file? Yes, it does. > Every commit that deletes the whitespace from an otherwise empty line in a 30KB file is another 30KB of hard drive space Yes, it is. "It's worth repeating that git stores every revision of an object separately in the database, addressed by the SHA checksum of its contents. There is no obvious connection between two ver…

[deleted]

Re: Git is too hard

#657

Post by jcstauffer »

Meta comment: this thread has over 600 comments after 10 hours (one comment per minute) - most of which are of the form "I use it this way", or "here's a better way to do that" - thus proving the point of the article.

Re: Git is too hard

#658

Post by emidln »

briffle wrote: post #528
emidln wrote: post #495

Earlier quoted context omitted.

> and you have to ask a coworker or StackOverflow to rescue you... That or you could RTFM. That's what your coworker and the person writing on StackOverflow did.

I have read the manual many times. But when I only run into an issue once every 6 months to a year or so, its not exactly fresh on the mind. I still like to look it up again, to make sure I'm not working wrong from memory, and about to lose my work.

So you agree that you should Read The Fine Manual when you hit unfamiliar territory? My post wasn't aimed at saying git isn't complicated, but to encourage reading the thorough documentation of the tool giving you trouble rather than immediately shutting off the brain in the face of unfamiliarity.

Re: Git is too hard

#659

Post by wool_gather »

lhnz wrote: post #473
simiones wrote: post #447

Earlier quoted context omitted.

As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them. Also, git lfs and git submodules and their associated commands are necessary or not based on the project, not on your personal level of proficiency. I…

I've used both but generally don't use stash. I think it's more expressive to have a single commit like "wip: some simple description goes here" and then to `git commit --amend` this until we are happy with its contents. As well as being more descriptive if you come back after a long weekend, this also means that you can swap branches without worrying that your stash relates to a particular branch but doesn't explici…

Tip, instead of amending, it's also straightforward to "uncommit" a temporary commit when you come back to it. `git reset HEAD~` and the state of the commit becomes the state of your working tree instead.
Post reply on HN