Junio C Hamano wrote:
quoted text
>  (2) End of week comes.  Create an empty branch 'weekly' if you
>      do not already have one.  Make a full tree snapshot, and
>      create a parentless commit for the week if the 'weekly'
>      branch did not exist, or make it a child of the 'weekly'
>      commit from the last week.  Discard 'lastweek' branch if
>      you have one, and rename 'daily' branch to 'lastweek'.

That sounds like it'd work, but doesn't it imply that the history of a 
given file in the backups is not continuous? That is, an old copy of a 
file on the "weekly" branch doesn't have any kind of ancestor 
relationship with the same file on the "daily" branch? While that's 
obviously no different than the current git-less situation where there's 
no notion of ancestry at all, it'd be neat if this backup scheme could 
actually track long-term changes to individual files.

I wonder if rebasing can get me what I want. Something like:

(1) Make a new branch from the latest daily. Commit a full tree
    snapshot to the new branch. (Each branch has exactly one commit.)

(2) To expire a daily backup, rebase the second-oldest daily branch,
    which will initially be a child of the oldest daily branch, under
    the latest weekly branch instead. Delete the oldest daily branch.
    I believe the right commands here would be:

    git-rebase -s recursive -s ours --onto latest-weekly \
               oldest-daily second-oldest-daily
    git-branch -D oldest-daily

    (Not sure about the double "-s", but I want it to detect renames
    where possible and never flag any conflicts.)

(3) At the end of the week, instead of expiring the oldest daily
    branch, rename it to indicate that it's now a weekly snapshot.
    (That will implicitly do the first part of step 2, since the
    next daily branch in line will already be a descendant of the
    newly renamed branch.)

    Repeat step 2, rebasing against the latest monthly branch,
    to expire the oldest weekly.

(4) To expire an old monthly, rebase the second-oldest monthly branch
    under the initial empty revision, then delete the oldest monthly.
    This is basically step 2 again, but rebasing under a fixed starting
    point.

(5) Run git-prune to expire the objects in the deleted branches, then
    git-repack -a -d to delta-compress everything.

That's a bit convoluted, admittedly, and probably a perversion of 
everything pure about the branch system, but would it work? The big 
thing I'm not sure about here is whether, after doing my rebase and 
delete in step 2, the objects from the oldest daily will actually be 
removed by git-prune. They should be unreachable at that point, I think.

-Steve
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html