2

I am managing my svn repositories as a git repo through git-svn tool, but there is no way to handle my svn externals. This problem is solved by treating each external as a git-svn repo. This is done using a script and the result is something similar to this:

> src/
> -- .git/
> -- Source1.x
> -- Source2.x
> -- .git_external/
> ---- git-svn_external1/
> ------ .git/
> ------ ExternalSource1.x
> ---- git-svn_external2/
> ------ .git/
> ------ AnotherExternalSource1.x
> ------ AnotherExternalSource2.x

With the lack of a tool to handle the svn externals, I need to verify each modification through a bash script that is executed manually and it is something like this:

#!/bin/sh
for i in `ls .` do
  if [ -d $i ] then
    cd $i
    if [ -d .git ] then
      git status .
    fi
  cd ..
  fi
done

How can I achieve this automatically while executing the git status command on main git-svn repository?

I didn't find any hook related to this situation, so I think that I need to find a workaround to this problem.

coelhudo
  • 4,710
  • 7
  • 38
  • 57
  • 2
    why aren't they submodules? – CharlesB Jan 30 '13 at 20:54
  • 1
    @CharlesB: AFAIK, Git submodules and git-svn don't play nicely together. Or at least I could never get them working nicely (although I'll grant that may be my incompetence). If you know of a good way to do it, please do share! – me_and Jan 30 '13 at 21:52
  • I don't know :) it was just naive question – CharlesB Jan 30 '13 at 22:01
  • 1
    @CharlesB: Dang. For a minute there I thought someone had worked out how to make my life far easier… – me_and Jan 30 '13 at 22:43

2 Answers2

4

In general git tries to provide as few hooks as possible, providing them only in situations where you can’t use a script instead. In this situation, just write a script that does your bidding and runs git status. Run this script instead of git status.

If you call it git-st and put it in your PATH, you can call it via git st.

Chronial
  • 66,706
  • 14
  • 93
  • 99
3

A trick I've used a few times is to write a shell wrapper function around git. Assuming you're using Bash (it's similar for other shells), add the following to your ~/.bashrc:

git () {
    if [[ $1 == status ]]
    then
        # User has run git status.
        #
        # Run git status for this folder.  The "command" part means we actually
        # call git, not this function again.
        command git status .

        # And now do the same for every subfolder that contains a .git
        # directory.
        #
        # Use find for the loop so we don't need to worry about people doing
        # silly things like putting spaces in directory names (which we would
        # need to worry about with things like `for i in $(ls)`).  This also
        # makes it easier to recurse into all subdirectories, not just the
        # immediate ones.
        #
        # Note also that find doesn't run inside this shell environment, so we
        # don't need to worry about prepending "command".
        find * -type d -name .git -execdir git status . \;
    else
        # Not git status.  Just run the command as provided.
        command git "$@"
    fi
}

Now when you run git status, it'll actually run git status for the current folder and in any subfolder that contains its own .git folder.

Alternatively, you could make this into a new command, either by writing a script as Chronial suggests, or by putting it into a Git alias. To do the latter, run something like the following command:

git config --global alias.full-status '!cd ${GIT_PREFIX:-.}; git status .; find * -type d -name .git -execdir git status . \;'

Then you'll be able to run git full-status to do the same thing.

(The cd ${GIT_PREFIX:-.} part is there to return you to whichever directory you ran the command from; Git aliases by default run from the root of the repository. The rest is as for the function solution above.)

Community
  • 1
  • 1
me_and
  • 15,158
  • 7
  • 59
  • 96
  • Note that the command-wrapper trick is more fragile than Git commands are normally. For example, if you were to invoke `git -p status` (perfectly valid, see `man 1 git`), the wrapper above wouldn't work. I consider that a reasonable trade-off, as someone who never uses that style of invocation, but if you do use such arguments, you may want to write a fancier wrapper. Or just hack the Git source code to do what you want in the first place. – me_and Feb 18 '13 at 14:59