|
Khorne posted:Especially once you understand what git is doing under the hood and want to make sure the right things are happening.
|
#
?
Sep 30, 2019 21:59
|
|
|
|
| # ? Jun 8, 2024 03:56 |
|
|
Khorne posted:I don't get why people use anything other than command line for git. Everything else is awkward in comparison. Especially once you understand what git is doing under the hood and want to make sure the right things are happening. I like seeing the branching tree in front of me. Makes it easier for me to pick out what's new after a pull and to choose where to go when I need to revert to search for where a feature might have broken in the past. It's also easier to immediately spot when you've made a terrible mistake.
|
|
#
?
Sep 30, 2019 23:12
|
|
|
Khorne posted:I don't get why people use anything other than command line for git. Everything else is awkward in comparison. Especially once you understand what git is doing under the hood and want to make sure the right things are happening. I agreed. Sourcetree was the one that made me give up in frustration and just learn the command line because the GUIs are all so cumbersome. Especially since (this obviously depends on what you're building, I'm just speaking for myself here) there's a good chance I have a terminal open that I'm working in anyway. The only thing I can think of that particularly sucks from the command line is merging, but you can set VS Code up as your merge tool and it works well enough. Some of the comments here about commit messages and rebasing make me think you guys are leaving your feature branches around for waaaaayyyy too long.
|
|
#
?
Sep 30, 2019 23:35
|
|
|
I just mix git cli and tig 
|
|
#
?
Sep 30, 2019 23:47
|
|
|
Xarn posted:tig yeah i used mig at one place, just awful! buncha ==== >>>'s all over the place after a merge, tig's so much cleaner in the hands of a pro
|
|
#
?
Oct 1, 2019 02:38
|
|
|
Yeah tig is the one tool that makes git palatable to me
|
|
#
?
Oct 1, 2019 04:34
|
|
|
Just wanna say thanks for the replies everybody. I asked you something I didn't want to ask my coworkers because people get all high and mighty about their preferred way of doing things, feel like you're calling them out and start questioning their life choices, or think but don't say "who cares can we talk about something else". Some good, insightful reasons as to why some people prefer GUI. A few of you just need to spam "git status" between every breath and use git diff with either HEAD~N or a remote branch name to solve your CLI woes. But some others had good points, like if you're regularly but not frequently doing complex staging workflows the CLI is going to be a pain. And some people will prefer visualization. Which makes sense, because you made me realize I sometimes check bitbucket or github or whatever for similar things. So truly, I am inferior for using a web interface instead of a GUI. I never even considered the "I use both" workflow, either. Most GUI users I know use the GUI until they're forced not to because they accidentally broke everything with the GUI. JawnV6 posted:this is some faint praise If you meant that the other way, like for me, I didn't mean it that way. I consider lots of people who replied better at programming and probably git. Khorne fucked around with this message at 05:19 on Oct 1, 2019 |
|
#
?
Oct 1, 2019 05:17
|
|
|
I wish mercurial had won the battle of source control systems built on the (still-twitching) corpse of bitkeeper
|
|
#
?
Oct 1, 2019 08:46
|
|
|
a hot gujju bhabhi posted:Some of the comments here about commit messages and rebasing make me think you guys are leaving your feature branches around for waaaaayyyy too long. Khorne posted:Git's one of the top 5 advances in software engineering in the past 20 years. It's just significantly more complex than what came before it and takes actual effort to learn.
|
|
#
?
Oct 1, 2019 12:28
|
|
|
Volte posted:Learning how git works and learning its hot garbage of a CLI are two different things. Git isn't really that complicated if you have a good mental model of how it works. Yeah, I was going to say something like this. Like, yeah I agree git is a big advance for software development. It's a shame it has such a terribly designed CLI. I feel like we've reached yet another path dependence nightmare wherein git has made such inroads that we're all stuck with what we've got for the next two decades.
|
|
#
?
Oct 1, 2019 18:52
|
|
|
Khorne posted:Git's one of the top 5 advances in software engineering in the past 20 years. It's just significantly more complex than what came before it and takes actual effort to learn. Counterargument: git is one of the worst things to happen to software engineering in the past 20 years.
|
|
#
?
Oct 3, 2019 05:04
|
|
|
An unsupported claim isn't an argument.
|
|
#
?
Oct 3, 2019 05:17
|
|
|
Distributed Version Control is one of the top things to happen in the last 20 years, at least.
|
|
#
?
Oct 3, 2019 06:18
|
|
|
Presto posted:Counterargument: git is one of the worst things to happen to software engineering in the past 20 years. Take this hot needs some supporting arguments.
|
|
#
?
Oct 3, 2019 11:09
|
|
|
as someone who was previously forced to use clearcase, I can say that the git user experience is a comparative delight, and its ubiquity forcing places to move away from old proprietary poo poo is a great step forward for professional software development it doesn’t matter how much better hg was, nobody used it so it’s irrelevant
|
|
#
?
Oct 3, 2019 11:14
|
|
|
Soricidus posted:it doesn’t matter how much better hg was, nobody used it so it’s irrelevant Can anyone even claim hg was better? It's fine to call git "bad software" in terms of it being unintuitive or whatever but hg was a loving nightmare unless you live your developer life commiting straight to master or working on monolithic features without ever having to merge in other people's changes.  "Just use bookmarks they're just like git branches!"No they're not. They're a liability.
|
|
#
?
Oct 3, 2019 11:59
|
|
|
I think I've intentionally used hg once. It was on an open source, from scratch operating system project that fell apart about a month and a half in. This was probably about a decade ago. I know that's not empirical evidence that hg is dead, but I don't think I've ever used it even to check a repo out since then. By contrast, I'm not a programmer by trade or even a heavy FOSS user and I use Git a lot. Hell, I think I've typed "cvs" into a terminal more often than I have "hg". Sometimes software just doesn't go anywhere, because something better came along, but a subset of people stayed committed (heh) enough for some maintainer to keep cranking out maintenance releases.
|
|
#
?
Oct 3, 2019 16:37
|
|
|
FWIW, mercurial is far better than git for building additional tooling on top of, since it actually has an api for programmatic access that isn't "invoke the command line tool, or go poking through a bunch of files in a hidden directory and try to mimic what the official tool does with them".
|
|
#
?
Oct 3, 2019 16:58
|
|
|
I know code found from academia/research is cheating, but still...code:
|
|
#
?
Oct 3, 2019 17:24
|
|
|
git is not hard, at all
|
|
#
?
Oct 3, 2019 18:04
|
|
|
I mean, I guess you could say that a door with a pull handle that you're supposed to push is not hard to use either.
|
|
#
?
Oct 3, 2019 18:07
|
|
|
Thermopyle posted:I mean, I guess you could say that a door with a pull handle that you're supposed to push is not hard to use either. Just because you pulled a push handle doesn't make it a pull handle
|
|
#
?
Oct 3, 2019 18:14
|
|
|
xtal posted:Just because you pulled a push handle doesn't make it a pull handle alias git-pull="git push origin master --force"
|
|
#
?
Oct 3, 2019 19:57
|
|
|
xtal posted:Just because you pulled a push handle doesn't make it a pull handle CVS is an old doorknob that slips once in a while and needs a couple tries to open. SVN is a bare latch with a screwdriver jammed into it as a pry-bar.
|
|
#
?
Oct 3, 2019 20:05
|
|
|
xtal posted:Just because you pulled a push handle doesn't make it a pull handle https://99percentinvisible.org/article/norman-doors-dont-know-whether-push-pull-blame-design/
|
|
#
?
Oct 3, 2019 20:34
|
|
|
Kazinsal posted:CVS is an old doorknob that slips once in a while and needs a couple tries to open. SVN is a bare latch with a screwdriver jammed into it as a pry-bar. Perforce is a big pit with spikes at the bottom.
|
|
#
?
Oct 3, 2019 20:43
|
|
|
taqueso posted:Perforce is a big pit with spikes at the bottom.
|
|
#
?
Oct 3, 2019 21:17
|
|
|
Zopotantor posted:ClearCase is like that, but the spikes are covered in poison. And on fire. Visual SourceSafe is a portcullis that opens and slams shut at random intervals. A life insurance broker has a booth outside where he sells contracts consisting mostly of fine print at an exorbitant premium.
|
|
#
?
Oct 3, 2019 21:24
|
|
|
taqueso posted:Perforce is a big pit with spikes at the bottom. You have to request to fall on each spike individually though
|
|
#
?
Oct 3, 2019 21:30
|
|
|
Jabor posted:FWIW, mercurial is far better than git for building additional tooling on top of, since it actually has an api for programmatic access that isn't "invoke the command line tool, or go poking through a bunch of files in a hidden directory and try to mimic what the official tool does with them". Isn't this the problem libgit2 solves? (I haven't used it myself.)
|
|
#
?
Oct 3, 2019 23:28
|
|
|
Yes, but the fact that it's a reimplementation of git and not the library used by git itself is inherently a source of problems.
|
|
#
?
Oct 4, 2019 01:23
|
|
|
I just inserted an assert before the last label in a fall-through switch. I feel dirty.
|
|
#
?
Oct 4, 2019 10:28
|
|
|
xtal posted:git is not hard, at all the difficulty on git is like the difficulty on dynamic typed languages if you are on the surface it can be easier than other options if you dig down you can find complex stuff
|
|
#
?
Oct 4, 2019 14:14
|
|
|
I think git is fine, but what I don't like about it is something I get annoyed by in other areas, most of them in computer science. Giving annoying names to things. For instance, picking everyday words for something that has extremely specific meaning in that domain, but isn't the same as the dictionary definition. It might even have nothing to do with the dictionary meaning, or worse it's almost the same so your previous understanding messes you up. You don't revert something in everyday life, you revert to something. But in git, you revert something. So one might think doing git revert c on commits a, b, c, d, e will undo commits d and e, but you'd be very wrong. Also, picking random slang words that emerged in the group's discourse. It's released so it can be used by people who didn't take part in that chat, and so they don't have the mutual established understanding of the slang word's meaning. But the releasing group are so used to it, they confuse their own lingo with common intuition or vernacular. What the hell does "git cherry" do? quote:Determine whether there are commits in <head>..<upstream> that are equivalent to those in the range <limit>..<head>. Yeah...right. Cherry pick or something I guess? Real useful name.
|
|
#
?
Oct 4, 2019 16:43
|
|
|
TIL about git cherry... From reading the help, it seems to be a thing mostly complementary for git cherry-pick, so I am tempted to give it a pass though Also it is slowly getting better, with things like git switch and git restore.
|
|
#
?
Oct 4, 2019 17:06
|
|
|
Naming things is hard.
|
|
#
?
Oct 4, 2019 17:15
|
|
|
Ola posted:I think git is fine, but what I don't like about it is something I get annoyed by in other areas, most of them in computer science. Giving annoying names to things. For instance, picking everyday words for something that has extremely specific meaning in that domain, but isn't the same as the dictionary definition. It might even have nothing to do with the dictionary meaning, or worse it's almost the same so your previous understanding messes you up. You don't revert something in everyday life, you revert to something. But in git, you revert something. So one might think doing git revert c on commits a, b, c, d, e will undo commits d and e, but you'd be very wrong. I don't know, I think "revert <object>" and "revert to <object>" having different meanings does not originate with git and is pretty well understood.
|
|
#
?
Oct 4, 2019 17:19
|
|
|
Yeah, “revert” long predates git, and “cherry” is a shortening (that I’ve personally never heard of or used) of “cherry-pick”, which I think is an American idiom but a really common one.
|
|
#
?
Oct 4, 2019 17:26
|
|
|
Fair enough that I might be wrong about revert. But picking something that wasn't ambiguous might be better. They probably had a huge screaming fight over why "undo" wouldn't work. "Cherry pick" is obviously a well known idiom, but what exactly do you cherry pick with that command?quote:Determine whether there are commits in <head>..<upstream> that are equivalent to those in the range <limit>..<head>. Is that really the act of cherry picking?
|
|
#
?
Oct 4, 2019 18:21
|
|
|
|
| # ? Jun 8, 2024 03:56 |
|
|
quote:Given one or more existing commits, apply the change each one introduces, recording a new commit for each. That's cherry-pick. Cherry can help you find commits you might want to pick.
|
|
#
?
Oct 4, 2019 18:29
|
|
