* 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 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: 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 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: 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: 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
* [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: 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
* 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: 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: 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: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: 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: 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: [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: 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: Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-26 20:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Scott Chacon, Junio C Hamano, jonas.fonseca, git
In-Reply-To: <m34p6cv1gl.fsf@localhost.localdomain>
On Sat, Jul 26, 2008 at 01:24:05PM -0700, Jakub Narebski wrote:
> P.S. What about http://git-scm.org/ ?
This domain is kept by Jonas Fonseca and it seems to be used at
occassions. It traditionally pointed to git.or.cz; thus I think it would
make sense for it to keep following git.or.cz unless/until we decide to
repoint that to git-scm.com. Jonas?
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Johannes Sixt @ 2008-07-26 20:37 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Junio C Hamano
In-Reply-To: <1217065304-27815-1-git-send-email-prohaska@zib.de>
Zitat von Steffen Prohaska <prohaska@zib.de>:
> With MinGW's
>
> gcc.exe (GCC) 3.4.5 (mingw special)
> GNU ld version 2.17.50 20060824
>
> the old define caused link errors:
>
> git.o: In function `main':
> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
> collect2: ld returned 1 exit status
>
> The modified define works.
I have the same tools, but not this error. ???
-- Hannes
^ permalink raw reply
* Re: [PATCH v2] Support copy and rename detection in fast-export.
From: Alexander Gavrilov @ 2008-07-26 20:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <20080726202103.GA15769@spearce.org>
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>
---
On Sunday 27 July 2008 00:21:03 Shawn O. Pearce wrote:
> Do you mean to say git-fast-export in the end of the first line of
> that last paragraph?
Yes, of course. Thank you.
By the way, I see that http://git.kernel.org/?p=gitk/gitk.git;a=summary
hasn't been updated for 2 months. Did the main gitk repository move
to some other place?
-- 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..bb2f9a8 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 were always accepted by git-fast-export,
+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: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Steffen Prohaska @ 2008-07-26 21:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <1217104655.488b8b0f5ca48@webmail.nextra.at>
On Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:
> Zitat von Steffen Prohaska <prohaska@zib.de>:
>> With MinGW's
>>
>> gcc.exe (GCC) 3.4.5 (mingw special)
>> GNU ld version 2.17.50 20060824
>>
>> the old define caused link errors:
>>
>> git.o: In function `main':
>> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
>> collect2: ld returned 1 exit status
>>
>> The modified define works.
>
> I have the same tools, but not this error. ???
I cleaned my work tree and built several times but did not
find out what exactly is causing the error. So I came up
with the modified define, which declares the static
mingw_main in global scope. I have no clue why I see the
error that you don't have.
Steffen
^ permalink raw reply
* [PATCH 3/7] builtin-help: make list_commands() a bit more generic
From: Miklos Vajna @ 2008-07-26 21:40 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <Pine.GSO.4.62.0807261319310.16184@harper.uchicago.edu>
That function now takes two paramters to control the prefix of the
listed commands, and a second parameter to specify the title of the
table. This can be useful for listing not only all git commands, but
specific ones, like merge strategies.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Sat, Jul 26, 2008 at 01:28:39PM -0500, Jonathan Nieder <jrnieder@uchicago.edu> wrote:
> > 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)
Right. Here is an updated patch.
Also available at git://repo.or.cz/git/vmiklos.git, branch 'merge-custom'.
help.c | 18 ++++++++++--------
help.h | 1 +
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/help.c b/help.c
index d71937e..ec7999d 100644
--- a/help.c
+++ b/help.c
@@ -501,23 +501,25 @@ static unsigned int load_command_list(const char *prefix)
return longest;
}
-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("----------------------------");
- mput_char('-', strlen(exec_path));
+ printf("available %s in '%s'\n", title, exec_path);
+ printf("----------------");
+ mput_char('-', strlen(title) + strlen(exec_path));
putchar('\n');
pretty_print_string_list(&main_cmds, longest);
putchar('\n');
}
if (other_cmds.cnt) {
- printf("git commands available from elsewhere on your $PATH\n");
- printf("---------------------------------------------------\n");
+ printf("%s available from elsewhere on your $PATH\n", title);
+ printf("---------------------------------------");
+ mput_char('-', strlen(title));
+ putchar('\n');
pretty_print_string_list(&other_cmds, longest);
putchar('\n');
}
@@ -697,7 +699,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (show_all) {
printf("usage: %s\n\n", git_usage_string);
- list_commands();
+ list_commands("git-", "git commands");
printf("%s\n", git_more_info_string);
return 0;
}
diff --git a/help.h b/help.h
index 73da8d6..0741662 100644
--- a/help.h
+++ b/help.h
@@ -2,5 +2,6 @@
#define HELP_H
int is_git_command(const char *s, const char *prefix);
+void list_commands(const char *prefix, const char *title);
#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Shawn O. Pearce @ 2008-07-26 21:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Johannes Schindelin, Marek Zawirski, git
In-Reply-To: <200807261254.53939.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> So you would like to see something like the following question in the
> upcoming Git User's Survey?
>
> xx. Which editors/IDEs/RADs do you use?
> (zero or more; multiple choice with 'other')
> - Emacs, Vim, Eclipse, KDevelop, Anjuta, TextMate, Notepad++,
> Visual Studio, other
> + what choices should be in the list of editors and IDE;
> or should perhaps this question be free-form?
I think we should list explicitly any editor that we have Git
integration for, or which we know is popular and people have asked
about in the past, and leave an other for people to enter other
editors.
We know about Emacs, Vim, Eclipse, TextMate all having some sort
of Git integration. We know people have asked about NetBeans,
KDevelop and Anjuta. After that yea, Notepad++ and Visual Studio
are two commonly used tools that people may use.
Anyone know of anything missing from this list?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] bash completion: Add long options for 'git describe'
From: Shawn O. Pearce @ 2008-07-26 21:52 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, gitster, SZEDER GGGbor
In-Reply-To: <1217068016-10954-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> wrote:
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Much shorter, thanks.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 3b04934..4ae8b36 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -665,6 +665,15 @@ _git_commit ()
>
> _git_describe ()
> {
> + local cur="${COMP_WORDS[COMP_CWORD]}"
> + case "$cur" in
> + --*)
> + __gitcomp "
> + --all --tags --contains --abbrev= --candidates=
> + --exact-match --debug --long --match --always
> + "
> + return
> + esac
> __gitcomp "$(__git_refs)"
> }
>
--
Shawn.
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Jean-François Veillette @ 2008-07-26 21:52 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Jakub Narebski, Junio C Hamano, Johannes Schindelin,
Marek Zawirski, git
In-Reply-To: <20080726215031.GB16219@spearce.org>
Le 08-07-26 à 17:50, Shawn O. Pearce a écrit :
> Jakub Narebski <jnareb@gmail.com> wrote:
>> So you would like to see something like the following question in the
>> upcoming Git User's Survey?
>>
>> xx. Which editors/IDEs/RADs do you use?
>> (zero or more; multiple choice with 'other')
>> - Emacs, Vim, Eclipse, KDevelop, Anjuta, TextMate, Notepad++,
>> Visual Studio, other
>> + what choices should be in the list of editors and IDE;
>> or should perhaps this question be free-form?
>
> I think we should list explicitly any editor that we have Git
> integration for, or which we know is popular and people have asked
> about in the past, and leave an other for people to enter other
> editors.
>
> We know about Emacs, Vim, Eclipse, TextMate all having some sort
> of Git integration. We know people have asked about NetBeans,
> KDevelop and Anjuta. After that yea, Notepad++ and Visual Studio
> are two commonly used tools that people may use.
>
> Anyone know of anything missing from this list?
XCode
- jfv
^ permalink raw reply
* Re: [EGIT PATCH] Support linked resources
From: Shawn O. Pearce @ 2008-07-26 21:59 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Richie Vos, git
In-Reply-To: <200807261707.18299.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> torsdagen den 24 juli 2008 05.34.06 skrev Richie Vos:
> > I have a project that outputs to a linked directory (for example the
> > project is in /projects/foo and the project outputs to /projects/bar).
...
> I'd be inclined to prefer ignoring any non-plain resource, always. Linked
> resources are either absolute or relative to a variable. Other than that
> there is an analogy to symbolic links. Git manages the link, not its
> content (unless handled elsewhere). The link in this case is in the
> .project file and thus managed there.
>
> EGit could still managed the resource, but not via the link, but rather at
> the place it is located, iff that happens to be in a project managed by Egit.
My last day-job used a project layout in the filesystem of:
GIT_REPO/
.git/
.gitignore
_eclipse_projects/
com.sekret.foo/.project
com.sekret.bar/.project
foo/
com/sekret/foo/Foo.java
bar/
com/sekret/bar/Bar.java
The two .project files contained links called "src" to "foo" and
"bar" respectively. The _eclipse_projects folder is ignored by
.gitignore, and the .project files were actually generated on the
fly by our non-Eclipse based buildsystem.
Consequently I wanted egit to be able to manage the stuff inside of
a linked folder, so long as it mapped onto the same repository that
the project mapped onto. Without that the "src" folder contents
wouldn't be available to egit, and egit would be more-or-less
useless on this sort of layout.
--
Shawn.
^ 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