I could spend hours and hours and hours just ranting about what an awful experience dealing with git is



  • But I'd get so angry I'd break something. Why are such basic operations for a source control system so fucking hard!?

    Ok I have really no point in posting this since I didn't take notes or screenshots or anything but HOLY FUCK I've spent the last 3 hours wrestling with my source control instead of actually working with code. NOTHING FUCKING WORKS IN GIT. Error messages assume you have psychic powers: "merge is not possible because you have unmerged files. Hint: fix them up in the work tree." Ok, which files are "unmerged?" How do I fix them up? Why does adding a new file to my branch make merging "not possible"? Why is this error message SO FUCKING USELESS? FUUUUUCCCCCKKKKK!!!!!

    Oh well at least it didn't shit text all over my fil-- oh wait you mean it did shit text all over my source control files? Hey here's a good design: a source control system that ALTERS THE CONTENT OF THE FILES ITS STORING. In a stupid ham-fisted way that breaks all your fucking code, to boot. "Syntax error: >>>>>". Thanks git! I love solving bugs that you created in my project!

    Oh hey, here's a real WTF. When doing that merge above, the one that gave me a shitty useless error message? I was working off a freshly-downloaded, 100% clean copy of the files. Since I got git into a state where I couldn't do ANYTHING for some reason, I decided to just say "fuck it", remove my local repository and start over. Guess what? The second time, IT WORKED. 100%! No errors!

    git: the world's first non-deterministic source control system! Same operation? Different results!

    When the guy who picked git gets back from vacation, I swear to Christ I'm going to send him on a permanent vacation.



  • You don't like it? That's odd, I heard it was designed by the same guy who made the Linux kernel.



  • I suggest using some good GUI, like Tower.

    Also, if you have a problem with unmerged files, it's because you tried updating files on which changed stuff, and the changes conflicted with what's coming from the upstream. You could start by checking whatever you changed on the last commit. Any good GUI will show which files have problems, allow you to stash your work while you work it out, and provide you with a few options for merging tools.



  • @Renan said:

    Also, if you have a problem with unmerged files, it's because you tried updating files on which changed stuff, and the changes conflicted with what's coming from the upstream. You could start by checking whatever you changed on the last commit. Any good GUI will show which files have problems, allow you to stash your work while you work it out, and provide you with a few options for merging tools.

     

    @blakeyrat said:

    Oh hey, here's a real WTF. When doing that merge above, the one that
    gave me a shitty useless error message? I was working off a
    freshly-downloaded, 100% clean copy of the files.

     



  • @blakeyrat said:

    it did shit text all over my source control files? Hey here's a good design: a source control system that ALTERS THE CONTENT OF THE FILES ITS STORING.
    That would be the "fix them in the work tree" part. You've got concurrent changes that git couldn't merge automatically, so it dumped the changes in the files in the work copy so you can review the code and make the merge.@blakeyrat said:
    In a stupid ham-fisted way that breaks all your fucking code, to boot. "Syntax error: >>>>>".
    At least it made the changes visible. Better than introducing bugs invisibly, I guess.



  • @Renan said:

    I suggest using some good GUI, like Tower.

    I'd love to. Know of one for the platform 95% of the people on Earth use? (Github for Windows? Not good. Before you suggest that.)



  • @Zecc said:

    @blakeyrat said:

    it did shit text all over my source control files? Hey here's a good design: a source control system that ALTERS THE CONTENT OF THE FILES ITS STORING.
    That would be the "fix them in the work tree" part. You've got concurrent changes that git can't merged automatically, so it dumped the changes in the files so you can review the code and make the merge.

    And it didn't say which files they were, why?

     @Zecc said:

    @blakeyrat said:

    In a stupid ham-fisted way that breaks all your fucking code, to boot. "Syntax error: >>>>>".
    At least it made the changes visible. Better than introducing bugs invisibly, I guess.

     

    It's still an incredibly shitty thing for a source control system to shit all over the source files.

     



  • @blakeyrat said:

    Know of one for the platform 95% of the people on Earth use? (Github for Windows? Not good. Before you suggest that.)
    http://stackoverflow.com/questions/10231389/recommended-git-tools-for-windows



  • @Zecc said:

    That would be the "fix them in the work tree" part. You've got concurrent changes that git couldn't merge automatically, so it dumped the changes in the files in the work copy so you can review the code and make the merge.

    Am I crazy? Isn't the point of a source control system to preserve my code? How does shitting stuff all over my code contribute to that goal? I mean, isn't that like a backup system that puts, "hey you backed this file up a week ago" at the top of every text file it comes across? I mean I'm griping about the usability of this tool being shit, but that, conceptually, is terrible design.

    That said, I'm guessing there's some primitive, unusable, horrible CLI program that will show you the diffs and let you pick which version you want and fixes your file. But the Github for Windows client exposes none of that. If it exists.

    @Zecc said:

    At least it made the changes visible. Better than introducing bugs invisibly, I guess.

    But significantly worse than not fucking with my source files at all!



  • Change to hg and use tortoise. single installer for both is available



  • @DescentJS said:

    And it didn't say which files they were, why?
    I'm no git expert. I'm a total new, in fact. By I would say it's because it assumes you know 'git status'. @DescentJS said:
    It's still an incredibly shitty thing for a source control system to shit all over the source files.
    True.



  • @Zecc said:

    @DescentJS said:

    And it didn't say which files they were, why?
    I'm no git expert. I'm a total noob, in fact. But I would say it's because it assumes you know 'git status'. @DescentJS said:
    It's still an incredibly shitty thing for a source control system to shit all over the source files.
    True.

    Looks like I can't type today.

    Btw, I'm not defending git. I was just playing the devil's avocado. But now I've lost interest. So instead I'll say that git is a needlessly complex mess.

     



  • @blakeyrat said:

    Oh well at least it didn't shit text all over my fil-- oh wait you mean it did shit text all over my source control files? Hey here's a good design: a source control system that ALTERS THE CONTENT OF THE FILES ITS STORING. In a stupid ham-fisted way that breaks all your fucking code, to boot. "Syntax error: >>>>>". Thanks git! I love solving bugs that you created in my project!

    Don't hate on just git; cvs does this too.



  • @DescentJS said:

    @Zecc said:

    That would be the "fix them in the work tree" part. You've got concurrent changes that git can't merged automatically, so it dumped the changes in the files so you can review the code and make the merge.

    And it didn't say which files they were, why?

     

    Probably the same reason Windows says "Unable to delete file xxxxxxx.xxx because it is in use by another program.  Please close the other program and try again.  And you have to guess what program it is.  I know, but I'm not telling, neener neener neener."

     



  • @Helix said:

    Change to hg and use tortoise. single installer for both is available

    If I had a choice, do you think I'd be putting myself through this?



  • @Zecc said:

    @blakeyrat said:

    it did shit text all over my source control files? Hey here's a good design: a source control system that ALTERS THE CONTENT OF THE FILES ITS STORING.
    That would be the "fix them in the work tree" part. You've got concurrent changes that git couldn't merge automatically, so it dumped the changes in the files in the work copy so you can review the code and make the merge.@blakeyrat said:
    In a stupid ham-fisted way that breaks all your fucking code, to boot. "Syntax error: >>>>>".
    At least it made the changes visible. Better than introducing bugs invisibly, I guess.

     

    As hard as it feels, I'll have to agree with blackeyrat on this one. It's an extremely shitty design for some version control tool to modify the files you are editing. That's the standard behaviour of CVS, but all the newer systems realised that it is an extremely bad choice, and adopted the "we'll create new files, instead" policy... Well, except for GIT, it seems.

    Now, the rest of blakey's rant... It's the usual childish "I shouldn't have to learn anything new!".

     



  • So, at some point before this, you merged two branches. I'm guessing you confused git-checkout with git-pull. There were apparently merge conflicts, and git added markers around the conflicts so you could find them.

    Believe it or not, that's a good thing. You don't want these files to compile without having a human to look over them first. The code might compile, but do the two conflicting things in the wrong order, they might be variations of the same thing, and do it twice when it should be done once, or who knows what else.

    So, anyway, you apparently tried to do something else that required a merge - probably using git-pull again - and it wouldn't let you because the previous merge wasn't fixed yet.

    So, you decide you've had enough with source control, and try to be productive and get some code written, only to find it doesn't compile because of the merge conflicts you accidently introduced earlier.

    So; you'll probably want to revert this to back before you accidently merged your two branches, but if not, the way to fix merge conflicts is to use git-status to list the files that need resolution, search for ==== to find and manually fix the conflicts, use git-add on the fixed files, and finally git-commit to tell it everythings better now and to finish the merge.



  • @Mcoder said:

    Now, the rest of blakey's rant... It's the usual childish "I shouldn't have to learn anything new!".

    I love learning new things. I really wish people would stop making up this shit about me.

    What I hate is diving into a something and hitting a brick wall it's impossible to pass without hours and hours and hours of research. Learning things because they make me more productive (like new program features or shortcuts)? That's fun. Learning things because I literally can't progress without the knowledge? That's not fun.

    Source control tools should be like film edits-- when they're good, you don't notice them at all. Git is the opposite of this. It's whiny. It's noisy. It's fussy. Every communication it gives you is either a lie, hopelessly vague, or both. It screws with your carefully-edited files without your permission. It's unpredictable. It's basically like a toddler on a sugar-high.

    It's painfully obvious that approximately zero thought went into its interface and user experience. I'm sure nobody involved with git has even heard of the concept of "discoverability".



  • I didn't even need to finish reading the title to know that this would be a post by blakeyrat



  • Git does not shit all over your work, it's shits all over your working copy, and even then only if it exactly matches what's checked in. There's no way to lose any work due to git's conflict markers.

    You can always abort a merge with a hard reset, and the "shit" will magically go away.

    Or you can use a mergetool if you don't want to see the conflict markers.

    Personally I like merging with the conflict markers, b/c I can do the merge inside my normal editing environment, not some other tool. And most conflicts are pretty simple to fix.



  •  When I discovered git, I just realized how bad all version systems that I met before was. And how simple and logic interface to version system could be. But yes, I did read some manual first and then I did follow it, rather, than follow manual (or memories) for some of the previuos version systems. Andfrom that day I did everything in git, even if I actuallyworked with some other system for historical reasons. I just prepared everything in git and then commit the finalized and good merged product to those other systems. So while I had all my history with all mistakes and dead ways stored in gi, I had just couple of tested and super-clean commits in the "official" system, and no need to undergo all the bad fight with it again :)



  • @blakeyrat said:

    @Helix said:
    Change to hg and use tortoise. single installer for both is available
    If I had a choice, do you think I'd be putting myself through this?
    Here, have lots and lots of candy. And using "gitk" from the command line is incredibly amazing and something everyone should do from time to time. It's a GUI tool, too.



  • @blakeyrat said:

    I was working off a freshly-downloaded, 100% clean copy of the files [and I tried the same thing again and got different results].

    If you honestly think that's how computers work, please back away slowly with your hands up.

    Oh wait, you're complaining that your changes didn't override the other changes in the main repository?



  • @blakeyrat said:

    Error messages assume you have psychic powers: "merge is not possible because you have unmerged files. Hint: fix them up in the work tree." Ok, which files are "unmerged?" How do I fix them up? Why does adding a new file to my branch make merging "not possible"? Why is this error message SO FUCKING USELESS? FUUUUUCCCCCKKKKK!!!!!

    While I find git generally usable just fine, many error messages are totally insane and misleading indeed. One just remembers them after a while. This one simply means that there are uncommitted changes (either staged or unstaged). However apparently (from the next point) the files actually were unmerged, because the previous merge ended with conflicts.

    @blakeyrat said:

    Oh well at least it didn't shit text all over my fil-- oh wait you mean it did shit text all over my source control files? Hey here's a good design: a source control system that ALTERS THE CONTENT OF THE FILES ITS STORING. In a stupid ham-fisted way that breaks all your fucking code, to boot. "Syntax error: >>>>>". Thanks git! I love solving bugs that you created in my project!

    Each and every version control system I ever worked with used this method of marking conflicts. Git is better than any of the others because it makes it easy to recover the 3 states that lead to the conflict and because it only ever does it if all those states are committed. Subversion will do the same thing with conflicts on update with your local modification and that's a much bigger mess to clean up.

    @blakeyrat said:

    Oh hey, here's a real WTF. When doing that merge above, the one that gave me a shitty useless error message? I was working off a freshly-downloaded, 100% clean copy of the files. Since I got git into a state where I couldn't do ANYTHING for some reason, I decided to just say "fuck it", remove my local repository and start over. Guess what? The second time, IT WORKED. 100%! No errors!

    The first one wasn't 100% clean. You probably won't find out what was wrong now that you deleted it, but you definitely did different things each time.

    @blakeyrat said:

    When the guy who picked git gets back from vacation, I swear to Christ I'm going to send him on a permanent vacation.

    You mean he chose git and went to vacation right away? Well, that's a WTF. Git is very good, but it is significantly different from whatever you used before and with the amount of features not really simple. So if he chose git, he really should have provided support for it until everybody gets to speed with it.



  • I haven't actually used git beyond the occasional cloning of something or other as a way of downloading, but the choices for names of commands seem somewhat unintuitive to me. It's probably that I really started with subversion as far as VCS goes. I'm quite happy with mercurial now.

    @Bulb said:

    @blakeyrat said:
    Oh well at least it didn't shit text all over my fil-- oh wait you mean it did shit text all over my source control files? Hey here's a good design: a source control system that ALTERS THE CONTENT OF THE FILES ITS STORING. In a stupid ham-fisted way that breaks all your fucking code, to boot. "Syntax error: >>>>>". Thanks git! I love solving bugs that you created in my project!

    Each and every version control system I ever worked with used this method of marking conflicts. Git is better than any of the others because it makes it easy to recover the 3 states that lead to the conflict and because it only ever does it if all those states are committed. Subversion will do the same thing with conflicts on update with your local modification and that's a much bigger mess to clean up.

    Yes, this seems like SOP. I haven't tried subversion 1.7 (which I've heard has finally improved merging) but trying to do non-trivial merges with subversion is like Barack Obama at a debate. I recently converted an entire subversion repository to mercurial just to do a merge. Subversion had royally fucked it up, and mercurial did a perfect merge without me having to do anything. Blakeyrat should be thankful that he isn't using subversion, where it will mess up your uncommitted work.

    I wonder what blakey thought would happen when conflicts happened. From memory, his main experience with VCS has been with VSS and/or TFS. How do these things do merges and conflicts?

    Finally, blakey, find some gui tool (there have been several linked in this thread). I can't believe that people need to tell you to do this, since you're so unsuited to CLI tools.



  •  My coworker had to use GIT on a project. They were only doing checkout of the change our suppliers did to sources. Even that was a nightmare. 30% of the time you checkout the wrong tree, 30% of the time you get cryptic error messages and 30% of the time your are upgrading your git client because the server did upgrade.

     

    And i totally agree to the non deterministic behaviour.



  • @tchize said:

    30% of the time you checkout the wrong tree

    Does you car also make wrong turns 30% of the time?



  • @tchize said:

    30% of the time you checkout the wrong tree, 30% of the time you get cryptic error messages and 30% of the time your are upgrading your git client
     

    What about the other 10%?



  • @Mcoder said:

    Now, the rest of blakey's rant... It's the usual childish "I shouldn't have to learn anything new!".
    No it isn't. Git really is painful to learn when coming from a source control system like TFS. Branching, merging, conflict solving are very intuitive in TFS.

    When Microsoft started to support Git as a source for deployment on Windows Azure websites I decided to give it a go and I hit the same wall as Blakey. Git has a very steep learning curve. Github for Windows only covers a very small featureset of Git, Webstorm covers a bit more but basically you always need the CLI. For things than you can do in two clicks in TFS, git requires a combination of badly named commands and obscure parameters. If I don't use Git for more than two days, I have to revert back to google just to find out again how to do trivial stuff like pushing tags to the remote again.



  • @bjolling said:

    Git really is painful to learn when coming from a source control system like TFS. Branching, merging, conflict solving are very intuitive in TFS.

    Could you go into more detail about this? I agree that gits commands seem like weird ass choices, but could you describe the differences between merging in TFS and git?



  • @da Doctah said:

    @DescentJS said:
    And it didn't say which files they were, why?
    Probably the same reason Windows says "Unable to delete file xxxxxxx.xxx because it is in use by another program.  Please close the other program and try again.  And you have to guess what program it is.  I know, but I'm not telling, neener neener neener."

    Yes, very annoying.  But, it turns out that Windows won't tell you what program is using a particluar file because it doesn't know and doesn't care.  And apparently it's a deliberate design.

     

     



  • @dhromed said:

    @tchize said:

    30% of the time you checkout the wrong tree, 30% of the time you get cryptic error messages and 30% of the time your are upgrading your git client
     

    What about the other 10%?

    Lunch.

     



  • To be fair, git itself isn't that bad (although its error messages could certainly do with work). The problem is that the GUIs written for it are, to be blunt, (a word for excrement that rhymes with git).

    With git, I have to delve into the CLI at least once a session because the UI breaks horribly. In contrast, TortoiseHG Just Works. I can do everything from the Workbench, it's usable and intuitive... a perfect example of how OSS can be. git GUIs are the exact opposite.

    @blakey, unless git is a project imperative, I don't see any reason why you can't move your source to an Hg repo and save yourself unnecessary pain. You can use the "hg convert" extension to preserve all the repo history. There's also an Hg-Git plugin that allows you to access git repos from Hg, which (from what I can see) should work with TortoiseHG.



  • @boomzilla said:

    @tchize said:
    30% of the time you checkout the wrong tree

    Does you car also make wrong turns 30% of the time?

     

    No, but i don't have to change car 3 times a day. Otherwise, i am pretty sure 30% of the time i would be driving the wrong car :)

     

    The supplier had that habbit of making a new tree for ever change, send us a mail telling 'issue XY is fixed' but not telling us which tree included the changes ^^

     

    As for the 10%, it simply worked :)



  • @tchize said:

    @boomzilla said:
    @tchize said:
    30% of the time you checkout the wrong tree

    Does you car also make wrong turns 30% of the time?

    No, but i don't have to change car 3 times a day. Otherwise, i am pretty sure 30% of the time i would be driving the wrong car :)

    Oh. So when you change cars you forget where you're going, is what you're saying.

    @tchize said:

    The supplier had that habbit of making a new tree for ever change, send us a mail telling 'issue XY is fixed' but not telling us which tree included the changes ^^

    OK, so there was nothing wrong with git, just the gits at your supplier who don't understand what tags are for.



  • Try taking Dimensions for a spin.  When your VCS refuses to allow you to add a new source file because you specified the wrong fucking part number (apparently source code needs pre-defined part numbers) or the wrong 'design part' (wtf is a design part?),

    then you will know anger.  Git is fucking nirvana by comparison.  Bask in the knowledge that it can be far, far worse. 



  • @blakeyrat said:

    That said, I'm guessing there's some primitive, unusable, horrible CLI program that will show you the diffs and let you pick which version you want and fixes your file. But the Github for Windows client exposes none of that. If it exists.

    The ">>>>>>>>>>" markers are a standard convention among 3-way diff tools. A good one for Windows is TortoiseMerge. If you install it and make sure git knows where to find it, you can use it to resolve merge conflicts.

    Git is an excellent piece of software. It is complex because it deals with some complex problems. However it is not very user-friendly and it assumes some *nix knowledge.

    If you don't understand merging, then don't use git's merge capabilities. Even if you use a mostly linear workflow, git is far superior to other systems I have used (svn, and Microsoft's shitty offerings).



  • @The_Assimilator said:

    There's also an Hg-Git plugin that allows you to access git repos from Hg, which (from what I can see) should work with TortoiseHG.

    This. HG-Git and HGSubversion are actually the main reasons I ended up settling on Mercurial as my weapon of choice.



  • Git is on my top ten list of software I dislike with a huge passion. I can't help but constantly compare it to Mecurial, which [i]isn't[/i] completely retarded and isn't utterly hateful to use. Git seems to operate on the principle of [b]most[/b] surprise, giving me the constant feeling that it hates me and is out to get me. That means I don't like it, which means I am reluctant to invest any time into it, which means I'm probably never going to spend enough time to work out how to use it [i]properly[/i], and the circle of hate continues.



    The absolute biggest sin that Git has perpetuated is convincing users that they need Git. Using Git for a project with a small group of developers who all check into a central canonical source repository is like using the Tsar Bomba to crack a walnut. Look, Git is probably awesome if you're Linus Torvalds and you need to manage a thousand developers spread across the entire face of the earth. If you're not Linus Torvalds, or working on a project of similar scope and think that Git will help, then stop that! Git is not the One SCM To Rule Them All. Subversion is probably more than adequate for your needs, believe it or not. If you really must be buzzword compliant, then Mercurial is probably going to annoy you and your developers far less. There's no point arguing about tools like Github either, because you probably can't afford a Github Enterprise license. If you're going to mention hosted Github, then BitBucket is just as good and based on Mercurial (hence, it's better).



    Didn't I mention how much nicer Mercurial is? It is. Mercurial that is. It's nicer. Mercurial.



  • @jamesn said:

    If you don't understand merging, then don't use git's merge capabilities. Even if you use a mostly linear workflow, git is far superior to other systems I have used (svn, and Microsoft's shitty offerings).

    I understand merging. What I don't understand is why the merge didn't work, and how I could have fixed it. I don't understand that because git gave me zero clues to figure it out.

    Have you used TFS recently? I admit it was shit 5 years ago. Now it's pretty good-- it's just annoying about locking files. I could see why it wouldn't be a good choice for something like the Linux kernel, but for the project I'm working on right now, TFS would be a far better choice than git. So would SVN because I know how to use SVN, and the 1-in-1,000,000 chance SVN would screw up something that git would get right doesn't make up for the fact that I spent 3 hours figuring out git when I could have easily done it in SVN in 5 minutes.

    I actually tried Tortoise Git once and its installer didn't fucking work. I didn't even get as far as having a working installed copy of it. Maybe I'll give it another try.



  • @blakeyrat said:

    Have you used TFS recently? I admit it was shit 5 years ago. Now it's pretty good-- it's just annoying about locking files.

    I don't think I could tolerate a VCS that locked files. JOIN THE 21ST CENTURY.


  • Discourse touched me in a no-no place

    @boomzilla said:

    @blakeyrat said:
    Have you used TFS recently? I admit it was shit 5 years ago. Now it's pretty good-- it's just annoying about locking files.

    I don't think I could tolerate a VCS that locked files. JOIN THE 21ST CENTURY.

    But he'd have to learn something to do that!



  •  @Vanders said:

    ... If you're not Linus Torvalds, or working on a project of similar scope and think that Git will help, then stop that!  ...

    I am not Linus Torvalds and I do work on many small projects, some spread over as much as three computers, some on only one. I use GIT for all of them, as it is far better for that, han subversion ever was or will be. Git is much more convenient and logical to work with and do not try to destroy all your work as subversion did. Not mentioning much simpler and faster merging than subversion.

     

    The one and only one thing, that subversion had better is version numbering in source code. But small script in bash can solve even that in better way, than subversion did it. So I do not care.

     

    Maybe GUIs for GIT are bad, but who need GUI? CLI is much better, if you know, what you are doing.



  • @gilhad said:

    logical
     

    Logic doesn't really matter here. Only the software's intent and its use cases have any say in how to set up the UI. Logic is the fast lane to an incomprehensible and unusable interface.

    I'm glad that git caters to you as a CLI-addict and that it works for you.



  • @gilhad said:

    I am not Linus Torvalds and I do work on many small projects, some spread over as much as three computers, some on only one. I use GIT for all of them, as it is far better for that, han subversion ever was or will be. Git is much more convenient and logical to work with and do not try to destroy all your work as subversion did. Not mentioning much simpler and faster merging than subversion.

    What's your usage model where Git so awesome across a three computers and one developer? Assuming you're smart and are actually using the decentralised nature of Git, then if it were me I'd personally use Mercurial. I'm not even going to bother with your perception that Git is more logical than Subversion (good grief no), and I've never once seen Subversion "destroy all your work". Oh and branching & merging in Subversion was never a huge problem, and they made it even better in what, Subversion 1.7? That's so long ago it's not even worth arguing about.



    Like I said, unless you're managing hundreds of branches within branches, and dealing with potential commits from thousands of developers, you do not need all the fancy bells and whistles that Git provides. You won't ever even use them. Simple branching and merging, which is what the vast majority of developers do (even teams of developers working on commercial software) does not require the thermonuclear Git warhead. Use the right tool for the job. Unless you're Linus, Git probably isn't designed to solve the problems you have, so it's the wrong tool.

    @gilhad said:

    Maybe GUIs for GIT are bad, but who need GUI? CLI is much better, if you know, what you are doing.

    I'm a Linux sysadmin. The closest I've come to a GUI for Git is Gitk. The Git command line interface is hateful. I'll say it again: it operates on the principle of most surprise. It is not discoverable. Its output is ugly and confusing. Error reporting is so laughable it'd be funny if it weren't so dangerous.



  • @Vanders said:

    ...and I've never once seen Subversion "destroy all your work".

    I imagine he's talking about that fact that subversion uses the merge then commit paradigm instead of commit then merge, like git and mercurial (and other modern VCSes). I've been bitten by this design flaw. I don't think it destroyed all of my work, but it made my life a lot worse than it needed to be. I'd rather use git than subversion. Fortunately, I don't have to use either.



  •  why not turn hours and hours of ranting into a hour or two use case for changing VCS to something that you already know how to use or has a shallow learning curve?



  • Discourse touched me in a no-no place

    @blakeyrat said:

    @Mcoder said:
    Now, the rest of blakey's rant... It's the usual childish "I shouldn't have to learn anything new!".

    I love learning new things. I really wish people would stop making up this shit about me.

    We aren't making it up. You're saying so yourself:

    What I hate is diving into a something and hitting a brick wall it's impossible to pass without hours and hours and hours of research. Learning things because they make me more productive (like new program features or shortcuts)? That's fun. Learning things because I literally can't progress without the knowledge? That's not fun.

    Which means that you shouldn't have to learn anything new to use git.

    Source control tools should be like film edits-- when they're good, you don't notice them at all. Git is the opposite of this. It's whiny. It's noisy. It's fussy. Every communication it gives you is either a lie, hopelessly vague, or both. It screws with your carefully-edited files without your permission. It's unpredictable. It's basically like a toddler on a sugar-high.

    It's painfully obvious that approximately zero thought went into its interface and user experience. I'm sure nobody involved with git has even heard of the concept of "discoverability".

    I haven't used git extensively, but from what I've read here, you obviously have no idea what you're doing with it and are suffering as a result. Also, have you considered that the type of hyperbole you often use (the last paragraph is an excellent example) might contribute to the number of arguments you seem to get into on this site?


  • @PedanticCurmudgeon said:

    Which means that you shouldn't have to learn anything new to use git.

    How do you get from what I said to that? WTF?

    No, it means git should be discoverable-- if there's something I need to learn to use git, it should guide me in the right direction to ensure I learn it. Right now there's no guidance. Like I posted on Twitter yesterday, the error message would have been just as useful if it read, "didn't work, fuck you".

    @PedanticCurmudgeon said:

    I haven't used git extensively, but from what I've read here, you obviously have no idea what you're doing with it and are suffering as a result.

    I know. You don't consider that a bad thing?

    @PedanticCurmudgeon said:

    Also, have you considered that the type of hyperbole you often use (the last paragraph is an excellent example) might contribute to the number of arguments you seem to get into on this site?

    No I do it because it's funny. And because idiots like you don't fucking read what I typed anyway, as evidenced in the post I'm replying to.



  • @PedanticCurmudgeon said:

    @blakeyrat said:
    It's painfully obvious that approximately zero thought went into its interface and user experience. I'm sure nobody involved with git has even heard of the concept of "discoverability".

    I haven't used git extensively, but from what I've read here, you obviously have no idea what you're doing with it and are suffering as a result. Also, have you considered that the type of hyperbole you often use (the last paragraph is an excellent example) might contribute to the number of arguments you seem to get into on this site?

    Yeah...especially considering this:

    @the simplest git session evar said:


    $ git
    usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
    [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
    [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
    [-c name=value] [--help]
    <command> [<args>]

    The most commonly used git commands are:
    add Add file contents to the index
    bisect Find by binary search the change that introduced a bug
    branch List, create, or delete branches
    checkout Checkout a branch or paths to the working tree
    clone Clone a repository into a new directory
    commit Record changes to the repository
    diff Show changes between commits, commit and working tree, etc
    fetch Download objects and refs from another repository
    grep Print lines matching a pattern
    init Create an empty git repository or reinitialize an existing one
    log Show commit logs
    merge Join two or more development histories together
    mv Move or rename a file, a directory, or a symlink
    pull Fetch from and merge with another repository or a local branch
    push Update remote refs along with associated objects
    rebase Forward-port local commits to the updated upstream head
    reset Reset current HEAD to the specified state
    rm Remove files from the working tree and from the index
    show Show various types of objects
    status Show the working tree status
    tag Create, list, delete or verify a tag object signed with GPG

    See 'git help <command>' for more information on a specific command.

    This is the equivalent of opening up a GUI program and looking at what shows up on the screen. Whatever you think about git, there's definitely discoverability built into the CLI version. Most of those should be familiar concepts to anyone with a clue about VCS.

    Of course, what's "painfully obvious" is very different to different people.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.