Re: [git-users] multi workspace solution
Thanks, it looks promising (although it is quite old) Does anyone know about its restrictions, or does anyone have experiences with it? Thanks Andras On Thursday, October 3, 2013 11:48:39 AM UTC+2, Konstantin Khomoutov wrote: On Thu, 3 Oct 2013 01:28:03 -0700 (PDT) pof Andras porj...@gmail.com javascript: wrote: I would like to implement a multi-workspace version of git. The main goal is to have several independent workspaces using only one and single repository (without their own cloned repos). All these things will run on one host, or probably will be located on nfs and will be available on more hosts. Yes, I know there should be some restrictions, for example push and pull will work on the repo (probably there can be something like my-push). Branches will be somehow tied to the workspaces, also all workspaces will have its own HEAD. I would like to discuss here how can it be implemented, what will (or will not) work. That was implemented long time ago in the form of the git-new-workdir script available in the contrib Git subdirectory [1]. The basic idea this Unix shell script implements is to create a separate directory with .git subdirectory in it which links to the real one *but* leaving intact things like HEAD which are purely local. This allows to have any number of separate checkouts of different branches, all referring to a single repository. Note that this script won't work on Windows as it makes use of symlinks which doesn't play together well with Windows. 1. https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir -- 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] moving top of branch to another repository
Hi Konstatin, thanks to you mentioning git filter-branch I found out it is possible to have two seperated trees in a repository. Your reply was not in this thread, so I include in at the bottom of this reply. This is what I succesfully tried in another repo: - in that repo I had a branch only containing new files, my goal is to have a repo with only the commits and files that were introduced where the branch started. - a problem was formed by the files of the main project that I don't need anymore. You explained that they come to live after rebasing again unless some measures are taken. I tried *git filter-branch* and found a new tree in the repository. That gave me an idea. After some reading of documentation I came up with this: - I made a completely new commit, apart from the existing tree with 'git commit --orphan new' - in commit new I removed all files with git rm -r - made a branch with git branch x - rebased the commits I needed onto (empty branch) x with git rebase --onto x start_branch^ head_branch - leaving me in exactly the situation I wanted (apart from the x-commit, which I can squash with the first commit of the rebased branch). The branch now only contained the files that where introduced by it, not the unrelated files in the main tree. Konstatin, thanks for the help and the inspiration. The sun is shining again! Ruud Konstatin wrote: *Yes, basically in the rebase script presented to you by `git rebase` you change the action for A to edit (and change its title when prompted), then change the actions for B-E to fixup and then leave the actions for F-G as pick. The result would be E' created of A (with modified title) plus B-E squashed into it and F-G picked on top of that E'. But note that you mentioned A contains lots of unwanted files. It wasn't obvious to me you wanted to get rid of some files and not just squash several commits into one. It might turn out that you might want to make delete the action for A and adjust the actions for B-E accordingly. Also note that if a file you intend to delete from A has been modified in any of commits B-G, a mere deletion of A during the rebase operation would not be enough: the file deleted by wiping off A would be magically brought to life in the nearest commit in which a changed state of that file has been recorded. So you might consider first running `git filter-branch` on your branch-to-be-extracted to actually get rid of all the unwanted files through the whole range of the branch's commits.* -- 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] multi workspace solution
On Fri, 4 Oct 2013 01:24:32 -0700 (PDT) pof Andras porje...@gmail.com wrote: [...] I would like to implement a multi-workspace version of git. [...] That was implemented long time ago in the form of the git-new-workdir script available in the contrib Git subdirectory [1]. The basic idea this Unix shell script implements is to create a separate directory with .git subdirectory in it which links to the real one *but* leaving intact things like HEAD which are purely local. This allows to have any number of separate checkouts of different branches, all referring to a single repository. Note that this script won't work on Windows as it makes use of symlinks which doesn't play together well with Windows. 1. https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir Thanks, it looks promising (although it is quite old) What do you mean by old? It's a simple script which just creates a couple of directories and a number of symlinks; the format of Git database and metadata directory did not change for ages so why change this script if it works? Note that the script does not do any magic, and you can do what it does using nothing more than Git plumbing tools and Unix core utilities. Does anyone know about its restrictions, Windows, as explained above. But support for symlinks did not exist even in Git for Windows proper due to the same reasons, so I don't think much can be done for this short of writing a specialized (C) Windows program which would mimic the behaviour of this script and would require elevation of privileges in the manifest file built into the resulting executable. -- 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] Using filter-branch without messing up the working copy
I'm working on using git filter-branch to remove the history of a large file from my repository so as to reduce the size of the repository. Generally, this pattern seems to be a correct way to do this: 1. git filter-branch --index-filter 'git rm --cached --ignore-unmatch core.4563' HEAD 2. edit .git/packed-refs to remove the line [hash] refs/original/refs/heads/master (so that there is no reference to the old HEAD) 3. git gc --quiet --aggressive (to remove the space used by the big file, which is no longer referenced) 4. git reset -q HEAD (to ensure that the index matches HEAD) The difficulty I am having is that I do not want to disturb the working copy while doing this. The working copy is my entire home directory, because I am using the repository as a historical backup system for my home directory. Currently, Git will not execute filter-branch if there are unstaged changes in the working copy, despite the fact that git filter-branch --index-filter does not touch the working copy itself. (In this case, the file to be deleted, core.4563, is not now in the working copy, so the filtering would not affect the working copy at all.) A further difficulty is that the repository is remote, the .git directory is not in my home directory, and core.worktree is /home/worley. If the current directory is the parent of .git, git filter-branch complains You need to run this command from the toplevel of the working tree. This is peculiar, because other Git commands (e.g., git commit and git add) work correctly when the current directory is the parent of the .git of a remote repository. (After all, core.worktree tells where the working copy is.) The best set of steps I have found that accomplishes my goals is to (1) disconnect the repository from the working copy by removing the core.worktree value, (2) use git checkout -q -f master to create in the repository's location an entire copy of my home directory, (3) perform the above filtering steps, (4) reconnect the repository by adding the core.worktree value, and (5) deleting the temporary working copy files. Surely there is a better way than this. It appears to me that two validity checks should be relaxed: (1) git filter-branch should work when run from the parent of .git of a remote repository. (2) git filter-branch --index-filter should check that the index is clean, but not the working copy files. 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] Integrating a previously split sub-directory back into the same initial repository
Hi All, Apologies if this was asked somewhere else but my colleague and I haven't been able to find any mention of a situation like this before. Context: 1. We started in CVS with a Main Repository A and within it, a subdirectory B 2. We migrated to GIT and preserved all history - we have Main Repository A, and pulled out subdirectory B into it's own repository. A and B are now two entirely separate repositories. Question: Is there a way to bring B back into Main Repository A and preserve all history (for both)? A and B have now progressed a bit, otherwise we would just scrap the whole thing and do the migration over again. Note: There are plenty of links and info on combining repositories, but we've not seen any regarding combining two repositroies that were once one. Thanks very much, -Eric -- 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: git5 submit bypassing tap
those may or may not be names of internal google tools On Sat, Sep 21, 2013 at 5:08 PM, Thomas Ferris Nicolaisen tfn...@gmail.comwrote: On Friday, September 20, 2013 11:34:14 AM UTC+2, Rajnish Kumar wrote: Hi, Just tried submitting a CL using TAP, which ran 422 test cases and had 7 failures. These failures have been verified to be caused by a recent change. Now I wish to submit the CL without going through TAP to avoid running these test once again. 'git5 submit' used to work earlier but it does not seem to work anymore. Is there any way to submit the CL without running the tests once again? I like to think of myself as a proficient Git user, but I didn't get a single one of those acronyms. What are you talking about? -- 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.
