* 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
* [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
* [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 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
* [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
* 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
* 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: 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: [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: [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: 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: 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
* [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: 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
* 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: 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: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 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 10:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811141512480.3468@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>
> On Fri, 14 Nov 2008, Andreas Ericsson wrote:
>> The license decided for libgit2 is "GPL with gcc exception".
>
> What's the exact language?
>
> I'm likely ok with GPLv2 + libgcc-like exception, but I'd like to see the
> exact one. I haven't followed the discussions much..
>
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.
As the original author, you sort of have veto here since everything core-ish
is derived from what you wrote. Iow, if you say nay, libgit2 with a non-GPL
license will only fly if index, tree, commit, ref, etc... manipulation is
rewritten from scratch. That will be hard, given that it can fairly easily
be claimed that the people most likely to do it are so heavily influenced by
the current code that it's impossible for them not to make 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: [PATCH v2 04/11] gitweb: optional custom name for refs in git_heads_body
From: Giuseppe Bilotta @ 2008-11-15 10:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811150032.14558.jnareb@gmail.com>
On Sat, Nov 15, 2008 at 12:32 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 13 Nov 2008, Giuseppe Bilotta wrote:
>
>> We make a clear separation between the hash reference and the displayed
>> name for refs displayed by git_heads_body. This can be used e.g. to
>> group them and display only the distinct part of the name.
>
> It is not clear for me from this commit message what this patch
> is meant to do. Already git_heads_body (and also git_tags_body)
> uses $ref{'name'} for display, and $ref{'fullname'} for linking
> (to avoid possibility of tag/branch name conflict).
>> + my $hname = $ref{'hname'} || $ref{'fullname'} || $ref{'name'};
>
> I don't remember setting $ref{'hname'} anywhere; if there is a patch
> that sets this, it should really be squashed together with this commit.
> Otherwise the commit is not standalone, as it should be.
The patch that sets hname is the next patch (the one that introduces
git_split_heads_body. It's quite obvious that this whole 'split head
lists' part needs some rethinking.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH v2 05/11] gitweb: git_split_heads_body function.
From: Giuseppe Bilotta @ 2008-11-15 10:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811150059.14515.jnareb@gmail.com>
On Sat, Nov 15, 2008 at 12:59 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 13 Nov 2008, Giuseppe Bilotta wrote:
>
>> The purpose of this function is to split a headlist into groups
>> determined by the leading part of the refname, and call git_heads_body()
>> on each group.
>
> What is the reason of this patch? Is it to split remote-tracking
> branches ('remotes' references) into remotes, and group them by
> the remote repository name?
>
> If it is true, then first: you should have wrote the _reason_ behind
> this patch and not only what it does in this commit message. And use
> better summary (commit title / subject of this patch).
>
> 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. Because there are many ways to specify remotes due to
> backwards compatibility (and simplicity, as some for example prefer
> old 'branches/' way to specify remotes), namely config, files under
> '.git/remotes', and (from Cogito) files in '.git/branches', you would
> have to either reimplement/reuse parts of git-remote (there is old Perl
> implementation in contrib/examples), or use "git remote" or
> "git remote -v" command output[1].
The initially intended purpose for this patch was to group remote
heads by remotes, but an interesting side-effect of doing it this way
was that it allowed to group _local_ heads too, by using the
stuff/morestuff syntax. For example, I could group gitweb/pathinfo and
gitweb/allheads together (although I disabled this grouping for local
heads in the patchset).
However, as you remark, the current patch fails to achieve even its
intended purpose, so it looks like going the 'git remote' way would be
the right way to find at least the grouping keys: this has the benefit
of allowing us to retrieve the remote URL as well by using 'git remote
-v', although it has the underside of require one additional git call.
It would also probably be a good idea to separate the actual head
grouping from the display of the grouped head lists. I wonder if Perl
has a 'tree' data structure that could be used to store the grouped
head lists ...
Ah yes, the code in this patch I was never actually really satisfied
with, hopefully I can rewrite it more sensibly with the adittional
experience I've accumulated this year.
>> +
>> + # Split @$headlist into a hash of lists
>> + map {
>> + my %ref = %$_;
>> + $ref{'hname'} = $ref{'name'};
>> + if ($ref{'name'} =~ /\//) {
>> + $ref{'name'} =~ s!^([^/]+)/!!;
>
> As I said, this would fail on for example "gsoc2008/gitweb-caching"
> remote...
Would you say that in this case we want 'gsoc2008/gitweb-caching' as
the group head, or would you rather have nested groups [gsoc2008
[gitweb-caching [branches in gsoc2008/gitweb-caching] [etc]] ? I must
say that I think the latter would be quite interesting, but I _am_ a
little afraid we could turn up with way too much nested groups ...
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Nicolas Pitre @ 2008-11-15 8:04 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: David Brown, Linus Torvalds, Andreas Ericsson, Git Mailing List
In-Reply-To: <20081115050039.GC2932@spearce.org>
On Fri, 14 Nov 2008, Shawn O. Pearce wrote:
> David Brown <git@davidb.org> wrote:
> > On Fri, Nov 14, 2008 at 03:46:58PM -0800, Shawn O. Pearce wrote:
> >
> >> 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.)
> >
> > Is this license intended to allow static linking but forbid dynamic
> > linking into a non-GPL program? It depends on how you interpret
> > "linked into a combined executable", but that sounds like it
> > intentionally excludes the dynamic case.
>
> I don't know. When I read it myself I assumed dynamic linking
> would also be OK.
libgcc is a dynamic library on most modern systems these days. Yet they
routinely execute non-GPL programs. If that text intentionally excluded
the dynamic case then every non-GPL applications on such systems would
have been breaking the license for a long time. So I don't think anyone
could have substance for such a claim.
Nicolas
^ permalink raw reply
* Re: [PATCH resend] Documentation: git-svn: fix example for centralized SVN clone
From: Junio C Hamano @ 2008-11-15 7:56 UTC (permalink / raw)
To: Eric Wong; +Cc: Jan Krüger, Git ML
In-Reply-To: <20081115062927.GA426@hand.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> I see what happened: I mis-CC-ed Adam as never had him in my aliases
> file :x
Ah, I see. I should have checked with my "git who" alias.
^ permalink raw reply
* Re: [PATCH] sha1_file: make sure correct error is propagated
From: Sam Vilain @ 2008-11-15 6:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Francis Galiegue, Francis Galiegue, git
In-Reply-To: <7vr65d7dct.fsf@gitster.siamese.dyndns.org>
On Fri, 2008-11-14 at 21:44 -0800, Junio C Hamano wrote:
> Actually, POSIX does not even talk about EPERM for mkdir(2), but that was
> not my point. The code does something different from what the proposed
> commit log message talks about. That was what bothered me.
My wording was a little terse and confusing. Here's a new one;
Subject: sha1_file.c: resolve confusion EACCESS vs EPERM
EPERM or 'Operation not permitted' is an unlikely error from
mkstemp(); test for EACCESS 'Access Denied' instead. Make the
special branch which prints the error to the user nicely also
understand EACCESS.
^ permalink raw reply
* Re: [PATCH resend] Documentation: git-svn: fix example for centralized SVN clone
From: Eric Wong @ 2008-11-15 6:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan Krüger, Git ML
In-Reply-To: <7vljvl7d3k.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Jan Krüger" <jk@jk.gs> writes:
>
> > The example that tells users how to centralize the effort of the initial
> > git svn clone operation doesn't work properly. It uses rebase but that
> > only works if HEAD exists. This adds one extra command to create a
> > somewhat sensible HEAD that should work in all cases.
> >
> > Signed-off-by: Jan Krüger <jk@jk.gs>
> > ---
> > When I first sent this one I said I didn't like the solution all that
> > much (it would be nicer to use origin/HEAD but we didn't fetch that)
> > but Eric said he thinks it's okay and the original author of the
> > section hasn't piped in. It's still better than a nonfunctional example
> > in any case.
>
> I'll mark this Acked by Eric and apply to 'maint'. Thanks, both.
No problem.
I see what happened: I mis-CC-ed Adam as never had him in my aliases
file :x
--
Eric Wong
^ 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