* Re: Official Git Homepage change? Re: git-scm.com
From: Jakub Narebski @ 2008-07-26 20:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: Scott Chacon, Junio C Hamano, git
In-Reply-To: <20080726201751.GU10151@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Fri, Jul 25, 2008 at 11:43:55PM -0700, Scott Chacon wrote:
> > However, I have evangelized Git in person to literally thousands of
> > people, and tens of thousands more online. GitHub hosts over 10,000
> > public git projects completely for free, and has contributed a ton
> > back to the community, both in code and proselytization efforts.
>
> I certainly agree that GitHub has done a lot for spreading Git; the
> mention of code is interesting, though. There is Grist and the GitHooks;
> anything else? It's a pity Grist wasn't even announced at the mailing
> list. :-(
And neither project was added to Git Wiki:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
It looks like GitHub-bers are a bit of splinter faction. Thank you
Scott Chacon for trying to change this...
P.S. What about http://git-scm.org/ ?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH v2] Support copy and rename detection in fast-export.
From: Shawn O. Pearce @ 2008-07-26 20:21 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <200807262249.18005.angavrilov@gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> This patch makes fast-export output correct action
> logs when -M or -C are enabled.
...
> +-M, -C::
> + Perform move and/or copy detection, as described in the
> + linkgit:git-diff[1] manual page, and use it to generate
> + rename and copy commands in the output dump.
> ++
> +Note that these options are always accepted by git-fast-import,
> +but before a certain version it silently produced wrong results.
> +You should always check the git version before using them.
Do you mean to say git-fast-export in the end of the first line of
that last paragraph?
--
Shawn.
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-26 20:17 UTC (permalink / raw)
To: Scott Chacon; +Cc: Junio C Hamano, git
In-Reply-To: <d411cc4a0807252343n2b9ade68veaebb68664f0a3d7@mail.gmail.com>
On Fri, Jul 25, 2008 at 11:43:55PM -0700, Scott Chacon wrote:
> However, I have evangelized Git in person to literally thousands of
> people, and tens of thousands more online. GitHub hosts over 10,000
> public git projects completely for free, and has contributed a ton
> back to the community, both in code and proselytization efforts.
I certainly agree that GitHub has done a lot for spreading Git; the
mention of code is interesting, though. There is Grist and the GitHooks;
anything else? It's a pity Grist wasn't even announced at the mailing
list. :-(
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-26 19:58 UTC (permalink / raw)
To: Roman Zippel; +Cc: Tim Harper, git
In-Reply-To: <200807260512.40088.zippel@linux-m68k.org>
On Sat, 26 Jul 2008, Roman Zippel wrote:
> >
> > So without --full-history, if any parent matches the state, it just
> > removes the merge and picks that parent that contained all the state.
> > Obviously, any changes to that file can be sufficiently explained by
> > walking just that limited history, because they must have changed in
> > _that_ history too!
>
> Is that really a good default behaviour?
Yes. It's the only sane default right now. See below.
> Is there a way to change that default?
Use an alias or something.
To see why it's the default, do a few tests. In particular, try it with
gitk on the kernel. Try it on some fairly simple file that doesn't get a
lot of churn. Example:
gitk lib/vsprintf.c
vs
gitk --full-history lib/vsprintf.c
and if you don't _immediately_ see why --full-history isn't the default,
there's likely something wrong with you. One is useful. The other is not.
So we absolutely _have_ to simplify merges. There is no question about it.
That said, we currently simplify merges the simple and stupid way, and
I've hinted several times on this mailing list that there is a better way
to do it (last time it was the discussion about "filter-branch".
In fact, if you google for
filter-branch full-history
you'll find some of the discussion. In order to make --full-history useful
as a default, we'd need to do an after-the-fact merge cleanup (ie remove
lines of development that are later found to really be totally
uninteresting), but that is *hard*.
But if we did that, I'd agree to making --full-history the default (and it
would be a good thing, no doubt about it - I just cannot see how to do ti
simply and sanely enough)
Linus
^ permalink raw reply
* Re: git-scm.com
From: Scott Chacon @ 2008-07-26 19:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git list
In-Reply-To: <alpine.DEB.1.00.0807262118420.26810@eeepc-johanness>
On Sat, Jul 26, 2008 at 12:20 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 26 Jul 2008, Scott Chacon wrote:
>
>> On Sat, Jul 26, 2008 at 12:11 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> >
>> > On Sat, 26 Jul 2008, Scott Chacon wrote:
>> >
>> >> I'm sorry you don't like us, but we're really not that bad. If
>> >> you're in the SF bay area sometime, send me a note and I'll take you
>> >> out for a beer and we can discuss what else we can do :)
>> >
>> > If that applies to everybody having concerns, I would love to take you
>> > up on your word for it. I will be in the bay area around 24th of
>> > October this year.
>>
>> That is open to anyone that has contributed a patch to git - I at least
>> owe you a beer.
>
> Welcome the masses:
>
> $ git shortlog -s | wc -l
> 504
>
>> Let me know when you're around.
>
> As I said, around 24th of October this year.
>
> Ciao,
> Dscho
>
Heh. That would be a hell of a night... Nick Hengeveld said he's up
for it too, anytime.
btw, doener pointed out that I had the repo.or.cz numbers backward
earlier - it should be 1500ish with forks, 1300ish without.
Scott
^ permalink raw reply
* Re: git-scm.com
From: Johannes Schindelin @ 2008-07-26 19:20 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list
In-Reply-To: <d411cc4a0807261213j9d7c68cw345aca2a87eabda1@mail.gmail.com>
Hi,
On Sat, 26 Jul 2008, Scott Chacon wrote:
> On Sat, Jul 26, 2008 at 12:11 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Sat, 26 Jul 2008, Scott Chacon wrote:
> >
> >> I'm sorry you don't like us, but we're really not that bad. If
> >> you're in the SF bay area sometime, send me a note and I'll take you
> >> out for a beer and we can discuss what else we can do :)
> >
> > If that applies to everybody having concerns, I would love to take you
> > up on your word for it. I will be in the bay area around 24th of
> > October this year.
>
> That is open to anyone that has contributed a patch to git - I at least
> owe you a beer.
Welcome the masses:
$ git shortlog -s | wc -l
504
> Let me know when you're around.
As I said, around 24th of October this year.
Ciao,
Dscho
^ permalink raw reply
* Re: git-scm.com
From: Scott Chacon @ 2008-07-26 19:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git list
In-Reply-To: <alpine.DEB.1.00.0807262110140.26810@eeepc-johanness>
On Sat, Jul 26, 2008 at 12:11 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Scott,
>
> On Sat, 26 Jul 2008, Scott Chacon wrote:
>
>> I'm sorry you don't like us, but we're really not that bad. If you're
>> in the SF bay area sometime, send me a note and I'll take you out for a
>> beer and we can discuss what else we can do :)
>
> If that applies to everybody having concerns, I would love to take you up
> on your word for it. I will be in the bay area around 24th of October
> this year.
>
> Ciao,
> Dscho
That is open to anyone that has contributed a patch to git - I at
least owe you a beer. Let me know when you're around.
Scott
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Johannes Schindelin @ 2008-07-26 19:06 UTC (permalink / raw)
To: Jakub Narebski
Cc: Shawn O. Pearce, Jing Xue, git, Junio C Hamano, Marek Zawirski
In-Reply-To: <200807262017.04413.jnareb@gmail.com>
Hi,
On Sat, 26 Jul 2008, Jakub Narebski wrote:
> It looks like alternate Git implementation are cropping left and right:
> jgit in Java, widgit/Git-R-Done and git# GSoC Mono project in C#,...
> but not all of them maturing.
Seems as if git# is actively worked on, by a user called "igfgt1". See
http://code.google.com/p/mono-soc-2008/source/browse/
However, it appears that the same problem as last year is happening: no
communication with those that could help -- us. For example, the latest
change in git# adds a method to "Blob" that returns the content. Which is
obviously read once, never to be freed.
I know that it is unfair to rant here, but on the other hand: it is not my
itch, and I have tons of other stuff to do.
Ciao,
Dscho
^ permalink raw reply
* Re: git-scm.com
From: Junio C Hamano @ 2008-07-26 18:51 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, Scott Chacon, git
In-Reply-To: <20080726130757.GY32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> One Scott's concern that didn't occur to me was that a the time of
> release, we could have broken links between the time tag is created and
> tarballs are wrapped up. I *think* that in practice, this happens at the
> same time, I wonder if Junio could confirm that.
Heh, and you did not Cc: me ;-)?
There is a mirroring process involved between the public machines and the
machine I push the tag into and place the tarballs. I do not have control
over that mirroring. But modulo that, the tarballs and RPMs are made
public before the tag and the tips of branches are pushed into the public
repository.
The release procedure goes like this (extend this as an addendum to
Documentation/howto/maintain-git.txt if somebody feels like it):
* On the development machine outside k.org, create the tag, and prepare
RPM for i386;
* scp i386 RPM to a private staging area at k.org, and push the tag to a
private building area also at k.org;
* run the release procedure in the private building area at k.org, which:
- builds x86_64 RPM and deposits it to the same private staging area
i386 RPM were scp'ed to earlier;
- builds the source tarball and documentation tarballs;
- puts all of the above in /pub/software/scm/git/ to be mirrored out;
- extracts html documentation tarball in /pub/software/scm/git/docs/v*
to be mirrored out;
http://www.kernel.org/pub/software/scm/git/docs/, the "current"
documentation page, has links to these "documentation for
released versions" and they point at these docs/v* areas.
* push the tag and branch tips out to the public repository, so that it
will be mirrored to /pub/scm/git/git.git/ (this updates the "current"
documentation pages as a side effect);
* send out the release announcement message to the list.
The 1.4.4.5 backport was an oddball. I do not think I did anything other
than simply pushing the tag out.
^ permalink raw reply
* [PATCH v2] Support copy and rename detection in fast-export.
From: Alexander Gavrilov @ 2008-07-26 18:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807211207470.3305@eeepc-johanness>
Although it does not matter for Git itself, tools that
export to systems that explicitly track copies and
renames can benefit from such information.
This patch makes fast-export output correct action
logs when -M or -C are enabled.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
Added a note to the fast-export documentation. When this patch
is merged, it probably should be updated with the exact version.
-- Alexander
Documentation/git-fast-export.txt | 9 +++++++
builtin-fast-export.c | 28 +++++++++++++++++++++-
t/t9301-fast-export.sh | 46 +++++++++++++++++++++++++++++++++++++
3 files changed, 81 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
index 332346c..699b69e 100644
--- a/Documentation/git-fast-export.txt
+++ b/Documentation/git-fast-export.txt
@@ -36,6 +36,15 @@ when encountering a signed tag. With 'strip', the tags will be made
unsigned, with 'verbatim', they will be silently exported
and with 'warn', they will be exported, but you will see a warning.
+-M, -C::
+ Perform move and/or copy detection, as described in the
+ linkgit:git-diff[1] manual page, and use it to generate
+ rename and copy commands in the output dump.
++
+Note that these options are always accepted by git-fast-import,
+but before a certain version it silently produced wrong results.
+You should always check the git version before using them.
+
EXAMPLES
--------
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index 8bea269..3225e8f 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -118,10 +118,27 @@ static void show_filemodify(struct diff_queue_struct *q,
{
int i;
for (i = 0; i < q->nr; i++) {
+ struct diff_filespec *ospec = q->queue[i]->one;
struct diff_filespec *spec = q->queue[i]->two;
- if (is_null_sha1(spec->sha1))
+
+ switch (q->queue[i]->status) {
+ case DIFF_STATUS_DELETED:
printf("D %s\n", spec->path);
- else {
+ break;
+
+ case DIFF_STATUS_COPIED:
+ case DIFF_STATUS_RENAMED:
+ printf("%c \"%s\" \"%s\"\n", q->queue[i]->status,
+ ospec->path, spec->path);
+
+ if (!hashcmp(ospec->sha1, spec->sha1) &&
+ ospec->mode == spec->mode)
+ break;
+ /* fallthrough */
+
+ case DIFF_STATUS_TYPE_CHANGED:
+ case DIFF_STATUS_MODIFIED:
+ case DIFF_STATUS_ADDED:
/*
* Links refer to objects in another repositories;
* output the SHA-1 verbatim.
@@ -134,6 +151,13 @@ static void show_filemodify(struct diff_queue_struct *q,
printf("M %06o :%d %s\n", spec->mode,
get_object_mark(object), spec->path);
}
+ break;
+
+ default:
+ die("Unexpected comparison status '%c' for %s, %s",
+ q->queue[i]->status,
+ ospec->path ? ospec->path : "none",
+ spec->path ? spec->path : "none");
}
}
}
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index f18eec9..bb595b7 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -162,4 +162,50 @@ test_expect_success 'submodule fast-export | fast-import' '
'
+export GIT_AUTHOR_NAME='A U Thor'
+export GIT_COMMITTER_NAME='C O Mitter'
+
+test_expect_success 'setup copies' '
+
+ git config --unset i18n.commitencoding &&
+ git checkout -b copy rein &&
+ git mv file file3 &&
+ git commit -m move1 &&
+ test_tick &&
+ cp file2 file4 &&
+ git add file4 &&
+ git mv file2 file5 &&
+ git commit -m copy1 &&
+ test_tick &&
+ cp file3 file6 &&
+ git add file6 &&
+ git commit -m copy2 &&
+ test_tick &&
+ echo more text >> file6 &&
+ echo even more text >> file6 &&
+ git add file6 &&
+ git commit -m modify &&
+ test_tick &&
+ cp file6 file7 &&
+ echo test >> file7 &&
+ git add file7 &&
+ git commit -m copy_modify
+
+'
+
+test_expect_success 'fast-export -C -C | fast-import' '
+
+ ENTRY=$(git rev-parse --verify copy) &&
+ rm -rf new &&
+ mkdir new &&
+ git --git-dir=new/.git init &&
+ git fast-export -C -C --signed-tags=strip --all > output &&
+ grep "^C \"file6\" \"file7\"\$" output &&
+ cat output |
+ (cd new &&
+ git fast-import &&
+ test $ENTRY = $(git rev-parse --verify refs/heads/copy))
+
+'
+
test_done
--
1.5.6.3.18.gfe82
^ permalink raw reply related
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Scott Chacon @ 2008-07-26 18:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080726175121.GA15015@spearce.org>
On Sat, Jul 26, 2008 at 10:51 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Jing Xue <jingxue@digizenstudio.com> writes:
>> >
>> > Just a thought - how about a question polling whether people would be
>> > interested in build tool wrappers around jgit - ant tasks, maven
>> > plugins, etc.?
>>
>> True, there are a lot of tools written in Java, which have or could
>> have support for Git: Ant tasks, Maven plugins, Hudson rules
>> (continuous integration), JIRA (bug/issue tracker). Some of them
>> perhaps could use jgit, although if I understand correctly jgit is not
>> yet full implementation of Git: it is enough for egit, for local clone
>> of repository.
>
> What Java based build tools would you like to see Git support in?
> (choose zero or more, multiple choice)
> Ant, Maven, Hudson, JIRA, other
>
>> I wonder if similar tools like mentioned above, but for the Ruby camp,
>> like Capistrano, Merb, Gitosis, whatever use git directly, or do they
>> use Ruby interface (and which interface). I don't think there is
>> implementation of Git in Ruby... hmmmm....
>
> There is an implementation in Ruby, but I'm not sure what its
> state is.
>
The most up-to-date project is 'Grit', a spinoff of the GitHub site.
It has a number of things implemented in pure-ruby and is under active
development. It runs GitHub, Gitorious, GitNub (osx tool), etc.
http://github.com/mojombo/grit/tree/master
Scott
^ permalink raw reply
* Re: git-scm.com
From: Scott Chacon @ 2008-07-26 18:33 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <F3D70DCD-E9A9-42C3-8870-ABB7EECF83CC@wincent.com>
On Sat, Jul 26, 2008 at 8:48 AM, Wincent Colaiuta <win@wincent.com> wrote:
> El 26/7/2008, a las 7:30, Scott Chacon escribió:
>
>> However, that being said, it's going to be difficult to have Github
>> projects not dominate the list a bit. The fact is that it hosts far,
>> far more projects than any other single hosting service. Just in
>> fully public projects, the current stats (from the website pages) are
>> something like this:
>>
>> kernel.org : 475
>> repo.or.cz : 1,553
>> gitorious : 780
>> github : 10,560
>>
>> It hosts far more than that if you include private projects, too. So,
>> if we want to choose totally randomly, it's going to be at least a 5:1
>> ratio between github projects and all other public hosting providers.
>
>
> I think those numbers are pretty meaningless seeing as GitHub encourages
> people to publish "forks" of other projects. Rails, for example, has about
> 270 forks at the time of writing. If I scan the list of popular projects I
> see fork counts like 129, 105, 78 and 78 (again). Are all the forks counted
> in that figure of 10,560 that you count? How many "real" projects are hosted
> there?
Actually, no - I was including forked projects in the repo.or.cz count
and _not_ including forks in the github count. The actual apples to
apples count is :
Unique Projects:
repo.or.cz: 1553
github: 10,560
With Forks:
repo.or.cz : 1349
github : 16,021
Again, that is only the free, public projects - there are far more if
you include the private projects as well. I understand that the
commercial side that is necessitated by that is uncomforting to many
people, but it is great for the adoption of Git. Otherwise, every
company that wants to use Git professionally, including freelancers
and consultants, would have to setup, manage and maintain their own
git servers. It should not be a precondition that in order to use Git
on a commercial project you either have to be a) a systems
administrator capable of setting up and running your own server (and
keeping it secure, etc), or b) part of an organization large enough to
have a department to take care of that for you. Sure, you and I can
do it, and it's easy for us, but that is not true of everyone.
> I'd like to see the "official" Git homepage as distanced as possible from
> GitHub. They've taken Git (free as in speech, free as in beer) and built a
> closed-source commercial product on top of it -- curiously for something
> which you can do for free yourself anyway -- and as far as I can tell from
> observing this mailing list and watching the commits going into git.git,
> haven't ever contributed _anything_ back to the community. At least within
> the niche that is the Ruby/Rails community, GitHub has basically done a
> hijack job and managed to become synonymous with Git, supplanting it, and
> it's a trend that I wouldn't like to see continue.
Again, very few of us are excellent C programmers - I'm sure you
wouldn't want any patches we have to offer there. We have spent
considerable time and resources on things like gitcasts (which github
sponsors for me), and on libraries and tools like ticgit (which is
being included in the next Debian release) and Grit (a ruby/git
library that runs Gitorious, and probably most other web-based Git
repos), and will be contributing back improvements to ssh libraries
that allow for the sort of traffic they have to deal with. They have
also been looking to fund further open-source git related projects (in
case any of you are interested, btw) :
http://github.com/blog/107-supercharged-ruby-git
> Just my personal opinion, but GitHub doesn't provoke any warm fuzzy feelings
> here. Quite the contrary. I actively dislike it.
>
> Cheers,
> Wincent
I'm sorry you don't like us, but we're really not that bad. If you're
in the SF bay area sometime, send me a note and I'll take you out for
a beer and we can discuss what else we can do :)
Scott
^ permalink raw reply
* Re: [PATCH 3/7] builtin-help: make list_commands() a bit more generic
From: Jonathan Nieder @ 2008-07-26 18:28 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <68749731fe8de8b2a9ffc53963291aeab9256b82.1217037178.git.vmiklos@frugalware.org>
On Sat, 26 Jul 2008, Miklos Vajna wrote:
> -static void list_commands(void)
> +void list_commands(const char *prefix, const char *title)
> {
> - unsigned int longest = load_command_list(NULL);
> + unsigned int longest = load_command_list(prefix);
> const char *exec_path = git_exec_path();
>
> if (main_cmds.cnt) {
> - printf("available git commands in '%s'\n", exec_path);
> + printf("available %s in '%s'\n", title, exec_path);
> printf("----------------------------");
> mput_char('-', strlen(exec_path));
> putchar('\n');
Should this be
printf("available %s in '%s'\n", title, exec_path);
printf("----------------");
mput_char('-', strlen(exec_path) + strlen(title));
putchar('\n');
?
(same question goes for the if(other_cmds.cnt) block, too)
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-26 18:17 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Jing Xue, git, Junio C Hamano, Johannes Schindelin,
Marek Zawirski
In-Reply-To: <20080726175121.GA15015@spearce.org>
On Sat, 26 July 2008, Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Jing Xue <jingxue@digizenstudio.com> writes:
>>>
>>> Just a thought - how about a question polling whether people would be
>>> interested in build tool wrappers around jgit - ant tasks, maven
>>> plugins, etc.?
>>
>> True, there are a lot of tools written in Java, which have or could
>> have support for Git: Ant tasks, Maven plugins, Hudson rules
>> (continuous integration), JIRA (bug/issue tracker). Some of them
>> perhaps could use jgit, although if I understand correctly jgit is not
>> yet full implementation of Git: it is enough for egit, for local clone
>> of repository.
>
> xx. What Java based build tools would you like to see Git support in?
> (choose zero or more, multiple choice)
> - Ant, Maven, Hudson, JIRA, other
Some of those tools have more or less official support for Git, for
example there is Git plugin for Hudson (e.g. continuous integration)
http://hudson.gotdns.com/wiki/display/HUDSON/Git+Plugin
and Maven SCM git provider
http://jira.codehaus.org/browse/SCM-182
>> I wonder if similar tools like mentioned above, but for the Ruby camp,
>> like Capistrano, Merb, Gitosis, whatever use git directly, or do they
>> use Ruby interface (and which interface). I don't think there is
>> implementation of Git in Ruby... hmmmm....
>
> There is an implementation in Ruby, but I'm not sure what its
> state is.
What it is? URL or name, please?
It looks like alternate Git implementation are cropping left and right:
jgit in Java, widgit/Git-R-Done and git# GSoC Mono project in C#,...
but not all of them maturing.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/7] Make is_git_command() usable outside builtin-help
From: Jonathan Nieder @ 2008-07-26 18:12 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <f311372167c02868ccf5aa4dc03c97b7f956d855.1217037178.git.vmiklos@frugalware.org>
On Sat, 26 Jul 2008, Miklos Vajna wrote:
> + if (!prefix)
> + prefix = "git-";
> + prefix_len = strlen(prefix);
The whitespace gave me a start: the diff markup moved the prefix_len
line to the next tab stop, so at first glance it seems there are missing
braces here. But it is an illusion. (I mention this so others might
avoid wasting time worrying about it.)
I like the patch so far. Thanks for the pleasant reading.
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Shawn O. Pearce @ 2008-07-26 17:51 UTC (permalink / raw)
To: Jakub Narebski
Cc: Jing Xue, git, Junio C Hamano, Johannes Schindelin,
Marek Zawirski
In-Reply-To: <m38wvovbh2.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> Jing Xue <jingxue@digizenstudio.com> writes:
> >
> > Just a thought - how about a question polling whether people would be
> > interested in build tool wrappers around jgit - ant tasks, maven
> > plugins, etc.?
>
> True, there are a lot of tools written in Java, which have or could
> have support for Git: Ant tasks, Maven plugins, Hudson rules
> (continuous integration), JIRA (bug/issue tracker). Some of them
> perhaps could use jgit, although if I understand correctly jgit is not
> yet full implementation of Git: it is enough for egit, for local clone
> of repository.
What Java based build tools would you like to see Git support in?
(choose zero or more, multiple choice)
Ant, Maven, Hudson, JIRA, other
> I wonder if similar tools like mentioned above, but for the Ruby camp,
> like Capistrano, Merb, Gitosis, whatever use git directly, or do they
> use Ruby interface (and which interface). I don't think there is
> implementation of Git in Ruby... hmmmm....
There is an implementation in Ruby, but I'm not sure what its
state is.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Johannes Schindelin @ 2008-07-26 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, Johannes Sixt, git
In-Reply-To: <7vod4kft7d.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 26 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > However, argv0_path needs the full path, so add a function to discover
> > the program by traversing the PATH manually.
>
> I think unconditionally requiring argv0_path to be set is the root cause
> of the bug. Unless we do not fix _that_, we will have to make a
> needless call to lookup_program_in_path() even when nobody needs that
> information, which is unacceptable.
Fair enough. How about having a function called from system_path() which
has a flag so it is run only once, and then calls lookup_program_in_path()
provided that argv0_path contains no slashes _and_ exec_path is relative?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Junio C Hamano @ 2008-07-26 17:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0807261613120.26810@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When the program 'git' is in the PATH, the argv[0] is set to the basename.
While it may be true, I do not think it matters that we cannot get the
full path _UNLESS_ we are doing the relative "../" business.
> However, argv0_path needs the full path, so add a function to discover the
> program by traversing the PATH manually.
I think unconditionally requiring argv0_path to be set is the root cause
of the bug. Unless we do not fix _that_, we will have to make a needless
call to lookup_program_in_path() even when nobody needs that information,
which is unacceptable.
^ permalink raw reply
* [PATCH] builtin-merge: avoid non-strategy git-merge commands in error message
From: Miklos Vajna @ 2008-07-26 17:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807261900180.26810@eeepc-johanness>
If an invalid strategy is supplied, like -s foobar, then git-merge
listed all git-merge-* commands. This is not perfect, since for example
git-merge-index is not a valid strategy.
These are now removed from the output by scanning the list of main
commands; if the git-merge-foo command is listed in the all_strategy
list, then it's shown, otherwise excluded. This does not exclude
commands somewhere else in the PATH, where custom strategies are
expected.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Sat, Jul 26, 2008 at 07:01:16PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hmm. So let's say ent->name is "ours.exe", ent->len is set to 4.
> >
> > Then !strncmp(ent->name, all_strategy[j].name, ent->len) will be
> > true,
> > and the command will not be added to the exclude list.
>
> What I meant is: if you change the strcmp to strncmp because one of
> the
> both strings is not supposed to be NUL terminated, you still want to
> make
> sure that one is not a strict prefix of the other.
Aah, I forgot about all_strategy[j].name is NUL terminated.
Updated patch below.
builtin-merge.c | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index cdbc692..29826b1 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -88,8 +88,21 @@ static struct strategy *get_strategy(const char *name)
return &all_strategy[i];
if (!is_git_command(name, "git-merge-")) {
+ struct cmdnames not_strategies;
+
+ memset(¬_strategies, 0, sizeof(struct cmdnames));
+ for (i = 0; i < main_cmds.cnt; i++) {
+ int j, found = 0;
+ struct cmdname *ent = main_cmds.names[i];
+ for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
+ if (!strncmp(ent->name, all_strategy[j].name, ent->len)
+ && !all_strategy[j].name[ent->len])
+ found = 1;
+ if (!found)
+ add_cmdname(¬_strategies, ent->name, ent->len);
+ }
fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
- list_commands("git-merge-", "strategies");
+ list_commands("git-merge-", "strategies", ¬_strategies);
exit(1);
}
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: git-scm.com
From: Junio C Hamano @ 2008-07-26 17:10 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807251759m1d83d7c4w4724806b19f7c02a@mail.gmail.com>
"Scott Chacon" <schacon@gmail.com> writes:
> On Fri, Jul 25, 2008 at 4:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>> I find a tabular list like this list easier to read if it were sorted like
>> this:
>>
>> A D G
>> B E H
>> C F
>> ...
>
> I fixed the things you mentioned here, except for the list ordering,
> only because I kinda think you big contributors should be at the top
> there,...
If you are going to list 30 or so top contributors in 8 rows times 4
columns, because visually the columns are much more distinct than the
rows, it makes the result look more sorted. This is the same reasoning
hwo "git help --all" was fixed with 112d0ba (Make "git help" sort git
commands in columns, 2005-12-18).
By the way, I think this shows another issue with the "rest of us" list in
the lower half.
I have a mild suspicion that sorting that list in alphabetical order may
actually make it much better. It all depends on the purpose of that list,
though.
The purpose of the list would most likely not to find somebody with high
activity to contact for help (you would use the top list that is sorted by
the commit count for that kind of thing). It would primarily be to give
credit to everybody, and perhaps so that people on the contributor list
can point at their own name and say "I helped them", or find somebody else
they happen to know in the list.
When a contributor used to have 8 commits and then adds 2 commits, that
would move the name in the list by a dozen places or so with the current
set of contributors. It would be much easier to locate one's own name
among a huge list if the names are alphabetically sorted, not by commit
count. When more people start to contribute, your name does not move so
drastically. If you are Adam, you are likely to find yourself near the
beginning of the list, if you are Scott, you are likely to find yourself
near one fourth from the end of the list.
And for the "giving credit" purpose, I do not think truncating the list at
5 commits or less threshold, as suggested earlier and already done, makes
much sense, either.
^ permalink raw reply
* Re: git sequencer prototype
From: Sverre Rabbelier @ 2008-07-26 17:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stephan Beyer, git, Christian Couder, Daniel Barkalow
In-Reply-To: <alpine.DEB.1.00.0807261617010.26810@eeepc-johanness>
On Sat, Jul 26, 2008 at 16:19, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Why is it no issue for the builtin? Is it so much different from the
> prototype?
Because it's blazing fast :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 7/7] builtin-merge: avoid non-strategy git-merge commands in error message
From: Johannes Schindelin @ 2008-07-26 17:01 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080726160022.GM32057@genesis.frugalware.org>
Hi,
On Sat, 26 Jul 2008, Miklos Vajna wrote:
> On Sat, Jul 26, 2008 at 05:38:55PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > - if (!strcmp(main_cmds.names[i]->name, all_strategy[j].name))
> > > + if (!strncmp(ent->name, all_strategy[j].name, ent->len))
> >
> > Oops... that is not what I meant. You'd have to check if
> > !all_strategy[j].name[ent->len], too...
>
> Hmm. So let's say ent->name is "ours.exe", ent->len is set to 4.
>
> Then !strncmp(ent->name, all_strategy[j].name, ent->len) will be true,
> and the command will not be added to the exclude list.
What I meant is: if you change the strcmp to strncmp because one of the
both strings is not supposed to be NUL terminated, you still want to make
sure that one is not a strict prefix of the other.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rev-parse: Add support for the ^! and ^@ syntax
From: Björn Steinbrink @ 2008-07-26 16:54 UTC (permalink / raw)
To: git; +Cc: Christian Couder, Junio C Hamano
In-Reply-To: <20080726163756.GA25103@atjola.homenet>
On 2008.07.26 18:37:56 +0200, Björn Steinbrink wrote:
> Those shorthands are explained in the rev-parse documentation but were not
> actually supported by rev-parse itself.
>
> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
> ---
Ah crap, forgot to say that I wrote this because I wanted gitk to
support the ^! syntax and that uses rev-parse to parse its revision
arguments. My use-case with gitk is to quickly verify a bunch of grafts
I used to fixup the history in a git-svn repo.
Björn
^ permalink raw reply
* [PATCH] Clarify that "git log x.c y.h" lists commits that touch either file
From: Abhijit Menon-Sen @ 2008-07-26 16:50 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
Documentation/git-log.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 5a58d5b..05cbac5 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -58,7 +58,7 @@ include::diff-options.txt[]
its size is not included.
<paths>...::
- Show only commits that affect the specified paths.
+ Show only commits that affect any of the specified paths.
include::rev-list-options.txt[]
--
1.6.0.rc0.43.g2aa74
^ permalink raw reply related
* Re: Official Git Homepage change? Re: git-scm.com
From: Thomas Adam @ 2008-07-26 16:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Johannes Schindelin, Scott Chacon, git
In-Reply-To: <7v8wvok3f6.fsf@gitster.siamese.dyndns.org>
2008/7/26 Junio C Hamano <gitster@pobox.com>:
> Where does this observation lead us in this "Official" git homepage
> discussion? Perhaps the conclusion would be that there does not have to
> be any _single_ official home? I dunno.
I would disagree. If there is already a sporadic mess of GIT-related
information, not having somewhere "official" to collate and track
development changes in documentation, etc., could be very confusing
indeed. There is no guarantee these so-called "dark-matter" people
would ever get around to updating anything they're currently writing
which would be disasterous.
-- Thomas Adam
^ permalink raw reply
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