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

131–140 of 821 posts

Re: Git is too hard

#131

Post by jariel »

exDM69 wrote: post #74
dimgl wrote: post #6

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…

Exactly. I like to say that git is a "white box". You need to understand the internals to be able to use it. Contrast this with "black boxes" where you don't have to or even can't understand what's going on. Some would argue that software shouldn't be built that way, but I will respectfully disagree. It's not an end user facing consumer product, it's a tool for professionals. You wouldn't expect anyone to operate a t…

"You wouldn't expect anyone to operate a table saw"

? Coming from a family of carpenters, I can assure you none of them really know that much at all about the internals of the table saw. Maybe a little bit.

The 'black box' analogy is upside down: there are a million artifacts of the computer that you use every day for which you have no understanding. We use encapsulated concepts to be able to leverage much more complexity than we would otherwise.

Having to deal with the 'inner workings' of git, is like having to have the instruction set for the chipset your computer is running on handy 'just in case'.

Git is very powerful, but very poorly designed from a product perspective, there was no 'strategy' just 'add commands and flags that do this and that'.

When products expose considerably more complexity than they need to for most uses cases, it's just bad design.

I also have a sneaking suspicion that so many 'git experts' are really just expert within a fairly narrow range of commands/options - because when I start to ask more detailed questions, the answers are never clear.

No other product has consistently caused so much confusion, wasted time. Though 95% of my personal interactions are fine, there are just too many times where we have Senior Developers, huddled on someone's machine, trying to solve some arcane problem - this is the 'not very hidden cost' of git.

I would say: "Within Git, there is a much smaller and clearer CVS struggling to get out."

Re: Git is too hard

#132

Post by em-bee »

zingermc wrote: post #83
ramraj07 wrote: post #38

Earlier quoted context omitted.

I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. With GitHub desktop you don't need to open the command line for any standard operations, I only need to use t…

I've definitely been the victim of my own git hubris. Once, when leaving a job, I decided to copy all of my local WIP branches to the server. I whipped out this fancy --mirror option I had just heard of: git push --mirror $remote Surprise! All branches on the remote repo got wiped. My local refs replaced the refs on the remote. Somehow I found the right commits floating around in the git ether. I was able to recreate…

mistakes happen. it is a testament to the power of git that your command didn't cause permanent damage. and yes, it could have been worse.

but if you want a system that protects you from these mistakes by making mistakes impossible, then you get a system that is very rigit and actually harder to use.

git protects you from these mistakes by making it possible to recover.

in this particular instance though, there could probably be some extra help to recover. (some way restore the removed refs)

Re: Git is too hard

#133

Post by blux »

remirk wrote: post #4

Git is one of those technologies where it's super important to get a good grasp of how to internals work. Once you got that, it get easier to answer git questions for others or yourself, and to read the documentation or man pages, as you know what is happening. With how software devs use git, it's 100% worth it to read a good book on it.

I agree in the sense that it is important to understand the underlying concepts of Git. Once that is clear in your mind, it becomes much easier to use.

When I explain Git to other people I explain it as a tool for manipulating commit graphs, where every node in the graph is a (merge) commit with some unique hash, where a commit itself is just essentially a patch on the previous node(s) in the graph.

Implementation details on how this commit graph is manipulated or stored behind the scenes are not important to understand Git in my opinion.

Re: Git is too hard

#134

Post by oopEnforcer »

I completely disagree. There is the very serious danger of replacing an elastic, very simple to learn system which is battle tested in real battles (like kernel development) with a fancy GUI or CLI that can only deal with 10% of the problems I can solve with Git.

Re: Git is too hard

#135

Post by h0l0cube »

secondcoming wrote: post #130
ramraj07 wrote: post #38

Earlier quoted context omitted.

I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. With GitHub desktop you don't need to open the command line for any standard operations, I only need to use t…

+1 These commands will get you 99% of the way: - git status - git branch - git pull - git add - git commit - git diff - git merge - git push - git checkout For everything else there's StackOverflow, but the info in there comes with the risk of being stale. -------------- Edit commit abaeb3b4: Add missing commands and improve formatting Edit commit 842babda: Add git checkout

`git status` is required to determine which untracked files you need to add. And then, of course, `git add` would be need to be added to the list too. To add untracked files you could use interactive mode `git add -i` and forgo reading `status`. But you can also `git commit -p` if you only modified files and forgo the `add` step.

