Gnome chose Git

Gnome chose Git

[Teemu Likonen]

FYI: The Gnome release team just announced that Gnome will migrate from
Subversion to Git:

    http://thread.gmane.org/gmane.comp.gnome.infrastructure/1134

Re: Gnome chose Git

[Sverre Rabbelier]

Heya,

On Thu, Mar 19, 2009 at 12:23, Teemu Likonen <tlikonen@iki.fi> wrote:
> FYI: The Gnome release team just announced that Gnome will migrate from
> Subversion to Git:
>
>    http://thread.gmane.org/gmane.comp.gnome.infrastructure/1134

Sweet, now how long until my university starts offering git hosting
and my fellow students start using it in their projects? :P

-- 
Cheers,

Sverre Rabbelier

Re: Gnome chose Git

[Mike Ralphson]

2009/3/19 Teemu Likonen <tlikonen@iki.fi>:
> FYI: The Gnome release team just announced that Gnome will migrate from
> Subversion to Git:
>
>    http://thread.gmane.org/gmane.comp.gnome.infrastructure/1134

There does seem to be a typo in the release though.

"We realize that git is not perfect, and that the transition will
require significant and important changes to many GNOME processes."

s/ not//

There, fixed that.

Seriously, they should be advocating a c) there, contributing
improvements back to git (and whichever svn migration tool they used)
for the benefit of all, which I'm sure we'll see.

Mike

Re: Gnome chose Git

[Michael J Gruber]

Teemu Likonen venit, vidit, dixit 19.03.2009 12:23:
> FYI: The Gnome release team just announced that Gnome will migrate from
> Subversion to Git:
> 
>     http://thread.gmane.org/gmane.comp.gnome.infrastructure/1134

Good choice :)

Interestingly, they seem to go the svn-all-fast-export route.

Also, they need push tracking for pushing through ssh, which is a common
requirement for many large projects. Do we have something to support
that? git-notes comes to my mind.

Their current approach is writing to a single log file (receive-hook).
That may support a linear push history best, but looking up who pushed
what, given "what"?

Michael

Re: Gnome chose Git

[Pat Notz]

On Thu, Mar 19, 2009 at 7:50 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Pat Notz venit, vidit, dixit 19.03.2009 14:43:
>> On Thu, Mar 19, 2009 at 7:33 AM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Teemu Likonen venit, vidit, dixit 19.03.2009 12:23:
>>>> FYI: The Gnome release team just announced that Gnome will migrate from
>>>> Subversion to Git:
>>>>
>>>>     http://thread.gmane.org/gmane.comp.gnome.infrastructure/1134
>>>
>>> Good choice :)
>>>
>>> Interestingly, they seem to go the svn-all-fast-export route.
>>>
>>> Also, they need push tracking for pushing through ssh, which is a common
>>> requirement for many large projects. Do we have something to support
>>> that? git-notes comes to my mind.
>>>
>>> Their current approach is writing to a single log file (receive-hook).
>>> That may support a linear push history best, but looking up who pushed
>>> what, given "what"?
>>>
>>
>> That's also something we do.  Since the post-receive hook gives you
>> the refname and the old and new refs you should have everything you
>> need.  We basically record the user name, UTC timestamp and the ref
>> info.  With a little bit more scripting you should be able to figure
>> everything else out (though post-receive isn't called for local
>> commits).
>>
>
> I know the info is there. It might just make more sense to have it in
> the git repo the way notes are/will be: It's public, it's connected to
> the commits, it's tamper proof (anyone would notice rewrites).
>

Ahh, yes.  We'd like that too.

> Michael
>
> P.S.: Was this intentionally off-list? Just in case I respected it.
>

Oops, sorry about that.  Fixed.

Re: Gnome chose Git

[Shawn O. Pearce]

