Re: [git-users] multiple eclipse projects using single repository
Thanks. On Thursday, December 6, 2012 1:50:38 PM UTC-5, William Mizuta wrote: You need one .project for each eclipse project. So, you need diferent subdirectories for each one of your eclipse project. However, that's not a good solution. I recommend to create a git repository for each one of your eclipse projects. William Seiti Mizuta @williammizuta Desenvolvedor da Caelum On Thu, Dec 6, 2012 at 4:22 PM, Jeffrey Marans jma...@gmail.comjavascript: wrote: Can I create multiple eclipse projects using the same GIT repository without sub-repositories or the need to re-clone the repository each time? It seems that when one creates a project in eclipse it saves a .project file into the repository making it impossible to create another. -- --
[git-users] Re: multiple eclipse projects using single repository
Thanks, I think it's worth reading. On Thursday, December 6, 2012 2:30:04 PM UTC-5, John McKown wrote: I hesitate to mention this, but have you looked at submodules? It is, kind of, similar to what you seem to want. Each eclipse project is in its own subdirectory of the same parent. The parent is a superproject. From my reading, this is cutting edge in git. I.e. it is new and still changing. I am a bit uncomfortable mentioning it, but I don't believe in protecting people from themselves. Your foot, your bullet. http://git-scm.com/book/en/Git-Tools-Submodules On Thursday, December 6, 2012 12:22:58 PM UTC-6, Jeffrey Marans wrote: Can I create multiple eclipse projects using the same GIT repository without sub-repositories or the need to re-clone the repository each time? It seems that when one creates a project in eclipse it saves a .project file into the repository making it impossible to create another. --
Re: [git-users] GIT actions from bugzilla server to origin
I'll rephrase my issue without the extraneous bits. I've a bugzilla server from which I want to send branch manipulation commands to a remote central GIT repository server. The bugzilla/mysql database stored procedure that generates system commands is not the issue. I thought the only possible solution was to have a complete set of repositories local to the bugzilla server, as per your first suggestion. Thanks for pointing out a far more practical method. I thought that sending ssh commands to the GIT server would not work because there's no .git sub-directory and no working tree in each of the central repositories. But commands like 'ssh git@git cd /oacis/test; git branch -lf R73_2_bug R73' work just fine. Near as I can tell, you've now removed all the technical hurtles that prevented my migrating a couple of dozen CVS modules with history going back 15 years to GIT. I'm sure there are about 55 developers here who're going to way way happier once that's done. Regarding shell access, /usr/bin/git-shell is exactly what I need. Administrator accounts are different, as is root. Thanks again. Jeff. On Wednesday, December 5, 2012 6:37:56 AM UTC-5, Konstantin Khomoutov wrote: On Tue, 4 Dec 2012 10:43:32 -0800 (PST) Jeffrey Marans jma...@gmail.com javascript: wrote: I'm working on transitioning about 15 CVS modules to GIT repositories and I think I've got a handle on how to translate the cvs triggers to make them run on the git origin. I have to create triggers that run from the bugzilla server against the git origin server that will branch from either main or a release branch to a bug branch. This was difficult with svn, but quite doable without any SVN repositories local to the bugzilla server. I'm hoping to find out I've made a mistake thinking that isn't possible with GIT. Any ideas on that? Could you please try to re-explain your idea without mentioning Subversion and CVS completely? Do I understand you correctly that your bugzilla server is on a different machine from that one hosting a central Git repository (what you call the origin server), and you want actions done in bugzilla to modify the Git repository hosted on that another machine? If yes, then read ahead. In Subversion, the information about branches is only kept (and manipulated) on the server, and so the Subversion client naturally has commands to manipulate those branches on the server. Git client is only able to push and fetch history, updating the so-called references (local, when fetching and remote, when pushing) which is a generic name for branches and tags. As a special case, pushing also allows to delete references in remote repos. That's all the Git protocol is able to do when it comes to branch manipulation on the remote side. Hence, if you want to manipulate branches in a remote repository using nothing but a Git client, you could do this way: 1) Install a Git client on the bugzilla server. 2) `git clone --bare` the blessed repository from your Git origin server. 3) Each time you need to do something from a bugzilla trigger, a) Force-update the local repository doing something like git fetch origin '+refs/*:refs/*' This is needed for both servers to have identical ideas about how the blessed repo looks like. b) Do whatever manipulation is needed, locally. For instance, fork a branch off the required branch. c) Push this change to the origin. Say, if your script created a branch bug-12345, it has to do git push origin bug-12345 There might be another approach which people for some reason tend to overlook. If your Git origin server can be accessed via SSH, you can perform any sugrery on the remote repository using nothing but the SSH client on the bugzilla side as SSH is a *shell.* The scripting is done either by constructing a string to be passed to the `ssh` program as its last argument, or as a script (in a string, in a temporary file, in a here document or whatnot) which is then fed to the standard input of the `ssh` program. In either case, the script runs on the remote side, so it has to do certain setup (like `cd`ing to the Git repository) first and then perform the requested actions. Or it could just call a pre-made script on the remote side. The only tricky part in this approach is setting up automated SSH access. This setup usually employs authenticating using public keys (better) or supplying a password to the SSH client using something like `sshpass` or scripting the whole thing using Expect. --
Re: [git-users] GIT actions from bugzilla server to origin
The bugzilla server script is written in perl and I construct command strings of the form ssh $user@$host cd $dir; $cmd $options /dev/null 21 Then I use system($command); Thanks for the -e -u; minor nitpicks to you are useful groomings for the rest of us. It'll be my new prefix :) On Wednesday, December 5, 2012 10:13:44 AM UTC-5, Konstantin Khomoutov wrote: On Wed, 5 Dec 2012 05:10:30 -0800 (PST) Jeffrey Marans jma...@gmail.com javascript: wrote: I thought the only possible solution was to have a complete set of repositories local to the bugzilla server, as per your first suggestion. Thanks for pointing out a far more practical method. In fact, I suspect the first approach could be made less heavy-weight using shallow cloning so that each local clone keeps only a minimum amount of history since your requirements for branching seemingly do not require forking new branches off anything other but extsting branches, that is, history tips. But I have no experience with this kind of setup so can't really say if it would work or not. I thought that sending ssh commands to the GIT server would not work because there's no .git sub-directory and no working tree in each of the central repositories. But commands like 'ssh git@git cd /oacis/test; git branch -lf R73_2_bug R73' work just fine. That is correct. The SSH client has nothing to do with anything local. Using Git's SSH transport actually just employs the fact SSH provides both scripting *and* tunnelling, so, say, `git fetch` uses SSH to connect to the server, authenticate, and spawn `git-upload-pack` there; it then spawns `git-receive-pack` locally and then those two processes are made communicate with each other through their standard I/O streams which got connected via SSH. So it's the local Git process which actually accesses the Git repository data (under .git), not the SSH client, which knows nothing about Git. The same trick is routinely exploited by tools like rdiff-backup, which connects via SSH to the client, spawns `rsync` there and another `rsync` locally and then makes them communicate. One minor nitpick about your 'cd /oacis/test; git branch -lf R73_2_bug R73' script. The Unix shell is notorious for its strange approach to error handling: by default, if a command fails, nothing at all happens unless some other command cares to inspect the return code and do something if it's not zero or unless a compound command is created using '||' or ''. So, if, for instance, /oacis/test suddenly vanished for whatever reason or became inaccessible (say, someone messed up its permission/ownership data) your `cd` command will silently fail and the shell will happily continue with running the next command. So I would advise to always start your scripts with the `set -e -u` command, which switches the shell to the fail on any error and on access to an unset variable mode. This usually makes failures of shell scripts more sensible to understand and debug. --
[git-users] GIT actions from bugzilla server to origin
I'm working on transitioning about 15 CVS modules to GIT repositories and I think I've got a handle on how to translate the cvs triggers to make them run on the git origin. I have to create triggers that run from the bugzilla server against the git origin server that will branch from either main or a release branch to a bug branch. This was difficult with svn, but quite doable without any SVN repositories local to the bugzilla server. I'm hoping to find out I've made a mistake thinking that isn't possible with GIT. Any ideas on that? --
[git-users] Re: permanent branch deletion on origin
On Monday, November 26, 2012 10:06:35 AM UTC-5, Jeffrey Marans wrote: I've done a cvs2git conversion of a number of cvs modules and was unable to exclude the private working branches, PWB*. I'd like to delete them from the git repos and have tried the following, but the branches live on regardless of the output messages. By that I mean if I clone another instance of test, the branches still show up on the origin server. mkdir test cd test git clone git@git:/git/gitroot/oacis/test cd test git branch -r | grep PWB origin/PWB1 origin/PWB10 origin/PWB2 origin/PWB3 origin/PWB4 origin/PWB5 origin/PWB6 origin/PWB7 origin/PWB8 origin/PWB9 for i in `git branch -r | grep PWB`;do git branch -rD $i;done Deleted remote branch origin/PWB1 (was 4e34650). Deleted remote branch origin/PWB10 (was 2992912). Deleted remote branch origin/PWB2 (was b9126e8). Deleted remote branch origin/PWB3 (was e48d2d1). Deleted remote branch origin/PWB4 (was 32c90f3). Deleted remote branch origin/PWB5 (was 234f826). Deleted remote branch origin/PWB6 (was 72409ca). Deleted remote branch origin/PWB7 (was 234f826). Deleted remote branch origin/PWB8 (was e30b526). Deleted remote branch origin/PWB9 (was a8ab921). The for loop above is the only deletion method that seems to work, and that's just fine. The process here has been to merge to a PWB, solve the bug, then merge back to Main or a release branch. I think the logs will capture the merge back, so no worries about orphaned references. Thanks for the tips, you've saved me days, if not weeks, of searching. --
[git-users] permanent branch deletion on origin
I've done a cvs2git conversion of a number of cvs modules and was unable to exclude the private working branches, PWB*. I'd like to delete them from the git repos and have tried the following, but the branches live on regardless of the output messages. By that I mean if I clone another instance of test, the branches still show up on the origin server. mkdir test cd test git clone git@git:/git/gitroot/oacis/test cd test git branch -r | grep PWB origin/PWB1 origin/PWB10 origin/PWB2 origin/PWB3 origin/PWB4 origin/PWB5 origin/PWB6 origin/PWB7 origin/PWB8 origin/PWB9 for i in `git branch -r | grep PWB`;do git branch -rD $i;done Deleted remote branch origin/PWB1 (was 4e34650). Deleted remote branch origin/PWB10 (was 2992912). Deleted remote branch origin/PWB2 (was b9126e8). Deleted remote branch origin/PWB3 (was e48d2d1). Deleted remote branch origin/PWB4 (was 32c90f3). Deleted remote branch origin/PWB5 (was 234f826). Deleted remote branch origin/PWB6 (was 72409ca). Deleted remote branch origin/PWB7 (was 234f826). Deleted remote branch origin/PWB8 (was e30b526). Deleted remote branch origin/PWB9 (was a8ab921). --
[git-users] auto branching origin server
I'm working on converting 20 cvs modules into snv/git repositories in order to determine which is most appropriate for my client's needs. The module to repo conversion is going well because the cvs2svn/git tools work as documented. Thanks for that. I've been able to write some autobranch code that runs on our bugzilla server against the SVN repos and is triggered by a bugs table update. I'm at a loss how to accomplish the same results against the GIT origin. Any suggestions would be appreciated. Jeff. --
[git-users] Re: git commit not doing anything
Are you sure you don't for some reason have a hook which silently fails? Bizarre, but possible... On Sep 9, 8:57 am, David Doria daviddo...@gmail.com wrote: On Tue, Aug 31, 2010 at 11:28 AM, E.J. Hassick ehass...@gmail.com wrote: Is this just happening in a specific project of yours or in others too? It's happening again, this time in a different project! The way I fixed it last time was to just delete the local files and re-pull from the repo. Surely I am just doing something silly... any thoughts? David -- 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-us...@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] Re: Small mystery
A key note in git-fetch(1) is: A parameter ref without a colon is equivalent to ref: when pulling/fetching, so it merges ref into the current branch without storing the remote branch anywhere locally. That bit of the documentation seems a little off to me. There's no way that git fetch actually performs a merge. What it does is fetch the objects and update FETCH_HEAD to point to the fetched ref. -- 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-us...@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] Re: some questions about merge
Sounds like you want these two commands: git checkout --ours dir1 git checkout --theirs dir2 If branch A added some files in dir2 and branch B added some in dir1, and you want to get rid of those, you'd want to remove them first (perhaps even just remove the entire directories before doing the checkouts). Jeffrey On Mar 12, 1:47 pm, apm korja...@gmail.com wrote: I have two branch, very very long wasnt merged. And have alot of conflicts. Mostly conflicts CONFLICT (add/add). Is it possible (which git command? ) say use for this subdir left side, for other dir right side. for examle branchA -dir1 --a --b --c --f -dir2 --a --b --c --x branchB -dir1 --a --b --c --g -dir2 --a --b --c --z after merge branchB into branchA i have: both added: dir1/a i want forget about all files branchB/dir1 and revert my mergebranch to branchA/dir1, and the same but vice verca with dir2, i want have dir2 from branchB which command help me revert ? -- 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-us...@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] Re: User Restrictions....
You might want to do this in the form of requiring signed-off-by lines. That'd be a relatively easy thing to check for in an update hook; sure, they're a little easier to fake than authorship information, but they permanently record the information. On Jan 21, 5:14 pm, Jeffda daniel.viviot...@gmail.com wrote: Thanks for the replies/ideas. I think I'll stick with your idea, Jacob, unless someone has an even more secure solution that's simpler than creating a wrapper. Creating a wrapper is a good idea, I just don't know how to, and I don't have time to figure out how to create one. Thanks again. -- 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-us...@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] Re: Custom commit property?
This sounds like precisely the purpose of standard formats for log messages. The simplest thing would be to prefix the subject with [type]: like this: major: add big feature or put it on the first line of the body, if you have something else you like to do with the subject, whatever. As long as your format is standard, you can easily search for that particular key. Jeffrey On Jan 1, 11:59 am, Trans transf...@gmail.com wrote: Is there are way to add a custom property to commits? I want to use it to track commit type For example, I use 'admin', 'doc', 'major', 'minor', and 'bug' to classify my commits. Thanks. -- 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-us...@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] Re: unable to chdir or not a git archive
On Sep 22, 1:43 pm, erenay erenay...@gmail.com wrote: git remote show origin returned fatal: 'origin': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly On Sep 22, 2:59 pm, Michael P. Soulier msoul...@digitaltorque.ca wrote: On 22/09/09 erenay said: My crone url is like: g...@github.com:x/y.git I clone it by using git clone g...@github.com:x/y.git Works for me. Perhaps you should take it up with github. Does 'git remote' show a list including origin? If not, you have managed to lose the named remote 'origin' pointing to where you cloned from. If it is there, are you able to clone again using the same URL? If no, you've got a problem on the other end. If yes... look in .git/config for a section like this: [remote origin] url = ... fetch = +refs/heads/*:refs/remotes/origin/* and make sure the url is correct, fetch is set to that (or something else valid, if you know what you're doing), and there aren't any other bizarre settings in that section. Jeffrey --~--~-~--~~~---~--~~ 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] Re: git diff with external
For your specific question, I'm not sure there's a way. It's not something that could be solved with gitattributes, is it? That'd let you use external diff on a subset of files. Otherwise, I'd suggest just making some aliases, something like: df = diff --no-ext-diff dfe = diff --ext-diff Jeffrey On Sep 21, 2:56 am, Jeenu jee...@gmail.com wrote: Hi, I have a wrapper script whose name I've set to the diff.external configuration. But I tend to use the internal diff often but now have to pass the --no-ext-diff option every time I want to view a normal diff. Is there a way to have the --ext-diff as the default option, but still keeping the script's name in diff.external config? Thanks :J --~--~-~--~~~---~--~~ 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] Re: Copy files between local branches.
What's wrong with git checkout? git checkout tree-ish paths... it's the second usage on the man page. It does add to the index as well, but you can quickly reset them back (that git reset HEAD...) tip. Jeffrey --~--~-~--~~~---~--~~ 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] git-archive, selecting files by patterns
I would like to create an archive of a subset of the content tracked by my repository. Ruling out some options: - I'd really like to use git-archive, since it's far faster than manually using tar with a file list. I assume this is because git can read out of the repo, which is compressed and therefore requires less disk access. The repo in question is on an NFS mount, so disk access is especially expensive. - The subset is best specified by inclusive patterns (e.g. *.c, *.h), so gitattributes' export-ignore is not ideal. - git-archive can't read from stdin or from a file containing a list of files. The list of files desired is too long to use a solution like git archive master $(git ls-files *.c *.h) - I get an 'argument list is too long' error. Any suggestions? Something besides improving git-archive, hopefully. Thanks, Jeffrey --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
