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 »

Zhentar: Sep 28, 2003; Brilliant Master Genius

Mithaldu posted:

TGit paired with Putty's pageant handles branching, diffing, logs, merging and most importantly, connectivity to remote repos with ssh keys completely transparently for you.

Except it leaves pageant open, with a starting directory in wherever you first used it, which holds a file lock and prevents you from deleting/moving/renaming that folder.

AutoCrLf handling is, at best, poor. It will mark files as modified immediately after checking them out, which will interfere with a lot of operations (no switching for you).

I've had numerous operations mysteriously fail, and then succeed on the second try without doing anything differently. And other operations that failed for a good reason, but all TortoiseGit will give me is a pop-up dialog with a hex string in it.

# ? Mar 20, 2010 18:36

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 01:23

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

Note in advance: I sort of assume that a developer working on windows knows how to administrate their own machine.

Zhentar posted:

Except it leaves pageant open, with a starting directory in wherever you first used it, which holds a file lock and prevents you from deleting/moving/renaming that folder.

I don't move/delete my repos daily, so closing pageant for a moment is not a problem. Plus, it's in my autostart anyway, so it can't interfere like you described.

Zhentar posted:

It will mark files as modified immediately after checking them out

I don't even know what this is supposed to mean.

Zhentar posted:

which will interfere with a lot of operations (no switching for you).

Oh no. I have to make the massive and completely unwarranted effort of stashing things. :qq:

Zhentar posted:

I've had numerous operations mysteriously fail, and then succeed on the second try without doing anything differently. And other operations that failed for a good reason, but all TortoiseGit will give me is a pop-up dialog with a hex string in it.

Haven't had this occur a single time, neither of these scenarios. And I've been doing a lot of stuff with it, including git-svn. Maybe you only tried an old version?

Zhentar posted:

AutoCrLf handling is, at best, poor.

If you don't have an editor which can easily deal with all three line ending styles, or cannot set it to automatically transform all files to unix-style or don't even do that then you can walk off a cliff for all i care.

As such, i never even noticed this being a problem at all.

# ? Mar 20, 2010 19:03

ToxicFrog: Apr 26, 2008

Mithaldu posted:

I don't even know what this is supposed to mean.
Oh no. I have to make the massive and completely unwarranted effort of stashing things.

If you don't have an editor which can easily deal with all three line ending styles, or cannot set it to automatically transform all files to unix-style or don't even do that then you can walk off a cliff for all i care.

As such, i never even noticed this being a problem at all.

The problem he refers to is not with the editor, but with git itself. It's possible to get into a situation where the following happens:

- you check out a commit
- git fucks up with the CRLF conversion somewhere
- now git thinks all your files are modified because the line endings differ
- you can't switch branches or anything because git thinks everything is modified even though it isn't

Personally, I haven't observed this behaviour recently, but then, I haven't used git on windows recently either.

# ? Mar 20, 2010 22:55

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

ToxicFrog posted:

The problem he refers to is not with the editor, but with git itself. It's possible to get into a situation where the following happens:

- you check out a commit
- git fucks up with the CRLF conversion somewhere
- now git thinks all your files are modified because the line endings differ
- you can't switch branches or anything because git thinks everything is modified even though it isn't

Personally, I haven't observed this behaviour recently, but then, I haven't used git on windows recently either.

Must be an old and now fixed issue. I've used git across multiple platforms and versioning systems in projects of varying structures and nothing even remotely similar has happened.

Thanks for explaining though.

# ? Mar 20, 2010 23:00

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

ToxicFrog posted:

The problem he refers to is not with the editor, but with git itself. It's possible to get into a situation where the following happens:

- you check out a commit
- git fucks up with the CRLF conversion somewhere
- now git thinks all your files are modified because the line endings differ
- you can't switch branches or anything because git thinks everything is modified even though it isn't

Personally, I haven't observed this behaviour recently, but then, I haven't used git on windows recently either.

You can't git stash away the (non)changes?

# ? Mar 20, 2010 23:04

ColdPie: Jun 9, 2006

