* Proper attribution for modified files
From: alexandrul @ 2009-10-22 16:23 UTC (permalink / raw)
To: Git Mailing List
Hi,
I have started from git-instaweb script and modified it
in order to support my custom setup. The original script
starts with:
#!/bin/sh
#
# Copyright (c) 2006 Eric Wong
#
What would be the proper attribution to place in my modified script
in order to make it available for public download?
Have a nice day,
A.
^ permalink raw reply
* [PATCH] describe: when failing, tell the user about options that work
From: Thomas Rast @ 2009-10-22 15:44 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910220810n389d065di349339ab38909ef7@mail.gmail.com>
Users seem to call git-describe without reading the manpage, and then
wonder why it doesn't work with unannotated tags by default.
Make a minimal effort towards seeing if there would have been
unannotated tags, and tell the user. Specifically, we say that --tags
could work if we found any unannotated tags. If not, we say that
--always would have given results.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Eugene Sajine wrote:
> [git-describe fails if you don't have annotated tags]
>
> Thanks! It is working ok.
> Although it is probably not the best error handling.
> I believe git should fail with some meaningful message in this case...
We already had most of the information available, so hey, why not.
builtin-describe.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/builtin-describe.c b/builtin-describe.c
index 2dcfd3d..1ffa0d8 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -96,8 +96,6 @@ static int get_name(const char *path, const unsigned char *sha1, int flag, void
if (!all) {
if (!prio)
return 0;
- if (!tags && prio < 2)
- return 0;
}
add_to_known_names(all ? path + 5 : path + 10, commit, prio, sha1);
return 0;
@@ -184,6 +182,7 @@ static void describe(const char *arg, int last_one)
struct possible_tag all_matches[MAX_TAGS];
unsigned int match_cnt = 0, annotated_cnt = 0, cur_match;
unsigned long seen_commits = 0;
+ unsigned int unannotated_cnt = 0;
if (get_sha1(arg, sha1))
die("Not a valid object name %s", arg);
@@ -217,7 +216,9 @@ static void describe(const char *arg, int last_one)
seen_commits++;
n = c->util;
if (n) {
- if (match_cnt < max_candidates) {
+ if (!tags && !all && n->prio < 2) {
+ unannotated_cnt++;
+ } else if (match_cnt < max_candidates) {
struct possible_tag *t = &all_matches[match_cnt++];
t->name = n;
t->depth = seen_commits - 1;
@@ -259,7 +260,14 @@ static void describe(const char *arg, int last_one)
printf("%s\n", find_unique_abbrev(sha1, abbrev));
return;
}
- die("cannot describe '%s'", sha1_to_hex(sha1));
+ if (unannotated_cnt)
+ die("cannot describe '%s'"
+ " with only\nannotated tags. Try --tags.",
+ sha1_to_hex(sha1));
+ else
+ die("cannot describe '%s'"
+ " with tags\nTry --always, or create some tags.",
+ sha1_to_hex(sha1));
}
qsort(all_matches, match_cnt, sizeof(all_matches[0]), compare_pt);
--
1.6.5.1.70.g1383ae
^ permalink raw reply related
* Re: What's cooking in git.git (Oct 2009, #03; Mon, 19)
From: Johannes Schindelin @ 2009-10-22 15:33 UTC (permalink / raw)
To: Johan Herland; +Cc: Junio C Hamano, git
In-Reply-To: <200910191125.19997.johan@herland.net>
Hi Johan,
On Mon, 19 Oct 2009, Johan Herland wrote:
> On Monday 19 October 2009, Junio C Hamano wrote:
> > * jh/notes (2009-10-09) 22 commits.
> > - fast-import: Proper notes tree manipulation using the notes API
> > - Refactor notes concatenation into a flexible interface for combining notes
> > - Notes API: Allow multiple concurrent notes trees with new struct notes_tree
> > - Notes API: for_each_note(): Traverse the entire notes tree with a callback
> > - Notes API: get_note(): Return the note annotating the given object
> > - Notes API: add_note(): Add note objects to the internal notes tree structure
> > - Notes API: init_notes(): Initialize the notes tree from the given notes ref
> > - Notes API: get_commit_notes() -> format_note() + remove the commit restriction
> > - Add selftests verifying concatenation of multiple notes for the same commit
> > - Refactor notes code to concatenate multiple notes annotating the same object
> > - Add selftests verifying that we can parse notes trees with various fanouts
> > - Teach the notes lookup code to parse notes trees with various fanout schemes
> > - Teach notes code to free its internal data structures on request
> > - Add '%N'-format for pretty-printing commit notes
> > - Add flags to get_commit_notes() to control the format of the note string
> > - t3302-notes-index-expensive: Speed up create_repo()
> > - fast-import: Add support for importing commit notes
> > - Teach "-m <msg>" and "-F <file>" to "git notes edit"
> > - Add an expensive test for git-notes
> > - Speed up git notes lookup
> > - Add a script to edit/inspect notes
> > - Introduce commit notes
>
> > Is this good for 'next' now?
>
> Not all of it.
>
> I suspect the first 14 patches are stable and 'next'-worthy, although
> it would be nice if Dscho had the time to ACK them.
As you probably realized, I have little time for Git these days (mainly
due to work), so please do not wait for me.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: skillzero @ 2009-10-22 15:31 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jakub Narebski, Junio C Hamano, Git Mailing List
In-Reply-To: <fcaeb9bf0910220415v69c22ed9o4ab85b8858fbf187@mail.gmail.com>
On Thu, Oct 22, 2009 at 4:15 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Thu, Oct 22, 2009 at 3:46 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>> * nd/sparse (2009-08-20) 19 commits.
>>> - sparse checkout: inhibit empty worktree
>>> - Add tests for sparse checkout
>>> - read-tree: add --no-sparse-checkout to disable sparse checkout support
>>> - unpack-trees(): ignore worktree check outside checkout area
>>> - unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
>>> - unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
>>> - unpack-trees.c: generalize verify_* functions
>>> - unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
>>> - Introduce "sparse checkout"
>>> - dir.c: export excluded_1() and add_excludes_from_file_1()
>>> - excluded_1(): support exclude files in index
>>> - unpack-trees(): carry skip-worktree bit over in merged_entry()
>>> - Read .gitignore from index if it is skip-worktree
>>> - Avoid writing to buffer in add_excludes_from_file_1()
>>> - Teach Git to respect skip-worktree bit (writing part)
>>> - Teach Git to respect skip-worktree bit (reading part)
>>> - Introduce "skip-worktree" bit in index, teach Git to get/set this bit
>>> - Add test-index-version
>>> - update-index: refactor mark_valid() in preparation for new options
>>
>> Hmmm... what is happening with that series?
>
> Junio concerned about CE_MATCH_IGNORE_VALID being used by both
> assume-unchanged and skip-worktree bits, which I did not resolve yet.
> I should really get back to the series when I have time.
Just an FYI, but I've been using this series for a while. I'm actually
relying on sparse support in our internal build system (via my private
build with this series) so I hope it doesn't go away :) I haven't
really noticed any problems (I thought the index state got out of sync
once, but I couldn't reproduce the problem later). Here's some
feedback though:
1. I found it confusing to have to append '/' to directories in the
sparse pattern list for directories. I always forget it requires them.
It would be nice to support the same rules as .gitignore in terms of
'/'.
2. It would be nice to have built-in support for a sparse modules file
and switching between them. Maybe .gitmodules could support "module"
or "sparsemodule" sections to list the patterns for that sparse
module. I've written a simple script to do this and it's what I use.
It just parses the INI-style file:
[module "MyProject"]
App1
Shared1
!FolderIDontWant
Then I have a "module" script to read that file for a specified module
and switch to it:
git module switch MyProject
The script just parses `git show HEAD:.gitmodules` (so it works
without a working directory) and switches sparse modules by enabling
sparse, writing info/sparse-checkout, and doing a checkout:
sub cmd_switch
{
# Enable sparse.
my $currentCmd = "git config core.sparsecheckout true";
system( $currentCmd ) == 0 or die( "error: $currentCmd\n" );
# Write sparse patterns.
my $gitDir = `git rev-parse --git-dir`;
chop( $gitDir );
my $sparsePath = $gitDir . "/info/sparse-checkout";
if( $? != 0 ) { die( "error: read git directory failed $?\n" ); }
open( FILE, ">", $sparsePath ) or die( "error: can't open '$sparsePath'\n" );
foreach( @{$gModules->{$gModuleName}} )
{
print( FILE "$_\n" );
}
close( FILE );
# Checkout using new sparse patterns.
system( "git checkout" ) == 0 or die( "error: switch module failed\n" );
}
That said, the current level of sparse support provided by this series
is good enough for me because I can build my own scripts like this on
top of it to automate things.
^ permalink raw reply
* Re: git describe is failing
From: Eugene Sajine @ 2009-10-22 15:10 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200910221702.39452.trast@student.ethz.ch>
> man git-describe:
>
> DESCRIPTION
> The command finds the most recent tag that is reachable from a
> commit.
> [...]
> By default (without --all or --tags) git describe only shows
> annotated tags. For more information about creating annotated
> tags see the -a and -s options to git-tag(1).
>
> If there is no such tag, it refuses to work. Annotate your tags, or
> try --always.
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
>
Thanks! It is working ok.
Although it is probably not the best error handling.
I believe git should fail with some meaningful message in this case...
Thanks,
Eugene
^ permalink raw reply
* Re: git describe is failing
From: Thomas Rast @ 2009-10-22 15:02 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910220747w709d2b41s4f7b121e421e843c@mail.gmail.com>
Eugene Sajine wrote:
> $ git describe
>
> gives:
>
> fatal: cannot describe 'SHA-1'
man git-describe:
DESCRIPTION
The command finds the most recent tag that is reachable from a
commit.
[...]
By default (without --all or --tags) git describe only shows
annotated tags. For more information about creating annotated
tags see the -a and -s options to git-tag(1).
If there is no such tag, it refuses to work. Annotate your tags, or
try --always.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git describe is failing
From: Mikael Magnusson @ 2009-10-22 14:59 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910220747w709d2b41s4f7b121e421e843c@mail.gmail.com>
2009/10/22 Eugene Sajine <euguess@gmail.com>:
> Hi,
>
> I have a test repo which I'm playing with. It has about 15 commits and
> one branch only (master) and couple of tags. Somehow it got to a state
> when
>
> $ git describe
>
> gives:
>
> fatal: cannot describe 'SHA-1'
>
> The command is working ok with my other repo. It doesn't seem that the
> test repo is corrupted. I can commit, push and pull, see the history
> with gitk... How can I check or repair it?
>
> Thanks,
> Eugene
Your tags are probably not annotated (lightweight tags), use git
describe --tags.
--
Mikael Magnusson
^ permalink raw reply
* git describe is failing
From: Eugene Sajine @ 2009-10-22 14:47 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
Hi,
I have a test repo which I'm playing with. It has about 15 commits and
one branch only (master) and couple of tags. Somehow it got to a state
when
$ git describe
gives:
fatal: cannot describe 'SHA-1'
The command is working ok with my other repo. It doesn't seem that the
test repo is corrupted. I can commit, push and pull, see the history
with gitk... How can I check or repair it?
Thanks,
Eugene
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Daniel Barkalow @ 2009-10-22 14:46 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Shawn O. Pearce, Johan Herland, git
In-Reply-To: <20091022192149.6117@nanako3.lavabit.com>
On Thu, 22 Oct 2009, Nanako Shiraishi wrote:
> Quoting "Shawn O. Pearce" <spearce@spearce.org>
>
> > Actually, after some further research, the bug is not Johan's but is
> > actually Daniel's. Johan, I apologize for claiming it was your bug.
> > ...
> > Long story short, transport_close() is what is supposed to perform
> > the work that disconnect_helper does, as its the final thing right
> > before we free the struct transport block. Free'ing the data block
> > inside of the fetch or push functions is wrong.
> >
> > Its fine to close the helper and restart it within the single
> > lifespan of a struct transport, but dammit, don't free the
> > struct helper_data until transport_close().
>
> Ping? Are there any progress on this issue?
Ah, right. Shawn's analysis is correct, and I should have a different
function to just finish the helper, but leave the rest of the data alone.
(when I wrote it originally, I didn't have anything other than the
connection in there, so it was right to clear it, but now there's a real
helper_data and it needs to do the right things).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Documentation/git-pull.txt: Add subtitles above included option files
From: Jari Aalto @ 2009-10-22 14:14 UTC (permalink / raw)
To: git
In-Reply-To: <20091022192152.6117@nanako3.lavabit.com>
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/git-pull.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> Ah, in your defense ;-) I think you looked only at git-fetch.txt without
>> checking where else this file is included. Then the patch certainly is
>> understandable. It would probably make git-fetch.{1,html} easier to scan,
>> while making things not worse for git-pull.{1,html}
>
> Can't we introduce subsections in the OPTIONS section to
> group them together, like this (sorry, not a patch)?
>
> OPTIONS
> -------
>
> Options related to merging <---- added
> ~~~~~~~~~~~~~~~~~~~~~~~~~~ <---- added
> include::merge-options.txt[]
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 7578623..51534dd 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -26,6 +26,10 @@ Also note that options meant for 'git-pull' itself and underlying
OPTIONS
-------
+
+Options related to merging
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
include::merge-options.txt[]
:git-pull: 1
@@ -47,6 +51,9 @@ unless you have read linkgit:git-rebase[1] carefully.
--no-rebase::
Override earlier --rebase.
+Options related to fetching
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
include::fetch-options.txt[]
include::pull-fetch-param.txt[]
--
1.6.4.3
^ permalink raw reply related
* Re: [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Jeff King @ 2009-10-22 11:25 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Jari Aalto, git
In-Reply-To: <20091022192152.6117@nanako3.lavabit.com>
On Thu, Oct 22, 2009 at 07:21:52PM +0900, Nanako Shiraishi wrote:
> > Ah, in your defense ;-) I think you looked only at git-fetch.txt without
> > checking where else this file is included. Then the patch certainly is
> > understandable. It would probably make git-fetch.{1,html} easier to scan,
> > while making things not worse for git-pull.{1,html}
>
> Can't we introduce subsections in the OPTIONS section to
> group them together, like this (sorry, not a patch)?
Yes, that was my first thought when reading this thread, too (sorry, no
patch here, either. I need to sleep and then get on a plane).
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: Nguyen Thai Ngoc Duy @ 2009-10-22 11:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <m3ljj3es02.fsf@localhost.localdomain>
On Thu, Oct 22, 2009 at 3:46 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>> * nd/sparse (2009-08-20) 19 commits.
>> - sparse checkout: inhibit empty worktree
>> - Add tests for sparse checkout
>> - read-tree: add --no-sparse-checkout to disable sparse checkout support
>> - unpack-trees(): ignore worktree check outside checkout area
>> - unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
>> - unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
>> - unpack-trees.c: generalize verify_* functions
>> - unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
>> - Introduce "sparse checkout"
>> - dir.c: export excluded_1() and add_excludes_from_file_1()
>> - excluded_1(): support exclude files in index
>> - unpack-trees(): carry skip-worktree bit over in merged_entry()
>> - Read .gitignore from index if it is skip-worktree
>> - Avoid writing to buffer in add_excludes_from_file_1()
>> - Teach Git to respect skip-worktree bit (writing part)
>> - Teach Git to respect skip-worktree bit (reading part)
>> - Introduce "skip-worktree" bit in index, teach Git to get/set this bit
>> - Add test-index-version
>> - update-index: refactor mark_valid() in preparation for new options
>
> Hmmm... what is happening with that series?
Junio concerned about CE_MATCH_IGNORE_VALID being used by both
assume-unchanged and skip-worktree bits, which I did not resolve yet.
I should really get back to the series when I have time.
--
Duy
^ permalink raw reply
* Re: [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Nanako Shiraishi @ 2009-10-22 10:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jari Aalto, git
In-Reply-To: <7vhbts3285.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Ah, in your defense ;-) I think you looked only at git-fetch.txt without
> checking where else this file is included. Then the patch certainly is
> understandable. It would probably make git-fetch.{1,html} easier to scan,
> while making things not worse for git-pull.{1,html}
Can't we introduce subsections in the OPTIONS section to
group them together, like this (sorry, not a patch)?
OPTIONS
-------
Options related to merging <---- added
~~~~~~~~~~~~~~~~~~~~~~~~~~ <---- added
include::merge-options.txt[]
:git-pull: 1
--rebase::
Instead of a merge, perform a rebase after fetching. If
there is a remote ref for the upstream branch, and this branch
was rebased since last fetched, the rebase uses that information
to avoid rebasing non-local changes. To make this the default
for branch `<name>`, set configuration `branch.<name>.rebase`
to `true`.
+
[NOTE]
This is a potentially _dangerous_ mode of operation.
It rewrites history, which does not bode well when you
published that history already. Do *not* use this option
unless you have read linkgit:git-rebase[1] carefully.
--no-rebase::
Override earlier --rebase.
Options related to fetching <---- added
~~~~~~~~~~~~~~~~~~~~~~~~~~~ <---- added
include::fetch-options.txt[]
include::pull-fetch-param.txt[]
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Nanako Shiraishi @ 2009-10-22 10:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Daniel Barkalow, Johan Herland, git
In-Reply-To: <20091015204543.GP10505@spearce.org>
Quoting "Shawn O. Pearce" <spearce@spearce.org>
> Actually, after some further research, the bug is not Johan's but is
> actually Daniel's. Johan, I apologize for claiming it was your bug.
> ...
> Long story short, transport_close() is what is supposed to perform
> the work that disconnect_helper does, as its the final thing right
> before we free the struct transport block. Free'ing the data block
> inside of the fetch or push functions is wrong.
>
> Its fine to close the helper and restart it within the single
> lifespan of a struct transport, but dammit, don't free the
> struct helper_data until transport_close().
Ping? Are there any progress on this issue?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC/PATCH] git-merge: forbid fast-forward and up-to-date when --no-commit is given
From: Nanako Shiraishi @ 2009-10-22 10:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Clemens Buchacher, Bjorn Steinbrink, Daniel Barkalow,
Thomas Rast
In-Reply-To: <7vpr8g1l2a.fsf_-_@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Traditionally "git merge --no-commit" meant just that: do not create a new
> commit even when a merge succeeds. But this leads to confusion when the
> merged commit is a descendant of the current commit, in which case we
> succeed the merge by fast-forwarding and without creating a new commit.
> Also when the merged commit is already a part of the history, we succeeded
> without doing anything.
>
> Error out when --no-commit is given but the merge would result in a
> fast-forward or an up-to-date.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> * This is the first alternative. I think it makes more sense than the
> other one, but I am unsure, as I obviously do not get confused when
> --no-commit becomes no-op due to a fast-forward nor an up-to-date and
> am rather happy with the current behaviour.
I think this is good (but I am saying this only from your
description without understanding the updated code), but
the change breaks --squash to merge a branch, doesn't it?
% git checkout feature # from your master branch
% work; git commit; work; git commit
% git checkout master # go back to your master branch
% git merge --squash feature
This is a useful way to clean up changes that were built
in small steps that turned out to be worth only a commit.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Thomas Rast @ 2009-10-22 9:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, Daniel Barkalow, git
In-Reply-To: <7vk4ypb71j.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > So that's ten days of #git. I left out a bunch of duplications (most
> > were "pull == fetch", "pull == update" and "pull to update
> > non-checked-out branch").
>
> Interesting; this shows that people who do not understand what "pull" does
> expect different behaviour from "pull", use the word "pull" to express
> what they want to happen, expect other people interpret the word to mean
> the way they think it does. At the same time, judging from different
> behaviour expected by these people, push/pull asymmetry does not seem to
> have much to do with the confusion.
This of course is where our conclusions differ. I haven't counted
them, but Björn (thanks again for the excellent survey) points out
that most duplicates are confusion with fetch, (imagined) update or
"update to not checked out branch".
Pull is none of these, but if it was (current) fetch, at least the
first group of people would have had the right idea of what it does.
> I am actually even Ok, at least in the long run (like in 3 years), if we
> were to deprecate the refspecs with colon given on the command line to
> "pull" and "fetch" altogether [*1*].
As an aside, there are actually some use-cases, e.g., to grab the
git-svn refs from a freshly cloned repository you would run:
git fetch origin refs/remotes/*:refs/remotes/*
(and then 'git svn init' etc.) I've also had some weird requests on
IRC that could be solved by clever (and of course dangerous) use of
'git fetch . glob:otherglob'.
Hiding that power behind an option could be a good idea though.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] Documentation/merge-options.txt: order options in alphabetical groups
From: Jari Aalto @ 2009-10-22 9:24 UTC (permalink / raw)
To: git
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/merge-options.txt | 79 ++++++++++++++++++++-------------------
1 files changed, 41 insertions(+), 38 deletions(-)
The --option and --no-options have been grouped together as in:
--option
--no-option
The alphabetical order is according to the --option.
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index adadf8e..f1fdb65 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -1,43 +1,42 @@
--q::
---quiet::
- Operate quietly.
-
--v::
---verbose::
- Be verbose.
+--commit::
+--no-commit::
+ Perform the merge and commit the result. This option can
+ be used to override --no-commit.
---stat::
- Show a diffstat at the end of the merge. The diffstat is also
- controlled by the configuration option merge.stat.
+ With --no-commit perform the merge but pretend the merge
+ failed and do not autocommit, to give the user a chance to
+ inspect and further tweak the merge result before committing.
--n::
---no-stat::
- Do not show a diffstat at the end of the merge.
+--ff::
+--no-ff::
+ Do not generate a merge commit if the merge resolved as
+ a fast-forward, only update the branch pointer. This is
+ the default behavior of git-merge.
---summary::
---no-summary::
- Synonyms to --stat and --no-stat; these are deprecated and will be
- removed in the future.
+ With --no-ff Generate a merge commit even if the merge
+ resolved as a fast-forward.
--log::
+--no-log::
In addition to branch names, populate the log message with
one-line descriptions from the actual commits that are being
merged.
---no-log::
- Do not list one-line descriptions from the actual commits being
- merged.
+ With --no-log do not list one-line descriptions from the
+ actual commits being merged.
---no-commit::
- Perform the merge but pretend the merge failed and do
- not autocommit, to give the user a chance to inspect and
- further tweak the merge result before committing.
---commit::
- Perform the merge and commit the result. This option can
- be used to override --no-commit.
+--stat::
+-n::
+--no-stat::
+ Show a diffstat at the end of the merge. The diffstat is also
+ controlled by the configuration option merge.stat.
+
+ With -n or --no-stat do not show a diffstat at the end of the
+ merge.
--squash::
+--no-squash::
Produce the working tree and index state as if a real
merge happened (except for the merge information),
but do not actually make a commit or
@@ -47,18 +46,9 @@
top of the current branch whose effect is the same as
merging another branch (or more in case of an octopus).
---no-squash::
- Perform the merge and commit the result. This option can
- be used to override --squash.
---no-ff::
- Generate a merge commit even if the merge resolved as a
- fast-forward.
-
---ff::
- Do not generate a merge commit if the merge resolved as
- a fast-forward, only update the branch pointer. This is
- the default behavior of git-merge.
+ With --no-squash perform the merge and commit the result. This
+ option can be used to override --squash.
-s <strategy>::
--strategy=<strategy>::
@@ -67,3 +57,16 @@
If there is no `-s` option, a built-in list of strategies
is used instead ('git-merge-recursive' when merging a single
head, 'git-merge-octopus' otherwise).
+
+--summary::
+--no-summary::
+ Synonyms to --stat and --no-stat; these are deprecated and will be
+ removed in the future.
+
+-q::
+--quiet::
+ Operate quietly.
+
+-v::
+--verbose::
+ Be verbose.
--
1.6.4.3
^ permalink raw reply related
* Re: [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Jari Aalto @ 2009-10-22 9:23 UTC (permalink / raw)
To: git
In-Reply-To: <7vhbts3285.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think you looked only at git-fetch.txt without
> checking where else this file is included. Then the patch certainly is
> understandable. It would probably make git-fetch.{1,html} easier to scan,
> while making things not worse for git-pull.{1,html}
Yes. Unfortunately there doesn't seem to be a way to arrange all nicely,
so perhaps you could accept the following patch to accompany with it. At
least there would be ordered "git-fetch" and semi ordered "git-pull".
Subject: [PATCH] Documentation/merge-options.txt: order options in alphabetical groups
Jari
^ permalink raw reply
* Re: [PATCH] modernize fetch/merge/pull examples
From: Thomas Rast @ 2009-10-22 8:51 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Junio C Hamano, Björn Steinbrink, Daniel Barkalow, git
In-Reply-To: <20091021172123.GB27495@localhost>
Clemens Buchacher wrote:
> On Tue, Oct 20, 2009 at 11:22:16PM -0700, Junio C Hamano wrote:
>
> > For example, I am in favor of deprecating the "pull $there $src:$dst"
> > notation.
>
> A first step in that direction.
I think this is a good change independently of the deprecation.
> +------------------------------------------------
> +$ git fetch origin +pu:pu maint:tmp
> +------------------------------------------------
[...]
> +The `pu` branch will be updated even if it is does not fast-forward;
> +the others will not be.
I think to a new user it is not immediately clear if this means "will
not be updated, period" or "will not be updated if ...". How about
The `pu` branch will always be updated; the `tmp` branch only if it
is a fast-forward update.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: Jakub Narebski @ 2009-10-22 8:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Giuseppe Bilotta, Mark Rada, Stephen Boyd, Nick Edelen,
Nguyen Thai Ngoc Duy
In-Reply-To: <7veiovly35.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * gb/maint-gitweb-esc-param (2009-10-13) 1 commit.
> (merged to 'next' on 2009-10-14 at 105f997)
> + gitweb: fix esc_param
> (this branch is used by sb/gitweb-link-author.)
Good. Beside fixing excaping of multibyte Unicode characters this
also finally makes gitweb use '+' and not '%20' to encode space ' '
in CGI parameters.
This reminds me that gitweb really should do conversion / marking data
as UTF-8 _on input_, to avoid situations where output is mangled
because of problems with Unicode. That goes to my gitweb's TODO.
> * mr/gitweb-snapshot (2009-09-26) 2 commits.
> - gitweb: append short hash ids to snapshot files
> (merged to 'next' on 2009-10-11 at 22ba047)
> + gitweb: check given hash before trying to create snapshot
>
> I lost track of the discussion around the tip commit. The bottom one may
> better go to 'master' regardless.
The tip commit should be fixed before accepting. There are some
problems with it as it is now:
* $hash parameter is abused to hold version suffix of snapshot
filename (and archive prefix), e.g. 'next-ae4ab03'; it really
should be done using separate variable, and perhaps even separate
subroutine which would generate snapshot name.
* I don't think it works with fully qualified refnames that gitweb
itself generate, e.g. 'refs/heads/next' or 'refs/tags/v1.6.0',
nor with hierarchical branch names such as 'mr/gitweb-snapshot';
snapshot name can't include '/', and prefix shouldn't include '/'
* when new test is running with --debug option, it dumps whole output
of gitweb for 'snapshot' action, which includes *binary data*, and
not only HTTP headers like it should (at least in first version).
> * sb/gitweb-link-author (2009-10-15) 1 commit
> - gitweb: linkify author/committer names with search
>
> Soon in 'next'.
Is this version that uses title attribute to show that this link is
different in that it leads to search results, not an action view?
> * jn/gitweb-blame (2009-09-01) 5 commits.
> - gitweb: Minify gitweb.js if JSMIN is defined
> - gitweb: Create links leading to 'blame_incremental' using JavaScript
> (merged to 'next' on 2009-10-11 at 73c4a83)
> + gitweb: Colorize 'blame_incremental' view during processing
> + gitweb: Incremental blame (using JavaScript)
> + gitweb: Add optional "time to generate page" info in footer
>
> Ajax-y blame. Probably the first three should go to 'master' by now?
The first three makes fairly 'invisible' change, but introduce
possibility of using JavaScript in gitweb. I'd like more testing with
different browsers than mine, but corrections if any can be done
in-tree.
The "Create links" patch is not ready yet.
> * rs/pretty-wrap (2009-10-17) 1 commit
> - Implement wrap format %w() as if it is a mode switch
> (this branch uses js/log-rewrap; is related to jc/strbuf-nested-expand.)
>
> When it comes to design issues to keep unnecessary complexity out, I tend
> to trust Rene (and Nico) a lot more than I trust myself. Tonight's 'pu'
> queues this series instead of my "nested" one.
> * jc/strbuf-nested-expand (2009-10-18) 3 commits
> . Teach --wrap to only indent without wrapping
> . Add %[wrap(width,in1,in2)<<any-string>>%] implementation
> . strbuf_nested_expand(): allow expansion to interrupt in the middle
> (this branch uses js/log-rewrap; is related to rs/pretty-wrap.)
>
> Ejected from 'pu' to let rs/pretty-wrap in as described above.
I think nested expand is easier to use than a mode switch: using
scoping (well, kind of) like in high-level programming languages is
IMVHO easier than programming a state machine like in assembler (or
e.g. OpenGL).
On the other hand this makes pretty format into a mini-language; also
we already have and use mode switches in the form of color codes.
Perhaps if color also used wrapping / nested expand, so one doesn't
have to track where to turn off and on which toggle...
> * jg/log-format-body-indent (2009-09-19) 1 commit.
> . git-log --format: Add %B tag with %B(x) option
...and this was yet another alternate solution (less generic, though)
> * jc/pretty-lf (2009-10-04) 1 commit.
> - Pretty-format: %[+-]x to tweak inter-item newlines
I understand that %a%+b expands to %a%n%b if %b has non-empty
expansion, and to %a if %b is empty, but what %-b is used for?
> * js/log-rewrap (2008-11-10) 2 commits
> - Add strbuf_add_wrapped_text() to utf8.[ch]
> - print_wrapped_text(): allow hard newlines
> (this branch is used by jc/strbuf-nested-expand and rs/pretty-wrap.)
>
> Soon in 'next'; regardless of how wrapping is exposed to --pretty=format,
> this code will be used, and it seems to be leak-free and reasonably done.
>
> We _might_ want to cherry-pick the tip of jc/strbuf-nested-expand to this
> series, though.
> --------------------------------------------------
> [Cooking]
>
> * ne/rev-cache (2009-10-19) 7 commits.
> - support for commit grafts, slight change to general mechanism
> - support for path name caching in rev-cache
> - full integration of rev-cache into git, completed test suite
> - administrative functions for rev-cache, start of integration into git
> - support for non-commit object caching in rev-cache
> - basic revision cache system, no integration or features
> - man page and technical discussion for rev-cache
>
> Still unstable? Has an extra test squashed in; tonight's 'pu' does not
> pass tests.
BTW. I would really prefer if this series was send with cover letter
explaining series and perhaps differences from previous version of
series as a whole (reordering, splitting and joining patches, new
patches etc.), and individual patches in series replies to this cover
letter, without 'Re: ' prefix in subject, and with explanation of the
difference from previous version (if any) in the commentary area.
> * nd/sparse (2009-08-20) 19 commits.
> - sparse checkout: inhibit empty worktree
> - Add tests for sparse checkout
> - read-tree: add --no-sparse-checkout to disable sparse checkout support
> - unpack-trees(): ignore worktree check outside checkout area
> - unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
> - unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
> - unpack-trees.c: generalize verify_* functions
> - unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
> - Introduce "sparse checkout"
> - dir.c: export excluded_1() and add_excludes_from_file_1()
> - excluded_1(): support exclude files in index
> - unpack-trees(): carry skip-worktree bit over in merged_entry()
> - Read .gitignore from index if it is skip-worktree
> - Avoid writing to buffer in add_excludes_from_file_1()
> - Teach Git to respect skip-worktree bit (writing part)
> - Teach Git to respect skip-worktree bit (reading part)
> - Introduce "skip-worktree" bit in index, teach Git to get/set this bit
> - Add test-index-version
> - update-index: refactor mark_valid() in preparation for new options
Hmmm... what is happening with that series?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))
From: Stephen Boyd @ 2009-10-22 8:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kirill Smelkov, Shawn O. Pearce
In-Reply-To: <7veiovly35.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> * ks/precompute-completion (2009-10-05) 1 commit.
> (merged to 'next' on 2009-10-14 at adf722a)
> + Speedup bash completion loading
>
> Are people happy with this?
No. I now have rebase.sh, am.sh, etc. in my completion because of how
git help -a fully lists git commands in libexec and elsewhere in my
$PATH (which gets pointed to my build directory during make).
It's late and I'm tired, but I think we can just ignore files ending in
*.sh, *.perl, etc.
diff --git a/contrib/completion/git-completion.bash.generate b/contrib/completion/git-completion.bash.generate
index 33b1d1d..6487fd5 100755
--- a/contrib/completion/git-completion.bash.generate
+++ b/contrib/completion/git-completion.bash.generate
@@ -24,6 +24,7 @@ __git_all_commands ()
do
case $i in
*--*) : helper pattern;;
+ *.sh|*.perl) : build scripts;;
*) echo $i;;
esac
done
^ permalink raw reply related
* Re: Finding a commit
From: Soham Mehta @ 2009-10-22 8:32 UTC (permalink / raw)
To: git
Thanks for all the answers! Sorry for the delayed reply.
Like Douglas Campos suggested, git-cherry (which uses git-patch-id like
Thomas Rast suggests) works for me. Here is what I tried:
from first repo$: git fetch second-repo
from first repo$: git cherry -v second-repo/branch-in-question sha1 sha1^
- sha1 <commit message>
Outputs the sha1 with a minus sign in front, which means the change is
already present in second-repo/branch-in-question, and is what I expect.
-Soham
thus spake Daniele Segato , On 10/21/2009 6:55 AM:
> On Wed, Oct 21, 2009 at 2:37 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>
>>> Commit -> Tree ---> Blob1, Blob2, Blob3
>>>
>>> Commit, Trees and Blobs are all identified by sha1
>>> the commit should keep information on the author, the "parent"
>>> commit(s) and so on..
>>> the tree should just keep the "snapshot" of the data..
>>>
>>> so I think that if you search for the SHA-1 of the tree you should be fine..
>>>
>> Not if you really want to find out if X was cherry-picked into this
>> repository, because the tree is the *final state* at that commit,
>> which of course includes all preceding changes.
>>
>> So suppose you have two patches A.diff and B.diff introducing files of
>> the same name; then if you combine them into history as
>>
>> A -- B
>>
>> the tree state at B has both files, and hence is different from the
>> tree state of B' in
>>
>> B' -- A'
>>
>> because there it only has the file B.
>>
>
> Yes... obviously...
> the tree is the snapshot of a complete data set: so if you apply the
> same patch to different data set you get different trees...
> thanks for pointing it out.. :)
>
> Regards,
> Daniele
>
^ permalink raw reply
* Re: [PATCH v2 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Johannes Sixt @ 2009-10-22 8:31 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <200910221005.11813.trast@student.ethz.ch>
Thomas Rast schrieb:
> Well, I just observed while writing the patch that you cannot say
>
> git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
Please include this in the commit message.
> Johannes Sixt wrote:
>> Thomas Rast schrieb:
>>> @@ -257,15 +257,29 @@ git read-tree || die "Could not seed the index"
>>> # map old->new commit ids for rewriting parents
>>> mkdir ../map || die "Could not create map/ directory"
>>>
>>> +non_ref_args=$(git rev-parse --no-revs --sq "$@")
>>> +dashdash=--
>>> +for arg in "$non_ref_args"; do
>> At this point $non_ref_args might contain one or more IFS-separatable
>> words, but if you say "$non_ref_args" here, this loop will be entered
>> exactly once. But even if you drop the dquotes, the --sq quoting that you
>> requested from rev-parse bought you nothing.
>
> Hrm. Ok, so the ".." were clearly in mistake, but why could I remove
> the --sq? Doesn't the shell expand the arguments provided by
> $non_ref_args if I use it without quotes nor --sq, so that it might
> accidentally expand paths or such?
When the shell expands $variable (outside quotes), it does not apply
quotes anymore, but only word-splits using $IFS. In your code, the words
would contain literal single-quotes, and paths with spaces would still be
split into words.
Wouldn't it be sufficient to just check whether any non-rev arguments are
present, and to suppress '--' if there are, like:
dashdash=
test -z "$(git rev-parse --no-revs "$@")" && dashdash=--
OK, this still leaves you with the problem that you want to separate
non-rev arguments from rev arguments. Right?
For this I suggest that you extract revs into a regular variable (because
the SHA1s can be word-split in a predictable way), and that you leave the
non-rev arguments in $@:
revs=$(git rev-parse --revs "$@") # don't know if this works
eval set -- "$(git rev-parse --no-revs --sq "$@")" # dquotes?
or so... This way you 'eval' should not be needed in later code.
-- Hannes
^ permalink raw reply
* Re: keeping track of where a patch begins
From: Thomas Rast @ 2009-10-22 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, E R, git, Jeff King
In-Reply-To: <7veiow4iqc.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> A branch in git, as Randal often used to say on #git, is an illusion---it
> points only at the top and does not identify the bottom.
>
> But it does _not_ have to stay that way at the Porcelain level.
>
> Here is a rough sketch of one possible solution. It is not fully thought
> out; the basic idea is probably sound but I did not try to exhaustively
> cover changes to various tools that are necessary to maintain the
> invariants this scheme requires.
>
> (0) Define a way to identify the bottom of a branch. One way to do this
> is by an extra ref (e.g. refs/branchpoints/frotz). Then the commits
> between refs/branchpoints/frotz..refs/heads/frotz identifies the
> commits on the branch. None of the additional restrictions below
> applies when the branch does not have such bottom defined (i.e.
> created by the current git without this extension).
>
> (1) At branch creation, the branchpoint is noted. [...]
>
> (2) You can grow the branch naturally with "commit", "am" and "merge".
> The bottom of the branch does not have to move with these operations.
>
> (3) Operations that alter histories, e.g. "commit --amend", "rebase",
> "reset", while on a branch that records its bottom need to be taught
> to pay attention to not break its bottom. [...]
>
> (4) Operations that browse histories, e.g. "log", "show-branch", while on
> a branch that records its bottom can be taught to pay attention to
> the bottom. [...]
I think this not only changes the model of branches, but also commits,
to some extent. Currently, commit have no intrinsic branch
membership; if you say
git branch foo bar
you cannot distinguish whether the commits on 'bar' were created on
'foo' or on 'bar'. (By git's means; of course the decision would
favour 'master' if I had used that instead.)
Technically your proposal does not change this fact very much; it is
still possible to create "clones" of branches that are
indistinguishable. However, to the *user* I think we would create a
notion that "a commit belongs to one specific branch", in that, during
the course of normal operations, a commit will end up on exactly one
git rev-list --first-parent base..branch
range.
(Not sure if I consider this as an argument in favour or against yet,
but I wanted to point it out anyway.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH v3] Quote ' as \(aq in manpages
From: Thomas Rast @ 2009-10-22 8:19 UTC (permalink / raw)
To: git; +Cc: Anders Kaseorg, Miklos Vajna, Junio C Hamano, bill lam
In-Reply-To: <alpine.DEB.2.00.0910211824220.5105@dr-wily.mit.edu>
The docbook/xmlto toolchain insists on quoting ' as \'. This does
achieve the quoting goal, but modern 'man' implementations turn the
apostrophe into a unicode "proper" apostrophe (given the right
circumstances), breaking code examples in many of our manpages.
Quote them as \(aq instead, which is an "apostrophe quote" as per the
groff_char manpage.
Unfortunately, as Anders Kaseorg kindly pointed out, this is not
portable beyond groff, so we add an extra Makefile variable GNU_ROFF
which you need to enable to get the new quoting.
Thanks also to Miklos Vajna for documentation.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Anders Kaseorg wrote:
> On Wed, 21 Oct 2009, Junio C Hamano wrote:
> > > +# Define GNU_ROFF if you have GNU roff and you don't want to have pretty
> > > +# apostrophe so that cut&pasting examples to the shell will work.
> >
> > This makes it sound as if groff is the only roff implementation that has
> > this problem---iow, if we use non-GNU roff then the documentation comes
> > out just fine. Is that the case?
>
> Yes:
I'll take your word for it, but I cannot test with anything non-GNU.
> In order to build a manpage that can be viewed correctly on both
> platforms, the conditional logic should live in the manpage itself (as per
> the bug comments I linked to and Thomas quoted from).
I reworded Miklos' doc patch a bit to indicate that it's about the
target system, and also added a slightly longer comment to the
Documentation/Makefile for completeness.
Documentation/Makefile | 8 ++++++++
Documentation/manpage-quote-apos.xsl | 16 ++++++++++++++++
Makefile | 4 ++++
3 files changed, 28 insertions(+), 0 deletions(-)
create mode 100644 Documentation/manpage-quote-apos.xsl
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 06b0c57..cd5b439 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -103,6 +103,14 @@ ifdef DOCBOOK_SUPPRESS_SP
XMLTO_EXTRA += -m manpage-suppress-sp.xsl
endif
+# If your target system uses GNU groff, it may try to render
+# apostrophes as a "pretty" apostrophe using unicode. This breaks
+# cut&paste, so you should set GNU_ROFF to force them to be ASCII
+# apostrophes. Unfortunately does not work with non-GNU roff.
+ifdef GNU_ROFF
+XMLTO_EXTRA += -m manpage-quote-apos.xsl
+endif
+
SHELL_PATH ?= $(SHELL)
# Shell quote;
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
diff --git a/Documentation/manpage-quote-apos.xsl b/Documentation/manpage-quote-apos.xsl
new file mode 100644
index 0000000..aeb8839
--- /dev/null
+++ b/Documentation/manpage-quote-apos.xsl
@@ -0,0 +1,16 @@
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ version="1.0">
+
+<!-- work around newer groff/man setups using a prettier apostrophe
+ that unfortunately does not quote anything when cut&pasting
+ examples to the shell -->
+<xsl:template name="escape.apostrophe">
+ <xsl:param name="content"/>
+ <xsl:call-template name="string.subst">
+ <xsl:with-param name="string" select="$content"/>
+ <xsl:with-param name="target">'</xsl:with-param>
+ <xsl:with-param name="replacement">\(aq</xsl:with-param>
+ </xsl:call-template>
+</xsl:template>
+
+</xsl:stylesheet>
diff --git a/Makefile b/Makefile
index fea237b..2ccbe4a 100644
--- a/Makefile
+++ b/Makefile
@@ -159,6 +159,10 @@ all::
# Define ASCIIDOC_NO_ROFF if your DocBook XSL escapes raw roff directives
# (versions 1.72 and later and 1.68.1 and earlier).
#
+# Define GNU_ROFF if your target system uses GNU groff. This forces
+# apostrophes to be ASCII so that cut&pasting examples to the shell
+# will work.
+#
# Define NO_PERL_MAKEMAKER if you cannot use Makefiles generated by perl's
# MakeMaker (e.g. using ActiveState under Cygwin).
#
--
1.6.5.1.144.g316236
^ permalink raw reply related
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