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

91–100 of 111 posts

Re: Write yourself a Git (2018)

#91

Post by james-mcelwain »

palebluedot wrote: post #80
pierrebai wrote: post #68

Earlier quoted context omitted.

Not rebasing does not affect reviewing a branch in the least, unless your diff software is seriously broken. Comparing a branch to trunk shoudl only shows the actual difference. That you merged trunk multiple times shoudl have zero bearing. The only way it could ever confuse anyone is if they review every commit and somehow fail to pass over merge commits. The single most aggravating thing in git are its self-appoint…

Feature branches really should be rebased to have clean self-contained logical commits prior to merging, and this goes beyond just making it easier to review (although that is an important point). It's good git hygiene! No individual commit should break the build; one reason is to keep git-bisect working well for future users bug-hunting, without getting stopped because someone didn't keep the commits on their dev br…

Absolutely. Personally, I like to spam commits while I'm developing, just to make sure I keep track of what I've done while I'm iterating, but none of this is relevant to the final merge. Any individual commit on my feature branch may not even compile, but when that feature is applied to master, I want it to be a clean atomic commit that can easily be reverted or applied to other branches.

Re: Write yourself a Git (2018)

#92

Post by camgunz »

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…

In a lot of workflows I've used, we _always_ rebase against before pushing a PR, the virtue being that the history is cleaner. I definitely don't think it deserves the huge "NEVER USE" sticker you're slapping on it. I use it multiple times a day.

Re: Write yourself a Git (2018)

#93

Post by pdonis »

AnIdiotOnTheNet wrote: post #90
pdonis wrote: post #64

Earlier quoted context omitted.

Are there other VCSs that you find it easier to understand and build a mental model of?

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?

Re: Write yourself a Git (2018)

#94

Post by chousuke »

AnIdiotOnTheNet wrote: post #31
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…

Yeah, I too don't really understand git. It seems that it was developed without any concern for affording a good mental model of its operation to its users, and thus it is just a complex black box you chant arcane rituals at and hope it doesn't decide to burn your world down. I know I could build a mental model of it if I put enough time into it, but who wants to do that when there's actually useful things to do? So…

I have the exact opposite problem. I have a mental model of git, but not a very good one for most of its competitors; I don't really get mercurial for example, but git is just:

1) uncommitted stuff in workdir. Potentially can be lost, so commit often.

2) blobs in repo representing snapshots at commit time. Can never be lost.

3) symbolic references to the blobs. Can always recover from reflog.

4) tools to sync the above two things between repositories. (fetch and push)

5) tools to merge, diff and otherwise manipulate the changes between snapshots and files.

I'm confident that git will never lose my data, so long as I commit it. This makes experimentation stress-free.

Technically, you can lose data by explicitly deleting your refs, expiring the reflog, and running gc, but if you go that far you might as well rm -r .git

Re: Write yourself a Git (2018)

#95

Post by chousuke »

tsukikage wrote: post #83
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…

git is to version control systems as vim is to text editing or dwarf fortress is to god sims. (dear everyone here and elsewhere recommending git incantations "but of course you have to know what you're doing": if you regularly have to take a backup of your working area before interacting with the vcs, because the interaction may do things you did not intend from which the simplest way back is to reset hard and start…

I'm not sure if I'm reading your comment right, but if you're going to do something that might result in a mess (such as a merge or a rebase) the sane thing to do is not to have anything uncommitted in your workdir; that way you can always retry, undo and experiment, and the VCS is doing exactly what it's supposed to be doing.

It's something subversion can't do last I checked, so whenever I need to do a complicated operation with SVN, I import the local state into a git repo first :P

Re: Write yourself a Git (2018)

#96

Post by krupan »

chousuke wrote: post #94
AnIdiotOnTheNet wrote: post #31

Earlier quoted context omitted.

Yeah, I too don't really understand git. It seems that it was developed without any concern for affording a good mental model of its operation to its users, and thus it is just a complex black box you chant arcane rituals at and hope it doesn't decide to burn your world down. I know I could build a mental model of it if I put enough time into it, but who wants to do that when there's actually useful things to do? So…

I have the exact opposite problem. I have a mental model of git, but not a very good one for most of its competitors; I don't really get mercurial for example, but git is just: 1) uncommitted stuff in workdir. Potentially can be lost, so commit often. 2) blobs in repo representing snapshots at commit time. Can never be lost. 3) symbolic references to the blobs. Can always recover from reflog. 4) tools to sync the abo…

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 behind your back.

Re: Write yourself a Git (2018)

#97

Post by jancsika »

Deganta wrote: post #73
influx wrote: post #54

Earlier quoted context omitted.

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.

That's because most users don't actually need the distributed part of git. For most projects the sanest solution is to have a single master repository that all users pull/push from/to. IMHO the only real advantages over SVN for most users are the better branch/merge functions.

In other words-- git is so good at being decentralized you only notice the consequences in the improved branch/merge UX.

Re: Write yourself a Git (2018)

#98

Post by s4vi0r »

sransara wrote: post #42

Thanks for sharing. I too agree on this: "... Git is complex is, in my opinion, a misconception... But maybe what makes Git the most confusing is the extreme simplicity and power of its core model. The combination of core simplicity and powerful applications often makes thing really hard to grasp..." If I may do a self plug, I had recently written a note on "Build yourself a DVCS (just like Git)"[0]. The note is an e…

Inconsistent commands are pretty annoying - why is it git stash list instead of git stash -ls or --list?

Re: Write yourself a Git (2018)

#99

Post by chousuke »

krupan wrote: post #96
chousuke wrote: post #94

Earlier quoted context omitted.

I have the exact opposite problem. I have a mental model of git, but not a very good one for most of its competitors; I don't really get mercurial for example, but git is just: 1) uncommitted stuff in workdir. Potentially can be lost, so commit often. 2) blobs in repo representing snapshots at commit time. Can never be lost. 3) symbolic references to the blobs. Can always recover from reflog. 4) tools to sync the abo…

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 lineages, not an actual repository object.

As such, any reference to a commit uniquely identifies a branch, so the concept of a "named line of development" is simply implemented as a reference that gets updated as you make more commits. When you "delete" a branch in git, it goes nowhere. Only its name is removed.

What sort of structure does mercurial use to represent its branches? I know they are not just an emergent thing like in git.

Re: Write yourself a Git (2018)

#100

Post by [deleted] »

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…

[deleted]
Post reply on HN