And to give yourself a sense of the commit graph, these aliases come in handy

    [alias]
        lol = log --graph --decorate --pretty=oneline --abbrev-commit
        lola = log --graph --date=short --pretty=format:'%C(auto)%h %C(dim)%ad%C(auto)%d %s' --all
The only 'advanced' thing I commonly do is `git rebase -i` to squash a bunch of WIP commits. And a shell script I have to turn merged branch into a tag, and remove the branch.

The other day I had to remove a sensitive file that accidentally got checked into the repo for a couple of commits behind HEAD, and was glad that git had the power to do this in one line and without fuss. (Edit: but yes, I had to look it up on SE)

Re: Git is too hard

#136

Post by ubercow13 »

walty8 wrote: post #34
rusk wrote: post #20

Earlier quoted context omitted.

‘git checkout filename’ is the equivalent of ‘svn revert filename’

Yes, it works but not intuitive. I mean why use the checkout for the file reversion? And I think that's the problem of git: it's powerful and it works, but it's really not easy to get started.

It's like shorthand for git checkout -- . You're only omitting the current branch which is the default. I'm not sure if it's intuitive but it seems pretty coherent.

edit: on second thought no it's really not very coherent. If you exclude it means checkout all files if you write a , but no files if you write no . So excluding doesn't consistently do the same as using . I guess git does kind of suck.

Re: Git is too hard

#138

Post by HlessClaudesman »

Here is another approach:

Back in the bad old days before git I was in a 20-30 person company that used Microsoft's SourceSafe. For anyone unfamiliar it had a basic library type structure where only one person could get out (lock) a file at a time.

Now the obvious downside is that when someone goes on holiday or simply forgets those locked files can become blockers. The solution to that is to have an admin unlock the files, which was pretty easy, then a merge, which is basically what happens by default with git.

The upsides of the library approach were a) that I could scan the top directory, and quickly drill down to see who was working on what. b) I feel that walking over to someone's desk and asking if they were still working on a file produced some great back and forth, that was where the magic of collaboration actually happened.

Re: Git is too hard

#140

Post by giovannibajo1 »

> and there’s really good man page documentation now

Well, my pet peeve has always been git-tag. When I discuss about technical documentation, I actually use man git-tag as a reference of what NOT to do.

The summary (called NAME in manpages):

       git-tag - Create, list, delete or verify a tag object signed with GPG
... which might make sense but is already confusing to a beginner because of its reference to GPG (are all tags signed with GPG?).

But DESCRIPTION is actually the best:

       Add a tag reference in refs/tags/, unless -d/-l/-v is given to delete, list or verify tags.

       Unless -f is given, the named tag must not yet exist.

       If one of -a, -s, or -u  is passed, the command creates a tag object, and requires a tag message.
       Unless -m  or -F  is given, an editor is started for the user to type in the tag message.

       If -m  or -F  is given and -a, -s, and -u  are absent, -a is implied.

       Otherwise, a tag reference that points directly at the given object (i.e., a lightweight tag) is created.

       A GnuPG signed tag object will be created when -s or -u  is used. When -u  is not used, the
       committer identity for the current user is used to find the GnuPG key for signing. The configuration
       variable gpg.program is used to specify custom GnuPG binary.

       [... spoiler: it doesn't get any better]
So this should be a description that makes beginners understand git-tag.

Instead, it is a sequence of unrelated sentences that merely describes functionalities in response to command line arguments, in a very convoluted way (I think "If -m or -F is given and -a, -s, and -u are absent, -a is implied" is a little gem).

This is how I would write it:

       Create, view, and delete tags.

       By default, it creates a new “lightweight” tag, which is simple a reference to the current commit (eg: “git tag v1.2”). If you specify “-a”, a “annotated” tag is created instead; an annotated tag is still a reference to the current commit, but also remembers the date in which it was created, who created it, and optionally saves a message associated to the tag (like a “commit” message for the tag).

       Annotated tags can also be cryptographically signed with GnuPG, using “-s” instead of “-a”.

       You can also tag a commit which is not the current head by simply specifying it on the command line (eg: “git tag v1.2 abcde1234”).

       Use “git tag -l” to view the list of all tags.

       Use “git tag -d” to delete a tag.
So I think git still has a long way to go with documentation.
Post reply on HN