Just to clarify: last year we were co-mentoring with Ram. I ended up
having a lot of time and did most of the work (not blaming Ram, and I
enjoyed the experience). I'm still motivated to co-mentor, but this time
the co-mentoring has to be more balanced (or unballanced to the other
mentor ;-) ).
- Junio, who contributed some project ideas, but who in the past has
declined to mentor in order to remain impartial as the maintainer
who evaluates student results (which I think is quite reasonable)
Yes, as a mentor I did appreciate having Junio as impartial
maintainer/reviewer. And he did for sure contribute even without being a
mentor!
From your list, it seems we can target 1 or 2 slots. I'd say it's still
From: Jeff King <hidden> Date: 2016-06-15 23:03:52
On Fri, Feb 20, 2015 at 10:39:42AM +0100, Matthieu Moy wrote:
Jeff King [off-list ref] writes:
quoted
- Matthieu, who also cited time constraints
Just to clarify: last year we were co-mentoring with Ram. I ended up
having a lot of time and did most of the work (not blaming Ram, and I
enjoyed the experience). I'm still motivated to co-mentor, but this time
the co-mentoring has to be more balanced (or unballanced to the other
mentor ;-) ).
Yes, but who is your co-mentor this year? :)
From your list, it seems we can target 1 or 2 slots. I'd say it's still
worth applying, but if we don't find more mentors then perhaps it would
make sense to say so explicitely in
http://git.github.io/SoC-2015-Ideas.html so that students looking for
organization know that we'll have very few slots.
I don't mind doing 1 slot if that's what we have resources for. But if
we have to say "eh, we do not really have enough mentors to support
you", then I wonder if it is worth doing. They do not know how many
people have applied, or how tight the competition is.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 23:03:53
On Fri, Feb 20, 2015 at 04:48:44AM -0500, Jeff King wrote:
quoted
From your list, it seems we can target 1 or 2 slots. I'd say it's still
worth applying, but if we don't find more mentors then perhaps it would
make sense to say so explicitely in
http://git.github.io/SoC-2015-Ideas.html so that students looking for
organization know that we'll have very few slots.
I don't mind doing 1 slot if that's what we have resources for. But if
we have to say "eh, we do not really have enough mentors to support
you", then I wonder if it is worth doing. They do not know how many
people have applied, or how tight the competition is.
So that being said, I did complete the application. We can still
withdraw if we want before students start applying, or we can put a
disclaimer on the ideas page.
I tweaked the application text to update it for this year, but nothing
too major. The result is at:
http://git.github.io/SoC-2015-Org-Application.html
That content was cut-and-pasted into Google's application interface.
Matthieu, as backup admin you should have access to tweak that if there
are typos, etc (and I will probably not be available to apply fixes from
now until the deadline, so please do so if you see anything).
We can continue to improve the ideas page as time goes on. At some point
Google will look at as part of the application, but probably not right
at the deadline. :)
-Peff
From: Philip Oakley <hidden> Date: 2016-06-15 23:03:59
From: "Matthieu Moy" <redacted>
Sent: Friday, February 20, 2015 9:39 AM
Jeff King [off-list ref] writes:
quoted
- Matthieu, who also cited time constraints
Just to clarify: last year we were co-mentoring with Ram. I ended up
having a lot of time and did most of the work (not blaming Ram, and I
enjoyed the experience). I'm still motivated to co-mentor, but this
time
the co-mentoring has to be more balanced (or unballanced to the other
mentor ;-) ).
quoted
- Junio, who contributed some project ideas, but who in the past
has
declined to mentor in order to remain impartial as the maintainer
who evaluates student results (which I think is quite reasonable)
Yes, as a mentor I did appreciate having Junio as impartial
maintainer/reviewer. And he did for sure contribute even without being
a
mentor!
From your list, it seems we can target 1 or 2 slots. I'd say it's
still
worth applying, but if we don't find more mentors then perhaps it
would
make sense to say so explicitely in
http://git.github.io/SoC-2015-Ideas.html so that students looking for
organization know that we'll have very few slots.
--
Hi,
Given the mention of the GSoC ideas list, I thought it worth writing out
one of my little ideas..
A possible idea is to add a date based variant of shallow clone :
'git clone --date <when> ...'
in the same vein as the existing depth (shallow) clone.
On the wire advertise a 'shallow-date' capability, passing a signed big
integer as the unix time for the shallow cut-off point (i.e. future
extensible to cover a very wide date range), with optional(?) date+depth
hysteresis (clock skew) parameters.
Command line interface to use existing date/time formats, (and possibly
revision dates?).
Extend 'git fetch' to include the --date <when> option.
Ensure that 'git push' continues to work with and between
shallow/shallow-date clones.
Update the documentation in line with the capability.
Document any migration plan (if required)
Why
===
This capability would eliminate the existing confusion over the --depth
parameter as different branches may require different depths to reach a
"common" start point.
Extra points for an easy method of '--unshallow-date <new_when>' to
remove 'old' commits that the user may no longer need locally.
(unshallow may not be the right term...)
--
Philip
From: Stefan Beller <hidden> Date: 2016-06-15 23:03:59
On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley [off-list ref] wrote:
A possible idea is to add a date based variant of shallow clone :
'git clone --date <when> ...'
in the same vein as the existing depth (shallow) clone.
As food for thought:
Maybe broaden this further up to the git-ish way of describing refs, so
git clone --since 2.weeks.ago <url>
git clone --since v2.10 <url>
git clone --since c0ffee^^ <url>
would all equally work?
I am not sure if that is feasible though, but it would come in handy. (E.g.
you are an end user and want to bisect down a bug which you notice in the
new version X but not in old version Y, so you start on getting the sources,
compiling, bisecting)
From: Philip Oakley <hidden> Date: 2016-06-15 23:03:59
From: "Stefan Beller" <redacted>
On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley [off-list ref]
wrote:
quoted
A possible idea is to add a date based variant of shallow clone :
'git clone --date <when> ...'
in the same vein as the existing depth (shallow) clone.
As food for thought:
Maybe broaden this further up to the git-ish way of describing refs,
so
git clone --since 2.weeks.ago <url>
git clone --since v2.10 <url>
git clone --since c0ffee^^ <url>
would all equally work?
The use of --since instead of --date would be an equally valid way of
spelling the option (coders choice;-)
At the clone stage, the local Git can't determine (for the 2nd & 3d
option) where such a revison is located, so would have to send the
revision string to the server for processing, which could complicate the
protocol. Hence my choice of a simple unix time value at the protocol
level.
An alternate/addition is to use a nominated sha1 (from ls-remote) as a
stand in for a date, allowing your option 2 (--since <tag>) to be
implemented as an alias or script.
It all depends on how complicated we want it to become, but starting
simple (though extensible) is important.
I am not sure if that is feasible though, but it would come in handy.
(E.g.
you are an end user and want to bisect down a bug which you notice in
the
new version X but not in old version Y, so you start on getting the
sources,
compiling, bisecting)
--
The use of --since instead of --date would be an equally valid way of
spelling the option (coders choice;-)
I think it is a demonstration of poor taste. Everywhere else, --since
is a way to
specify the date, not a revision. Why should this one alone should be different?
On Thu, Mar 5, 2015 at 6:55 AM, Stefan Beller [off-list ref] wrote:
On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley [off-list ref] wrote:
quoted
A possible idea is to add a date based variant of shallow clone :
'git clone --date <when> ...'
in the same vein as the existing depth (shallow) clone.
As food for thought:
Maybe broaden this further up to the git-ish way of describing refs, so
git clone --since 2.weeks.ago <url>
git clone --since v2.10 <url>
git clone --since c0ffee^^ <url>
would all equally work?
Yes, and we could generalize it further: add shallow-rev-list
capability and send "shallow-rev-list <rev-list options and _some_
rev>" line to define shallow boundary. The protocol change would be
simple enough. The hard part is select a safe subset of rev-list
options that can be used in this mode and reject the rest.
I am not sure if that is feasible though, but it would come in handy. (E.g.
you are an end user and want to bisect down a bug which you notice in the
new version X but not in old version Y, so you start on getting the sources,
compiling, bisecting)
The use of --since instead of --date would be an equally valid way of
spelling the option (coders choice;-)
I think it is a demonstration of poor taste. Everywhere else, --since
is a way to
specify the date, not a revision. Why should this one alone should be different?
I wanted to point out the broader use case than being stylish correct,
though from
an English grammars point of view `--since` should also be able to
describe a point
in time ("since 2 weeks ago" is as valid as "since Feb 17th")
I cannot remember the usual option off hand to describe the revision
instead of a date.
Maybe we want to have one option long term to allow any kind of input (revision
and date), as this may be easier to remember, especially if it aligns well with
the English language.
On Thu, Mar 5, 2015 at 5:05 AM, Philip Oakley [off-list ref] wrote:
Given the mention of the GSoC ideas list, I thought it worth writing out one
of my little ideas..
A possible idea is to add a date based variant of shallow clone :
'git clone --date <when> ...'
in the same vein as the existing depth (shallow) clone.
I do have plenty of topics to finish up. But I wanted to see how this
feature would look like. I needed to write some code for that and for
straightening my thoughts. Totally untested, but I think it looks cool :)
I think this feature is feasible. The protocol and UI are still up in
the air. Plenty of work for any student who wants to pick this up.
Nguyễn Thái Ngọc Duy (6):
upload-pack: move shallow deepen code out of receive_needs()
upload-pack: move "shallow" sending code out of deepen()
upload-pack: remove unused variable "backup"
upload-pack: move "unshallow" sending code out of deepen()
shallow.c: implement a generic shallow boundary finder based on rev-list
upload-pack: example code to use get_shallow_commits_by_rev_list
commit.h | 2 +
shallow.c | 65 +++++++++++++++++++++++++++++
upload-pack.c | 129 +++++++++++++++++++++++++++++++++++++---------------------
3 files changed, 149 insertions(+), 47 deletions(-)
--
2.3.0.rc1.137.g477eb31
Instead of a custom commit walker like get_shallow_commits(), this new
function uses rev-list to mark SHALLOW to all reachable commits. The
definition of reachable is to be defined by the protocol later. This
makes it more flexible to define shallow boundary.
Note: if a commit has one not_shallow parent and one shallow parent,
then it's considered the boundary. Which means in the client side,
this commit has _no_ parents. This could lead to surprising cuts if
we're not careful.
Another option is to include more commits and only mark commits whose
all parents are not-shallow as boundary.
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
commit.h | 2 ++
shallow.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 67 insertions(+)
@@ -137,6 +139,69 @@ struct commit_list *get_shallow_commits(struct object_array *heads, int depth,returnresult;}+staticvoidshow_commit(structcommit*commit,void*data)+{+commit->object.flags|=*(int*)data;+}++structcommit_list*get_shallow_commits_by_rev_list(intac,constchar**av,+intshallow_flag,intnot_shallow_flag)+{+structcommit_list*result=NULL;+structrev_inforevs;+unsignedinti,nr;++/*+*SHALLOWandNOT_SHALLOWshouldnotbesetatthis+*point.Butbetterbesafethansorry.+*/+nr=get_max_object_index();+for(i=0;i<nr;i++){+structobject*o=get_indexed_object(i);+o->flags&=~(shallow_flag|not_shallow_flag);+}++is_repository_shallow();/* make sure shallows are read */++init_revisions(&revs,NULL);+save_commit_buffer=0;+setup_revisions(ac,av,&revs,NULL);++/* mark all reachable commits as SHALLOW */+if(prepare_revision_walk(&revs))+die("revision walk setup failed");+traverse_commit_list(&revs,show_commit,NULL,&shallow_flag);++nr=get_max_object_index();+for(i=0;i<nr;i++){+structobject*o=get_indexed_object(i);+structcommit*c=(structcommit*)o;+structcommit_list*p;+intparent_is_not_shallow=0;++if(o->type!=OBJ_COMMIT||!(o->flags&shallow_flag))+continue;++if(parse_commit(c))+die("unable to parse commit %s",+sha1_to_hex(c->object.sha1));++for(p=c->parents;p;p=p->next){+if(p->item->object.flags&shallow_flag)+continue;+parent_is_not_shallow=1;+if(p->item->object.flags¬_shallow_flag)+continue;+p->item->object.flags|=not_shallow_flag;+commit_list_insert(p->item,&result);+}++if(parent_is_not_shallow)+commit_list_insert(c,&result);+}+returnresult;+}+staticvoidcheck_shallow_file_for_update(void){if(is_shallow==-1)
This is a prep step for further refactoring. Besides reindentation and
s/shallows\./shallows->/g, no other changes are expected.
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
upload-pack.c | 99 +++++++++++++++++++++++++++++++----------------------------
1 file changed, 52 insertions(+), 47 deletions(-)
@@ -531,6 +531,55 @@ error:}}+staticvoiddeepen(intdepth,conststructobject_array*shallows)+{+structcommit_list*result=NULL,*backup=NULL;+inti;+if(depth==INFINITE_DEPTH&&!is_repository_shallow())+for(i=0;i<shallows->nr;i++){+structobject*object=shallows->objects[i].item;+object->flags|=NOT_SHALLOW;+}+else+backup=result=+get_shallow_commits(&want_obj,depth,+SHALLOW,NOT_SHALLOW);+while(result){+structobject*object=&result->item->object;+if(!(object->flags&(CLIENT_SHALLOW|NOT_SHALLOW))){+packet_write(1,"shallow %s",+sha1_to_hex(object->sha1));+register_shallow(object->sha1);+shallow_nr++;+}+result=result->next;+}+free_commit_list(backup);+for(i=0;i<shallows->nr;i++){+structobject*object=shallows->objects[i].item;+if(object->flags&NOT_SHALLOW){+structcommit_list*parents;+packet_write(1,"unshallow %s",+sha1_to_hex(object->sha1));+object->flags&=~CLIENT_SHALLOW;+/* make sure the real parents are parsed */+unregister_shallow(object->sha1);+object->parsed=0;+parse_commit_or_die((structcommit*)object);+parents=((structcommit*)object)->parents;+while(parents){+add_object_array(&parents->item->object,+NULL,&want_obj);+parents=parents->next;+}+add_object_array(object,NULL,&extra_edge_obj);+}+/* make sure commit traversal conforms to client */+register_shallow(object->sha1);+}+packet_flush(1);+}+staticvoidreceive_needs(void){structobject_arrayshallows=OBJECT_ARRAY_INIT;
@@ -623,53 +672,9 @@ static void receive_needs(void)if(depth==0&&shallows.nr==0)return;-if(depth>0){-structcommit_list*result=NULL,*backup=NULL;-inti;-if(depth==INFINITE_DEPTH&&!is_repository_shallow())-for(i=0;i<shallows.nr;i++){-structobject*object=shallows.objects[i].item;-object->flags|=NOT_SHALLOW;-}-else-backup=result=-get_shallow_commits(&want_obj,depth,-SHALLOW,NOT_SHALLOW);-while(result){-structobject*object=&result->item->object;-if(!(object->flags&(CLIENT_SHALLOW|NOT_SHALLOW))){-packet_write(1,"shallow %s",-sha1_to_hex(object->sha1));-register_shallow(object->sha1);-shallow_nr++;-}-result=result->next;-}-free_commit_list(backup);-for(i=0;i<shallows.nr;i++){-structobject*object=shallows.objects[i].item;-if(object->flags&NOT_SHALLOW){-structcommit_list*parents;-packet_write(1,"unshallow %s",-sha1_to_hex(object->sha1));-object->flags&=~CLIENT_SHALLOW;-/* make sure the real parents are parsed */-unregister_shallow(object->sha1);-object->parsed=0;-parse_commit_or_die((structcommit*)object);-parents=((structcommit*)object)->parents;-while(parents){-add_object_array(&parents->item->object,-NULL,&want_obj);-parents=parents->next;-}-add_object_array(object,NULL,&extra_edge_obj);-}-/* make sure commit traversal conforms to client */-register_shallow(object->sha1);-}-packet_flush(1);-}else+if(depth>0)+deepen(depth,&shallows);+elseif(shallows.nr>0){inti;for(i=0;i<shallows.nr;i++)