Re: remotes/* for "foreign" archives

Now that git-cvsimport and git-svn are mature, I'll share my script which I call "get.cvs" to track a number of remote archives. It's not extremely general, but maybe it'll inspire someone else to generalize it.

I have ~/MIRROR/foo-GITSVN tracking a remote archive using git-svn, so the name of the directory reflects the tracking mechanism. There's also *-CVS, *-SVN, *-GIT, and *-GITCVS.

For *-GITCVS, I have to keep the args for git-cvsimport around, so I store that in the respository under getcvs.gitcvsargs.

For *-GITSVN, I have to force the head/origin to softlink to the proper remote svn reference.

The *-GIT* merges are safe, because they won't pull over any uncommited entries, but they *will* merge into whatever the current branch is. This keeps any checked out tree trivially up to date, which is mostly what I'm watching anyway.

Setting up *-GIT* generally requires checking out a master branch to really track the files... I think I did this with "git-checkout -b master origin".

#!/bin/sh

cd && cd MIRROR || exit 1

case $# in
    0) set -- '*';;
esac

eval set -- "$@"

trap ':' 2
for i in "$@"
do (
        trap - 2
        cd $i || exit
        echo == $i ==
        case $i in
            *-CVS) cvs -q update;;
            *-SVN) svn update;;
            *-GIT*)
                ## first, update "origin":
                case $i in
                    *-GIT)
                        git-fetch
                        ;;
                    *-GITCVS)
                        git-cvsimport -k -i $(git-repo-config getcvs.gitcvsargs)
                        ;;
                    *-GITSVN)
                        ## be sure to have origin "ref: refs/remotes/git-svn"
                        git-svn multi-fetch
                        ;;
                esac
                if git-status | grep -v 'nothing to commit'
                then echo UPDATE SKIPPED
                else
                    if git-pull . origin | egrep -v 'up-to-date'
                    then
                        git log --no-merges ORIG_HEAD.. | git shortlog
                    fi
                fi
                ;;
            *)
                echo "[ignoring]";;
        esac
        )
done

Randal> *-GIT*) Randal> ## first, update "origin": Randal> case $i in Randal> *-GIT) Randal> git-fetch Randal> ;; Randal> *-GITCVS) Randal> git-cvsimport -k -i $(git-repo-config getcvs.gitcvsargs) Randal> ;; Randal> *-GITSVN) Randal> ## be sure to have origin "ref: refs/remotes/git-svn" Randal> git-svn multi-fetch Randal> ;; Randal> esac

It occurred to me after posting this, and while still thinking about the presentation I'm writing, that it'd be interesting if "get-fetch" could hide this from me.

If the file in remotes/origin looked something like:

        Pull: !git-svn multi-fetch trunk
        Push: !git-svn commit

then git-fetch and git-push could treat "origin" as a "foreign" branch and indirect through these commands.

Then I could just use "git-pull" naively, and it would git-fetch origin, invoking git-svn multi-fetch trunk to update it, and later I could git-push and it would use git-svn commit.

This idea is half baked, but it could definitely hide the various foreign adaptors from the invocation line, allowing layered tools to use them transparently.

merlyn@stonehenge.com (Randal L. Schwartz) writes:

This sort of integration could be quite cool. But I think the most common use of git-svn is with rebase and not pull. My experience with git-svn and pull is that I very quickly ended up making broken commits to svn --- I've had much better luck rebasing.

Seth> This sort of integration could be quite cool. But I think the most Seth> common use of git-svn is with rebase and not pull. My experience Seth> with git-svn and pull is that I very quickly ended up making broken Seth> commits to svn --- I've had much better luck rebasing.

Well, you'd still be using "git-fetch origin" then, transparently, and your push command could do your preferred thing.

merlyn@stonehenge.com (Randal L. Schwartz) writes:

I agree fully, as it was in my earlier "wishlist" ;-)

Anybody?

On Tue, Nov 21, 2006 at 08:33:48PM CET, Junio C Hamano wrote:

It's currently right after first stage of remotes support in Cogito in my TODO list (and that's not a vaporware anymore but is actually what I'm already working on these days).