Earlier quoted context omitted.
> each commit points to their parent Potentially more than one.
just to spell it out fully for dear reader: that's how merge commits work.
and Just for fun, sometimes it can be as big as 66, meet Cthulhu merge [1]
Things I wish everyone knew about Git (Part I)
31–40 of 200 posts
Re: Things I wish everyone knew about Git (Part I)
#32> 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…
> 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?
[deleted]
Re: Things I wish everyone knew about Git (Part I)
#33I'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.
Re: Things I wish everyone knew about Git (Part I)
#34If 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.
Re: Things I wish everyone knew about Git (Part I)
#35Fwiw 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. Th…
This is exactly the point the author plans to address under "Branches are fictitious", in the outline at the top.
Re: Things I wish everyone knew about Git (Part I)
#36> 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 situati…
> 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% beca…
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
Re: Things I wish everyone knew about Git (Part I)
#37Earlier quoted context omitted.
> 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?
[deleted]
[deleted]
Re: Things I wish everyone knew about Git (Part I)
#38> 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 situati…
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.
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
Re: Things I wish everyone knew about Git (Part I)
#39haha, i cant count the times i fucked up and i just copied my files out, rm -rf repo; git clone; copy in :)
Obligatory https://xkcd.com/1597/
Re: Things I wish everyone knew about Git (Part I)
#40> 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…
> 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?
> 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.