Version Control Questions Megathread (SVN / git / whatever else)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›100 »

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

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

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 06:12

Mithaldu: Sep 25, 2007; Let's cuddle.

Factor Mystic posted:

-git is slower

Wow, very nicely detailed post, thanks. I'll probably think about it a bit more tomorrow, but right now i'd like to ask this, and apologies in advance for asking, but i can't assume anything:

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

Dromio: Oct 16, 2002; Sleeper

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

Zhentar: Sep 28, 2003; Brilliant Master Genius

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: Oct 16, 2002; Sleeper

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'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?

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

Dromio: Oct 16, 2002; Sleeper

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

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Mithaldu posted:

Sadly not: http://whygitisbetterthanx.com/

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.

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.

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:

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.

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

Captain Corny: Dec 16, 2000

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.

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!

Nice attitude. Try reading what I'm actually saying next time.

# ? Apr 21, 2011 06:28

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

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

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Captain Corny posted:

Nice attitude. Try reading what I'm actually saying next time.

You mean these posts? Here, I'll reply to them line-by-line to emulate your terrible posting:

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.

Linux *is* the "much bigger" platform, for developers. Git's not a My Little Pony video game, it's a developer tool, and if you don't want to use it on a developer OS then that's not Git's fault. You might as well complain that Photoshop is hard to use because it doesn't run well in FreeBSD.

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?

The developer of Git is the developer of Linux. Git was written for the single purpose of managing the Linux kernel. There is no reason for it to be ported to any other OS.

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.

e2: Perl, really? What's Perl doing in what ought to be a straight C/C++ project.

Yes, an early design decision to run on the OS it's used to develop dooms Git to working well on...the OS it's used to develop, and that everyone who wants Git already uses.

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.

"Full-blood coders" == "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.

Just because it happens to frustrate your bizarre, obscure edge case (running a complex UNIX tool on a non-POSIX OS) doesn't make it 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.

No they're not.

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.

It's hardly crippling, if the only people it impacts are the set of programmers who can't figure out how to install Perl (a set which, until I recently, I would have assumed null).

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.

Linus didn't write Git to be a general-purpose VCS. It was explicitly a replacement for Bitkeeper, it only needed to run on Linux, and any amount of platform-dependence was acceptable in the name of performance.

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.

The Git target audience doesn't seem to mind its UI at all.

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.

Again, you assume that being cross-platform is important to a developer tool. That's simply not true; off the top of my head, I can't think of a *single* major developer tool that works well on anything but the platform it was written for.

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.

No doubt this highly informed and reasonable paragraph is based on your years of time in the Linux developer community?

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."

The only thing that matters to the end user is what the software does, not how or why it came to doing that.

Or how about : it's a tool for developers, by developers, written for the premier development platform, and it's been ported to Windows by a handful of volunteers who don't care if the installer needs to ask the user a few questions because it'll only ever have a market share of 100 users on that platform.

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.

No it doesn't, and you're an idiot for claiming it does. If I somehow manage (through emulation and trickery) to get a MacOS application running on Windows, it would be idiotic to claim it's a badly-designed application because installation was difficult and the UI doesn't look right.

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.

Or, you could just click through and select the (well-chosen, reasonable) default options.

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.

I'm more appalled by your terrible posting.

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.
http://www.python.org/dev/peps/pep-0374/

The Python developers chose Mercurial because it's Guido's favorite. The poll was only ever a formality; they decided on Mercurial from the outset, and then looked for reasons to reject the other VCS contenders.

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.

What about for software that's not supposed to run on Windows, and doesn't have any significant Windows user base, and is designed for users that are actively writing an alternative operating system?

# ? Apr 21, 2011 16:41

epswing: Nov 4, 2003; Soiled Meat

Janin posted:

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")

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

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

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.

_{(I agree with the majority of your other points)}

The last time I used Mercurial on Windows, it couldn't handle:

* 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

wellwhoopdedooo: Nov 23, 2007; Pound Trooper!

Janin posted:

Emacs/Vim: POSIX only
SVN/CVS: POSIX only (the Windows ports are missing major functionality)

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:

* 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.

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

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

wellwhoopdedooo posted:

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?

Sure, but you've got to admit it's a very non-native experience, right? I have 7.2 installed on a Windows machine somewhere, and it uses different fonts, graphical widgets, and even a separate clipboard.

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

wellwhoopdedooo: Nov 23, 2007; Pound Trooper!

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

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