ToxicFrog posted:

The problem he refers to is not with the editor, but with git itself. It's possible to get into a situation where the following happens:

- you check out a commit
- git fucks up with the CRLF conversion somewhere
- now git thinks all your files are modified because the line endings differ
- you can't switch branches or anything because git thinks everything is modified even though it isn't

Personally, I haven't observed this behaviour recently, but then, I haven't used git on windows recently either.

git reset --hard HEAD

# ? Mar 20, 2010 23:46

ToxicFrog: Apr 26, 2008

stash/reset might work if you realize what's happened immediately; however (at least back when this happened to me) the more common case was checkout, hack hack hack, status, oh dear it thinks everything is modified. And then you have to disentangle the real changes from the bogus ones before you can stash.

:shrug:

These days I do most of my development on linux and all of it using LF linebreaks, so.

# ? Mar 21, 2010 00:42

Pardot: Jul 25, 2001

ToxicFrog posted:

stash/reset might work if you realize what's happened immediately; however (at least back when this happened to me) the more common case was checkout, hack hack hack, status, oh dear it thinks everything is modified. And then you have to disentangle the real changes from the bogus ones before you can stash.

These days I do most of my development on linux and all of it using LF linebreaks, so.

This wouldn't happen with my workflow, though it's not for everyone

Never work on master, always be in a topic branch.
make a billion commits every time any progress is made, no matter how small. I aliased gw to git add -u && git commit -m
rebase from master as needed when other people commit to it
when the feature is done, switch to master and do git merge --squash topic-branch-name then commit that with a nice message of the overall feature

That way, I can have the benefits of lots of small commits while I'm working something out, but master is one nice, linear history of what changed without all the back and forth of development.

# ? Mar 21, 2010 01:07

Zhentar: Sep 28, 2003; Brilliant Master Genius

I only started using git a few weeks ago, so I've only used the current version of TortoiseGit

Otto Skorzeny posted:

You can't git stash away the (non)changes?

I shall give that a try...

And now I've got a shining example of TortoiseGit messages:

Only registered members can see post attachments!

# ? Mar 21, 2010 02:26

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

Zhentar posted:

I only started using git a few weeks ago, so I've only used the current version of TortoiseGit

I shall give that a try...

And now I've got a shining example of TortoiseGit messages:

How the hell did you manage to gently caress up your system like that? I've been using it for a while now and never saw anything like what you got there. Looking at it it actually seems like you have some kind of permission problem with a directory being read-only there.

Edit: It's possible that the stuff in your repo has a directory set to read-only with the unix file flags and git tries to recreate that on windows and paints itself in a corner that way. This might even be a problem with git itself and not tgit, since all you're getting there anyhow is an error with the revert it does after saving to stash. The actual saving was fine.

Mithaldu fucked around with this message at 10:36 on Mar 21, 2010

# ? Mar 21, 2010 10:33

tripwire: Nov 19, 2004; _{ghost flow}

Mithaldu posted:

How the hell did you manage to gently caress up your system like that? I've been using it for a while now and never saw anything like what you got there. Looking at it it actually seems like you have some kind of permission problem with a directory being read-only there.

Edit: It's possible that the stuff in your repo has a directory set to read-only with the unix file flags and git tries to recreate that on windows and paints itself in a corner that way. This might even be a problem with git itself and not tgit, since all you're getting there anyhow is an error with the revert it does after saving to stash. The actual saving was fine.

I can definitely feel where hes coming from though.

If what you are saying is true, shouldnt it be handled a little more sensibly by a front-end of git which is designed for windows users? At the very least it could pop up a dialog explaining to the user what you've just said here, which is more helpful than "Cannot reset index file revision to HEAD"

# ? Mar 21, 2010 17:52

Nomnom Cookie: Aug 30, 2009

Mithaldu posted:

How the hell did you manage to gently caress up your system like that? I've been using it for a while now and never saw anything like what you got there. Looking at it it actually seems like you have some kind of permission problem with a directory being read-only there.