Pat Notz <patnotz@gmail.com> wrote:
> On Thu, Mar 19, 2009 at 7:50 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
> > Pat Notz venit, vidit, dixit 19.03.2009 14:43:
> >> On Thu, Mar 19, 2009 at 7:33 AM, Michael J Gruber
> >> <git@drmicha.warpmail.net> wrote:
> >>>
> >>> Also, they need push tracking for pushing through ssh, which is a common
> >>> requirement for many large projects. Do we have something to support
> >>> that? git-notes comes to my mind.
> >>>
> >>> Their current approach is writing to a single log file (receive-hook).
> >>> That may support a linear push history best, but looking up who pushed
> >>> what, given "what"?
> >>
> >> That's also something we do. ?Since the post-receive hook gives you
> >> the refname and the old and new refs you should have everything you
> >> need. ?We basically record the user name, UTC timestamp and the ref
> >> info. ?With a little bit more scripting you should be able to figure
> >> everything else out (though post-receive isn't called for local
> >> commits).

Why are people reinventing the reflog, and core.logallrefupdates ?

> > I know the info is there. It might just make more sense to have it in
> > the git repo the way notes are/will be: It's public, it's connected to
> > the commits, it's tamper proof (anyone would notice rewrites).
> 
> Ahh, yes.  We'd like that too.

Eclipse is also talking about Git, and has a similar problem.

Anytime you start talking about "who put what" though, you get into a
"where, and why does it matter?"

Imagine you are Eclipse Foundation or GNOME, you need to know which
authorized developer put the code on your servers.

But imagine you are an ISV like Oracle or IBM and you consume
code from the upstream project (Eclipse), put it on your servers,
add some "extra sauce", and distribute the result in some form.
Who put what on the Eclipse server isn't relevant, but what employee
your clone to use 3.4.1 instead of 3.4.0 matters a whole lot more.
For the most part, you just trust the upstream to do their own
IP tracking and diligence, as they have the contributor license
agreements, and you don't.

Its a thorny problem.  We've talked about trying to add some sort
of GnuPG signature into a push stream (for example) to allow the
server to store a record of who-did-what-when and later distribute
that back.

  http://thread.gmane.org/gmane.comp.version-control.git/71849

-- 
Shawn.

Re: Gnome chose Git

[Pat Notz]

On Thu, Mar 19, 2009 at 9:16 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
>
> Why are people reinventing the reflog, and core.logallrefupdates ?
>

Hmmm, lack of awareness of core.logallrefupdates in my case.  Thanks
for the pointer.

~ Pat

Re: Gnome chose Git

[Andreas Ericsson]

Mike Ralphson wrote:
> 2009/3/19 Teemu Likonen <tlikonen@iki.fi>:
>> FYI: The Gnome release team just announced that Gnome will migrate from
>> Subversion to Git:
>>
>>    http://thread.gmane.org/gmane.comp.gnome.infrastructure/1134
> 
> There does seem to be a typo in the release though.
> 
> "We realize that git is not perfect, and that the transition will
> require significant and important changes to many GNOME processes."
> 
> s/ not//
> 
> There, fixed that.
> 
> Seriously, they should be advocating a c) there, contributing
> improvements back to git (and whichever svn migration tool they used)
> for the benefit of all, which I'm sure we'll see.
> 

Kristian Högsberg played a rather significant part in the migration
process. Since he's an old git contributor, he'll almost certainly
see to it that improvements are made available to core git.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: Gnome chose Git

[Jeff King]

On Thu, Mar 19, 2009 at 09:50:39AM -0600, Pat Notz wrote:

> On Thu, Mar 19, 2009 at 9:16 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> >
> > Why are people reinventing the reflog, and core.logallrefupdates ?
> >
> 
> Hmmm, lack of awareness of core.logallrefupdates in my case.  Thanks
> for the pointer.

But do note that reflogs expire eventually, so you will want to also
look at gc.reflogexpire and gc.reflogexpireunreachable if you want to
keep this as an activity log forever.

-Peff

Re: Gnome chose Git

[demerphq]

2009/3/19 Jeff King <peff@peff.net>:
> On Thu, Mar 19, 2009 at 09:50:39AM -0600, Pat Notz wrote:
>
>> On Thu, Mar 19, 2009 at 9:16 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
>> >
>> > Why are people reinventing the reflog, and core.logallrefupdates ?
>> >
>>
>> Hmmm, lack of awareness of core.logallrefupdates in my case.  Thanks
>> for the pointer.
>
> But do note that reflogs expire eventually, so you will want to also
> look at gc.reflogexpire and gc.reflogexpireunreachable if you want to
> keep this as an activity log forever.

