#15 Allow checking out specific revisions of the gitslave repositories

[Robert Munteanu]

When using gitslave it can be useful to checkout all attached projects at specific revisions, not necessary the same one.

Assume that you have a web application which embeds two libraries, and you have to debug a problem with version 1.2.0. You then need to checkout those two libraries at the specific revision which you know you have shipped for 1.2.0. Since they are in different git repos, there can't be a single revision or tag which identifies them.

This might be doable by adding an extra flag to the .gitslave file, revision=$rev , where $rev is a valid git revision ( commit, tag, branch ). Multiple flags can be space-separated or comma-separated.

A .gitslave file which uses this new flag would then be

"../project1" project1 revision=cafebabe
"../project2" project2 revision=release-1.2.0
"../project3" project3 ifpresent revision=release-1.2.0

I haven't touched perl in some time, but with a little guidance I can try and implement this myself.

[Baka Project]

Bah, my comment appears to have gotten lost, twice!. Anyway, to recreate, it feels more like you are confused as to how gitslave was designed to be used and what the alternatives are. In general, with gitslave you are expected to have the same tag (name) on all of the repos when you release. Fixing subprojects at specific revisions is something that git-submodules was designed to do.

The typical use case for releasing and later reviewing is to release via gits tag cafebabe-2.0 (assuming the release was codenamed cafebabe-2.0). All three repositories in your superproject will have the tag cafebabe-2.0. Some of those slaves which don't change very often might have many cafebabe tags all pointing to the same revision, which might correspond of release-1.2.0 or might not. Then, when you need to revisit the cafebabe-2.0 release, you gits checkout cafebabe-2.0 and you will be at the same revision you were at when you tagged.

I would need to better understand your use case and why git-submodules (or a more gitslaveish workflow) isn't the answer prior to doing work or accepting a patch.

[Robert Munteanu]

Right, I'll expand our use case a bit.

We have a collection of git repositories which have a loosely related lifecycle. The content of these repositories ends up in the same product. We assemble all these projects using .gitslave into a super-project, which allows developers to get a holistic view of the application. We have around 70 modules, and it's good for us to get a complete checkout and manage it easily with gitslave, mostly for cloning, pulling and pushing.

However, for a release we do not take snapshots/make releases at the same point in time of each project, but we rather decide for each project independently. This means that we can not use gits to tag all of the repos with 'release-1.1.0', but rather have a 'bill of materials' which contains each project and its version

• cafebabe-2.0
• deadbeef-4.2
• feeldead-2.1.6

Our use case is that we want to take this bill of materials and have a way of checking out the superproject and all its projects as they were packaged for a release. It seemed natural for us to use gitslave for it, so we have tooling which generates a .gitslave file with the contents of a release and with the flags I have suggested in the report.

We did consider git submodules and subtrees but they really did not fit our requirements, just gitslave did.