* Re: Starting 1.5.3 stabilization cycle
From: Peter Baumann @ 2007-07-03 22:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707031923180.4071@racer.site>
On Tue, Jul 03, 2007 at 07:27:54PM +0100, Johannes Schindelin wrote:
[... skipping an embarrassing part of the message :-) ...]
> > This is meant for reordering the commits, merge several commits into
> > one or even remove some of them.
>
> Or even better:
>
> - "git rebase" learned an "interactive" mode, where you can pick
> and reorder the commits to be applied.
Sounds nicer, but I would add that it is also possible to remove commits.
> > > - "git-filter-branch" is a reborn cg-admin-rewritehist.
> >
> > Better mention what it is for, e.g:
> >
> > Lets you rewrite GIT revision history by applying custom filters
> > on each revision. Those filters can modify each tree or
> > information about each commit.
>
> I never liked that description. How about (shameless plug) the description
> >from my last patch:
>
> git-filter-branch lets you rewrite the revision history of the
> current branch, creating a new branch. You can specify a number of
> filters to modify the commits, files and trees.
I find it a little distracting to mention the "new branch" in this short
description. I think this belongs into the manpage and not in a short
description for the release notes. But I agree that this sounds otherwise nicer.
-Peter
^ permalink raw reply
* [StGIT PATCH v2] Recognize refs under remotes/ as parent branch on stack creation.
From: Yann Dirson @ 2007-07-03 22:12 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Also remove the "relaxed" parentbranch detecting logic (accepting
anything with an embedded slash as a parent branch name), which was
never invoked because of a bug, and looks like a bad idea anyway.
Better add sensible namespaces when we feel a need for them, rather
than accepting anything by default, with potentially unwanted results.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
For some reason I had omitted to run the testsuite on the final
version of this patch. Here is a version that also works when the
branchpoint is a stgit-only ref ("base" in the testsuite).
stgit/commands/branch.py | 39 +++++++++++++++++++++++++--------------
1 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/stgit/commands/branch.py b/stgit/commands/branch.py
index c22e143..2fb5f59 100644
--- a/stgit/commands/branch.py
+++ b/stgit/commands/branch.py
@@ -122,27 +122,38 @@ def func(parser, options, args):
tree_id = None
if len(args) >= 2:
+ parentbranch = None
try:
- if git.rev_parse(args[1]) == git.rev_parse('refs/heads/' + args[1]):
- # we are for sure referring to a branch
- parentbranch = 'refs/heads/' + args[1]
- out.info('Recording "%s" as parent branch' % parentbranch)
- elif git.rev_parse(args[1]) and re.search('/', args[1]):
- # FIXME: should the test be more strict ?
- parentbranch = args[1]
- else:
- # Note: this includes refs to StGIT patches
- out.info('Don\'t know how to determine parent branch'
- ' from "%s"' % args[1])
- parentbranch = None
+ branchpoint = git.rev_parse(args[1])
+
+ # first, look for branchpoint in well-known branch namespaces
+ for namespace in ('refs/heads/', 'remotes/'):
+ # check if branchpoint exists in namespace
+ try:
+ maybehead = git.rev_parse(namespace + args[1])
+ except git.GitException:
+ maybehead = None
+
+ # check if git resolved branchpoint to this namespace
+ if maybehead and branchpoint == maybehead:
+ # we are for sure referring to a branch
+ parentbranch = namespace + args[1]
+
except git.GitException:
# should use a more specific exception to catch only
# non-git refs ?
out.info('Don\'t know how to determine parent branch'
' from "%s"' % args[1])
- parentbranch = None
+ # exception in branch = rev_parse() leaves branchpoint unbound
+ branchpoint = None
- tree_id = git_id(args[1])
+ tree_id = branchpoint or git_id(args[1])
+
+ if parentbranch:
+ out.info('Recording "%s" as parent branch' % parentbranch)
+ else:
+ out.info('Don\'t know how to determine parent branch'
+ ' from "%s"' % args[1])
else:
# branch stack off current branch
parentbranch = git.get_head_file()
^ permalink raw reply related
* Re: [PATCH] Document git-filter-branch
From: Frank Lichtenheld @ 2007-07-03 22:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707031746400.4071@racer.site>
General note: All the stuff in all uppercase should probably also
have some asciidoc emphasis.
On Tue, Jul 03, 2007 at 05:47:44PM +0100, Johannes Schindelin wrote:
> +DESCRIPTION
> +-----------
> +Lets you rewrite git revision history by creating a new branch from
> +your current branch, applying custom filters on each revision.
> +Those filters can modify each tree (e.g. removing a file or running
> +a perl rewrite on all files) or information about each commit.
> +Otherwise, all information (including original commit times or merge
> +information) will be preserved.
> +
> +The command takes the new branch name as a mandatory argument and
> +the filters as optional arguments. If you specify no filters, the
> +commits will be recommitted without any changes, which would normally
> +have no effect and result in the new branch pointing to the same
> +branch as your current branch. Nevertheless, this may be useful in
> +the future for compensating for some git bugs or such, therefore
> +such a usage is permitted.
> +
> +WARNING! The rewritten history will have different object names for all
> +the objects and will not converge with the original branch. You will not
> +be able to easily push and distribute the rewritten branch on top of the
> +original branch. Please do not use this command if you do not know the
> +full implications, and avoid using it anyway, if a simple single commit
> +would suffice to fix your problem.
> +
> +Always verify that the rewritten version is correct before disposing
> +the original branch.
> +
> +Note that since this operation is extensively I/O expensive, it might
> +be a good idea to redirect the temporary directory it off-disk, e.g. on
^^^^^^
The "it" probably doesn't belong there.
> +tmpfs. Reportedly the speedup is very noticeable.
> +
> +
> +Filters
> +~~~~~~~
> +
> +The filters are applied in the order as listed below. The <command>
> +argument is always evaluated in shell using the 'eval' command.
> +The $GIT_COMMIT environment variable is permanently set to contain
^^^^^^^^^^^
I find the use of this word in this context odd and a little confusing.
Maybe better "always" or "each time"?
> +the id of the commit being rewritten. The author/committer environment
> +variables are set before the first filter is run.
Maybe give the actual names of the environment variables here?
> +A 'map' function is available that takes an "original sha1 id" argument
> +and outputs a "rewritten sha1 id" if the commit has been already
> +rewritten, fails otherwise; the 'map' function can return several
> +ids on separate lines if your commit filter emitted multiple commits.
> +
> +
> +OPTIONS
> +-------
> +
> +--env-filter <command>::
> + This is the filter for modifying the environment in which
> + the commit will be performed. Specifically, you might want
> + to rewrite the author/committer name/email/time environment
> + variables (see gitlink:git-commit[1] for details). Do not forget
> + to re-export the variables.
> +
> +--tree-filter <command>::
> + This is the filter for rewriting the tree and its contents.
> + The argument is evaluated in shell with the working
> + directory set to the root of the checked out tree. The new tree
> + is then used as-is (new files are auto-added, disappeared files
> + are auto-removed - .gitignore files nor any other ignore rules
> + HAVE NO EFFECT!).
Is "nor" correct here? Not just "or"?
[...]
> +--subdirectory-filter <directory>::
> + Only regard the history, as seen by the given subdirectory. The
^^^
Does this comma belong there?
> + result will contain that directory as its project root.
> +
> +-d <directory>::
> + Use this option to set the path to the temporary directory used for
> + rewriting. When applying a tree filter, the command needs to
> + temporary checkout the tree to some directory, which may consume
> + considerable space in case of large projects. By default it
> + does this in the '.git-rewrite/' directory but you can override
> + that choice by this parameter.
> +
> +<rev-list-options>::
> + When options are given after the new branch name, they will
> + be passed to gitlink:git-rev-list[1]. Only commits in the resulting
> + output will be filtered, although the filtered commits can still
> + reference parents which are outside of that set.
> +
> +
> +Examples
> +--------
> +
> +Suppose you want to remove a file (containing confidential information
> +or copyright violation) from all commits:
> +
> +-------------------------------------------------------
> +git filter-branch --tree-filter 'rm filename' newbranch
> +-------------------------------------------------------
> +
> +A significantly faster version:
> +
> +-------------------------------------------------------------------------------
> +git filter-branch --index-filter 'git update-index --remove filename' newbranch
> +-------------------------------------------------------------------------------
Even if your code goes beyond 80 chars, the surrounding "---" doesn't
have to and makes it even harder to read when reading the original
asciidoc text.
> +
> +Now, you will get the rewritten history saved in the branch 'newbranch'
> +(your current branch is left untouched).
> +
> +To "etch-graft" a commit to the revision history (set a commit to be
> +the parent of the current initial commit and propagate that):
> +
> +----------------------------------------------------------------------
> +git filter-branch --parent-filter sed\ 's/^$/-p <graft-id>/' newbranch
> +----------------------------------------------------------------------
Wouldn't have 'sed s/^$/-p <graft-id>/' exactly the same effect, since
the quotes are interpreted by the original shell anyway and not the
filter shell? Just wondering why it uses such a complicated way to
express it.
> +(if the parent string is empty - therefore we are dealing with the
> +initial commit - add graftcommit as a parent). Note that this assumes
> +history with a single root (that is, no merge without common ancestors
> +happened). If this is not the case, use:
> +
[...]
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [BUG] gitk fails with argument that is both existing directory and branch name
From: Johannes Schindelin @ 2007-07-03 21:55 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20070703202301.GA24071@informatik.uni-freiburg.de>
Hi,
On Tue, 3 Jul 2007, Uwe Kleine-K?nig wrote:
> zeisberg@cassiopeia:~/gsrc/linux-2.6$ git rev-list ^linus/master fixes
> fatal: ambiguous argument 'fixes': both revision and filename
> Use '--' to separate filenames from revisions
>
> but
>
> gitk ^linus/master fixes --
Umm. Why don't you just use gitk linus/master..fixes? This is how we teach
people to use rev-list anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: Re: being nice to patch(1)
From: Andrew Morton @ 2007-07-03 21:03 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: quilt-dev, Linus Torvalds, git
In-Reply-To: <200707031534.47004.agruen@suse.de>
On Tue, 3 Jul 2007 15:34:46 +0200 Andreas Gruenbacher <agruen@suse.de> wrote:
> On Tuesday 03 July 2007 02:28, Linus Torvalds wrote:
> > So I would suggest that in quilt and other systems, you either:
> >
> > - strip all headers manually
> >
> > - forget about "patch", and use "git-apply" instead that does things
> > right and doesn't screw up like this (and can do rename diffs etc too).
> >
> > I guess the second choice generally isn't an option, but dammit,
> > "git-apply" really is the better program here.
>
> I'm in bit of a conflict with choice one: when applying patches in an
> automated build process or similar, the likely way to do so is a simple loop
> over the series file. So the less magic when applying patches with quilt, the
> better.
>
> Turning off the insane heuristic with patch -u will do well enough I hope.
> Quilt does not use that option by default because it also supports context
> diffs (some people / projects prefer them), but that can easily be customized
> in .quiltrc:
>
> QUILT_PATCH_OPTS=-u
>
I guess one could try `patch -p1' and if that failed, `patch -p1 -u'.
But the problem is that patch will get stuck in interactive mode prompting
for a filename. I've never actually worked how to make patch(1) just fail
rather than going interactive, not that I've tried terribly hard. Any
hints there?
Thanks.
^ permalink raw reply
* Re: Re: being nice to patch(1)
From: Andrew Morton @ 2007-07-03 21:03 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: quilt-dev, Linus Torvalds, git
In-Reply-To: <200707031803.15633.agruen@suse.de>
On Tue, 3 Jul 2007 18:03:15 +0200 Andreas Gruenbacher <agruen@suse.de> wrote:
> On Tuesday 03 July 2007 17:49, Andrew Morton wrote:
> > I guess one could try `patch -p1' and if that failed, `patch -p1 -u'.
>
> Hmm, I'll think about that, thanks.
>
> > But the problem is that patch will get stuck in interactive mode prompting
> > for a filename. I've never actually worked how to make patch(1) just fail
> > rather than going interactive, not that I've tried terribly hard. Any
> > hints there?
>
> Patch -f will turn off those questions.
>
darnit, both `-f' and `-t' work. Sigh. I blame the manpage: too long ;)
Incidentally, the offending patch
(http://userweb.kernel.org/~akpm/git-scsi-misc.patch) sends patch(1) into
an infinite loop with `patch -p1 -f' and `patch -p1 -t'. Presumably
it will do the same when that patch is offered to quilt...
^ permalink raw reply
* Wrapper scripts to help git-cvsimport cope with cvs 1.12 breakage
From: Yann Dirson @ 2007-07-03 21:43 UTC (permalink / raw)
To: GIT list
[-- Attachment #1: Type: text/plain, Size: 667 bytes --]
Some of you may have noticed that cvs 1.12.x has a bad habit, when a
file gets added on a branch, of creating a dummy 1.x.2.1 revision of
the empty file on the branch. What's annoying, is that the dummy
revision gets an erroneous timestamp, which makes the cvsps output
wrong, following the well-known GIGO principle.
Until someone (maybe me, but I can give no guaranty whatsoever) finds
the time to deal with this bug in cvsps, as well as avoiding at the
cvsps level the extra "file initially added on branch" dummy
revisions, here is a little perl filter that sanitizes the csvps
output, and a customizable git-cvsimport wrapper using it.
Best regards,
--
Yann
[-- Attachment #2: cvsps-filter --]
[-- Type: text/plain, Size: 1137 bytes --]
#!/usr/bin/perl
use strict;
use warnings;
$/='---------------------';
our @branches = qw/HEAD/;
our %parents = (); # parents not yet recorded
# parsing state
our $patchset_is_valid;
our $patchset;
while(<>) {
$patchset = $_;
# skip first separator line
if ($patchset eq $/) {
print $patchset;
next;
}
$patchset_is_valid = 1;
my ($branch, $ancestor);
if (m/^Branch: (.*)/m) {
$branch = $1;
if (!grep { $_ eq $branch } @branches) {
push @branches, $branch;
}
} else {
die "no branch in $patchset";
}
if (m/^Ancestor branch: (.*)/m) {
$ancestor = $1;
if (!grep { $_ eq $ancestor } @branches or
m/^file .* was added on branch /m) {
print STDERR "preparing $branch fixup\n";
$patchset_is_valid = 0;
$parents{$branch} = $ancestor;
}
}
if (m/^file .* was added on branch /m) {
$patchset_is_valid = 0;
}
if (defined $parents{$branch} and $patchset_is_valid) {
print STDERR "finalizing $branch fixup\n";
my $line = 'Ancestor branch: ' . $parents{$branch} . "\n";
$patchset =~ s/^(?=Tag:)/$line/m;
delete $parents{$branch};
}
[-- Attachment #3: fetch-from-cvs.sh --]
[-- Type: application/x-sh, Size: 252 bytes --]
^ permalink raw reply
* Re: being nice to patch(1)
From: Linus Torvalds @ 2007-07-03 21:35 UTC (permalink / raw)
To: Paul Eggert
Cc: Theodore Tso, quilt-dev, Johannes Schindelin, Paolo Ciarrocchi,
Junio C Hamano, Andrew Morton, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0707031422201.9434@woody.linux-foundation.org>
On Tue, 3 Jul 2007, Linus Torvalds wrote:
>
> But maybe you can use this patch as a starting point, at least.
Oh, Paul - I forgot to mention, and since it wasn't necessarily clear from
the patch..
I used the patch-2.5.9 sources as a base for this. I don't know how
official that source base is, I picked it up from a Debian package as the
"original tar-ball": patch_2.5.9.orig.tar.gz
I suspect it applies to just about any version of patch with no
modifications, but just to clarify what the base was. Judging by the
ChangeLog, you're the one who has been doing the later 2.5.x releases even
though the last version on the GNU sites is 2.5.4.
Confusing.
Linus
^ permalink raw reply
* Re: being nice to patch(1)
From: Linus Torvalds @ 2007-07-03 21:30 UTC (permalink / raw)
To: Paul Eggert
Cc: Theodore Tso, quilt-dev, Johannes Schindelin, Paolo Ciarrocchi,
Junio C Hamano, Andrew Morton, Git Mailing List
In-Reply-To: <87zm2dxl5l.fsf@penguin.cs.ucla.edu>
On Tue, 3 Jul 2007, Paul Eggert wrote:
>
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > Anyway, I tried to look at the patch sources, but I had to stop. That
> > whole "intuit_diff_type()" function is probably designed as an initiation
> > rite for any patch programmers, and to make sure that you have to be
> > really serious about wanting to send patches before you can become part of
> > the "in crowd". It's "mental hazing".
>
> You should have seen it in the good old days when Larry Wall wrote it.
> It was at least -- at least! -- 10% worse.
Heh.
Anyway, I figured out a sane way to do this - I had been thinking about it
all wrong. Instead of worrying about all the places that change (and look
at) "p_indent" - which is the real variable - I just made it not calculate
"indent" in the first place.
That makes it catch it all in one place, and then quite naturally ignore
any indented hunks because it won't recognize them as patches any more. At
least I _think_ so, from just reading the source code.
So a patch like the following may or may not work. It compiles, but quite
frankly, while it makes sense and worked for the single test-case I
bothered with, somebody should double-check the logic.
> > In this case, the improvement would be to simply ignore indented patches
> > (preferably by default, but at least have the option to do so).
>
> I agree. POSIX has tied our hands to some extent, though, since it
> _requires_ patch to accept indented patches by default. It's too late
> to fix this in the current POSIX go-round, but we can fix it in the
> next. And in the mean time we can add an option, I suppose defaulting
> to not stripping indentation unless POSIXLY_CORRECT is set. That
> would be fine with me.
>
> I'll add it to my list of things to do.
Ok, so this doesn't do the POSIXLY_CORRECT thing, and you may not agree
with the flag name either ("--strip-indent" is a lot of characters to
write, but I thought it was so esoteric that I think it's ok. I never even
realized "patch" would ever do something as strange as that, and I'm
hoping a lot of other people didn't realize either, so that changing this
isn't going to matter, and very few people would hopefully ever need to
use the "--strip-indent" flag).
But maybe you can use this patch as a starting point, at least.
(And if you wonder why I put the "if (!strip_indentation)" thing inside
the loop, even though it doesn't ever change in the loop: it generated a
smaller patch, and I didn't want to re-indent that code and make it even
worse. So the logic is kind of stupid, but whatever..)
Linus
---
diff --git a/common.h b/common.h
index c7fc5c2..45fecdc 100644
--- a/common.h
+++ b/common.h
@@ -174,6 +174,7 @@ XTERN bool canonicalize;
XTERN int patch_get;
XTERN bool set_time;
XTERN bool set_utc;
+XTERN bool strip_indentation;
enum diff
{
diff --git a/patch.c b/patch.c
index 9e04daf..6e25d2a 100644
--- a/patch.c
+++ b/patch.c
@@ -522,6 +522,7 @@ static struct option const longopts[] =
{"no-backup-if-mismatch", no_argument, NULL, CHAR_MAX + 6},
{"posix", no_argument, NULL, CHAR_MAX + 7},
{"quoting-style", required_argument, NULL, CHAR_MAX + 8},
+ {"strip-indent", no_argument, NULL, CHAR_MAX + 9},
{NULL, no_argument, NULL, 0}
};
@@ -580,6 +581,7 @@ static char const *const option_help[] =
" --verbose Output extra information about the work being done.",
" --dry-run Do not actually change any files; just print what would happen.",
" --posix Conform to the POSIX standard.",
+" --strip-indent handle indented patches.",
"",
" -d DIR --directory=DIR Change the working directory to DIR first.",
#if HAVE_SETMODE_DOS
@@ -779,6 +781,9 @@ get_some_switches (void)
(enum quoting_style) i);
}
break;
+ case CHAR_MAX + 9: /* --strip-indent */
+ strip_indentation = true;
+ break;
default:
usage (stderr, 2);
}
diff --git a/pch.c b/pch.c
index d98af86..fcb08c5 100644
--- a/pch.c
+++ b/pch.c
@@ -345,6 +345,8 @@ intuit_diff_type (void)
}
strip_trailing_cr = 2 <= chars_read && buf[chars_read - 2] == '\r';
for (s = buf; *s == ' ' || *s == '\t' || *s == 'X'; s++) {
+ if (!strip_indentation)
+ break;
if (*s == '\t')
indent = (indent + 8) & ~7;
else
^ permalink raw reply related
* Re: being nice to patch(1)
From: Paul Eggert @ 2007-07-03 20:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Tso, Paolo Ciarrocchi, Johannes Schindelin,
Junio C Hamano, Andrew Morton, Git Mailing List, quilt-dev
In-Reply-To: <alpine.LFD.0.98.0707031159580.9434@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Anyway, I tried to look at the patch sources, but I had to stop. That
> whole "intuit_diff_type()" function is probably designed as an initiation
> rite for any patch programmers, and to make sure that you have to be
> really serious about wanting to send patches before you can become part of
> the "in crowd". It's "mental hazing".
You should have seen it in the good old days when Larry Wall wrote it.
It was at least -- at least! -- 10% worse.
> In this case, the improvement would be to simply ignore indented patches
> (preferably by default, but at least have the option to do so).
I agree. POSIX has tied our hands to some extent, though, since it
_requires_ patch to accept indented patches by default. It's too late
to fix this in the current POSIX go-round, but we can fix it in the
next. And in the mean time we can add an option, I suppose defaulting
to not stripping indentation unless POSIXLY_CORRECT is set. That
would be fine with me.
I'll add it to my list of things to do.
^ permalink raw reply
* [PATCH] glossary: add 'reflog'
From: Johannes Schindelin @ 2007-07-03 20:28 UTC (permalink / raw)
To: git, gitster
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/glossary.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index e903abf..3f7b1e4 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -330,6 +330,12 @@ This commit is referred to as a "merge commit", or sometimes just a
denotes a particular <<def_object,object>>. These may be stored in
`$GIT_DIR/refs/`.
+[[def_reflog]]reflog::
+ A reflog shows the local "history" of a ref. In other words,
+ it can tell you what the 3rd last revision in _this_ repository
+ was, and what was the current state in _this_ repository,
+ yesterday 9:14pm. See gitlink:git-reflog[1] for details.
+
[[def_refspec]]refspec::
A "refspec" is used by <<def_fetch,fetch>> and
<<def_push,push>> to describe the mapping between remote
--
1.5.3.rc0.2640.g59df9-dirty
^ permalink raw reply related
* [BUG] gitk fails with argument that is both existing directory and branch name
From: Uwe Kleine-König @ 2007-07-03 20:23 UTC (permalink / raw)
To: git
Hello,
I have a branch named fixes in my linux repo and until I did:
git format-patch -o fixes linus/master
the following command worked fine:
gitk ^linus/master fixes
but now that there is a directory named fixes, nothing happens when
running gitk. With rev-list I get
zeisberg@cassiopeia:~/gsrc/linux-2.6$ git rev-list ^linus/master fixes
fatal: ambiguous argument 'fixes': both revision and filename
Use '--' to separate filenames from revisions
but
gitk ^linus/master fixes --
doesn't work either. I'd suspect that the call to rev-list doesn't see
the "--" and the error is lost somewhere inbetween ...?
I currently have no time to look into it, so for now you only get a
report.
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=i+squared
^ permalink raw reply
* Re: [PATCH] Add core.pager config variable.
From: Brian Gernhardt @ 2007-07-03 19:50 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Johannes Schindelin
In-Reply-To: <200707032142.07154.robin.rosenberg.lists@dewire.com>
On Jul 3, 2007, at 3:42 PM, Robin Rosenberg wrote:
> Nak.
>
> PAGER cannot override core.pager with this.
core.pager is acting exactly like GIT_PAGER. The priority goes (from
pager.c:30):
GIT_PAGER
core.pager
PAGER
"less"
I think this is a desirable option because I'd like to tell all other
programs to use less and tell git to use tig (which I'm trying out).
I specifically want core.pager to override PAGER, but this leaves
GIT_PAGER as the final override. Why should I export an environment
variable to every program when git has a configuration file? And
what does overriding PAGER break? If the user doesn't want to use
core.pager, they don't have to.
~~ Brian
^ permalink raw reply
* Re: being nice to patch(1)
From: Linus Torvalds @ 2007-07-03 19:48 UTC (permalink / raw)
To: Theodore Tso
Cc: Paolo Ciarrocchi, Johannes Schindelin, Junio C Hamano,
Andrew Morton, Git Mailing List, quilt-dev, Paul Eggert
In-Reply-To: <20070703183947.GE5322@thunk.org>
[ Paul Eggert added to Cc: I'm not sure he actually maintains "patch"
or cares any more, but hopefully he at least knows who does ]
On Tue, 3 Jul 2007, Theodore Tso wrote:
>
> Or people could submit a bug report/feature request/patch to the
> patch(1) maintainer. :-)
Is there such a thing?
The latest official version of patch from GNU is 2.5.4 from 1999, I think.
I'm finding references to 2.5.9 in distributions (from 2003), but 2.5.4 is
the latest I see on the GNU mirror at kernel.org, and that's also what
Fedora 7 has too, it seems, so the 2.5.9 thing seems to be something
unofficial or at least not widely known about..
Anyway, I tried to look at the patch sources, but I had to stop. That
whole "intuit_diff_type()" function is probably designed as an initiation
rite for any patch programmers, and to make sure that you have to be
really serious about wanting to send patches before you can become part of
the "in crowd". It's "mental hazing".
Yeah, git-apply sources aren't necessarily a thing of great beauty either,
but in comparison to patch, I think it's a work of art. Of course, part of
it is that it doesn't try to parse 'ed' scripts etc, but a large part of
it really is that "patch" is an old program that has grown over time, and
not seen a lot of cleanups, I suspect.
IOW, I tried to see how easy it would be to dismiss the code that
takes care of "indent", but it wasn't totally obvious. It's set in many
different places, and the logic for "skip_this_patch" is a bit confusing.
Anyway, with Paul Eggert Cc'd, maybe he can help us sort it out.
Paul - the issue here isn't actually with git at all, but the fact that
Andrew Morton noticed that he cannot apply one of the series of patches he
has with "patch" (well, with his scripts that are designed _around_
patch, to be exact).
The reason? Part of the patch *description* looked like this:
[SCSI] 53c700: Amiga 4000T NCR53c710 SCSI
New driver for the Amiga 4000T built-in NCR53c710 SCSI controller, using the
53c700 SCSI core.
where it really *was* indented by four characters (and that's where git
comes in: git indents the patch descriptions exactly so that you cannot
*possibly* confuse the patch itself with the description).
It turns out that "patch" would actually think there is a patch there: the
line
53c700 SCSI core.
was determined to be an ed-script ("53c700") _despite_ the fact that it's
indented.
Andrew was able to fix that particular damage by using "-u" and forcing
anything but unified diffs to be ignored, but that isn't an option for all
quilt users, since some projects use old-fashioned context diffs or a
mixture.
Besides, the explanations can certainly contain patch fragments anyway (in
the kernel, we put things like example code in them).
And it really boils down to a really simple thing: when scripting, you DO
NOT WANT "patch" to make random guesses. And that whole "indentation"
thing by patch is a pure guess, and should simply NOT BE DONE. And there's
no way to tell patch to not do it.
So Paul, you're our only hope.
I'm personally trying to tell people not to use "patch" at all (this isn't
the first time patch has done insane things by default, but it's the first
time you cannot even _disable_ the insane behaviour), but Ted has a point:
regardless of whether people learn to use "git-apply" to apply patches,
the old "patch" binary would be better off just improved.
In this case, the improvement would be to simply ignore indented patches
(preferably by default, but at least have the option to do so).
Linus
^ permalink raw reply
* Re: [PATCH] Add core.pager config variable.
From: Jonas Fonseca @ 2007-07-03 19:48 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git, Johannes Schindelin
In-Reply-To: <20070703181811.GA17966@Hermes.local>
On 7/3/07, Brian Gernhardt <benji@silverinsanity.com> wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 1d96adf..d319359 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -281,6 +281,10 @@ core.excludesfile::
> of files which are not meant to be tracked. See
> gitlink:gitignore[5].
>
> +core.pager::
> + The command that git will use to paginatee output. Can be overridden
> + with the `GIT_PAGER` environment variable.
> +
A typo: paginatee.
--
Jonas Fonseca
^ permalink raw reply
* Re: Problems with git-svnimport
From: Matthias Urlichs @ 2007-07-03 19:45 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706072329020.4046@racer.site>
Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:
> Let's deprecate git-svnimport, once for all.
>
> git-svn should work much better.
>
In other words, you volunteer to fold everything that git-svnimport can do into
git-svn? The last time I checked, neither was a feature-complete subset of the
other...
If so: don't let me hold you back. ;-)
--
Matthias Urlichs
^ permalink raw reply
* Re: [PATCH] Add core.pager config variable.
From: Robin Rosenberg @ 2007-07-03 19:42 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git, Johannes Schindelin
In-Reply-To: <20070703181811.GA17966@Hermes.local>
tisdag 03 juli 2007 skrev Brian Gernhardt:
> This adds a configuration variable that performs the same function as,
> but is overridden by, GIT_PAGER.
[...]
> diff --git a/pager.c b/pager.c
> index 5f280ab..3bfed02 100644
> --- a/pager.c
> +++ b/pager.c
> @@ -32,6 +32,8 @@ void setup_pager(void)
> if (!isatty(1))
> return;
> if (!pager)
> + pager = pager_program;
> + if (!pager)
> pager = getenv("PAGER");
> if (!pager)
> pager = "less";
Nak.
PAGER cannot override core.pager with this.
-- robin
^ permalink raw reply
* git-svnexport
From: Steve French @ 2007-07-03 19:31 UTC (permalink / raw)
To: git
I noticed a git-svnexport, but don't see an easy way to do the more
common task ... export a replica (via svn) of a kernel directory whose
master copy is in git (no changes come through svn, all changes come
through git).
The Samba team (jra and others) use svn and would like me to keep more
uptodate the svn branch (which I sync manually now by applying the
patches from the kernel git tree by hand) for the two cifs git trees.
Basically I need to do something like:
git log fs/cifs
save off each of the commits which hit fs/cifs which are not in the svn tree yet
patch and "svn checkin" each of the commits to the svn tree
Has anyone done any scripts to --- export -- to an svn tree from part
of a git tree?
I don't want to go to having my svn tree as the master and import into
git from svn.
--
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH] repack: don't report "Nothing new to pack." if -q is given
From: Uwe Kleine-König @ 2007-07-03 19:17 UTC (permalink / raw)
To: git
In-Reply-To: <20070703181923.GE4580@xp.machine.xx>
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
---
Peter Baumann wrote:
> On Tue, Jul 03, 2007 at 10:47:58AM +0200, Uwe Kleine-König wrote:
> > exit 1
> > if [ -z "$name" ]; then
> > - echo Nothing new to pack.
> > + if test -q "$quiet"; then
> > + echo Nothing new to pack.
> > + fi
>
> This looks wrong, especially as I can't find a '-q' in the manpage of "test".
> Perhaps you ment something like the following code, which is already used in
> the script:
>
> if test "$quiet" != '-q'; then
> echo ...
> fi
actually I meant test -z "$quiet", but test "$quiet" != '-q' would be
equally good.
Thanks for noticing.
Uwe
git-repack.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index ddfa8b4..1ce2760 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -65,7 +65,9 @@ args="$args $local $quiet $no_reuse_delta$extra"
name=$(git-pack-objects --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
exit 1
if [ -z "$name" ]; then
- echo Nothing new to pack.
+ if test -z "$quiet"; then
+ echo Nothing new to pack.
+ fi
else
chmod a-w "$PACKTMP-$name.pack"
chmod a-w "$PACKTMP-$name.idx"
--
1.5.2.2.1451.gb0e5e
> > Best regards
> > Uwe
> >
> > git-repack.sh | 4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/git-repack.sh b/git-repack.sh
> > index ddfa8b4..d980275 100755
> > --- a/git-repack.sh
> > +++ b/git-repack.sh
> > @@ -65,7 +65,9 @@ args="$args $local $quiet $no_reuse_delta$extra"
> > name=$(git-pack-objects --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
> -Peter
>
--
Uwe Kleine-König
$ dc -e "5735816763073014741799356604682P"
^ permalink raw reply related
* gitk doesn't start due to cygwin wish not following symlinks?
From: Kees-Jan Dijkzeul @ 2007-07-03 19:02 UTC (permalink / raw)
To: git
Hi,
I'm using "stow" to manage several versions of git on my cygwin
system. As a result, my /usr/local/bin contains a bunch of symlinks to
the actual binaries in /usr/local/stow/git-1.5.2.2/bin.
This works like a charm, except that gitk won't start up, claiming, in
turn, that it is unable to start git itself. After some investigation,
I found that the "wish" that is supplied with cygwin isn't a true
cygwin one, and hence doesn't understand cygwin style simlinks, and
thus cannot start the /usr/local/bin/git symlink. It needs the true
binary.
So for now, I've worked around this by updating the first few lines of
the gitk script to read:
#!/bin/sh
# Tcl ignores the next line -*- tcl -*- \
export PATH=$PATH:/usr/local/stow/git-1.5.2.2/bin
# Tcl ignores the next line also \
exec wish "$0" -- "$@"
This works for me, but is admittedly butt-ugly. Any tips on how to
handle this kind of situation?
Thanks a lot!
Groetjes,
Kees-Jan
^ permalink raw reply
* Re: being nice to patch(1)
From: Theodore Tso @ 2007-07-03 18:39 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Johannes Schindelin, Linus Torvalds, Junio C Hamano,
Andrew Morton, git, quilt-dev
In-Reply-To: <4d8e3fd30707030521k6cb3129dy9193344e9e1eccf7@mail.gmail.com>
On Tue, Jul 03, 2007 at 02:21:51PM +0200, Paolo Ciarrocchi wrote:
> >But maybe they would be willing to install git to get that wonderful
> >git-apply program, and that wonderful rename-and-mode-aware git-diff, and
> >the git-merge-file program, all of which can operate outside of a git
> >repository. (Take that, hg!)
>
> How about shipping just these commands as a separate package?
> Is that a cray idea?
Or people could submit a bug report/feature request/patch to the
patch(1) maintainer. :-)
- Ted
^ permalink raw reply
* Re: [PATCH] Add core.pager config variable.
From: Johannes Schindelin @ 2007-07-03 18:39 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <20070703181811.GA17966@Hermes.local>
Hi,
On Tue, 3 Jul 2007, Brian Gernhardt wrote:
> This adds a configuration variable that performs the same function as,
> but is overridden by, GIT_PAGER.
>
> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> ---
>
> Since Johannes agrees, core.pager it is. :-)
Acked-by: Johannes E. Schindelin <johannes.schindelin@gmx.de>
Ciao,
Dscho
^ permalink raw reply
* Re: Starting 1.5.3 stabilization cycle
From: Johannes Schindelin @ 2007-07-03 18:27 UTC (permalink / raw)
To: Peter Baumann; +Cc: Junio C Hamano, git
In-Reply-To: <20070703181428.GD4580@xp.machine.xx>
Hi,
On Tue, 3 Jul 2007, Peter Baumann wrote:
> On Tue, Jul 03, 2007 at 12:29:32AM -0700, Junio C Hamano wrote:
>
> > - "git rebase" learned an "interactive" mode.
>
> Short describtion missing?
s/b/p/ ;-)
> This is meant for reordering the commits, merge several commits into
> one or even remove some of them.
Or even better:
- "git rebase" learned an "interactive" mode, where you can pick
and reorder the commits to be applied.
> > - "git-filter-branch" is a reborn cg-admin-rewritehist.
>
> Better mention what it is for, e.g:
>
> Lets you rewrite GIT revision history by applying custom filters
> on each revision. Those filters can modify each tree or
> information about each commit.
I never liked that description. How about (shameless plug) the description
from my last patch:
git-filter-branch lets you rewrite the revision history of the
current branch, creating a new branch. You can specify a number of
filters to modify the commits, files and trees.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] repack: don't report "Nothing new to pack." if -q is given
From: Peter Baumann @ 2007-07-03 18:19 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20070703084757.GA4694@lala>
On Tue, Jul 03, 2007 at 10:47:58AM +0200, Uwe Kleine-König wrote:
> Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
> ---
> This patch is on top of maint. For master and next you need
> s/name/names/.
>
> Best regards
> Uwe
>
> git-repack.sh | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/git-repack.sh b/git-repack.sh
> index ddfa8b4..d980275 100755
> --- a/git-repack.sh
> +++ b/git-repack.sh
> @@ -65,7 +65,9 @@ args="$args $local $quiet $no_reuse_delta$extra"
> name=$(git-pack-objects --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
> exit 1
> if [ -z "$name" ]; then
> - echo Nothing new to pack.
> + if test -q "$quiet"; then
> + echo Nothing new to pack.
> + fi
This looks wrong, especially as I can't find a '-q' in the manpage of "test".
Perhaps you ment something like the following code, which is already used in
the script:
if test "$quiet" != '-q'; then
echo ...
fi
-Peter
^ permalink raw reply
* [PATCH] Add core.pager config variable.
From: Brian Gernhardt @ 2007-07-03 18:18 UTC (permalink / raw)
To: git, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0707031729370.4071@racer.site>
This adds a configuration variable that performs the same function as,
but is overridden by, GIT_PAGER.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
Since Johannes agrees, core.pager it is. :-)
Documentation/config.txt | 4 ++++
cache.h | 1 +
config.c | 5 +++++
environment.c | 1 +
| 2 ++
5 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1d96adf..d319359 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -281,6 +281,10 @@ core.excludesfile::
of files which are not meant to be tracked. See
gitlink:gitignore[5].
+core.pager::
+ The command that git will use to paginatee output. Can be overridden
+ with the `GIT_PAGER` environment variable.
+
alias.*::
Command aliases for the gitlink:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
diff --git a/cache.h b/cache.h
index 0d23a25..e64071e 100644
--- a/cache.h
+++ b/cache.h
@@ -546,6 +546,7 @@ extern int write_or_whine_pipe(int fd, const void *buf, size_t count, const char
/* pager.c */
extern void setup_pager(void);
+extern char *pager_program;
extern int pager_in_use;
extern int pager_use_color;
diff --git a/config.c b/config.c
index 4de8926..561ee3b 100644
--- a/config.c
+++ b/config.c
@@ -387,6 +387,11 @@ int git_default_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.pager")) {
+ pager_program = xstrdup(value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index 1c2773f..f83fb9e 100644
--- a/environment.c
+++ b/environment.c
@@ -30,6 +30,7 @@ int core_compression_seen;
size_t packed_git_window_size = DEFAULT_PACKED_GIT_WINDOW_SIZE;
size_t packed_git_limit = DEFAULT_PACKED_GIT_LIMIT;
size_t delta_base_cache_limit = 16 * 1024 * 1024;
+char *pager_program;
int pager_in_use;
int pager_use_color = 1;
int auto_crlf = 0; /* 1: both ways, -1: only when adding git objects */
--git a/pager.c b/pager.c
index 5f280ab..3bfed02 100644
--- a/pager.c
+++ b/pager.c
@@ -32,6 +32,8 @@ void setup_pager(void)
if (!isatty(1))
return;
if (!pager)
+ pager = pager_program;
+ if (!pager)
pager = getenv("PAGER");
if (!pager)
pager = "less";
--
1.5.3.rc0
^ 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