* Re: [PATCH] prepare deprecation of git-revert
From: Pierre Habouzit @ 2008-10-31 15:57 UTC (permalink / raw)
To: git
In-Reply-To: <1225468527-29694-1-git-send-email-madcoder@debian.org>
[-- Attachment #1: Type: text/plain, Size: 2442 bytes --]
On Fri, Oct 31, 2008 at 03:55:27PM +0000, Pierre Habouzit wrote:
> * Rename builtin-revert.c into builtin-cherry-pick.c
>
> * Add option -R/--revert to git-cherry-pick.
> Document it by taking the current content of git-revert manpage for the
> option.
>
> * get rid of the no_replay initialization, just ignore it when we're in
> the revert case, it makes really no sense to error out.
>
> * put the warning of deprecation in cmd_revert, #if 0-ed out for now.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
>
> I've not kept the auto-edit feature of git-revert for the git-cherry-pick -R
> case as I don't believe it makes a lot of sense. But if people are unhappy
> with that, I can easily "fix" it.
>
> Documentation/git-cherry-pick.txt | 15 +++++++++++++++
> Makefile | 6 +++---
> builtin-revert.c => builtin-cherry-pick.c | 10 ++++------
> 3 files changed, 22 insertions(+), 9 deletions(-)
> rename builtin-revert.c => builtin-cherry-pick.c (98%)
>
> diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
> index 837fb08..2d92f2d 100644
> --- a/Documentation/git-cherry-pick.txt
> +++ b/Documentation/git-cherry-pick.txt
> @@ -40,6 +40,21 @@ OPTIONS
> development branch), adding this information can be
> useful.
>
> +-R::
> +--revert::
> + Given one existing commit, revert the change the patch introduces, and
> + record a new commit that records it. This requires your working tree
> + to be clean (no modifications from the HEAD commit).
> ++
> +Note: 'git revert' is used to record a new commit to reverse the
^ this was supposed to spell out 'git cherry-pick -R' of course :/
> +effect of an earlier commit (often a faulty one). If you want to
> +throw away all uncommitted changes in your working directory, you
> +should see linkgit:git-reset[1], particularly the '--hard' option. If
> +you want to extract specific files as they were in another commit, you
> +should see linkgit:git-checkout[1], specifically the 'git checkout
> +<commit> -- <filename>' syntax. Take care with these alternatives as
> +both will discard uncommitted changes in your working directory.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: why not TortoiseGit
From: Scott Chacon @ 2008-10-31 15:57 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Ian Hilt, Li Frank-B20596, git
In-Reply-To: <490AFBA5.5090700@op5.se>
I'm trying to get this restarted - dscho and I talked about this at
the GitTogether, and I met some people (from the OpenAFS project that
also happened to be there, oddly) who were interested in working on
this with me. I think the lack of a linkable library has greatly
hindered the development of projects like this, so that will likely be
part of the development process as well.
Scott
On Fri, Oct 31, 2008 at 5:35 AM, Andreas Ericsson <ae@op5.se> wrote:
> Ian Hilt wrote:
>>
>> On Fri, Oct 31, 2008 at 09:44:45AM +0800, Li Frank-B20596 wrote:
>>>
>>> There are TortoiseCVS, TortoiseSVN, TortoiseBzr, TortoiseHg
>>> Why not ToroiseGit
>>
>> This is what Johannes Schindelin had to say,
>>
>> <http://code.google.com/p/msysgit/wiki/GitCheetah>
>
> Noone's written TortoiseGit yet. I have no idea why, and I have
> no reason to write it myself. If GitCheetah isn't working well,
> I'm sure patches are welcome.
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Jakub Narebski @ 2008-10-31 16:26 UTC (permalink / raw)
To: Thanassis Tsiodras; +Cc: git
In-Reply-To: <f1d2d9ca0810310428o166dc075wbb43c00c1a555350@mail.gmail.com>
Thanassis Tsiodras wrote:
> On Fri, Oct 31, 2008 at 1:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > Git does deltification _only_ in packfiles. But when you push via SSH
> > git would generate a pack file with commits the other side doesn't
> > have, and those packs are thin packs, so they also have deltas... but
> > the remote side then adds bases to those thin packs making them
> > standalone: you would have to git-gc on remote.
>
> So I have to git-gc on my side (after the commits), git-gc on the remote,
> and then git-push?
Perhaps I haven't made myself clear.
On the local side: git-commit creates loose (compressed, but not
deltified) objects. git-gc packs and deltifies.
On the remote side (for smart protocols, i.e. git and ssh): git
creates _thin_ pack, deltified; on the remote side git either makes
pack thick/self contained by adding base objects (object + deltas),
or explodes pack into loose object (object). You need git-gc on
remote server to fully deltify on remote side. But transfer is fully
deltified.
On the remote side (for dumb protocols, i.e. rsync and http): git
finds required packs and transfers them whole. So the situation is
like on local side, but git might transfer more than really needed
because it transfers packs in full.
HTH.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Jakub Narebski @ 2008-10-31 16:36 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225468527-29694-1-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> * Rename builtin-revert.c into builtin-cherry-pick.c
>
> * Add option -R/--revert to git-cherry-pick.
> Document it by taking the current content of git-revert manpage for the
> option.
>
> * get rid of the no_replay initialization, just ignore it when we're in
> the revert case, it makes really no sense to error out.
>
> * put the warning of deprecation in cmd_revert, #if 0-ed out for now.
> +#if 0
> + warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> +#endif
By the way, Mercurial names this command IIRC 'hg backout'.
But I think that adding '-R' option to git-cherry-pick is a good idea
even if we don't go deprecating git-revert.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Johannes Schindelin @ 2008-10-31 16:46 UTC (permalink / raw)
To: Jeff King
Cc: Sam Vilain, git, Scott Chacon, Tom Preston-Werner, J.H.,
Christian Couder, Kai Blin
In-Reply-To: <20081031003154.GA5745@sigill.intra.peff.net>
Hi,
On Thu, 30 Oct 2008, Jeff King wrote:
> On Wed, Oct 29, 2008 at 05:22:00PM -0700, Sam Vilain wrote:
>
> > + * 'git branch --switch' : alternative to checkout
>
> Blech. I think switching branches is the one thing that checkout does
> unconfusedly. And this is much more typing. Not to mention that So I
> would rather see "git switch" if checkout is somehow unpalatable.
You know, I asked for this because a _user_ told me "Guess how long it
took me to find out how to check out a branch!".
I think if you are not confused by CVS/SVN, the name "checkout" is utterly
unintuitive.
Ciao,
Dscho
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Matthieu Moy @ 2008-10-31 16:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Thanassis Tsiodras, git
In-Reply-To: <200810311726.57122.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Thanassis Tsiodras wrote:
>
>> So I have to git-gc on my side (after the commits), git-gc on the remote,
>> and then git-push?
>
> Perhaps I haven't made myself clear.
>
> On the local side: git-commit creates loose (compressed, but not
> deltified) objects. git-gc packs and deltifies.
>
> On the remote side (for smart protocols, i.e. git and ssh): git
> creates _thin_ pack, deltified;
I don't understand this point: the OP talks about pushing, so isn't
the pack created on the _local_ machine (and then sent to the remote)?
--
Matthieu
^ permalink raw reply
* Re: [PATCH] git show <tree>: show mode and hash, and handle -r
From: Johannes Schindelin @ 2008-10-31 16:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, schacon
In-Reply-To: <7vtzatdbtk.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 30 Oct 2008, Junio C Hamano wrote:
> I wonder if it would help breaking down cmd_log_init() a bit like this.
Sorry, I am quite busy (this is the first time I am able to check my mail
since the GitTogether), so I cannot look at that in detail.
However, I strongly expect your suggestion not to help: for showing
commits, we _want_ recursive to be the default. And switching that on
devoids us from being able to DIFF_OPT_TST(.., RECURSIVE) to detect if the
user said '-r' _explicitely_.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Alex Riesen @ 2008-10-31 16:50 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225468527-29694-1-git-send-email-madcoder@debian.org>
Pierre Habouzit, Fri, Oct 31, 2008 16:55:27 +0100:
> @@ -439,16 +436,17 @@ static int revert_or_cherry_pick(int argc, const char **argv)
>
> int cmd_revert(int argc, const char **argv, const char *prefix)
> {
> +#if 0
> + warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> +#endif
"git revert" is much shorter to type than "git cherry-pick -R".
How about renaming "cherry-pick" into something short, like "pick"?
^ permalink raw reply
* [PATCH] git send-email: allow any rev-list option as an argument.
From: Pierre Habouzit @ 2008-10-31 16:52 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <1225450632-7230-3-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
One can consider to squash that on top of
<1225450632-7230-3-git-send-email-madcoder@debian.org> to be able to pass
all non path arguments before a possible '--' to git format-patch.
The downside of this patch is that:
git send-email -C -C -M origin/next
will send the content of origin/next if it's an existing file. Of course a
disambiguation can be:
git send-email -C -C -M refs/heads/origin/next
But again if this file also exists, one is basically screwed. I see no
proper way to fix that, unless to change git-send-email behaviour at once.
Though I believe this semantics to be better than the one in the previous
patch, as it's often a good idea to pass -M -C -C to format-patch, which is
currently impossible. It also allow revision lists to work as expected (wrt
--all, --not and so on).
Comments are welcomed.
Documentation/git-send-email.txt | 2 +-
git-send-email.perl | 19 ++++++++++++++-----
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 9ee81d5..39d6da9 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -8,7 +8,7 @@ git-send-email - Send a collection of patches as emails
SYNOPSIS
--------
-'git send-email' [options] <file|directory|rev-list>...
+'git send-email' [options] <file|directory|rev-list options>...
DESCRIPTION
diff --git a/git-send-email.perl b/git-send-email.perl
index 5c189a7..8667e0b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -25,6 +25,8 @@ use Term::ANSIColor;
use File::Temp qw/ tempdir /;
use Git;
+Getopt::Long::Configure qw/ pass_through /;
+
package FakeTerm;
sub new {
my ($class, $reason) = @_;
@@ -39,7 +41,7 @@ package main;
sub usage {
print <<EOT;
-git send-email [options] <file | directory | rev-list >
+git send-email [options] <file | directory | rev-list options >
Composing:
--from <str> * Email From:
@@ -383,8 +385,12 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
# Now that all the defaults are set, process the rest of the command line
# arguments and collect up the files that need to be processed.
-for my $f (@ARGV) {
- if (-d $f) {
+my @rev_list_opts;
+while (my $f = pop @ARGV) {
+ if ($f eq "--") {
+ push @rev_list_opts, "--", @ARGV;
+ @ARGV = ();
+ } elsif (-d $f) {
opendir(DH,$f)
or die "Failed to opendir $f: $!";
@@ -394,11 +400,14 @@ for my $f (@ARGV) {
} elsif (-f $f or -p $f) {
push @files, $f;
} else {
- my $tempdir = tempdir(CLEANUP => 1);
- push @files, $repo->command('format-patch', '-o', $tempdir, $f);
+ push @rev_list_opts, $f;
}
}
+if (@rev_list_opts) {
+ push @files, $repo->command('format-patch', '-o', tempdir(CLEANUP => 1), @rev_list_opts);
+}
+
if ($validate) {
foreach my $f (@files) {
unless (-p $f) {
--
1.6.0.3.791.g15769.dirty
^ permalink raw reply related
* Re: [PATCH] prepare deprecation of git-revert
From: Pierre Habouzit @ 2008-10-31 16:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m33aichgc1.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]
On Fri, Oct 31, 2008 at 04:36:33PM +0000, Jakub Narebski wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > * Rename builtin-revert.c into builtin-cherry-pick.c
> >
> > * Add option -R/--revert to git-cherry-pick.
> > Document it by taking the current content of git-revert manpage for the
> > option.
> >
> > * get rid of the no_replay initialization, just ignore it when we're in
> > the revert case, it makes really no sense to error out.
> >
> > * put the warning of deprecation in cmd_revert, #if 0-ed out for now.
>
> > +#if 0
> > + warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> > +#endif
>
> By the way, Mercurial names this command IIRC 'hg backout'.
>
> But I think that adding '-R' option to git-cherry-pick is a good idea
> even if we don't go deprecating git-revert.
Actually part of the "Git UI sucks at time"-talk by pasy, we somehow
decided that git-revert would probably be deprecated in the future to
avoid the clash between what people coming from other's SCM worlds
expect it to be.
I don't remember what the tentative schedule was, that's why I left the
warning commented out for now.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Pierre Habouzit @ 2008-10-31 16:58 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20081031165003.GA5355@steel.home>
[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]
On Fri, Oct 31, 2008 at 04:50:03PM +0000, Alex Riesen wrote:
> Pierre Habouzit, Fri, Oct 31, 2008 16:55:27 +0100:
> > @@ -439,16 +436,17 @@ static int revert_or_cherry_pick(int argc, const char **argv)
> >
> > int cmd_revert(int argc, const char **argv, const char *prefix)
> > {
> > +#if 0
> > + warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> > +#endif
>
> "git revert" is much shorter to type than "git cherry-pick -R".
> How about renaming "cherry-pick" into something short, like "pick"?
Do you really use git revert _that_ often ? I don't. And cherry-pick is
a really usual name for the tool.
FWIW the basic idea is to deprecate revert in a (not so ?) long time,
and leave git revert unimplemented for ever so that people that would
like it to be 'git checkout HEAD --' alias it to that, and the ones that
want to keep the current behaviour alias it to 'git cherry-pick -R'
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Jean-Luc Herren @ 2008-10-31 17:03 UTC (permalink / raw)
To: Jakub Narebski, Thanassis Tsiodras, git
In-Reply-To: <m37i7pggnk.fsf@localhost.localdomain>
Jakub Narebski wrote:
> "Thanassis Tsiodras" <ttsiodras@gmail.com> writes:
>> Then again, I must confess I only did the git-gc after I pushed.
>> Does the git-push actually take advantage of the similarities only if
>> I do a git-gc first?
>
> Git does deltification _only_ in packfiles. But when you push via SSH
> git would generate a pack file with commits the other side doesn't
> have, and those packs are thin packs, so they also have deltas...
AFAICT, git stopped pushing thin packs by default with 1.5.3.2, so
you have to explicitely ask for it. The original poster might not
be clear about this (or even know what a thin pack is).
Thanassis, try to use "git push --thin". 'man git-push' says:
--thin, --no-thin
These options are passed to git-send-pack. Thin transfer spends
extra cycles to minimize the number of objects to be sent and meant
to be used on slower connection.
I did a quick test with big random files and it indeed only sends
small deltas on small changes, but if you don't pass --thin, it
will send the full objects.
I didn't find a configuration variable to change that default. It
would make sense for people that regularly push over slow lines.
Hope this helps,
jlh
^ permalink raw reply
* large publicly accessible HTTP archive?
From: Bryan Larsen @ 2008-10-31 17:07 UTC (permalink / raw)
To: git
In-Reply-To: <S1751776AbYJaQ5O/20081031165714Z+111@vger.kernel.org>
Hello,
I'm one of the maintainers of MacPorts git port.
A long time ago, we had problems pulling extremely large archives over
HTTP on PowerPC machines. By large, I mean on the order of 500
megabytes: I was testing using an embedded Linux distribution.
We "fixed" the problem by turning off CURL_MULTI and ignored the
problem. Yes, bad form, I know.
Our problems were against curl 7.16.2.
However, in recent git's, CURL_MULTI is required to do an HTTP push, so
we've had users complaining.
Curl is up to 7.19.0, they may have fixed our problem. Unfortunately,
the distribution I used for testing is gone now. Putting up a local
archive doesn't exhibit the problem either.
Is anybody aware of a very large HTTP accessible repository that
wouldn't mind me doing a few test pulls from? By large, I mean >500
megabytes of network traffic for a single pull.
thanks,
Bryan
^ permalink raw reply
* libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 17:07 UTC (permalink / raw)
To: git; +Cc: Scott Chacon
During the GitTogether we were kicking around the idea of a ground-up
implementation of a Git library. This may be easier than trying
to grind down git.git into a library, as we aren't tied to any
of the current global state baggage or the current die() based
error handling.
I've started an _extremely_ rough draft. The code compiles into a
libgit.a but it doesn't even implement what it describes in the API,
let alone a working Git implementation. Really what I'm trying to
incite here is some discussion on what the API looks like.
API Docs:
http://www.spearce.org/projects/scm/libgit2/apidocs/html/modules.html
Source Code Clone URL:
http://www.spearce.org/projects/scm/libgit2/libgit2.git
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pieter de Bie @ 2008-10-31 17:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Scott Chacon
In-Reply-To: <20081031170704.GU14786@spearce.org>
On 31 okt 2008, at 18:07, Shawn O. Pearce wrote:
> Source Code Clone URL:
> http://www.spearce.org/projects/scm/libgit2/libgit2.git
This 404's for me
- Pieter
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pieter de Bie @ 2008-10-31 17:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List, Scott Chacon
In-Reply-To: <680C5F4A-C55A-45B1-99E0-A2A74B2DC634@ai.rug.nl>
On 31 okt 2008, at 18:28, Pieter de Bie wrote:
>> Source Code Clone URL:
>> http://www.spearce.org/projects/scm/libgit2/libgit2.git
>
> This 404's for me
Nevermind, it's only a clone url.. I'd expected a gitweb or so ;)
Sorry for the noise,
^ permalink raw reply
* Re: [PATCH] git show <tree>: show mode and hash, and handle -r
From: Junio C Hamano @ 2008-10-31 17:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, schacon
In-Reply-To: <alpine.DEB.1.00.0810311753080.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Thu, 30 Oct 2008, Junio C Hamano wrote:
>
>> I wonder if it would help breaking down cmd_log_init() a bit like this.
>
> Sorry, I am quite busy (this is the first time I am able to check my mail
> since the GitTogether), so I cannot look at that in detail.
>
> However, I strongly expect your suggestion not to help: for showing
> commits, we _want_ recursive to be the default. And switching that on
> devoids us from being able to DIFF_OPT_TST(.., RECURSIVE) to detect if the
> user said '-r' _explicitely_.
You can turn on recursive unconditionally for the normal "show committish"
case, and check for explicit "-r" for "show treeish" that was bolted-on
much later, can't you?
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-10-31 17:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Scott Chacon
In-Reply-To: <20081031170704.GU14786@spearce.org>
[-- Attachment #1.1: Type: text/plain, Size: 3900 bytes --]
On Fri, Oct 31, 2008 at 05:07:04PM +0000, Shawn O. Pearce wrote:
> During the GitTogether we were kicking around the idea of a ground-up
> implementation of a Git library. This may be easier than trying
> to grind down git.git into a library, as we aren't tied to any
> of the current global state baggage or the current die() based
> error handling.
>
> I've started an _extremely_ rough draft. The code compiles into a
> libgit.a but it doesn't even implement what it describes in the API,
> let alone a working Git implementation. Really what I'm trying to
> incite here is some discussion on what the API looks like.
I know this isn't actually helping a lot to define the real APIs, but we
should really not repeat current git mistakes and have a really uniform
APIs, meaning that first we must decide:
* proper namespacing (e.g. OBJ_* looks like failure to me, it's a way
too common prefix);
* proper public "stuff" naming (I e.g. realy like types names -- not
struct or enum tags, that I don't really care -- ending with _t as
it helps navigating source.
* ...
And write that down _first_. It's not a lot of work, but it must be
done. Working on a library really asks us to create something coherent
for our users.
Second, if we want this to be a successful stuff, we all agree we must
let git be able to use it medium term. That means that when git-core is
experimenting with new interfaces, it will probably need to hook into
some more internal aspects of the library. This is a problem to solve
elegantly, linking git against a static library won't please a lot of
vendors and linux distributions, and exporting "private" symbols is a
sure way to see them being abused.
Last but not least, I believe parts of git-core are currently easy to
just take. For example, any code *I* wrote, I hereby give permission to
relicense it in any of the following licenses: BSD-like, MIT-like,
WTFPL.
For example, on parse-options.c, git blame yields:
git blame -C -C -M parse-options.c|cut -d\( -f2|cut -d2 -f1|sort|uniq -c
16 Alex Riesen
6 Jeff King
47 Johannes Schindelin
12 Junio C Hamano
19 Michele Ballabio
1 Nanako Shiraishi
1 Olivier Marin
395 Pierre Habouzit
Okay, arguably parse-options.c in libgit quite doesn't makes sense
(though it can help bringing some kind of uniformity to other git
ecosystem tools built on libgit but that's not the point I'm trying to
make), I'm sure this kind of pattern where it's likely to be easy to
relicense code happens to some source files. Nicolas already said I
think that he was okay with relicensing his work too e.g.
Maybe we could, in parallel to that, contact people who "own" code in
the core parts of git to ask them where they stand, and see if that can
free some bits of the code. Attached is the current owners of the non
builtin-* C, non header, code in git core, got using this on top of
next:
for i in *.c; do
case $i in
builtin-*)
continue;;
*)
git blame -C -C -M $i|cut -d\( -f2|cut -d2 -f1;;
esac
done
and doing sort | uniq -c | sort -n >owners on it is attached.
Interestingly, it yields around 200 contributors "only" but more
interestingly, only 41 people "own" more than 100 lines of code in
there, and 23 more if you add people with more than 50. IOW, it wouldn't
be absurd to mail those roughly 65 people ask them what they think of
relicensing their work (for those where it's needed because of current
GPL-ness of the code) and see what result it yields. Worst case we lost
like 2 or 3 weeks, best case scenario, we can reuse some bits of git to
reimplement some of the algorithms verbatim.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #1.2: owners --]
[-- Type: text/plain, Size: 4029 bytes --]
16818 Junio C Hamano
8892 Linus Torvalds
4978 Johannes Schindelin
3664 Shawn O. Pearce
2938 Nick Hengeveld
2857 Nicolas Pitre
2455 Daniel Barkalow
1660 Pierre Habouzit
1294 Adam Simpkins
1126 Mike McCormack
1110 René Scharfe
861 Jeff King
653 Lukas Sandström
564 Miklos Vajna
531 Johannes Sixt
495 Alex Riesen
400 Martin Koegler
332 Petr Baudis
310 Jon Loeliger
263 Timo Hirvonen
236 Brandon Casey
231 Lars Hjemli
221 Sergey Vlasov
200 H. Peter Anvin
181 Dmitry Potapov
165 Mike Hommey
163 Matthias Lederhofer
158 Robert Shearman
155 Andreas Ericsson
151 YOSHIFUJI Hideaki
147 Franck Bui-Huu
137 Christian Couder
127 Stephan Beyer
127 David Reiss
123 Paolo Bonzini
120 Steffen Prohaska
115 Scott R Parish
113 Bradford C. Smith
109 Kristian Høgsberg
105 Heikki Orsila
100 Andy Whitcroft
93 Jim Meyering
90 Wincent Colaiuta
90 Julian Phillips
87 Stephen R. van den Berg
85 Marco Costalba
82 David Rientjes
76 Sven Verdoolaege
75 Eric Wong
72 Edgar Toernig
71 Ramsay Allan Jones
69 Martin Waitz
68 Mark Wooding
68 Eric W. Biederman
67 Geert Bosch
64 Michal Ostrowski
64 David Kastrup
63 Theodore Ts'o
63 Alexandre Julliard
61 Brian Downing
59 Alexander Gavrilov
58 Andy Parkins
56 Jon Seymour
52 Carlos Rica
47 Sean Estabrooks
44 Dana L. How
43 J. Bruce Fields
41 Ping Yin
40 Florian Forster
38 Tilman Sauerbeck
38 Serge E. Hallyn
38 Kay Sievers
38 Jason Riedy
37 Dustin Sallings
35 Nguyễn Thái Ngọc Duy
35 Luiz Fernando N. Capitulino
35 Clemens Buchacher
34 Fredrik Kuivinen
33 Pavel Roskin
33 Lars Knoll
32 Josef Weidendorfer
32 Jonas Fonseca
30 Peter Eriksen
28 Jay Soffian
26 Grégoire Barbier
25 Adam Roben
24 Marius Storm-Olsen
24 Luben Tuikov
24 Jürgen Rühle
24 Bryan Larsen
24 Anders Melchiorsen
23 Pieter de Bie
23 Nanako Shiraishi
23 Michael S. Tsirkin
23 Brian Hetro
22 Paul Mackerras
22 Jens Axboe
20 Thomas Rast
19 Paul Collins
19 Matthias Kestenholz
19 Joachim Berdal Haga
19 David Woodhouse
18 Mark Levedahl
17 Michele Ballabio
15 Gerrit Pape
14 Sam Vilain
13 Olivier Marin
13 Adam Brewster
12 SZEDER Gábor
12 Kai Ruemmler
12 Govind Salinas
11 Sasha Khapyorsky
11 Raphael Zimmerer
11 Brian Gernhardt
10 Steven Grimm
10 Holger Eitzenberger
10 Dmitry V. Levin
10 Dennis Stosberg
10 Avery Pennarun
9 Willy Tarreau
9 Santi Béjar
9 Robin H. Johnson
9 James Bowes
9 Björn Steinbrink
8 Markus Amsler
8 Jonathan del Strother
8 Johan Herland
8 Chris Parsons
8 Boyd Lynn Gerber
7 Robin Rosenberg
7 Paul Serice
7 Matt Kraai
7 Jason McMullan
7 Frank Lichtenheld
7 Christopher Li
6 Qingning Huo
6 Han-Wen Nienhuys
6 David Soria Parra
6 Björn Engelmann
6 Ariel Badichi
5 Sam Ravnborg
5 Peter Hagervall
5 Paul T Darga
5 Michal Vitecek
5 James Bottomley
5 Dotan Barak
5 David S. Miller
5 André Goddard Rosa
4 Uwe Kleine-König
4 Teemu Likonen
4 Samuel Tardieu
4 Patrick Welche
4 Michael Spang
4 Matthieu Moy
4 Joey Hess
4 Finn Arne Gangstad
4 Dmitry Kakurin
4 Carl Worth
4 Arjen Laarhoven
3 Steven Drake
3 Matthew Ogilvie
3 Li Hong
3 Josh Triplett
3 Jakub Narebski
3 Eygene Ryabinkin
3 Brian Gerst
2 Tom Prince
2 Todd Zullinger
2 Shawn Bohrer
2 Matthias Urlichs
2 Martin Sivak
2 Krzysztof Kowalczyk
2 Kevin Ballard
2 Jan Harkes
2 Fernando J. Pereda
2 Eyvind Bernhardsen
2 Deskin Miller
2 Charles Bailey
2 Andrew Ruder
2 Amos Waterland
2 Alp Toker
2 Alexey Nezhdanov
1 Yann Dirson
1 Tuncer Ayaz
1 Tony Luck
1 Timo Sirainen
1 Thomas Harning
1 Thomas Glanzmann
1 Sverre Hvammen Johansen
1 Stephan Feder
1 Simon Hausmann
1 Salikh Zakirov
1 Ryan Anderson
1 Rutger Nijlunsing
1 Randal L. Schwartz
1 Peter Valdemar Mørch
1 Paul Eggert
1 Patrick Higgins
1 Mika Kukkonen
1 Matt Draisey
1 Marco Roeland
1 Lars Doelle
1 Jerald Fitzjerald
1 Jean-Luc Herren
1 Jan Andres
1 Ingo Molnar
1 David Symonds
1 David Meybohm
1 Darrin Thompson
1 Bryan Donlan
1 Brad Roberts
1 Blake Ramsdell
1 Benoit Sigoure
1 Adeodato Simó
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* commit type
From: 7rans @ 2008-10-31 17:58 UTC (permalink / raw)
To: git
Hi--
I have a feature request.
I'd like to be a able to add a commit type to my commits, like 'major', 'minor',
'bug', etc. it would be useful in reviewing changes, especially when listing
changes for end-users to see, because then miscellaneous/administrative commits
could be omitted and only changes important to users listed.
Currently I achieve this by adding "[type]" to the end of my commit messages.
But of course that's less than optimal. I think being able to add a commit type
would be generally useful to everyone, and really has no downside becuase you do
not need to use it if you prefer not.
Thanks,
trans.
^ permalink raw reply
* Re: commit type
From: David Symonds @ 2008-10-31 18:04 UTC (permalink / raw)
To: 7rans; +Cc: git
In-Reply-To: <loom.20081031T174821-603@post.gmane.org>
On Fri, Oct 31, 2008 at 10:58 AM, 7rans <transfire@gmail.com> wrote:
> Currently I achieve this by adding "[type]" to the end of my commit messages.
> But of course that's less than optimal.
Why is that less than optimal? It seems a lot less intrusive than what
you suggest.
Dave.
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Jeff King @ 2008-10-31 18:24 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Shawn O Pearce
In-Reply-To: <1225429753-70109-1-git-send-email-benji@silverinsanity.com>
On Fri, Oct 31, 2008 at 01:09:13AM -0400, Brian Gernhardt wrote:
> Not all /bin/sh have a builtin echo that recognizes -n. Using printf
> is far more portable.
>
> Discovered on OS X 10.5.5 in t4030-diff-textconv.sh and changed in all
> the test scripts.
Hmph. I think this is a good patch, and there is precedent in the past
(20fa04ea, 2aad957, 9754563). But I am surprised this was not caught by
our recent autobuilding project.
However, it seems to work on FreeBSD (which makes it doubly weird that
it is broken on OS X). On Solaris, the /bin/sh is so horribly broken
that I have to use bash anyway. Commit 9754563 claims breakage on AIX,
but it looks like Mike is doing the AIX builds with bash.
So I guess we just need an OS X autobuild. ;)
> t/t4030-diff-textconv.sh | 2 +-
And of course this one was me, but I blame JSixt, whose test I just
mindlessly copied. ;)
-Peff
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Pierre Habouzit @ 2008-10-31 18:36 UTC (permalink / raw)
To: Jeff King; +Cc: Brian Gernhardt, Git List, Shawn O Pearce
In-Reply-To: <20081031182456.GC3230@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]
On Fri, Oct 31, 2008 at 06:24:56PM +0000, Jeff King wrote:
> On Fri, Oct 31, 2008 at 01:09:13AM -0400, Brian Gernhardt wrote:
>
> > Not all /bin/sh have a builtin echo that recognizes -n. Using printf
> > is far more portable.
> >
> > Discovered on OS X 10.5.5 in t4030-diff-textconv.sh and changed in all
> > the test scripts.
>
> Hmph. I think this is a good patch, and there is precedent in the past
> (20fa04ea, 2aad957, 9754563). But I am surprised this was not caught by
> our recent autobuilding project.
Set up a Debian autobuilder with dash as a /bin/sh (apt-get install
dash, dpkg-reconfigure -plow dash and say 'yes'). You'll see those kind
of problems arise immediately.
Dash is a POSIX compatible shell, with almost no extension added (in
particular its echo has no -n option) which helps to find those kind of
issues.
It would help detecting git shell scripts that use bashism as well.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Jeff King @ 2008-10-31 18:39 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Brian Gernhardt, Git List, Shawn O Pearce
In-Reply-To: <20081031183601.GB8464@artemis.corp>
On Fri, Oct 31, 2008 at 07:36:01PM +0100, Pierre Habouzit wrote:
> Set up a Debian autobuilder with dash as a /bin/sh (apt-get install
> dash, dpkg-reconfigure -plow dash and say 'yes'). You'll see those kind
> of problems arise immediately.
I don't need to; my development box is Debian with dash as /bin/sh. :)
> Dash is a POSIX compatible shell, with almost no extension added (in
> particular its echo has no -n option) which helps to find those kind of
> issues.
>
> It would help detecting git shell scripts that use bashism as well.
Agreed, and actually I found such a bashism (test ==) last week (though
of course it also broke on FreeBSD).
-Peff
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 18:41 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Scott Chacon
In-Reply-To: <20081031174745.GA4058@artemis.corp>
Pierre Habouzit <madcoder@debian.org> wrote:
>
> I know this isn't actually helping a lot to define the real APIs, but we
> should really not repeat current git mistakes and have a really uniform
> APIs, meaning that first we must decide:
Agreed.
> * proper namespacing (e.g. OBJ_* looks like failure to me, it's a way
> too common prefix);
Fixed. Its now GIT_OBJ_*.
> * proper public "stuff" naming (I e.g. realy like types names -- not
> struct or enum tags, that I don't really care -- ending with _t as
> it helps navigating source.
Fixed, types now end in _t.
> And write that down _first_. It's not a lot of work, but it must be
> done. Working on a library really asks us to create something coherent
> for our users.
How about this?
http://www.spearce.org/projects/scm/libgit2/apidocs/CONVENTIONS
> Second, if we want this to be a successful stuff, we all agree we must
> let git be able to use it medium term. That means that when git-core is
> experimenting with new interfaces, it will probably need to hook into
> some more internal aspects of the library. This is a problem to solve
> elegantly, linking git against a static library won't please a lot of
> vendors and linux distributions, and exporting "private" symbols is a
> sure way to see them being abused.
Private symbols are a problem. On some systems we can use link
editing to strip them out of the .so, but that isn't always going to
work everywhere. I've outlined the idea of using double underscore
to name private functions, and we can link-edit out '*__*' if the
platform's linker supports it (e.g. GNU ld).
> Last but not least, I believe parts of git-core are currently easy to
> just take. For example, any code *I* wrote, I hereby give permission to
> relicense it in any of the following licenses: BSD-like, MIT-like,
> WTFPL.
Yea. We could try to do that. I don't know how far it will get us,
but if we have to "steal" code we can rip a good part from JGit.
Its BSD-like, but has that "icky Java smell" to it. :-)
Before worrying about where we get implementation bits from I'm
more interested in trying to get a consistent view of what our
namespace looks like, and what our calling conventions are, so we
have some sort of benchmark to measure APIs against as we add them
to the implementation.
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-10-31 18:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Scott Chacon
In-Reply-To: <20081031184154.GV14786@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 3787 bytes --]
On Fri, Oct 31, 2008 at 06:41:54PM +0000, Shawn O. Pearce wrote:
> Pierre Habouzit <madcoder@debian.org> wrote:
> How about this?
>
> http://www.spearce.org/projects/scm/libgit2/apidocs/CONVENTIONS
looks like a good start.
> > Second, if we want this to be a successful stuff, we all agree we must
> > let git be able to use it medium term. That means that when git-core is
> > experimenting with new interfaces, it will probably need to hook into
> > some more internal aspects of the library. This is a problem to solve
> > elegantly, linking git against a static library won't please a lot of
> > vendors and linux distributions, and exporting "private" symbols is a
> > sure way to see them being abused.
>
> Private symbols are a problem. On some systems we can use link
> editing to strip them out of the .so, but that isn't always going to
> work everywhere. I've outlined the idea of using double underscore
> to name private functions, and we can link-edit out '*__*' if the
> platform's linker supports it (e.g. GNU ld).
Well, I propose the following: we set-up on GNU-ld + gcc enabled systems
all what is needed to use symbol visibility, which isn't that intrusive,
and also rather easy given your GIT_EXPORT macro definition.
This way, people who care about portability across all libgit2 supported
platforms will have to align on the lowest common denominator, which
will not have any kind of private stuff available, so we're safe. And
GCC/GNU-ld enabled platforms cover most of the popular platforms (namely
linux and *BSD, I'm not sure about Macos dynlibs). Even win32 has kind
of what you need to do visibility I think.
IOW prehistoric systems will be have to cope with that because of Linux
(yeah, this is kind of deliciously backwards ;p).
No, my worry was rather wrt git core itself, I really think we _must_
make it link against libgit2 if we want libgit2 to stay current, but git
core will _very likely_ need the private stuff, and it _will_ be a
problem. I mean we cannot seriously so-name a library and show its guts
at the same time, and I'm unsure how to fix that problem. _that_ was my
actual question.
> > Last but not least, I believe parts of git-core are currently easy to
> > just take. For example, any code *I* wrote, I hereby give permission to
> > relicense it in any of the following licenses: BSD-like, MIT-like,
> > WTFPL.
>
> Yea. We could try to do that. I don't know how far it will get us,
> but if we have to "steal" code we can rip a good part from JGit.
> Its BSD-like, but has that "icky Java smell" to it. :-)
>
> Before worrying about where we get implementation bits from I'm
> more interested in trying to get a consistent view of what our
> namespace looks like, and what our calling conventions are, so we
> have some sort of benchmark to measure APIs against as we add them
> to the implementation.
I'd say we should do both at the same time. Asking people if they would
agree to relicense code can be done in parallel. We could extract a list
of source files that we may need (my extraction included stuff that is
very unlikely to be useful like test-*.c that aren't useful, and some
that are already BSD I think), and see who it yields. It should be
possible to do a matrix source-file x people and see on a per-file basis
what they think.
If someone gives me the list of files we should consider (I'm not sure
about a good list right now) I could do the matrix at some fixed sha1
from git.git using git blame -C -M -M -w, and ask people see where it
leads us ?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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