Outside of parsing the reflog directly, (which feels wrong and dirty
to me), how does one find out the times that a reflog entry was
created?

The closest thing i could find was git log -g, but that shows the time
of the commit that was switched to, not the time the reflog entry was
created. I dont see a --format pattern for it, and there doesnt seem
to be a switch to git reflog to do it. (I had initially (before
RTFM'ing) assumed that git reflog -v would show the times, but
apparently not).

If the times were easy to access then it would be much more useful as
a general logging facility.

cheers,
Yves




-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Gnome chose Git

[Shawn O. Pearce]

demerphq <demerphq@gmail.com> wrote:
> Outside of parsing the reflog directly, (which feels wrong and dirty
> to me), how does one find out the times that a reflog entry was
> created?
> 
> The closest thing i could find was git log -g, but that shows the time

  git reflog -g branch@{now}

the @{now} suffix is the magic to make it show the time.

-- 
Shawn.

Re: Gnome chose Git

[Shawn O. Pearce]

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> demerphq <demerphq@gmail.com> wrote:
> > Outside of parsing the reflog directly, (which feels wrong and dirty
> > to me), how does one find out the times that a reflog entry was
> > created?
> > 
> > The closest thing i could find was git log -g, but that shows the time
> 
>   git reflog -g branch@{now}

Arrgh, I of course actually meant

    git log -g branch@{now}
 
> the @{now} suffix is the magic to make it show the time.

-- 
Shawn.

Re: Gnome chose Git

[demerphq]

2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
> demerphq <demerphq@gmail.com> wrote:
>> Outside of parsing the reflog directly, (which feels wrong and dirty
>> to me), how does one find out the times that a reflog entry was
>> created?
>>
>> The closest thing i could find was git log -g, but that shows the time
>
>  git reflog -g branch@{now}
>
> the @{now} suffix is the magic to make it show the time.

Ah cool. Its not documented but that at least would have sorted my
immediate needs.

But for a logging tool it would be nice to get something like:

2009-03-19 21:46 > de9b652... HEAD@{0}: commit: pod/perlreftut.pod:
keep example in tune with the times
2009-03-19 21:44 > 53102b2... HEAD@{1}: HEAD^: updating HEAD
2009-03-19 21:40 > a9a8f59... HEAD@{2}: commit: must stay contemporary

instead of:

$ git reflog -g HEAD@{now}
de9b652... HEAD@{57 minutes ago}: commit: pod/perlreftut.pod: keep
example in tune with the times
53102b2... HEAD@{61 minutes ago}: HEAD^: updating HEAD
a9a8f59... HEAD@{61 minutes ago}: commit: must stay contemporary

But thanks a lot for the info. I take this is documented in a newer
release than i currently have?

Yves





-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Gnome chose Git

[demerphq]

2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
> "Shawn O. Pearce" <spearce@spearce.org> wrote:
>> demerphq <demerphq@gmail.com> wrote:
>> > Outside of parsing the reflog directly, (which feels wrong and dirty
>> > to me), how does one find out the times that a reflog entry was
>> > created?
>> >
>> > The closest thing i could find was git log -g, but that shows the time
>>
>>   git reflog -g branch@{now}
>
> Arrgh, I of course actually meant
>
>    git log -g branch@{now}
>
>> the @{now} suffix is the magic to make it show the time.

Ah! Much nicer! Thanks.

Is there by any chance any way to set the date format it uses to
something more suitable for machine processing?

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Gnome chose Git

[Shawn O. Pearce]

demerphq <demerphq@gmail.com> wrote:
> 2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
> > "Shawn O. Pearce" <spearce@spearce.org> wrote:
> >
> > git log -g branch@{now}
> 
> Ah! Much nicer! Thanks.
> 
> Is there by any chance any way to set the date format it uses to
> something more suitable for machine processing?

I don't think so.  If you want to machine process it, why not
just read the reflog directly?  Its a really simple format.

-- 
Shawn.

Re: Gnome chose Git

[demerphq]

2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
> demerphq <demerphq@gmail.com> wrote:
>> 2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
>> > "Shawn O. Pearce" <spearce@spearce.org> wrote:
>> >
>> > git log -g branch@{now}
>>
>> Ah! Much nicer! Thanks.
>>
>> Is there by any chance any way to set the date format it uses to
>> something more suitable for machine processing?
>
> I don't think so.  If you want to machine process it, why not
> just read the reflog directly?  Its a really simple format.

Mostly my problem with that is that it violates the abstraction. If i
update git and the reflog format changes my script breaks. I dont
necessarily know where it will be located, etc. And while no doubt i
can reverse engineer the format, well, who knows maybe Ill miss
something important, I mean is it documented anywhere?

So i guess if the format were documented (and thus changing it would
break compatibility and be noted in the changes file) then it would be
fine to do so, but it seems to me making a way to access the reflog
data in a structured way via a plumbing level command makes more
sense. (At the very least this abstract the user of having to figure
out where the log is stored).

Yves




-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Gnome chose Git

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 812 bytes --]

