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.
Things I wish everyone knew about Git (Part I)
21–30 of 200 posts
Re: Things I wish everyone knew about Git (Part I)
#22> 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.
Re: Things I wish everyone knew about Git (Part I)
#23I 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.
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.
Re: Things I wish everyone knew about Git (Part I)
#24> 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?
Re: Things I wish everyone knew about Git (Part I)
#25I 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.
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.
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?
Re: Things I wish everyone knew about Git (Part I)
#26> 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% 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.
Re: Things I wish everyone knew about Git (Part I)
#27The author mentions the 30-odd page Git From the Bottom Up in his talk and I think it's a solid starting point--
Re: Things I wish everyone knew about Git (Part I)
#28I 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.
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.
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.
Re: Things I wish everyone knew about Git (Part I)
#29> 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?
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.
Re: Things I wish everyone knew about Git (Part I)
#30>
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.)