* Re: git to libgit2 code relicensing
From: Pau Garcia i Quiles @ 2008-11-15 10:28 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <491EA1CC.9020605@op5.se>
> Shawn posted the exact text. The spirit of that license is that anyone can
> use an unmodified version of the library for whatever they want, but it's
> illegal to link non-GPL software to an altered version of the library. That
> is, the git community will get all changes back while other projects can
> use the official version of the library without having to worry about
> licensing issues. EvilCompany cannot make changes to the library and then
> link non-GPL'd software to their changed version. They can do that if they
> send their library changes upstream and then only use them once they're
> considered "official" though.
Do you mean if I write a patch to libgit2, send it upstream and make
it public on my website but it is not accepted upstream, I cannot link
my modified libgit2 version (i. e. libgit2 + my patch) to my non-GPL
software? It looks insane to me: I wrote the patch and made it public
but you guys did not accept it!
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Andreas Ericsson @ 2008-11-15 11:05 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Git Mailing List
In-Reply-To: <3af572ac0811150228k291b8850idc34cb474f455aa7@mail.gmail.com>
Pau Garcia i Quiles wrote:
>> Shawn posted the exact text. The spirit of that license is that anyone can
>> use an unmodified version of the library for whatever they want, but it's
>> illegal to link non-GPL software to an altered version of the library. That
>> is, the git community will get all changes back while other projects can
>> use the official version of the library without having to worry about
>> licensing issues. EvilCompany cannot make changes to the library and then
>> link non-GPL'd software to their changed version. They can do that if they
>> send their library changes upstream and then only use them once they're
>> considered "official" though.
>
> Do you mean if I write a patch to libgit2, send it upstream and make
> it public on my website but it is not accepted upstream, I cannot link
> my modified libgit2 version (i. e. libgit2 + my patch) to my non-GPL
> software?
I think that's the case, yes.
> It looks insane to me: I wrote the patch and made it public
> but you guys did not accept it!
>
Well, if you wrote a patch that uses a closed-source database library
to store git objects in, how would that benefit the community even if
you published the patch?
You could ofcourse fork the library, but then you'd have to take care
of namespace conflicts and such things. The fork would naturally have
to be licensed GPL + gcc-exception too, since it's a derivative work.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Pau Garcia i Quiles @ 2008-11-15 11:33 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <491EACFA.9040604@op5.se>
On Sat, Nov 15, 2008 at 12:05 PM, Andreas Ericsson <ae@op5.se> wrote:
>> Do you mean if I write a patch to libgit2, send it upstream and make
>> it public on my website but it is not accepted upstream, I cannot link
>> my modified libgit2 version (i. e. libgit2 + my patch) to my non-GPL
>> software?
>
> I think that's the case, yes.
>
>> It looks insane to me: I wrote the patch and made it public
>> but you guys did not accept it!
>>
>
> Well, if you wrote a patch that uses a closed-source database library
> to store git objects in, how would that benefit the community even if
> you published the patch?
The case I had in mind is not that but this: say I write a patch which
is totally open-source and uses only open-source software to add some
feature to libgit2 but I want to link that libgit2 + mypatch to a
closed source application (say, for instance, software for military
use, which I'm not allowed to open source). To state it clearly:
- My contribution is 100% open source
- My contribution is 100% towards libgit2
- In fact, I could add that very feature to my application instead of
libgit2 but as I'm open-source-friendly, I decide to contribute that
patch to libgit2.
For some reason, that patch:
- Is not accepted for some time (for instance, I'm thinking in that
tcl/tk limitation which is preventing Junio from merging a patch, it's
been in the "what's cooking" for some weeks now)
- Or is not accepted at all
According to what you said, I only have two options:
- Either I fork libgit2, or
- I keep my feature in my application and do not contribute my feature
to libgit2
It looks even more insane now!
What about rephrasing the libgcc exception to something like: "if you
have a patch, and sent us that patch, but we put the patch in stand-by
or declided the patch, you are still allowed to combine libgit2 with
your closed-source application". After all, the fault is not in the
closed-source part (I contributed the patch, it is 100% open-source
and only uses 100% open-source) but in the libgit2 part (patch is on
hold or not accepted at all).
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Andreas Ericsson @ 2008-11-15 11:52 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Git Mailing List
In-Reply-To: <3af572ac0811150333p28546975m9cf3ad73e62eb97@mail.gmail.com>
Pau Garcia i Quiles wrote:
> On Sat, Nov 15, 2008 at 12:05 PM, Andreas Ericsson <ae@op5.se> wrote:
>
>>> Do you mean if I write a patch to libgit2, send it upstream and make
>>> it public on my website but it is not accepted upstream, I cannot link
>>> my modified libgit2 version (i. e. libgit2 + my patch) to my non-GPL
>>> software?
>> I think that's the case, yes.
>>
>>> It looks insane to me: I wrote the patch and made it public
>>> but you guys did not accept it!
>>>
>> Well, if you wrote a patch that uses a closed-source database library
>> to store git objects in, how would that benefit the community even if
>> you published the patch?
>
> The case I had in mind is not that but this: say I write a patch which
> is totally open-source and uses only open-source software to add some
> feature to libgit2 but I want to link that libgit2 + mypatch to a
> closed source application (say, for instance, software for military
> use, which I'm not allowed to open source). To state it clearly:
> - My contribution is 100% open source
> - My contribution is 100% towards libgit2
> - In fact, I could add that very feature to my application instead of
> libgit2 but as I'm open-source-friendly, I decide to contribute that
> patch to libgit2.
>
> For some reason, that patch:
> - Is not accepted for some time (for instance, I'm thinking in that
> tcl/tk limitation which is preventing Junio from merging a patch, it's
> been in the "what's cooking" for some weeks now)
> - Or is not accepted at all
>
> According to what you said, I only have two options:
> - Either I fork libgit2, or
> - I keep my feature in my application and do not contribute my feature
> to libgit2
>
> It looks even more insane now!
>
No, it's still sane. You can keep the code in your application until
that patch is applied upstream. Besides, given the nature of shared
libraries you'd probably have to fall back to the version in your
app for quite some time anyways.
> What about rephrasing the libgcc exception to something like: "if you
> have a patch, and sent us that patch, but we put the patch in stand-by
> or declided the patch, you are still allowed to combine libgit2 with
> your closed-source application". After all, the fault is not in the
> closed-source part (I contributed the patch, it is 100% open-source
> and only uses 100% open-source) but in the libgit2 part (patch is on
> hold or not accepted at all).
>
Rephrasing an existing license is really, really stupid, as it means
companies that want to build stuff on top of it will have to do the
legal procedure all over again.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Junio C Hamano @ 2008-11-15 12:07 UTC (permalink / raw)
To: Piotr Findeisen; +Cc: Jonas Fonseca, git
In-Reply-To: <ddb82bf60811140502y60987761g55fc959a3e246afe@mail.gmail.com>
"Piotr Findeisen" <piotr.findeisen@gmail.com> writes:
> However, this seems a bit messy -- fighting against asciidoc instead
> of using it as it's designed to be used. IMHO, it's better to
> explicitly escape non-punctuation "--" with "\" and write punctuation
> "--" with spaces on both sides.
Thanks for digging. I agree with that.
^ permalink raw reply
* [PATCH] Makefile: introduce NO_PTHREADS
From: Junio C Hamano @ 2008-11-15 12:08 UTC (permalink / raw)
To: Git Mailing List; +Cc: Linus Torvalds
In-Reply-To: <alpine.LFD.2.00.0811141109580.3468@nehalem.linux-foundation.org>
This introduces make variable NO_PTHREADS for platforms that lack the
support for pthreads library or people who do not want to use it for
whatever reason. When defined, it makes the multi-threaded index
preloading into a no-op, and also disables threaded delta searching by
pack-objects.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I notice a handful platforms do not define THREADED_DELTA_SEARCH, and
on them Linus's preload-index.c is the first source file that includes
<pthreads.h>, which may result in breakages.
Makefile | 10 +++++++++-
config.mak.in | 1 +
configure.ac | 5 +++++
preload-index.c | 9 +++++++++
4 files changed, 24 insertions(+), 1 deletions(-)
diff --git c/Makefile w/Makefile
index acac0ae..ffc9531 100644
--- c/Makefile
+++ w/Makefile
@@ -90,6 +90,8 @@ all::
#
# Define NO_MMAP if you want to avoid mmap.
#
+# Define NO_PTHREADS if you do not have or do not want to use Pthreads.
+#
# Define NO_PREAD if you have a problem with pread() system call (e.g.
# cygwin.dll before v1.5.22).
#
@@ -1018,9 +1020,15 @@ ifdef INTERNAL_QSORT
COMPAT_OBJS += compat/qsort.o
endif
+ifdef NO_PTHREADS
+ THREADED_DELTA_SEARCH =
+ BASIC_CFLAGS += -DNO_PTHREADS
+else
+ EXTLIBS += $(PTHREAD_LIBS)
+endif
+
ifdef THREADED_DELTA_SEARCH
BASIC_CFLAGS += -DTHREADED_DELTA_SEARCH
- EXTLIBS += $(PTHREAD_LIBS)
LIB_OBJS += thread-utils.o
endif
ifdef DIR_HAS_BSD_GROUP_SEMANTICS
diff --git c/config.mak.in w/config.mak.in
index ea7705c..14dfb21 100644
--- c/config.mak.in
+++ w/config.mak.in
@@ -51,4 +51,5 @@ OLD_ICONV=@OLD_ICONV@
NO_DEFLATE_BOUND=@NO_DEFLATE_BOUND@
FREAD_READS_DIRECTORIES=@FREAD_READS_DIRECTORIES@
SNPRINTF_RETURNS_BOGUS=@SNPRINTF_RETURNS_BOGUS@
+NO_PTHREADS=@NO_PTHREADS@
PTHREAD_LIBS=@PTHREAD_LIBS@
diff --git c/configure.ac w/configure.ac
index 4256742..8821b50 100644
--- c/configure.ac
+++ w/configure.ac
@@ -490,6 +490,8 @@ AC_SUBST(NO_MKDTEMP)
# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
# Enable it on Windows. By default, symrefs are still used.
#
+# Define NO_PTHREADS if we do not have pthreads
+#
# Define PTHREAD_LIBS to the linker flag used for Pthread support.
AC_LANG_CONFTEST([AC_LANG_PROGRAM(
[[#include <pthread.h>]],
@@ -502,9 +504,12 @@ else
${CC} -lpthread conftest.c -o conftest.o > /dev/null 2>&1
if test $? -eq 0;then
PTHREAD_LIBS="-lpthread"
+ else
+ NO_PTHREADS=UnfortunatelyYes
fi
fi
AC_SUBST(PTHREAD_LIBS)
+AC_SUBST(NO_PTHREADS)
## Site configuration (override autodetection)
## --with-PACKAGE[=ARG] and --without-PACKAGE
diff --git c/preload-index.c w/preload-index.c
index 6253578..3ae83dc 100644
--- c/preload-index.c
+++ w/preload-index.c
@@ -2,6 +2,14 @@
* Copyright (C) 2008 Linus Torvalds
*/
#include "cache.h"
+
+#ifdef NO_PTHREADS
+static void preload_index(struct index_state *index, const char **pathspec)
+{
+ ; /* nothing */
+}
+#else
+
#include <pthread.h>
/*
@@ -81,6 +89,7 @@ static void preload_index(struct index_state *index, const char **pathspec)
die("unable to join threaded lstat");
}
}
+#endif
int read_index_preload(struct index_state *index, const char **pathspec)
{
^ permalink raw reply related
* Re: [PATCH v2 05/11] gitweb: git_split_heads_body function.
From: Junio C Hamano @ 2008-11-15 12:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Giuseppe Bilotta, git, Petr Baudis
In-Reply-To: <200811150059.14515.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Second, this patch wouldn't do what you want from it if there are
> remotes with '/' in name. I for example use "gsoc2008/gitweb-caching"
> for Lea Wiemann repository with her GSoC 2008 work on adding caching
> to gitweb.
I think your point is if you also use gsoc2008/gitstats from another
remote repository, these two sets of remote tracking branches will be
shown grouped together. But is it a bad thing? After all, you chose to
use hierarchical names for them, _and_ you chose to use the same toplevel
hierarchy name for them. Doesn't that mean you _wanted_ to have them both
appear in the same GSoC 2008 group?
^ permalink raw reply
* Re: [PATCH v2 07/11] gitweb: add 'remotes' action
From: Jakub Narebski @ 2008-11-15 12:16 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226616555-24503-8-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 13 Nov 2008, Giuseppe "Oblomov" Bilotta wrote:
> This action is similar to the 'heads' action, but it displays
> remote heads, grouped by remote repository.
I think I would prefer would go together with the change that split
the 'heads' ('branches') part of summary view into 'heads' and
'remotes', so that both section title header, and '...' continuation
if present, lead to proper view.
So either
[heads] # or [branches]
master
to-submit
origin/master
origin/next
...
where both '[heads]' and (possibly) '...' link to 'heads' view showing
_both_ local branches (refs/heads/*) and remote-tracking branches
(refs/remotes/*), like in first patch of series (perhaps with some
subdivision).
Or
[heads]
master
to-submit
...
[remotes]
origin/master
origin/next
...
where '[heads]' link to 'heads' view which shows only local branches
(refs/heads/*), and '[remotes]' link to 'remotes' view which shows only
remote-tracking branches.
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 16 +++++++++++++++-
> 1 files changed, 15 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 03e0b21..09728cb 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -507,6 +507,7 @@ our %actions = (
> "commit" => \&git_commit,
> "forks" => \&git_forks,
> "heads" => \&git_heads,
> + "remotes" => \&git_remotes,
> "history" => \&git_history,
> "log" => \&git_log,
> "rss" => \&git_rss,
> @@ -4755,13 +4756,26 @@ sub git_heads {
> git_print_page_nav('','', $head,undef,$head);
> git_print_header_div('summary', $project);
>
> - my @headslist = git_get_heads_list();
> + my @headslist = git_get_heads_list(undef, 'heads');
Hmmm... I wonder if it would be possible to use some DWIM-mery on
the side of git_get_heads_list (for example checking if first argument
is a number, and assuming that nobody would be insane enough to use
refs/15 for namespace), and just use git_get_heads_list('heads') here.
But I guess that this form is good enough...
> if (@headslist) {
> git_heads_body(\@headslist, $head);
> }
> git_footer_html();
> }
>
> +sub git_remotes {
> + my $head = git_get_head_hash($project);
> + git_header_html();
> + git_print_page_nav('','', $head,undef,$head);
> + git_print_header_div('summary', $project . ' remotes');
> +
> + my @headslist = git_get_heads_list(undef, 'remotes');
> + if (@headslist) {
> + git_split_heads_body(\@headslist, $head);
> + }
> + git_footer_html();
> +}
Nice. I see the difference from git_heads is using $project . ' remotes'
in place of $project in git_print_header_div() (why?), and using
'remotes' in call to git_get_heads_list().
> +
> sub git_blob_plain {
> my $type = shift;
> my $expires;
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v2 05/11] gitweb: git_split_heads_body function.
From: Giuseppe Bilotta @ 2008-11-15 12:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Petr Baudis
In-Reply-To: <7vprkx5gqb.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 15, 2008 at 1:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Second, this patch wouldn't do what you want from it if there are
>> remotes with '/' in name. I for example use "gsoc2008/gitweb-caching"
>> for Lea Wiemann repository with her GSoC 2008 work on adding caching
>> to gitweb.
>
> I think your point is if you also use gsoc2008/gitstats from another
> remote repository, these two sets of remote tracking branches will be
> shown grouped together. But is it a bad thing? After all, you chose to
> use hierarchical names for them, _and_ you chose to use the same toplevel
> hierarchy name for them. Doesn't that mean you _wanted_ to have them both
> appear in the same GSoC 2008 group?
The problem is that we have gsoc2008/gitweb-caching/branch1
gsoc2008/gitweb-caching/branch2 gsoc2008/gitstats/branch3
gsoc2008/gitstats/branch3, and my current code would show
gitweb-caching/branch1, gitweb-caching/branch2 etc under gsoc2008.
Having branch1 and branch2 under gsoc2008/gitweb-caching, and branch3
and branch4 under gsoc2008/gitstats would be more logical,
remote-wise, but it would of course lose the coupling between all the
gsoc2008 remotes.
If deep nesting is not a problem, I can code something to have
gitweb-caching and gistats under gsoc2008, and the respective branches
within.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH v2 07/11] gitweb: add 'remotes' action
From: Giuseppe Bilotta @ 2008-11-15 12:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811151316.32024.jnareb@gmail.com>
On Sat, Nov 15, 2008 at 1:16 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 13 Nov 2008, Giuseppe "Oblomov" Bilotta wrote:
>
>> This action is similar to the 'heads' action, but it displays
>> remote heads, grouped by remote repository.
>
> I think I would prefer would go together with the change that split
> the 'heads' ('branches') part of summary view into 'heads' and
> 'remotes', so that both section title header, and '...' continuation
> if present, lead to proper view.
>
> So either
>
> [heads] # or [branches]
> master
> to-submit
> origin/master
> origin/next
> ...
>
> where both '[heads]' and (possibly) '...' link to 'heads' view showing
> _both_ local branches (refs/heads/*) and remote-tracking branches
> (refs/remotes/*), like in first patch of series (perhaps with some
> subdivision).
>
> Or
>
> [heads]
> master
> to-submit
> ...
> [remotes]
> origin/master
> origin/next
> ...
>
> where '[heads]' link to 'heads' view which shows only local branches
> (refs/heads/*), and '[remotes]' link to 'remotes' view which shows only
> remote-tracking branches.
That's funny, I just squashed this patch with the summary list split
view patch 8-) I'm going for the second option, to have [heads] link
to heads which only lists local heads, and [remotes] linking to
remotes that lists the remotes. We may or may not want to rather have
[branches] instead of [heads], and keep the heads action to mean *all*
heads, local and remote, but I'm not sure about it.
>> - my @headslist = git_get_heads_list();
>> + my @headslist = git_get_heads_list(undef, 'heads');
>
> Hmmm... I wonder if it would be possible to use some DWIM-mery on
> the side of git_get_heads_list (for example checking if first argument
> is a number, and assuming that nobody would be insane enough to use
> refs/15 for namespace), and just use git_get_heads_list('heads') here.
>
> But I guess that this form is good enough...
I've been wondering about this myself. Another possibility would be to
use named options instead of positional parameters, but then again it
all looks like overkill, at least for the time being.
>> if (@headslist) {
>> git_heads_body(\@headslist, $head);
>> }
>> git_footer_html();
>> }
>>
>> +sub git_remotes {
>> + my $head = git_get_head_hash($project);
>> + git_header_html();
>> + git_print_page_nav('','', $head,undef,$head);
>> + git_print_header_div('summary', $project . ' remotes');
>> +
>> + my @headslist = git_get_heads_list(undef, 'remotes');
>> + if (@headslist) {
>> + git_split_heads_body(\@headslist, $head);
>> + }
>> + git_footer_html();
>> +}
>
> Nice. I see the difference from git_heads is using $project . ' remotes'
> in place of $project in git_print_header_div() (why?),
FWIW, I decided to scratch that additional ' remotes' string when
squashing this patch.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Miklos Vajna @ 2008-11-15 12:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, Andreas Ericsson, Git Mailing List
In-Reply-To: <20081114234658.GA2932@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
On Fri, Nov 14, 2008 at 03:46:58PM -0800, "Shawn O. Pearce" <spearce@spearce.org> wrote:
> Note that the only valid version of the GPL as far as this project
> is concerned is _this_ particular version of the license (ie v2, not
> v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>
> In addition to the permissions in the GNU General Public License,
> the authors give 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 combined executable.)
IANAL - what is the difference between this and the LGPL?
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Junio C Hamano @ 2008-11-15 13:00 UTC (permalink / raw)
To: Miklos Vajna
Cc: Shawn O. Pearce, Linus Torvalds, Andreas Ericsson,
Git Mailing List
In-Reply-To: <20081115123916.GN24201@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Fri, Nov 14, 2008 at 03:46:58PM -0800, "Shawn O. Pearce" <spearce@spearce.org> wrote:
>> Note that the only valid version of the GPL as far as this project
>> is concerned is _this_ particular version of the license (ie v2, not
>> v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>>
>> In addition to the permissions in the GNU General Public License,
>> the authors give 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 combined executable.)
>
> IANAL - what is the difference between this and the LGPL?
Under LGPL, you must provide linkable object files to your (possibly
closed source) program, so that people who made changes to (or obtained an
updated version of) a LGPL'ed library can re-link your program and use the
updated library. The above does not ask you to do so.
The way I read LGPL is that "We deeply care about our LGPL library and any
improvements to it. Although we do not care at all about how your crappy
closed source program is written, we want to make sure that the users can
keep using your program after improvements are made to our library.". I
do not think it makes a practical difference when your program uses the
LGPL library as a shard library from that point of view.
^ permalink raw reply
* Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-15 14:19 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Junio C Hamano, Johannes Schindelin, git, Linus Torvalds,
Ingo Molnar, Andrew Morton, Jeff Garzik, David Miller
In-Reply-To: <491D4D02.6080004@gnu.org>
Le vendredi 14 novembre 2008, Paolo Bonzini a écrit :
> >> users could also set up a few
> >> special bisect/set-debug-to-1, bisect/remove-cflags-o2 and so on
> >> patches that you could use for purposes other than ensuring known bugs
> >> are fixed.
> >
> > In this case it is similar to Junio's proposal. But I think that for
> > changes like set-debug-to-1 and remove-cflags-o2, using the right make
> > command should be enough.
>
> Yeah, I couldn't think of a better usecase, but you got the idea.
>
> >> Finally, you could have a [bisect] configuration section with entries
> >> like "cherry-pick = BROKEN-SHA1 FIX-SHA1" and "git bisect" would apply
> >> FIX-SHA1 automatically if the bisect tip were in
> >> BROKEN-SHA1..FIX-SHA1.
> >
> > Yes, but how do you share this between members of a team?
>
> That's a common problem with stuff that goes in .gitconfig. It does not
> belong in the repository, though...
Why?
Git encourages people to develop by creating many branches of commits,
working on them and sharing them, and that seems to work very well. So I
really don't understand why _the hell_ people using bisect could not also
benefit of from creating patched up branches, sharing them, bisecting on
them.
Especially as, in my patch series, it does not in _any way_ change anything
for people who just don't want to use patched up branches. They just need
to not download any "bisect-replace-*" branch, or we can even implement a
config option "bisect.useReplaceBranches" that default to "no" if that is
such a big threat to them.
I agree that the name of the branches "bisect-replace-*" may not be the best
or that using special refs in "refs/replace/" might be better (except that
these refs should have in my opinion a special namespace to be easily
distinguished from others), but I don't think _at all_ that this should be
enough to discard the whole idea (and implementation but that's another
story).
Or is there a god command I don't know about that says:
Thou shall not use patched up branches to bisect!
Thou shall bisect painfully!
Regards,
Christian.
^ permalink raw reply
* [PATCH] gitweb: fixes to gitweb feature check code
From: Giuseppe Bilotta @ 2008-11-15 14:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
The gitweb_check_feature routine was being used for two different
purposes: retrieving the actual feature value (such as the list of
snapshot formats or the list of additional actions), and to check if a
feature was enabled.
For the latter use, since all features return an array, it led to either
clumsy code or subtle bugs, with disabled features appearing enabled
because (0) evaluates to 1.
We fix these bugs, and simplify the code, by separating feature (list)
value retrieval (gitweb_get_feature) from boolean feature check (i.e.
retrieving the first/only item in the feature value list). Usage of
gitweb_check_feature across gitweb is replaced by the appropriate call
wherever needed.
---
gitweb/gitweb.perl | 52 +++++++++++++++++++++++++++++++++++-----------------
1 files changed, 35 insertions(+), 17 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 933e137..b0d00ea 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -190,7 +190,9 @@ our %feature = (
# if there is no 'sub' key (no feature-sub), then feature cannot be
# overriden
#
- # use gitweb_check_feature(<feature>) to check if <feature> is enabled
+ # use gitweb_get_feature(<feature>) to retrieve the <feature> value
+ # (an array) or gitweb_check_feature(<feature>) to check if <feature>
+ # is enabled
# Enable the 'blame' blob view, showing the last commit that modified
# each line in the file. This can be very CPU-intensive.
@@ -329,7 +331,8 @@ our %feature = (
'default' => [0]},
);
-sub gitweb_check_feature {
+# retrieve the value of a given feature, as an array
+sub gitweb_get_feature {
my ($name) = @_;
return unless exists $feature{$name};
my ($sub, $override, @defaults) = (
@@ -344,6 +347,21 @@ sub gitweb_check_feature {
return $sub->(@defaults);
}
+# check if a given feature is enabled or not, returning the first (and only)
+# value of the feature. Comfort code, allowing the use of
+# my $bool_feat = gitweb_check_feature('bool_feat');
+# or
+# gitweb_check_feature('bool_feat') or somecode;
+# instead of
+# my ($bool_feat) = gitweb_git_feature('bool_feat');
+# or
+# (gitweb_check_feature('bool_feat'))[0] or somecode;
+# respectively
+sub gitweb_check_feature {
+ return (gitweb_get_feature(@_))[0];
+}
+
+
sub feature_blame {
my ($val) = git_get_project_config('blame', '--bool');
@@ -767,7 +785,7 @@ our $git_dir;
$git_dir = "$projectroot/$project" if $project;
# list of supported snapshot formats
-our @snapshot_fmts = gitweb_check_feature('snapshot');
+our @snapshot_fmts = gitweb_get_feature('snapshot');
@snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
# dispatch
@@ -810,7 +828,7 @@ sub href (%) {
}
}
- my ($use_pathinfo) = gitweb_check_feature('pathinfo');
+ my $use_pathinfo = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
@@ -2101,7 +2119,7 @@ sub git_get_projects_list {
$filter ||= '';
$filter =~ s/\.git$//;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
if (-d $projects_list) {
# search in directory
@@ -2947,7 +2965,7 @@ EOF
}
print "</div>\n";
- my ($have_search) = gitweb_check_feature('search');
+ my $have_search = gitweb_check_feature('search');
if (defined $project && $have_search) {
if (!defined $searchtext) {
$searchtext = "";
@@ -2961,7 +2979,7 @@ EOF
$search_hash = "HEAD";
}
my $action = $my_uri;
- my ($use_pathinfo) = gitweb_check_feature('pathinfo');
+ my $use_pathinfo = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
$action .= "/".esc_url($project);
}
@@ -3084,7 +3102,7 @@ sub git_print_page_nav {
$arg{'tree'}{'hash'} = $treehead if defined $treehead;
$arg{'tree'}{'hash_base'} = $treebase if defined $treebase;
- my @actions = gitweb_check_feature('actions');
+ my @actions = gitweb_get_feature('actions');
my %repl = (
'%' => '%',
'n' => $project, # project name
@@ -3454,7 +3472,7 @@ sub is_patch_split {
sub git_difftree_body {
my ($difftree, $hash, @parents) = @_;
my ($parent) = $parents[0];
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
print "<div class=\"list_head\">\n";
if ($#{$difftree} > 10) {
print(($#{$difftree} + 1) . " files changed:\n");
@@ -3968,7 +3986,7 @@ sub git_project_list_body {
# actually uses global variable $project
my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
my @projects = fill_project_list_info($projlist, $check_forks);
$order ||= $default_projects_order;
@@ -4428,7 +4446,7 @@ sub git_summary {
my @taglist = git_get_tags_list(16);
my @headlist = git_get_heads_list(16);
my @forklist;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
if ($check_forks) {
@forklist = git_get_projects_list($project);
@@ -4457,7 +4475,7 @@ sub git_summary {
}
# Tag cloud
- my $show_ctags = (gitweb_check_feature('ctags'))[0];
+ my $show_ctags = gitweb_check_feature('ctags');
if ($show_ctags) {
my $ctags = git_get_project_ctags($project);
my $cloud = git_populate_project_tagcloud($ctags);
@@ -4747,7 +4765,7 @@ sub git_blob {
$expires = "+1d";
}
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
or die_error(500, "Couldn't cat $file_name, $hash");
my $mimetype = blob_mimetype($fd, $file_name);
@@ -4840,7 +4858,7 @@ sub git_tree {
my $ref = format_ref_marker($refs, $hash_base);
git_header_html();
my $basedir = '';
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
my @views_nav = ();
if (defined $file_name) {
@@ -5838,7 +5856,7 @@ insensitive).</p>
<dt><b>commit</b></dt>
<dd>The commit messages and authorship information will be scanned for the given pattern.</dd>
EOT
- my ($have_grep) = gitweb_check_feature('grep');
+ my $have_grep = gitweb_check_feature('grep');
if ($have_grep) {
print <<EOT;
<dt><b>grep</b></dt>
@@ -5855,7 +5873,7 @@ EOT
<dt><b>committer</b></dt>
<dd>Name and e-mail of the committer and date of commit will be scanned for the given pattern.</dd>
EOT
- my ($have_pickaxe) = gitweb_check_feature('pickaxe');
+ my $have_pickaxe = gitweb_check_feature('pickaxe');
if ($have_pickaxe) {
print <<EOT;
<dt><b>pickaxe</b></dt>
@@ -5907,7 +5925,7 @@ sub git_shortlog {
sub git_feed {
my $format = shift || 'atom';
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
# Atom: http://www.atomenabled.org/developers/syndication/
# RSS: http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
--
1.5.6.5
^ permalink raw reply related
* [RFC PATCH 0/2] fixing git pull from symlinked directory
From: Marcel M. Cary @ 2008-11-15 15:11 UTC (permalink / raw)
To: git; +Cc: Marcel M. Cary
In a past message I described a problem when pulling in a
directory that I arrived at by "cd"-ing to a symlink.
http://article.gmane.org/gmane.comp.version-control.git/98223
I've created a unit test to illustrate the problem and
compare it to "git pull" without the symlink and "git push"
with the symlink, which both work. That's the first patch
in this series.
I think the root cause here is that a shell's "cd" and C's
chdir() behave slightly different with symlinks. See the unit
test comments for more details.
I can make the unit test pass if I make bash's "cd" behave
like chdir() by adding "-P", as in the second patch of this
series, but I think that has portability issues. Any tips
for addressing that? Maybe instead call realpath() on the
result of "git rev-parse --show-cdup" in C before printing
it? That's a substantial change as it would print
/full/path/to/work-dir/ instead of just "../".
Marcel M. Cary (2):
Add failing test for "git pull" in symlinked directory
Support shell scripts that run from symlinks into a git working dir
git-sh-setup.sh | 2 +-
t/t5521-pull-symlink.sh | 67 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 68 insertions(+), 1 deletions(-)
create mode 100644 t/t5521-pull-symlink.sh
^ permalink raw reply
* [RFC PATCH 1/2] Add failing test for "git pull" in symlinked directory
From: Marcel M. Cary @ 2008-11-15 15:11 UTC (permalink / raw)
To: git; +Cc: Marcel M. Cary
In-Reply-To: <cover.1226759762.git.marcel@oak.homeunix.org>
* Illustrate the scenario of interest and show how it breaks
* Show a contrasting working "git pull" without the symlink
* Show a contrasting working "git push" with the symlink
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
---
t/t5521-pull-symlink.sh | 67 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/t/t5521-pull-symlink.sh b/t/t5521-pull-symlink.sh
new file mode 100644
index 0000000..683784d
--- /dev/null
+++ b/t/t5521-pull-symlink.sh
@@ -0,0 +1,67 @@
+#!/bin/sh
+
+test_description='pulling from symlinked subdir'
+
+. ./test-lib.sh
+
+D=`pwd`
+
+# The scenario we are building:
+#
+# trash\ directory/
+# clone-repo/
+# subdir/
+# bar
+# subdir-link -> clone-repo/subdir/
+#
+# The working directory is subdir-link.
+#
+test_expect_success setup '
+
+ mkdir subdir &&
+ touch subdir/bar &&
+ git add subdir/bar &&
+ git commit -m empty &&
+ git clone . clone-repo &&
+ # demonstrate that things work without the symlink
+ test_debug "cd clone-repo/subdir/ && git pull; cd ../.." &&
+ ln -s clone-repo/subdir/ subdir-link &&
+ cd subdir-link/ &&
+ test_debug "set +x"
+'
+
+# From subdir-link, pulling should work as it does from
+# clone-repo/subdir/.
+#
+# Instead, the error pull gave was:
+#
+# fatal: 'origin': unable to chdir or not a git archive
+# fatal: The remote end hung up unexpectedly
+#
+# bacause git would find the .git/config for the trash\ directory
+# repo, not for the clone-repo repo. The trash\ directory repo
+# had no entry for origin. Git found the wrong .git because
+# git rev-parse --show-cdup printed a path relative to
+# clone-repo/subdir/, not subdir-link/. Git rev-parse --show-cdup
+# used the correct .git, but when the git pull shell script did
+# "cd `git rev-parse --show-cdup`", it ended up in the wrong
+# directory. Shell "cd" works a little different from chdir() in C.
+# Bash's "cd -P" works like chdir() in C.
+#
+test_expect_failure 'pulling from symlinked subdir' '
+
+ git pull
+'
+
+# Prove that the remote end really is a repo, and other commands
+# work fine in this context.
+#
+test_debug "
+ test_expect_success 'pushing from symlinked subdir' '
+
+ git push
+ '
+"
+cd "$D"
+
+test_done
--
1.6.0.3
^ permalink raw reply related
* [RFC PATCH 2/2] Support shell scripts that run from symlinks into a git working dir
From: Marcel M. Cary @ 2008-11-15 15:11 UTC (permalink / raw)
To: git; +Cc: Marcel M. Cary
In-Reply-To: <cover.1226759762.git.marcel@oak.homeunix.org>
Use "cd -P" instead of just "cd" when switching to the top level
of the git working directory. When working from a symlink
into GIT_WORK_TREE, the shell function cd_to_toplevel will now
change to GIT_WORK_TREE rather than the parent of the symlink,
which may not even be the root of a git working directory.
Unfortunately this solution looks non-portable.
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
---
git-sh-setup.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index dbdf209..4006150 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -85,7 +85,7 @@ cd_to_toplevel () {
cdup=$(git rev-parse --show-cdup)
if test ! -z "$cdup"
then
- cd "$cdup" || {
+ cd -P "$cdup" || {
echo >&2 "Cannot chdir to $cdup, the toplevel of the working tree"
exit 1
}
--
1.6.0.3
^ permalink raw reply related
* Re: [PATCH 2/3] Add -y/--no-prompt option to mergetool
From: Theodore Tso @ 2008-11-15 15:50 UTC (permalink / raw)
To: Charles Bailey
Cc: Junio C Hamano, git, Jeff King, Andreas Ericsson, William Pursell
In-Reply-To: <1226580075-29289-3-git-send-email-charles@hashpling.org>
On Thu, Nov 13, 2008 at 12:41:14PM +0000, Charles Bailey wrote:
> This option lets git mergetool invoke the conflict resolution program
> without waiting for a user prompt each time.
>
> Also added a mergetool.prompt (default true) configuration variable
> controlling the same behaviour
My apologies for not commeting earlier on your patches; I've been a
bit overloaded as of late --- way too much conference travel! :-(
I can see why this should perhaps be the default for gui-based merge
program. The one place where it should perhaps not be the default is if
the tool could be text based (i.e., if you are using text-based emacs
to do the emerge). So perhaps what we should do is
1) Make the question of whether or not a particular back-end merge
program should require the user to hit return first to be configured
on a per-gui tool basis.
2) For all of the gui tools default the answer to be to _not_ prompt
first.
3) For the emacs-based merge, make the default be based on whether or
not $DISPLAY is set. (But allow an overide based on
mergetool.emerge.prompt.)
I think this much more accurately would model what users want, and if
we get the default right for most users, that's definitely a win.
Regards,
- Ted
^ permalink raw reply
* Re: [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Theodore Tso @ 2008-11-15 15:56 UTC (permalink / raw)
To: Charles Bailey
Cc: Junio C Hamano, git, Jeff King, Andreas Ericsson, William Pursell
In-Reply-To: <1226580075-29289-4-git-send-email-charles@hashpling.org>
On Thu, Nov 13, 2008 at 12:41:15PM +0000, Charles Bailey wrote:
> This option stops git mergetool from aborting at the first failed merge.
> This allows some additional use patterns. Merge conflicts can now be
> previewed one at time and merges can also be skipped so that they can be
> performed in a later pass.
>
> There is also a mergetool.keepGoing configuration variable covering the
> same behaviour.
Instead of making this be a command-line and configuration option,
maybe it would be better to prompt the user after an aborted merge,
and give the user the opportunity to continue or abort? i.e., instead
of just saying "merge of foo.c failed" and then exiting, to ask the
user instad something like, "Merge of foo.c failed; continue
attempting to merge the rest of the files? <y>"
I suspect this might be more friendly than Yet Another command-line
option and configuration parameter. What do you think?
- Ted
^ permalink raw reply
* Re: [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Theodore Tso @ 2008-11-15 16:12 UTC (permalink / raw)
To: Charles Bailey
Cc: Jeff King, Junio C Hamano, git, Andreas Ericsson, William Pursell
In-Reply-To: <491D7C38.7070906@hashpling.org>
On Fri, Nov 14, 2008 at 01:25:12PM +0000, Charles Bailey wrote:
> Previously, if you aborted a merge, you were left with the
> base/local/remote temporaries for the merge that you aborted.
>
> To be honest, I found this a little irritating. The base, local and
> remote temporaries are inputs so are accessible from slots 1,2 and 3 of
> the index, and any intermediate output will be in the target file. You
> can git clean, but if you have other temporaries you need to keep, you
> end up having to manually clean them up in any case.
I agree. On occasion it's useful, but more often than not, keeping
the temporaries is more annoying than anything else. At the time when
I wrote mergetool, it was a pain for me to either do "git ls-files
--stage" and then cut and paste the SHA hash, or to type commands like
"git cat-file blob :1:long/pathname/from/the/top.c" to look one
various staged versions of the file.
I'd suggest that this is probably worth turning into an option
(-k|--keep-files), and default the answer to deleting the temporaries
before mergetool exits.
- Ted
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Linus Torvalds @ 2008-11-15 16:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <20081114234658.GA2932@spearce.org>
On Fri, 14 Nov 2008, Shawn O. Pearce wrote:
>
> The language we are using in libgit2 is taken from libgcc, and is
> as follows:
Ok, I'm fine with this.
Linus
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Martin Koegler @ 2008-11-15 17:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <491E021E.5020104@op5.se>
Andreas Ericsson wrote:
> Shawn posted the exact text. The spirit of that license is that anyone can
> use an unmodified version of the library for whatever they want, but it's
> illegal to link non-GPL software to an altered version of the library. That
> is, the git community will get all changes back while other projects can
> use the official version of the library without having to worry about
> licensing issues. EvilCompany cannot make changes to the library and then
> link non-GPL'd software to their changed version. They can do that if they
> send their library changes upstream and then only use them once they're
> considered "official" though.
I would not interpret the license this way. Lets look at the text:
| In addition to the permissions in the GNU General Public License,
| the authors give 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 combined executable.)
It's an additional permission, which allows linking into binaries and
distributing them.
Modification is still covered by the GPL text, 2b:
| You must cause any work that you distribute or publish, that in
| whole or in part contains or is derived from the Program or any
| part thereof, to be licensed as a whole at no charge to all third
| parties under the terms of this License.
So a patched version must be available unter the "this" license. In my
option, this must be GPLv2+addition permission. GPLv3 explicitly talks
about additional terms, so its clear, that they propagate. GPLv2
doesn't do this, but additional terms, like OpenSSL linkage exceptions
are usually propagated.
So EvilCompany can create their own, modified GPL+GCC exception
libgit2 version behind their doors.
Then they link it into their non-GPL software and can distribute the
resulting binary without any GPL restriction. As the exception states,
that the binary can be distributed without any restrictions coming
from the GPL+GCC exception code, this COULD mean, that clause 3 of the
GPL does not apply too (ship binary without source code).
I'm only a programmer, so you should ask people with better
understanding of legal things.
Your interpretation of the GCC exception would render it useless for
the Debian probject [and probably other projects too], which means,
that they can use/distribute libgit2 only the GPL. If you don't want
that, you should consider posting to Debian Legal
(http://lists.debian.org/debian-legal/) for advice.
mfg Martin Kögler
PS:
Have you looked at the Classpath exception:
| Linking this library statically or dynamically with other modules is
| making a combined work based on this library. Thus, the terms and
| conditions of the GNU General Public License cover the whole
| combination.
|
| As a special exception, the copyright holders of this library give you
| permission to link this library with independent modules to produce an
| executable, regardless of the license terms of these independent
| modules, and to copy and distribute the resulting executable under
| terms of your choice, provided that you also meet, for each linked
| independent module, the terms and conditions of the license of that
| module. An independent module is a module which is not derived from
| or based on this library. If you modify this library, you may extend
| this exception to your version of the library, but you are not
| obligated to do so. If you do not wish to do so, delete this
| exception statement from your version.
^ permalink raw reply
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Linus Torvalds @ 2008-11-15 17:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vtza95h01.fsf@gitster.siamese.dyndns.org>
On Sat, 15 Nov 2008, Junio C Hamano wrote:
>
> This introduces make variable NO_PTHREADS for platforms that lack the
> support for pthreads library or people who do not want to use it for
> whatever reason. When defined, it makes the multi-threaded index
> preloading into a no-op, and also disables threaded delta searching by
> pack-objects.
Ack. Makes sense.
Linus
^ permalink raw reply
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-15 17:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3aht8z17.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 15, 2008 at 4:10 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>>> The approach with enum { Q, N, V } cannot express this, unfortunately.
>>>
>>> So let's do something like the attached patch, instead.
>>
>> That's ok. We should not break anything.
>>
>> Do you want me to resubmit a new patch with the changes?
>
> As long as you are happy with the suggested change, there is no need to.
> You'd need to sign-off the patch, though...
>
I forgot to add -s to my commit call this time around.
I will apply your changes and repost it with the signoff.
^ permalink raw reply
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-15 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i7594cx.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 15, 2008 at 2:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> @@ -637,9 +638,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
>> remote = remote_get(argv[0]);
>>
>> transport = transport_get(remote, remote->url[0]);
>> - if (verbose >= 2)
>> + if (verbosity == VERBOSE)
>> transport->verbose = 1;
>> - if (quiet)
>> + if (verbosity == QUIET)
>> transport->verbose = -1;
>> if (upload_pack)
>> set_option(TRANS_OPT_UPLOADPACK, upload_pack);
>
> In the original code, the variable verbose can be ">= 2" when "-v -v" is
> given, so transport->verbose is not turned on with a single "-v" alone
> (this correctly mimics the original behaviour in the scripted version).
>
Doesn't this also mean that we need to be able to concatenate
multiple -v options in git-pull.sh similar to what one of the first
versions of my patch did?
<snip>
^ 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