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

Write yourself a Git (2018)

wyag.thb.lt

Post reply on HN
Print view View original

101–110 of 111 posts

Re: Write yourself a Git (2018)

#101

Post by krupan »

chousuke wrote: post #99
krupan wrote: post #96

Earlier quoted context omitted.

Mercurial is the same except: 0) you forgot to explain git's index. Mercurial doesn't have the index, it works how you described git. 2) data (blobs, revsets, whatever) in the repo actually can never be lost, there is no automatic gc 3) no need for some different tool/viewer to view commits that don't have refs Technically there are several ways to remove data from the repo, but it never ever happens automatically be…

The mental model helps me with git because it maps pretty closely to what data actually exists. The index is just a useful thing to help me put stuff into a repository in a controlled manner. I've never attained a similar transparent understanding of mercurial. I think I've asked this before, but what exactly are mercurial's branches? In git, they are a "physical" feature of the repository as it represents a set of l…

Mercurial uses a DAG just like git. It has facilities for embedding a branch name in each commit, or for not doing that and having anonymous branches. It also has a feature similar to git's "branches"

Two articles that might help if you really want to dig into it:

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...

https://bryan-murdock.blogspot.com/2013/06/git-branches-are-...

Re: Write yourself a Git (2018)

#102

Post by cabalamat »

influx wrote: post #54
cabalamat wrote: post #34

Earlier quoted context omitted.

> It seems that it was developed without any concern for affording a good mental model of its operation to its users I think Linus' design goal was something that runs as quickly/efficiently as possible on large repositories. > it is just a complex black box you chant arcane rituals at and hope it doesn't decide to burn your world down My feeling too!

No, his design goal was to create a vcs for the Linux kernel. Frankly most people use git like svn version 2, completely skipping the distributed parts of it. Git actually doesn’t scale to really huge monorepos.

> his design goal was to create a vcs for the Linux kernel

Which is a largish piece of software.

Re: Write yourself a Git (2018)

#103

Post by cabalamat »

huffstler wrote: post #51
cabalamat wrote: post #32

Earlier quoted context omitted.

> Your idea of a "user's mental model" might land you into trouble though If I do do this, I will explicitly lay out the user's metal model in the documentation at the start. Then it will be the user's fault if they can't be bothered to read it.

While gits documentation might not lay out the model at the start, they certainly have documentation showing how everything works, complete with diagrams and such. As such... > Then it will be the user's fault if they can't be bothered to read it. can be applied to you about git technically. I think that's just me being a "little" pedantic though. It sounds like the issue you actually have is that the documentation i…

> can be applied to you about git technically.

I have read large parts of the git docs. I don't like them. This is not just the text: the low contract colours and hard-to-read fonts are also factors.

