Hi Lowell, You can use all of the options in the rev-list for selecting which commits are in the bundle (which is just a thin wrapper around the pack file that would be sent over the wire).
You can include more commits in the bundle than you need [1], that is, have an overlap. One option is simply to use the --since=<date> option as a way of ensuring you go far enough back in history. Plus the --all to get everything after tha date [2]. I suspect that part of the problem is finding a way of recording what has been transferred in the three way transfer - I'd suggest it's just as easy to use a small note book (or formal admin log) for recording the date of transfers and use that to guide the bundle creation. Plus you can always stack up the bundles, so can fetch first from the oldest bundle, and then from the newer bundle, etc. I see you have the typical 'transfer review' process for the bundle exchange (implies a certain kind of environment ;-) - does it ever fail/reject the transfer? or is it simply making sure it is what you thought it was and have recorded the transfer correctly (I expect it's actually the latter). If you get true rejection you have more issues. I don't really think you need a special 'script' (beyond satisfying some edict), as the bundle and fetch commands should be sufficient for doing the transfer. Probably the biggest issue at that point is having a standardised naming convention for the bundle file, e.g. server<n>-<datethen>-<datenow>.bndl so that you know where it came from, where the --since cut point was, and when it was created. Then it becomes fairly easy to import/fetch from the bundle acording to the carefully mandated process. Philip [1] https://git-scm.com/docs/git-bundle It is okay to err on the side of caution, causing the bundle file to contain objects already in the destination, as these are ignored when unpacking at the destination. [2] http://stackoverflow.com/questions/11792671/how-to-git-bundle-a-complete-repo ----- Original Message ----- From: Lowell Alleman To: Git for human beings Sent: Wednesday, February 01, 2017 9:58 PM Subject: [git-users] Synchronizing air gapped git repositories using bundles I have 3 separate air-gapped git repositories (hosted on local GitHub enterprise) that I'm trying to keep in sync. Currently, I'm using "git bundle" to push revisions back and forth, which worked fairly well with just 2 repositories, but I'm struggling a bit since the 3rd (and final) repository has been added to the mix. I was using a single tag to track the point of last export as noted in the "git bundle" docs, but I'm struggling to make that scale with 2+ total repositories. In terms of information flow, we've deemed one of the repositories as "primary" and the other two as "secondary" repositories. So in a sense we are using the "primary" repository like a development and merging area so that all changes go through the primary repository and trickle down to the secondary repositories. Changes are always pushed upstream to primary, and then synced down to the other secondary repository. Please note that our use of git is more like a "versioned file system" than the typical developer use case. I go on to explain that a bit more later, but wanted to get to my main question before everyone gives up on reading this really long and complicated explanation of the mess I made. Q: Does anyone know of any existing scripts, documented methods, or best practices to follow when syncing a branch between multiple air-gapped repositories? How we are using git: As noted above, this is NOT a typical development-centered use-case. Branching is very infrequent, and most work is done on the "master" branch in each repository. Unlike typical developer-centric approaches, each clone (working copy) ends up tied to a specific server, rather than a single developer. So multiple users end up working in the same working copy and committing code from one place. The team is small and the changes are infrequent enough that this works for us, despite the atypical and less-than-ideal use case. How we are using branches: We treat each repository as if it has just one branch, a single "master". However, because of the synchronization requirements, we create special purpose branches in each repository that essentially mirror the master branches of the other repositories. So the primary repository has 2 mirrored branches, one for each of the secondary repositories. And each secondary repository has a single mirrored branch that represents the primary (upstream) repository. (By convention, we have agreed never to synchronize revisions directly between the two secondary repositories.) Local changes are never applied to a mirrored repository branch, so that it should match the "master" branch of the mirrored repository exactly. (That is, the only changes to these mirrored branches are fast-forward only "pull"s made from bundle files exported from the mirrored repository.) The process of merging changes between branches is manual, and I think I want to keep it that way for the foreseeable future. (Perhaps one day I'll make fast-forward merges apply automatically, but in general I want a human to be responsible for this step.) So while each repositories' "master" branch may diverge, or at least have a slightly different history, in the end, they should all end up with the same content. Well, at least that's the ultimate goal. File transfer: Transferring bundle files between air-gapped environments involve multiple human steps including content review, approval, and some safety checks for compliance. Therefore, there's no way to automatically schedule synchronization, which is a bummer. That being said, I'd like to make this as painless as possible within the realm of what I can control. I'm looking to create import and export scripts (or find existing ones to borrow from) that handle bundle creation and the import process. I'm looking for a little help designing an appropriate synchronization solution, and would appreciate any feedback you may have. The combination of using git bundle and our non-traditional use case has made it difficult to find relevant resources. If there is anything I've missed, please point me in the right direction. -- 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/d/optout. -- 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/d/optout.
