511–520 of 520 posts
Earlier quoted context omitted.
SourceTree keeps the same language regular git uses. But I highly agree. JetBrains IDEs add their own lingo out of support for multiple version control plugins I'm sure but its confusing and easy to screw up. SourceTree is the one GUI client I want on Linux...
VSCode is the only Git GUI that you need and it's available on Linux
Earlier quoted context omitted.
You're entitled to your own opinion of course, but you underestimate the efficiency of the command line, especially when you already have one open for other development tasks. I use one or more GUIs for visualizing branches, and old branch cleanup, and yes, committing single lines from hunks that can't be split. However for everything else CLI is fairly close to optimal, including interactive adding/rebasing, and don…
> Fugitive That's interesting. I switched back from emacs to vim (neovim), and fugitive was recommended. it just looked like :commands for the normal git cli... maybe I missed something. So even though I edit in vim, I jump back to emacs for magit for bigger commits or multiple smaller commits (where I need to see diffs to be sure I capture my changes). I have desired something as useful in vim, but I didn't think th…
As soon I started to work with git, I installed fugitive. My learning curve of fugitive has been slow, and I have never be able to stage efficiently with it.
And then, a colleague showed me magit: I waited for a year that something similar comes to vim, trying to push this idea to fugitive https://github.com/tpope/vim-fugitive/issues/569 , without success.
Finally, some first experiments showed that partial hunk stage was feasible, and I created vimagit.
As you will see, it is far from whole magit features. For the moment, it "only" focuses on stage/unstage and commit feature (which is the main use case to me). The current workflow is quite robust: you can easily navigate through all the diffs to review them, stage by file/hunk/line/part of line, write the commit message (or amend the last commit), jump to the diff locations in their files... I continue to use fugitive for Gblame and Gdiff.
Next major features should be git stash (be able to prepare a stash like a commit, by file/hunk/line) and some git log related feature (to easily git commit --fixup a chosen commit in a log for example).
Earlier quoted context omitted.
Well, I disagree, because the alternative for many is probably no source control.
Folks writing production crap would opt for no source control? Well, fair enough I guess. But I (and probably most competent sw engineering folks) would never hire someone who was completely oblivious to using source control. So hopefully that 'practice' would die through attrition.
Earlier quoted context omitted.
Not to sound snarky / adversarial but why is it that (nearly) every article I see on Git has some sort of diagram within it? Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish.
> Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish. It looks like you mindlessly associate a CLI with a poor -- or suboptimal -- user experience. In fact even your choice of weasel words conveys the idea that you want to mindlessly push an irrational belief in spite of not being able to provide arguments to support it. The truth of the matter is that git -- or any other VCS…
Put another way, Git is a process that can be rendered pictorially. Words (i.e., CLI) are a less intuitive abstraction.
Pardon me for stating the obvious :)
Earlier quoted context omitted.
Not to sound snarky / adversarial but why is it that (nearly) every article I see on Git has some sort of diagram within it? Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish.
The issue is with understanding staging and the working directory. The lightbulb moment for me was reading this article from Atlassian: https://www.atlassian.com/git/tutorials/resetting-checking-o... Understanding that git reset --soft moves HEAD but doesn't change the staged snapshot or working directory, whilst --mixed updates the staged snapshot to match the commit but doesn't touch the working directory was very…
Earlier quoted context omitted.
I think you've put your finger on the schism of why so many git users prefer a GUI. The built-in porcelain is stupidly inconsistent and confusing. And yet, git's underlying model is so simple and powerful that I think it's worth suffering the bad CLI just to be more fluent and able to utilize git's power fully. The model itself is very easy to grok, it just takes some time to memorize the various random incantations…
"C language is so simple and powerful that I think it's worth suffering the bad syntax and memory leak just to be more fluent and be able to utilize the machine's power fully." Pick the right tool for the right job, man. Joking aside, think about the ratio of tasks. Most of the git commands I do is deadly simple. There might be once-in-a-year complex tasks that are more suitable to CLI, but for 99% of the tasks I thi…
Earlier quoted context omitted.
I could name a few things, like interactive rebases, but the main thing is not something that can really be explained. Have you ever significantly become strong in some kind of contest, may it be sports, gaming, music or similar? There is this situation where one day you struggle with something and don't see an end, and the next day it finally clicks, and you can do things naturally that one day earlier where not eve…
Long story short, you're using git because it makes you feel smart. Ironically, you even admit it - "therefore have no logical reason to go through the pain of really learning git". Correct, there is no logical reason to deal with a contorted DVCS when there are better alternatives. Your arguments are fully subjective.
What I'm saying is that most people are blind when it comes to skill, because they never make it over the hurdle once. But because most people don't have any skill, it is general consensus in our society to declare skills based on interest rather than the ability to solve hard problems or win competitions. I mean if one person is unable to judge if another person is good at solving merge conflicts, how could he criticize that person declaring himself as Git Expert Of The Team. And then again of course most people feel it is inappropriate to tell other people they are unskilled, so posts like this one get hated a lot on. But actually it's just calling out the facts. Sky is blue, grass is green, most people are too unskilled to even recognize what would enhance skills.
Earlier quoted context omitted.
> Git is fundamentally better than most of the alternatives No way. Only if you define “good” as “good at the kind of project that git is good at,” where it will hold vacuously. I suffer daily through the cyst that is git LFS, and it’s a joke. It would be funny if it weren’t so tragic. I hear that it’s not doing any better in large scale mono repo land. Google doesn’t use it, afaik. Microsoft does (but multi repo, la…
That's a fair criticism for sure, git makes tradeoffs that fall apart with large repos. You can, however, go a whole career without those things being a problem. Most code repositories are simply not that big.
Earlier quoted context omitted.
Long story short, you're using git because it makes you feel smart. Ironically, you even admit it - "therefore have no logical reason to go through the pain of really learning git". Correct, there is no logical reason to deal with a contorted DVCS when there are better alternatives. Your arguments are fully subjective.
If you tell a blind person, he should use the color red more when dressing, it might be a good advise, but for the blind person there is no logical reason to choose red over green. What I'm saying is that most people are blind when it comes to skill, because they never make it over the hurdle once. But because most people don't have any skill, it is general consensus in our society to declare skills based on interest…
You seem to be under the impression that doing hard things has some intrinsic value, when it's not the case. You could be rolling rocks uphill all day and be the best in the world at it. So what? A keyboard going clicketyclack* for 5 minutes while typing git commands (and possibly stackoverflow queries) is the opposite of work, it's actually a waste of time. Sure, at the end of the day you solved the problem git presented you; you're smart, and feel satisfied with you amazing display of intelligence and skill. However, this ignores the fact that you should not have had to solve that problem to begin with, because your version control system should just magically work (unless you get a bonus for each git commit/merge).
> how could he criticize that person declaring himself as Git Expert Of The Team
I have no problem with someone being a git expert - I actually will even admit that I am not a git expert and that there are people extremely skilled at git. The issue here is that there are some people really skilled at, for example, typing using the backs of their fingers. Potentially impressive, but entirely useless. Saying you're skilled at git is like saying you're skilled at using Jira or editing Wikipedia; good for you, but in all but most extreme cases this doesn't actually generate value and it also doesn't make you a better developer.
> one person is unable to judge if another person is good at solving merge conflicts
Just out of curiosity, is this somehow relevant to git? Shouldn't solving a merge conflict be a simple matter of looking at a diff tool presenting you two inputs and one output screen? Or better yet, wouldn't it be better if you were automatically told you are editing a file someone else is working on, so that it prevents conflicts from happening?
Earlier quoted context omitted.
If you tell a blind person, he should use the color red more when dressing, it might be a good advise, but for the blind person there is no logical reason to choose red over green. What I'm saying is that most people are blind when it comes to skill, because they never make it over the hurdle once. But because most people don't have any skill, it is general consensus in our society to declare skills based on interest…
Unless I'm mistaken, people are paid to solve engineering/programming problems, not fight with a mess of a DVCS. And if I can use a Mercurial GUI and do in 15 seconds what would take 5+ minutes in the git command line, what's the point of being the Git Expert Of The Team? Is version control not used for saving work progress? A simple thing that 99.99+% of developers should be taking for granted in an ideal world, jus…