Edit: It's possible that the stuff in your repo has a directory set to read-only with the unix file flags and git tries to recreate that on windows and paints itself in a corner that way. This might even be a problem with git itself and not tgit, since all you're getting there anyhow is an error with the revert it does after saving to stash. The actual saving was fine.

Open handle can do it to; if so, Process Explorer can diagnose.

# ? Mar 21, 2010 18:18

ColdPie: Jun 9, 2006

tripwire posted:

I can definitely feel where hes coming from though.

If what you are saying is true, shouldnt it be handled a little more sensibly by a front-end of git which is designed for windows users? At the very least it could pop up a dialog explaining to the user what you've just said here, which is more helpful than "Cannot reset index file revision to HEAD"

I really don't know why people don't just use git's command-line interface. It's very easy to use and well-designed, and the error messages are much more helpful than whatever a wrapper would be able to guess at. Much easier than messing about with an additional layer between you and what's actually going on.

# ? Mar 21, 2010 19:10

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

Dammit guys, I'm almost still a newbie (realized i can branch just this thursday) to git and i can make sense of that message. And hell, it's not like the command line would be more useful since that message there is just the command line output copied into a message box.

Taken apart:

First it stored the current changes successfully into the stash

THEN

it did "git checkout-index" which failed

BECAUSE

it could not create "examples/findnameindexes.cpp"

BECAUSE

permission do do that was denied (likely by the file system)

THUS

the index file revision could not be reset to HEAD.

So, in summary: Saving the stash went fine, but because of some permission problems it could not actually remove the saved changes from the working copy.

Now, the permission problem could be either an inability to create "examples", due to read-only on the base directory; "findnameindexes.cpp" due to read-only on "examples" or because "findnameindexes.cpp" already exists and is not read-only.

Since it's not trying to move or delete anything open handles are almost irrelevant, unless some amazingly dumb IDE has a read-only lock on "findnameindexes.cpp". However this is not a problem with git but with Windows and said IDE and if it is the case then git and tgit did all they could to report it.

Figuring this poo poo out is not hard and all it takes is some common sense and reading comprehension. Seriously now guys. :colbert:

tripwire posted:

If what you are saying is true, shouldnt it be handled a little more sensibly by a front-end of git which is designed for windows users?

The only way to get a gui frontend like this on git is to run the command line stuff and parse the resulting text. This means that the author has to do a poo poo-ton of matching, which has to handle many possible combinations and situations that can be easy to overlook.

Additionally tgit is largely done by one man who is most certainly not slacking off: http://repo.or.cz/git-browser/by-commit.html?r=TortoiseGit.git

As such, it's very possible that the author of tgit wasn't even aware that this could happen and had noone report it yet.

Thanks.
vvvv

Mithaldu fucked around with this message at 20:45 on Mar 21, 2010

# ? Mar 21, 2010 20:04

ToxicFrog: Apr 26, 2008

Mithaldu posted:

As far as i know (and i could be wrong) the only real way to get a gui frontend like this on git is to run the command line stuff and parse the resulting text. This means that the author has to do a poo poo-ton if matching and many possible combinations and situations that can be easy to overlook.

Correct, and IMO this is one of git's biggest flaws; the lack of a "libgit" that programs can talk to directly makes it harder to write frontends for it relative to other VCSs, which in turn means frontend development for git tends to lag behind, limiting uptake among people who aren't fond of the command line interface.

# ? Mar 21, 2010 20:30

Zhentar: Sep 28, 2003; Brilliant Master Genius

Mithaldu posted:

Now, the permission problem could be either an inability to create "examples", due to read-only on the base directory; "findnameindexes.cpp" due to read-only on "examples" or because "findnameindexes.cpp" already exists and is not read-only.

There were 14 other files in the same folder that had no issues. I didn't have the file open in any program. This one particular file was, for no apparent reason, deleted. I was able to restore the file by reverting the the folder afterwords. Since I hadn't made any changes to the file, I don't know if anything would have been lost. Considering that I have never had SVN delete files on me, this didn't exactly convince me to hop on the Git train.

