From: Jakub Narebski <jnareb@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Heikki Orsila <shdl@zakalwe.fi>, bill lam <cbill.lam@gmail.com>,
git@vger.kernel.org
Subject: Re: how to backup git
Date: Mon, 12 May 2008 11:54:15 -0700 (PDT) [thread overview]
Message-ID: <m38wyf4als.fsf@localhost.localdomain> (raw)
In-Reply-To: <alpine.DEB.1.00.0805121920120.30431@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 12 May 2008, Heikki Orsila wrote:
>
>> On Mon, May 12, 2008 at 06:07:28PM +0100, Johannes Schindelin wrote:
>>
>>> On Mon, 12 May 2008, Heikki Orsila wrote:
>>>> Is there a simple and efficient mechanism for incremental backups?
>>>
>>> Umm. "git fetch"?
>>>
>>> Like I said, it does not get the reflogs, but if you want to back up a
>>> repository, the safest is to clone once, and fetch later. Or you
>>> could set up a remote with the --mirror option, if you want to
>>> preserve the refs' namespaces.
>>
>> Preferably some solution that does not require too much understanding of
>> Git internals so that admins will actually use it, instead of hacking
>> their own inefficient backup scripts.
>>
>> Could someone please write a "git-backup" script?-)
>
> Heikki, why don't you just go with the "git fetch" approach I described?
> We do not need "git backup" when "git fetch" does already what you want.
I think that bundles (see git-bundle) would be what you want (please
read GitFaq/GitTips/"Git in Nutshell" for explanation and use cases).
"git fetch" (perhaps using bundle) would save state of refs (heads,
remote branches, tags) and object repository. To save state of
working area and index I think it would be best to use 'git-stash'
before creating backup, and unstash after it; see documentation for
git-stash. What is left is: reflogs, configuration, hooks, grafts and
shallow, repository local excludes file, repository local attributes
file[*1*].
[*1*] Which is not mentioned in Documentation/repository-layout.txt
--
Jakub Narebski
Poland
ShadeHawk on #git
next prev parent reply other threads:[~2008-05-12 18:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-12 6:08 how to backup git bill lam
2008-05-12 6:36 ` Tobias Sarnowski
2008-05-12 6:40 ` Sverre Hvammen Johansen
2008-05-12 13:11 ` Eric Hanchrow
2008-05-12 13:28 ` Johannes Schindelin
2008-05-12 14:13 ` bill lam
2008-05-12 14:54 ` Miklos Vajna
2008-05-12 15:08 ` Johannes Schindelin
2008-05-12 15:27 ` Heikki Orsila
2008-05-12 17:07 ` Johannes Schindelin
2008-05-12 18:07 ` Heikki Orsila
2008-05-12 18:21 ` Johannes Schindelin
2008-05-12 18:36 ` Heikki Orsila
2008-05-12 18:38 ` Heikki Orsila
2008-05-12 18:58 ` Tim Harper
2008-05-12 19:10 ` Heikki Orsila
2008-05-12 19:49 ` Sverre Rabbelier
2008-05-12 18:54 ` Jakub Narebski [this message]
2008-05-12 21:19 ` Daniel Barkalow
2008-05-12 22:26 ` Junio C Hamano
2008-05-12 23:43 ` Daniel Barkalow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m38wyf4als.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=cbill.lam@gmail.com \
--cc=git@vger.kernel.org \
--cc=shdl@zakalwe.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).