[HN Gopher] Things I wish everyone knew about Git (Part I)
___________________________________________________________________
Things I wish everyone knew about Git (Part I)
Author : Tomte
Score : 128 points
Date : 2022-06-29 17:46 UTC (5 hours ago)
(HTM) web link (blog.plover.com)
(TXT) w3m dump (blog.plover.com)
| krono wrote:
| The Git docs are very comprehensive and the writing is
| surprisingly easy to follow.
|
| Also you're totally allowed to set up private repos and run
| whatever dodgy commands some karma-poor guy on SO claims should
| sort you out and see what you end up with, or create a "rewritten
| history" scenario that everyone has always been warning you to
| avoid (forbidden fruit...).
|
| In summary: Read the docs and git grokking!
| mytailorisrich wrote:
| If you're going to move files around, it's worth experimenting
| with one file first without doing any change in order to make
| sure you do it in a way that preserve history.
|
| There is 'git mv' for that. I have found the best way is to
| create new directories then use 'git mv' on the files.
| Arubis wrote:
| I'm pleased the coming Part II purports to point to `reflog`. For
| a tool that _looks_ like it's fairly advanced, this is one of my
| favorites to show juniors, because it works so well as a "get me
| back to where I was" hack.
| timost wrote:
| `git reflog`[0] saved my sanity numerous times.
|
| [0]: https://git-scm.com/docs/git-reflog
| shmerl wrote:
| I definitely recommend Git From the Bottom Up. Very good
| explanation of git design.
| mikewarot wrote:
| It was only recently that I learned GIT doesn't store deltas as
| it's core functionality, which is how I had presumed it works.
| It's just saving snapshots, and making up the deltas in
| retrospect, for purposes of merging, etc.
|
| In using it, you're always confronted with deltas, so it seemed
| that was how it worked. The command structure didn't correspond
| at all, and was thus very confusing.
|
| Git is really a contents addressable archive disguised as a
| version tracking system.
| smusamashah wrote:
| If you can understand the data structure git uses (Merkel Trees)
| it becomes easy to understand git (won't help with the CLI
| though).
|
| I think it can be summarized as Linked List in reverse. New
| entries are always added on head instead of tail. The pointer
| used to track the growing list is 'branch' pointer. The pointer
| that is fixed to a specific node is 'tag'. Since we are adding on
| Head, we can have multiple nodes point to one node.
| layer8 wrote:
| That's the easy part. It doesn't tell you how local and remote
| interact and how the working tree, index and repository
| interact, and how to handle the issues you can run into with
| merging, rebasing, etc.
| smusamashah wrote:
| Rebasing is when a whole branch (a chain of commits) is
| picked up and moved on to some other commit. It's easy to
| build up on that.
|
| Working tree is current state of files. Index is the staging
| area or the buffer (if I am not forgetting) where you put
| your changes you are about to permanently commit.
|
| Git is distributed system. Your repo can point to another
| repo as its remote copy. Can have multiple remotes. The
| default remote is 'origin'. When pushed, changes are uploaded
| to that remote repo. The remote repo doesn't have to be on a
| server. You can have it locally in another folder. When you
| push, your changes will be copied to that one too.
|
| Edit: I don't know how merge really works, and merge issues
| have been difficult to resolve therefore.
| microSnowball wrote:
| The author mentions the 30-odd page Git From the Bottom Up in his
| talk and I think it's a solid starting point--
|
| https://jwiegley.github.io/git-from-the-bottom-up/
| smm11 wrote:
| Screenshots are boring any more, what with this All Things Git.
| I'll be happy the day we collectively recall there has been TTY
| for a long time without it.
| cryptonector wrote:
| https://gist.github.com/nicowilliams/a6e5c9131767364ce2f4b39...
| buzzwords wrote:
| I wonder how many hours have been wasted on fixing mistakes made
| on git. Recently, I watch a friend spend two days try and figure
| out what the junior Devs have done with commits and branches
| crispyambulance wrote:
| Yeah, that's the tragic thing about git. It's so easy to get
| the wrong idea or fumble on the easily forgettable garbage CLI
| semantics and make mistakes. Even experienced people make
| mistakes if they try do something that's different from their
| daily grind.
|
| To make it worse, correcting mistakes ALSO is something that's
| not done regularly-- so that becomes an obstacle as well.
| buzzwords wrote:
| Judging by the comments here, there are a lot of frustration.
| Since git is open sourced and it's a basic tool why aren't the
| experts here contributing and making it work how everyone here
| thinks it should work?
| macintux wrote:
| This thread from earlier this week ("Oh shit, Git") includes
| discussion of many similar resources.
|
| https://news.ycombinator.com/item?id=31874308
|
| Some that looked interesting:
|
| * https://learngitbranching.js.org/
|
| * https://github.com/blog/2019-how-to-undo-almost-anything-wit...
|
| * https://github.com/k88hudson/git-flight-rules
| karmakaze wrote:
| > Git has an elegant and powerful underlying model based on a few
| simple concepts: Commits are immutable
| snapshots of the repository Branches are named sequences
| of commits Every object has a unique ID, derived from its
| content
|
| I would list them as: Every object has a unique
| ID, derived from its content - and every commit id
| depends on its ancestors' commit ids Each commit has an
| associated snapshot (file tree) of the repository A
| branch is a named reference to a commit - the referenced
| commit changes with addition/rebase/amend of commit(s)
|
| Not quite as compact or elemental but a usably granular mental
| model.
|
| If you want to learn how git works you can read about it, or
| merely look at the small text files inside a .git directory.
| cryptonector wrote:
| You can get by quite well w/o really understanding objects,
| just commits. So I like to start teaching Git concepts by
| looking at commits and refs first, then add color with objects.
| kyberias wrote:
| The definition of a branch here does not seem useful in any way.
| WanderPanda wrote:
| Maybe they should have been called "head" while the actual head
| is maybe the "current-head"?
| pavlov wrote:
| Maybe the root problem isn't the definition, but that git calls
| this concept a branch?
| skrebbel wrote:
| Fwiw a branch isn't a named sequence of commits, it's just a
| label that points to a single commit. It's exactly the same as a
| tag except that git moves it when you make a new commit.
|
| Mercurial calls these bookmarks which IMO is a much better name
| because it works exactly like real bookmarks (in books, not
| browsers). A git branch _feels_ a little bit like a branch of a
| tree because each commit points to their parent. Therefore, you
| don 't need to track the entire sequence of commits in the branch
| but just the commit at the tip. I think if they'd had named only
| this concept better, Git would've been way easier to grok.
|
| I wouldn't usually nitpick like this but given that the entire
| point of this article is it matters to get the basic concepts
| right, I figured the author might want to get this basic concept
| right.
| HWR_14 wrote:
| Am I the only one sad that Git beat out Mercurial as the
| industry standard?
|
| And am I also the only one who still knows how to do things in
| Mercurial but not how to take the corresponding action in Git?
| I mean, they're things I haven't had a reason to do in years,
| but it has some psychological cost to feel like I'm using a
| system I'm worse at.
| cryptonector wrote:
| I'm not sad.
|
| Mercurial is opinionated. It's had to adopt the Git way
| slowly, grudgingly.
| brianwawok wrote:
| I was on the team of a large org doing a POC between the two.
| Merc did some stuff better, git did more. I am glad git won
| out overall. I think the only feature Merc had that I cared
| about was tracking folders as objects.
| [deleted]
| lisper wrote:
| > each commit points to their parent
|
| Potentially more than one.
| tomjakubowski wrote:
| just to spell it out fully for dear reader: that's how merge
| commits work.
| Anunayj wrote:
| and Just for fun, sometimes it can be as big as 66, meet
| Cthulhu merge [1]
|
| 1. https://lkml.org/lkml/2014/1/21/361
| hinkley wrote:
| Linus doesn't appear to be particularly enthusiastic
| about this strategy.
|
| Humans really do handle treating changes as a sequence. I
| wonder if this was really necessary or could have been
| serialized.
| HWR_14 wrote:
| Mercurial, by the spec, only allows two parents to force
| merges like that into a sequence.
| wdfx wrote:
| And when you are playing around with git to try this
| strategy and it's not allowed you get the wonderful error
| message "should not be doing an octopus".
|
| (IIRC, from some version of git from about 6 years ago)
| jsmith45 wrote:
| This is exactly the point the author plans to address under
| "Branches are fictitious", in the outline at the top.
| skrebbel wrote:
| Sure but then why do they describe the term wrong in the
| first paragraph? That's just adding to the confusion they
| intend to fight. I'm not sure the author is reading this, but
| think it's worth rewording.
| mjd wrote:
| I'm reading it and I think I got it right. The Git
| community, the Git documentation, and the Git tools all
| refer to "branches", and I think what they mean when they
| talk about "branches" is much closer to what I described
| than to what you did.
|
| For example, consider this very ordinary-sounding phrase
| that I just picked out of the git-rebase man page:
|
| > If the upstream branch already contains a change you have
| made ...
|
| I don't think your account can explain what is meant by
| this.
|
| In any case, I didn't make the choice casually,
| thoughtlessly, or from ignorance.
| layer8 wrote:
| But what's the precise rule defining what constitutes the
| commits of a branch, after you reach a merge point? Does
| the branch end there? If not, which parent of the merge
| does it go? It's not clear a priori.
| edflsafoiewq wrote:
| I think it goes to all the parents, ie. a branch denote
| not a linear sequence of commits, but an entire sub-DAG.
| hbn wrote:
| The only thing that makes me competent enough to do most normal
| day-to-day stuff in git is the built-in git UI in JetBrains IDEs.
|
| It's super intuitive, there's buttons that say exactly what
| they'll do without me having to worry what underlying commands
| it's running, and the best part is the merge conflict resolution
| UI that lets you go file by file and has a 3-pane split for
| existing changes, merged file, and incoming changes. You can
| select the arrows that are drawn from one pane into the center to
| bring those changes into it, X to ignore those changes, and the
| center is completely interactive like any other text editing area
| in the IDE so you can just copy paste from each side and fix it
| yourself.
|
| I basically don't ever bother with git from the command line.
| georgia_peach wrote:
| The thing I wish everyone knew about Git is that Mercurial is
| better. Much much better.
|
| https://hginit.github.io/
| cryptonector wrote:
| Which is ironically hosted on a Git (GH) repo.
|
| Mercurial is dead.
| jaskyle wrote:
| A great video tutorial on Version Control for Code Using Git:
| https://www.youtube.com/watch?v=mndB6zHmU3k
|
| And Managing Code Projects with Git Branching:
| https://www.youtube.com/watch?v=tzJDZY1x31I
| imwillofficial wrote:
| Can't wait for part 2, way to be a tease, author!
| [deleted]
| milliams wrote:
| The examples of `git reset` and `git checkout` are being fixed by
| things like separating them out into `git restore` and `git
| switch` which helps a lot in my experience. Also, `git status`
| does a good job of reminding you which commands to run.
| chx wrote:
| > When I first used Git it drove me almost to tears of rage and
| frustration. But I did get it under control. I don't love Git,
| but I use it every day, by choice, and I use it effectively.
|
| Yes. For me the rescue was Charles Duan's git tutorial:
| Understanding Git conceptually.
| https://www.sbf5.com/~cduan/technical/git/
|
| > you can only really use Git if you understand how Git works.
| Merely memorizing which commands you should run at what times
| will work in the short run, but it's only a matter of time before
| you get stuck or, worse, break something.
|
| The original claims
|
| > It is very hard to permanently lose work.
|
| I disagree. So I run a git reset safety net
| https://gist.github.com/chx/85db0ebed1e02ab14b1a65b6024dea29 it
| saved my bacon quite a few times. (Bonus git cd command. It's
| useful.)
| cryptonector wrote:
| Basically, making `git reset --hard` and `git checkout -f`
| auto-stash would be great.
| chx wrote:
| That's what the script does for the first. Essentially.
| evanrelf wrote:
| That `git cd` command is a great idea! Thanks for sharing.
| stu2b50 wrote:
| > I disagree.
|
| Anything that ends up in a commit should be recoverable (on the
| same local git repository, that is), no? The main things that
| can forever clobber your work afaik is git checkout -- <path>,
| which will perhaps a little unintuitively just clobber over
| whatever is not committed.
| layer8 wrote:
| > no?
|
| Technically no, due to GC.
| throw7 wrote:
| Isn't "naming things" one of those "hard things" to do well in
| computer science?
|
| It seemed to me, linus and the initial git architects just kind
| of slapped names on operations as features grew organically over
| top of the model. To early adopters, all of it made sense. Yeah,
| someone new looking in from the top down will be bewildered.
| dotancohen wrote:
| Git reused much of the terminology of other VCS systems, even
| though the architecture was completely different.
|
| So usage-wise git was familiar to someone familiar with e.g.
| SVN right from the beginning.
| masklinn wrote:
| Except that's not true because a lot of the commands git
| reused do something rather to completely different from their
| role in svn.
| masklinn wrote:
| The worst part is that many of the names were inherited from
| earlier tools, but usually mangled, or repurposed because the
| old version was "not needed" (revert) because they'd merged
| multiple high-level features in the same command out of low-
| level commonalities (checkout and add being poster children for
| this)
| s1k3s wrote:
| I disagree with the premise that I need to know what happens
| behind the doors to successfully use a tool. I've been using git
| for the past 15 years with literally 0 issues of merging or
| branching. The only rule I have to follow is "don't do stupid
| things with it". Branch -> push -> merge is what I've been doing
| all my life and it worked like a charm. Just avoid the problems
| and it's all going to work just fine.
| omginternets wrote:
| With few exceptions, this mentality is exactly what separates
| well-paid senior engineers from those who write rest endpoints
| all day. Knowing your tools is part of the job. Knowing how
| your tools work is a big part of knowing how to use them
| effectively.
| pdimitar wrote:
| Senior engineers are paid to get stuff done on time while
| following good practices, and be proactive and communicative
| (and not end up on Twitter for the entire day because they
| couldn't figure out one project requirement by themselves, as
| many juniors do).
|
| Compared to a junior engineer, they have to get thrice more
| things right at the same time.
|
| Knowing a tool inside out can help with this, but it's not a
| requirement at all. It's just one of the, _a-hem_ , tools in
| their box with which they can achieve efficiency.
|
| I am like many others in this thread. I don't care about
| GIT's "beautiful data model" one bit. I learned with time
| which commands are dangerous and I do due diligence to make
| triple sure I don't trip on them. With 2 exceptions for the
| last 10+ years (each took me half a day to fix) this has
| worked perfectly.
|
| It's quite OK to stick to what you know is safe and works
| well (and what pre-conditions have to be met so it works
| well).
|
| At this point if a customer comes around and asks me to use
| advanced GIT features I'll just bill them triple while
| telling them exactly why.
|
| I deliver, and at least 80% of the time I deliver on time,
| and 95% of the time with good practices and due diligence
| attached. How I use GIT is my business. I've been contacted
| by the next contractors no small amount of times and have
| eaten praise for how easy to track my project's change /
| commit history has been, too.
| s1k3s wrote:
| How? I've heard this argument a lot. How does me knowing how
| to solve a problem I created myself make me better than me
| avoiding it altogether?
|
| To expand on this: how many engineers you work with know what
| actually happens in a CPU when they run a for loop, for
| example? How many of them need to know that? It seems to me
| that a lot of people are very successful at creating useful
| things without understanding the underlying tech. Isn't this
| why we built it?
| pdimitar wrote:
| I'll try and track this series. I am not willing to invest almost
| any time in understanding GIT better because with time I just
| learned what's dangerous and how to avoid it. Worked perfectly
| for me for more than 10 years with 2 exceptions (and each took
| half the day to fix; ouch).
|
| I might very well be negatively biased but I'll admit that the
| whole "GIT's data model is beautiful" makes me roll my eyes every
| time. I've read through several guides and they have not helped
| me _at all_ ; they even confused me more.
|
| GIT is a tool for managing versions of files. It must be
| blindingly and painfully simple and all the special cases should
| be named much better than they are right now.
|
| The fact that they are not is just making me impatiently wait for
| when GIT's mind-share stealer will come around. Or I dunno, I
| might just start using Mercurial CLI on top of it and just give
| up.
| bstpierre wrote:
| If you really want a deep understanding of git, it's not actually
| that hard to reimplement a few very basic operations in your
| language of choice. I'm not saying _everyone_ should do this, but
| it's a way to level-up your understanding. Write the porcelain
| for stuff like `cat-file`, `commit-tree`, `read-tree`, `write-
| tree`. Adding command options aren't really needed, you're not
| trying to actually reimplement git, you're just trying to write
| enough so that all of the concepts fit together in your head.
| throwaway2214 wrote:
| haha, i cant count the times i fucked up and i just copied my
| files out, rm -rf repo; git clone; copy in :)
| WanderPanda wrote:
| Seriously, probably faster than searching for the command you
| need to fix it with all the right options that if not set would
| amplify your issues
| captaincrowbar wrote:
| Obligatory https://xkcd.com/1597/
| lisper wrote:
| > But if I were going to tell everyone just one more thing, it
| would be:
|
| > It is very hard to permanently lose work.
|
| Unfortunately, this is not quite true. Git checkout will silently
| and irretrievably clobber all the changes in your working tree
| [UPDATE: if you do 'git checkout [path]', but that is not an
| uncommon thing to do.]
|
| It is true that it is very hard to lose work that you have
| committed. But even this is not necessarily a good thing if, for
| example, you accidentally committed something that contains
| sensitive information that you _want_ to delete. (And God help
| you if you have pushed such a change upstream.)
|
| The sad fact of the matter is that while the underlying data
| structures are beautiful and tremendously useful, the UI/UX is a
| dumpster fire.
|
| It's actually not that hard to put a different UI/UX on top of
| the core. I'm kind of surprised no one has done this.
| cryptonector wrote:
| Never `git checkout -f` or `git reset --hard` unless you know
| you _want_ to throw away extant changes from the workspace.
|
| That's it. Know that, live that, and you'll never lose work
| because of Git.
| stu2b50 wrote:
| You can git reset --hard and still get your work back without
| much trouble. Resets just move the branch pointer back, after
| all.
| cryptonector wrote:
| Hard resets throw away extant changes in the workspace that
| are not in the index or committed. You can't find those
| changes in the reflog or stash.
| lisper wrote:
| Nope. There is at least one other case that loses work
| irretrievably. Details can be found in sibling comments.
| atq2119 wrote:
| > Unfortunately, this is not quite true. Git checkout will
| silently and irretrievably clobber all the changes in your
| working tree.
|
| Not by default it won't.
|
| It _can_ do that, if you explicitly run it with the options to
| checkout a specific path. But why would you do that if it 's
| not what you want?
| auraham wrote:
| IIRC mercurial creates backup (.bak) files when restoring a
| file. As a result, you can keep changes in .bak files even
| after (accidentally) doing a `git checkout -- file` in
| mercurial. Git does not have that feature.
| amcoy37 wrote:
| Accidentally running a git command in the wrong folder is
| pretty easy to do at the command line.
|
| I was, at one point, in the habbit of running "git checkout
| ." after writing some experimental code. Several times a day,
| or however often. So of course, I once accidentally ran that
| command in the wrong repo and obliterated some pending
| changes that hadn't been commited.
| dotancohen wrote:
| How is that git's fault?
|
| I used to `vim test.c` then `rm Alt-.` very very often.
| Until one day sure enough I'm in the wrong directory, and I
| actually saw `Alt-.` complete the filename of an important
| file, but the brain veto latency is slower than the muscle
| memory twitch and my pinky continued on over to the Enter
| key.
|
| I blame only Dotan and changed my work habits. Bash had
| nothing to do with the incident.
| eropple wrote:
| I dunno - I can tell zsh to are-you-sure me about an `rm
| -rf *`, git seems like it should be able to do similarly.
| Or, as Mercurial does, back up overwritten files to .bak.
|
| These are pretty light asks.
| compiler-guy wrote:
| "Just don't make a mistake" is a pretty bad strategy.
| chronometry888 wrote:
| But "save your changes before running a command that can
| clobber" is a pretty good strategy.
| [deleted]
| [deleted]
| lisper wrote:
| > It can do that, if you explicitly run it with the options
| to checkout a specific path.
|
| Fair point. I've update my comment to clarify.
|
| > But why would you do that if it's not what you want?
|
| Because sometimes it is what you want. The point is, if you
| happen to do it when it's not what you want, you're hosed. So
| it is simply not true that "It is very hard to permanently
| lose work." It is, in fact, quite easy under certain not-
| uncommon circumstances.
| atq2119 wrote:
| Fair point. There probably should be standard advice along
| the lines of "if in doubt, make a 'wip' commit before you
| do anything". That's good advice even beyond using git
| itself.
| intrepidhero wrote:
| > But if you try to understand the commands without the model,
| you will suffer, because the commands do not make sense.
|
| I've read this about git several times and certainly felt it. My
| question is why hasn't anyone come along and fixed it? Git has
| the plumbing vs. porcelain separation. Why hasn't someone written
| new porcelain that makes git as intuitive as mercurial,
| subversion, etc? This seems like a similar situation as dpkg/apt.
| The underlying design has been settled but we desperately need a
| better interface.
|
| > Git has an elegant and powerful underlying model based on a few
| simple concepts
|
| My second question is, if the underlying model is so f*cking
| elegant, how did it lead to such a confusing interface? This
| isn't so much me griping about git (although I am) but more a
| curious case for design theory. Would love to read serious
| analysis. I can't offhand think of another piece of software
| where "the model is elegant but the interface is confusing" is
| such a common critique.
| radarsat1 wrote:
| > Why hasn't someone written new porcelain that makes git as
| intuitive as mercurial, subversion, etc?
|
| I've used svn and git extensively, but after getting very used
| to git, i tried working on a project that used mercurial and
| walked away completely confused by how it works. With
| "branches" being completely different beasts that i couldn't
| understand and unsure when it was appropriate to use bookmarks
| instead. It completely baffles me that people find it better
| than git's super straightforward dag-of-snapshots model and I
| reject the idea that it is simpler or more intuitive.
| jcranmer wrote:
| If you're coming from git, this is what you need to do to
| understand Mercurial: don't worry about Mercurial's branches,
| ever. Whenever you want to use the term 'branch' from git,
| translate it to 'bookmark'. Mercurial's branches correspond
| more directly to svn's branches--they're immutable properties
| of a revision--but it's not a terribly useful property, and
| you can forget about them entirely and be perfectly
| productive.
|
| Although note that unlike git, you don't need to use
| Mercurial's bookmarks since Mercurial is perfectly happen to
| let commits sit around without having names pointing to them.
| masklinn wrote:
| > My question is why hasn't anyone come along and fixed it? Git
| has the plumbing vs. porcelain separation.
|
| Dozens have, but by the time their replacement porcelain gets
| anywhere near useful they've attained a grasp of the plumbing
| more than good enough they don't need it anymore.
|
| > My second question is, if the underlying model is so f*cking
| elegant, how did it lead to such a confusing interface?
|
| Mastery of structural elegance doesn't mean you have also
| mastered interface and experience. In fact it's often not the
| case.
|
| > I can't offhand think of another piece of software where "the
| model is elegant but the interface is confusing" is such a
| common critique.
|
| Every database. The relational model is a beautiful thing, sql
| is a horrendous shit-show.
| dariusj18 wrote:
| Tons of people have tried creating GUIs to make using git
| easier, and many do, but where they fail is when they try and
| change the terminology to make it easier to understand.
| WanderPanda wrote:
| GitKraken + git cli works like a dreamteam. GitKraken for 80%
| of the interactions like staging lines, commiting, browsing
| the history. Git cli for the 20% long tail of special
| operations
| kortex wrote:
| > My question is why hasn't anyone come along and fixed it?
|
| There's been dozens of "replacements"/frontends/guis for git,
| off the top of my head: gitless, magit, tortoise git,
| gitkraken. Heres a whole mess of em:
| https://git.wiki.kernel.org/index.php/Interfaces,_frontends,...
|
| > My second question is, if the underlying model is so f*cking
| elegant, how did it lead to such a confusing interface?
|
| I think this is 66% because the operations are on the
| tree/nodes themselves, and not like, on "versions", branches,
| or some other skeumorphic abstraction. It's very bare metal. If
| you know how the command operates on the tree, you know how to
| conduct the actual action desired. I think the rest is due to
| cruft/familiarity - once you build that mental model, it works
| extremely well. So it's vi-like with a steep learning curve and
| arcane interface, but once you "git good", it's phenomenally
| productive.
| WanderPanda wrote:
| I believe I will never figure out when I have to use "remove"
| "delete" "-d". These naming inconsistencies make it a lot
| harder than necessary
| ziml77 wrote:
| A porcelain whose only purpose is to address those
| inconsistencies would be wonderful.
| cryptonector wrote:
| > My question is why hasn't anyone come along and fixed it?
|
| Because the model is simple and easy to understand, and you get
| a lot of power from understanding it. Whereas opinionated
| porcelain that tries to insulate the user from the model will
| tend to fail in obnoxious ways and will not serve the user.
|
| Really, there's objects, there's commits, then there's a couple
| of methods for symbolically naming commits (branches and tags)
| because humans need symbolic names (because we can't memory
| SHA-1 hashes, or any hashes). Object and commit hashes function
| as pointers or inode numbers. Symbolic commit names function as
| hard links.
|
| If you understand the Unix filesystem, you can understand Git.
|
| Everything else follows from these things.
|
| Merges create new objects referenced from the merge commit.
|
| Rebase is just a script around cherry-pick.
|
| Cherry-pick is just applying a delta from a commit and then re-
| committing.
|
| Everything is copy-on-write _except_ the symbolic names (branch
| names, tag names).
|
| There -- I've just told you everything you need to know about
| the model. And all of that trivially carries over to the UI.
| yCombLinks wrote:
| The problem isn't requiring knowledge of the model, the
| problem is inconsistencies in the git commands for working
| with the model.
| OkayPhysicist wrote:
| I'm not a fan of this mythos around Git's complexity. It is
| simply a DAG, a bunch of references to nodes in that graph, and a
| stack of commands that let you make any modification to that
| system you so desire.
|
| If you just learn the mapping of those concepts to Git's
| vocabulary, you really don't need to memorize all the commands.
| In the odd case, you can just look up the docs. Nodes are
| commits, references are either branches or labels depending on
| whether they stick to leaf nodes or any other node. Your working
| tree is the current state of the repo in your filesystem, and
| staging is how you assemble commits.
| bombcar wrote:
| There's a strong current in all tech things where "I couldn't
| figure it out intuitively the first time I sat down and tried
| it" becomes exactly the same as "this is ungodly complex and
| impossible to use".
|
| I've seen it leveled against emacs, git, vim, etc. It's kind of
| sad.
|
| I suspect that "attempts to explain something in an easy (but
| subtly wrong) way" have fueled it with regards to git.
| digisign wrote:
| Sounds great. But doesn't get anyone from point A to point B.
|
| It's like being handed city maps of LA and NYC and told to
| drive from one to the other.
| pessimizer wrote:
| 1) Git's vocabulary is bizarre.
|
| 2) Every tutorial and book leans into the horrible vocabulary,
| and the metaphors they use to "simplify" and "explain" it only
| make it worse. All of the analogical baggage is far more
| complicated than a straightforward description of the data
| structures.
|
| It took an embarrassingly long time for me to understand that
| HEAD was just a pointer at the branch or commit you were
| currently working with (I wish somebody would take that
| "detached HEAD" terminology out back and shoot it), and that a
| branch was just a tag that, if HEAD is pointing at it, will
| move to point to a new commit that you make.
|
| That's because "HEAD" and "branch" are stolen terms crowbarred
| into something quite different than CVS.
|
| edit: the actual Git book from git-scm.com is not bad at all,
| but most people aren't learning from that.
| gorgoiler wrote:
| Thing I wish I'd learned sooner about git: it was designed to
| make patches a first class entity. Trees of objects are indeed
| the fundamentals, but it's quite possible to detach a commit by
| formatting it into a patch ("git format-patch") and sharing it
| outside of the context of a repo. No ssh required: email it, fax
| it, print it out and mail it -- all the metadata is retained
| allowing the commit to be reconstituted as if it were git pushed
| or pulled over TCP.
|
| Why is this important? Because code review is about reviewing the
| changes and applying patches in a different context to where they
| were authored. If I fix a bug in my repo then you should be able
| to apply my fix cleanly to a repo in a quite different state that
| mine was in. We can work on different things in a decentralised
| way and yet still collaborate.
|
| Most people of course don't work like this. Most people in 2022
| will literally share a parent commit from a central repository.
| They push and pull over the net instead of emailing patches.
| Their trees are in sync a lot more than the days of patch
| emailing yore. (Although emailing patches is still used by people
| who need to exfiltrate a change from some system not blessed with
| full access credentials to do a real push.)
|
| The thing that _does_ still hang around is the idea of a
| dissociated patch being the unit of a review. Some code review
| tools don't really get this right -- Gitlab in particular still
| muddles up the idea of a merge request and a commit. A merge
| request has a title and a description but so does a commit and
| yet they are kept separate. You view an MR's changes as one big
| patch and these may or may not bear _any resemblance_ to the git
| commit or commits and their own titles and descriptions. It is as
| if GitLab's authors either purposely or naively ignored the idea
| that git was designed to think in this way from the ground up,
| and so they implemented a patch-like thing of their own, on top.
|
| I've also never embraced the idea of commits that are for public
| consumption and those which are not. In my model, there are no
| feature branches, only branches that combine different sets of
| patches.
|
| It doesn't need to be so complex and indeed if you embrace the
| underlying tool ( _on which your product is named!_ ) gitlab
| based git projects would be a bit less special and a bit more
| like everyone else.
| comradesmith wrote:
| Does the same criticism apply equally to GitHub's pull
| requests? I feel like they are essentially the same thing
| layered on top of a repo, gitlab even supports merge requests
| across forks.
| fleddr wrote:
| Given how widely used git is, we must also empathize as widely as
| possible. Meaning, users of git are on a spectrum from hardcore
| engineer with two decades of Unix experience to casual hobbyist.
|
| The casual group may include people very young/old, people with
| no (significant) background in programming, people that had
| little formal education in general, non-English speakers, people
| with cognitive limitations.
|
| When you approach Git like that, neither the commands nor the
| concepts behind them make any sense.
|
| Saying something like "see, git is just a merkel tree of
| immutable objects with a unique hash id and a commit is a blah
| blah..."
|
| ...makes no sense whatsoever to the casual group. They are alien
| words and concepts that are not relatable to the actual task: I
| just want to version manage something.
___________________________________________________________________
(page generated 2022-06-29 23:01 UTC)