Re: [git-users] prune during fetch, can I make it default for a remote?
On Wed, Aug 14, 2013 at 03:29:10PM -0700, Sam Roberts wrote: I don't see anything in the docs (other than a gui.pruneduringfetch). I'd be OK with a global default, I think I want this always, but a per/remote option for .git/config would be nice to. Have I missed this somewhere? I have the following in my ~/.gitconfig, which I think works the way you want ;) [alias] fetch = fetch -p /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay pgpmowy6ONVRT.pgp Description: PGP signature
Re: [git-users] Branch level authentication
On Thu, Aug 15, 2013 at 09:46:49PM -0700, Jimit Modi wrote: At our company, we are evaulating to migrate to GIT from SVN. Here we are following a process in which we have the following branch and access control. --- | Branch| Purpose | ACL | --- | `master` | live copy| AGM | --- | `staging` | staging copy | AGM, TL | --- | 'dev` | development copy | AGM, TL, Devs| --- Now all devs create a feature branch from the dev branch and again merge it in dev when they have finished working and push it. Now TL review the work and cherry pick or merge dev in staging, depending on the sencario. If everything is well they push the changes on staging. Same is done by AGM's for master branch. We want that devs will be able to pull the changes from staging and master branch, but will not be able to push. So the question is: - How can we setup a authentication system where only the allowed one will be able to push.? I gather you can write a hook that allows only certain users to push changes from `staging` to `master`. Most likely that sort of script can already be found in the wild somewhere. Here's another thought, albeit a wild and crazy one: trust that the developers understand rules and can follow them. Just tell them to never ever push anything from `staging` to `master`. If you want to you can monitor them for a while to convince yourself that they can follow that simple instruction and only if they completely fail can you start looking at authorization for pushing into certain branches (or consider whether you really want people around who can't follow such basic instructions ;-). Reasons for doing it this way: - It almost certainly will work from day one. - Git makes it easy to revert any failures to comply with the rule. - With this 'social solution' you can much more easily break the rule when the need arises. The day will come when you are facing a critical bug, that has to be pushed to `master`, but no-one authorized is available. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay pgpQLoZxRDOB5.pgp Description: PGP signature
Re: [git-users] Branch level authentication
Well the branches do not need to be on the same location/folder/computer. The devs could push to e.g. /cmdata/git/devs/myproject.git The tl pulls from devs and pushes to e.g. /cmdata/git/tl/myproject.git The agm pulls from tl and could push to e.g. /cmdata/git/agm/myproject.git You just configure your various sources apart from 'origin'. The folders you assign different user/group write permissions - so the write access is handled via OS. -- 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: git tree subfolder workflow
I do not think it's possible to only clone a part of a repo. That being said, I have not experimented with subtree nor submodule. Have you look into that yet? i've looked into submodule i don't think that's what i need. i need to look at subtree. btw, i tried cloning to local disk running git inside a cygwin, guess what i still see the same problem, atleast on nfs, 'git log' was fast, now even 'git log' takes too long, i'm not sure if cygwin is to blame here. thanks for your responses. On Sat, Aug 17, 2013 at 9:26 PM, Huu Da Tran huuda.t...@gmail.com wrote: I do not think it's possible to only clone a part of a repo. That being said, I have not experimented with subtree nor submodule. Have you look into that yet? Is there any way for you to access to repo from a remote host, but not mounted nfs? Seems like a flaw in network design. One hour is not the long if you let run over night (my experience took over 35min without nfs). Is that nfs plus your network time from the server? If so, maybe you can get on that server and clone locally on the server so it is no more nfs. Then from your local machine, clone your cloned? Unfortunately, I can only offer potential workaround. I have no experience to say that when pushing back to the nfs repo would be any faster if you could clone only a directory. Hope that helps a little. HD. -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/C7xeO8r97Yo/unsubscribe. To unsubscribe from this group and all its topics, 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] How do I remove a file from all branches in a git repository but leave it on the file system
From: joeriel...@gmail.com At some point I added a large file into a git repository. It now exists on multiple branches, possibly with some changes to it. I'd like to remove it from git, but leave its current form (say the one on the master branch) on the file system. You've figured out how to remove it from the repository. To keep a copy around, I would extract it explicitly with git cat-file and put it somewhere outside of the working copy before doing git filter-branch. 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] How do I remove a file from all branches in a git repository but leave it on the file system
If it is still in the working directory, why not rename it (using OS commands, not git command), do the git command to remove all traces as previously mentioned, then rename it back? On Mon, Aug 19, 2013 at 12:38 PM, Dale R. Worley wor...@alum.mit.eduwrote: From: joeriel...@gmail.com At some point I added a large file into a git repository. It now exists on multiple branches, possibly with some changes to it. I'd like to remove it from git, but leave its current form (say the one on the master branch) on the file system. You've figured out how to remove it from the repository. To keep a copy around, I would extract it explicitly with git cat-file and put it somewhere outside of the working copy before doing git filter-branch. 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. -- As of next week, passwords will be entered in Morse code. 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] How do I remove a file from all branches in a git repository but leave it on the file system
On Mon, 19 Aug 2013 10:04:33 -0700 (PDT) joeriel...@gmail.com wrote: At some point I added a large file into a git repository. It now exists on multiple branches, possibly with some changes to it. I'd like to remove it from git, but leave its current form (say the one on the master branch) on the file system. I tried (on a dummy git archive) git filter-branch --index-filter 'git rm --cached --ignore-unmatch bigfile' master branch1 branch2 That, however, does not leave a copy of bigfile on the file system. It isn't clear to me why not, though the description of the --tree-filter option to filter-branch (I'm using the --index-filter option, but is is similar) states: (new files are auto-added, disappeared files are auto-removed ... ). Is there a direct way to do what I want, with git? I've found similar requests; none of the responses point out that the above command actually deletes the file from the file system. I'm with Dale on this issue, but why do you consistently mention file system? If you want `git filter-branch` to keep your file on your file system, just copy it yourself from the project's work tree somewhere else, and after filtering your branches, move it back to the work tree, then make it a part of a commit on the relevant branch. What's the problem? If you wonder why the file disappears from the work tree during the filtering process, my take on it is that 1) the work tree is used as a scratch space during the filtering, and 2) the work tree (normally) contains the same state HEAD does, so if filtering deleted the file from HEAD it's logical the work tree does not contain it as well. -- 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] How do I remove a file from all branches in a git repository but leave it on the file system
On Monday, August 19, 2013 10:53:34 AM UTC-7, Konstantin Khomoutov wrote: On Mon, 19 Aug 2013 10:04:33 -0700 (PDT) joeri...@gmail.com javascript: wrote: At some point I added a large file into a git repository. It now exists on multiple branches, possibly with some changes to it. I'd like to remove it from git, but leave its current form (say the one on the master branch) on the file system. I tried (on a dummy git archive) git filter-branch --index-filter 'git rm --cached --ignore-unmatch bigfile' master branch1 branch2 That, however, does not leave a copy of bigfile on the file system. It isn't clear to me why not, though the description of the --tree-filter option to filter-branch (I'm using the --index-filter option, but is is similar) states: (new files are auto-added, disappeared files are auto-removed ... ). Is there a direct way to do what I want, with git? I've found similar requests; none of the responses point out that the above command actually deletes the file from the file system. I'm with Dale on this issue, but why do you consistently mention file system? If you want `git filter-branch` to keep your file on your file system, just copy it yourself from the project's work tree somewhere else, and after filtering your branches, move it back to the work tree, then make it a part of a commit on the relevant branch. What's the problem? If you wonder why the file disappears from the work tree during the filtering process, my take on it is that 1) the work tree is used as a scratch space during the filtering, and 2) the work tree (normally) contains the same state HEAD does, so if filtering deleted the file from HEAD it's logical the work tree does not contain it as well. I wonder because git rm --cached bigfile does *not* remove the file from the working directory. It's not clear, then, why the file is removed in the filter-branch call. What is the point of passing --cached to the call to git rm in the --index-filter command? Is it merely for efficiency? It seems to have the same effect without it. That is not the case when using git rm alone: git rm bigfile removes the file from working directory as well as the index. -- 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] How do I remove a file from all branches in a git repository but leave it on the file system
That seems the simplest approach. Thanks. On Monday, August 19, 2013 10:48:59 AM UTC-7, John McKown wrote: If it is still in the working directory, why not rename it (using OS commands, not git command), do the git command to remove all traces as previously mentioned, then rename it back? On Mon, Aug 19, 2013 at 12:38 PM, Dale R. Worley wor...@alum.mit.edujavascript: wrote: From: joeri...@gmail.com javascript: At some point I added a large file into a git repository. It now exists on multiple branches, possibly with some changes to it. I'd like to remove it from git, but leave its current form (say the one on the master branch) on the file system. You've figured out how to remove it from the repository. To keep a copy around, I would extract it explicitly with git cat-file and put it somewhere outside of the working copy before doing git filter-branch. 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+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- As of next week, passwords will be entered in Morse code. 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] Strange effect when tar-ing a cloned repository
From: peter boudewijns ing...@gmail.com I've been trying to put my filesystem for a very small busybox-based distro into a git-repository. And with succes. The only strange thing I can not get my head around is the following : When making a compressed tarball from the files from the repository (after clone/checkout) I get a very much larger tar.gz-file. Size goes up from 16M to 21M (!?) Has anyone got a clue ? My guess is that the cloned repository isn't compressed in exactly the same way as the original repository. The first step would be to find out the amount of disk space occupied by the original and the cloned repositories (using du -s) rather than depending on the size of the .tar files. If you want the repository to be small, look into git gc --aggressive. Dale Dale Worley -- Today is: 12.19.16.17.0 9 Ahaw 18 Mak Only 1100 more shopping days until the end of the World. -- 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] Strange effect when tar-ing a cloned repository
- Original Message - From: peter boudewijns To: git-users@googlegroups.com Sent: Monday, August 19, 2013 8:10 PM Subject: [git-users] Strange effect when tar-ing a cloned repository Hi All, I've been trying to put my filesystem for a very small busybox-based distro into a git-repository. And with succes. The only strange thing I can not get my head around is the following : When making a compressed tarball from the files from the repository (after clone/checkout) I get a very much larger tar.gz-file. Size goes up from 16M to 21M (!?) Has anyone got a clue ? Thanks PeTer The usual reason is that you 'forgot' that the git repo itself is inside the hidden directory .git at the top level. So you have both your working tree of regular files, and then you have the hidden repo storage - so you have everything twice, and the history as well! Have a look at the 'git archive' command if you want just your your work tree, without the whole repo history. Philip -- 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] How to diagnose a failing test
I've made a small change to the Git source and now test t/t1001-read-tree-m-2way.sh fails. In particular, this test fails: test_expect_success \ '4 - carry forward local addition.' \ 'bash -x 2/tmp/2 -c rm -f .git/index read_tree_must_succeed $treeH git checkout-index -u -f -q -a git update-index --add yomin read_tree_twoway $treeH $treeM git ls-files --stage 4.out test_must_fail git diff --no-index M.out 4.out 4diff.out compare_change 4diff.out expected check_cache_at yomin clean' How do I get detailed information on exactly what the failure is? I expect that there are two methods. One is that there is some manner of executing the test that causes it to produce copious information on what the various commands are doing. The other is how to manually simulate the test execution environment and then enter each command in sequence by hand. Unfortunately, I don't know how to do either. 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.
[git-users] Git to display stashed changes presence in git-status?
Hello, Can git display presence of stashed changes in the repository in the output of git-status? If the answer is no, do you think it would be a welcome addition? The story: today I was quite puzzled to see a change I remember doing some time ago has been lost and not to be found on any branch of my repo. After scratching my head for quite a while and when I was nearly ready to start writing it again, I looked in the stashed changes and, bingo! it was there. Phe-e-ew. I figure it could save me some nerve if git would just give me a hint in the git-status, like so: # On branch master # You have stashed changes # ... The output of git-status is really verbose already (and quite helpful for beginners will all these use this command to do this, use that command to do that, etc.,) so I figure adding this won't hurt anyone and will remind to deal with the temp uncommitted changes timely before they get lost. -- Alex -- 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] Strange effect when tar-ing a cloned repository
On 19 August 2013 21:10, peter boudewijns ing...@gmail.com wrote: Hi All, [...] When making a compressed tarball from the files from the repository (after clone/checkout) I get a very much larger tar.gz-file. Size goes up from 16M to 21M (!?) Not so strange. git is very good at compressing. One my of bare git repository is 32M but a tar.gz file of all files excluding the .git directory is 92M. /Martin -- 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] How to diagnose a failing test
- Original Message - From: Dale R. Worley wor...@alum.mit.edu I've made a small change to the Git source and now test t/t1001-read-tree-m-2way.sh fails. In particular, this test fails: test_expect_success \ '4 - carry forward local addition.' \ 'bash -x 2/tmp/2 -c rm -f .git/index read_tree_must_succeed $treeH git checkout-index -u -f -q -a git update-index --add yomin read_tree_twoway $treeH $treeM git ls-files --stage 4.out test_must_fail git diff --no-index M.out 4.out 4diff.out compare_change 4diff.out expected check_cache_at yomin clean' How do I get detailed information on exactly what the failure is? Dale, I presume you've read \git\t\README which has a lot of stuff about testing. My limited attempts simply used various echo commands liberally interspersed with the code. (plus close reading of the code - a technique from history ;-) I expect that there are two methods. One is that there is some manner of executing the test that causes it to produce copious information on what the various commands are doing. The other is how to manually simulate the test execution environment and then enter each command in sequence by hand. Unfortunately, I don't know how to do either. Dale -- Philip -- 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] Re: Git to display stashed changes presence in git-status?
On Monday, August 19, 2013 10:51:26 PM UTC+2, Alex Shulgin wrote: Hello, Can git display presence of stashed changes in the repository in the output of git-status? If the answer is no, do you think it would be a welcome addition? The story: today I was quite puzzled to see a change I remember doing some time ago has been lost and not to be found on any branch of my repo. After scratching my head for quite a while and when I was nearly ready to start writing it again, I looked in the stashed changes and, bingo! it was there. Phe-e-ew. I figure it could save me some nerve if git would just give me a hint in the git-status, like so: # On branch master # You have stashed changes # ... The output of git-status is really verbose already (and quite helpful for beginners will all these use this command to do this, use that command to do that, etc.,) so I figure adding this won't hurt anyone and will remind to deal with the temp uncommitted changes timely before they get lost. -- I think it's an interesting idea. I probably wouldn't change the default behavior for legacy reasons, but it could be configured. For the idea to be considered properly, bring it up on the Git dev listhttps://gist.github.com/tfnico/4441562. In the mean time, you can get what you need by using an alias: git config --global alias.st '!git status git stash list' -- 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.
