|
Man, I really wished I worked with someone who understood git, or received any training. I've been reading http://book.git-scm.com/4_rebasing.html and I can't follow those diagrams. I'm also getting confused by the term 'commit' having just come from SVN.
|
#
?
Dec 12, 2011 16:39
|
|
|
|
| # ? May 11, 2024 22:24 |
|
|
Watch this: http://blip.tv/open-source-developers-conference/git-for-ages-4-and-up-4460524 The first half should educate you plenty. 
|
|
#
?
Dec 12, 2011 16:49
|
|
|
Mithaldu posted:Watch this: http://blip.tv/open-source-developers-conference/git-for-ages-4-and-up-4460524 Thanks for that, it's really useful! Edit: After watching that video I had a look at our tree. It appears that the new 'origin' and the origin I was working from are actually identical and refer to the same node, so I don't know why they want branches redone. The more you know! nexus6 fucked around with this message at 18:02 on Dec 12, 2011 |
|
#
?
Dec 12, 2011 17:25
|
|
|
I just setup Mercurial on my VPS. I'm trying to push my main repo, but I'm getting this error:code:The repo has the same group/user permissions as the SSH account (recursively set). /tmp contains a hg-unbundle file that's 3.8gb (right at the size of my repo). Anyone know how I can fix this without reuploading the entire repo? If I look at the size of the repo, it's 474mb, but inside the .hg/store directory, I can see there's still a lock on the repo. [edit] gently caress it, I just wiped the repo. Gonna try again from scratch. [edit2] I was able to fix it. For anyone that encounters this error, I think it's because I was trying to push a larger changeset than Mercurial could handle (whether the limit is memory or something inherent in Mercurial itself, I'm not sure). I fixed this by splitting up my pushes into several 400mb-500mb pushes. These each completed successfully. Does Git do any better with really large repos? [edit3] Turns out that wasn't actually the problem either. I made edit2 when I was like 3 pushes in, and I thought that was gonna work. The problem was that I had 1 file that was very large (500mb). Mercurial apparently handles all files as Python strings in memory. My VPS is a Linode 512, so what was happening was that I was running out of memory (physical and swap). I deleted the file, wiped the repo, pushed the entire repo from scratch, and it worked! The takeaway here is that Mercurial isn't very good at handling large files. I'm sure that if I had a more beastly server with something like 4gb+ RAM, I would've been just fine, but know that Mercurial uses memory proportional to each file size on the receiving machine when pushing a repo. Fangs404 fucked around with this message at 14:52 on Dec 14, 2011 |
|
#
?
Dec 12, 2011 17:44
|
|
|
Plorkyeran posted:git push origin :branchname to delete a remote branch. Thanks, by the way, to you and pseudorandom name. This worked.
Golbez fucked around with this message at 16:28 on Dec 13, 2011 |
|
#
?
Dec 13, 2011 16:26
|
|
|
nexus6 posted:Man, I really wished I worked with someone who understood git, or received any training. I've been reading http://book.git-scm.com/4_rebasing.html and I can't follow those diagrams. I'm also getting confused by the term 'commit' having just come from SVN. Make a dummy repo with like 5 files. Make a bunch of commits changing them, make branches, change them etc, then start playing with the commands and see what the results are. Practice makes perfect.
|
|
#
?
Dec 14, 2011 08:24
|
|
|
In git, we have our master/live branch, and a test branch that we throw projects in whenever they need testing. All our projects branch off master, and we merge them into test as needed. Due to some poor decisions a few months ago and possibly a bad merge more recently, test is becoming unusable. When I branch a new branch off master and want to merge it into test, I now have to deal with so many inconsistencies that it's easier to just copy the changed files out of my development branch and copy them manually into the test branch, rather than try merging. My plan for resolving this is to nuke test and reclone it from master, then merge back in all of our development branches that are currently in testing. My fear, though, is that since test will technically be newer than the development branches (having been cloned off a more recent version of master) that the branches won't want to properly merge in; I've had problems in the past where, before I fully learned how git worked, I wasn't able to merge changes into a branch because it was considered more recent than the development branch, or some weirdness. So, does this sound like it will work or will it bite me in the rear end? Edit: Just tested it, looks like it would bite me in the rear end: pre:$ git checkout -b testing_this master Switched to a new branch 'testing_this' $ git merge --no-commit new_feature Already up-to-date. What are my options here to shore up the testing branch? Golbez fucked around with this message at 23:23 on Dec 27, 2011 |
|
#
?
Dec 27, 2011 20:56
|
|
|
Are you sure the commits in the feature branch are not already in master? I think that's what that error message means.
|
|
#
?
Dec 27, 2011 23:42
|
|
|
ColdPie posted:Are you sure the commits in the feature branch are not already in master? I think that's what that error message means. They're definitely not, no. What I think it's seeing here is that the feature branch came off master from weeks ago, so now when trying to merge into this new testing branch, it sees, "Oh, this master is more recent than what I branched from! It is therefore up to date and there's nothing I can add." Edit: Which makes no sense, because I know that when I merge that branch back into master, despite master being newer, it will happily merge the files in. So I have no clue what's going on. Edit again: Found the problem: * A feature had been branched off months ago from test instead of master. * When I merged it into master, I cherrypicked what I wanted in. Unfortunately this still sucked in a bunch of test's history into master. * So when I branched a new feature off master and tried to merge it into test, a bunch of legacy conflicts appeared. * Solution was to roll back master to before test infecting it, recommit any changes since then, and rebranch those features off the new master. Golbez fucked around with this message at 18:13 on Dec 28, 2011 |
|
#
?
Dec 27, 2011 23:50
|
|
|
Fangs404 posted:The takeaway here is that Mercurial isn't very good at handling large files. I'm sure that if I had a more beastly server with something like 4gb+ RAM, I would've been just fine, but know that Mercurial uses memory proportional to each file size on the receiving machine when pushing a repo.
|
|
#
?
Dec 28, 2011 01:42
|
|
|
Fangs404 posted:I just setup Mercurial on my VPS. I'm trying to push my main repo, but I'm getting this error: That will certainly be useful to know once my projects aren't <10MB of source total, I had no idea Mercurial would have a problem with this. May I ask though how you set up Mercurial to push stuff to your VPS? I have a bunch of repos on my local windows machine, and would like to push them to my host (NFS). It's a basic shared deal, but i have SSH access and used it successfully to connect to the SQL server. I already tried this a few times based on some incomplete information I found, but with no success.
|
|
#
?
Dec 28, 2011 23:29
|
|
|
mobby_6kl posted:That will certainly be useful to know once my projects aren't <10MB of source total, I had no idea Mercurial would have a problem with this. mobby_6k1 posted:May I ask though how you set up Mercurial to push stuff to your VPS? I have a bunch of repos on my local windows machine, and would like to push them to my host (NFS). It's a basic shared deal, but i have SSH access and used it successfully to connect to the SQL server. I already tried this a few times based on some incomplete information I found, but with no success. Just ssh into your server (I assume you have hg installed there) and run hg init to create a new, empty repo. Then on your local machine just hg push ssh://you@wherever.net:/path/to/repo. That's all you need to do. I'm assuming the normal hg distribution for windows has ssh support out of the box, we use tortoisehg at work and handle interaction with the master hg server in exactly this way. EDIT: Oh it looks like you probably can't have hg installed on the server. In that case just hg bundle -a ../repo-name.hg and scp that to the server and push to that. Or zip a clean clone and stick that up there, whichever. SavageMessiah fucked around with this message at 22:26 on Jan 4, 2012 |
|
#
?
Jan 4, 2012 22:21
|
|
|
I have some questions about using git. I am using it for personal projects, which means I'm the only one writing code for it. However, I do sometimes use a different computer. All hell broke loose on me while doing that, although a lot of that I think has to do with Windows volunteering to fix some files in the git source tree. Help me understand how to more properly use it here. I was doing a pull up front, committing code, and then pushing it back. It's my understanding this is naughty, and I should be using a branch for all this. So is it like this: 1. Declare a branch for the project into which I will be merging from now on as my "trunk." 2. When I get the inkling to screw with my code, declare a branch on my local copy. 3. Muck around with the branch, committing to that branch as I feel like it. 4. Merge that branch into the trunk. Will that merge go up to the server? Do I push to that branch on the server? I was also thinking that I have some personal hosting that doesn't get much use. I was thinking I'd set up my repository on it and use SSH. If git is not technically installed on the host machine, can I expect problems? If everything is kosher there, how do I set up the repository there? Can I just copy my local hard disk master repository up on there and expect good things?
|
|
#
?
Jan 14, 2012 15:22
|
|
|
Branches are complicated and generally not worth it for a single developer scenario, in my opinion. Have you read http://progit.org/book/ ? Especially chapters 1, 2, 3, 5, and 6. My suggestion would be to use git-rebase much more than git-merge and git-pull (If you don't know what that means, please keep reading ), since linear histories are much easier to understand. E: About your server, read chapter 4. SSH access might be sufficient. I'm not sure if that requires Git installed on the remote end. ColdPie fucked around with this message at 16:46 on Jan 14, 2012 |
|
#
?
Jan 14, 2012 16:37
|
|
|
My (all windows based) team has started to get used to git and we've got a pretty good convention around branch names. However, every once in a while someone will accidentally push a branch with the something in the wrong case. For example, the original branch was "ticket/3092--FixSomething" and the guy checks it out but then somehow pushes to "Ticket/3092--FixSomething". So now, whenever I do a git fetch it tells me there's something new: code:Any ideas on how to get out of this mess?
|
|
#
?
Jan 16, 2012 03:45
|
|
|
I talked with the Dev and he'd already realized his mistake and put his changes into the right branch, so I was able to just push origin :Ticket/3092--FixSomething and all is fine. But this is the third time it's happened and it's really getting annoying.
|
|
#
?
Jan 16, 2012 16:07
|
|
|
I have no idea how the hell something like this could happen. Are you using the latest MSysGit?
|
|
#
?
Jan 16, 2012 16:19
|
|
|
They've managed to do it with msysgit, smartgit and tortoise.
|
|
#
?
Jan 16, 2012 19:45
|
|
|
Dromio posted:They've managed to do it with msysgit, smartgit and tortoise. Maybe they're using this stickykeys feature that uppercases the start of words, or are typing on a cellphone ...
|
|
#
?
Jan 16, 2012 19:49
|
|
|
Mithaldu posted:Maybe they're using this stickykeys feature that uppercases the start of words, or are typing on a cellphone ... This might not be too far off really. I do expect he has to use special accessibility tools that might be too vigorous in trying to make sure his text entry is correct-- this particular developer is partially paralyzed. I suppose I should ask him if our naming conventions are difficult with his tools.
|
|
#
?
Jan 16, 2012 21:07
|
|
|
I have a development branch, let's call it dev:code:The changes have definitely been made, and I can see the differences when I check out to the other branch, but the changes aren't getting pushed for some reason. I'd - obviously - like to view my branch on GitHub, but git won't let me. What's up?
|
|
#
?
Jan 20, 2012 22:39
|
|
|
ufarn posted:What's up? git push origin dev
|
|
#
?
Jan 20, 2012 22:51
|
|
|
Mithaldu posted:If the branch of your local repo does not exist in the remote already, you need to specify it manually, i.e.:
|
|
#
?
Jan 20, 2012 23:31
|
|
|
Do you need git installed on a remote machine to use git locally with SSH with the remote space? I know the normal thing to do is to do the git administration on the remote machine--particularly the git init that starts the whole mess. But is it really necessary? Could I set up a .git hierarchy in some directory, and then run all the git operations from my client machine? I don't know what operations git is doing over the SSH link.
|
|
#
?
Jan 25, 2012 19:08
|
|
|
Rocko Bonaparte posted:Do you need git installed on a remote machine to use git locally with SSH with the remote space? I know the normal thing to do is to do the git administration on the remote machine--particularly the git init that starts the whole mess. But is it really necessary? Could I set up a .git hierarchy in some directory, and then run all the git operations from my client machine? I don't know what operations git is doing over the SSH link. You do need git installed on the remote computer (git locally is sshing into the remote and starting git there, then they communicate over the ssh connection). That said, you can always just mount the remote machine over ssh using sshfs, and then access it with git as though it were a local directory. E: or have a post-commit hook that rsyncs a local repo to the remote machine
|
|
#
?
Jan 25, 2012 19:16
|
|
|
ToxicFrog posted:You do need git installed on the remote computer (git locally is sshing into the remote and starting git there, then they communicate over the ssh connection). 
|
|
#
?
Jan 26, 2012 06:01
|
|
|
Rocko Bonaparte posted:I'm now scared shitless of actually trying to go the next step. I'd be uneasy about this too. I don't believe Git is designed to work over a network mount like this, and who knows how well the dokan sshfs plugin works. If msysgit bash actually recognizes the sshfs mount as a drive letter (good luck, by the way), you'll want make sure that your local development repository's .git/config has a remote URL of the form file:///z/path/to/repo.git. The file:// prefix forces Git to use its normal network transfer protocol instead of e.g. trying to hardlink pack files on a local disk. This is all a horrible idea anyway; why don't you just install Git on your web host machine? (You can SSH into your web hosting and install things, right? You can even install Git into your home directory if you don't have root on the machine.)
|
|
#
?
Jan 26, 2012 14:24
|
|
|
Lysidas posted:I'd be uneasy about this too. I don't believe Git is designed to work over a network mount like this, and who knows how well the dokan sshfs plugin works. It works fine over sshfs-in-linux (and nfs, for that matter), but I have no idea how the windows one works.
|
|
#
?
Jan 26, 2012 19:02
|
|
|
Lysidas posted:This is all a horrible idea anyway; why don't you just install Git on your web host machine? (You can SSH into your web hosting and install things, right? You can even install Git into your home directory if you don't have root on the machine.) I have a question about conventions for creating repositories. Today I was trying to get much more into git at work and init'd myself a trash repository. I didn't make it a bare repository, so there was a .git hiding in the path I did the init. In Git Extensions for Visual Studio, I noted it was a public repository when I did the clone command. Somehow in all that, it came through okay. But when I tried again as a private repository, I got poo poo on trying to push changes back up--kind of the generic git message about refusing to fast forward. But if I did it with a bare repo, I would be okay. So for small team projects hitting a UNIX drive over SSH, is the convention to do a bare repo? Is there really a benefit one way or another? All I can think of is referring to the project path directly instead of project_path/.git.
|
|
#
?
Jan 27, 2012 07:59
|
|
|
Rocko Bonaparte posted:Ehh kinda. I can SSH into it but there's no git on the plan I had. I had sent a message in tech support about that. I have some web hosting package, and would have to upgrade to a virtual or dedicated host. I'm pondering it, though as an opportunity to re-examine my whole hosting situation. You can use gitorious or github as your hosting solution. I'm sure you can find something to fit your needs at one of them. Rocko Bonaparte posted:So for small team projects hitting a UNIX drive over SSH, is the convention to do a bare repo? Is there really a benefit one way or another? All I can think of is referring to the project path directly instead of project_path/.git. Bare repositories can't checkout, they just store objects, branches, and tags. That saves disk space and prevents problems like pushing to a checked out branch, or someone mistakenly using the master repo or something.
|
|
#
?
Jan 27, 2012 13:16
|
|
|
Did I get this video from this thread? http://blip.tv/open-source-developers-conference/git-for-ages-4-and-up-4460524 Good content plagued by bad presentation. I got to 19 minutes before I got tired of watching him struggle with the tinkertoys. Anyone else have some good git (or mercurial, bazaar) videos like this? Something that avoids the really basic stuff like "git add is a command that you use to add st... etc." and dives right into the branching complexity? I work in an environment that doesn't produce lots of branches so it's hard for me to learn about how it works without tutorials.
|
|
#
?
Jan 28, 2012 05:28
|
|
|
There's Federico's git tutorials: Pushing and Pulling with Git, part 1 Pushing and Pulling with Git, part 2 Why I want to have the children of git rebase --interactive For something really low-level, you can read Git from the Bottom Up.
|
|
#
?
Jan 28, 2012 09:01
|
|
|
Wideshanks posted:Did I get this video from this thread? Very likely, since i post it whenever i can.  And you're right, the useful bit of it is the first half, then it kinda falls apart. However, the first half already gives you a massive advantage over a SVN dude trying to transition on his own.As for branches, the easiest way to learn about them is to try and do an interactive rebase manually: 1. pick a commit in the past you want to edit 2. set a new branch marker on the commit 2 before that one and check it out 3. cherry-pick the two commits before the one you want to edit 4. cherry-pick the one you want to edit, edit code and make a --amend commit 5. go through and cherry-pick each of the following ones, resolving conflicts as you go 6. reset --hard the master branch tag to the HEAD of your new branch 7. delete the new branch tag you made previously 8. push --force Now you know everything you need to know about branches.
|
|
#
?
Jan 28, 2012 14:24
|
|
|
Why is it that, on Windows 7, `git diff` sometimes returns absolutely nothing? Makes it hard to see what's changed ... Second, is there really no way to prevent git from interpreting removed or added as completely new documents, where everything is -'d and +'d?
|
|
#
?
Jan 28, 2012 14:53
|
|
|
ufarn posted:Why is it that, on Windows 7, `git diff` sometimes returns absolutely nothing? Makes it hard to see what's changed ... ufarn posted:Second, is there really no way to prevent git from interpreting removed or added as completely new documents, where everything is -'d and +'d?
|
|
#
?
Jan 28, 2012 14:55
|
|
|
Mithaldu posted:Never had that happen, and anyhow, you want to run git gui for that because it lets you easily get an overview on both your working directory and the index.
|
|
#
?
Jan 28, 2012 15:16
|
|
|
Suspicious Dish posted:For something really low-level, you can read Git from the Bottom Up. Ah, this is perfect, thank you. Cool command--get a list of each of the objects in your repo and what type they are: find .git/objects -type f | awk 'BEGIN{FS="/"}{print$3$4}' | while read -r hash; do git cat-file -t $hash; done
|
|
#
?
Jan 28, 2012 17:31
|
|
|
Suspicious Dish posted:For something really low-level, you can read Git from the Bottom Up. I'm also fond of Git for Computer Scientists for a good look at how branches etc work internally without getting sidetracked by implementation details.
|
|
#
?
Jan 28, 2012 20:55
|
|
|
Wideshanks posted:Ah, this is perfect, thank you. FYI this only examines loose objects, i.e. those that aren't stored in a pack file. (A few git commands run git gc --auto after they complete, and this will consolidate loose objects into a pack file if there are too many. You can also manually pack your loose objects with git repack.) EDIT: code:
|
|
#
?
Jan 29, 2012 00:30
|
|
|
|
| # ? May 11, 2024 22:24 |
|
|
Lysidas posted:FYI this only examines loose objects, i.e. those that aren't stored in a pack file. (A few git commands run git gc --auto after they complete, and this will consolidate loose objects into a pack file if there are too many. You can also manually pack your loose objects with git repack.) Yeah, I noticed that. I guess it's useful only for learning purposes with a small testing repo: I thought it was nice to see what objects were created when I ran a command. Run git add, then see it add the blob. Do git commit and then see the commit object pop up. Edit: Is there a way to use hg-style shortcuts for the unambiguous commands in git? E.g. type "git co" for "git commit" / "git stat" for "git status"? Wideshanks fucked around with this message at 18:53 on Jan 29, 2012 |
|
#
?
Jan 29, 2012 04:32
|
|