Hi,

On Thu, 19 Mar 2009, demerphq wrote:

> 2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
> > "Shawn O. Pearce" <spearce@spearce.org> wrote:
> >> demerphq <demerphq@gmail.com> wrote:
> >> > Outside of parsing the reflog directly, (which feels wrong and dirty
> >> > to me), how does one find out the times that a reflog entry was
> >> > created?
> >> >
> >> > The closest thing i could find was git log -g, but that shows the time
> >>
> >>   git reflog -g branch@{now}
> >
> > Arrgh, I of course actually meant
> >
> >    git log -g branch@{now}
> >
> >> the @{now} suffix is the magic to make it show the time.
> 
> Ah! Much nicer! Thanks.
> 
> Is there by any chance any way to set the date format it uses to
> something more suitable for machine processing?

git log --date=$FORMAT -g branch

Hth,
Dscho

Re: Gnome chose Git

[Jeff King]

On Thu, Mar 19, 2009 at 02:43:17PM -0700, Shawn O. Pearce wrote:

> demerphq <demerphq@gmail.com> wrote:
> > Outside of parsing the reflog directly, (which feels wrong and dirty
> > to me), how does one find out the times that a reflog entry was
> > created?
> > 
> > The closest thing i could find was git log -g, but that shows the time
> 
>   git reflog -g branch@{now}
> 
> the @{now} suffix is the magic to make it show the time.

Yuck. It would be nice to just have a "Reflog date" header that you
could depend on, like:

diff --git a/reflog-walk.c b/reflog-walk.c
index f751fdc..cb7c66b 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -269,6 +269,8 @@ void show_reflog_message(struct reflog_walk_info* info, int oneline,
 				       - 2 - commit_reflog->recno);
 			printf("} (%s)\nReflog message: %s",
 			       info->email, info->message);
+			printf("Reflog date: %s\n",
+				show_date(info->timestamp, info->tz, relative_date));
 		}
 	}
 }

Then you could just do:

  $ git log --date=raw -g

Looking at making this trivial patch, though, it seems there is a bug
with the relative_date parameter. It is really a date_mode enum. In the
multi-line format, we feed it to show_date. But in the oneline mode, we
use it to decide whether to show the date, but then always pass the
"relative" date mode. So you get:

  $ git log --oneline -g origin/master | head -n 1
  e986ceb refs/remotes/origin/master@{0}: fetch origin: fast forward
  $ git log --oneline -g --date=relative origin/master | head -n 1
  e986ceb refs/remotes/origin/master@{2 days ago}: fetch origin: fast forward
  $ git log --oneline -g --date=raw origin/master | head -n 1
  e986ceb refs/remotes/origin/master@{2 days ago}: fetch origin: fast forward

Hmm. It seems to drop the TZ, too. I'll whip up a patch.

I guess my original "extra reflog header" isn't terribly useful, then:
you can always just pass --date=raw and parse it from the branch@{}
syntax.

