[git-users] Re: Problem cloning a GIT repo, Out of memory, windows XP (32-bit)
$ git --version git version 1.8.1.msysgit.1 Am Samstag, 2. März 2013 13:19:07 UTC+1 schrieb Thomas Ferris Nicolaisen: On Friday, March 1, 2013 1:17:49 PM UTC+1, Igor Kazarnovskiy wrote: Morning :) I have a problem cloning a large GIT repository on a windows XP (32-bit) machine. The output looks as follows: $ git clone ssh://user@server/.../git/repo/myrepo mylocalrepo Cloning into 'mylocalrepo'... remote: Counting objects: 384454, done. remote: Compressing objects: 100% (64510/64510), done. Receiving objects: 100% (384454/384454), 215.03 MiB | 5.65 MiB/s, done. remote: Total 384454 (delta 219550), reused 384454 (delta 219550) Resolving deltas: 100% (219550/219550), done. fatal: Out of memory, malloc failed (tried to allocate 440237 bytes) Unlink of file 'mylocalrepo/.git/objects/pack/pack-a92fdeb2782784db447564664d98fe6 7183d155c.idx' failed. Should I try again? (y/n) n I've tried many solutions found on forums with no luck. Could someone help me? Your help is very appreciated! Thanks Igor What version of git is this (git --version)? I see there are some historical problems http://code.google.com/p/msysgit/issues/detail?id=194 with memory use in older versions.. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] basic queries on branching merging in Git
On Saturday, March 2, 2013 9:29:55 PM UTC+5:30, Rahmat Budiharso wrote: the stash command is your friends, basically before you switch to master from b1, you do a git stash: (on b1) $ git stash save -u this will save all your untracked and unstaged file in b1 in a stash, after that you'll be back in a state just like you were when you first branch off of master, now you can switch to master and branch off b2. after you finish with b2 and merge it to master, you can go back to b1 and do a git stash pop to get your stashed changes back in b1. I'm suggesting that you do a 'git merge b2' before poping the stash. so in a nutshell, here's what you can do (*b1) git stash save -u (*b1) git checkout master (*master) git branch -b b2 (*b2) hack or bug fixing and testing… (*b2) git commit (*b2) git co master (*master) git merge b2 (*master) git co b1 (*b1) git merge b2 (*b1) git stash pop hope that's help Rahmat Budiharso Sent with Sparrow http://www.sparrowmailapp.com/?sig This seems to look fine. For testing, I took 1 single file. created a branch b1.. edited it. Instead of staging, I stashed... then checked out master then created b2 branch edited the file again (different data).. this time, staged- did commit.. checked out master, and merged branch b2. Now, I went back to b1. did stash pop now I see Auto-merging conflict On Saturday, March 2, 2013 at 10:48 PM, Surya wrote: I am working of a project X I created a branch b1 from master. I am working on some improvements in b1. I didn't commit anything. Not even stage! In the middle of the story, I found another bug need to be address soon. So, I thought to create another branch b2 from Master and work on it, merge it with master, push it to origin.. and later on go back to b1 job. However, when I switched to master to create b2 branch for fixing bug, I found all the untracked files of b1 branch in master!! All I thought till now is, until I merge or push, from a branch I don't practically, change things in master.. However, I see things now.. This is stopping me to create b2 branch from master to work on another work.. independent of b1 work. Hope you understand my situation. So, the below is summary of above- -- and what I am expecting.. How to do it? The master is where actual code is.. b1 is where I currently work on an issue. Suddenly I need to go for another issue. So, want to create b2 branch from master to work on it.. However, I am finding untracked files of b1 in master.. I want to work on b2 issue independent of b1 issue.. and later merge into master, and b1 if its really fixed.. How to do this? How do people usually happen to deal with this situation ? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] basic queries on branching merging in Git
From: Surya kasturisu...@gmail.com However, when I switched to master to create b2 branch for fixing bug, I found all the untracked files of b1 branch in master!! The important point is that these untracked changes were changes in the files of the working directory. When you told Git to switch to the master branch, by default it does not remove changes in the working directory that have not been committed. (If it did, you would lose your work.) You can use git stash to save the current state of the working directories. Or you can simply do git commit -m 'Checkpoint.' to save the current state of your work in b1, before switching back to master. Dale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] basic queries on branching merging in Git
On Sat, 2 Mar 2013 07:48:41 -0800 (PST) Surya kasturisu...@gmail.com wrote: I created a branch b1 from master. I am working on some improvements in b1. I didn't commit anything. Not even stage! In the middle of the story, I found another bug need to be address soon. So, I thought to create another branch b2 from Master and work on it, merge it with master, push it to origin.. and later on go back to b1 job. However, when I switched to master to create b2 branch for fixing bug, I found all the untracked files of b1 branch in master!! All I thought till now is, until I merge or push, from a branch I don't practically, change things in master.. However, I see things now.. [...] This problem stems from having a wrong mental model about how branching work in Git. Consider reading this my lengthy reply [1] to someone with exactly the same problem. 1. http://www.mail-archive.com/git-users@googlegroups.com/msg03448.html -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Can't restore from stash
On Sun, 3 Mar 2013 15:16:46 -0800 (PST) Tom Green tomgreen1...@gmail.com wrote: I did a GIT STASH (working in Windows command line). Now I can't restore from it I get the message: TECHNOTE/git.TXT: needs merge unable to refresh index [...] Thanks again, and for some reason -- not sure exactly what did it -- the files are back in my working directory. So my problem is resolved, but I would still like to understand. Anyhow, the urgency is gone. You're right, I'm new to GIT, so I'm not offended by anything. I did a GIT STATUS and saw the same file as unmerged. It said that I needed to resolve conflicts, but I didn't understand how to do that. I'm not sure if this did it, but I edit the file and removed the lines with Updated upstream and Stashed changes and saved it. Okay, that Stashed changes line provides the necessary clue so I think I'm able to reconstruct what have happened. Application of a stash record might result in conflicts. This is to be expected: if you have checked out some commit A (usually this is a tip of a branch), did some local changes on top of it, stashed them, then checked out some other commit B and then attempted to apply the stash record made against the files of that commit A, the `git stash` machinery will have to apply the stashed changes to a different set of files with their contents quite possibly different compared to the set of files of that commit A, against which the stashed changes have been recorded. By now you could probably see that if both the commit B and your stashed changes changed the same piece(s) of a file as recorded in the commit A, an attempt to apply those stashed changes to that file as recorded in the commit B will result in a conflict. Note that bringing the commit B into the work tree might not necessarely result from checking out another branch or something like this -- you might as well just record a number of commits on top of that base commit A, moving the tip of the current branch forward. So that is what most probably have happened. You stashed your local changes, checked out some other branch or recorded a number of commits (thus moving the current branch forward) then applied the stashed changes which *did* work but resulted in conflicts. Since you are seemingly not familiar with merging conflicts and their resolution, you ignored the message from `git stash` about conflicts. The next time you tried to apply the same stash record `git stash` noticed you had merge conflicts in the index and refused to proceed without even trying. Now let's debunk how merge conflicts are handled by Git... - Does GIT look for the markers in the file to see if I resolved the conflict? - Or does it somehow check the file date? No to both questions. It's actually simpler. When Git detects a conflict while merging a file, it records this fact in the index entry for that particular file. This special kind of entry actually refers to the versions of both sides of merging, known as ours and theirs -- referring to the base version of the file and its version which was attempted to be merged. (This, by the way, allows to easily replace the contents of a file with conflicts in the work tree using `git checkout --ours -- filename` and `git checkout --theirs ...`, respectively.) Git also replaces each conflicting chunk in the file with the chunks from the both sides of the merge, and decorates them with the conflict markers. To resolve conflicts for a file, you must do two things, in this order: 1) Actually resolve the conflicts. This either means fixing the file, replacing each conflicting part with the correct text (obviously, the conflict markers should be removed as well) or just overwriting the file with the version beleived to be correct (see above). 2) Stage the updated content of the file for the next commit by just `git add`-ing it. This simply replaces the special in conflict index entry for that file with a normal entry. Repeat for each file with conflicts until `git status` shows you that everything is okay. Of course, not having formal conflicts in the index does not mean your data is correct. I mean, after resolving merge conflicts you might have to ensure the state of your code is sensible (by running a test suite or similar means). [...] Also, another stupid question: - Does the term INDEX refer to what GIT-GUI calls STAGED CHANGES? Yes. The term staging area is used to refer to the index as this is the place where the changes are staged for the next commit. Note that the cache was another (earlier) term used to refer to the index. The remnants of this might be seen in some git commands, like `git diff --cached` to see the diff between the HEAD and the index and `git rm --cached` for removing entries from the index and not from the work tree etc. The top of my tree (from GITK) looked roughly like this. * Local uncommitted changes * STASH * Saving GIT.TXT so I can
Re: [git-users] Can I delete origin/HEAD origin/master to start new repo?
On Mon, 4 Mar 2013 08:01:40 -0800 (PST) banaca...@gmail.com wrote: I have a clone of a local repo that has so many significant updates that it really needs to be a major release. I'm thinking that it should be new repo, so I want to disconnect it from the old repo. What is the best way to handle this? Should I (can I) delete the origin/HEAD origin/master? What about the clone pointer in the original repo? $ git remote remove origin Should make your repository has no traces of what was your origin remote. You could also just rename origin to something else and add another remote named origin in its place -- the name origin is really nothing special, it's just the name `git clone` uses by default. What I do not get though is why you think it's a good idea to create a disconnected repo for a new release. This is not Mercurial with its one directory per checkout paradigm. No matter how many commits you did in your clone, you can push them all to the origin with little to no effort. So could you please provide more background for your use case? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Can I delete origin/HEAD origin/master to start new repo?
Being a newbie (despite being 60), I may not entirely understand what you want. But if you're saying that you've got a working directory and you want it to not refer to the repo from which it was cloned, but a new bare repo, then you can do this rather easily. The simplest may be something like: # # go to where the stuff I want in the new repo is cd ~/existing-working-directory # # create a new bare repo by using ssh to login to # the remote site. Or use some other method, such # as will github. ssh user@remote #start up a shell at the remote site git init --bare --shared /the/new/git/repo/subdir/repo.git exit # leave remote site, returning to local site # # push everything up to the new bare repo git push --all ssh://user@remote/the/new/git/repo/subdir/repo.git # everything is now in the new repo # # remote the old origin and point to the newly # created one. git remote rm origin # remove pointer to old bare repo # # -t master assumes that master is the branch we want to track git remote add -t master ssh://user@remote/the/new/git/repo/subdir/repo.git # I don't know about that last thing: the clone pointer in the original repo. As far as I know, git does not remember or have any pointer to who did a clone against this repo. I.e. there is no tracking from the bare repository to the person who may have cloned it. There is a pointer in the cloned .git to where it came from. Which the above alters. On Mon, Mar 4, 2013 at 10:01 AM, banaca...@gmail.com wrote: I have a clone of a local repo that has so many significant updates that it really needs to be a major release. I'm thinking that it should be new repo, so I want to disconnect it from the old repo. What is the best way to handle this? Should I (can I) delete the origin/HEAD origin/master? What about the clone pointer in the original repo? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Can I delete origin/HEAD origin/master to start new repo?
Hi Konstantin, Thanks for the info. It's not that I can't push the commits, but that I don't want to push the commits upstream. So many of the changes made to the clone require significant structural changes to databases, etc. that it is incompatible with older implementations. There is no need to upgrade clients who are happily using the previous version, but I want to maintain the older version in a separate development track while starting a new development track for the new version. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Empty directories with submodules
I added a few submodules to my project (I already had some and needed a few others) at home and then I tried ran a pull request at work. The only thing that happened is that it re-created empty directories with submodules. git pull git submodule status some sha1 value bundle/FuzzyFinder some sha1 value bundle/L9 some sha1 value bundle/vim-pathogen some sha1 value bundle/vim-powerline some sha1 value bundle/vim-project All of those directories were empty. I tried running git submodule update But nothing happened. Those directories stayed empty. Can anyone explain why those submodules were not cloned? I had to run git sumodule init git submodule update Only after that I got all my sumodules. Do I have to run git submodule init every time I add a new one? My understanding was is that I have to run git submodule update. Does anybody know what is the issue? Any help is appreciated. I'm running Windows XP Pro Version 2002 SP 3 git 1.8.0.msysgit.0 -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] warning: Not setting branch master as its own upstream.
Both --track and --set-upstream-to operates on the current branch. The thing you need is: --track origin/master or --set-upstream-to=origin/master Gergely On 4 March 2013 18:21, FlashBurn rail.shafigu...@gmail.com wrote: I committed some changes to my repository at home and then I tried to pull them at my work and I got the following message There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull remote branch If you wish to set tracking information for this branch you can do so with: git branch --set-upstream master origin/master Naturally I tried to run git branch --set-upstream master origin/master And here is what I got when I ran it The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to Branch master set up to track remote branch master from origin. Since this option will be removed I decided to it the modern way using --track. Here is what I got after running git branch --track master fatal: A branch named 'master' already exists. After this error I decided to use --set-upstream-to option. Here is what I got after running git branch --set-upstream-to=master warning: Not setting branch master as its own upstream. Then I ran git pull and everything worked. I suspect it worked because of --set-upstream deprecated. Can someone explain what have I done wrong with --track and --set-upstream-to options? Any help is appreciated. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] warning: Not setting branch master as its own upstream.
On Monday, March 4, 2013 2:09:00 PM UTC-5, Gergely Polonkai wrote: Both --track and --set-upstream-to operates on the current branch. The thing you need is: --track origin/master or --set-upstream-to=origin/master Gergely On 4 March 2013 18:21, FlashBurn rail.sh...@gmail.com javascript:wrote: I committed some changes to my repository at home and then I tried to pull them at my work and I got the following message There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull remote branch If you wish to set tracking information for this branch you can do so with: git branch --set-upstream master origin/master Naturally I tried to run git branch --set-upstream master origin/master And here is what I got when I ran it The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to Branch master set up to track remote branch master from origin. Since this option will be removed I decided to it the modern way using --track. Here is what I got after running git branch --track master fatal: A branch named 'master' already exists. After this error I decided to use --set-upstream-to option. Here is what I got after running git branch --set-upstream-to=master warning: Not setting branch master as its own upstream. Then I ran git pull and everything worked. I suspect it worked because of --set-upstream deprecated. Can someone explain what have I done wrong with --track and --set-upstream-to options? Any help is appreciated. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. Thanks it worked. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Can I delete origin/HEAD origin/master to start new repo?
One technique, which is a bit of a hack, is to first checkout the branch/commit that you want to be your start point, and then copy the whole directory to a new directory. Then delete the .git subdirectory leaving you with a new clean folder that isn't yet a git repo at all. (or you could do a checkout to a work_dir path) Now you can do the git init and build up your new repo fom there. The other option is to use `git checkout --orphan` to start a new branch which is disconnected from the rest of the commit history, but is still part of the same repo. You can even temporarily make it look connected again with a git grafts file (see my question http://stackoverflow.com/q/6800692/717355) (rename the grafts file to make the apparent link disappear) In this case you have one repo but two disconnected lines of development. Philip - Original Message - From: banaca...@gmail.com To: git-users@googlegroups.com Sent: Monday, March 04, 2013 4:01 PM Subject: [git-users] Can I delete origin/HEAD origin/master to start new repo? I have a clone of a local repo that has so many significant updates that it really needs to be a major release. I'm thinking that it should be new repo, so I want to disconnect it from the old repo. What is the best way to handle this? Should I (can I) delete the origin/HEAD origin/master? What about the clone pointer in the original repo? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2899 / Virus Database: 2641/6144 - Release Date: 03/03/13 -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] not clear about submodules
I'm not very clear on submodules. I did look at the Online git book, http://git-scm.com/book/ch6-6.html, but I'm still somewhat confused. From this chapter I understood that if I want one project to include another, I use submodules. But here is where I'm clear. Say I have the following directory structure myproject (regular git project) | |-some other project 1 (as a git submodule) |-some other project 2 (as a git submodule) 1) Say both project1 and project2 are being developed. However when I clone or pull myproject I don't want the latest version of project 1 and project 2. I want them at the state when I created them as submodules. Do I need to git add myproject/project1 myproject/project2 ? 2) What do I need to do I do want the latest revisions of project1 and project2 when myproject is clonded or pulled? Any help is appreciated. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] basic queries on branching merging in Git
the failed auto merge happens because you modify the same file on both that saved in the stash and in b2 which you merge prior to popping the stash. When git want to apply changes that recorded in the stash, git found that the file has changed since the last time you do a git stash so git can't apply the changes cleanly thus the failed auto merge. In that case after doing 'git stash pop' you just need to resolve the conflict, doing 'git status' will tell you which files that has conflict in them and then you just need to decide which changes are the 'correct' one. Git make this easier for you by marking the conflicted part with '' and ''. After you've done with the conflicted files just save them and do a 'git stash drop' to remove the merged stash and you'll be green again. On Mar 4, 2013 11:37 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Mon, 4 Mar 2013 06:59:56 -0800 (PST) Surya kasturisu...@gmail.com wrote: [...] For testing, I took 1 single file. created a branch b1.. edited it. Instead of staging, I stashed... then checked out master then created b2 branch edited the file again (different data).. this time, staged- did commit.. checked out master, and merged branch b2. Now, I went back to b1. did stash pop now I see Auto-merging conflict Impossible. You must have had some other changes on b1 compared to its state at the time of recording that stash record. A stash entry contains changes relative to the base version which was checked out at the time you recorded that entry (in other words, what HEAD pointed to at the moment). So when you apply these changes to *the same* base version, they are guaranteed to apply cleanly. So supposedly you updated b1 as well after recording your stash or did something like this. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Empty directories with submodules
Have you try do a 'git submodule update --init' ? On Mar 5, 2013 12:48 AM, FlashBurn rail.shafigu...@gmail.com wrote: I added a few submodules to my project (I already had some and needed a few others) at home and then I tried ran a pull request at work. The only thing that happened is that it re-created empty directories with submodules. git pull git submodule status some sha1 value bundle/FuzzyFinder some sha1 value bundle/L9 some sha1 value bundle/vim-pathogen some sha1 value bundle/vim-powerline some sha1 value bundle/vim-project All of those directories were empty. I tried running git submodule update But nothing happened. Those directories stayed empty. Can anyone explain why those submodules were not cloned? I had to run git sumodule init git submodule update Only after that I got all my sumodules. Do I have to run git submodule init every time I add a new one? My understanding was is that I have to run git submodule update. Does anybody know what is the issue? Any help is appreciated. I'm running Windows XP Pro Version 2002 SP 3 git 1.8.0.msysgit.0 -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
