From: mac4-git@theory.org
To: Nanako Shiraishi <nanako3@lavabit.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Support ref logs for refs/*
Date: Thu, 8 Jan 2009 08:52:40 -0800 [thread overview]
Message-ID: <20090108165240.GA22815@tesla.theory.org> (raw)
In-Reply-To: <20090108180857.6117@nanako3.lavabit.com>
On Thursday, January 08, 2009, the wise Nanako Shiraishi wrote:
>Quoting Neil Macneale <mac4-git@theory.org>:
>
>> The documentation for git update-ref seems to imply that logging of ref
>> updates should be done for anything in refs/...
>
>The documementation for git-update-ref is part of git, and git does not use anything outside of refs/{heads,tags,remotes}/ for its normal operation.
>
>I think it is generally assumed that there is nothing of interest outside of these areas that deserves the automated creation of reflogs, and the code you are touching is about that. Once you have reflog for any ref you are interested outside of these areas, your actions will be logged regardless.
Why is that generally assumed? I can fetch to arbitrary refs and git prune
doesn't clean objects references from argitrary refs, so it seems like
there is implicit support for these references. A little extra logging
never hurt anyone.
>Most notably, refs/stash itself is exempt from this code path and it makes sure that reflog exists without relying on log_all_ref_updates configuration.
Why not? I'd like like have logs for stash actions. Makes the case when
someone runs git stash clear by mistake a little easier to recover from.
The alternative is for me to touch a file in .git/logs/refs prior to any
use of git update-ref. It seems like most git commands go to great
lengths to prevent you from ever needing to get into the .git dir, so maybe
an alternative would be an option to force git update-ref to create a log
file automatically. I thought thats what the "all" in core.logallrefupdates
meant. Silly me.
A command line option for git update-ref is not ideal because when I run
git fetch remote refs/whatever:refs/whatever, I still want a log entry.
Thus, I still need to be mucking with the .git dir when I shouldn't need
to.
Whats the harm in a little more logging? The space wasted is pretty much
nothing. I'd much rather be able to look at a ref log in the event that I
mess somthing up than run git fsck.
Cheers,
Neil
>
>--
>Nanako Shiraishi
>http://ivory.ap.teacup.com/nanako3/
>
>--
>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
prev parent reply other threads:[~2009-01-08 16:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-08 8:28 [PATCH] Support ref logs for refs/* Neil Macneale
2009-01-08 9:08 ` Nanako Shiraishi
2009-01-08 16:52 ` mac4-git [this message]
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=20090108165240.GA22815@tesla.theory.org \
--to=mac4-git@theory.org \
--cc=git@vger.kernel.org \
--cc=nanako3@lavabit.com \
/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).