* Re: How to create & switch to a branch after changes have already been made?
From: Patrick Doyle @ 2007-07-03 14:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707031210020.4071@racer.site>
The real problem was that I did a
$ git-mv somefile somefile.new
and then created a new version of "somefile". When I temporarily
renamed it, all of the given suggestions worked. Thanks.
--wpd
^ permalink raw reply
* Re: Can git-svn treat specify paths as branches ?
From: Dongsheng Song @ 2007-07-03 14:11 UTC (permalink / raw)
To: Jeffrey C. Ollie; +Cc: git
In-Reply-To: <1183467196.3868.1.camel@lt21223.campus.dmacc.edu>
Thanks, it works.
2007/7/3, Jeffrey C. Ollie <jeff@ocjtech.us>:
> On Tue, 2007-07-03 at 17:12 +0800, Dongsheng Song wrote:
> > For google code projects, the repositories organized is:
> >
> > branches tags trunk wiki
> >
> > Can I treat wiki as a branch? i.e.
> >
> > [svn-remote "svn"]
> > url = http://serf.googlecode.com/svn
> > fetch = trunk:refs/remotes/trunk
> > branches = branches/*,wiki:refs/remotes/*
> > tags = tags/*:refs/remotes/tags/*
>
> What's the structure underneath the wiki directory? If it's just
> content, I'd use:
>
> fetch = wiki:refs/remotes/wiki
>
> Jeff
>
>
>
^ permalink raw reply
* Re: [Bug?] compiler warning with gcc >= 4.2
From: Nicolas Pitre @ 2007-07-03 14:18 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List
In-Reply-To: <20070703125844.GL12721@planck.djpig.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1850 bytes --]
On Tue, 3 Jul 2007, Frank Lichtenheld wrote:
> Hi,
>
> while testing for an (probably) unrelated miscompilation bug,
> I got the following warning while compiling git:
>
> gcc-4.2 -o sha1_file.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>'
> -DETC_GITCONFIG='"/home/djpig/etc/gitconfig"' -DNO_STRLCPY sha1_file.c
> sha1_file.c: In function ‘check_packed_git_idx’:
> sha1_file.c:523: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false
> sha1_file.c:523: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false
>
> This comes from the new -Wstrict-overflow which warns about the fact
> that with -fstrict-overflow, which is activated by default with -O2,
> the if clause referenced in the warning will be optimised away.
>
> So I would be interested to know
> a) if the compiler optimising this check away (which seems to be a check
> about whether signed overflow can occour) can lead to unwanted results
Of course it can if the compiler blindly optimizes the test away.
In this particular case, the answer can be determined at compile time
though, since all values to perform the test are constants. So in this
case the warning is rather obnoxious.
However it would be completely wrong if the compiler optimized away the
if from index-pack.c on line 104, or from builtin-pack-objects.c on line
579. Even warning about it without actually optimizing it away would be
bad in those cases.
> b) if not a), if it would make sense trying to suppress that warning, so
> that other people don't end up wondering the same as me
I really wonder what's the point for gcc to warn about such things.
Sure the warning should go away, but not by compromizing the test that
we need performed on the actual definition of off_t.
Nicolas
^ permalink raw reply
* Re: git-rm isn't the inverse action of git-add
From: Johannes Schindelin @ 2007-07-03 14:21 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Yann Dirson, Christian Jaeger, git
In-Reply-To: <vpqir91hagz.fsf@bauges.imag.fr>
Hi,
On Tue, 3 Jul 2007, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Tue, 3 Jul 2007, Matthieu Moy wrote:
> >
> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >>
> >> > What's so wrong with our man pages? You know, there have been man
> >> > hours invested in them, and they are exclusively meant for
> >> > consumption by people who do not know about the usage of the
> >> > commands...
> >>
> >> What's wrong is just that I shouldn't have to read a man page to
> >> avoid data-loss.
> >
> > Okay, Mr Moy.
>
> Glad to be called by my name. Is it a tradition here, or a way to make
> fun of me?
I tried to be funny, by introducing some diversity...
> > How did you learn that "rm" leads to data-loss? Because it does.
>
> It obviously does, and I can't imagine any other behavior than deleting
> the file for a command like "rm".
>
> > Hmm. How did you expect then, that git-rm does _not_ lead to data
> > loss?
>
> Because there are tons of possible behaviors for "$VCS rm", and I'd
> expect it to be safe even if VCS=git, since it is with all the other VCS
> I know.
Which proves exactly my point. There are a ton of interpretations that
make sense. So I would always look into the man page.
> What's wrong with the behavior of "hg rm"?
> What's wrong with the behavior of "svn rm"?
> What's wrong with the behavior of "bzr rm"?
> (no, I won't do it with CVS ;-) )
>
> None of these commands have the problem that git-rm has.
Guess what. I do not know how they operate! I have no idea what the
behaviour of the commands you mentioned is. So before I would answer (if
they were not rethoric questions), I would actually really read the man
page to know what they are supposed to do.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] stash: end commit log with a newline
From: Jeff King @ 2007-07-03 14:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Uwe Kleine-König, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707031228460.4071@racer.site>
On Tue, Jul 03, 2007 at 12:29:42PM +0100, Johannes Schindelin wrote:
> Why not
>
> w_commit=$(echo "WIP on $msg" |
>
> Hmm? It is shorter and more to the point. IMHO it is also more common.
Because echo cannot reliably reproduce arbitrary strings. See commits:
a23bfaed..4b7cc26a
You can add this to your list of reasons to rewrite everything in C.
-Peff
^ permalink raw reply
* Re: being nice to patch(1)
From: David Kastrup @ 2007-07-03 13:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: quilt-dev, git
In-Reply-To: <Pine.LNX.4.64.0707031437560.4071@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi David,
>
> [please Cc me, since I will be more likely to miss replies if you do not]
>
> On Tue, 3 Jul 2007, David Kastrup wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > 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!)
>>
>> As long as git-diff lists all added files in a second non-git dirtree
>> as "/dev/null" when doing
>> git-diff --name-status -B -M -C dir1 dir2
>> its usefulness is limited.
>>
>> git-diff --name-status -B -M -C dir1 dir2
>> D dir1/auctex-11.84/CHANGES
>> D dir1/auctex-11.84/COPYING
>> D dir1/auctex-11.84/ChangeLog
>>
>> [...]
>
> Yes, directories are a problem. There our DWIMery does not really help.
> But there is a solution: say
>
> git diff --name-status --no-index -B -M -C dir1 dir2
It would help if you actually read what you are replying to. The
problem is that added files are listed as "/dev/null", and --no-index
does not make a difference here. It actually makes no apparent
difference at all when outside of a non-git dirtree. Hardly
surprising, since no index file that could be consulted is present in
the first place.
The output still is (editing somewhat more so that it becomes even
more obvious):
git-diff -B -M -C --no-index --name-status dir1 dir2
D dir1/auctex-11.84/CHANGES
[...]
A /dev/null
A /dev/null
R100 dir1/auctex-11.84/images/amstex.xpm dir2/etc/auctex/images/amstex.xpm
[...]
_All_ lines starting in A end with /dev/null.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] git-repack: generational repacking (and example hook script)
From: Nicolas Pitre @ 2007-07-03 14:45 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git
In-Reply-To: <4689D77D.20601@vilain.net>
On Tue, 3 Jul 2007, Sam Vilain wrote:
> Nicolas Pitre wrote:
> >> Add an option to git-repack that makes the repack run suitable for
> >> running very often. The idea is that packs get given a "generation",
> >> and that the number of packs in each generation (except the last one)
> >> is bounded.
> >
> > Please explain again why this should be useful and is worth the
> > complexity it brings along. Last time this was discussed I wasn't
> > convinced at all, and I'm still not convinced this time either.
>
> First I think we should establish some common ground.
>
> 1. Do you agree that some users would want their git repositories to be
> "maintenance free"?
I'm not so sure. I think it is best to let GIT users know (or the
admins on their behalf) how to properly maintain their repository than
pretending that it needs no maintenance. GIT is a tool for "developers"
after all, not for Aunt Tillie.
And even if your developers are completely inept to the point of not
wanting to run 'git gc' once a week for example, or once a day if
they're otherwise really really productive, I'm sure you can automate
some of that maintenance asynchronously from a simple post commit hook
or something, based on the output of 'git count-objects -v'.
> 2. Do you agree that having thousands of packs would add measurable
> overhead?
Sure it would, but far less as it used to when we last discussed this
since performances in those cases has been improved significantly.
And if you end up with thousands of packs in the first place I think you
have a more fundamental problem to fix, something that generational
repacking would just paper over.
Nicolas
^ permalink raw reply
* [TIG PATCH] Ignore generated manpages.
From: Brian Gernhardt @ 2007-07-03 14:50 UTC (permalink / raw)
To: git, Jonas Fonseca
Adds tig.1 and tigrc.5 to .gitignore
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
A simple change that will help me from committing man pages by
accident. ;-)
.gitignore | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index f7ab840..9bc5de5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,5 @@ manual.toc
tig
tig.spec
tig-*.tar.gz
+tig.1
+tigrc.5
--
1.5.3.rc0
^ permalink raw reply related
* Re: [PATCH] git-repack: generational repacking (and example hook script)
From: Shawn O. Pearce @ 2007-07-03 14:55 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sam Vilain, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999.0707031020300.26459@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> And even if your developers are completely inept to the point of not
> wanting to run 'git gc' once a week for example, or once a day if
> they're otherwise really really productive, I'm sure you can automate
> some of that maintenance asynchronously from a simple post commit hook
> or something, based on the output of 'git count-objects -v'.
Yea, you need not just the loose object count but also the number
of packfiles. git-gui suggests repacking based on loose object
count alone right now, but with us keeping fetched packfiles by
git-index-pack I found a repository on my desktop the other day
that had 30 packfiles in it. I need to fix that in git-gui and
also add a limit based on the number of small-ish packfiles present.
BTW, I have some users that might as well be Aunt Tillie. They
merge any branch they can find. "Oh, look, there's a new branch
called Highly-Experimental! I'll bet that's good for merging too!"
Asking them to also run git-gc once in a while is like asking them
to actually do their job or something... *sighs* OK, I have to go
to work and undo that Highly-Experimental merge I found last night.
*sigh*
--
Shawn.
^ permalink raw reply
* [PATCH] diff --no-index: fix --name-status with added files
From: Johannes Schindelin @ 2007-07-03 15:01 UTC (permalink / raw)
To: David Kastrup; +Cc: git, gitster
In-Reply-To: <86hcolr3sb.fsf@lola.quinscape.zz>
Without this patch, an added file would be reported as /dev/null.
Noticed by David Kastrup.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Would be nice, next time, to have a bug report which is not
embedded in a thread.
diff.c | 3 ++-
t/t4013-diff-various.sh | 2 ++
t/t4013/diff.diff_--name-status_dir2_dir | 3 +++
3 files changed, 7 insertions(+), 1 deletions(-)
create mode 100644 t/t4013/diff.diff_--name-status_dir2_dir
diff --git a/diff.c b/diff.c
index b6eb72b..1958970 100644
--- a/diff.c
+++ b/diff.c
@@ -2418,7 +2418,8 @@ static void diff_flush_raw(struct diff_filepair *p,
printf("%s ",
diff_unique_abbrev(p->two->sha1, abbrev));
}
- printf("%s%c%s", status, inter_name_termination, path_one);
+ printf("%s%c%s", status, inter_name_termination,
+ two_paths || p->one->mode ? path_one : path_two);
if (two_paths)
printf("%c%s", inter_name_termination, path_two);
putchar(line_termination);
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index b453b42..9eec754 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -17,6 +17,7 @@ test_expect_success setup '
export GIT_AUTHOR_DATE GIT_COMMITTER_DATE &&
mkdir dir &&
+ mkdir dir2 &&
for i in 1 2 3; do echo $i; done >file0 &&
for i in A B; do echo $i; done >dir/sub &&
cat file0 >file2 &&
@@ -254,6 +255,7 @@ diff --patch-with-stat initial..side
diff --patch-with-raw initial..side
diff --patch-with-stat -r initial..side
diff --patch-with-raw -r initial..side
+diff --name-status dir2 dir
EOF
test_done
diff --git a/t/t4013/diff.diff_--name-status_dir2_dir b/t/t4013/diff.diff_--name-status_dir2_dir
new file mode 100644
index 0000000..ef7fdb7
--- /dev/null
+++ b/t/t4013/diff.diff_--name-status_dir2_dir
@@ -0,0 +1,3 @@
+$ git diff --name-status dir2 dir
+A dir/sub
+$
--
1.5.3.rc0.2637.g1dd84-dirty
^ permalink raw reply related
* Re: being nice to patch(1)
From: Johannes Schindelin @ 2007-07-03 15:01 UTC (permalink / raw)
To: David Kastrup; +Cc: quilt-dev, git
In-Reply-To: <86hcolr3sb.fsf@lola.quinscape.zz>
Hi,
On Tue, 3 Jul 2007, David Kastrup wrote:
> It would help if you actually read what you are replying to.
Actually, your second explanation helped. Fix posted separately.
Ciao,
Dscho
^ permalink raw reply
* Re: pushing a project started in git back to a subversion repository...
From: Patrick Doyle @ 2007-07-03 15:06 UTC (permalink / raw)
To: Jeff King, git
In-Reply-To: <20070703142633.GC18597@coredump.intra.peff.net>
Oh dear, I just noticed that my previous reply was to you directly,
instead of the list at large.
On 7/3/07, Jeff King <peff@peff.net> wrote:
> On Tue, Jul 03, 2007 at 09:56:06AM -0400, Patrick Doyle wrote:
>
> > I started off with something like this -- actually, I tried "git-pull"
> > as well as "git-fetch", but in each case I ended up with a single
> > commit in the SVN repository with a log message reading something like
> > "merged ../path/to/original" instead of multiple commits, tracking the
> > log messages from the original repository.
>
> git-pull is the equivalent of git-fetch followed by a merge. But you
> don't want to do the merge, since you are going to graft. So you
> definitely don't want to pull. However, the merge should have all of the
> original commits in it, unless git-svn is somehow squashing the merge
> down into a single commit.
>
I thought that the git-merge implicit in "git-pull" is what was
squashing the merge down into a single commit. Nowadays, when I try a
"git-pull" from my unrelated repository followed by a "git-svn
dcommit", I get an error (from the dcommit command) that it is unable
to extract revision information from one of the commits in the chain.
>
> > I found I needed to do "git-branch -D original", which makes me think
> > that either I'm still not doing something completely Kosher here, that
> > I'm still not understanding something, or that "git-branch" doesn't
> > know about the "info/grafts" file. (I put my money on the first
> > explanation, and include the 3rd just for completeness).
>
> Hmm. It worked for me with '-d'. I did:
>
Ahhh... if I do the "git-branch -d original" _before_ I do the
"git-svn dcommit", then I get no warning, which makes sense because
everything on the "original" branch is on the "master" branch. But,
if I do it _after_ I do the "git-svn dcommit", I get the warning and
have to use -D. This is probably consistent with the history rewrite
that occurs with the "dcommit"
>
> > Oops, my bad, I mean "git-rev-list". But even now, writing that, I
> > realize that they wouldn't show up there either -- git-rev-list lists
> > the commit chain for a given branch. I'm just wondering what happened
> > to commit 0e3e0e1e that was in my original git repo and which seems to
> > have been replaced with commit 50a9979a in the new repo. Of course
> > the hash has changed, since git-svn added a "git-svn-id" line to my
> > log message. But I wonder why git-fsck doesn't report it as dangling.
> > "git-cat-file -p 0e3e" prints it out.
>
> Hmm. I wonder if git-svn squashed your changes during the merge, as I
> had mentioned previously. You could really get better answers from one
> of the git-svn people. :)
Ahh, but I forgot to include any git-svn people in my previous reply :-(
>
>
> It is presumably still referenced somewhere. Maybe even in your reflog
> (try git-reflog show).
>
yep -- it's referenced there. Not that this matters. I'm in the
"gee, now I'm curious" phase -- a dozen or so 200 byte entries
squished in the pack file aren't going to make any difference.
> > > > I'm also curious what experts would think of my fumbling efforts to
> > > > transfer this git-managed project into a git/svn-managed project,
> > > > maintaining the initial history. Did I go tremendously out of my way
> > > > to do something that was a one-line command?
> > >
> > > More or less. ;)
> > >
> > > Presumably you could take your _existing_ repository, point it at your
> > > svn upstream (look in the .git/config of your svn-cloned repo, and there
> > > is presumably some svn config), and do the dcommit. Unfortunately, I
> > > have the privilege of never having used svn or git-svn, so I can't
> > > comment further.
> > >
> > I'm not sure that would work, as it appears that git-svn plays some
> > games to associate git commits with SVN commits (hence my question
> > about about why the 0e3e commit doesn't dangle anywhere).
>
> Right. It seems like there ought to be a way around this, but again, one
> of the git-svn people can answer better. :) Maybe try re-asking your
> question as "is there a way to do this easily" and cc'ing Eric Wong.
>
or, perhaps by bringing this back on the list, I'll get some more feedback :-)
> > Thanks for the comments and explanations. At this point, I'm not sure
> > that git offers me anything better for me and my work-flows than what
> > I get from Subversion, or CVS, (or RCS, or for that matter, SCCS -- if
> > anybody still remembers that!), but I'm learning something new, and
>
> I thought the same way when I started with git, and then I realized that
> git opened up a lot of possibilities for changing my workflow in little
> ways. Coming from CVS, the concept of actually looking through history
> for information on a code problem was foreign to me. But now I use
> "git-log -p -S" all the time (-S is semi-confusingly documented under
> git-diff). And that becomes more useful when I make concise,
> well-documented commits, which is another thing git is great for. :)
>
> -Peff
Thanks again...
--wpd
^ permalink raw reply
* Re: being nice to patch(1)
From: David Kastrup @ 2007-07-03 15:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: quilt-dev, git
In-Reply-To: <Pine.LNX.4.64.0707031601100.4071@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 3 Jul 2007, David Kastrup wrote:
>
>> It would help if you actually read what you are replying to.
>
> Actually, your second explanation helped. Fix posted separately.
Thanks.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] git-submodule: provide easy way of adding new submodules
From: Sven Verdoolaege @ 2007-07-03 15:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Lars Hjemli
In-Reply-To: <7vps3k33ze.fsf@assigned-by-dhcp.pobox.com>
On Mon, Jun 25, 2007 at 12:09:09AM -0700, Junio C Hamano wrote:
> I am not sure about the usefulness of "-b branch" thing myself,
> but other than that, looks very sane to me.
So, do you want me to send it in again, without the branch thing?
skimo
^ permalink raw reply
* Re: [Quilt-dev] Re: being nice to patch(1)
From: Andrew Morton @ 2007-07-03 15:49 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
* [PATCH] Add pager.program config variable.
From: Brian Gernhardt @ 2007-07-03 16:03 UTC (permalink / raw)
To: git
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>
---
This takes the last bit of git specific configuration out of my
.profile and puts it in .gitconfig where it belongs.
I didn't know what name to use. I settled on pager.program, but
thought that core.pager might be better since there are no other
options in the pager section.
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..1c4f3d5 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -596,6 +596,10 @@ pack.deltaCacheLimit::
The maxium size of a delta, that is cached in
gitlink:git-pack-objects[1]. Defaults to 1000.
+pager.program::
+ The command that git will use to page output. Can be overridden with
+ the `GIT_PAGER` environment variable.
+
pull.octopus::
The default merge strategy to use when pulling multiple branches
at once.
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..146b4bd 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, "pager.program")) {
+ 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
* Re: [Quilt-dev] Re: being nice to patch(1)
From: Linus Torvalds @ 2007-07-03 16:03 UTC (permalink / raw)
To: Andrew Morton; +Cc: Andreas Gruenbacher, quilt-dev, git
In-Reply-To: <20070703084926.2e834aa5.akpm@linux-foundation.org>
On Tue, 3 Jul 2007, Andrew Morton wrote:
>
> 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 -t" (or "--batch") should do it, I suspect.
But even with "patch -tu -p1" you do seem to end up having patch notice
indented patch fragments (ie things that obviously are *not* part of the
patch, but some explanation).
Linus
^ permalink raw reply
* Re: [Quilt-dev] Re: being nice to patch(1)
From: Andreas Gruenbacher @ 2007-07-03 16:03 UTC (permalink / raw)
To: Andrew Morton; +Cc: quilt-dev, Linus Torvalds, git
In-Reply-To: <20070703084926.2e834aa5.akpm@linux-foundation.org>
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.
Andreas
^ permalink raw reply
* Re: [Quilt-dev] Re: being nice to patch(1)
From: Andrew Morton @ 2007-07-03 16:15 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
* Re: [TIG PATCH] Ignore generated manpages.
From: Jonas Fonseca @ 2007-07-03 16:23 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <20070703145012.GA11660@Hermes.local>
Brian Gernhardt <benji@silverinsanity.com> wrote Tue, Jul 03, 2007:
> Adds tig.1 and tigrc.5 to .gitignore
Thanks. Applied and pushed out.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Add pager.program config variable.
From: Johannes Schindelin @ 2007-07-03 16:30 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <20070703160308.GA16629@Hermes.local>
Hi,
On Tue, 3 Jul 2007, Brian Gernhardt wrote:
> I didn't know what name to use. I settled on pager.program, but
> thought that core.pager might be better since there are no other
> options in the pager section.
Yeah, core.pager seems more consistent.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Document git-filter-branch
From: Johannes Schindelin @ 2007-07-03 16:47 UTC (permalink / raw)
To: git, gitster
This moves the documentation in git-filter-branch.sh to its own
man page, with a few touch ups.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Sorry, for being so late. I just realised this is not yet in
git.git, and it would be better IMHO to have it in 1.5.3...
Documentation/cmd-list.perl | 1 +
Documentation/git-filter-branch.txt | 261 +++++++++++++++++++++++++++++++++++
git-filter-branch.sh | 187 +------------------------
3 files changed, 265 insertions(+), 184 deletions(-)
create mode 100644 Documentation/git-filter-branch.txt
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index f50f613..2143995 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -105,6 +105,7 @@ git-diff-tree plumbinginterrogators
git-fast-import ancillarymanipulators
git-fetch mainporcelain
git-fetch-pack synchingrepositories
+git-filter-branch ancillarymanipulators
git-fmt-merge-msg purehelpers
git-for-each-ref plumbinginterrogators
git-format-patch mainporcelain
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
new file mode 100644
index 0000000..ee60a1a
--- /dev/null
+++ b/Documentation/git-filter-branch.txt
@@ -0,0 +1,261 @@
+git-filter-branch(1)
+====================
+
+NAME
+----
+git-filter-branch - Rewrite branches
+
+SYNOPSIS
+--------
+[verse]
+'git-filter-branch' [--env-filter <command>] [--tree-filter <command>]
+ [--index-filter <command>] [--parent-filter <command>]
+ [--msg-filter <command>] [--commit-filter <command>]
+ [--tag-name-filter <command>] [--subdirectory-filter <directory>]
+ [-d <directory>] <new-branch-name> [<rev-list options>...]
+
+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
+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
+the id of the commit being rewritten. The author/committer environment
+variables are set before the first filter is run.
+
+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!).
+
+--index-filter <command>::
+ This is the filter for rewriting the index. It is similar to the
+ tree filter but does not check out the tree, which makes it much
+ faster. For hairy cases, see gitlink:git-update-index[1].
+
+--parent-filter <command>::
+ This is the filter for rewriting the commit's parent list.
+ It will receive the parent string on stdin and shall output
+ the new parent string on stdout. The parent string is in
+ a format accepted by gitlink:git-commit-tree[1]: empty for
+ the initial commit, "-p parent" for a normal commit and
+ "-p parent1 -p parent2 -p parent3 ..." for a merge commit.
+
+--msg-filter <command>::
+ This is the filter for rewriting the commit messages.
+ The argument is evaluated in the shell with the original
+ commit message on standard input; its standard output is
+ used as the new commit message.
+
+--commit-filter <command>::
+ This is the filter for performing the commit.
+ If this filter is specified, it will be called instead of the
+ gitlink:git-commit-tree[1] command, with arguments of the form
+ "<TREE_ID> [-p <PARENT_COMMIT_ID>]..." and the log message on
+ stdin. The commit id is expected on stdout.
++
+As a special extension, the commit filter may emit multiple
+commit ids; in that case, ancestors of the original commit will
+have all of them as parents.
+
+--tag-name-filter <command>::
+ This is the filter for rewriting tag names. When passed,
+ it will be called for every tag ref that points to a rewritten
+ object (or to a tag object which points to a rewritten object).
+ The original tag name is passed via standard input, and the new
+ tag name is expected on standard output.
++
+The original tags are not deleted, but can be overwritten;
+use "--tag-name-filter=cat" to simply update the tags. In this
+case, be very careful and make sure you have the old tags
+backed up in case the conversion has run afoul.
++
+Note that there is currently no support for proper rewriting of
+tag objects; in layman terms, if the tag has a message or signature
+attached, the rewritten tag won't have it. Sorry. (It is by
+definition impossible to preserve signatures at any rate.)
+
+--subdirectory-filter <directory>::
+ Only regard the history, as seen by the given subdirectory. The
+ 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
+-------------------------------------------------------------------------------
+
+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
+----------------------------------------------------------------------
+
+(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:
+
+-------------------------------------------------------------------------------
+git filter-branch --parent-filter \
+ 'cat; test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>"' newbranch
+-------------------------------------------------------------------------------
+
+To remove commits authored by "Darl McBribe" from the history:
+
+------------------------------------------------------------------------------
+git filter-branch --commit-filter '
+ if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
+ then
+ shift;
+ while [ -n "$1" ];
+ do
+ shift;
+ echo "$1";
+ shift;
+ done;
+ else
+ git commit-tree "$@";
+ fi' newbranch
+------------------------------------------------------------------------------
+
+The shift magic first throws away the tree id and then the -p
+parameters. Note that this handles merges properly! In case Darl
+committed a merge between P1 and P2, it will be propagated properly
+and all children of the merge will become merge commits with P1,P2
+as their parents instead of the merge commit.
+
+To restrict rewriting to only part of the history, specify a revision
+range in addition to the new branch name. The new branch name will
+point to the top-most revision that a 'git rev-list' of this range
+will print.
+
+Note that the changes introduced by the commits, and not reverted by
+subsequent commits, will still be in the rewritten branch. If you want
+to throw out _changes_ together with the commits, you should use the
+interactive mode of gitlink:git-rebase[1].
+
+Consider this history:
+
+------------------
+ D--E--F--G--H
+ / /
+A--B-----C
+------------------
+
+To rewrite only commits D,E,F,G,H, but leave A, B and C alone, use:
+
+--------------------------------
+git filter-branch ... new-H C..H
+--------------------------------
+
+To rewrite commits E,F,G,H, use one of these:
+
+----------------------------------------
+git filter-branch ... new-H C..H --not D
+git filter-branch ... new-H D..H --not C
+----------------------------------------
+
+To move the whole tree into a subdirectory, or remove it from there:
+
+---------------------------------------------------------------
+git filter-branch --index-filter \
+ 'git ls-files -s | sed "s-\t-&newsubdir/-" |
+ GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
+ git update-index --index-info &&
+ mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' directorymoved
+---------------------------------------------------------------
+
+
+Author
+------
+Written by Petr "Pasky" Baudis <pasky@suse.cz>,
+and the git list <git@vger.kernel.org>
+
+Documentation
+--------------
+Documentation by Petr Baudis and the git list.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 3772951..22fb5bf 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -4,190 +4,9 @@
# Copyright (c) Petr Baudis, 2006
# Minimal changes to "port" it to core-git (c) Johannes Schindelin, 2007
#
-# Lets you rewrite GIT revision history by creating a new branch from
-# your current branch by 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 with 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 ids 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. Please do
-# not use this command if you do not know the full implications, and
-# avoid using it anyway - do not do what a simple single commit on top
-# of the current version would fix.
-#
-# 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 do it off-disk, e.g. on tmpfs. Reportedly the speedup
-# is very noticeable.
-#
-# OPTIONS
-# -------
-# -d TEMPDIR:: The path to the temporary tree 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.
-#
-# 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
-# the id of the commit being rewritten. The author/committer environment
-# variables are set before the first filter is run.
-#
-# 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
-# (see below).
-#
-# --env-filter COMMAND:: The filter for modifying environment
-# 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 `git-commit` for details). Do not forget to
-# re-export the variables.
-#
-# --tree-filter COMMAND:: The filter for rewriting tree (and its contents)
-# This is the filter for rewriting the tree and its contents.
-# The COMMAND 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!).
-#
-# --index-filter COMMAND:: The filter for rewriting index
-# This is the filter for rewriting the Git's directory index.
-# It is similar to the tree filter but does not check out the
-# tree, which makes it much faster. However, you must use the
-# lowlevel Git index manipulation commands to do your work.
-#
-# --parent-filter COMMAND:: The filter for rewriting parents
-# This is the filter for rewriting the commit's parent list.
-# It will receive the parent string on stdin and shall output
-# the new parent string on stdout. The parent string is in
-# format accepted by `git commit-tree`: empty for initial
-# commit, "-p parent" for a normal commit and "-p parent1
-# -p parent2 -p parent3 ..." for a merge commit.
-#
-# --msg-filter COMMAND:: The filter for rewriting commit message
-# This is the filter for rewriting the commit messages.
-# The COMMAND argument is evaluated in shell with the original
-# commit message on standard input; its standard output is
-# is used as the new commit message.
-#
-# --commit-filter COMMAND:: The filter for performing the commit
-# If this filter is passed, it will be called instead of the
-# `git commit-tree` command, with those arguments:
-#
-# TREE_ID [-p PARENT_COMMIT_ID]...
-#
-# and the log message on stdin. The commit id is expected on
-# stdout. As a special extension, the commit filter may emit
-# multiple commit ids; in that case, all of them will be used
-# as parents instead of the original commit in further commits.
-#
-# --tag-name-filter COMMAND:: The filter for rewriting tag names.
-# If this filter is passed, it will be called for every tag ref
-# that points to a rewritten object (or to a tag object which
-# points to a rewritten object). The original tag name is passed
-# via standard input, and the new tag name is expected on standard
-# output.
-#
-# The original tags are not deleted, but can be overwritten;
-# use "--tag-name-filter=cat" to simply update the tags. In this
-# case, be very careful and make sure you have the old tags
-# backed up in case the conversion has run afoul.
-#
-# Note that there is currently no support for proper rewriting of
-# tag objects; in layman terms, if the tag has a message or signature
-# attached, the rewritten tag won't have it. Sorry. (It is by
-# definition impossible to preserve signatures at any rate, though.)
-#
-# --subdirectory-filter DIRECTORY:: Only regard the history, as seen by
-# the given subdirectory. The result will contain that directory as
-# its project root.
-#
-# EXAMPLE USAGE
-# -------------
-# 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
-#
-# 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 graftcommitid/' newbranch
-#
-# (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 git-merge without common ancestors
-# happened). If this is not the case, use:
-#
-# git-filter-branch --parent-filter 'cat; [ "$GIT_COMMIT" = "COMMIT" ] && echo "-p GRAFTCOMMIT"' newbranch
-#
-# To remove commits authored by "Darl McBribe" from the history:
-#
-# git-filter-branch --commit-filter 'if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ]; then shift; while [ -n "$1" ]; do shift; echo "$1"; shift; done; else git commit-tree "$@"; fi' newbranch
-#
-# (the shift magic first throws away the tree id and then the -p
-# parameters). Note that this handles merges properly! In case Darl
-# committed a merge between P1 and P2, it will be propagated properly
-# and all children of the merge will become merge commits with P1,P2
-# as their parents instead of the merge commit.
-#
-# To restrict rewriting to only part of the history, specify a revision
-# range in addition to the new branch name. The new branch name will
-# point to the top-most revision that a 'git rev-list' of this range
-# will print.
-#
-# Consider this history:
-#
-# D--E--F--G--H
-# / /
-# A--B-----C
-#
-# To rewrite commits D,E,F,G,H, use:
-#
-# git-filter-branch ... new-H C..H
-#
-# To rewrite commits E,F,G,H, use one of these:
-#
-# git-filter-branch ... new-H C..H --not D
-# git-filter-branch ... new-H D..H --not C
-#
-# To move the whole tree into a subdirectory, or remove it from there:
-#
-# git-filter-branch --index-filter \
-# 'git ls-files -s | sed "s-\t-&newsubdir/-" |
-# GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
-# git update-index --index-info &&
-# mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' directorymoved
-
-# Testsuite: TODO
+# 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.
set -e
--
1.5.3.rc0.2637.g1dd84-dirty
^ permalink raw reply related
* [PATCH] filter-branch: add a test for the commit removal example
From: Johannes Schindelin @ 2007-07-03 16:50 UTC (permalink / raw)
To: git, gitster
In the man page, there is an example which describes how to remove
single commits (although it keeps the changes which were not reverted
in the next non-removed commit). Better make sure that it works as
expected.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t7003-filter-branch.sh | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 21f9bc5..451ac86 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -107,4 +107,39 @@ test_expect_success 'use index-filter to move into a subdirectory' '
mv \$GIT_INDEX_FILE.new \$GIT_INDEX_FILE" directorymoved &&
test -z "$(git diff HEAD directorymoved:newsubdir)"'
+test_expect_success 'author information is preserved' '
+ : > i &&
+ git add i &&
+ test_tick &&
+ GIT_AUTHOR_NAME="B V Uips" git commit -m bvuips &&
+ git-filter-branch --msg-filter "cat; \
+ test \$GIT_COMMIT = $(git rev-parse master) && \
+ echo Hallo" \
+ preserved-author &&
+ test 1 = $(git rev-list --author="B V Uips" preserved-author | wc -l)
+'
+
+test_expect_success "remove a certain author's commits" '
+ echo i > i &&
+ test_tick &&
+ git commit -m i i &&
+ git-filter-branch --commit-filter "\
+ if [ \"\$GIT_AUTHOR_NAME\" = \"B V Uips\" ];\
+ then\
+ shift;\
+ while [ -n \"\$1\" ];\
+ do\
+ shift;\
+ echo \"\$1\";\
+ shift;\
+ done;\
+ else\
+ git commit-tree \"\$@\";\
+ fi" removed-author &&
+ cnt1=$(git rev-list master | wc -l) &&
+ cnt2=$(git rev-list removed-author | wc -l) &&
+ test $cnt1 -eq $(($cnt2 + 1)) &&
+ test 0 = $(git rev-list --author="B V Uips" removed-author | wc -l)
+'
+
test_done
--
1.5.3.rc0.2637.g1dd84-dirty
^ permalink raw reply related
* Re: Starting 1.5.3 stabilization cycle
From: Peter Baumann @ 2007-07-03 18:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x9yrllv.fsf@assigned-by-dhcp.cox.net>
On Tue, Jul 03, 2007 at 12:29:32AM -0700, Junio C Hamano wrote:
> I tagged the tip of 'master' as 1.5.3-rc0; in addition to the
> topics described in the latest "What's in", most of the topics
> that have been cooking in 'next' are there. The time some of
> them have spent before going to 'master' might be shorter than
> usual and there are a handful patches that I took directly to
> 'master', but the tip of 'master' should be as solid as usual.
>
> There probably could be a few bits that we have already seen and
> was reviewed on the list that deserve to be in v1.5.3 (the only
> ones I have in mind right now are a few gitweb ones), but other
> than that, I think this is pretty much it, modulo bugfixes.
>
> Oh, by the way, a maintenance release 1.5.2.3 is also out.
>
> ----------------------------------------------------------------
>
> GIT v1.5.3 Release Notes (draft as of -rc0)
> ========================
>
> Updates since v1.5.2
> --------------------
>
> * The commit walkers other than http are officially deprecated
> (but still supported).
/
|>
|> * The submodule support has Porcelain layer now.
|>
|> * An initial interation of Porcelain level superproject support
^^^^^^^^^^ typo
|> started to take shape.
\
Duplicated?
>
> * Thee are a handful pack-objects changes to help you cope better with
> repositories with pathologically large blobs in them.
>
> * For people who need to import from Perforce, a front-end for
> fast-import is in contrib/fast-import/ now.
>
> * Comes with git-gui 0.8.0.
>
> * Comes with updated gitk.
>
> * New commands and options.
>
> - "git stash" allows you to quickly save away your work in
> progress and replay it later on an updated state.
>
> - "git rebase" learned an "interactive" mode.
Short describtion missing?
This is meant for reordering the commits, merge several commits into
one or even remove some of them.
>
> - "git fsck" can save its findings in lost-found, without a
> separate invocation of "git lost-found" command.
>
> - GIT_WORK_TREE environment variable can be used together with
> GIT_DIR to work in a subdirectory of a working tree that is
> not located at "$GIT_DIR/..".
>
> - "git log" learned a new option '--follow', to follow
> renaming history of a single file.
>
> - "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.
>
> - "git-cvsserver" learned new options (--base-path, --export-all,
> --strict-paths) inspired by git-daemon.
[...]
> - snapshot files "gitweb" creates from a repository at
> $path/$project/.git are more useful. We use $project part
> in the filename, which we used to discard.
>
> - "git cvsimort" creates lightweight tag; there is not any
^- should be "cvsimport"
> interesting information we can record in an annotated tag,
> and the handcrafted ones the old code created was not
> properly formed anyway.
>
> - "git-push" pretends that you immediately fetched back from
> the remote by updating corresponding remote tracking
> branches if you have any.
>
> - The diffstat given after a merge (or a pull) honors the
> color.diff configuration.
>
> - "git-apply --whitespace=strip" removes blank lines added at
> the end of the file.
>
> - "git-fetch" over git native protocols with -v shows connection
> status, and the IP address of the other end, to help
> diagnosing problems.
>
> - We used to have core.legacyheaders configuration, when
> set to false, allowed git to write loose objects in a format
> that mimicks the format used by objects stored in packs. It
> turns out that this was not so useful. Although we will
> continue to read objects written in that format, we do not
> honor that configuration anymore and create loose objects in
> the legacy/traditional format.
>
> - "--find-copies-harder" option to diff family can now be
> spelled as "-C -C" for brevity.
>
> - "git-mailsplit" (hence "git-am") can read from Maildir
> formatted mailboxes.
>
> - "git-cvsserver" does not barf upon seeing "cvs login"
> request.
>
> - "pack-objects" honors "delta" attribute set in
> .gitattributes. It does not attempt to deltify blobs that
> come from paths with delta attribute set to false.
>
> - new-workdir script (in contrib) can now be used with a bare
> repository.
>
> - "git-mergetool" learned to use gvimdiff.
>
> - "gitview" (in contrib) has a better blame interface.
>
> - "git log" and friends did not handle a commit log message
> that is larger than 16kB; they do now.
>
> - "--pretty=oneline" output format for "git log" and friends
> deals with "malformed" commit log messages that have more
> than one lines in the first paragraph better. We used to
> show the first line, cutting the title at mid-sentence; we
> concatenate them into a single line and treat the result as
> "oneline".
>
> * Builds
>
> - old-style function definitions (most notably, a function
> without parameter defined with "func()", not "func(void)")
> have been eradicated.
>
> * Performance Tweaks
>
> - git-pack-objects avoids re-deltification cost by caching
> small enough delta results it creates while looking for the
> best delta candidates.
>
> - diff-delta code that is used for packing has been improved
> to work better on big files.
>
> - when there are more than one pack files in the repository,
I'm no native english speaker, but shouldn't this be
- when there is more then one pack file in the repository,
^^ ^^^^
> the runtime used to try finding an object always from the
> newest packfile; it now tries the same packfile as we found
> the object requested the last time, which exploits the
> locality of references.
>
> - verifying pack contents done by "git fsck --full" got boost
> by carefully choosing the order to verify objects in them.
>
>
> Fixes since v1.5.2
> ------------------
>
> All of the fixes in v1.5.2 maintenance series are included in
> this release, unless otherwise noted.
>
> * Bugfixes
>
> - "gitweb" had trouble handling non UTF-8 text with older
> Encode.pm Perl module.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ 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