|
ColdPie posted:You can also learn the Git CLI interface, which is very user-friendly. Yeah, I hardly ever bother using GUI git stuff on Windows. I almost always use the command line and it works perfectly. ON WINDOWS!!!!!!
|
#
?
Apr 16, 2011 03:50
|
|
|
|
| # ? May 12, 2024 11:57 |
|
|
ColdPie posted:You can also learn the Git CLI interface, which is very user-friendly. I didn't want to scare away the kind of people who think the msysgit installer is too complex.
|
|
#
?
Apr 16, 2011 07:07
|
|
|
Thermopyle posted:Yeah, I hardly ever bother using GUI git stuff on Windows. I almost always use the command line and it works perfectly. ON WINDOWS!!!!!! I don't think anyone was arguing about the functionality of git on Windows. It was mostly an issue with the installer. I remember last year when I looked the download page for msygit didn't have a binary for windows. TortoiseGit still requires you to install msygit instead of bundling it together. This is a huge failure in my opinion and will only help deter new users from adopting it.
|
|
#
?
Apr 16, 2011 16:20
|
|
|
MEAT TREAT posted:I don't think anyone was arguing about the functionality of git on Windows. It was mostly an issue with the installer. I remember last year when I looked the download page for msygit didn't have a binary for windows. Does TortoiseGit have any affiliation with Git for Windows? I don't really have any clue, but I assumed it was just a program that used Git for Windows. In other words, if my assumption is right complaining that you have to install msysgit to use TortoiseGit is like complaining that you have to have Word installed to use some Word add-on. Anyway, for a developer to write off git because it's installer needs improved (I don't think anyone thinks it doesn't...do they?) is just loving stupid. Five minutes of Googling and you can figure out what options you need. If you can't do this I don't know how you write computer programs. After you install Git for Windows it works fine.
|
|
#
?
Apr 16, 2011 17:14
|
|
|
Captain Corny posted:I wrote an article about my first experiences with Git on Windows, and would appreciate some feedback. I can agree with you to an extent, for I had similar experiences when getting started with Git on Windows. I'm not a fan of Cygwin and I ran into problems with GitCheetah that required a system restore to fix. But it really is simple once you realize what you're doing: I chose "Run Git from the Windows Command Prompt", didn't install any explorer extensions, and it works easily from the command line. I also use TortoiseGit, but I hear it promotes bad practices to Git users coming from Subversion. The "once you realize what you're doing" part is admittedly a fault, and a large one at that. It might have been where I was looking, but assistance for starting up on Windows was hard to find and what I did find wasn't very helpful. Maybe there wasn't much assistance because the process was so simple nobody required it — but I had no way of knowing that!
|
|
#
?
Apr 16, 2011 20:30
|
|
|
ToxicFrog posted:
quote:(2) Why are you writing off the entire concept of DVCS based on a bad experience with one windows build of git? You kind of give the impression that you went into this wanting to dislike git so you could dismiss DVCS as a whole and reassure yourself that by using SVN, you've made the right choice. quote:(3) As a windows user, why did you decide to start with Git in the first place when even Git diehards like myself agree that Mercurial has better windows support? Also, past experiences with earlier Linux flavors and some other open source software didn't help. I don't like wasting time, and when software makes me jump through hoops that clearly aren't necessary and due to developer laziness, I simply will not use that software anymore. I use Linux for all things server side by the way, and I run an Ubuntu server at home. Here's a question for you: Why is apt-get easier to use than the Git installer for Windows? NOISIA posted:I can agree with you to an extent, for I had similar experiences when getting started with Git on Windows. I'm not a fan of Cygwin and I ran into problems with GitCheetah that required a system restore to fix. But it really is simple once you realize what you're doing: I chose "Run Git from the Windows Command Prompt", didn't install any explorer extensions, and it works easily from the command line. I also use TortoiseGit, but I hear it promotes bad practices to Git users coming from Subversion. GitCheetah requiring a system restore is just another thing that pisses me off in a major way. This is advertised as mature software. quote:The "once you realize what you're doing" part is admittedly a fault, and a large one at that. It might have been where I was looking, but assistance for starting up on Windows was hard to find and what I did find wasn't very helpful. Maybe there wasn't much assistance because the process was so simple nobody required it — but I had no way of knowing that! Captain Corny fucked around with this message at 21:01 on Apr 16, 2011 |
|
#
?
Apr 16, 2011 20:37
|
|
|
Captain Corny posted:Why is apt-get easier to use than the Git installer for Windows? Git relies on the GNU toolchain and even needs a perl installed. On *any* linux system that's a given, on windows? Total loving crapshot. You might have SFU installed, or a different version of msys already, or cygwin. Then you might have various versions of tools installed in cygwin, be they gnu, perl or even git itself. That's a hundred possible ways of existing tools to conflict with what you're going to install. (The git command you call with option two is actually a git.cmd that sets up a shell environment for the git executable so it can find the packaged dependencies and then calls it with your parameters.) Thus, the msysgit maintainers can't take *any* chances and need to provide you with everything git needs, but at the same time need to make sure installing it doesn't mean shooting yourself in the foot. On linux it's as easy as just defining your deps. Captain Corny posted:Yet, these people were telling everyone that Git was the best thing since sliced bread. Why? And just to dispell the myth that git is only useful in big projects with multiple people: Git gives you the staging area to commit to. That means that even when you're working on a project solo and don't even have a remote server acting as a backup repo, it's *still* better than svn for this reason: When you've hacked on your project and did 3 separate changes in the same file to complete feature X, on SVN you have to commit them at once. In git you can select the lines for the first logic change, commit that with a clear message; select the lines for the second logic change, commit that with a clear message; select the lines for the third logic change, commit that with a clear message and you have a very clear and easily readable change log. Plus, when one of these changes turns out to be ill-advised you can go back, branch off the offending change, modify it in the branch, reintegrate it and have a clear representation of what happened in your history. Also, it provides extra fault-checking as you'll often spot mistakes while reviewing staged changes. So basically, git will make you code better and this is no exxageration. And again, i'm a hardcore windows user, i refuse to even look at code in vi on ssh sessions and will get it into my IDE first. So don't think i'm some kind of linux-neckbeard white-knighting for his precious FOSS toys. I measure tools by how much work they allow me to get done and git beats anything else out there. Mithaldu fucked around with this message at 21:00 on Apr 16, 2011 |
|
#
?
Apr 16, 2011 20:57
|
|
|
I probably had an advantage when I started using git because it was my first VCS. Many of the complaints I hear about it are from people trying to use it like a traditional system.
|
|
#
?
Apr 16, 2011 21:28
|
|
|
Mithaldu posted:Because: e2: Perl, really? What's Perl doing in what ought to be a straight C/C++ project. quote:Because git actually is, even if you have to use it through the command line. The only reason i personally use tortoise because its commit log is prettier. No other reason. TortoiseGit's main value is to provide a crutch to people transitioning from TortoiseSVN. As people grow used to git they'll slowly gravitate away from it and start using git directly. quote:And just to dispell the myth that git is only useful in big projects with multiple people: Git gives you the staging area to commit to. That means that even when you're working on a project solo and don't even have a remote server acting as a backup repo, it's *still* better than svn for this reason: quote:And again, i'm a hardcore windows user, i refuse to even look at code in vi on ssh sessions and will get it into my IDE first. So don't think i'm some kind of linux-neckbeard white-knighting for his precious FOSS toys. I measure tools by how much work they allow me to get done and git beats anything else out there. e: I don't believe a hardcore windows user who hates vi knows as much as you do about the GNU toolchain by the way. You sound more like a hardcore Linux user with some experience on Windows. Captain Corny fucked around with this message at 23:13 on Apr 16, 2011 |
|
#
?
Apr 16, 2011 21:30
|
|
|
Captain Corny posted:So, an early software design decision ends up exposing first time Git users to the complex inner workings of the software they're about use. Bad design decision. Dumb design decision. And i think your conclusion is unfair. The people doing msysgit (who are NOT the people who made git) are doing their best to make it work on a platform that is inherently hostile to it. They're abstracting away as much as possible and what you're left with are the edges that are really hard to polish over. They had to decide to allow experienced coders to shoot themselves in the foot, or make it fool-proof and opted for the former. Captain Corny posted:I doubt that. You strike me as someone who hasn't worked closely with graphical designers and other left-brain types. They already hate SVN because it's too hard, and all they're required to do is checking out and checking in. Captain Corny posted:e2: Perl, really? What's Perl doing in what ought to be a straight C/C++ project. Captain Corny posted:I hope those benefits are also in Mercurial, because it's much more likely that that's what I'll be using in the future. HG is missing two of the most important features: On-the-fly branch switching (it literally takes less than a tenth of a second to switch a branch in git and only takes a right-click followed by a single click in the context menu) as well as the staging area. Captain Corny posted:A fellow vi hater, pleased to meet you. I like nano.  Captain Corny posted:e: I don't believe a hardcore windows user who hates vi knows as much as you do about the GNU toolchain by the way. You sound more like a hardcore Linux user with some experience on Windows. Plus, i deploy websites to linux servers, because linux *is* easier to administrate remotely. I do pay people to do heavy adminning though.
|
|
#
?
Apr 16, 2011 22:10
|
|
|
Mithaldu posted:Sadly not: http://whygitisbetterthanx.com/ Some of those benchmarks are very suspicious. Exactly what command does he propose takes 90 seconds in mercurial but only 1.2 seconds in git? Is he (and you?) seriously comparing git branch to hg clone? Two very different things. I would be interested to know what deficiencies in mercurial's branching model you are referring to. I won't argue with you about the stash though, except to say that nobody has ever actually articulated what its benefit is other than never having to type out long hg commit commands with a bunch of specific filenames.
|
|
#
?
Apr 16, 2011 22:42
|
|
|
Captain Corny posted:You strike me as someone You sure can tell a lot just from the way people post!
|
|
#
?
Apr 16, 2011 22:43
|
|
|
Mithaldu posted:Actually, it's a demography decision. Git was made by linux kernel hackers for linux kernel hackers. The target audience is full-blood coders. quote:And i think your conclusion is unfair. The people doing msysgit (who are NOT the people who made git) are doing their best to make it work on a platform that is inherently hostile to it. They're abstracting away as much as possible and what you're left with are the edges that are really hard to polish over. They had to decide to allow experienced coders to shoot themselves in the foot, or make it fool-proof and opted for the former. quote:Yes, you're right, i usually work with other tool creators. When i talk about git, i mostly talk about how coders would use it. quote:Git provides git-svn which allows one to use their git client to set up a local checkout of an SVN repo into a git repo, which is then able to talk to the SVN repo so people get the niceties of client-side git features. A very important principle any good programmer knows is Do-Not-Repeat-Yourself, so they used a perl SVN interfacing library to talk to svn. quote:Sadly not: http://whygitisbetterthanx.com/ quote:Self-defense mechanism. I write perl professionally and like to do so on windows, which means i need to know why poo poo that breaks on windows is designed as it is, which means i need to know GNU. I've also had to debug some terrible return value swallowing issues when i tried to automate git with perl, which is why i know it's internals. If you doubt my Win32-chops, check out some things i did. (Note how i didn't write testcases for linux/mac. It's because i do not own machines with those.)  But still, Perl? e: Perl on Windows? That's weird... Captain Corny fucked around with this message at 23:05 on Apr 16, 2011 |
|
#
?
Apr 16, 2011 22:48
|
|
|
Doc Hawkins posted:You sure can tell a lot just from the way people post! For example, I can tell from your post that you're an idiot.
|
|
#
?
Apr 16, 2011 22:52
|
|
|
Sailor_Spoon posted:Some of those benchmarks are very suspicious. Exactly what command does he propose takes 90 seconds in mercurial but only 1.2 seconds in git? Is he (and you?) seriously comparing git branch to hg clone? Two very different things. I would be interested to know what deficiencies in mercurial's branching model you are referring to. He's talking about creating a new named branch HEAD off an arbitrary commit. In git that simply means creating a marker that says "the next commit on this branch is a child of this commit" and maybe checking out the versions of the files at that commit if they differ from the working copy. In git this action is (almost) O(1) and completely independent from the repo size. If this kind of action involves copying files or whatever on hg then i can see it taking that long on a big repo. I never actually bothered to spend much time with it due to lack of staging area. Sailor_Spoon posted:I won't argue with you about the stash though, except to say that nobody has ever actually articulated what its benefit is other than never having to type out long hg commit commands with a bunch of specific filenames. The stash is just a global branch that acts as copy/paste emulation. I was talking about the staging area though, which is not the stash. Captain Corny posted:Full-blood Linux coders. Captain Corny posted:While coders are the main beneficiaries of version control systems, the popular versioning tools of the future are going to be used by a lot more people than just coders. Captain Corny posted:I am familiar with the principle, but this sounds like an example of adhering to a principle to the point of crippling yourself, and therefore a bad decision. Captain Corny posted:Someone in this thread pointed out that libgit, through necessity, is now being rewritten to make it at least bearable to use on other platforms. Talk about repeating yourself. Captain Corny posted:I do not think those features will be important enough to beat Mercurial in the grand scheme of things. Captain Corny posted:I believe you. Sounds like you know your poo poo. 
|
|
#
?
Apr 16, 2011 23:37
|
|
|
Mithaldu posted:The stash is just a global branch that acts as copy/paste emulation. I was talking about the staging area though, which is not the stash. err yeah, I guess I was talking about the staging area as well. Mercurial teaches us not to care about more than the first 2 or 3 letters of a command.
|
|
#
?
Apr 17, 2011 00:02
|
|
|
Mithaldu posted:You don't seem to understand coders. A coder works on a problem. If he hits an issue that requires another tool to be created, he creates that tool and goes back to his problem. That's how *every* coder works and what happened in this case. (Sometimes coders forget to back and concentrate on the tool instead, but that's a rare occurrence.)
|
|
#
?
Apr 17, 2011 00:10
|
|
|
Mithaldu posted:He's talking about creating a new named branch HEAD off an arbitrary commit. In git that simply means creating a marker that says "the next commit on this branch is a child of this commit" and maybe checking out the versions of the files at that commit if they differ from the working copy. In git this action is (almost) O(1) and completely independent from the repo size. In git, do you not have to actually update the working copy to the parent revision first? Because that can obviously take some time. The subsequent commit is effectively instantaneous.
|
|
#
?
Apr 17, 2011 00:16
|
|
|
Captain Corny posted:I'll answer you next morning, because I'm going to bed. I disagree by the way, and I am a coder. Sure, sleep is good. @sailor spoon: Nope, not necessary at all. In fact, since you seem to imply this: Creating a branch in git is not even a commit, just an internal marker. You can even have 5 branch heads pointing at the same commit.
|
|
#
?
Apr 17, 2011 00:24
|
|
|
Mithaldu posted:@sailor spoon: Nope, not necessary at all. In fact, since you seem to imply this: Creating a branch in git is not even a commit, just an internal marker. You can even have 5 branch heads pointing at the same commit. Ah, ok. Yeah, with mercurial you can only apply the branch marker at the revision currently checked out, and they don't become "real" until you commit something to them. So you can say hg branch <whatever> as many times as you want, but only the last one will actually affect the next commit (or any commit).
|
|
#
?
Apr 17, 2011 00:29
|
|
|
Captain Corny posted:Someone in this thread pointed out that libgit, through necessity, is now being rewritten to make it at least bearable to use on other platforms. That was me, the idiot. I was trying to deflect your apparent anger at git contributors for having an "attitude," which apparently consists of not caring enough about the platform you personally use. The existence of the libgit2 project seems to show that there are people who think git is great, and who think having a fully portable re-entrant library is worth working on, because it's worth having more and better tools for more platforms. Many of these people don't code on Windows themselves, and yet there they are, attitude-free! They care! As Mithaldu basically said, the original "libgit.a" wasn't really a public api, so it's nice that we're getting one. Mithaldu posted:Not trying to insult you, but honestly, you're passing judgement on something you haven't even used and no experience with. It seems to be easy for intelligent people to get in this habit, though, of course, I would not know.
|
|
#
?
Apr 17, 2011 00:32
|
|
|
Captain Corny posted:No, but it is for version control software. Developers tend to use different OSes within the same projects so you have to accommodate for that. You could kind of make an exception for Visual Sourcesafe in the past because it was built at a time when cross platform development wasn't really feasible, but that's not true anymore, as you can see by its waning popularity. It seems like you're claiming that cross-platform development has recently become easier (since 2005 when VSS was released) yet the reason you're posting in this thread is that the work necessary to take a sizable Linux application and make it work well on Windows has taken years and is still years from completion. Isn't that a bit contradictory?
|
|
#
?
Apr 17, 2011 08:06
|
|
|
Mithaldu posted:You don't seem to understand coders. A coder works on a problem. If he hits an issue that requires another tool to be created, he creates that tool and goes back to his problem. That's how *every* coder works and what happened in this case. (Sometimes coders forget to back and concentrate on the tool instead, but that's a rare occurrence.) quote:They're not crippling themselves in *any* way. They needed a tool, they made the tool with the tools they had at hand. They were and are perfectly happy. End of story. quote:By the time those people realize that appending _new to a filename is not a good versioning system git will be smoothed out. quote:Libgit is being written, not rewritten. There was no programmatic interface so one is in the process of being created. As of right now, you need to run shell commands and parse their output to automate things because there was no need to automate things and git basically came into being as a collection of glue scripts between diff, cat and cp. quote:Not trying to insult you, but honestly, you're passing judgement on something you haven't even used and no experience with. These two features literally make people code better. Smugdog Millionaire posted:It seems like you're claiming that cross-platform development has recently become easier (since 2005 when VSS was released) yet the reason you're posting in this thread is that the work necessary to take a sizable Linux application and make it work well on Windows has taken years and is still years from completion. Isn't that a bit contradictory? e: Sometimes I wonder if they used their immature 'what would CVS not do' mantra in their decision to go single platform. Which would be both hilarious and sad. Captain Corny fucked around with this message at 12:14 on Apr 17, 2011 |
|
#
?
Apr 17, 2011 11:44
|
|
|
TBH, I pretty much never see anyone complaining about the installer to the length you have. Certainly, not to the point where people are giving up on git because of it. It seems pretty ludicrous that people who are technically proficient enough to use a VCS would give up on it just because the installer is less than perfect...especially with all the praise that git generally gets. Because of that I think your predictions of doom and gloom for git's future are kinda overblown. It just seems wildly apparent that you went in to using git with an agenda. "How DARE they make me use git?!?!?" On top of that, I don't see how you can make some of the claims you're making about how they should have designed it. Git was wrote for linux developers to use on linux machines while doing linux-y stuff...why should they go through extra effort to make sure it was cross platform? It's just a happy side-effect that it was so good that a bunch of other people came along and decided they wanted to use it too. Besides, you keep saying git doesn't have "good Windows support", which is just completely false. The installer is less clear than it should be, but once it is installed it works perfect.
|
|
#
?
Apr 17, 2011 15:51
|
|
|
Captain Corny posted:CVS and SVN had decent Windows support from the start. Bullshit. CVS was originally a set of shell scripts made publicly available in 1986. Two years later it was rewritten in C. In 1990, Brian Berliner wrote a USENIX paper about the rewrite. In the future enhancements section of that paper it mentions it has been extensively tested on Sun-3 and Sun-4 systems and that other operating systems have not been tested. It specifically says "the overall portability of the code is still questionable".
|
|
#
?
Apr 17, 2011 16:28
|
|
|
Captain Corny posted:it's generally a good idea to look at who your userbase is going to be. I hate leftards, but with all open source software this applies: You can play with it as much as you want, but if you break it you get to keep both halves. If someone thinks that is unreasonable, then i'd say they're crazy. Captain Corny posted:and when you are creating something that's intended for external use Captain Corny posted:And particularly with version control, you should design your software to be at least portable enough that somebody else can make a version for another platform. Captain Corny posted:However, don't be surprised when people don't want to use your creation as a result of that. We don't care whether you continue to inflict _new, .old, .bak and ~ on yourself because you didn't like the  in the installer. We're annoyed that you complain about something that is a non-issue and continue to state falseties as truths.And lastly, we're appalled that you choose to publicly bitch out an open source project instead of taking the standard channels. If your blog post had been in a more tempered tone and included a constructive "here's how i would've done it" section, it could've made a perfect "patch" and made *everyone* happy. Captain Corny posted:I didn't mean that as passing judgment, sorry about that. I meant that, for most Windows users that would be interested in versioning, good Windows support is a much more compelling feature than whatever sets Git apart. Captain Corny posted:With cross platform development, you make your application cross-platform (or at least easily portable) from the first line of code you write. Captain Corny posted:CVS and SVN had decent Windows support from the start. Additionally TortoiseSVN only started in 2003 and before that you were forced to use it on the command line exclusively. (And i'd bet it wasn't even particularly usable until 2005.)
|
|
#
?
Apr 17, 2011 17:45
|
|
|
Captain Corny posted:I meant that, for most Windows users that would be interested in versioning, good Windows support is a much more compelling feature than whatever sets Git apart. This is a pretty incredible sentence. You not only know what most windows devs want, you also know that it isn't any of the features which you admit to not knowing much about! I'm sure you feel like you have every reason for your strong opinions, but I still hope that you someday get the chance to see why people are actually making such a fuss about Git. I'd be interested in reading the resulting article.
|
|
#
?
Apr 17, 2011 22:31
|
|
|
Wow, I'm surprised how quickly you went from being somewhat reasonable to spilling outright bullshit and veiled personal attacks.Mithaldu posted:I never disagreed on it being a good idea, i merely said that that is usually not what HAPPENS. And this has a reason too: Open source software development is done by volunteers. You do not get to tell those volunteers how they have to apply their time they are freely giving. But even if that wasn't true, what you're basically doing is making excuses. "Sure, the software has flaws but it's because of the build process." "Sure, the installer is harder to use than it should be, but that's because it depends on a set of tools that aren't available on Windows." The only thing that matters to the end user is what the software does, not how or why it came to doing that. quote:It was never intended for external use. Never. Seriously, this single thing unravels your whole line of reasoning. quote:Let me be perfectly blunt: This thread of developers is collectively raising its eyebrow at your bitching about how the installer asks you to think (and maybe google) for 2 minutes or just plain ask some people for help. quote:We don't care whether you continue to inflict _new, .old, .bak and ~ on yourself because you didn't like the quote:And lastly, we're appalled that you choose to publicly bitch out an open source project instead of taking the standard channels. quote:If your blog post had been in a more tempered tone and included a constructive "here's how i would've done it" section, it could've made a perfect "patch" and made *everyone* happy. quote:I'm saying git has awesome windows support. The problem is that you're so hung up about a tiny bump in the installation process that you never got to actually see that, yet continue to act as if you already know it as a fact. http://www.python.org/dev/peps/pep-0374/ I've cut off the rest because it became boring and we're going way off track. quote:This is a pretty incredible sentence. You not only know what most windows devs want, you also know that it isn't any of the features which you admit to not knowing much about!
|
|
#
?
Apr 18, 2011 17:49
|
|
|
can we get a gas itt
|
|
#
?
Apr 18, 2011 17:52
|
|
|
Msysgit was my first exposure to git. The installer didn't phase me at all and I didn't think any of the questions it asked me were that hard nor did it require any great amount of effort to make it through the install. If you have 0 experience with linux then "bash" might not be known to you, but if you don't know what bash is, that particular screen still tells you what the effect is on your system. Option 1) No changes to your PATH will happen Option 2) Git will be placed into your PATH Option 3) Git and some other things will be placed in your PATH, possibliy overriding some standard tools. If you are a Windows developer and you don't know what your PATH is and what modifying it may do, then maybe you shouldn't be developing on Windows (or anywhere).
|
|
#
?
Apr 18, 2011 17:59
|
|
|
Captain Corny posted:
To be fair, "weakest out of the three" != "lack of decent Windows support". Git's Windows support is more than decent.
|
|
#
?
Apr 18, 2011 18:04
|
|
|
Captain Corny posted:Wow, I'm surprised how quickly you went from being somewhat reasonable to spilling outright bullshit and veiled personal attacks. Captain Corny posted:I'm sorry, but this is bullshit. There's always a lead developer, or some kind of body that makes decisions about architecture or design, even in open source. This doesn't even have to be formal. It just always works that way. Captain Corny posted:It doesn't unravel squat. It is entirely irrelevant what it was intended for. The only thing that matters is that it *did* get released for Windows. That fact alone makes it completely fair to compare it to other Windows applications and to pass judgment on it from a Windows centric perspective. Captain Corny posted:You're completely misrepresenting my point now. The installer doesn't ask you to think, it asks you to *know*. Captain Corny posted:About stating falsities as truth, please specify, because that's a pretty serious charge you're casually flinging at me. Captain Corny posted:You keep saying that Git's Windows support is awesome, yet the Python devs recently chose Mercurial over Git. One of the key reasons was lack of decent Windows support. Captain Corny posted:Here's where I start thinking that you didn't even bother to read my article. Because it did include suggestions for improvement. So either you didn't read it, or you're flat out lying now.
|
|
#
?
Apr 18, 2011 18:11
|
|
|
Thermopyle posted:In other words, if my assumption is right complaining that you have to install msysgit to use TortoiseGit is like complaining that you have to have Word installed to use some Word add-on. Myabe, but this is completely contrary to the other Tortoise projects that don't require you to have the client binary installed on your path. However I didn't know that another team was starting to work on libgit, I assumed it already existed. I can only hope that once it's finished the developers of TortoiseGit start using it.
|
|
#
?
Apr 18, 2011 18:24
|
|
|
Mithaldu posted:Because you're expecting people to wait on you hand and foot. quote:And how does that invalidate "You can play with it as much as you want, but if you break it you get to keep both halves." at all? That paragraph doesn't even remotely touch the words you quoted from me. quote:The people releasing msysgit are an ENTIRELY different set of people from those who made git in the first place. You're putting expectations on one team because of actions of another team. quote:It asks you to research and think. Google is not hard. quote:This was written in November 2008, that is 2.5 years ago. Things changed since then and that article contains a lot of outdated information. (Like, for example the lack of Tortoise has long been adressed.) quote:Admittedly, i didn't read that far. Apologies for that. While your recommendations are wordy and vague, they are better than nothing. Now impress me by doing the right thing with them. Captain Corny fucked around with this message at 19:50 on Apr 18, 2011 |
|
#
?
Apr 18, 2011 19:42
|
|
|
Profane Obituary! posted:Option 2) Git will be placed into your PATH
|
|
#
?
Apr 18, 2011 20:07
|
|
|
Rest of the thread: are you sick and tired of my little bitchfest yet or is it entertaining enough to carry on?
|
|
#
?
Apr 18, 2011 20:09
|
|
|
Captain Corny posted:You've mentioned this before, but it's irrelevant. I don't care about which team did what. I care about what the end result was. I thought I made that clear. You're expecting one set of people (kernel hackers) to conform to your expectations (full portability from the word go) because a different set of people (msysgit maintainers) did something that's completely outside of the control of the first set of people. That's completely insane. Would you expect british car designers to make cars with steering wheels on both sides because some brits decide to drive them in germany?  Captain Corny posted:Are you going to call them liars too? Captain Corny posted:Sure. Have they switched to Git yet? Captain Corny posted:I have used Git by the way, just to clear that up (I was required to).
|
|
#
?
Apr 18, 2011 20:09
|
|
|
Captain Corny posted:Rest of the thread: are you sick and tired of my little bitchfest yet?
|
|
#
?
Apr 18, 2011 20:17
|
|
|
Mithaldu posted:Really? Let's get down to brass tacks then: How did you experience bad windows support in the actual usage of git? I'm not really keeping up with the back and forth between the thread and Captain Corny but I'll take this. We recently migrated a large svn repo to git. Here's my experience on Windows going from one to the other: -git is slower. Many operations seem to crawl compared to svn. I will acknowledge that some of that may be TortoiseGit's fault (see later point) as using git log (for example) on the command line seems to be snappier. I know that on paper "git is fast because operations are local" but I'm telling you my first hand experience flies counter to this. -TortoiseGit has a hard to reproduce rebase related bug. This isn't really about git per se but rather the git tooling on Windows is halfassed at best. There are certain situations some on our team have found that when remote master is a few commits ahead and you have some local commits, and you try to fetch and rebase, TGit reports success but doesn't always rebase all your commits, so when you push it looks like things got lost. This is traumatizing. Personally I no longer use TGit in favor of the direct command line tools, but it was a definite problem we had that could only have happened with typical git tooling on Windows. So you may fairly be able to corner my points as an indictment of TGit rather than git itself which I suppose is fair, however it's an easy mistake for a new git rollout to reccommend TGit thinking it's on par with TSvn and THg. So it's definitely something to consider in the discussion. "Git on Windows" debate aside, git is just a more complex tool then a lot of devs are used to, and Windows is not the primary target platform, so it's not surprising that there are going to be tooling or documentation gaps that are sort of left as an exercise to the user. For what it's worth in addition to svn and git I also use mercurial and it has been nothing but a pleasure to use from internals to tooling, it's a superior vcs in my opinion at the cost of a sliver of functionality that's possibly only relevant to giant open source projects.
|
|
#
?
Apr 18, 2011 20:41
|
|
|
|
| # ? May 12, 2024 11:57 |
|
|
Captain Corny posted:Rest of the thread: are you sick and tired of my little bitchfest yet or is it entertaining enough to carry on? In contrast, Factor Mystic's post is an intelligent and thoughtful discussion of the topic at hand, rather than a troll.
|
|
#
?
Apr 18, 2011 20:47
|
|