> It sounds like the issue you actually have is that the documentation isn't easily readable in one or two sittings, and you don't have the time (or can't be bothered) to go through it and learn it.

So how long should it take to learn a VCS? And how long does git take to learn?

Re: Write yourself a Git (2018)

#104

Post by cabalamat »

neals wrote: post #33
cabalamat wrote: post #29

I have an admission to make: I don't understand git. By this I mean I have a few simple commands I use (status/add/commit/push/pull) and if I try to do anything more complicated it always ends up with lots of complex error messages that I don't understand and me nuking the repository and starting again. So I think: there must be a better way. I have often thought about implementing a VCS. The idea behind one doesn't…

I think this is a large majority of Git users. The last company I worked at had 30 good developers, 1 of which I think really deeply understood git. So I guess 97% of users don't really get git.

> The last company I worked at had 30 good developers, 1 of which I think really deeply understood git.

I think this is really damning. Developers understand complex languages/compilers like C++, Python, Java, etc, all of which have a good deal more intrinsic complexity than a VCS. So if a VCS isn't understood, it is badly designed.

Re: Write yourself a Git (2018)

#105

Post by cabalamat »

rsp1984 wrote: post #46
cabalamat wrote: post #29

I have an admission to make: I don't understand git. By this I mean I have a few simple commands I use (status/add/commit/push/pull) and if I try to do anything more complicated it always ends up with lots of complex error messages that I don't understand and me nuking the repository and starting again. So I think: there must be a better way. I have often thought about implementing a VCS. The idea behind one doesn't…

Just curious: Have you tried any of the git GUIs out there? There are many good ones: Fork, Git Tower, GitX-dev. I guess I would be lost as well just using the command line.

> Have you tried any of the git GUIs out there?

I regularly use Giggle.

> Fork, Git Tower, GitX-dev

None of these work on Linux. GitX-dev also has a website I have difficulty reading.

Re: Write yourself a Git (2018)

#106

Post by stouset »

ectospheno wrote: post #58
linkmotif wrote: post #53

Earlier quoted context omitted.

What makes it hard is that it’s taught wrong. All this pull/checkout/commit/push whereas for me it took a long time to discover that fetch/rebase/show-branch/reset/checkout —amend, and especially the interactive -p variants, are the core tools that really make it a pleasure to use. They give you flexibility and let you write and rewrite your story, whereas the commands you’re introduced with provide no control to the…

The rebase command is only safe if you never share a branch. Most people use a distributed revision control system to work with others and if you do work with others then rebase is dangerous and should not be used. Almost every rebase user I've spoken with has no idea what the danger is despite it being clearly discussed in the manual page for rebase and despite rebase being listed as dangerous every time it is menti…

I rebase pushed branches all the time if I’m the only one who is working on them, even for repos with multiple team members working on them. In almost a decade I can’t think of a single time this has caused problems.

Yes, don’t rebase branches with multiple authors doing parallel work. But I can’t think of many times I’ve even had to work on a feature branch with multiple authors.

Re: Write yourself a Git (2018)

#107

Post by GhostVII »

pjc50 wrote: post #85
palebluedot wrote: post #81

Earlier quoted context omitted.

Almost always, you can recover a bad rebase via git reflog.

That's true, but it's an obscure feature, not a convenient "undo" button; to the average insecure git user you might as well tell them that their work has been eaten by a dragon and they can recruit another dragon to get it back.

Reflog may not be known by the average git user, but I think it is pretty convenient - just call `git reflog`, copy the hash before the rebase, and checkout/reset to that hash. Doesn't get much easier than that.

Re: Write yourself a Git (2018)

#108

Post by chousuke »

krupan wrote: post #101
chousuke wrote: post #99

Earlier quoted context omitted.

The mental model helps me with git because it maps pretty closely to what data actually exists. The index is just a useful thing to help me put stuff into a repository in a controlled manner. I've never attained a similar transparent understanding of mercurial. I think I've asked this before, but what exactly are mercurial's branches? In git, they are a "physical" feature of the repository as it represents a set of l…

Mercurial uses a DAG just like git. It has facilities for embedding a branch name in each commit, or for not doing that and having anonymous branches. It also has a feature similar to git's "branches" Two articles that might help if you really want to dig into it: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... https://bryan-murdock.blogspot.com/2013/06/git-branches-are-...

Hmm, so the branch names are part of the commit's metadata. I'm not sure I agree with that, but I guess it's a valid choice.

The first article also states that unnamed branches are useful for small, temporary diversions, and notes that git has to name branches, but I think that's somewhat misrepresenting git since you can throw away names as soon as they are no longer useful. To me it seems kind of silly to have unnamed branches, given that names are free and much easier to remember than commit hashes.

Re: Write yourself a Git (2018)

#109

Post by AnIdiotOnTheNet »

pdonis wrote: post #93
AnIdiotOnTheNet wrote: post #90

Earlier quoted context omitted.

Personally I just rely on daily backup of my workstation and manually copied and compressed snapshots of the project when I feel significant progress has been made. I tried SVN once, but it wasn't very transparent what it was doing and didn't really enhance my workflow any.

Is all of your coding projects that you are working on by yourself? Or do you have to share code with other people?

All my personal projects are just me. When I contribute to open source projects I use whatever they use, which is usually git. At work, even though I am usually the only programmer on my programming projects, I use TFS because that's the company's process.

Re: Write yourself a Git (2018)

#110

Post by frosted-flakes »

cabalamat wrote: post #104
neals wrote: post #33

Earlier quoted context omitted.

I think this is a large majority of Git users. The last company I worked at had 30 good developers, 1 of which I think really deeply understood git. So I guess 97% of users don't really get git.

> The last company I worked at had 30 good developers, 1 of which I think really deeply understood git. I think this is really damning. Developers understand complex languages/compilers like C++, Python, Java, etc, all of which have a good deal more intrinsic complexity than a VCS. So if a VCS isn't understood, it is badly designed.

It's because it's so opaque and inconsistent. If git was a program like Microsoft Word, where every available action is easily discoverable and the current state is obvious, then it wouldn't be so bad. Something like what Nikita Tonsky wrote in an article called "Reinventing Git Interface"[0], which has a lot of good ideas.

[0] http://tonsky.me/blog/reinventing-git-interface/

Post reply on HN