|
Is there a source control thread? Should there be?
|
#
?
Aug 15, 2017 18:10
|
|
|
|
| # ? May 30, 2024 14:13 |
|
|
Blue Footed Booby posted:Is there a source control thread? Should there be? Yes.
|
|
#
?
Aug 15, 2017 18:15
|
|
|
ratbert90 posted:*Edit* The proper response to "this tool is difficult to use and makes it incredibly easy to shoot your own foot" is not "git gud," it's "okay so what steps can we take to make the tool better?" If the user interface to your tool makes people invoke img-eve-difficulty-curve then chances are you've hosed up along the way and should stop and fix it. But this will never happen because the people that maintain git have absolutely no interest whatsoever in actually providing a sane and consistent user interface. So gently caress them, and gently caress their tooling, and gently caress the entire open source ecosystem for standardizing on a lovely tool that nobody wants to fix. If a tool makes my life harder instead of easier, I'm not going to want to use that tool. I'll be using another tool instead. McGlockenshire fucked around with this message at 18:20 on Aug 15, 2017 |
|
#
?
Aug 15, 2017 18:18
|
|
|
Again, my problem with git is not with the source control mechanism itself, it's with the unintuitive CLI. EG, why doesn't git branch default to checking out to that branch? Has anyone created a branch with the express purpose of not using it? To which you can argue, 'ah, yes, but there's a flag you can use to do so...' - but why is that a flag, rather than the default? Shouldn't flags be there for less common use patterns? The arguments I hear git programmers use are the same ones I hear from hardcore C programmers. Yes, if you know exactly what you're doing, it's fine. But for most programmers, it would be better to work with an easier, more abstracted language, even if you lose out on some power by doing so.
|
|
|
#
?
Aug 15, 2017 18:28
|
|
|
Eela6 posted:Again, my problem with git is not with the source control mechanism itself, it's with the unintuitive CLI. Git was created by Linus for Linus. And Linus is no longer a developer primarily. He is a maintainer. Why does it do X instead of Y? Because it helps Linus and you can gently caress off. So, unless you are a maintainer of an extremely large project, git's way of doing things could look awkward to you. But that's ok, since you do have 3 choices: Learn to use it, make your own (better) tool or use one of the many version control systems already out there.
|
|
#
?
Aug 15, 2017 18:33
|
|
|
Fascinating discussion on source control. NOT
|
|
#
?
Aug 15, 2017 18:35
|
|
|
Ugh have you ever tried actually using NOT's command line interface? It's the loving worst
|
|
#
?
Aug 15, 2017 18:56
|
|
|
Zaphod42 posted:You just haven't learned how to think in git ways yet. This is actually way easier to manage in git, you just... need to do it the Git Way. Thank you for this. I'll have a (delayed) read - I thought that using CVS will be (and should be) transferable experience, but now I suppose there's really no way of learning how Git should be approached on the go. rjmccall posted:You can ignore the git philosophers. Just make your weird mish-mash of intermingled commits locally, then do an interactive rebase from the start of the chain and reorder/combine them however you like. Yeah - if I understand correctly, that's what I've been doing so far, although thank you for pointing out that you can reorder the history and merge local commits (atm that's, I think, the only thing that makes me angry, when I've ABABCAC etc. commits). Eela6 posted:The arguments I hear git programmers use are the same ones I hear from hardcore C programmers. Yes, if you know exactly what you're doing, it's fine. But for most programmers, it would be better to work with an easier, more abstracted language, even if you lose out on some power by doing so. It's a little bit unfair - you can always install an application that provides more intuitive interface for handling Git and removes the functionalities that you don't necessarily need (and there're plenty of them). On the other hand, I've installed TortoiseGit, because other applications I've tried suffered from one thing to the other (GitKraken - didn't know where to even start, Tower - couldn't setup SSH) and it was enough similar to TortoiseSVN
|
|
#
?
Aug 15, 2017 19:00
|
|
|
I hardly ever have to do anything outside the norm with git so the cli is just fine to me
|
|
#
?
Aug 15, 2017 19:41
|
|
|
Pijul is so cool but the network effect is big enough at this point that I think git will be permanent.
|
|
#
?
Aug 15, 2017 19:49
|
|
|
ratbert90 posted:Then I started interviewing. uncurable mlady posted:it's the fact that vast swathes of professional developers have 0 loving interest in learning new things or learning things that are ancillary to their job of shifting out jira tickets all day. That really is the job though 
|
|
#
?
Aug 15, 2017 20:08
|
|
|
Git provides no abstraction between its inner workings and the end-user. Git GUIs further cement this by mostly just providing "the CLI but with buttons for the commands". I'm not sure how people don't realize this is "unfriendly". UIs should be designed around performing the tasks the end-user wants to do, not the state changes you need to go through to accomplish the task.
|
|
#
?
Aug 15, 2017 20:16
|
|
|
Eela6 posted:Again, my problem with git is not with the source control mechanism itself, it's with the unintuitive CLI. The CLI is pretty intuitive and easy to use though; more so than CVS. Good loving luck trying to handle merges and check ins on a project of any size with CVS CLI. You're using some GUI tool. So at that point, compare that to a git GUI tool, which is the exact same thing??? Unfair comparison. If you want a GUI tool download a GUI tool. Git GUIs for all IDEs exist already. Dude if git branch not checking out gives you such a headache, create an alias? Well, I guess you'd need a branchname but... write a function? That's trivial. No, I completely disagree. Its nothing like C. It is way way way easier to blow everything up on CVS than Git. The idea that Git is this complicated super advanced thing that once you master is good but otherwise sucks is completely inaccurate. I took an entire team from CVS to Git in a day. Its not rocket science. Easier and more abstracted is exactly how I describe git! Instead of having to merge all these files constantly with this one snapshot repo you can just freely branch and merge over and over.
|
|
#
?
Aug 15, 2017 20:17
|
|
|
Zaphod42 posted:The CLI is pretty intuitive and easy to use though Nobody (well, i guess almost nobody) thinks this unless you're using git in the most basic of ways. (which to be fair, is sufficient most of the time)
|
|
#
?
Aug 15, 2017 20:20
|
|
|
SupSuper posted:Git provides no abstraction between its inner workings and the end-user. You wish. Git commands are split into plumbing and porcelain. The porcelain commands are the ones you use every day. They are the user friendly interface. Like any good toilet, git repos are filled with poo poo.
|
|
#
?
Aug 15, 2017 20:27
|
|
|
Oh, someone was talking about using git in intellij/webstorm/jetbrains stuff. It works great except for the fact that you can't commit parts of files like you can with something like git-gui. (aka git add -p) Fortunately, according to that issue it sounds like they're working on adding it. Unfortunately, their brief description of their proposed mechanism (changelists) sounds kind of clunky to me.
|
|
#
?
Aug 15, 2017 20:37
|
|
|
SupSuper posted:Git provides no abstraction between its inner workings and the end-user.
|
|
#
?
Aug 15, 2017 20:54
|
|
|
Thermopyle posted:Oh, someone was talking about using git in intellij/webstorm/jetbrains stuff. Oh, that's pretty cool! Although this from SO seems a bit clunky, the git gui way in diff seems more sane. When I asked about partial commits, my more knowledgeable colleague suggested that you would have to do it per branching file, and commiting separate functionalities in different branches (so, for functionalities A and B within single file, you'd revert the code to beginning, create branches, do A in one, do B in other, commit, merge) which seemed very unnecessary (but I guess sensible). It's good to know something like this exists.
|
|
#
?
Aug 15, 2017 21:14
|
|
|
Zaphod42 posted:The CLI is pretty intuitive and easy to use though; more so than CVS. Good loving luck trying to handle merges and check ins on a project of any size with CVS CLI. You're using some GUI tool. So at that point, compare that to a git GUI tool, which is the exact same thing??? Unfair comparison. If you want a GUI tool download a GUI tool. Git GUIs for all IDEs exist already. Git CLI is insanely unintuitive, for reference look at the most viewed posts on stackoverflow, almost all of them are instructions on really basic tasks that should be intuitive but instead are really opaque. Git is awesome. It's insanely powerful and the things it can do constantly amaze me. It's also a pile of poo poo, I've been using git for years, often doing fairly complex tasks, but even still I have to google basic functionality constantly because none of it makes sense. And it needs an official GUI that isn't poo poo. Simple things like diffing are an unusable disaster via CLI - that's a task that's really not suited for CLI and forces everyone to use a myriad of third-party tools, many of which suck and make the landscape harder to navigate, because finding instructions on how to do something will only be applicable to that third-party tool, and there's no clear leader in that area.
|
|
#
?
Aug 15, 2017 21:21
|
|
|
The Dark Wind posted:Is WebStorm's git tools similar to IntelliJ? Right now I'm using VS Code and the CLI. They have a git tool that I've never paid any particular attention to, but if some day I have to in a professional setting and it's not enough, I'm curious how the JetBrains solution stacks up. I'm late to the party, but, WebStorm's git tools are nearly identical to PHPStorm's or IntelliJ's with very little exception. For context, I got my bearings with git using git extensions and only ever dropped down into CLI whenever a wizard told me to do something special in it, and just having the tool flash whatever git command it was running was enough for me to get an idea of what was going on and now I'm pretty fluent at using CLI git. JetBrains' git workflow threw me a curveball but it was worth picking up, but mostly just to keep my focus and have less context switching. JetBrains' approach to git is a little bit different than just using CLI or any other "git UI tool" I've used. If you are working in a linear history then it is as simple as hitting ctrl+k every once and a while (similar to using VS Code with git integration), but if you're trying to prepare a feature branch for a PR with an upstream repository then the notion of change sets might complicate your work flow in a way you might not be familiar with. Change sets are really cool if you need to switch contexts a lot, for things that should be broken out into their own feature branches but with less retracing of steps. Sometimes it might be a little bit difficult to fully grasp what state your repo and your reflog is in. Some questions I found myself asking often even though I thought I was familiar with most git tools were: Where is my local HEAD? Which of these branches are my repo's and which one is the similarly named upstream one? How do I just rebase this entire branch straight to wherever upstream is at? Once you start using it you learn what to look for but it's easy for those features to be so out-of-your-way that you barely even notice when they're there, even if you might be familiar with other tools. Over-all learning to use them within the editor with the keyboard shortcuts has saved me a lot of time compared to the CLI _and_ git extensions. A big part in learning what I wanted was, when I got exhausted looking around the UI or in the docs for what I wanted was to just press ctrl+shift+a (to open the action/option search) and type something like git rebase and seeing what the dialogs would show me. EntranceJew fucked around with this message at 22:42 on Aug 15, 2017 |
|
#
?
Aug 15, 2017 22:35
|
|
|
Taffer posted:Git CLI is insanely unintuitive, for reference look at the most viewed posts on stackoverflow, almost all of them are instructions on really basic tasks that should be intuitive but instead are really opaque. Git is awesome. It's insanely powerful and the things it can do constantly amaze me. It's also a pile of poo poo, I've been using git for years, often doing fairly complex tasks, but even still I have to google basic functionality constantly because none of it makes sense. If only there was a way to open up your preferred diff tool from git preserving all relevant information. like git-diff but to open up vimdiff or kdiff instead of dumping to the terminal. If only someone thought to make git-difftool.
|
|
#
?
Aug 15, 2017 23:34
|
|
|
Those who defend git's intuitiveness but do not have Mercurial experience should be aware of a few things. - Mercurial has ordinal revisions. Meaning, numbers starting from zero. They're local to each clone, and exist concurrently with the hash revision IDs. Mercurial could work without them, but they exist for UI benefit, so that users can specify ranges of revisions with ranges of numbers, and not "ancestors of this but not this" which borders on writing a script. - Mercurial has rebasing, hard resetting, history rewriting, partial committing. All that stuff in git that's handy if you're prepared to learn it, but not strictly necessary. It comes in the distribution but it's TURNED OFF, because new users shouldn't be bothered with it. When you're ready for one of these features, you can enable it in your config file and go. - Mercurial has no command "forms" indicated by the post-option arguments, because expressing variations is what options are for. As a result, it can follow the longstanding Unix command line convention of using "--" to separate options from trailing arguments, not some trailing arguments from others. - As an example if you want to rebase revisions from A to B onto C, Mercurial rebase requires you to tag each of those with an option, rather than specifying two of them (which two?) in a particular order (which?) and the third with an option that modifies (or maybe doesn't) the semantics of the other two. Git's CLI has been created by and for people who breathe shell scripts, people who long ago forgot how silly it is to write something like [ "x$file" = x ]. And we know that it didn't have to be like that, because Mercurial didn't make the same mistakes. Gazpacho fucked around with this message at 23:40 on Aug 15, 2017 |
|
#
?
Aug 15, 2017 23:35
|
|
|
McGlockenshire posted:The proper response to "this tool is difficult to use and makes it incredibly easy to shoot your own foot" is not "git gud," it's "okay so what steps can we take to make the tool better?" Git gud was a joke. Calm down. Also git is easy and works well. I dont think I have ever had any major issues with it. I use it 100% in the CLI and have never ever had an issue with it. Also the best gui for git is githubs gui. Also people ask on stackoverflow because they cant be arsed to type "man git" FlapYoJacks fucked around with this message at 23:53 on Aug 15, 2017 |
|
#
?
Aug 15, 2017 23:47
|
|
|
Gazpacho posted:Those who defend git's intuitiveness but do not have Mercurial experience should be aware of a few things. Honestly, I think two of the three things you listed make the mercurial UI worse than git's, based on my experience. Gazpacho posted:- Mercurial has ordinal revisions. Meaning, numbers starting from zero. They're local to each clone, and exist concurrently with the hash revision IDs. Mercurial could work without them, but they exist for UI benefit, so that users can specify ranges of revisions with ranges of numbers, and not "ancestors of this but not this" which borders on writing a script. Having an obvious revision identifier which is not portable to different clones is a user-hostile mistake. It results in people trying to communicate "look at revision 17" and having their coworker look in the wrong place, because neither understood that they were not appropriately communicating a global identifier. Gazpacho posted:- Mercurial has rebasing, hard resetting, history rewriting, partial committing. All that stuff in git that's handy if you're prepared to learn it, but not strictly necessary. It comes in the distribution but it's TURNED OFF, because new users shouldn't be bothered with it. When you're ready for one of these features, you can enable it in your config file and go. Having features which are unavailable until a config file is modified is a user-hostile mistake. It results in people writing scripts which mysteriously fail for other users, or it results in some users accidentally breaking their config because they want to use one of these tools, and it means that you have to defensively write documentation and tooling as if all of your users are using their own uniquely personalized VCS instead of a single well-defined program. Gazpacho posted:- Mercurial has no command "forms" based on the the post-option arguments, because expressing variations is what options are for. As a result, it can follow the longstanding Unix command line convention of using "--" to separate options from trailing arguments, not some trailing arguments from others. This is fair. Named arguments are more self-documenting than positional arguments, just like in programming languages.
|
|
#
?
Aug 15, 2017 23:53
|
|
|
ShoulderDaemon posted:Having features which are unavailable until a config file is modified is a user-hostile mistake. It results in people writing scripts which mysteriously fail for other users, or it results in some users accidentally breaking their config because they want to use one of these tools, and it means that you have to defensively write documentation and tooling as if all of your users are using their own uniquely personalized VCS instead of a single well-defined program. e: which is not to say that Mercurial lacks an ecosystem. It's just coded in Python, not bash, and at that level features are not turned off. Gazpacho fucked around with this message at 00:18 on Aug 16, 2017 |
|
#
?
Aug 16, 2017 00:11
|
|
|
What are you people doing with Git that makes you feel like you need an army of shell scripts to manage it? Nearly all of my Git usage can be distilled down to 10 commands:
Am I missing something in this discussion? The Mercurial CLI suite isn't any friendlier for the commands I just listed, and the second you start using Mercurial for actual things you run into the buzzsaw of annoying error messages like abort: cannot rebase immutable changeset because Mercurial knows best about history rewriting and abort: abandoned transaction found - run hg recover! because Mercurial is a fragile flower when it comes to repo integrity. It lost versus Git for a reason, and it's not just because it's like an order of magnitude slower.
|
|
#
?
Aug 16, 2017 00:26
|
|
|
chutwig posted:What are you people doing with Git that makes you feel like you need an army of shell scripts to manage it? Nearly all of my Git usage can be distilled down to 10 commands: Don't forget git push origin :butts Or more importantly git bisect Not sure what you would want a shell script for other than passing to bisect though.
|
|
#
?
Aug 16, 2017 00:32
|
|
|
Gazpacho posted:So it''s user-hostile, where the user is the developer of consumer of a script. You're kind of making my final point here. The goal should be to make something that serves its purpose without an ecosystem of scripts. I mean, this is a completely fair point, but there are definitely communities of users who can and do write shell scripts to automate tasks, but are not software engineers and can't program a drat thing in Python. I'm probably colored in my perception because I work in a large team where git was specifically chosen as "less magic" than mercurial by a group of people who were essentially novice users of revision control - in many cases I would classify my users as non-programmers, and they value being able to write down a sequence of commands and have them reliably do the same thing for everyone more than they value the tool being easy to understand, because they just aggressively script every single flow they use.
|
|
#
?
Aug 16, 2017 00:37
|
|
|
I don't think I've ever written a shell script for git operations other than filter-branch shenanigans, which is about as far from a routine operation as you can get. There's certainly nothing I do on a regular basis that involves running a sequence of git commands.
|
|
#
?
Aug 16, 2017 00:40
|
|
|
Yeah, I have just a couple aliases, the only complicated one of which is to format the log how I want it. And I'm all about reftree hacking.
|
|
#
?
Aug 16, 2017 01:00
|
|
|
I use SourceTree for Git. It's okay.
|
|
#
?
Aug 16, 2017 02:35
|
|
|
SourceTree is real, and strong, and he's my friend.
|
|
#
?
Aug 16, 2017 02:45
|
|
|
Mezzanine posted:SourceTree is real, and strong, and he's my friend. The main problem with git are the fanbois. Oh boy, they're annoying as hell. And SourceTree should be a non-starter for the simple fact that they want you to register on their stupid website. And a newb can easily gently caress up git commits/branches with SourceTree just as easily as he/she can do it via the normal console. I know that for a fact, I've seen them at work. It's pathetic. "force push" should only be available in an UI after a thesis has been created and submitted and a git exam has been passed by the user. Otherwise a box glove should come out of the monitor to punch that user in the nose whenever he/she tries to "force push" anything. anywhere.
|
|
#
?
Aug 16, 2017 03:08
|
|
|
Volguus posted:The main problem with git are the fanbois. Oh boy, they're annoying as hell. I don't use --force; can you still just reflog to get the pointer to the lost commits back? Fergus Mac Roich fucked around with this message at 03:30 on Aug 16, 2017 |
|
#
?
Aug 16, 2017 03:26
|
|
|
This is my (inaccurate) mental image of Sourcetree:
|
|
#
?
Aug 16, 2017 03:31
|
|
|
Fergus Mac Roich posted:You wish. Git commands are split into plumbing and porcelain. The porcelain commands are the ones you use every day. They are the user friendly interface. if your toilet is full of poo poo all the time then you really need to hire a plumber or stop having over so many lovely guests
|
|
#
?
Aug 16, 2017 03:35
|
|
|
Fergus Mac Roich posted:I don't use --force; can you still just reflog to get the pointer to the lost commits back? I have no idea. What we did was educate the fools on how to use git. Without SourceTree. And to never ever (not even in your dreams) use "force" for anything. I left before the training was over so I have no idea how well it worked.
|
|
#
?
Aug 16, 2017 03:35
|
|
|
Horse Clocks posted:It was always 'git rebase origin/develop; git push --force; github-merge' (repeat this for 5 mins until nobody else had done the same while you were doing it) I've used git bisect to isolate the exact problem with your workflow. What the gently caress are you doing all dropping steaming turds on a single develop branch? Even if you don't use feature branches jesus christ at least have bob-develop and joe-develop separate. Pristine commits are a godsend for hunting down regressions - you're guaranteed the tree will build. Dozens of WIP landmines everywhere make debugging a nightmare. There's a lot of warts on git. Most of it comes from maintaining backwards compatibility with the shell scripts linus whipped up in a few days a decade ago. The one that hits people most often has got to be "how does rebasing work?" The incantation to get it to move some commits from branch A to branch B is incredibly arcane - even the guys upthread who answered my question got it wrong (Even if you're checked out on a branch, rebase --root --onto only wants to grab the first commit, not all of them.) Associating a local with remote branch is always a horror too - the command understands exactly what you want to do, and smugly gives you what you needed to type to actually do it. Why is "I've created a new feature branch and want to push it to a same-named new remote" not the default? Who knows. And I say this as someone who uses the "e" command in git -p to edit the raw diffs to separate out logical changes. Harik fucked around with this message at 04:27 on Aug 16, 2017 |
|
#
?
Aug 16, 2017 04:08
|
|
|
Harik posted:I've used git bisect to isolate the exact problem with your workflow. What the gently caress are you doing all dropping steaming turds on a single develop branch? Even if you don't use feature branches jesus christ at least have bob-develop and joe-develop separate. Pristine commits are a godsend for hunting down regressions - you're guaranteed the tree will build. Dozens of WIP landmines everywhere make debugging a nightmare. Another thing you can do with Git is create a named and documented tag for a specific revision, say if that's when you did code review with your lead, and you want to know where to pick it up in the next review (assuming you need at least one more before it's good to merge).
|
|
#
?
Aug 16, 2017 04:22
|
|
|
|
| # ? May 30, 2024 14:13 |
|
|
Absurd Alhazred posted:Another thing you can do with Git is create a named and documented tag for a specific revision, say if that's when you did code review with your lead, and you want to know where to pick it up in the next review (assuming you need at least one more before it's good to merge). That's good too, although that's more useful when you're doing raw git than something with integration (github enterprise/gitlab/whatever) that handles code review in the UI. Apropos to this thread, any workflow with a lack of code review is the real horror.
|
|
#
?
Aug 16, 2017 04:31
|
|