Re: [git-users] git svn dcommit after git rebase
Simone (Oct03日（Wed）) Hello, I have a git local branch tracking a svn remote branch. I noticed that if I git rebase that branch onto another local branch (tracking a different svn remote branch) then the dcommit I do on the first goes to the remote of the second. IOW branches: *feature1-local* tracks remote svn *feature1*, *master* tracks remote *trunk* git checkout feature1-local git rebase feature1-local master git svn dcommit -- commits to *trunk* * * I would expect that dcommitting feature1-local would commit to feature1 svn remote branch rather than the trunk. git-svn dcommits to the branch that the closest parent commit which has been checked in is on[*]. You may have noticed that every commit which has been dcommited has some git-svn-id metadata attached to the commit message. git-svn steps back through the history until it finds a commit containing this line, and then uses it to determine the branch it belongs to. You can show which commit that is by executing the following: git show --first-parent HEAD --grep git-svn-id -1 If you have no commits in feature1 (on svn), then your commits on feature1-local (local commits, with no git-svn-id) will be reapplied on top of the current master, and tracing the commits back to the first one with a git-svn-id will indeed give you one on the master branch, pointing to trunk. If you do have commits in feature1, you have a rather bigger problem. In SVN, the tree looks like this, say: --A--B--C--D--E--F - trunk \ -G--H--I - feature1 But in git, it looks like this: --A--B--C--D--E--F- trunk \ -G--H--I - feature1 That is to say, commits D, E, and F exist on feature1 in git, and are BEFORE the feature commits G, H, and I. SVN has no way to rewrite history like that, so when you try to git svn dcommit it I'm actually not sure what it will do, but it won't be what you expect. I wrote on a similar subject on this list a week or so back -- I'm afraid Google's web interface messes up the diagrams a bit, but you can see the post here if you'd like: https://groups.google.com/forum/?hl=jafromgroups=#!topic/git-users/8h1xHsTqShE The gist of it is, you need to be aware of which commits are local to your git repository, and which have already been dcommitted to (or pulled from) the subversion server. For the latter set, you have to be careful about which git functionality you make use of, since subversion doesn't support all of it. In the above case, I don't think there's any way around doing a subversion-style merge from trunk to feature1 (you can do it in git, if you like, by merging master into feature1-local with the --squash option), and then again merging your changes from feature1 back into master when you're finished. Hope that helps, -- Dani. [*] Most of the time. I found myself in the situation the other day when it was *not* doing this, because I had done some weird archaeology to my commit tree which resulted in the closest parent commit's hash not matching what git-svn thought it should be. I had to hack the /usr/share/perl5/vendor_perl/Git/SVN.pm file to skip the hash check and perform the operation, after which it righted itself and I could remove the hack. I still don't understand this properly, but it shouldn't happen unless you're fiddling with git-svn's internals anyway. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/0E8qpgzFE04J. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] avoid pulling binaries
The SHA-1 hash which identifies each commit in git is generated from the state of the tree at that point and thus having a version of that commit with binaries and a version without results in -- as far as git is concerned -- entirely separate commits. It is really useful when the same commit maps to the same SHA-1 on everyone's copy of the repo, so in general I would say this is a bad idea. What I would possibly do in your situation is to have a separate, binaries-only repository. You could put it in a subdirectory of your main repo if you liked, and stop it spamming `git status` output by adding it to .git/info/excludes. Then, you could write a post-commit hook which could automatically commit the binaries into the binaries repo, perhaps inserting the commit hash on the main repository which that binary corresponds to in order to help you map them later on. There may be a better way around it, but that's probably how I'd go about it. -- Dani. Angelo Borsotti (Tue, Sep 25, 2012 at 02:11:14AM -0700) Suppose I have a private repository and a public one. I develop using my private repository, and at significant steps I do a commit in which I save all, sources] and binaries. The reason for saving binaries is to allow to recover a previously committed version without having then to rebuild all binaries. When I have completed the development of a feature, I push it to a public repository, one that is accessed by an integrator, that takes my contributes and other developers' as well, and integrates all of them. After having pulled all the contributed, the integrator always rebuilds the binaries. Therefore, there is no need for me to push binaries from my private repository to the public one, and for him to pull them. Is there a way in git to avoid to push and pull binaries in this workflow? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/txZDxAw_laEJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Checking out files into existing directory
Jeffery Brewer (Tue, Aug 07, 2012 at 11:54:16AM -0700) So here's my current problem. I'm trying to checkout (not sure if that's the right term or not) files from my repository into an existing folder (a Try to be careful with terminology. It's made more confusing by the fact that the same terms mean different things in different version control systems, but in git checkout means, Update files in the working tree to match the version in the index or the specified tree[1], where the specified tree is usually a commit or branch ID. Also, always bear in mind that in a DVCS like git *every clone* is a repository. So when you say my repository -- which repository do you mean? Do you mean a repository you've created on your local machine, a repository you've cloned locally, or some central repository on a server somewhere (say, github)? If it is a local repository, it would be usual for there already to be a working tree of the files checked out (unless you'd created a bare repository which you are unlikely to have done accidentally). folder created as a NetBeans project...something NetBeans recognizes as a project folder). Clone doesn't work...tells me there is existing content. Please describe what is the state of the repository and your working folders and what it is you are trying to achieve (what state you are trying to get them into). It sounds as if you have a set of source files in a repository on a server somewhere, and a folder locally-created by NetBeans with no source but some sort of project files which NetBeans uses. Assuming this is the case, here is one approach. In the following sequence of commands, $ represents the prompt, so shouldn't be copied. Anything without a $ represents the likely output, so obviously you don't copy that either. You should start in the parent folder of the netbeans project. Obviously you would need to replace the repository address with your own. Also I know nothing about NetBeans so I just pretended for the sake of example that your netbeans project folder contains a single file, project.netbeans. Hopefully all will become clear... $ ls netbeans_project $ git clone g...@github.com:username/project.git Cloning into 'project'... remote: Counting objects: 20, done. remote: Compressing objects: 100% (16/16), done. remote: Total 20 (delta 5), reused 19 (delta 4) Receiving objects: 100% (20/20), 16.21 KiB, done. Resolving deltas: 100% (5/5), done. $ ls netbeans_project project $ cp -rf netbeans_project/* project $ rm -rf netbeans_project $ cd project $ git status # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # project.netbeans nothing added to commit but untracked files present (use git add to track) $ git add . $ git commit -m Added NetBeans project files $ git push In the above sequence, I first clone the project into a local directory, outside of the netbeans_project directory. I then copy the entire contents of the netbeans_project directory into my local clone, and delete the old version. Changing into the project directory, I confirm the presence of the netbeans project file with git status. I then add and commit them as usual. Note that git add . will add all files in the current folder and all subfolders. You may want to be more selective about which files you add! Look at the output of git status and add only those files which you want in the repository. Also be very careful with rm -rf. This will delete all files in the directory specified and all subdirectories, without any kind of confirmation dialogue to make sure it's ok. When I deleted all the content and cloned it again, it put all the contents into a sub-folder. So I tried using fetch. When I fetched, it took a very long time and looked like it was doing work (it was showing me some kind of progress), but when it got all done the folder was empty. I tried this a couple of times and then tried pull, which did the same thing. At one point after a fetch I typed git status and got a long message saying all my files were deleted. Finally after searching around for clues decided to clone into a separate directory then copy and paste all the contents of that directory back over to my project directory. When describing problems like these, it is always better to provide a log of exactly the commands you typed and their output than to try and describe it in English. You can simply copy and paste the contents of your command prompt window. I guess my question is, how do I get my files out of the repository and into an existing folder on my computer? And why doesn't fetch or pull actually fetch or pull any files down from the repository? git fetch will fetch the contents of the remote repository into the local repository (remember your local clone is a full repository!), but will not merge those files with any of your local branches or check
Re: [git-users] Beginner stuck in a commit
Hello, Jeffery Brewer (Mon, Aug 06, 2012 at 07:57:13PM -0700) I've slowly been trying to get git to work and just running into loads of problems. Using the windows bash I just tried to do a commit this evening and forgot to add a message (e.g. -m my work for today) and sent the bash into some sort of odd editing mode that I can't seem to get out of. I finally just closed the bash and opened a new bash and tried to commit and got all kinds of error messages with a prompt to type (R) to recover. Typed R to recover and it took me right back into the strange editing mode that I can't seem to get out of now. I've backed up all the files in the directory (sensing an impending catastrophe) but not sure what else to do at this point to get git running again. Any help would be appreciated. The default editor for git is vim, which is a sensible choice as its available on nearly every platform, but if you've never encountered it before it can seem a little... unusual. A little more information on it is at the wiki page here: http://en.wikipedia.org/wiki/Vim_(text_editor) And an introduction to its use can be found here: http://blog.interlinked.org/tutorials/vim_tutorial.html (First hit on google; I haven't read it so can't vouch for its quality) The gist of it is: Press i to enter insert mode, which will let you type. Press esc to exit that mode. In normal mode (after pressing esc) type :wq to write your changes to file and quit. More detail... If I open a new bash in the directory and run git commit I'm getting this error message: E325: ATTENTION Found a swap file by the name .git\.COMMIT_EDITMSG.swp dated: Mon Aug 06 19:45:14 2012 file name: C:/Users/me/Documents/NetBeansProjects/foldername/.git/COMMIT_EDITMSG modified: YES user name: me host name: my computer process ID: 10368 While opening file .git\COMMIT_EDITMSG dated: Mon Aug 06 19:55:29 2012 NEWER than swap file! (1) Another program may be editing the same file. If this is the case, be careful not to end up with two different instances of the same file when making changes. Quit, or continue with caution. (2) An edit session for this file crashed. If this is the case, use :recover or vim -r .git\COMMIT_EDITMSG to recover the changes (see :help recovery). If you did this already, delete the swap file .git\.COMMIT_EDITMSG.swp to avoid this message. Swap file .git\.COMMIT_EDITMSG.swp already exists! -- More -- SPACE/d/j: screen/page/line down, b/u/k: up, q: quit These warnings are vim warnings and not git ones. They're telling you that vim ended unexpectedly (when you force-closed the window) while you were editing a file, so there's a backup you can recover. Clicking recover opens the backup so that you can edit it again. Having said all this, you can change the text editor using the following command-line: git config --global core.editor notepad Obviously changing notepad to something more sensible first(!) Vim is a very good editor and I recommend learning it. I believe the Cream distribution is popular with Windows people: http://en.wikipedia.org/wiki/Cream_(software) It is an entirely separate thing from git however, and there is an argument for learning the two tools separately, in which case perhaps changing the editor to something you're more comfortable with until you feel happy with git would be a good idea. Dani. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Sorry...need help installing on windows
Jeffery Brewer (Mon, Jul 23, 2012 at 03:24:46PM -0700) OK, so I've read about GIT, I took the free online course over at Code School, I spent more time reading about git, read the git book on the git website...I'm eager to try it out...I go to the Git website, download the windows installation, install, find a command prompt, type $ git config like it says in the booknothing. I'm getting '$' is not recognized as an internal or external command, operable program or batch file. The $ represents your prompt, so you shouldn't type it. Try git config instead. -Dani. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Apply merge rules from .gitattributes file to git rebase calls
Hello, I have been using custom merge rules based on an answer I found on stackoverflow[1] a while back, in order to merge certain filetypes automatically. This has worked well, however I now find myself using `git rebase` at least as frequently as I do `git merge`, and when I do so it appears these merge rules are not being followed -- I am asked to resolve merges in filetypes set in my .gitattributes file manually. Is there a way to make `git rebase` follow the merge strategy defined in my .gitattributes file? I have looked in the documentation for git rebase and gitattributes but didn't notice anything relating specifically to this issue -- perhaps I missed it. If anyone could help point me in the right direction it would be most appreciated. Many thanks, -dpw [1]: http://stackoverflow.com/questions/928646/how-do-i-tell-git-to-always-select-my-local-version-for-conflicted-merges-on-a-s -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
