* Re: getting list of objects for packing
From: Brandon Casey @ 2008-10-31 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <7v7i7o8nc5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> Nicolas Pitre wrote:
>>> On Fri, 31 Oct 2008, Brandon Casey wrote:
>>>> -The sed statement is stripping off anything after the sha1. Any way to
>>>> get rev-list to print out just the sha1 so that sed is not necessary?
>>> If you strip the data after the SHA1 when pipping into pack-objects then
>>> you'll have horrible delta compression results. The path names after
>>> each SHA1 is used to sort objects when trying to find best matches for
>>> delta compression. So you should preserve those and feed it back
>>> especially with those packs that you still want delta compression for.
>> Ah, I'll have to rethink my script then. Thanks!
>
> Yeah, but wasn't the purpose of your whole exercise to list objects that
> do not delta nor compress well with each other, in which case the delta
> compression order (aka name hash) would not matter, no?
The script I wrote actually starts up two pack-objects instances and I was
writing the objects I wanted to pack _normally_ to one, and the ones that I
did not want compressed/deltafied to the other (which was started with
--no-reuse-object --window=0 --depth=0 --compression=0).
I didn't mentioned that fact in my first email, but I'm very glad Nico
made his point.
-brandon
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 21:43 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: david, Pierre Habouzit, git, Scott Chacon
In-Reply-To: <alpine.LFD.2.00.0810311651451.13034@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 31 Oct 2008, david@lang.hm wrote:
> > On Fri, 31 Oct 2008, Nicolas Pitre wrote:
> > > On Fri, 31 Oct 2008, Pierre Habouzit wrote:
> > >
> > > > 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.
> > >
> > > First........... is there really a need to re-license it?
> > > If so then the choice of license is IMHO rather important.
Some people want to be able to link the library into an application
that they redistribute binaries of, but not sources to. Those folks
have also volunteered to help write the library. If they put their
code where their mouth is, then I think they should be able to use
their code the way they want to.
That said, I think the license choice that makes the most sense
here is probably LGPL or GPL+gcc exception, like you note below.
BSD and MIT are probably not serious contenders.
> > at the very least you should go from GPLv2 to LGPLv2 for the library.
>
> Sure.
Well, we cannot do a GPL->LGPL switch on code without author
permission for that sort of re-licensing.
That said, I think many authors of git.git code would be more
comfortable with a GPL->LGPL change, where they wouldn't be OK with
a GPL->BSD/MIT change. There may be some folks though who still
wouldn't accept a GPL->LGPL move.
> > > My favorite license for a library is the GPL with the gcc exception,
...
> > >
> > > For reference, here's the exception text:
> > >
> > > In addition to the permissions in the GNU General Public License, the
> > > Free Software Foundation gives you unlimited permission to link the
> > > compiled version of this file into combinations with other programs,
> > > and to distribute those combinations without any restriction coming
> > > from the use of this file. (The General Public License restrictions
> > > do apply in other respects; for example, they cover modification of
> > > the file, and distribution when not linked into a combine
> > > executable.)
> >
> > <shrug>, I don't see why this is needed with the LGPL, but I'm not a lawyer.
>
> The LGPL also asks that proprietary applications provides necessary
> object files so you can link it against an alternative implementation of
> the LGPL library if you so wish. With dynamic libraries this is rather
> moot but I think that's the main difference.
I'm happy with either the LGPL or the GPL+exception above. If I
read these correctly the GPL+exception allows one to distribute
static executables without source or object files, so long as the
library source wasn't modified. I'd almost prefer just using the
standard LGPL then, static linking isn't very common anymore.
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 21:50 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: david, Pierre Habouzit, git, Scott Chacon
In-Reply-To: <20081031214356.GX14786@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> That said, I think the license choice that makes the most sense
> here is probably LGPL or GPL+gcc exception, like you note below.
> BSD and MIT are probably not serious contenders.
I should clarify that I said the above paragraph...
> That said, I think many authors of git.git code would be more
> comfortable with a GPL->LGPL change, where they wouldn't be OK with
> a GPL->BSD/MIT change. There may be some folks though who still
> wouldn't accept a GPL->LGPL move.
because of this paragraph.
Like Pierre I also prefer a BSD style license, and JGit is under
that, as it offers quite a bit of freedom for the consumer of
the code.
I'm also not too worried about not getting changes back. If someone
forks away from the base project and doesn't contribute back,
that's their problem. So long as the base project has sufficient
momentum under it making changes and improving things, everyone
else will want to pull and either face merge-hell once in a while,
or send changes back upstream to avoid merge-hell.
But I doubt Git regulars share our views on this, and I think most
of the major contributors to git.git have stated multiple times
that they prefer a GPL style license on their code. I want those
people to contribute to libgit2 (assuming the project moves past the
pie-in-the-sky theory stage), so I want the license to be something
they will be comfortable with.
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-10-31 21:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nicolas Pitre, david, git, Scott Chacon
In-Reply-To: <20081031214356.GX14786@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 959 bytes --]
On Fri, Oct 31, 2008 at 09:43:56PM +0000, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > On Fri, 31 Oct 2008, david@lang.hm wrote:
> > > at the very least you should go from GPLv2 to LGPLv2 for the library.
> >
> > Sure.
>
> Well, we cannot do a GPL->LGPL switch on code without author
> permission for that sort of re-licensing.
>
> That said, I think many authors of git.git code would be more
> comfortable with a GPL->LGPL change, where they wouldn't be OK with
> a GPL->BSD/MIT change. There may be some folks though who still
> wouldn't accept a GPL->LGPL move.
FWIW, I dislike the LGPL for many reasons, and I prefer 100x times a GPL
with GCC kind of exceptions. But if other people hate it, I wont be
be a problem and refuse it.
--
·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: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git, Scott Chacon
In-Reply-To: <7vfxmc8r8g.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> >> * 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.
>
> Ugh.
>
> You could talk me into it if you promise never typedef structures (or
> pointer to structures) with such symbols, I guess.
I should write that one down in CONVENTIONS.
IMHO:
typedef uint32_t uid_t; /* sane */
typedef enum {...} status_t; /* sane */
typedef struct foo_t foo_t; /* sane */
typedef struct {...} foo_t; /* borderline insane */
typedef char* str_t; /* totally nuts */
typedef char**** str_pppp_t; /* totally nuts */
Hiding the fact that scalar types like a uid_t are 32 bits on
this system is reasonable. Heck, uid_t is already in POSIX,
we shouldn't fight that sort of idea. It at least improves
documentation somewhat.
Hiding the fact that some scalar type is an enum, so you don't have
to type "enum blah" everywhere is also reasonable. Its slightly
better than #define some magic constants and passing an int
everywhere. Its a reasonable balance between reducing keystrokes
and keeping the code semi-self-documenting.
Hiding the fact that an opaque struct (or union) you cannot ever
see the members of is a struct or union is good API design. You can
later change the major class from struct to union or back, or totally
redefine it, but the caller never needs to know what is going on.
Hiding a pointer is wrong. Callers should know they are getting a
pointer, or are being asked to supply a pointer-to-a-pointer. So the
"FILE*" stdio functions are sane, because we don't know what is under
a FILE type but we do know when we are dealing with a pointer to one.
My original proposal didn't stick _t onto the end of everything,
because I didn't think it was really necessary. I'm fine with it
either way. It may be better to include the _t suffix, it seems
to be somewhat common in libraries.
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-10-31 21:59 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <20081031174745.GA4058@artemis.corp>
Pierre Habouzit wrote:
> 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);
>
As it's the git-lib, all public functions should almost certainly be
prefixed with "git" or "git_". I favor "git_".
> * 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.
>
*_t types are reserved by POSIX for future implementations, so that's
a no-go (although I doubt POSIX will ever make types named git_*_t).
Apart from that, please consider reading Ulrich Drepper's musings on
library design at http://people.redhat.com/drepper/goodpractice.pdf
It's pretty short but brings up nearly all the crucial points one really
don't want to forget.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-10-31 22:01 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pierre Habouzit, git, Scott Chacon
In-Reply-To: <490B7FD3.8060003@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
>> * 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.
>
> *_t types are reserved by POSIX for future implementations, so that's
> a no-go (although I doubt POSIX will ever make types named git_*_t).
Yikes. Anyone know where a concise list of the reserved names are?
> Apart from that, please consider reading Ulrich Drepper's musings on
> library design at http://people.redhat.com/drepper/goodpractice.pdf
I think I've read that before, but I'll skim over it again.
Thanks for the link.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/3] git send-email: do not ask questions when --compose is used.
From: Ian Hilt @ 2008-10-31 22:01 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20081031213803.GB21799@artemis.corp>
On Fri, Oct 31, 2008 at 10:38:03PM +0100, Pierre Habouzit wrote:
> On Fri, Oct 31, 2008 at 09:33:38PM +0000, Ian Hilt wrote:
> > On Fri, Oct 31, 2008 at 01:36:48PM +0100, Pierre Habouzit wrote:
> > > +GIT: Please enter your email below this line.
> >
> > At first glance I thought this meant to enter my email address here.
> > So, instead of "email" would "message" be better? Although on second
> > glance I realized this is where the body of the message went. Not sure
> > if this is worth changing.
>
> Well, this line sounds kind of awkward actually, so I was even thinking
> about removing it.
>
> Decent editors should probably have a plugin to put the cursor here and
> be done with it.
>
>
> In fact what looks odd is the GIT: stuff. a line looking like:
>
> --- write your message below this line ---
>
> Looks 10x better, though need some code to strip it out if the user kept
> it, and I'm lazy, GIT: stuff is automatically removed...
Or, to follow the convention of git-status and git-commit, you could do
this with "# ".
So something like,
--->8---
From: Ian Hilt <ihilt@mcgregor-surmount.com>
Date: Fri, 31 Oct 2008 17:55:46 -0400
Subject: [PATCH] Use a hash instead of GIT: for line removal
Signed-off-by: Ian Hilt <ihilt@mcgregor-surmount.com>
---
git-send-email.perl | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 5cebb40..c6e21a8 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -427,7 +427,7 @@ sub get_patch_subject($) {
while (my $line = <$fh>) {
next unless ($line =~ /^Subject: (.*)$/);
close $fh;
- return "GIT: $1\n";
+ return "# $1\n";
}
close $fh;
die "No subject line in $fn ?";
@@ -446,14 +446,14 @@ if ($compose) {
print C <<EOT;
From $tpl_sender # This line is ignored.
-GIT: Lines beginning in "GIT: " will be removed.
-GIT: Consider including an overall diffstat or table of contents
-GIT: for the patch you are writing.
+# Lines beginning in "# " will be removed.
+# Consider including an overall diffstat or table of contents
+# for the patch you are writing.
From: $tpl_sender
Subject: $tpl_subject
In-Reply-To: $tpl_reply_to
-GIT: Please enter your email below this line.
+# --- write your message below this line ---
EOT
for my $f (@files) {
@@ -479,7 +479,7 @@ EOT
my $in_body = 0;
my $summary_empty = 1;
while(<C>) {
- next if m/^GIT: /;
+ next if m/^# /;
if ($in_body) {
} elsif (/^\n$/) {
$in_body = 1;
--->8---
> But if that's the only thing that you don't like in the series, I'm
> glad, this is quite a minor issue ;)
I've thought something like this would be a good thing. An editor makes
things easier to fix than the command-line.
Ian
^ permalink raw reply related
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Johannes Schindelin @ 2008-10-31 22:14 UTC (permalink / raw)
To: Alex Riesen
Cc: Sam Vilain, Git Mailing List, Junio C Hamano, Jeff King,
René Scharfe
In-Reply-To: <20081031070003.GA4458@blimp.localdomain>
Hi,
On Fri, 31 Oct 2008, Alex Riesen wrote:
> ActiveState Perl on Windows is portable? To another windows, maybe.
/me wonders why you could not use the Perl that ships with Git for
Windows, at least for the purposes of Git.
Ciao,
Dscho
^ permalink raw reply
* Re: libgit2 - a true git library
From: Nicolas Pitre @ 2008-10-31 22:10 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <20081031213114.GA21799@artemis.corp>
On Fri, 31 Oct 2008, Pierre Habouzit wrote:
> Git is currently mostly "GPLv2 or later". A BSDish license was
> mentioned, because it's the most permissive one and that nobody cared
> that much, though a LGPL/GPL-with-GCC-exception would probably fly.
I do care. I think the BSD license is too permissive. There are really
nifty pieces of code in Git that I would be really sorry to see go
proprietary.
> Many of the people needing a library for libgit are probably reading the
> list, I'll let them comment. The kind of license you propose would
> totally suite my needs, and I think, most of the one discussed at
> GitTogether'08 (except for the eclipse people disliking GPL'ed stuff,
> but anyways there was the issue of C code being non pure java anyways,
> so maybe Shawn can comment on that bit, I don't recall the exact
> specifics I must reckon).
Eclipse is Java and that issue is already solved with JGIT which doesn't
reuse C code from git.
> OT: FWIW I prefer BSDish licenses (even the MIT actually) for libraries
> because I believe that computing is overall better if everyone can use
> the right tool for the task, and I don't want to prevent people from
> using good stuff (I hope I write good stuff ;P) because of the license.
Everybody can and does link against glibc on Linux which is LGPL. So
that doesn't affect "usage".
> And I don't care about people don't giving back to me, those are not the
> kind of people who would have given back if it was GPL'ed anyways.
> But I understand this is a completely personal view, and I'm not even
> trying to persuade you :)
Sure, and that's where we differ. I let you use my code for free, as
long as you give me back your improvements to it. This way everybody
stays honnest. I think this is Linus' view as well which he often
resume as "tit for tat".
Nicolas
^ permalink raw reply
* Re: getting list of objects for packing
From: Jakub Narebski @ 2008-10-31 22:23 UTC (permalink / raw)
To: Brandon Casey; +Cc: Junio C Hamano, Nicolas Pitre, Git Mailing List
In-Reply-To: <fAUegZ3bxPo8HquZjUM9syW-giYefuAzBtb1XXHQ-TwbmvJvMZvmDA@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Junio C Hamano wrote:
> > Yeah, but wasn't the purpose of your whole exercise to list objects that
> > do not delta nor compress well with each other, in which case the delta
> > compression order (aka name hash) would not matter, no?
>
> The script I wrote actually starts up two pack-objects instances and I was
> writing the objects I wanted to pack _normally_ to one, and the ones that I
> did not want compressed/deltafied to the other (which was started with
> --no-reuse-object --window=0 --depth=0 --compression=0).
>
> I didn't mentioned that fact in my first email, but I'm very glad Nico
> made his point.
Wasn't there some gitattribute which prohibited deltification of some
files (`delta` or something)? Or wasn't this patch accepted, as I
cannot find such attribute in documentation (gitattributes(5))...
... err, it was added in commit a74db82e15cd8a2c53a4a83e9a36dc7bf7a4c750
(Teach "delta" attribute to pack-objects.) by Junio C Hamano in May
19, _without_ documentation.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Documentation/gitattributes: Add subsection header for each attribute
From: Jakub Narebski @ 2008-10-31 22:24 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
This makes attributes easier to find; before this patch some
attributes had individual subsections, and some didn't.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/gitattributes.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 24e880c..eb64841 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -213,6 +213,9 @@ with `crlf`, and then `ident` and fed to `filter`.
Generating diff text
~~~~~~~~~~~~~~~~~~~~
+`diff`
+^^^^^^
+
The attribute `diff` affects if 'git-diff' generates textual
patch for the path or just says `Binary files differ`. It also
can affect what line is shown on the hunk header `@@ -k,l +n,m @@`
@@ -331,6 +334,9 @@ patterns are available:
Performing a three-way merge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+`merge`
+^^^^^^^
+
The attribute `merge` affects how three versions of a file is
merged when a file-level merge is necessary during `git merge`,
and other programs such as `git revert` and `git cherry-pick`.
--
1.6.0.3
^ permalink raw reply related
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Johannes Schindelin @ 2008-10-31 22:36 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, pasky, srabbelier
In-Reply-To: <1225445204-28000-1-git-send-email-madcoder@debian.org>
Hi,
On Fri, 31 Oct 2008, Pierre Habouzit wrote:
> git_commit_non_empty_tree is added to the functions that can be run from
> commit filters. Its effect is to commit only commits actually touching
> the tree and that are not merge points either.
>
> The option --prune-empty is added. It defaults the commit-filter to
> 'git_commit_non_empty_tree "$@"', and can be used with any other
> combination of filters, except --commit-hook that must used
> 'git_commit_non_empty_tree "$@"' where one puts 'git commit-tree "$@"'
> usually to achieve the same result.
I think that the example Sverre posted is better. It might be a bit more
to write out, but at least people can adapt it to their needs (as opposed
to only skip "empty" commits).
However, I would _love_ to see your tests being merged with Sverre's patch
(of course, the tests should use the described procedure, then).
Ciao,
Dscho
^ permalink raw reply
* Re: git archive problem with 1.6.0.3 (maybe regression?)
From: Charles Bailey @ 2008-10-31 22:37 UTC (permalink / raw)
To: Alessandro Guido; +Cc: git
In-Reply-To: <200810312213.32224.ag@alessandroguido.name>
Alessandro Guido wrote:
> [please CC: me on replies]
>
> Hi everybody.
>
> With git 1.6.0.3, I get the following error when trying to "git archive" on a
> bare clone of the Linux kernel repo:
>
> ~ $ cd Kernel/
> ~/Kernel $ ls
> branches config description FETCH_HEAD HEAD hooks info logs objects
> packed-refs refs
> ~/Kernel $ git archive 721d5df > /dev/null
> fatal: Not a valid object name
>
> With git 1.6.0.2, on the same tree, it works fine.
http://git.kernel.org/?p=git/git.git;a=commit;h=ddff8563510a2c5c675d488a02e2642306430fc1
^ permalink raw reply
* Re: [PATCH] Introduce receive.denyDeletes
From: Johannes Schindelin @ 2008-10-31 22:45 UTC (permalink / raw)
To: Jan Krüger; +Cc: Shawn O. Pearce, git, gitster
In-Reply-To: <20081030194503.2f9ece1a@perceptron>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 170 bytes --]
Hi,
On Thu, 30 Oct 2008, Jan Krüger wrote:
> By the way, I love what your mail client did to my name.
I think Shawn forgot to turn his pirate filter off.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Pierre Habouzit @ 2008-10-31 22:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, pasky, srabbelier
In-Reply-To: <alpine.DEB.1.00.0810312334480.22125@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]
On Fri, Oct 31, 2008 at 10:36:58PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 31 Oct 2008, Pierre Habouzit wrote:
>
> > git_commit_non_empty_tree is added to the functions that can be run from
> > commit filters. Its effect is to commit only commits actually touching
> > the tree and that are not merge points either.
> >
> > The option --prune-empty is added. It defaults the commit-filter to
> > 'git_commit_non_empty_tree "$@"', and can be used with any other
> > combination of filters, except --commit-hook that must used
> > 'git_commit_non_empty_tree "$@"' where one puts 'git commit-tree "$@"'
> > usually to achieve the same result.
>
> I think that the example Sverre posted is better. It might be a bit more
> to write out, but at least people can adapt it to their needs (as opposed
> to only skip "empty" commits).
>
> However, I would _love_ to see your tests being merged with Sverre's patch
> (of course, the tests should use the described procedure, then).
Well Sverre's example is probably the most efficient way to do the task,
though the thing is right now, what one wants is rarely to "just" skip
empty commits, but to do some modifications that does not leave empty
commits.
IOW not doing a modification _then_ a new one, but both at the same
time. Given how slow filter-branch can be, it's better to do one
transformation instead of two.
Note that I don't think we should apply only my patch and not Sverre's,
his proposal just made me think that this was an itch I wanted to
scratch for a long time, and both probably are complementary.
--
·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: git archive problem with 1.6.0.3 (maybe regression?)
From: Alessandro Guido @ 2008-10-31 22:43 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <490B8896.6040007@hashpling.org>
On Friday 31 October 2008 23:37:10 Charles Bailey wrote:
> http://git.kernel.org/?p=git/git.git;a=commit;h=ddff8563510a2c5c675d488a02e
>2642306430fc1
Good. Thank you for the link
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Johannes Schindelin @ 2008-10-31 22:53 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Git List
In-Reply-To: <200810312035.20016.fg@one2team.com>
Hi,
On Fri, 31 Oct 2008, Francis Galiegue wrote:
> Unless I'm mistaken (and I probably am), the $(...) construct is
> bash-specific, isn't it?
You're mistaken,
Dscho
P.S.:
http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_06_03
^ permalink raw reply
* Re: libgit2 - a true git library
From: Junio C Hamano @ 2008-10-31 22:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andreas Ericsson, Pierre Habouzit, git, Scott Chacon
In-Reply-To: <20081031220133.GA14786@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Andreas Ericsson <ae@op5.se> wrote:
>>> * 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.
>>
>> *_t types are reserved by POSIX for future implementations, so that's
>> a no-go (although I doubt POSIX will ever make types named git_*_t).
>
> Yikes. Anyone know where a concise list of the reserved names are?
Essentially, anything that ends with "_t" ;-)
http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_02.html#tag_02_02_02
Look for "Any Header" in the table.
>> Apart from that, please consider reading Ulrich Drepper's musings on
>> library design at http://people.redhat.com/drepper/goodpractice.pdf
>
> I think I've read that before, but I'll skim over it again.
> Thanks for the link.
>
> --
> Shawn.
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Johannes Schindelin @ 2008-10-31 23:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: Pierre Habouzit, git
In-Reply-To: <20081031165003.GA5355@steel.home>
Hi,
On Fri, 31 Oct 2008, 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"?
I thought we agreed that we should _never_ remove support for "git
revert"? I mean, we can deprecate it, but I find it pretty strong, and
unnecessary, to break existing users' expectations.
Ciao,
Dscho
^ permalink raw reply
* Re: libgit2 - a true git library
From: Johannes Schindelin @ 2008-10-31 23:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pierre Habouzit, Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <490B7FD3.8060003@op5.se>
Hi,
On Fri, 31 Oct 2008, Andreas Ericsson wrote:
> Apart from that, please consider reading Ulrich Drepper's musings on
> library design at http://people.redhat.com/drepper/goodpractice.pdf
I do not know if I want to trust a person that has shown a certain
eagerness to ignore good library design by breaking the well-established
dont-change-apis-on-minor-versions idiom, and instead of listening to
users that have problems as a consequence rather ignore them.
Instead, let's build on the knowledge of people we have learnt to trust,
on this list.
Thank you,
Dscho
^ permalink raw reply
* Re: libgit2 - a true git library
From: Junio C Hamano @ 2008-10-31 23:14 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Pierre Habouzit, Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <alpine.LFD.2.00.0810311558540.13034@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> Depends. Sure, I gave permission to copy some of my code for JGIT
> because 1) JGIT is Java code in which I have little interest, 2) the
> different license was justified by the nature of the JGIT project, and
> 3) although no license convey this I asked for the C version of git to
> remain the authoritative reference and that any improvements done to JGIT
> first be usable in the C version under the GPL.
This reminds me that Shawn earlier in an unrelated thread asked me if I
can relicense builtin-blame.c for JGIT; your reasoning fully matches that
of mine regarding that part of the code.
> My favorite license for a library is the GPL with the gcc exception,
> i.e. what libraries coming with gcc are using. They're GPL but with an
> exception allowing them to be linked with anything.
Although I'd be Ok with either GPL + gcc exception on whatever core-ish
(i.e. what will be necessary for libgit2; "blame" would not count) pieces
I have in C-git codebase, "can be linked with anything" allows a gaping
hole to the library, which I'm a bit hesitant to swallow without thinking.
E.g. our read_object() may look like this:
void *read_object(const object_name_t sha1,
enum object_type *type,
size_t *size)
{
...
}
but an extension a closed-source person may sell you back may do:
+typedef void *read_object_fn(const object_name_t,
+ enum object_type *,
+ size_t *);
+read_object_fn read_object_custom = NULL;
void *read_object(const object_name_t sha1,
enum object_type *type,
size_t *size)
{
+ if (read_object_custom != NULL)
+ return read_object_custom(sha1, type, size);
...
}
I.e. use the supplied custom function to do proprietary magic, such as
reading the object lazily from elsewhere over the network. And we will
never get that magic bit back.
Although no license asks this, my wish is that if somebody built on top of
what I wrote to make the world a better place, I'd like the same access to
that additional code so that I too can enjoy the improved world. Because
almost all of my code in git.git are under GPLv2, in reality I do not have
any access to your software as long as you do not distribute your
additional code that made the world a better place, which is a bit sad.
^ permalink raw reply
* Re: commit type
From: Johannes Schindelin @ 2008-10-31 23:27 UTC (permalink / raw)
To: 7rans; +Cc: git
In-Reply-To: <loom.20081031T191102-81@post.gmane.org>
Hi,
On Fri, 31 Oct 2008, 7rans wrote:
> David Symonds <dsymonds <at> gmail.com> writes:
>
> > On Fri, Oct 31, 2008 at 10:58 AM, 7rans <transfire <at> 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.
>
> Because it becomes formalized. Which means people can write tools other
> people can use to work with them.
So you want to force this onto all Git users?
If yes: that murmur you hear in the background, it might well be the
collective "thanks, but no thanks" of people who do not want that type of
distinction between different commits.
If no: what would be the real difference from that suffix in the oneline?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Junio C Hamano @ 2008-10-31 23:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, Pierre Habouzit, git
In-Reply-To: <alpine.DEB.1.00.0811010012320.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 31 Oct 2008, 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"?
>
> I thought we agreed that we should _never_ remove support for "git
> revert"? I mean, we can deprecate it, but I find it pretty strong, and
> unnecessary, to break existing users' expectations.
Likewise.
The current state of affairs is that there is no remedy if teachers find
"git checkout -- path" or "git revert HEAD~24" is confusing to new people.
By introducing "git unstage path" or "git cherry-pick -r HEAD~24",
teachers can choose to teach what they feel less confusing, and they do
not have to teach "git checkout -- path" or "git revert HEAD~24". We
should stop there.
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Alex Riesen @ 2008-10-31 23:24 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20081031165814.GD627@artemis.corp>
Pierre Habouzit, Fri, Oct 31, 2008 17:58:14 +0100:
> 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.
Have it 5 times in my bash history of 20k lines. 4 recent, one relatively old.
> 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'
Well, I kind of got used to it. And it makes sense (as does -R by
cherry-pick, I have to admit). I have no other argument against the
change.
^ 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