-Peff

[PATCH] make oneline reflog dates more consistent with multiline format

[Jeff King]

The multiline reflog format (e.g., as shown by "git log -g")
will show HEAD@{<date>} rather than HEAD@{<count>} in two
situations:

  1. If the user gave branch@{<date>} syntax to specify the
     reflog

  2. If the user gave a --date=<format> specifier

It uses the "normal" date format in case 1, and the
user-specified format in case 2.

The oneline reflog format (e.g., "git reflog show" or "git
log -g --oneline") will show the date in the same two
circumstances. However, it _always_ shows the date as a
relative date, and it always ignores the timezone.

In case 2, it seems ridiculous to trigger the date but use a
format totally different from what the user requested.

For case 1, it is arguable that the user might want to see
the relative date by default; however, the multiline version
shows the normal format.

This patch does three things:

  - refactors the "relative_date" parameter to
    show_reflog_message to be an actual date_mode enum,
    since this is how it is used (it is passed to show_date)

  - uses the passed date_mode parameter in the oneline
    format (making it consistent with the multiline format)

  - does not ignore the timezone parameter in oneline mode

Signed-off-by: Jeff King <peff@peff.net>
---
 reflog-walk.c          |   12 +++++---
 reflog-walk.h          |    5 +++-
 t/t1411-reflog-show.sh |   67 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 78 insertions(+), 6 deletions(-)
 create mode 100755 t/t1411-reflog-show.sh

diff --git a/reflog-walk.c b/reflog-walk.c
index f751fdc..fd065f4 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -242,7 +242,7 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)
 }
 
 void show_reflog_message(struct reflog_walk_info* info, int oneline,
-	int relative_date)
+	enum date_mode dmode)
 {
 	if (info && info->last_commit_reflog) {
 		struct commit_reflog *commit_reflog = info->last_commit_reflog;
@@ -251,8 +251,10 @@ void show_reflog_message(struct reflog_walk_info* info, int oneline,
 		info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
 		if (oneline) {
 			printf("%s@{", commit_reflog->reflogs->ref);
-			if (commit_reflog->flag || relative_date)
-				printf("%s", show_date(info->timestamp, 0, 1));
+			if (commit_reflog->flag || dmode)
+				printf("%s", show_date(info->timestamp,
+						       info->tz,
+						       dmode));
 			else
 				printf("%d", commit_reflog->reflogs->nr
 				       - 2 - commit_reflog->recno);
@@ -260,10 +262,10 @@ void show_reflog_message(struct reflog_walk_info* info, int oneline,
 		}
 		else {
 			printf("Reflog: %s@{", commit_reflog->reflogs->ref);
-			if (commit_reflog->flag || relative_date)
+			if (commit_reflog->flag || dmode)
 				printf("%s", show_date(info->timestamp,
 							info->tz,
-							relative_date));
+							dmode));
 			else
 				printf("%d", commit_reflog->reflogs->nr
 				       - 2 - commit_reflog->recno);
diff --git a/reflog-walk.h b/reflog-walk.h
index 7ca1438..74c9096 100644
--- a/reflog-walk.h
+++ b/reflog-walk.h
@@ -1,11 +1,14 @@
 #ifndef REFLOG_WALK_H
 #define REFLOG_WALK_H
 
+#include "cache.h"
+
 extern void init_reflog_walk(struct reflog_walk_info** info);
 extern int add_reflog_for_walk(struct reflog_walk_info *info,
 		struct commit *commit, const char *name);
 extern void fake_reflog_parent(struct reflog_walk_info *info,
 		struct commit *commit);
-extern void show_reflog_message(struct reflog_walk_info *info, int, int);
+extern void show_reflog_message(struct reflog_walk_info *info, int,
+		enum date_mode);
 
 #endif
diff --git a/t/t1411-reflog-show.sh b/t/t1411-reflog-show.sh
new file mode 100755
index 0000000..c18ed8e
--- /dev/null
+++ b/t/t1411-reflog-show.sh
@@ -0,0 +1,67 @@
+#!/bin/sh
+
+test_description='Test reflog display routines'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+	echo content >file &&
+	git add file &&
+	test_tick &&
+	git commit -m one
+'
+
+cat >expect <<'EOF'
+Reflog: HEAD@{0} (C O Mitter <committer@example.com>)
+Reflog message: commit (initial): one
+EOF
+test_expect_success 'log -g shows reflog headers' '
+	git log -g -1 >tmp &&
+	grep ^Reflog <tmp >actual &&
+	test_cmp expect actual
+'
+
+cat >expect <<'EOF'
+e46513e HEAD@{0}: commit (initial): one
+EOF
+test_expect_success 'oneline reflog format' '
+	git log -g -1 --oneline >actual &&
+	test_cmp expect actual
+'
+
+cat >expect <<'EOF'
+Reflog: HEAD@{Thu Apr 7 15:13:13 2005 -0700} (C O Mitter <committer@example.com>)
+Reflog message: commit (initial): one
+EOF
+test_expect_success 'using @{now} syntax shows reflog date (multiline)' '
+	git log -g -1 HEAD@{now} >tmp &&
+	grep ^Reflog <tmp >actual &&
+	test_cmp expect actual
+'
+
+cat >expect <<'EOF'
+e46513e HEAD@{Thu Apr 7 15:13:13 2005 -0700}: commit (initial): one
+EOF
+test_expect_success 'using @{now} syntax shows reflog date (oneline)' '
+	git log -g -1 --oneline HEAD@{now} >actual &&
+	test_cmp expect actual
+'
+
+cat >expect <<'EOF'
+Reflog: HEAD@{1112911993 -0700} (C O Mitter <committer@example.com>)
+Reflog message: commit (initial): one
+EOF
+test_expect_success 'using --date= shows reflog date (multiline)' '
+	git log -g -1 --date=raw >tmp &&
+	grep ^Reflog <tmp >actual &&
+	test_cmp expect actual
+'
+
+cat >expect <<'EOF'
+e46513e HEAD@{1112911993 -0700}: commit (initial): one
+EOF
+test_expect_success 'using --date= shows reflog date (oneline)' '
+	git log -g -1 --oneline --date=raw >actual &&
+	test_cmp expect actual
+'
+
+test_done
-- 
1.6.2.1.342.gdbf4

Re: Gnome chose Git

[Michael J Gruber]

Jeff King venit, vidit, dixit 19.03.2009 21:14:
> On Thu, Mar 19, 2009 at 09:50:39AM -0600, Pat Notz wrote:
> 
>> On Thu, Mar 19, 2009 at 9:16 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
>>>
>>> Why are people reinventing the reflog, and core.logallrefupdates ?
>>>
>>
>> Hmmm, lack of awareness of core.logallrefupdates in my case.  Thanks
>> for the pointer.
> 
> But do note that reflogs expire eventually, so you will want to also
> look at gc.reflogexpire and gc.reflogexpireunreachable if you want to
> keep this as an activity log forever.
> 
> -Peff

In any case, reflogs are local. I would assume that accountability
tracking should be public and transparent. Depends on the use case, of
course.

Michael

Re: Gnome chose Git

[Jeff King]

On Fri, Mar 20, 2009 at 09:33:16AM +0100, Michael J Gruber wrote:

> > But do note that reflogs expire eventually, so you will want to also
> > look at gc.reflogexpire and gc.reflogexpireunreachable if you want to
> > keep this as an activity log forever.
> 
> In any case, reflogs are local. I would assume that accountability
> tracking should be public and transparent. Depends on the use case, of
> course.

I think the use case was auditing "when did this code get into the repo,
and by whom". Which is inherently a local thing, since you are talking
about when it got into a central repo.

As for public and transparent, reflogs are only the database mechanism;
git already has the hooks in place for writing every ref change to this
mechanism, and it stores everything you need.  They would just need some
way of publishing the information. I think it was you who suggested
notes, which would be one way of doing so; you could also publish tags
indexed by pusher (since we may or may not actually care about fast
lookup from commit to pusher here), or even just a web page.

-Peff