* Re: Lightweight tag ?
From: Michael J Gruber @ 2009-01-12 12:55 UTC (permalink / raw)
To: Francis Moreau; +Cc: Junio C Hamano, git
In-Reply-To: <m2bpucnas2.fsf@gmail.com>
Francis Moreau venit, vidit, dixit 01/12/09 10:17:
> Hello,
>
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Don't use explicit --tags blindly. It says "no matter what kind of tag,
>> transfer everything under refs/tags". Otherwise you won't see a
>> difference.
>
> Well:
>
> $ git --version
> git version 1.6.0.4
> $ mkdir test-tag
> $ cd test-tag/
> $ date > A
> $ git init
> Initialized empty Git repository in
> /home/fmoreau/tmp/git/test-tag/.git/
> $ git add .
> $ git commit -a -s -m "Init"
> Created initial commit be8750e: Init
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 A
> $ cd ..
> $ git clone --bare test-tag test-tag.git
> Initialized empty Git repository in /home/fmoreau/tmp/git/test-tag.git/
> $ cd test-tag
> $ git tag light
>
> $ git tag -a -m "Annoted tag" annoted
> $ git push ../test-tag.git
> Everything up-to-date
> $ git push --tags ../test-tag.git
> Counting objects: 1, done.
> Writing objects: 100% (1/1), 166 bytes, done.
> Total 1 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (1/1), done.
> To ../test-tag.git
> * [new tag] annoted -> annoted
> * [new tag] light -> light
>
> It looks like they're no difference for git-push...
>
> That said the documentation about this is rather cryptic IMHO:
>
> ,----[ man git-push ]
> | --tags
> | All refs under $GIT_DIR/refs/tags are pushed, in
> | addition to refspecs explicitly listed on the command
> | line.
> `----
>
> From a user point of view, the word lightweight is missing here. Why
> not simply saying:
>
> ,----
> | All kind of tags are pushed with this option _otherwise_ only annoted
> | tags are pushed
> `----
Your test above confirms that the description is correct and nothing is
missing. "git push" pushes explicitly listed refspecs (or : as a
default). It pushes tags (light and heavy) when asked to.
"git pull" pulls tags if they can be reached from heads which are
pulled. It pulls all tags only when asked to.
In fact, the automatic following of tags (if they can be reached...)
depends on the transport, because typically you want to clone everything
if you clone locally but don't want all tags if you clone/pull from a
remote. There is also a config "tagopt" for overriding this. It's
mentioned but not really explained in "git tag"'s man page.
So, "non-local" tags are the ones which can be reached from heads which
you pull, and local ones are the others. I don't think lightweight tags
are more local than tag objects (please correct me if I'm wrong; I think
this needs more doc). It's just that the latter reside in the object db
store whereas the former are simple refs under refs/tags.
Michael
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Christian Couder @ 2009-01-12 13:01 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, Shawn O. Pearce, git, Stephan Beyer,
Daniel Barkalow
In-Reply-To: <alpine.DEB.1.00.0901102058220.3586@pacific.mpi-cbg.de>
Hi,
Le samedi 10 janvier 2009, Johannes Schindelin a écrit :
> Hi,
>
> On Sat, 10 Jan 2009, Jakub Narebski wrote:
> > "Shawn O. Pearce" <spearce@spearce.org> writes:
> > > The application answers really need to be reworked; we need to
> > > address our 2008 results in these parts.
> >
> > By the way, do you know what happened with git-sequencer project?
>
> -- snip --
> commit 3bfd6761ce2f769746c6b84be97f7da0cad7cad1
> Author: Stephan Beyer <s-beyer@gmx.net>
> Date: Wed Jan 7 19:07:31 2009 +0100
>
> builtin-sequencer.c/prepare_commit_msg_hook: tiny simplification
>
> Thanks to Christian.
> -- snap --
Yes, Stephan, Daniel and me are still working on it but very slowly.
You can see what happens on the repo here:
http://repo.or.cz/w/git/sbeyer.git?a=shortlog;h=refs/heads/seq-builtin-dev
May be we should move our discussions, patches and everything on the git
mailing list as it may motivate us and people on the list to help.
One good thing too would be if Stephan could share is todo list.
By the way don't hesitate to put us in CC :-)
Regards,
Christian.
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Christian Couder @ 2009-01-12 13:20 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Shawn O. Pearce, git
In-Reply-To: <496B2690.2010902@op5.se>
Le lundi 12 janvier 2009, Andreas Ericsson a écrit :
> Just chiming in that I can probably help mentoring whoever goes
> with libgit2. I do not have enough spare time for me to promise
> that I can be there as much as I think is necessary and proper,
> but I'll gladly help out.
>
> On a side-note, I think all mentors should urge the students in
> the strongest possible terms to deliver their work to git@vger
> as soon as possible.
I agree, but I think there is also a merge problem. I mean we should also
perhaps urge students to get what they have done merged as soon as possible
even if it means that they rework 5 or 10 time the code instead of
developing features according to the schedule.
But unfortunately even something merged into next can be removed afterwards,
so it's really difficult, because big features cannot for obvious reasons
be merged into master and the git release cycle doesn't always go along
well with the GSoC schedule.
> From previous years experience, successful
> projects are those that the list sees code from within a week
> or two after the project's started, while the projects that are
> kept in the dark rarely (if ever?) finish successfully.
I don't think things are so simple.
Regards,
Christian.
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Johannes Schindelin @ 2009-01-12 13:25 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Shawn O. Pearce, git
In-Reply-To: <496B2690.2010902@op5.se>
Hi,
On Mon, 12 Jan 2009, Andreas Ericsson wrote:
> Just chiming in that I can probably help mentoring whoever goes with
> libgit2. I do not have enough spare time for me to promise that I can be
> there as much as I think is necessary and proper, but I'll gladly help
> out.
I don't know if I like co-mentoring; I always had the impression that this
does not work all that well.
> On a side-note, I think all mentors should urge the students in the
> strongest possible terms to deliver their work to git@vger as soon as
> possible. From previous years experience, successful projects are those
> that the list sees code from within a week or two after the project's
> started, while the projects that are kept in the dark rarely (if ever?)
> finish successfully.
Nope, that is just plainly incorrect.
The most successful GSoC project we had was Miklos' builtin-merge, but the
code had to grow to a state that both him and me were comfortable with a
submission to git@vger.
The _communication_ should be open, and much of it on the mailing list, I
agree, but _only_ after the student is familiar enough with the aspects of
her project (including some familiarity with the source code).
I will _not_ force a student to ask questions openly that he finds
embarassing.
Ciao,
Dscho
^ permalink raw reply
* Re: git submodule merge madness
From: Andreas Ericsson @ 2009-01-12 13:27 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: git
In-Reply-To: <ADC7A3B1-6756-4258-93CD-DB40C7D2793C@develooper.com>
Ask Bjørn Hansen wrote:
> Hi,
>
> We've (again) replaced a few directories with submodules. Man, it's
> madness!
>
> The typical problem is that we get an error trying to merge a
> "pre-submodule" branch into master:
>
> fatal: cannot read object 894c77319a18c4d48119c2985a9275c9f5883584
> 'some/sub/dir': It is a submodule!
> Mark Levedahl wrote an example in July, but I don't think he got any
> replies: http://marc.info/?l=git&m=121587851313303
> Any ideas? Is there something we can do? I see a strong correlation
> between adding a new submodule and the number of "git sucks" messages on
> our internal IRC server.
>
Well, reworking the repository structure (which is essentially what you're
doing) should be a flag day. Merge stuff before that and mark it in some
way so that you don't run into the problems you're seeing now.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/2] grep: don't call regexec() for fixed strings
From: Johannes Schindelin @ 2009-01-12 13:33 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: René Scharfe, Git Mailing List, Junio C Hamano
In-Reply-To: <237967ef0901120425x79b7c1a4p238081a99694ae23@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 844 bytes --]
Hi,
On Mon, 12 Jan 2009, Mikael Magnusson wrote:
> 2009/1/10 René Scharfe <rene.scharfe@lsrfire.ath.cx>:
> > Add the new flag "fixed" to struct grep_pat and set it if the pattern
> > is doesn't contain any regex control characters in addition to if the
> > flag -F/--fixed-strings was specified.
> >
> > diff --git a/grep.c b/grep.c
> > index 394703b..a1092df 100644
> > --- a/grep.c
> > +++ b/grep.c
> > @@ -28,9 +28,31 @@ void append_grep_pattern(struct grep_opt *opt, const char *pat,
> > p->next = NULL;
> > }
> >
> > +static int isregexspecial(int c)
> > +{
> > + return isspecial(c) || c == '$' || c == '(' || c == ')' || c == '+' ||
> > + c == '.' || c == '^' || c == '{' || c == '|';
> > +}
>
> Shouldn't this include '*' and '\'?
This is covered by isspecial(): see ctype.c.
Hth,
Dscho
^ permalink raw reply
* Re: git-svn: File was not found in commit
From: Morgan Christiansson @ 2009-01-12 13:45 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090112051409.GB14992@dcvr.yhbt.net>
[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]
Eric Wong wrote:
> Eric Wong <normalperson@yhbt.net> wrote:
>
>> Morgan Christiansson <git@mog.se> wrote:
>>
>>> The "Ignoring path" message appears to be coming from git which is
>>> refusing to commit the .git directory. Which leads to git-svn being
>>> unaware of the files being ignored and giving an error when it can't
>>> find them.
>>>
>>> I'm personally fine with these files being ignored by git, but git-svn
>>> needs to be aware that they are not added to the repository.
>>>
>> Hi Morgan,
>> Can you try the following rough patch and see it it fixes things
>> for you? Thanks!
>>
>
> Actually, I think this patch is broken (my quickly put together test
> case was insufficient)...
>
Yes it was. apply_textdelta() is never called for my repo so it has no
effect.
I've attached an updated and simplified version of the testcase you sent
that correctly triggers the bug i reported.
I'm not a native perl coder though so I don't think I would be able to
provide a clean fix for this. But I've traced through enough of the
program to see that the .git directories should be filtered out as early
as possible to mimick the behaviour of git.
get_log() has a callback as it's last argument which gets called once
per commit, nesting this callback in a new callback which filters the
illegal paths out would work.
Also in gs_do_fetch_loop_common() after get_log() and before
do_git_commit() it's possible to filter them.
Regards,
Morgan
[-- Attachment #2: t9133-git-svn-nested-git-repo.sh --]
[-- Type: application/x-sh, Size: 495 bytes --]
^ permalink raw reply
* Re: Lightweight tag ?
From: Francis Moreau @ 2009-01-12 13:56 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <496B3DA8.1040308@drmicha.warpmail.net>
On Mon, Jan 12, 2009 at 1:55 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Your test above confirms that the description is correct and nothing is
> missing. "git push" pushes explicitly listed refspecs (or : as a
> default). It pushes tags (light and heavy) when asked to.
>
So do you mean that the only way I have for pushing annoted tags only is
to do:
$ git push origin refs/tags/annoted
That's not what Junio said:
Don't use explicit --tags blindly. It says "no matter what kind of tag,
transfer everything under refs/tags". Otherwise you won't see a
difference.
So I interpret this like don't use --tags otherwise lightweight and annoted tags
are the same.
> "git pull" pulls tags if they can be reached from heads which are
> pulled. It pulls all tags only when asked to.
>
[...]
> So, "non-local" tags are the ones which can be reached from heads which
> you pull, and local ones are the others.
So I can't create a local tag on public heads (the ones I'm pushing
out), can I ?
> I don't think lightweight tags are more local than tag objects
> (please correct me if I'm wrong; I think this needs more doc)
Perhaps it needs documents which are more user friendly: I don't know where
the 'lightweight' word is coming from (perhaps from the implementation) but
I would expect that the _local_ term appears in the git-tag manual.
> It's just that the latter reside in the object db
> store whereas the former are simple refs under refs/tags.
That's implementation detail...
I just need to create a local tag where I'm sure it won't be seen by others
whatever the git operations I'm doing, normally a simple "git tag" switch
should be enough...
thanks.
--
Francis
^ permalink raw reply
* [PATCH next] notes: fix core.notesRef documentation
From: Thomas Rast @ 2009-01-12 14:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
The path format was inconsistent with the one used in git-notes.sh: it
supposedly split the sha1 in the same 2/38 format that .git/objects
uses, but the code uses the full sha1 without a path separator.
While at it, also fix a grammatical error.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/config.txt | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index acfeb77..348da77 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -424,15 +424,13 @@ overlapping IO's.
core.notesRef::
When showing commit messages, also show notes which are stored in
- the given ref. This ref is expected to contain paths of the form
- ??/*, where the directory name consists of the first two
- characters of the commit name, and the base name consists of
- the remaining 38 characters.
+ the given ref. This ref is expected to contain files named
+ after the full SHA-1 of the commit they annotate.
+
-If such a path exists in the given ref, the referenced blob is read, and
+If such a file exists in the given ref, the referenced blob is read, and
appended to the commit message, separated by a "Notes:" line. If the
given ref itself does not exist, it is not an error, but means that no
-notes should be print.
+notes should be printed.
+
This setting defaults to "refs/notes/commits", and can be overridden by
the `GIT_NOTES_REF` environment variable.
--
tg: (1063ea4..) t/notes-doc-fix (depends on: next)
^ permalink raw reply related
* Re: [PATCH next] notes: fix core.notesRef documentation
From: Johannes Schindelin @ 2009-01-12 14:41 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <1231769764-17294-1-git-send-email-trast@student.ethz.ch>
Hi,
On Mon, 12 Jan 2009, Thomas Rast wrote:
> The path format was inconsistent with the one used in git-notes.sh: it
> supposedly split the sha1 in the same 2/38 format that .git/objects
> uses, but the code uses the full sha1 without a path separator.
>
> While at it, also fix a grammatical error.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Thanks,
Dscho
^ permalink raw reply
* Re: Lightweight tag ?
From: Michael J Gruber @ 2009-01-12 14:54 UTC (permalink / raw)
To: Francis Moreau; +Cc: Junio C Hamano, git
In-Reply-To: <38b2ab8a0901120556x279f320oe693304dd2452050@mail.gmail.com>
Francis Moreau venit, vidit, dixit 01/12/09 14:56:
> On Mon, Jan 12, 2009 at 1:55 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Your test above confirms that the description is correct and nothing is
>> missing. "git push" pushes explicitly listed refspecs (or : as a
>> default). It pushes tags (light and heavy) when asked to.
>>
>
> So do you mean that the only way I have for pushing annoted tags only is
> to do:
>
> $ git push origin refs/tags/annoted
You could use the equivalent, more user friendly "git push origin tag
annoted".
> That's not what Junio said:
>
> Don't use explicit --tags blindly. It says "no matter what kind of tag,
> transfer everything under refs/tags". Otherwise you won't see a
> difference.
>
> So I interpret this like don't use --tags otherwise lightweight and annoted tags
> are the same.
I don't see a difference between lightweight tags and tag objects
regarding the question of automatic tag following, see my parenthetical
request for correction (below) in case I'm wrong.
>> "git pull" pulls tags if they can be reached from heads which are
>> pulled. It pulls all tags only when asked to.
>>
>
> [...]
>
>> So, "non-local" tags are the ones which can be reached from heads which
>> you pull, and local ones are the others.
>
> So I can't create a local tag on public heads (the ones I'm pushing
> out), can I ?
>
>> I don't think lightweight tags are more local than tag objects
>> (please correct me if I'm wrong; I think this needs more doc)
>
> Perhaps it needs documents which are more user friendly: I don't know where
> the 'lightweight' word is coming from (perhaps from the implementation) but
> I would expect that the _local_ term appears in the git-tag manual.
It's the other way round. "lightweight" is in the first few lines of the
man, "local" nowhere. In fact I don't see it anywhere in the docs.
>> It's just that the latter reside in the object db
>> store whereas the former are simple refs under refs/tags.
>
> That's implementation detail...
>
> I just need to create a local tag where I'm sure it won't be seen by others
> whatever the git operations I'm doing, normally a simple "git tag" switch
> should be enough...
Taking "whatever" literally this is impossible, of course.
Taking it /cum grano salis/ it's still impossible within the same repo:
If others have read access they can "ls-remote" and "fetch" happily what
they want. The sane and easy way is to use a private repo for your local
work and all your "local tags", then to push to a public (i.e.
publically readable) repo those branches and tags which you want to be seen.
Are you a Mercurial user by any chance? "hg tag -l" creates local tags
which are stored in an unversioned, private file, whereas "hg tag"
creates (and commits) a tag entry in a versioned file, which is the
source of some confusion and problems with hg tags ("hg co sometag" does
not contain sometag etc.). Maybe you want the behaviour of "hg tag -l"?
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH 2/2] grep: don't call regexec() for fixed strings
From: Alex Riesen @ 2009-01-12 15:32 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <4967DB4A.2000702@lsrfire.ath.cx>
2009/1/10 René Scharfe <rene.scharfe@lsrfire.ath.cx>:
> +static int isregexspecial(int c)
> +{
> + return isspecial(c) || c == '$' || c == '(' || c == ')' || c == '+' ||
> + c == '.' || c == '^' || c == '{' || c == '|';
> +}
> +
> +static int is_fixed(const char *s)
> +{
> + while (!isregexspecial(*s))
> + s++;
> + return !*s;
> +}
strchr?
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Shawn O. Pearce @ 2009-01-12 15:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, git
In-Reply-To: <alpine.DEB.1.00.0901121421530.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 12 Jan 2009, Andreas Ericsson wrote:
>
> > Just chiming in that I can probably help mentoring whoever goes with
> > libgit2. I do not have enough spare time for me to promise that I can be
> > there as much as I think is necessary and proper, but I'll gladly help
> > out.
>
> I don't know if I like co-mentoring; I always had the impression that this
> does not work all that well.
I haven't tried it myself, so I can't comment. I thought though
that Daniel and Christian's mentoring went rather well, but maybe
that's just me.
This year I may not be able to be a mentor for GSoC. Even assuming
we are selected again we're likely to only have two students, given
the size of the program and the size of our organization's community.
I will most likely be hosting an intern at day-job, and I do want
to maintain some sort of contribution to Git, without hurting my
day job performance... so my time this summer is probably going to
be somewhat limited.
> > On a side-note, I think all mentors should urge the students in the
> > strongest possible terms to deliver their work to git@vger as soon as
> > possible. From previous years experience, successful projects are those
> > that the list sees code from within a week or two after the project's
> > started, while the projects that are kept in the dark rarely (if ever?)
> > finish successfully.
>
> Nope, that is just plainly incorrect.
>
> The most successful GSoC project we had was Miklos' builtin-merge, but the
> code had to grow to a state that both him and me were comfortable with a
> submission to git@vger.
Heh. I'd wager the most successful GSoC project was Marek's push
support for JGit. Having ObjectWriter available has opened up
the doors to support a lot of code in JGit, like the full protocol
suite, and bundles. Without it I wouldn't have gotten as far as
I did in Gerrit.
In terms of value, to me as a contributor, Marek's work gave me a
foundation we could build on and get stuff done. Miklos' merge is
great, but I don't think we gained nearly as many features as we
did with Marek's contribution.
Anyway, I don't want to get into a "my student was better!" contest.
I just think that we had a very successful year this year, with a
few really great projects being contributed to the community as a
result of our students' hard work.
> The _communication_ should be open, and much of it on the mailing list, I
> agree, but _only_ after the student is familiar enough with the aspects of
> her project (including some familiarity with the source code).
>
> I will _not_ force a student to ask questions openly that he finds
> embarassing.
I agree. The first few weeks are really critical to the student. They
are still trying to find their way around the code base and don't want
to look like an idiot. Nobody wants to look like an idiot, especially
in public, and especially when they have been "hired" to do a particular
job.
But... part of the reason GSoC exists is to get students involved
in open source. The rest of us don't come to Git with mentors we
can ask the "stupid" questions to. We come here and have to ask
what we need to ask, on the public mailing list, complete with
archives for the rest of time. As mentors we should be trying to
encourage our students to work in this, or any other, open source
community. GSoC is about getting these folks _involved_, so that
40 years from now, open source is just as viable as it is today.
--
Shawn.
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Shawn O. Pearce @ 2009-01-12 15:35 UTC (permalink / raw)
To: Christian Couder; +Cc: Andreas Ericsson, git
In-Reply-To: <200901121420.25420.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> wrote:
> Le lundi 12 janvier 2009, Andreas Ericsson a écrit :
> > From previous years experience, successful
> > projects are those that the list sees code from within a week
> > or two after the project's started, while the projects that are
> > kept in the dark rarely (if ever?) finish successfully.
>
> I don't think things are so simple.
Nope, they aren't. But the pattern is generally there, when you
look at all GSoC projects in aggregate.
Students who are involved with their community are far more likely
to have a successful project. In most communities, getting code
posted on the discussion list and actually discussing it is a very
important part of that involvement.
--
Shawn.
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Shawn O. Pearce @ 2009-01-12 15:37 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <496B2690.2010902@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Just chiming in that I can probably help mentoring whoever goes
> with libgit2. I do not have enough spare time for me to promise
> that I can be there as much as I think is necessary and proper,
> but I'll gladly help out.
Thanks. I'd love to see a libgit2 project this summer.
If we do have such a thing, and if I'm still wearing the maintainer
hat for libgit2, I think it would be improper for me to be the mentor
for the student. Just as Junio abstains from mentoring any students
in GSoC, to prevent potential bias during patch review, I probably
should abstain in the case of libgit2. Or at least move the project
to a dual-maintainer approach like we use with JGit, so the other
maintainer is the one doing the actual review and patch acceptance.
--
Shawn.
^ permalink raw reply
* Re: "git diff --stat" doesn't show added empty file
From: Michael J Gruber @ 2009-01-12 15:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ping Yin, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0901121319210.3586@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 01/12/09 13:19:
> Hi,
>
> On Mon, 12 Jan 2009, Ping Yin wrote:
>
>> $ git --version
>> git version 1.6.1.9.g97c34
>> $ mkdir test && cd test && git init && git commit --allow-empty -m
>> "Initial commit"
>> $ touch .gitignore && git add .gitignore && git commit -m "Add empty .gitignore"
>> $ git diff --stat HEAD^..
>> 0 files changed, 0 insertions(+), 0 deletions(-)
>>
>> May be the following is better?
>>
>> .gitignore | 0 +
>> 1 files changed, 0 insertions(+), 0 deletions(-)
>
> Have fun coding that.
Removing 5 lines from diff.c does the job, except for the " +" after 0,
but I don't know if that output is really better. Is the
addition/removal of an empty file a file change? It's certainly a change
of the containing dir, which git does not track. I don't see how to
distinguish addition from removal of an empty file at that point in the
code yet. This might be the "fun" part...
Michael
^ permalink raw reply
* Re: [RFC PATCH 3/3] Support fetching from foreign VCSes
From: Shawn O. Pearce @ 2009-01-12 15:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0901120041260.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Sun, 11 Jan 2009, Junio C Hamano wrote:
> > Daniel Barkalow <barkalow@iabervon.org> writes:
> > > This supports a useful subset of the usual fetch logic, mostly in the
> > > config file.
> >
> > I like the direction this series is going. In the longer term, it would
> > be nice if we can have git-svn and git-cvsimport replaced with something
> > like this.
The series seems to require that the foreign tool speak fast-import. I've
tried to get git-svn to use it, but its currently not possible because the
git-svn process needs to be able to read objects it has written during this
session. Those objects are stored in the output pack, where only the active
fast-import process can get to them. Thus git-svn can't use fast-import.
As import as the git-p4 stuff is, git-svn is our "killer feature" when it
comes to foreign system integration. I think we need to make SVN work for
this foreign vcs thing to work.
> > Is the current foreign vcs interface sufficiently rich to support git as a
> > foreign scm by using fast-import and fast-export?
>
> I think so, although it would be pretty strange, since it would generally
> have a whole lot of local data (a complete clone of any remote
> repository).
It might not be that bad. If the foreign system is git and the
local system is git, we should have a massive amount of object reuse.
At least all of the blobs from the foreign system should be reused
by the local system, and that's like 80-90% of most project's
object state.
If the import is flawless (no mangling of commit messages or history)
then you should get 100% object reuse and the git-git import would
give you the same SHA-1, but just slower than going over git://.
Its strange only because it would be sucking more CPU time on the
client than is necessary to do the fetch. But if something like
a filter-branch tool existed to massage a fast-import stream, it
might be useful to fetch someone else's tree, massage it a bit,
and then import it with a subtree merge. :-)
--
Shawn.
^ permalink raw reply
* Re: "git diff --stat" doesn't show added empty file
From: Linus Torvalds @ 2009-01-12 16:13 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320901111936h6343e51fo94750d83e95743dc@mail.gmail.com>
On Mon, 12 Jan 2009, Ping Yin wrote:
> $ git diff --stat HEAD^..
> 0 files changed, 0 insertions(+), 0 deletions(-)
In the kernel, we use "git diff --stat --summary" for exactly this reason.
Well, not exactly.
The thing is, even if the file is _not_ empty, there's a huge difference
between "added 100 lines to an already-existing file" and "created a new
100-line file". Which is exactly what "--summary" adds.
And it sometimes even makes sense to show the summary without the
diffstat. If you're _only_ interested in create/delete/rename information,
you can do "git show --summary <cmit>". It won't give you line counts, but
it will give you information about any changes to filenames, eg in the
kernel archive, you could see an example of this with
git show -M --summary 95b482a8d31116f3f5c2a5089569393234d06385
where you have a combination of renames, creates and deletes.
So I think it's already better than what you ask for.
Linus
^ permalink raw reply
* Re: [EGIT PATCH 7/7] Create an automatic UI test for the Git Import Wizard
From: Shawn O. Pearce @ 2009-01-12 16:45 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200901081957.20591.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
>
> We could hold onto this patch. It might be better if we start the built in git daemon and clone
> from it, or from file, instread of jgit.org, but please try it out and see if it looks like a good a approach to
> use SWTBot for UI tests.
I'm not applying this patch for two reasons:
1) I spent 30 minutes trying to get SWTBot installed and running,
I gave up. It doesn't want to run in my Eclipse. Heck, I didn't
even get as far as running, I couldn't get it to install far enough
to get the project to compile.
2) I really want to avoid remote network access during JUnit tests.
Now that we have our own server process we can run it over a pipe
or something to do this test. Or at worst, bind to a random port
on the loopback and have the client clone from that port.
--
Shawn.
^ permalink raw reply
* Re: [EGIT PATCH 1/3] Support viewing all changes in a single compare editor
From: Shawn O. Pearce @ 2009-01-12 16:54 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1231550077-1057-2-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> Instead of having to click on every file listed as a diff
> an extra diff entry is inserted at the top. Double clicking
> on it will launch a compare editor for all changed files.
Nice.
> diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitFileDiffViewer.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitFileDiffViewer.java
> index ebec261..7549aa4 100644
> --- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitFileDiffViewer.java
> +++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitFileDiffViewer.java
> @@ -124,13 +149,16 @@ void doCopy() {
...
> + else
> + r.append(((RevDiff)o).left.getChildren().length + " files");
This should use the NLS framework for translation.
> diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/FileDiffLabelProvider.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/FileDiffLabelProvider.java
> index 60b3a5a..c78ba6e 100644
> --- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/FileDiffLabelProvider.java
> +++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/FileDiffLabelProvider.java
> @@ -14,12 +14,49 @@
> class FileDiffLabelProvider extends BaseLabelProvider implements
...
> + StringBuilder b = new StringBuilder();
> + if (add > 0) {
> + b.append(add + " added");
> + }
> + if (mod > 0) {
> + if (b.length() > 0)
> + b.append(", ");
> + b.append(mod + " changed");
> + }
> + if (del > 0) {
> + if (b.length() > 0)
> + b.append(", ");
> + b.append(del + " deleted");
Again, NLS.
> diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/RevDiff.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/RevDiff.java
> new file mode 100644
> index 0000000..020ec73
> --- /dev/null
> +++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/RevDiff.java
> +class DiffSide implements ITypedElement, IStructureComparator {
...
> + public String getName() {
> + return "EGit diff";
> + }
Should this have NLS applied to it?
--
Shawn.
^ permalink raw reply
* Re: [PATCH EGIT Allow for git config to not error when lines have '/r' in them.]
From: Shawn O. Pearce @ 2009-01-12 17:10 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Ryan Alberts, git
In-Reply-To: <200901102134.05652.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> torsdag 08 januari 2009 04:10:05 skrev Ryan Alberts:
> > I have attached a small fix for when a git config has /r lines in the file.
> > I have to admit that I do not usually submit patches to the open source
> > community and I am not very familiar with the process :-) Please, please,
> > let me know if I can do something different next time!
>
> Back to the patch. I think we should only ignore \r (not /r, but could say CR in
> a comment) before an LF.
I disagree; ignoring CR anyplace in the file should be fine, unless
it is within a double quoted value, in which case it should use
the same rule that \n would use within the same region.
' ', \n, \t all act the same with regards to being (mostly) ignored
whitespace. \r is no different. Especially for anyone crazy enough
to still be using a Mac style formatted file, with only CRs in it.
--
Shawn.
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Johannes Schindelin @ 2009-01-12 17:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andreas Ericsson, git
In-Reply-To: <20090112153322.GA10179@spearce.org>
Hi,
On Mon, 12 Jan 2009, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Mon, 12 Jan 2009, Andreas Ericsson wrote:
> >
> > > Just chiming in that I can probably help mentoring whoever goes with
> > > libgit2. I do not have enough spare time for me to promise that I
> > > can be there as much as I think is necessary and proper, but I'll
> > > gladly help out.
> >
> > I don't know if I like co-mentoring; I always had the impression that
> > this does not work all that well.
>
> I haven't tried it myself, so I can't comment. I thought though that
> Daniel and Christian's mentoring went rather well, but maybe that's just
> me.
That impression came from a few conversations at the mentor summit, BTW.
I cannot really comment on C & D... as Christian pointed out, they are
still a bit secretive, even long after the official end of the project.
However, I have to mention that some projects (SIP communicator for
example) made it a _requirement_ to have pairs of mentors. But then, they
had the "disappearing mentor" syndrome already, so who can blame them for
that.
> This year I may not be able to be a mentor for GSoC.
Pity. But you started the preparation for the new application, thank you
very much. Will you be able to be administrator again?
> Heh. I'd wager the most successful GSoC project was Marek's push
> support for JGit. Having ObjectWriter available has opened up the doors
> to support a lot of code in JGit, like the full protocol suite, and
> bundles. Without it I wouldn't have gotten as far as I did in Gerrit.
>
> In terms of value, to me as a contributor, Marek's work gave me a
> foundation we could build on and get stuff done. Miklos' merge is
> great, but I don't think we gained nearly as many features as we did
> with Marek's contribution.
>
> Anyway, I don't want to get into a "my student was better!" contest.
Hehe. I am very proud that we are able to hold such a contest.
> I just think that we had a very successful year this year, with a
> few really great projects being contributed to the community as a
> result of our students' hard work.
>
> > The _communication_ should be open, and much of it on the mailing list, I
> > agree, but _only_ after the student is familiar enough with the aspects of
> > her project (including some familiarity with the source code).
> >
> > I will _not_ force a student to ask questions openly that he finds
> > embarassing.
>
> I agree. The first few weeks are really critical to the student. They
> are still trying to find their way around the code base and don't want
> to look like an idiot. Nobody wants to look like an idiot, especially
> in public, and especially when they have been "hired" to do a particular
> job.
>
> But... part of the reason GSoC exists is to get students involved
> in open source. The rest of us don't come to Git with mentors we
> can ask the "stupid" questions to. We come here and have to ask
> what we need to ask, on the public mailing list, complete with
> archives for the rest of time. As mentors we should be trying to
> encourage our students to work in this, or any other, open source
> community.
I do not think that both of your paragraphs contradict each other. Many
students need a bit of hand-holding until they realize that everybody is
cooking with water. At the end of the day, everybody has some brilliant
and some stupid ideas.
But it takes some getting used to to voice ideas in public, risking some
friendly jokes about your mental state or the quality of your smokables.
I actually see a lot of value in GSoC as a tools to get more students
through that period, especially students from parts of this planet whose
culture is so different from the "Western" culture shaped by
TV, consumism and the lack of physical insecurity, that they are rather
intimidated by the ways of Open Source.
> GSoC is about getting these folks _involved_, so that 40 years from now,
> open source is just as viable as it is today.
It will probably take over even more of our world.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH 1/3] Add "vcs" config option in remotes
From: Daniel Barkalow @ 2009-01-12 17:25 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git, Junio C Hamano
In-Reply-To: <36ca99e90901120152t7756e6d4n19521cbb7336c5fb@mail.gmail.com>
On Mon, 12 Jan 2009, Bert Wesarg wrote:
> On Sun, Jan 11, 2009 at 21:12, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > diff --git a/builtin-push.c b/builtin-push.c
> > index 122fdcf..3fdedba 100644
> > --- a/builtin-push.c
> > +++ b/builtin-push.c
> > @@ -53,6 +53,9 @@ static int do_push(const char *repo, int flags)
> > int i, errs;
> > struct remote *remote = remote_get(repo);
> >
> > + if (remote->foreign_vcs)
> > + die("Pushing with foreign VCSes not supported.");
> > +
> > if (!remote)
> > die("bad repository '%s'", repo);
> >
> Use of remote before NULL check.
Good catch, thanks.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [RFC/PATCH 1/7] sha1_file: make "read_object" static
From: Christian Couder @ 2009-01-12 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This function is only used from "sha1_file.c".
And as we want to add a "replace_object" hook in "read_sha1_file",
we must not let people bypass the hook using something other than
"read_sha1_file".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
cache.h | 3 ---
sha1_file.c | 7 +++++--
2 files changed, 5 insertions(+), 5 deletions(-)
Here is a new patch series. This time the hook is in "read_sha1_file".
There are still many things to do and to check after this, it's just a start.
But I try to follow the advise we give to GSoC student so I release early
and often :-)
diff --git a/cache.h b/cache.h
index 231c06d..8e1af26 100644
--- a/cache.h
+++ b/cache.h
@@ -631,9 +631,6 @@ extern int write_sha1_file(void *buf, unsigned long len, const char *type, unsig
extern int pretend_sha1_file(void *, unsigned long, enum object_type, unsigned char *);
extern int force_object_loose(const unsigned char *sha1, time_t mtime);
-/* just like read_sha1_file(), but non fatal in presence of bad objects */
-extern void *read_object(const unsigned char *sha1, enum object_type *type, unsigned long *size);
-
/* global flag to enable extra checks when accessing packed objects */
extern int do_check_packed_object_crc;
diff --git a/sha1_file.c b/sha1_file.c
index 52d1ead..f08493f 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1700,6 +1700,9 @@ static void add_delta_base_cache(struct packed_git *p, off_t base_offset,
delta_base_cache_lru.prev = &ent->lru;
}
+static void *read_object(const unsigned char *sha1, enum object_type *type,
+ unsigned long *size);
+
static void *unpack_delta_entry(struct packed_git *p,
struct pack_window **w_curs,
off_t curpos,
@@ -2130,8 +2133,8 @@ int pretend_sha1_file(void *buf, unsigned long len, enum object_type type,
return 0;
}
-void *read_object(const unsigned char *sha1, enum object_type *type,
- unsigned long *size)
+static void *read_object(const unsigned char *sha1, enum object_type *type,
+ unsigned long *size)
{
unsigned long mapsize;
void *map, *buf;
--
1.6.1.83.g16e5
^ permalink raw reply related
* [RFC/PATCH 2/7] refs: add a "for_each_replace_ref" function
From: Christian Couder @ 2009-01-12 17:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This is some preparation work for the following patches that are using
the "refs/replace/" ref namespace.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
refs.c | 5 +++++
refs.h | 1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/refs.c b/refs.c
index 33ced65..042106d 100644
--- a/refs.c
+++ b/refs.c
@@ -632,6 +632,11 @@ int for_each_remote_ref(each_ref_fn fn, void *cb_data)
return do_for_each_ref("refs/remotes/", fn, 13, cb_data);
}
+int for_each_replace_ref(each_ref_fn fn, void *cb_data)
+{
+ return do_for_each_ref("refs/replace/", fn, 13, cb_data);
+}
+
/*
* Make sure "ref" is something reasonable to have under ".git/refs/";
* We do not like it if:
diff --git a/refs.h b/refs.h
index 06ad260..8d2ee5a 100644
--- a/refs.h
+++ b/refs.h
@@ -23,6 +23,7 @@ extern int for_each_ref(each_ref_fn, void *);
extern int for_each_tag_ref(each_ref_fn, void *);
extern int for_each_branch_ref(each_ref_fn, void *);
extern int for_each_remote_ref(each_ref_fn, void *);
+extern int for_each_replace_ref(each_ref_fn, void *);
/*
* Extra refs will be listed by for_each_ref() before any actual refs
--
1.6.1.83.g16e5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox