1

I have a customer with my app and a local copy of its .git repository, which she uses to revert changes and test patches, etc. But there is no simple way she can pull a remote with the latest changes due to firewall and other rules. So I thought "just let them download a new, full .git repository zipped up". But the repository is a big mama to move around comfortably, so I would prefer to just send her a zipped up .git of incremental changes (objects, refs, etc) to be decompressed inside her local .git dir.

I've tried the following workflow (automated from within my software), based on the file timestamps:

  1. get the most recent timestamp in her .git/objects directory
  2. create a zip from my .git dir of files starting on that timestamp
  3. email zip file
  4. decompress zip inside customer's .git (it doesn't matter if some files are overwritten)
  5. git checkout -f master (or whatever branch/tag they need) and git clean -d -f

It works fine, since her working tree and .git directories are never modified locally, only checked-out from one branch to a tag or whatever. But file timestamps are definetly unreliable... ie it may all get touched by some backup or whatever, so I'm looking for a more elegant way to create this incremental zip using a commitish of some sort.

So, how could I programmatically create an incremental zip file of my .git directory given I have information from the customer's local .git? I guess this is very similar to what git does internally to pull things from remote incrementally. What's the algorithm to select the correct files? How do I determine the baseline commit from the customer's repository to build the incremental zip?

ojosilva
  • 1,984
  • 2
  • 15
  • 21

1 Answers1

2

Why not use git format-patch command? Or git bundle? Here is an example of how to do it. Your customer need to download full zipped .git directory only once with this, later he can use incremental patches.

madhead
  • 31,729
  • 16
  • 153
  • 201
  • +1... Seems like this kind of situation is exactly what git format-patch is for. – gcbenison Mar 07 '13 at 20:09
  • My intention is to keep both repositories synchronized since, from time to time, a support developer has to debug onsite and it's just more effective to have a mirror repository, to say blame or dissect a commit. As stated on the example link: "Note, however, that this approach does not recreate the state of the world as it was on the sender’s repository" which unfortunately is what I need. OTOH, git bundle might be a good solution... but which ref or commit or timestamp should I use to find where to bundle from? – ojosilva Mar 07 '13 at 20:44
  • When you apply patch, git does not recreate commit and SHA1 hash for it. It just only change files in your working dir. This is what they mean that history will not be identical. In your case better to use bundle. Use `bundle ..HEAD`, where SHA1 is SHA1 of commit that is definitely on customers site (for example some milestone commit or release tag). If customer has any extra updates since that - they will be skipped automatically. – madhead Mar 07 '13 at 21:18
  • `git bundle` + `git fetch` works great, but I'm still having trouble finding the customer's SHA1 to base the bundle on. I want it to be optimal to reduce the bundle size to a minimum. I can't keep track of common tags/releases/branches, I just want the customer to run a git command in their repository that will return the most recent SHA1 they got from us. I tried looking at the customer repo after a git fetch from a bundle, the only thing I could find in their repo that points to the bundle's latest is FETCH_HEAD, but I don't know if that is reliable. – ojosilva Mar 08 '13 at 11:09
  • No magic. Git cannot solve the problem of tracking the latest delivered patch. Additional manipulations required (like analyzing `git log` or `gitk`) – madhead Mar 08 '13 at 11:20