# ? Mar 21, 2010 21:03

BizarroAzrael: Apr 6, 2006; "That must weigh heavily on your soul. Let me purge it for you."

gently caress. Just switched to newest SVN, which seems to create a new problem when updating. I run svn from the command line and it wants user input every time it finds a file in conflict.

I want it to leave the local changes alone and move on with the update without input, is that svn update --non-interactive?

# ? Mar 23, 2010 11:10

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

BizarroAzrael posted:

gently caress. Just switched to newest SVN, which seems to create a new problem when updating. I run svn from the command line and it wants user input every time it finds a file in conflict.

I want it to leave the local changes alone and move on with the update without input, is that svn update --non-interactive?

It should show you a list of options like (df) diff-full, (tf) theirs-full, (mf) mine-full and (i) ignore (or something like that, I'm going off memory). Just type "i" or whatever the option is for "deal with this later."

Edit: But to answer your question, I believe yes, it's --non-interactive.

# ? Mar 23, 2010 11:48

BizarroAzrael: Apr 6, 2006; "That must weigh heavily on your soul. Let me purge it for you."

musclecoder posted:

It should show you a list of options like (df) diff-full, (tf) theirs-full, (mf) mine-full and (i) ignore (or something like that, I'm going off memory). Just type "i" or whatever the option is for "deal with this later."

Edit: But to answer your question, I believe yes, it's --non-interactive.

This update takes place overnight, as part of a larger process, so it needs to be automated.

Might not be as bad as I thought though, it seems to do merges fine in the tests I've done, so it's a handful of exceptions. And it deals with unversioned files blocking versioned ones, which I used to have to work around.

# ? Mar 23, 2010 12:07

BizarroAzrael: Apr 6, 2006; "That must weigh heavily on your soul. Let me purge it for you."

Problem:

Error: Checksum mismatch while updating Error: '[filename]'; expected: Error: '71467c5d444b7e4869609f5993ad077b', actual: '0b590ed77b36a502b78885db58340307' Error: Try a 'Cleanup'. If that doesn't work you need to do a fresh checkout.

Cleanup on the whole project didn't make a difference, and a new checkout is undesirable, can anyone tell me what happened here? The prior update stopped when it couldn't move a temp file over an existing one. The .tmp was left in the directory, though I don't know where it came from and why it wasn't coming from the repository.

Would deleting the offending directory and doing an SVN update to restore it sort it out?

# ? Mar 25, 2010 11:40

epswing: Nov 4, 2003; Soiled Meat

BizarroAzrael posted:

Would deleting the offending directory and doing an SVN update to restore it sort it out?

I don't know. But you can move the file, try it, and move it back if it doesn't work.

# ? Mar 29, 2010 04:59

hey mom its 420: May 12, 2007

In hg, I want to see all the files that were changed from revision 40 to revision 41. I don't want to see the diff contents, I just want to know which files were changed. Currently, I do:

code:

$ hg diff -g -r40:41 | grep "^diff"

and then get back

code:

diff --git a/foo.hs b/foo.hs
diff --git a/bar.hs b/bar.hs
diff --git a/baz.hs b/baz.hs

This works, but is this the proper way of doing this or is there a better way?

# ? Apr 7, 2010 00:15

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

code:

$ hg diff -g -r40:41 | diffstat

Might be more what you want.

# ? Apr 7, 2010 01:30

Allie: Jan 17, 2004

Or with hg 1.4 or newer:

code:

$ hg diff --stat -g -r40:41

Or maybe something a bit simpler:

code:

$ hg status --rev 40:41

# ? Apr 10, 2010 07:50

Knackered: Jul 29, 2006

Hey guys,

If you remember I posted a question a while back about setting up a code versioning system at work. It then resulted in a few pages of debate, which I was not expecting.

Well, I was hesitant at first about using a DVCS over an SVN, but after all the praise given to DVCS's and the sound arguments you guys put forward, I decided to give it a shot.

All I have to say is wow, you were right. We're now using Mercurial and TortoiseHG, its easy to use, merging repositories is simple and conflicts are a breeze to resolve, even for an amateur like me.

Thanks for all the assist goons, I would have made the wrong choice without all your help. Plus it was really entertaining to see you take apart SVN's so thoroughly.

# ? Apr 13, 2010 15:18

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

Knackered posted:

Great to hear, though the debate was mostly Sizzlechest digging in his heels and defending an inferior system that really should be put out of its misery. After using Git for so long, I'm not exaggerating my opinion in the slightest.

Long ago, I was going to say something about your original post:

Knackered posted:

I was thinking of using a simple SVN over GIT/Mercurial.
...
Of course the other guy if all for using GIT/Mercurial, which I think is over kill.

I meant to respond to this in particular; you had this backwards regarding which was simple and which was overkill

. There's a bit of a learning curve with the core concepts of a DVCS, but once you get past that, everything makes more sense and is easier to work with.

Since I'm in this thread, I may as well share some useful information too:

Zhentar posted:

AutoCrLf handling is, at best, poor. It will mark files as modified immediately after checking them out, which will interfere with a lot of operations (no switching for you).

I've seen this happen and I believe I have an explanation for it. I would guess that your repository contains files with CR+LF line endings (i.e. the actual content of the blob objects).

If core.autocrlf = true, Git will translate everything to a CR+LF line ending on checkout. However, since it would be committed with LF line endings instead of the CR+LF in the current commit, it's marked as modified (even after a git reset --hard or git stash). I believe that the best way to fix this is to commit the changes, thereby fixing the line endings in the actual repository. This will have detrimental effects on git blame, though. I'm sure you could fix the line endings in all previous commits with git filter-branch, but that can be quite disruptive (see the documentation on recovering from an upstream rebase)

Off the top of my head (i.e. I haven't had to do this in a while and I'm on a Linux machine now), I've found this sequence of operations to fix most CR/LF problems except for the one that I described above:

code:

git config core.autocrlf false
rm .git/index
git clean -dfx
git config core.autocrlf true
git reset --hard

This will rebuild the index and do a clean checkout of the entire working tree. Some or most of those commands may not be necessary and your mileage may vary depending on the root cause of your specific situation, but I've found this to work very well in the rare cases when I've had to resort to something like this.

# ? Apr 13, 2010 18:01

HFX: Nov 29, 2004

I've been using git with an svn connector. I had been doing all rebase and commits from the master after merging local branches. However, the rebase operation has an unfortunate side effect of removing the local git history for the branch being merged back to trunk. Can someone recommend me a way to keep the history and still be able to do updates from SVN?

# ? Apr 14, 2010 15:44

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

HFX posted:

I've been using git with an svn connector. I had been doing all rebase and commits from the master after merging local branches. However, the rebase operation has an unfortunate side effect of removing the local git history for the branch being merged back to trunk. Can someone recommend me a way to keep the history and still be able to do updates from SVN?

The short answer: create a new branch (like git branch old) before running git svn rebase.

I'm not sure if you should make new commits on the old branch, though. Repeated rebases of the same commits might not be handled correctly (though they seemed to be in my quick test).

# ? Apr 14, 2010 18:36

Lexical Unit: Sep 16, 2003

So I have to work with CVS and I was hoping to leverage git for this but I keep having problems with git cvsexportcommit. For example, I have a commit that touches a few files and I want to apply it to the cvs repository, right. Ok, here goes:

code:

$ cd cvs_repo
$ export GIT_DIR=/path/to/git_repo/.git
$ cvs update
cvs update: Updating .
cvs update: Updating project
$ git cvs exportcommit  "SHA_OF_THE_COMMIT_I_WANT"
Checking if patch will apply
Applying
<stdin>:89: trailing whitespace.
		
error: patch failed: project/file.cpp:33
error: project/file.cpp: patch does not apply
cannot patch at /opt/local/libexec/git-core/git-cvsexportcommit line 283.

Huh? Why doesn't the patch apply?

Then I took a look at the .cvsexportcommit.diff file git created and sure enough, the first diff starts on line 33. But the patch looks fine to me: the lines are just as expected. No one else has modified the file since the changes I've made.

code:

$ file /path/to/git_repo/project/file.cpp
/path/to/git_repo/project/file.cpp: ASCII c program text, with CRLF line terminators

Ughhh. Line endings issue. git creates the .cvsexportcommit.diff file with UNIX style line endings. Probably because I'm running git from Mac OS X and developing on a Windows VM. The line endings should be CRLF because the application is a Windows application.

Anyone got an idea how to fix this? I don't see why the diff doesn't have the correct line endings, that makes no sense. The source files are CRLF, why would diff change that? That's completely unhelpful.

# ? Apr 14, 2010 19:53

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

Lexical Unit posted:

I'm running git from Mac OS X and developing on a Windows VM.

This seems like a very bad idea, and I'm not surprised in the slightest that you're having problems. Are you using Git over a network mount, or something like that?

I recommend installing msysgit in the Windows VM and using Git from there. If you're using it on OS X, you're probably well-versed in the command line and won't mind a sub-par GUI (though I really like SmartGit, and it just hit version 1.5).

You should probably make sure that the repository's core.autocrlf value is set to false. msysgit sets that to true by default for new or cloned repositories, but Git on OS X won't. Your Git repository probably contains CR+LF line endings, and that combination can cause problems (as I mentioned a few posts ago).

# ? Apr 15, 2010 01:38

BizarroAzrael: Apr 6, 2006; "That must weigh heavily on your soul. Let me purge it for you."

I'm getting lots of failed svn updates when there is a file on the repository and one by the same name on the working copy. I thought this issue was dealt with in 1.6.5, and even tested it, but it's still happening. Maybe it's unable to merge the filetypes in question, but it should still deal with that. Can anyone suggest what I need to do to make SVN work in spite of itself? Do I need to script something to move the files out of the way on the working copy side again?

# ? Apr 15, 2010 09:30

NotShadowStar: Sep 20, 2000

Okay I'm git-stupid and really stuck.

I'm working with a project that other people are doing work in their won git forks on. Someone has several branches they want me to merge back. The problem is some of the branches have work on files that are completely removed so 'git merge branch1 other-remote/branch2' won't work because files are modified in other-remote/branch2 that no longer exits in branch1. It's work that I can just reject, so is there a way to merge all the changes for files that exist and just reject stuff that references files that no longer exist?

# ? Apr 15, 2010 21:58

ColdPie: Jun 9, 2006

NotShadowStar posted:

Okay I'm git-stupid and really stuck.

I'm working with a project that other people are doing work in their won git forks on. Someone has several branches they want me to merge back. The problem is some of the branches have work on files that are completely removed so 'git merge branch1 other-remote/branch2' won't work because files are modified in other-remote/branch2 that no longer exits in branch1. It's work that I can just reject, so is there a way to merge all the changes for files that exist and just reject stuff that references files that no longer exist?

It was pretty easy for me to resolve, actually. I just put together a quick test repository which did it. I ended up with this:

pre:

[andrew@archand gittest]$ git merge other
CONFLICT (delete/modify): b deleted in HEAD and modified in other. Version other of b left in tree.
Automatic merge failed; fix conflicts and then commit the result.
[andrew@archand gittest]$ git status
# On branch master
# Changes to be committed:
#
#	modified:   a
#
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#	deleted by us:      b
#
# Untracked files not listed (use -u option to show untracked files)
[andrew@archand gittest]$ git rm b
b: needs merge
rm 'b'
[andrew@archand gittest]$ git status
# On branch master
# Changes to be committed:
#
#	modified:   a
#
# Untracked files not listed (use -u option to show untracked files)
[andrew@archand gittest]$ git commit
[master 61a4207] Merge branch 'other'
[andrew@archand gittest]$ vim a
# successfully received other's changes
[andrew@archand gittest]$ ls
a
[andrew@archand gittest]$

# ? Apr 15, 2010 22:11

NotShadowStar: Sep 20, 2000

I simply didn't think about marking the file as removed on the working branch. Thanks, this git stuff is way too meta for me still.

# ? Apr 15, 2010 22:23

ColdPie: Jun 9, 2006

NotShadowStar posted:

I simply didn't think about marking the file as removed on the working branch. Thanks, this git stuff is way too meta for me still.

While it's not directly related to your issue, you might understand git better if you take a look at `git help gitcore-tutorial`. It's got a bunch of info about how git works underneath. Everyone should really read it, it'll help you understand what's going on (for one tiny example, how to effectively use git-reset and why it works that way).

# ? Apr 15, 2010 22:34

Pardot: Jul 25, 2001

Also check out chapter 9 of pro git. It's written by githubber Scott Chacon. I've only skimmed it and the whole book looks good, but ch 9 has all those diagrams I've seen him use at the ruby conferences and such which were a big help for me.

# ? Apr 15, 2010 23:23

Lexical Unit: Sep 16, 2003

Lysidas posted:

This seems like a very bad idea, and I'm not surprised in the slightest that you're having problems. Are you using Git over a network mount, or something like that?

I've heard that git on Windows isn't so great. And I'm more comfortable with a UNIX system. Figured it would be fine. It seems like it would be if whatever git is using to create diffs didn't transmogrify my line endings without asking. Git isn't being used over a network mount, the repos are stored on my OS X machine.

Lysidas posted:

I recommend installing msysgit in the Windows VM and using Git from there. If you're using it on OS X, you're probably well-versed in the command line and won't mind a sub-par GUI (though I really like SmartGit, and it just hit version 1.5).

Yeah, no need for a GUI. I haven't used Windows since 2k (until this project) and even then I was mostly using Linux at the time. I tried msysgit and it doesn't recognize cvsexportcommit or cvsimport. According to what I could find on google msysgit doesn't currently support those commands at all.

Lysidas posted:

You should probably make sure that the repository's core.autocrlf value is set to false. msysgit sets that to true by default for new or cloned repositories, but Git on OS X won't. Your Git repository probably contains CR+LF line endings, and that combination can cause problems (as I mentioned a few posts ago).

I have it set to true because I want to make sure I don't accidentally edit a file using a OS X application or something and have LF line endings put into a file. The line endings should most definitely always be CRLF, and it's nice that git will check that for me.

However, I figured out a workaround for this issue. Here it is in case anyone is interested:

code:

$ git cvsexportcommit $SHA
... patch won't apply blah blah ...
$ perl -pi -e 's/\n/\r\n/g' .cvsexportcommit.diff
$ chmod 444 .cvsexportcommit.diff
$ git cvsexportcommit -c $SHA
... works just fine ...
$ unset GIT_DIR

Ugly as hell, but hey, it works. V :shobon:

# ? Apr 15, 2010 23:38

king_kilr: May 25, 2007

Pardot posted:

Also check out chapter 9 of pro git. It's written by githubber Scott Chacon. I've only skimmed it and the whole book looks good, but ch 9 has all those diagrams I've seen him use at the ruby conferences and such which were a big help for me.

Similarly the talk by Chris Wanstrath at DjangoCon (it's up on djangocon.blip.tv) is a good resource for the conceptual identity of git. Scott also gave a talk at pycon, avialable at pycon.blip.tv, that's good (it's about DVCS in general).

# ? Apr 16, 2010 00:11

NotShadowStar: Sep 20, 2000

Oh I've read piles of stuff on git. The man pages are the typical overly technical man page that already assumes you know everything, and the rest of it is just way different from svn. I'll get it eventually since I'm working more and more with github and have actual projects to do instead of abstract concepts.

# ? Apr 16, 2010 02:45

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 01:23

Pardot: Jul 25, 2001

If instead, you want a good approach of how you can use git day-to-day, I recommend http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html and all the links in the notes section.

I've given up the interactive rebasing, though, in favor of git merge --squash topic-branch from master.

# ? Apr 16, 2010 09:01

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

«‹›100 »