[git-users] What is best practice to manage a set of repos?
I've just moved a monolithic svn repo to git, and divided it into multiple git repos, one per project. Generally, this is the structure I want. There is one project per repo and, while I do work on multiple projects in any given week, each check-in will be local to a single project. But, I sometimes will want to deal with the entire set as a whole, e.g., when moving my total history to a new machine. What's the best way to manage this? My first thought was git submodules. But, their doc suggests that they always point to an exact commit. For my purposes, I want to always point a the head of each ssubproject. So, I'm puzzled as to what is the best tool for me? git submodule with some flag? A simple script enumerating all the projects? Something else? Note: that a nice-to-have feature would be that any new project would be automatically added to the master list, or at least would make its absence noted. (E.g., if I used submodules, they'd each be in a subdirectory of the master list repo, so new projects would appear as untracked files). Thanks, David --
[git-users] Rebasing large commit-set including merges
Hi, I try to rebase our whole history (~1500 commits) onto a quite empty branch, only including a single commit (creating the base-directory - so there is nothing conflicting in there). I want to do this, because our project was developed on a git-repository but now we have to make our stuff available on a subversion-repository. So I created the target directory on subversion, added it with git svn init to my local git-repo and checked out a branch (git branch -b svn trunk). Now I want to add our commits to this branch to import it into the subversion-repository. (I don't want to add the single svn-commit to master, because I had to force-push master afterwards leading to lot's of trouble with already checked-out or local branches, I think) After quite a lot of reading and try-and-failing with the arguments of git-rebase, I think, git checkout svn; git cherry-pick first-sha; git rebase -p --onto svn first-sha master is the correct way to go. But when I call the rebase, I get lot's of conflicts I have to solve manually. It looks like these are the same conflicts, which where already solved in the various merge-commits in our history, so I'm confused why I have to solve all these conflicts again. Can you tell me, where I missed something? If you know any smarter way to solve this task, I'd be happy to hear :) Thanks in advance, Stefan Schulze --
[git-users] Re: What is best practice to manage a set of repos?
We've been using gitslave http://gitslave.sourceforge.net/ for this purpose with some great experiences. Note that it's somewhat untested on Windows though. --
Re: [git-users] Error:non-monotonic index after failed recursive sed command
Re-post from git@vger, in case someone stumbles upon this post:
Happy ending!
Turns out i have actually made a backup 3 days ago.
My other work was on a branch + in a stash. Commits done on a branch
were already present in a backup.
I was able to get the stash working by copying corrupted .pack files
from the backup, luckily all the new work wasn't packed yet.
So i've just verified the log messages to see that no new commits were
made, created a patch from the corrupted git repo of the stash,
applied it on the backup, and wo-hooo, everything worked.
And then I've pushed to origin to avoid such silliness in the future.
Thanks and Regards,
George
P.S. It's interesting to note that even though .pack files are
write-protected SED happily overrides them in -i mode.
On Mon, Jan 14, 2013 at 10:39 PM, George Karpenkov
true.chesh...@gmail.com wrote:
Thanks, will try.
No, it wasn't pushed anywhere, stupid, I know.
On Monday, January 14, 2013 6:54:29 PM UTC+11, Konstantin Khomoutov wrote:
On Sun, Jan 13, 2013 at 11:19:53PM -0800, George Karpenkov wrote:
Hi All,
I've managed to corrupt my very valuable repository with a recursive sed
which went wrong.
I wanted to convert all tabs to spaces with the following command:
find ./ -name '*.*' -exec sed -i 's/\t//g' {} \;
I think that has changed not only the files in the repo, but the data
files
in .git directory itself. As a result, my index became corrupted, and
almost every single command dies:
[...]
.git/objects/pack/pack-0c9d5ae4e2b46dd78dace7533adf6cdfe10326ef.idx
error: non-monotonic index
.git/objects/pack/pack-e8bd5c7f85e96e7e548a62954a8f7c7f223ba9e0.idx
Segmentation fault (core dumped)
Any advice? I've lost about 2 weeks worth of work.
Is there anything better I can try to do other then trying to
reconstruct
the data manually from git blobs?
Please ask this question on the main Git list (for developers)
which is git at vger.kernel.org (see [1] for more info) as it might
require assistance of people who know what's the format of Git packs on
the byte level.
As an aside: did you really never pushed your work anywhere for all of
those two weeks? The problem is that what you did sounds to be hardly
reversible as Git packs probably contained a number of bytes with code
0x20 (the space) before you turned each occurence of byte 0x09 in them
into a series of byte 0x20.
For an I feel lucky approach you could probably *copy* the directory
with your repository (recursively) to some other place and try to run
the same command on it as you did but with the arguments to the sed's
substitution command reversed. If Git packs did not happen to contain a
series of 4 consecutive spaces before the change, you will revert them
back to normal. Same applies to unpacked blobs but I feel chances are
lower in this case.
1. http://vger.kernel.org/vger-lists.html#git
--
--
[git-users] rev-parse --is-inside-work-tree never returns false?
I was playing around with some of the information that rev-parse can return and just tried --is-inside-work-tree to see what it would return. As expected, in my working-dir $PROJ, it returns true. Same for within $PROJ/.git and $PROJ/dir_with_nothing_tracked However, when I try git rev-parse --is-inside-work-tree outside my repo, I get fatal: Not a git repository (or any parent up to mount point /home) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). According to my reading of the docs/man-pages, I should get false instead. Under what conditions should rev-parse return false? In this case, I've got my user directories mounted on /home and a test repo in $PROJ=/home/tim/tmp/g so the error occurs in /home/tim and /home/tim/tmp but returns true in /home/tim/tmp/g /home/tim/tmp/g/.git and /home/tim/tmp/g/dir_with_nothing_tracked Thanks, -tkc PS: running 1.7.10.4, FWIW, so if this has been fixed more recently, I'd be happy to just get a already fixed in $NEWER_REV. --
[git-users] Re: rev-parse --is-inside-work-tree never returns false?
On Tuesday, January 15, 2013 3:24:34 AM UTC+1, Tim Chase wrote: I was playing around with some of the information that rev-parse can return and just tried --is-inside-work-tree to see what it would return. As expected, in my working-dir $PROJ, it returns true. Same for within $PROJ/.git and $PROJ/dir_with_nothing_tracked However, when I try git rev-parse --is-inside-work-tree outside my repo, I get fatal: Not a git repository (or any parent up to mount point /home) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). According to my reading of the docs/man-pages, I should get false instead. Under what conditions should rev-parse return false? As far as I understand, there are three related queries here: 1. is-inside-git-dir 2. is-inside-work-tree 3. is-bare-repository They are used to discern whether you are inside the repo/.git dir, or in the work-tree. If you are in a bare repository, the first one will happen to always be true, but if you want to know whether you're in a bare repository or not, the third one is the one to use. --
