|
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? I hope you never stop. Forking is cheap, so lets have the people who are uninterested maintain their own thread! If they come up with any good insights, we can always pull them in and rebase!
|
# ? Apr 18, 2011 21:00 |
|
|
# ? May 11, 2024 13:02 |
|
Factor Mystic posted:-git is slower Are you sure you're using straight git and not git-svn? Even rather large repos i have, like ExtUtils::MakeMaker with 2288 commits come up literally instantly when i open the tortoise git log, while git-svn usually takes its sweet time to do anything at all.
|
# ? Apr 18, 2011 21:20 |
|
Mithaldu posted:Are you sure you're using straight git and not git-svn? As a git-svn user, it's not slower for me. "git log" is near instant for me. Even tortoisegit log is near instant. The only slowdowns I hit are when the designer checks in 400M+ video files I'm trying to move from msysgit's bash to msysgit inside cygwin's shell. I'm sick of having to switch back and forth between the environments, and I had a bad time with cygwin's git-svn. I'm doing pretty well with it EXCEPT when I have my laptop clone the repo from my desktop machine. So, my desktop machine has my main git repo. I use git-svn to keep it in sync with our svn server out there. Then on my laptop I've cloned the repo off my desktop. Worked fine. But now if I "git pull origin" I get the following error: "bash: git-upload-pack: command not found" I don't see a git-upload-pack command in my msysgit folder on either machine. Any clues what's going on?
|
# ? Apr 19, 2011 15:06 |
|
Factor Mystic posted:TGit reports success but doesn't ... This part of my experience a year ago is what really turned me off about TortoiseGit; when I did things wrong I'd often end up with a "Success" message containing details about the error, or just a line of hex.
|
# ? Apr 19, 2011 16:07 |
|
Dromio posted:As a git-svn user, it's not slower for me. "git log" is near instant for me. Even tortoisegit log is near instant. The only slowdowns I hit are when the designer checks in 400M+ video files I found git-upload-pack, it was in the libexec folder of msysgit. I added that to my PATH and got past that issue. But now my git pull origin gives me a new error-- "fatal: '/cygdrive/d/Projects/theProject' does not appear to be a git repository". Of course if I ssh to that server and browse to that folder it IS a repository. And it was initially cloned from there!
|
# ? Apr 19, 2011 19:37 |
|
My original clone was from a cygwin git installation, not msysgit. So it turns out msysgit doesn't actually know about the cygwin paths. I had to change my origin path from /cygdrive/d/Projects/theProject to D:/Projects/theProject. Now everything is smooth.
|
# ? Apr 20, 2011 17:14 |
|
Mithaldu posted:Sadly not: http://whygitisbetterthanx.com/ For example, you can't compare "clone" operations by timing how long it takes to download from four completely separate websites, and saying that git's "branch" is faster than bzr's is useless when they are actually entirely different commands that happen to have the same name. In the last point, he says Git is better than Mercurial because of Github, which makes me think the page is *really* old (Bitbucket was launched in 2008). He also doesn't mention what versions he tested with, which makes a big difference (especially on the performance-related parts). Finally, I think it's *really* weird that he lists "cheap branching" as the first one, *and* claims Mercurial and Bazaar don't support it. Bazaar has supported cheap branches since 0.8 (released: 2006), and if I remember correctly Mercurial had them even earlier. Captain Corny posted:If you're dumb/crazy enough to use Windows as a development workstation, you do not have permission to complain when standard tools do not work properly any more than someone still using Netscape 4 gets to complain about Google Docs requiring Javascript. Spend half an hour and install a real OS. It's obvious from your posts that you expect your VCS to hold your hand, spoon-feed you, and change your diaper before each commit. Maybe you'd be happier with Visual Source Safe -- it's got "visual" right in the name!
|
# ? Apr 21, 2011 05:23 |
|
Janin posted:VCSes are meant to be used from the command-line. Graphical wrappers are just hobbles used by idiot "I took an Excel class in college!" types who are too frightened of real software to get any work done.
|
# ? Apr 21, 2011 06:28 |
|
Janin posted:I'm a troll. Jesus Christ Janin stick to YOSPOS. Your first paragraph was just fine, but come on.
|
# ? Apr 21, 2011 10:34 |
|
Captain Corny posted:Nice attitude. Try reading what I'm actually saying next time. Captain Corny posted:Right, but I didn't really have any choice. It just saddens me that Git apparently was designed for Linux only, and that any use for it on other (much bigger) platforms was ignored because of some misplaced and immature pro-Linux bravado. It's just a dumb strategy to follow and even for that reason alone I don't like Git. Captain Corny posted:Whoever was developing it were wasting their time because they apparently collectively decided to make it Linux only with extremely limited support for other platforms. How's that? 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 to use. Bad design decision. Dumb design decision. First-time users aren't exposed to any "complex inner workings" unless they're installing on a broken OS that doesn't come with any standard developer tools, like Bash or Perl. Captain Corny posted:Full-blood Linux coders. Captain Corny posted:I get that. The design decision I talked about was made by the core developers, not the msysgit developers. Still a bad decision. 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. 90% of VCS features are targeted to and intended for programmers. There's no reason for non-coders to ever care about branches, or merging; in fact, the typical non-code file (graphic images) can't be reasonably merged at all. If you want non-developers to use VCS, write them a few simple tools with two or three buttons ("find changes", "send changes", "mark change") and don't expose them to branches or repositories or any of that. 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. 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:That may be true for small scripts and tools, but once you decide to go into anything heavier (and 4+ months development time for just a tool is heavy), and when you are creating something that's intended for external use, and when you are creating something that's intended to be a replacement for another tool that is available on all platforms, it's generally a good idea to look at who your userbase is going to be. 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. There seems to be a fundamental difference of opinion on this between us. The predicted (and, so far, major) userbase is Linux kernel developers. Some guy who used Git for his 200-line Rails plugin because he saw a cool screencast about it doesn't matter. Captain Corny posted:Of course, they are free to make their tool as they see fit and be happy about it. Not giving a gently caress is a right that I'll be the first to defend, and designing a good UI is a lot more work than inflicting unnecessary pain on your users. However, don't be surprised when people don't want to use your creation as a result of that. Captain Corny posted:Not at all, it's an entirely different thing. With cross platform development, you make your application cross-platform (or at least easily portable) from the first line of code you write. It's what I mean with early design decisions. Git was clearly not developed to be cross platform (bad early design decision IMO), so it's no surprise that people are running into problems getting it ported. CVS and SVN had decent Windows support from the start. They were cross platform and CVS existed before Git even started development, which proves that even back then, it was not impossible to develop cross platform. Visual Studio: Windows only XCode: MacOS only Emacs/Vim: POSIX only Git/Mercurial/Bazaar: POSIX only (the Windows ports are jokes) SVN/CVS: POSIX only (the Windows ports are missing major functionality) Autotools: POSIX only (... a bunch more marked "POSIX only") If you want to insist that CVS was cross-platform, then you don't get to say that Git isn't -- Git works at least as well, if not better, on Windows than CVS ever did. 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: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." 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*. Not only that, it asks you to know things that you can only know when you're already a user of the software. And that's unreasonable. Captain Corny posted:Seriously? You don't have something better to be appalled about than what some guy writes on the internet about a piece of software you're using? And you think the rest of the thread is with you on this? In that case, let me hereby apologize for offending your delicate sensitivities. I didn't realize how emotionally attached you were to Git. 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. That's not necessarily a bad thing -- Mercurial is a pretty good choice, and there's no compelling reason to pick any one of the major three DVCS in existance -- but you don't get to use it to support your position. Git on Windows works as well as Mercurial does, certainly. Captain Corny posted:I don't see how that's incredible. Decent Windows support is a pretty basic and common requirement for software that's supposed to run on Windows.
|
# ? Apr 21, 2011 16:41 |
|
Janin posted:Visual Studio: Windows only Actually Mercurial works super nice on Windows. I don't have enough experience with the other two VCS systems you mentioned to comment on their level of jokeness on Windows. (I agree with the majority of your other points)
|
# ? Apr 21, 2011 17:17 |
|
epswing posted:Actually Mercurial works super nice on Windows. I don't have enough experience with the other two VCS systems you mentioned to comment on their level of jokeness on Windows. * symlinks * hardlinks * files named "makefile" and "Makefile" in the same directory Has support for these improved/been added? I don't use Mercurial day-to-day.
|
# ? Apr 21, 2011 17:38 |
|
Janin posted:Emacs/Vim: POSIX only VIM is one of the first things I install on every Windows system that's mine. Well before I install Cygwin. What functionality is TortiseSVN missing? also: Janin posted:The last time I used Mercurial on Windows, it couldn't handle: Considering the fact that links don't exist on Windows in the same way they do on unix systems, your software isn't portable. Unless the links are a necessary part of the operation of Mercurial itself in that it would break even if your source tree didn't contain those items, this isn't a problem with Mercurial. As for makefile and Makefile, might be a genuine bug because NTFS is case-sensitive and exposes that to the POSIX subsystem, but be aware that any app that uses the Win32, WOW, or MS-DOS subsystems (pretty much everything not running under Cygwin or similar) will break. Slamming the tool because it doesn't support things that the OS and filesystem don't support seems pretty trollish tbh. wellwhoopdedooo fucked around with this message at 17:49 on Apr 21, 2011 |
# ? Apr 21, 2011 17:39 |
|
wellwhoopdedooo posted:VIM is one of the first things I install on every Windows system that's mine. Well before I install Cygwin. TortoiseSVN is a wrapper around SVN; SVN itself is, like Mercurial, reacts poorly when the repository contains links or case-differentiated filenames. It's not really the SVN developer's fault, it's just that the platform is missing features that the tool allows.
|
# ? Apr 21, 2011 17:47 |
|
It's a pretty big leap to call something "POSIX Only" because CTRL-C doesn't copy. e: It does use the same clipboard, the copy command is just mapped differently. Use copy from the menu.
|
# ? Apr 21, 2011 17:51 |
|
wellwhoopdedooo posted:It's a pretty big leap to call something "POSIX Only" because CTRL-C doesn't copy. "POSIX only" was a poor choice of words, I should have chosen something like "POSIX native" instead. Basically, I wanted to convey the feeling of "this was obviously written for a different OS" that comes from features like :! working sorta-but-not-quite.
|
# ? Apr 21, 2011 18:01 |
|
Janin posted:In the version of Vim I used (7.2 from vim.org), the vim clipboard (yy/dd/p and friends) and Windows clipboard were separate -- eg, you could copy "foo" in vim, copy "bar" in notepad, and then paste "foo" in vim. It's quite possible that this behavior was due to a problem with my machine. You can source a $VIMRUNTIME/mswin.vim file in 7.0 and up and get all the <C-c>, <C-s>, <C-x> key mappings and whatnot that most windows editors use. (IIRC this also works on non-windows machines as well)
|
# ? Apr 21, 2011 18:14 |
|
Janin posted:This page is pretty much entirely incorrect regarding competing DVCS. It's cute; but when you see numbers like "git: 1.6s, bzr: 82s", it's obvious that the author is doing something wrong. He didn't compare these: code:
I just reproduced his bazaar result on my own system: code:
As for bitbucket, you might be right. I don't know about it. As for cheap branching: Bazaar: I wouldn't call 40 seconds cheap. Neither is it particularly cheap to switch branches if "to branch" means "create a new directory". (And i haven't even looked into rebase (or similar) capability.) As such, i think it is entirely fair to say Bazaar has no such thing as cheap branches. If you still think so, please show us how i can create a branch or branch-like thing in Bazaar in under a second and also switch to another one while staying in the same directory. Mercurial: I have to admit, as far as speed and ease for creating and switching go, its on par with git. So his benchmark there seems to be completely out of date now. On the other hand, i still have to deduct points for lack of rebasing. That's pretty important to have.
|
# ? Apr 21, 2011 19:56 |
|
Janin posted:Huge post full of reasons for Windows users to not use Git, because it was developed for Linux only and not suited for any other platform.
|
# ? Apr 21, 2011 20:27 |
|
Janin posted:In the version of Vim I used (7.2 from vim.org), the vim clipboard (yy/dd/p and friends) and Windows clipboard were separate -- eg, you could copy "foo" in vim, copy "bar" in notepad, and then paste "foo" in vim. It's quite possible that this behavior was due to a problem with my machine. yy copies a line to the unnamed register. "+yy copies a line to the clipboard. p pastes from the last used register. "+p pastes from the clipboard. The clipboard does not exist outside the GUI, so this only really works in GVIM. If your terminal supports X11 selection, you can use the select register, "* See :help registers for more info. wellwhoopdedooo fucked around with this message at 20:32 on Apr 21, 2011 |
# ? Apr 21, 2011 20:28 |
|
Captain Corny posted:I don't see how this negates my article in any way. It actually reinforces my opinion that Git is a bad choice for developers that prefer to use Windows. Which is the majority. Jesus Christ, you two should marry. You're the perfect pair with one of you claiming only linux users can be developers and the other claiming that most developers prefer windows.
|
# ? Apr 21, 2011 20:30 |
|
Mithaldu posted:Jesus Christ, you two should marry. You're the perfect pair with one of you claiming only linux users can be developers and the other claiming that most developers prefer windows.
|
# ? Apr 21, 2011 20:53 |
|
Mithaldu posted:Jesus Christ, you two should marry. You're the perfect pair with one of you claiming only linux users can be developers and the other claiming that most developers prefer windows. What if Captain Corny and Janin are the same person with multiple personality disorder?
|
# ? Apr 21, 2011 20:59 |
|
epswing posted:What if Captain Corny and Janin are the same person with multiple personality disorder?
|
# ? Apr 21, 2011 21:07 |
|
Mithaldu posted:I think you might be misreading things. Yes -- if you want to compare branching in a local Git repo, you should compare it to branching in a local Bazaar repo: code:
Mithaldu posted:Bazaar: I wouldn't call 40 seconds cheap. Neither is it particularly cheap to switch branches if "to branch" means "create a new directory". (And i haven't even looked into rebase (or similar) capability.) As such, i think it is entirely fair to say Bazaar has no such thing as cheap branches. If you still think so, please show us how i can create a branch or branch-like thing in Bazaar in under a second and also switch to another one while staying in the same directory. The typical workflow of Bazaar is to have one branch per directory; however, you can use "bzr switch" to change what branch the current working copy uses. I like per-branch directories, so I don't use it much. Mithaldu posted:Mercurial: I have to admit, as far as speed and ease for creating and switching go, its on par with git. So his benchmark there seems to be completely out of date now. On the other hand, i still have to deduct points for lack of rebasing. That's pretty important to have.
|
# ? Apr 21, 2011 21:46 |
|
Captain Corny posted:Maybe I created 'Janin' to let the rest of the thread see how dumb a typical Git user is. You're just too dumb to realise how dumb you are.
|
# ? Apr 21, 2011 21:49 |
|
Janin posted:I don't even use Git; my most used VCSes are Perforce (at work), Bazaar (at home), Mercurial (when using BitBucket-based projects), and Darcs (my old at-home VCS, still migrating stuff from it). (USER WAS PUT ON PROBATION FOR THIS POST)
|
# ? Apr 21, 2011 21:52 |
|
wellwhoopdedooo posted:Considering the fact that links don't exist on Windows in the same way they do on unix systems
|
# ? Apr 21, 2011 23:31 |
|
Plorkyeran posted:Unless you're using a version of windows released in the last decade. http://en.wikipedia.org/wiki/Mklink derp, right you are.
|
# ? Apr 22, 2011 00:01 |
|
So, I've got a little-ish app that I'm developing. When I do a release version, I tag that commit (using git, BTW) with the version number, then I go on happily developing. When I need to do a bugfix on that version (like if I'm not far enough along in development to do a release of a newer version), I create a bugfix branch from that tag and then release from that branch. This is awkward because if I merge that branch back in to my development branch to get those bugfixes back in it can be a big mess because I may have done large structural changes or whatever. What's a better way to handle this?
|
# ? Apr 25, 2011 18:50 |
|
Thermopyle posted:So, I've got a little-ish app that I'm developing. When I do a release version, I tag that commit (using git, BTW) with the version number, then I go on happily developing.
|
# ? Apr 25, 2011 22:14 |
|
Yeah that's about as good as it gets. In the lucky cases that bug was in a part of the code that you didn't touch it should merge perfectly without any conflicts. Otherwise hopefully your removed that code, and the bug is no longer valid :p
|
# ? Apr 25, 2011 22:19 |
|
Janin posted:You're already doing it properly; there's not any perfect ways to merge bugfixes from one branch into a very different branch. Damnit, I want a loving magic merge fairy to do this work for me!
|
# ? Apr 25, 2011 23:09 |
|
Thermopyle posted:Damnit, I want a loving magic merge fairy to do this work for me! http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html might be as close as you get, which is still pretty nice.
|
# ? Apr 26, 2011 00:00 |
|
I've got a repo on GitHub that I'm trying to get to automatically deploy to my webserver (VPS) whenever a change is pushed to master. Right now I have it such that GitHub fires off an HTTP request to a PHP script on my web server that is supposed to do a git pull, but the git pull fails silently (and I'm not sure why). I've tried quite a few things that I've seen online to figure it out, to no avail. PHP, according to shell execing 'whoami', runs as the www-data user. I created a new group 'gitwriters', added myself and www-data to that group, changed the owning group of all of the files in the git repo directory to that group, gave that group permissions, and set the setgid bit on the files in it. After doing that, when I do a sudo -u www-data git pull it gave me a SSH key/permission error, so I created a RSA key pair for the www-data user. Now when I run git pull as www-data it works fine, but when I run it via the PHP script it fails silently still. I've verified that I'm in the right directory, but I'm not sure what else to try now. Edit: Apparently PHP's shell_exec doesn't automatically grab stderr, so I found this when I piped stderr to stdout and ran the PHP script: cannot open .git/FETCH_HEAD: Permission denied Edit 2: Changing the owner of all of the files to the www-data user fixed it, but I think there should probably be a better way, considering www-data is in the right group (and it worked when I sudo'd git pull as the www-data user...) POKEMAN SAM fucked around with this message at 15:22 on Apr 26, 2011 |
# ? Apr 26, 2011 15:12 |
|
You're kind of guessing what's wrong and trying different things. When you say the PHP script "fails silently"...is it 500'ing? If so, what does the web server's error.log say? If not, wrap the whole thing in try/catch and write the $exception to a file or something.
|
# ? Apr 26, 2011 15:17 |
|
epswing posted:You're kind of guessing what's wrong and trying different things. When you say the PHP script "fails silently"...is it 500'ing? If so, what does the web server's error.log say? If not, wrap the whole thing in try/catch and write the $exception to a file or something. Sorry, I meant I was writing the results of shell_exec to the page, and that returned nothing. Obviously if it were failing somehow else I'd know better how to track it down...
|
# ? Apr 26, 2011 15:22 |
|
Yeah man I got lucky. I was able to talk my comp into use VisualSVN. It's not git but its better than sourcesafe and VPRJCT. As long as you use .gitignore I don't see anything wrong with this. We actually have people that use SVN and Git together in a similar way(not git-svn command). Belgarath posted:I have to use Sourcesafe at work (I know, but it's out of my hands), but I've started using Git for my personal stuff. I was wondering if I could use Git at work, so that I could init a Git repo in my sourcesafe checkout, do some work, make some branches in Git, and then check back into sourcesafe after merging my Git branches into master?
|
# ? Apr 26, 2011 17:10 |
|
Did you just top post on an internet forum? Whole drat world's going to hell.
|
# ? Apr 27, 2011 02:22 |
|
|
# ? May 11, 2024 13:02 |
|
Git question here. I have been working on developing a project. During initial development, I basically just modified the master branch. Now I am to the point where I want to release the first version. I have created tag v1.0.0 and pointed it to the correct commit. What is the best method for performing bug fixes? I could theoretically continue to perform commits to master, then eventually tag v1.0.1 etc. I feel that this isn't really the best way. Any advice?
|
# ? Apr 28, 2011 16:52 |