3

My repository has a branch production and is filled with countless tags of the format production-20130101-1234 that point to what has been actually shipped on the given datetime.

I think this solution is somewhat messy and unwieldy and I wonder if reflogs would skip in here better. The objective is "make sure you can always find out what version has been deployed and when exactly".

Tags do the job, but reflogs sound even nicer because:

  • They are made automatically,
  • They allow a good amount of awesome, like in the form of git checkout origin/production@{3 months ago}.

That said, I don't know that much about reflogs and I'm not sure about possible downsides of such approach.

  1. I assume origin/production has its own reflog totally independent of my local remote-tracking production - is that correct?
  2. Doing 3 consecutive no-ff merges from an integration branch to my local production branch would make 3 entries in my local reflog, but pushing it to the central repo (as a part of the deployment procedure) would make 1 new entry in the "oracle" origin/production reflog, correct?
    I'd like to maintain the "1 deployment = 1 record" invariant.
  3. How to make sure a reflog of origin/production isn't pruned and continues to provide complete historical information for everyone?
  4. Any downsides or possible problems I didn't think of?
1
  • 3) Just tag it so it doesn't get pruned. 4) Tags can be signed and pushed unambiguously. The big question is if your solution is so much cleaner than tags? Git already provides you with something that fits your whole list, why not just adopt it? Oct 9, 2013 at 10:18

1 Answer 1

2

The main problem is that reflog is local thing and never propagated anywhere. So the data would be somewhat difficult to get at.

One alternative of tags that comes to my mind is a branch with subproject. Git tree can contain a link to a commit. So you can create a repository above the actual project and when you deploy, commit with the correct submodule revision. I am not sure whether it would be possible to have is somewhere on the side with the subproject included via symlink. I am sure though that it would be possible to write a utility for creating such revisions in the repository without actually having a work tree at all (git creates commits from state of index only and you can manipulate the index directly via commands and you can tell git to use different index file). It would take some work though.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.