Gnome chose Git
FYI: The Gnome release team just announced that Gnome will migrate from Subversion to Git:
http://thread.gmane.org/gmane.comp.gnome.infrastructure/1134
Teemu Likonen venit, vidit, dixit 19.03.2009 12:23:
Quoted 4 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 30 lines · Michael J Gruber
Pat Notz venit, vidit, dixit 19.03.2009 14:43:
Quoted 21 lines
Quoted 10 lines · Michael J Gruber
Teemu Likonen venit, vidit, dixit 19.03.2009 12:23:
Quoted 4 lines
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.
Quoted 8 lines
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"?
Quoted 7 lines
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).
Quoted 4 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.
Quoted 4 lines
Michael
P.S.: Was this intentionally off-list? Just in case I respected it.
Oops, sorry about that. Fixed.
Quoted 14 lines · Pat Notz
Quoted 12 lines · Michael J Gruber
Pat Notz venit, vidit, dixit 19.03.2009 14:43:
Quoted 11 lines
Quoted 8 lines · Michael J Gruber
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"?
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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 ?
Quoted 5 lines
Quoted 3 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
Signature · 1 line
Shawn.
Quoted 3 lines · Shawn O. Pearce
Why are people reinventing the reflog, and core.logallrefupdates ?
Hmmm, lack of awareness of core.logallrefupdates in my case. Thanks for the pointer.
~ Pat
Quoted 7 lines · Pat Notz
Quoted 3 lines · Shawn O. Pearce
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
2009/3/19 Jeff King <[email protected]>:
Quoted 7 lines · Pat Notz
Quoted 6 lines · Shawn O. Pearce
Quoted 3 lines
Why are people reinventing the reflog, and core.logallrefupdates ?
Quoted 6 lines
Quoted 2 lines
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
Signature · 1 line
perl -Mre=debug -e "/just|another|perl|hacker/"
Quoted 5 lines · demerphq
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.
Signature · 1 line
Shawn.
Quoted 8 lines · Shawn O. Pearce
Quoted 5 lines · demerphq
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}Quoted 1 line
the @{now} suffix is the magic to make it show the time.
Signature · 1 line
Shawn.
2009/3/19 Shawn O. Pearce <[email protected]>:
Quoted 6 lines
Quoted 5 lines · Shawn O. Pearce
Quoted 4 lines · demerphq
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?
Quoted 9 lines
Quoted 3 lines
Quoted 1 line
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}
Quoted 1 line
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
Signature · 1 line
perl -Mre=debug -e "/just|another|perl|hacker/"
Quoted 9 lines · demerphq
2009/3/19 Shawn O. Pearce <[email protected]>:
Quoted 3 lines
"Shawn O. Pearce" <[email protected]> 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.
Signature · 1 line
Shawn.
2009/3/19 Shawn O. Pearce <[email protected]>:
Quoted 6 lines
Quoted 5 lines · demerphq
2009/3/19 Shawn O. Pearce <[email protected]>:
Quoted 3 lines
"Shawn O. Pearce" <[email protected]> wrote:
git log -g branch@{now}
Quoted 7 lines
Quoted 4 lines
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
Signature · 1 line
perl -Mre=debug -e "/just|another|perl|hacker/"
Hi,
Quoted 13 lines · demerphq
2009/3/19 Shawn O. Pearce <[email protected]>:
Quoted 12 lines
Quoted 8 lines · Shawn O. Pearce
Quoted 5 lines · demerphq
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
Quoted 8 lines
Quoted 3 lines
git log -g branch@{now}
Quoted 1 line
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
2009/3/19 Shawn O. Pearce <[email protected]>:
Quoted 10 lines
Quoted 5 lines · demerphq
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 contemporaryBut thanks a lot for the info. I take this is documented in a newer release than i currently have?
Yves
Signature · 1 line
perl -Mre=debug -e "/just|another|perl|hacker/"
Quoted 10 lines · Shawn O. Pearce
Quoted 5 lines · demerphq
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:
reflog-walk.c +2 -0
@@ -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 forwardHmm. 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 1/1 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 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
--- 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
reflog-walk.c +7 -5
@@ -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);
reflog-walk.h +4 -1
@@ -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
t/t1411-reflog-show.sh new file +67 -0
67 lines not on this page · raw message
Signature · 1 line
1.6.2.1.342.gdbf4
Jeff King venit, vidit, dixit 19.03.2009 21:14:
Quoted 7 lines · Pat Notz
Quoted 6 lines · Shawn O. Pearce
Quoted 3 lines
Why are people reinventing the reflog, and core.logallrefupdates ?
Quoted 8 lines
Quoted 2 lines
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
Quoted 7 lines · Michael J Gruber
Quoted 3 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
2009/3/19 Teemu Likonen <[email protected]>:
Quoted 4 lines
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
Quoted 11 lines · Mike Ralphson
2009/3/19 Teemu Likonen <[email protected]>:
Quoted 4 lines
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."
Quoted 8 lines
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.
Signature · 7 lines
Andreas Ericsson [email protected] 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.
Heya,
Quoted 4 lines · 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
Sweet, now how long until my university starts offering git hosting and my fellow students start using it in their projects? :P
Signature · 3 lines
Cheers, Sverre Rabbelier