wellwhoopdedooo posted:

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.

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.

"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

Slurps Mad Rips: Jan 25, 2009; Bwaltow!

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.

"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.

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

Mithaldu: Sep 25, 2007; Let's cuddle.

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.

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.

I think you might be misreading things.

He didn't compare these:

code:

git clone git://github.com/brosner/django.git dj-git
hg clone [url]http://hg.dpaste.com/django/trunk[/url] dj-hg
bzr branch lp:django dj-bzr
svn checkout [url]http://code.djangoproject.com/svn/django/trunk[/url] dj-svn

They are the starting points after which you have a local repo to start making your own comparisons with.

I just reproduced his bazaar result on my own system:

code:

D:\bzr>bzr branch lp:django dj-bzr
Branched 8636 revision(s).

D:\bzr>c:\cygwin\bin\time bzr branch dj-bzr dj-bzr2
Branched 8636 revision(s).
0.01user 0.00system 0:40.42elapsed 0%CPU (0avgtext+0avgdata 144384maxresident)k
 0inputs+0outputs (560major+0minor)pagefaults 0swaps

D:\bzr>

Note the 0:40.42elapsed. During this time no network traffic happened. Did i do something wrong too?

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

Captain Corny: Dec 16, 2000

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.

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.

# ? Apr 21, 2011 20:27

wellwhoopdedooo: Nov 23, 2007; Pound Trooper!

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.

"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.

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

Mithaldu: Sep 25, 2007; Let's cuddle.

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

Captain Corny: Dec 16, 2000

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 a weird statement

# ? Apr 21, 2011 20:53

epswing: Nov 4, 2003; Soiled Meat

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

Captain Corny: Dec 16, 2000

epswing posted:

What if Captain Corny and Janin are the same person with multiple personality disorder?

Maybe I created 'Janin' to let the rest of the thread see how dumb a typical Git user is.

# ? Apr 21, 2011 21:07

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Mithaldu posted:

I think you might be misreading things.

[...]

Note the 0:40.42elapsed. During this time no network traffic happened. Did i do something wrong too?

Yes -- if you want to compare branching in a local Git repo, you should compare it to branching in a local Bazaar repo:

code:

$ bzr init-repo dj
$ cd dj
$ time bzr branch lp:django dj-bzr
$ time bzr branch dj-bzr dj-bzr2

The second branch should be much faster than the first, because it's creating a local branch instead of a separate repository.

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.

See above for how to use local/cheap branches.

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.

I think Mercurial has a plugin for rebasing -- Bazaar has for a while, and it's a pretty popular feature.

# ? Apr 21, 2011 21:46

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Captain Corny posted:

Maybe I created 'Janin' to let the rest of the thread see how dumb a typical Git user is.

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).

You're just too dumb to realise how dumb you are.

# ? Apr 21, 2011 21:49

Captain Corny: Dec 16, 2000

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).

You're just too dumb to realise how dumb you are.

lol

(USER WAS PUT ON PROBATION FOR THIS POST)

# ? Apr 21, 2011 21:52

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

wellwhoopdedooo posted:

Considering the fact that links don't exist on Windows in the same way they do on unix systems

Unless you're using a version of windows released in the last decade.

# ? Apr 21, 2011 23:31

wellwhoopdedooo: Nov 23, 2007; Pound Trooper!

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

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

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

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

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.

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?

You're already doing it properly; there's not any perfect ways to merge bugfixes from one branch into a very different branch.

# ? Apr 25, 2011 22:14

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

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

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

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

musclecoder: Oct 23, 2006; I'm all about meeting girls. I'm all about meeting guys.

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

POKEMAN SAM: Jul 8, 2004

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

epswing: Nov 4, 2003; Soiled Meat

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

POKEMAN SAM: Jul 8, 2004

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

Scarythought: Apr 26, 2011

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?

i.e. the checkout from sourcesafe would be the Git master, and I do all my work in branches, merging back to master when I'm happy, and then checking back into sourcesafe.

It doesn't sound all that unreasonable to me, assuming I setup my .gitignore file to ignore the relevant Sourcesafe files.

We're moving from Sourcesafe to Clearcase soon too If only I could convince them to buy into Git and get Github:FI

# ? Apr 26, 2011 17:10

ColdPie: Jun 9, 2006

Did you just top post on an internet forum?

Whole drat world's going to hell.

# ? Apr 27, 2011 02:22

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 06:12

Modern Pragmatist: Aug 20, 2008

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

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›100 »