FYI: The Gnome release team just announced that Gnome will migrate from Subversion to Git:
http://thread.gmane.org/gmane.comp.gnome.infrastructure/1134
Sverre RabbelierRe: Gnome chose Git
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
Mike RalphsonRe: Gnome chose Git
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
Andreas EricssonRe: Gnome chose Git
Mike Ralphson wrote:
Show 19 quoted lines
> 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.
Michael J GruberRe: Gnome chose Git
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
Pat NotzRe: Gnome chose Git
On Thu, Mar 19, 2009 at 7:50 AM, Michael J Gruber <git@drmicha.warpmail.net> wrote:
Show 34 quoted lines
> 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.
Shawn O. PearceRe: Gnome chose Git
Pat Notz <patnotz@gmail.com> wrote:
Show 20 quoted lines
> 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 ?
Show 5 quoted lines
> > 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.
Pat NotzRe: Gnome chose Git
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
Jeff KingRe: Gnome chose Git
On Thu, Mar 19, 2009 at 09:50:39AM -0600, Pat Notz wrote:
Show 7 quoted lines
> 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
2009/3/19 Jeff King <peff@peff.net>:
Show 13 quoted lines
> 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/"
Shawn O. PearceRe: Gnome chose Git
demerphq <demerphq@gmail.com> wrote:
Show 5 quoted lines
> 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.
Shawn O. PearceRe: Gnome chose Git
"Shawn O. Pearce" <spearce@spearce.org> wrote:
Show 8 quoted lines
> 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
2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
Show 15 quoted lines
> "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/"
Shawn O. PearceRe: Gnome chose Git
demerphq <demerphq@gmail.com> wrote:
Show 9 quoted lines
> 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
2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
Show 13 quoted lines
> 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/"
Johannes SchindelinRe: Gnome chose Git
Hi,
On Thu, 19 Mar 2009, demerphq wrote:
Show 21 quoted lines
> 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
2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
Show 10 quoted lines
> 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/"
Jeff KingRe: Gnome chose Git
On Thu, Mar 19, 2009 at 02:43:17PM -0700, Shawn O. Pearce wrote:
Show 10 quoted lines
> 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
Jeff King[PATCH] make oneline reflog dates more consistent with multiline format
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
reflog2. 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
Michael J GruberRe: Gnome chose Git
Jeff King venit, vidit, dixit 19.03.2009 21:14:
Show 15 quoted lines
> 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
Jeff KingRe: Gnome chose Git
On Fri, Mar 20, 2009 at 09:33:16AM +0100, Michael J Gruber wrote:
Show 7 quoted lines
> > 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