* Re: Git tree for old kernels from before the current tree
From: Theodore Tso @ 2007-07-23 18:57 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Jan Engelhardt, Paul Mundt, Jon Smirl,
Git Mailing List, lkml
In-Reply-To: <alpine.LFD.0.999.0707230950340.3607@woody.linux-foundation.org>
On Mon, Jul 23, 2007 at 09:55:24AM -0700, Linus Torvalds wrote:
>
> I actually tried to get something like this together back in the BK days
> and early in the SCO saga. It was pretty painful to try to find all the
> historic trees and patches - they're all in different format, and some of
> them are unreliable (ie CVS imports by people like Ted).
Um, *I* never had the bad taste to import Linux kernels into CVS. :-)
I'm pretty sure we never had anything like that on tsx-11.mit.edu, either.
- Ted
^ permalink raw reply
* Re: If NEEDS_LIBICONV is set for Solaris 8, it does not build git for me
From: Thomas Glanzmann @ 2007-07-23 18:51 UTC (permalink / raw)
To: Jason Riedy; +Cc: Junio C Hamano, GIT, Paul Jakma
In-Reply-To: <878x97eznf.fsf@sparse.dyndns.org>
Hello,
> I didn't even know you could patch 5.8 enough to use that compiler
> version. I can't imagine what strange combinations of C89 and C99
> features are available.
I even think that Forte 11 was one of the first who supported C99 in the
first place. However my intention is the following: I build git on
Solaris 5.8 because it works on any system that is 5.8 or higher (5.9,
5.10 and the upcomming 5.11). Good in theory. But not in practice since
they bumped the perl version (I did not thought of that before). With
high probability I could work around that. But at the moment I don't
care that much because I have a build host for every major release of
Solaris and I don't use the perl part of git not that much. However
having git on Solaris is a real pleasure. Together with sudo and vim.
Thomas
^ permalink raw reply
* Re: If NEEDS_LIBICONV is set for Solaris 8, it does not build git for me
From: Jason Riedy @ 2007-07-23 18:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Glanzmann, GIT, Paul Jakma
In-Reply-To: <7v8x98qc3k.fsf@assigned-by-dhcp.cox.net>
And Junio C. Hamano writes:
>
> In a distant past when I built git on an otherwise unused Sol8
> at work I recall I needed that. I do not think that machine
> used Forte compiler, though.
I didn't even know you could patch 5.8 enough to use that
compiler version. I can't imagine what strange combinations of
C89 and C99 features are available.
Luckily for me, I no longer have easy access to Solaris <9.
At some point, the crazy patch combinations need relegated to
each particular site's config.mak. Solaris 8 has entered the
first "retirement phase", but new orders can include it for about
another month:
http://www.sun.com/software/solaris/support/sol8.xml
Jason
^ permalink raw reply
* Re: having problems with building the manpages
From: Julian Phillips @ 2007-07-23 18:40 UTC (permalink / raw)
To: VMiklos; +Cc: git
In-Reply-To: <20070723182319.GQ31655@genesis.frugalware.org>
On Mon, 23 Jul 2007, VMiklos wrote:
> hi,
>
> the man branch of git.git contains the following lines in git-diff.1:
>
> EXAMPLES
> Various ways to check your working tree
>
> $ git diff (1)
> $ git diff --cached (2)
> $ git diff HEAD (3)
>
> 1. changes in the working tree not yet staged for the next commit.
> 2. changes between the index and your last commit; what you would be committing if you run "git
> commit" without "-a" option.
> 3. changes in the working tree since your last commit; what you would be committing if you run
> "git commit -a"
>
> when building the manpages myself i get the followings:
>
> EXAMPLES
> Various ways to check your working tree
>
> $ git diff \fB(1)\fR
> $ git diff --cached \fB(2)\fR
> $ git diff HEAD \fB(3)\fR
> .sp \fB1. \fRchanges in the working tree not yet staged for the next commit.
>
> .br \fB2. \fRchanges between the index and your last commit; what you would be committing if you run
> "git commit" without "-a" option.
>
> .br \fB3. \fRchanges in the working tree since your last commit; what you would be committing if you
> run "git commit -a"
>
> .br
>
> what can be the problem?
>
> i have asciidoc-8.2.2 and docbook-xml 4.2 installed. i'm building with
> ASCIIDOC8=YesPlease.
>
> if i missed any required info, please mention :)
Are you using docbook xsl 1.72? There are known problems building the
manpages with that version. 1.71 works, and 1.73 should work when it get
released.
--
Julian
---
Kirkland, Illinois, law forbids bees to fly over the village or through
any of its streets.
^ permalink raw reply
* having problems with building the manpages
From: VMiklos @ 2007-07-23 18:23 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]
hi,
the man branch of git.git contains the following lines in git-diff.1:
EXAMPLES
Various ways to check your working tree
$ git diff (1)
$ git diff --cached (2)
$ git diff HEAD (3)
1. changes in the working tree not yet staged for the next commit.
2. changes between the index and your last commit; what you would be committing if you run "git
commit" without "-a" option.
3. changes in the working tree since your last commit; what you would be committing if you run
"git commit -a"
when building the manpages myself i get the followings:
EXAMPLES
Various ways to check your working tree
$ git diff \fB(1)\fR
$ git diff --cached \fB(2)\fR
$ git diff HEAD \fB(3)\fR
.sp \fB1. \fRchanges in the working tree not yet staged for the next commit.
.br \fB2. \fRchanges between the index and your last commit; what you would be committing if you run
"git commit" without "-a" option.
.br \fB3. \fRchanges in the working tree since your last commit; what you would be committing if you
run "git commit -a"
.br
what can be the problem?
i have asciidoc-8.2.2 and docbook-xml 4.2 installed. i'm building with
ASCIIDOC8=YesPlease.
if i missed any required info, please mention :)
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Another question about importing SVN with fast-import
From: Jan Hudec @ 2007-07-23 18:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Frech, Julian Phillips, git
In-Reply-To: <20070720051142.GO32566@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
On Fri, Jul 20, 2007 at 01:11:42 -0400, Shawn O. Pearce wrote:
> It is possible. I'm just not sure what the syntax for it should be.
> Suggestions? I really want to stay backwards compatible with the
> current "C" command, so:
>
> 'C' SP commit SP path SP path
>
> is out because its ambiguous with the current meaning where the
> second (destination) path can contain SP without being quoted by
> the frontend.
I'd suggest one of two variants:
1) 'M' SP <mode> SP <dataref> SP <path> LF
where <dataref> would be extended to understand the
{tag-id|commit-id|tree-id}:path notation git-ref-parse understands plus
mark:path where mark points to commit.
2) 'C' SP <dataref> SP <path> LF
where again <dataref> can be {tag-id|commit-id|tree-id|mark}:path -- or
just path which implies current head.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git tree for old kernels from before the current tree
From: Linus Torvalds @ 2007-07-23 18:02 UTC (permalink / raw)
To: Nicolas Pitre
Cc: H. Peter Anvin, Jan Engelhardt, Paul Mundt, Jon Smirl,
Git Mailing List, lkml
In-Reply-To: <alpine.LFD.0.999.0707231343350.6355@xanadu.home>
On Mon, 23 Jul 2007, Nicolas Pitre wrote:
>
> I started this once.
>
> I have (sort of) a GIT tree with all Linux revisions that I could find
> from v0.01 up to v1.0.9. But the most interesting information and also
> what is the most time consuming is the retrieval of announcement
> messages for those releases in old mailing list or newsgroup archives to
> serve as commit log data. It seems to be even arder to find for post
> v1.0 releases.
Yes, I agree. Google finds some of them, but (a) I was never very good
about announcements anyway and (b) there's nothing really good to search
for, so it's very hit-and-miss.
Some of the really early release notes are easy to find, just because I
made them available with the sources, but mostly I'd just have posten to
the newsgroup/mailing lists.
If somebody creates a reasonably good tree (ie all the trees, easily
diffable, tied together with at least *some* commit history and the most
easily found release notes), I'm willing to try to spend some time just
writing down recollections from looking at the diffs. Not very reliable,
but better than nothing. This is the kind of thing that the "notes" thing
could be useful for, since there are others around who might also be
interested in adding their commentary.
Linus
^ permalink raw reply
* Re: index-pack died on pread
From: Nicolas Pitre @ 2007-07-23 18:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Michal Rokos, GIT
In-Reply-To: <alpine.LFD.0.999.0707230956390.3607@woody.linux-foundation.org>
On Mon, 23 Jul 2007, Linus Torvalds wrote:
>
>
> On Mon, 23 Jul 2007, Michal Rokos wrote:
> >
> > fatal: cannot pread pack file: No such file or directory (n=0,
> > errno=2, fd=3, ptr=40452958, len=428, rdy=0, off=123601)
>
> Ok, that's bogus. When "n" is zero, the errno (and thus the error string)
> is not changed by pread, so that's a very misleading error report.
>
> So what seems to have happened is that the pack-file is too short, so we
> got a return value of 0, and then reported it as if it had an errno.
>
> The reason for returning zero from pread would be:
>
> - broken pread. I don't think HPUX should be a problem, so that's
> probably not it.
>
> - the pack-file got truncated
>
> - the offset is corrupt, and points to beyond the size of the packfile.
>
> In this case, since the offset is just 123601, I suspect it's a truncation
> issue, and your pack-file is simply corrupt. Either because of some
> problem with receiving it, or because of problems on the remote side.
I doubt it can be that. pread() is always used on pack data that we
already received and validated, and part of the validation is the final
pack SHA1. No code path leads to pread() before the final pack SHA1 is
tested OK.
The only way for the received pack to be truncated and pread() to fail
is if write_or_die() somehow failed to write the pack data without Git
noticing.
Nicolas
^ permalink raw reply
* Re: Git tree for old kernels from before the current tree
From: Nicolas Pitre @ 2007-07-23 17:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Jan Engelhardt, Paul Mundt, Jon Smirl,
Git Mailing List, lkml
In-Reply-To: <alpine.LFD.0.999.0707230950340.3607@woody.linux-foundation.org>
On Mon, 23 Jul 2007, Linus Torvalds wrote:
> So I've been thinking about trying to re-create some really old history
> into git, but it's still a lot of work.. And obviously not very useful,
> just interesting from an archeological standpoint.
I started this once.
I have (sort of) a GIT tree with all Linux revisions that I could find
from v0.01 up to v1.0.9. But the most interesting information and also
what is the most time consuming is the retrieval of announcement
messages for those releases in old mailing list or newsgroup archives to
serve as commit log data. It seems to be even arder to find for post
v1.0 releases.
Nicolas
^ permalink raw reply
* Re: git-apply versus git-am
From: Timur Tabi @ 2007-07-23 17:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Sean Kelley, git
In-Reply-To: <Pine.LNX.4.64.0707231834280.14781@racer.site>
Johannes Schindelin wrote:
> Read it again. Junio talked about applymbox, not am.
Sorry, for some reason I thought git-am is just a shortcut for git-applymbox.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: git-apply versus git-am
From: Peter Baumann @ 2007-07-23 17:37 UTC (permalink / raw)
To: Timur Tabi; +Cc: Junio C Hamano, Sean Kelley, git
In-Reply-To: <46A4E368.7080909@freescale.com>
On Mon, Jul 23, 2007 at 12:20:40PM -0500, Timur Tabi wrote:
> Junio C Hamano wrote:
>
>> applymbox is going away.
>
> That sucks! I like git-am. Is there a replacement command that applies a
> patch and commits it at the same time? If I use git-apply on a patch that
> adds new files, I need to use git-add on the files before I can commit it.
> That's a real pain.
'git am' isn't going away, but as Junio mentioned, 'git applymbox' is.
Those are two *different* programms doing roughly the same, but
'git applymbox' is superceded by 'git am'.
-Peter
^ permalink raw reply
* Re: git-apply versus git-am
From: Johannes Schindelin @ 2007-07-23 17:34 UTC (permalink / raw)
To: Timur Tabi; +Cc: Junio C Hamano, Sean Kelley, git
In-Reply-To: <46A4E368.7080909@freescale.com>
Hi,
On Mon, 23 Jul 2007, Timur Tabi wrote:
> Junio C Hamano wrote:
>
> > applymbox is going away.
>
> That sucks! I like git-am.
Read it again. Junio talked about applymbox, not am.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] filter-branch: Big syntax change; support rewriting multiple refs
From: Johannes Schindelin @ 2007-07-23 17:34 UTC (permalink / raw)
To: git, gitster
We used to take the first non-option argument as the name for the new
branch. This syntax is not extensible to support rewriting more than just
HEAD.
Instead, we now have the following syntax:
git filter-branch [<filter options>...] [<rev-list options>]
All positive refs given in <rev-list options> are rewritten. Yes,
in-place. If a ref was changed, the original head is stored in
refs/original/$ref now, for your inspecting pleasure, in addition to the
reflogs (since it is easier to inspect "git show-ref | grep original" than
to inspect all the reflogs).
This commit also adds the --force option to remove .git-rewrite/ and all
refs from refs/original/ before filtering.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Junio, I know that this comes quite late in the game, but I really
think that the "first arg is new branch name" was a bad syntax.
Could you please consider taking this patch (or whatever version
comes out after review ;-) or keeping filter-branch of 1.5.3? I
do not want people to get used to the borked syntax...
BTW I considered "git log -g --all" as an alternative to
inspecting refs/original/, but ATM this die()s if just _one_ of
the refs has no logs. Probably should fix that, too.
Documentation/git-filter-branch.txt | 51 +++++++------
git-filter-branch.sh | 150 +++++++++++++++++++++++++++++-----
t/t7003-filter-branch.sh | 41 ++++++----
3 files changed, 182 insertions(+), 60 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index eaea82d..915258f 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -12,7 +12,7 @@ SYNOPSIS
[--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>...]
+ [-d <directory>] [-f | --force] [<rev-list options>...]
DESCRIPTION
-----------
@@ -26,10 +26,9 @@ 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.
+have no effect. 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
@@ -38,8 +37,9 @@ 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.
+Always verify that the rewritten version is correct: The original refs,
+if different from the rewritten ones, will be stored in the namespace
+'refs/original/'.
Note that since this operation is extensively I/O expensive, it might
be a good idea to redirect the temporary directory off-disk, e.g. on
@@ -142,6 +142,11 @@ definition impossible to preserve signatures at any rate.)
does this in the '.git-rewrite/' directory but you can override
that choice by this parameter.
+-f\|--force::
+ `git filter-branch` refuses to start with an existing temporary
+ directory or when there are already refs starting with
+ 'refs/original/', unless forced.
+
<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
@@ -156,14 +161,14 @@ Suppose you want to remove a file (containing confidential information
or copyright violation) from all commits:
-------------------------------------------------------
-git filter-branch --tree-filter 'rm filename' newbranch
+git filter-branch --tree-filter 'rm filename' HEAD
-------------------------------------------------------
A significantly faster version:
--------------------------------------------------------------------------------
-git filter-branch --index-filter 'git update-index --remove filename' newbranch
--------------------------------------------------------------------------------
+--------------------------------------------------------------------------
+git filter-branch --index-filter 'git update-index --remove filename' HEAD
+--------------------------------------------------------------------------
Now, you will get the rewritten history saved in the branch 'newbranch'
(your current branch is left untouched).
@@ -172,25 +177,25 @@ To set a commit (which typically is at the tip of another
history) to be the parent of the current initial commit, in
order to paste the other history behind the current history:
-------------------------------------------------------------------------
-git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' newbranch
-------------------------------------------------------------------------
+-------------------------------------------------------------------
+git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD
+-------------------------------------------------------------------
(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
--------------------------------------------------------------------------------
+ 'cat; test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>"' HEAD
+--------------------------------------------------------------------------
or even simpler:
-----------------------------------------------
echo "$commit-id $graft-id" >> .git/info/grafts
-git filter-branch newbranch $graft-id..
+git filter-branch $graft-id..HEAD
-----------------------------------------------
To remove commits authored by "Darl McBribe" from the history:
@@ -208,7 +213,7 @@ git filter-branch --commit-filter '
done;
else
git commit-tree "$@";
- fi' newbranch
+ fi' HEAD
------------------------------------------------------------------------------
The shift magic first throws away the tree id and then the -p
@@ -238,14 +243,14 @@ 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
+git filter-branch ... 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
+git filter-branch ... C..H --not D
+git filter-branch ... D..H --not C
----------------------------------------
To move the whole tree into a subdirectory, or remove it from there:
@@ -255,7 +260,7 @@ 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
+ mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD
---------------------------------------------------------------
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 0d000ed..0ff3475 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -78,6 +78,8 @@ filter_msg=cat
filter_commit='git commit-tree "$@"'
filter_tag_name=
filter_subdir=
+orig_namespace=refs/original/
+force=
while case "$#" in 0) usage;; esac
do
case "$1" in
@@ -85,6 +87,11 @@ do
shift
break
;;
+ --force|-f)
+ shift
+ force=t
+ continue
+ ;;
-*)
;;
*)
@@ -126,24 +133,43 @@ do
--subdirectory-filter)
filter_subdir="$OPTARG"
;;
+ --original)
+ orig_namespace="$OPTARG"
+ ;;
*)
usage
;;
esac
done
-dstbranch="$1"
-shift
-test -n "$dstbranch" || die "missing branch name"
-git show-ref "refs/heads/$dstbranch" 2> /dev/null &&
- die "branch $dstbranch already exists"
-
-test ! -e "$tempdir" || die "$tempdir already exists, please remove it"
+case "$force" in
+t)
+ rm -rf "$tempdir"
+;;
+'')
+ test -d "$tempdir" &&
+ die "$tempdir already exists, please remove it"
+esac
mkdir -p "$tempdir/t" &&
+tempdir="$(cd "$tempdir"; pwd)" &&
cd "$tempdir/t" &&
workdir="$(pwd)" ||
die ""
+# Make sure refs/original is empty
+git for-each-ref > "$tempdir"/backup-refs
+while read sha1 type name
+do
+ case "$force,$name" in
+ ,$orig_namespace*)
+ die "Namespace $orig_namespace not empty"
+ ;;
+ t,$orig_namespace*)
+ git update-ref -d "$name" $sha1
+ ;;
+ esac
+done < "$tempdir"/backup-refs
+
case "$GIT_DIR" in
/*)
;;
@@ -153,6 +179,29 @@ case "$GIT_DIR" in
esac
export GIT_DIR GIT_WORK_TREE=.
+# These refs should be updated if their heads were rewritten
+
+git rev-parse --revs-only --symbolic "$@" |
+while read ref
+do
+ # normalize ref
+ case "$ref" in
+ HEAD)
+ ref="$(git symbolic-ref "$ref")"
+ ;;
+ refs/*)
+ ;;
+ *)
+ ref="$(git for-each-ref --format='%(refname)' |
+ grep /"$ref")"
+ esac
+
+ git check-ref-format "$ref" && echo "$ref"
+done > "$tempdir"/heads
+
+test -s "$tempdir"/heads ||
+ die "Which ref do you want to rewrite?"
+
export GIT_INDEX_FILE="$(pwd)/../index"
git read-tree || die "Could not seed the index"
@@ -174,6 +223,8 @@ commits=$(wc -l <../revs | tr -d " ")
test $commits -eq 0 && die "Found nothing to rewrite"
+# Rewrite the commits
+
i=0
while read commit parents; do
i=$(($i+1))
@@ -234,22 +285,75 @@ while read commit parents; do
$(git write-tree) $parentstr < ../message > ../map/$commit
done <../revs
-src_head=$(tail -n 1 ../revs | sed -e 's/ .*//')
-target_head=$(head -n 1 ../map/$src_head)
-case "$target_head" in
-'')
- echo Nothing rewritten
+# In case of a subdirectory filter, it is possible that a specified head
+# is not in the set of rewritten commits, because it was pruned by the
+# revision walker. Fix it by mapping these heads to the next rewritten
+# ancestor(s), i.e. the boundaries in the set of rewritten commits.
+
+# NEEDSWORK: we should sort the unmapped refs topologically first
+while read ref
+do
+ sha1=$(git rev-parse "$ref"^0)
+ test -f "$workdir"/../map/$sha1 && continue
+ # Assign the boundarie(s) in the set of rewritten commits
+ # as the replacement commit(s).
+ # (This would look a bit nicer if --not --stdin worked.)
+ for p in $((cd "$workdir"/../map; ls | sed "s/^/^/") |
+ git rev-list $ref --boundary --stdin |
+ sed -n "s/^-//p")
+ do
+ map $p >> "$workdir"/../map/$sha1
+ done
+done < "$tempdir"/heads
+
+# Finally update the refs
+
+_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
+_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+count=0
+echo
+while read ref
+do
+ # avoid rewriting a ref twice
+ test -f "$orig_namespace$ref" && continue
+
+ sha1=$(git rev-parse "$ref"^0)
+ rewritten=$(map $sha1)
+
+ test $sha1 = "$rewritten" &&
+ warn "WARNING: Ref '$ref' is unchanged" &&
+ continue
+
+ case "$rewritten" in
+ '')
+ echo "Ref '$ref' was deleted"
+ git update-ref -m "filter-branch: delete" -d "$ref" $sha1 ||
+ die "Could not delete $ref"
;;
-*)
- git update-ref refs/heads/"$dstbranch" $target_head ||
- die "Could not update $dstbranch with $target_head"
- if [ $(wc -l <../map/$src_head) -gt 1 ]; then
- echo "WARNING: Your commit filter caused the head commit to expand to several rewritten commits. Only the first such commit was recorded as the current $dstbranch head but you will need to resolve the situation now (probably by manually merging the other commits). These are all the commits:" >&2
- sed 's/^/ /' ../map/$src_head >&2
- ret=1
- fi
+ $_x40)
+ echo "Ref '$ref' was rewritten"
+ git update-ref -m "filter-branch: rewrite" \
+ "$ref" $rewritten $sha1 ||
+ die "Could not rewrite $ref"
;;
-esac
+ *)
+ # NEEDSWORK: possibly add -Werror, making this an error
+ warn "WARNING: '$ref' was rewritten into multiple commits:"
+ warn "$rewritten"
+ warn "WARNING: Ref '$ref' points to the first one now."
+ rewritten=$(echo "$rewritten" | head -n 1)
+ git update-ref -m "filter-branch: rewrite to first" \
+ "$ref" $rewritten $sha1 ||
+ die "Could not rewrite $ref"
+ ;;
+ esac
+ git update-ref -m "filter-branch: backup" "$orig_namespace$ref" $sha1
+ count=$(($count+1))
+done < "$tempdir"/heads
+
+# TODO: This should possibly go, with the semantics that all positive given
+# refs are updated, and their original heads stored in refs/original/
+# Filter tags
if [ "$filter_tag_name" ]; then
git for-each-ref --format='%(objectname) %(objecttype) %(refname)' refs/tags |
@@ -286,6 +390,8 @@ fi
cd ../..
rm -rf "$tempdir"
-printf "\nRewritten history saved to the $dstbranch branch\n"
+echo
+test $count -gt 0 && echo "These refs were rewritten:"
+git show-ref | grep ^"$orig_namespace"
exit $ret
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 4ddd656..bc6e2dd 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -30,24 +30,24 @@ test_expect_success 'setup' '
H=$(git rev-parse H)
test_expect_success 'rewrite identically' '
- git-filter-branch H2
+ git-filter-branch branch
'
-
test_expect_success 'result is really identical' '
- test $H = $(git rev-parse H2)
+ test $H = $(git rev-parse HEAD)
'
test_expect_success 'rewrite, renaming a specific file' '
- git-filter-branch --tree-filter "mv d doh || :" H3
+ git-filter-branch -f --tree-filter "mv d doh || :" HEAD
'
test_expect_success 'test that the file was renamed' '
- test d = $(git show H3:doh)
+ test d = $(git show HEAD:doh)
'
-git tag oldD H3~4
+git tag oldD HEAD~4
test_expect_success 'rewrite one branch, keeping a side branch' '
- git-filter-branch --tree-filter "mv b boh || :" modD D..oldD
+ git branch modD oldD &&
+ git-filter-branch -f --tree-filter "mv b boh || :" D..modD
'
test_expect_success 'common ancestor is still common (unchanged)' '
@@ -69,7 +69,8 @@ test_expect_success 'filter subdirectory only' '
git rm a &&
test_tick &&
git commit -m "again not subdir" &&
- git-filter-branch --subdirectory-filter subdir sub
+ git branch sub &&
+ git-filter-branch -f --subdirectory-filter subdir refs/heads/sub
'
test_expect_success 'subdirectory filter result looks okay' '
@@ -89,7 +90,8 @@ test_expect_success 'setup and filter history that requires --full-history' '
test_tick &&
git commit -m "again subdir on master" &&
git merge branch &&
- git-filter-branch --subdirectory-filter subdir sub-master
+ git branch sub-master &&
+ git-filter-branch -f --subdirectory-filter subdir sub-master
'
test_expect_success 'subdirectory filter result looks okay' '
@@ -100,7 +102,8 @@ test_expect_success 'subdirectory filter result looks okay' '
'
test_expect_success 'use index-filter to move into a subdirectory' '
- git-filter-branch --index-filter \
+ git branch directorymoved &&
+ git-filter-branch -f --index-filter \
"git ls-files -s | sed \"s-\\t-&newsubdir/-\" |
GIT_INDEX_FILE=\$GIT_INDEX_FILE.new \
git update-index --index-info &&
@@ -108,9 +111,10 @@ test_expect_success 'use index-filter to move into a subdirectory' '
test -z "$(git diff HEAD directorymoved:newsubdir)"'
test_expect_success 'stops when msg filter fails' '
- ! git-filter-branch --msg-filter false nonono &&
- rm -rf .git-rewrite &&
- ! git rev-parse nonono
+ old=$(git rev-parse HEAD) &&
+ ! git-filter-branch -f --msg-filter false &&
+ test $old = $(git rev-parse HEAD) &&
+ rm -rf .git-rewrite
'
test_expect_success 'author information is preserved' '
@@ -118,7 +122,8 @@ test_expect_success 'author information is preserved' '
git add i &&
test_tick &&
GIT_AUTHOR_NAME="B V Uips" git commit -m bvuips &&
- git-filter-branch --msg-filter "cat; \
+ git branch preserved-author &&
+ git-filter-branch -f --msg-filter "cat; \
test \$GIT_COMMIT != $(git rev-parse master) || \
echo Hallo" \
preserved-author &&
@@ -129,7 +134,8 @@ test_expect_success "remove a certain author's commits" '
echo i > i &&
test_tick &&
git commit -m i i &&
- git-filter-branch --commit-filter "\
+ git branch removed-author &&
+ git-filter-branch -f --commit-filter "\
if [ \"\$GIT_AUTHOR_NAME\" = \"B V Uips\" ];\
then\
shift;\
@@ -148,4 +154,9 @@ test_expect_success "remove a certain author's commits" '
test 0 = $(git rev-list --author="B V Uips" removed-author | wc -l)
'
+test_expect_success 'barf on invalid name' '
+ ! git filter-branch -f master xy-problem &&
+ ! git filter-branch -f HEAD^
+'
+
test_done
--
1.5.3.rc2.32.g35c5b
^ permalink raw reply related
* Re: git-apply versus git-am
From: Timur Tabi @ 2007-07-23 17:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean Kelley, git
In-Reply-To: <7vsl7flctg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> applymbox is going away.
That sucks! I like git-am. Is there a replacement command that applies a patch and
commits it at the same time? If I use git-apply on a patch that adds new files, I need to
use git-add on the files before I can commit it. That's a real pain.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* git-apply and git-am should provide better errors when changelog is missing
From: Timur Tabi @ 2007-07-23 17:15 UTC (permalink / raw)
To: git
I was trying to apply a patch, and I kept getting this odd error:
I'm trying to apply a patch, and I get this error message:
git-apply --stat mpc86xx.patch
fatal: git-apply: bad git-diff - expected /dev/null on line 55
When I take a look at line 55 of mpc86xx.patch, I see this:
# Yes MCA RS/6000s exist but Linux-PPC does not currently support any
config MCA
diff --git a/arch/powerpc/boot/dts/mpc86xx.dts b/arch/powerpc/boot/dts/mpc86xx.dts$
new file mode 100644
index 0000000..a8a13b4
--- /dev/null <--- line 55
+++ b/arch/powerpc/boot/dts/mpc86xx.dts
@@ -0,0 +1,187 @@
+/*
+ * MPC86xx Device Tree Source
+ *
+ * Copyright 2007 Freescale Semiconductor Inc.
So obviously, I was confused. Well, I figured out the problem. The patch did not include
a changelog. All it had was this:
From b878a6b32a733e72a771fffd632f57b08808fc7f Mon Sep 17 00:00:00 2001
From: xxx <xxx@freescale.com>
Date: Tue, 19 Jun 2007 12:55:59 -0500
Subject: [PATCH] Added MPC86xx Support
Signed-off-by: xxx <xxx@freescale.com>
---
arch/powerpc/Kconfig | 3 +-
Could someone please update the git-am and git-apply code to provide a better error
message in this situation? Thanks.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] Teach git-commit about commit message templates.
From: Junio C Hamano @ 2007-07-23 17:12 UTC (permalink / raw)
To: Steven Grimm; +Cc: Johannes Schindelin, git
In-Reply-To: <46A48949.1020501@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> With the patch, my intent was:
>
> * Strip off all comment lines
> * Strip off all Signed-off-by: lines
> * Trim whitespace
> * If the result has no content (! -s file), abort.
> * If a template file was specified:
> * Strip off all comment and Signed-off-by: lines from the template
> * Trim whitespace from the template
> * If the resulting trimmed template is the same as the trimmed
> commit message, abort.
>
> So I guess before getting to the specifics of the code, I'll ask: does
> the above make sense as a design? I wanted to preserve the existing
> behavior in the absence of a template.
Offhand, an "interesting" side effect of the above I can see is
that you will cry "wolf" if the only thing the user did is to
add his own Signed-off-by: line ;-) But that is sane in the
context of coming up with totally new commit log message.
I am more worried about how this should interact with cases
where you usually do not start the log message from scratch.
For example, are there cases / policies where being able to use
templates to leave comments on merge commits are needed?
Squash-commits? Perhaps "apply this template but only when you
have hand resolved a conflicting merges"?
Or even the case of amending a commit made by somebody else,
without changing the tree contents, in order to make the commit
log message to conform to the company standard?
^ permalink raw reply
* Re: index-pack died on pread
From: Linus Torvalds @ 2007-07-23 17:04 UTC (permalink / raw)
To: Michal Rokos; +Cc: GIT
In-Reply-To: <333e1ca10707230552i34c2a1cfq9fae94f20023e9d7@mail.gmail.com>
On Mon, 23 Jul 2007, Michal Rokos wrote:
>
> fatal: cannot pread pack file: No such file or directory (n=0,
> errno=2, fd=3, ptr=40452958, len=428, rdy=0, off=123601)
Ok, that's bogus. When "n" is zero, the errno (and thus the error string)
is not changed by pread, so that's a very misleading error report.
So what seems to have happened is that the pack-file is too short, so we
got a return value of 0, and then reported it as if it had an errno.
The reason for returning zero from pread would be:
- broken pread. I don't think HPUX should be a problem, so that's
probably not it.
- the pack-file got truncated
- the offset is corrupt, and points to beyond the size of the packfile.
In this case, since the offset is just 123601, I suspect it's a truncation
issue, and your pack-file is simply corrupt. Either because of some
problem with receiving it, or because of problems on the remote side.
> fetch-pack from 'git://git.kernel.org/pub/scm/git/git' failed.
One thing to look out for is that the "git.kernel.org" machines aren't the
"primary" ones, and the data gets mirrored from other machines. If the
mirroring is incomplete, I could imagine that the remote side simply ended
up terminating the connection, and you ended up with a partial pack-file.
Some of the kernel.org machines ran out of disk space the other day, so
maybe you happened to hit it in an unlucky window. Does it still happen?
Linus
^ permalink raw reply
* Re: Git tree for old kernels from before the current tree
From: Linus Torvalds @ 2007-07-23 16:55 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Jan Engelhardt, Paul Mundt, Jon Smirl, Git Mailing List, lkml
In-Reply-To: <46A3D5EA.2050600@zytor.com>
On Sun, 22 Jul 2007, H. Peter Anvin wrote:
>
> Wouldn't be hard to make a git tree with all the patches all the way
> back to 0.01 even...
I actually tried to get something like this together back in the BK days
and early in the SCO saga. It was pretty painful to try to find all the
historic trees and patches - they're all in different format, and some of
them are unreliable (ie CVS imports by people like Ted).
The good news is that git would be a lot more natural to the process of
trying to create a history, because you could basically import random
trees, and tag them as just independent trees, and then re-create the
history after-the-fact by trying to stitch them all together. And if you
find a new tree, you'd just re-stitch it - something that was very hard to
do with BK (and BK generally wouldn't help you with keeping multiple
independent trees around, and wouldn't generally accept the notion of
re-doing the histories and keeping various versions of the histories
around).
So I've been thinking about trying to re-create some really old history
into git, but it's still a lot of work.. And obviously not very useful,
just interesting from an archeological standpoint.
Linus
^ permalink raw reply
* git-send-email and pine alias format
From: Kumar Gala @ 2007-07-23 16:49 UTC (permalink / raw)
To: git
I was wondering why we don't parse the pine alias format according to the
following spec:
http://www.washington.edu/pine/tech-notes/low-level.html
I'd expect omething like, to get the address field.
@@ -225,7 +238,7 @@ my %parse_alias = (
$aliases{$1} = [ split(/\s+/, $2) ];
}}},
pine => sub { my $fh = shift; while (<$fh>) {
- if (/^(\S+)\t.*\t(.*)$/) {
+ if (/^(\S+)\s+(.*)$/) {
$aliases{$1} = [ split(/\s*,\s*/, $2) ];
}}},
gnus => sub { my $fh = shift; while (<$fh>) {
- k
^ permalink raw reply
* Re: index-pack died on pread
From: Alex Riesen @ 2007-07-23 15:32 UTC (permalink / raw)
To: Michal Rokos; +Cc: GIT
In-Reply-To: <333e1ca10707230552i34c2a1cfq9fae94f20023e9d7@mail.gmail.com>
On 7/23/07, Michal Rokos <michal.rokos@gmail.com> wrote:
> fatal: cannot pread pack file: No such file or directory (n=0,
> errno=2, fd=3, ptr=40452958, len=428, rdy=0, off=123601)
> fatal: index-pack died with error code 128
strange. pread(2) should not return ENOENT. Not in HP-UX
not anywhere.
Could you recompile with NO_PREAD=1 and try again?
Maybe HP-UX pread(2) implementation is just broken.
^ permalink raw reply
* git-gui ignores core.excludesFile
From: Lars Noschinski @ 2007-07-23 15:07 UTC (permalink / raw)
To: git, spearce
Hello!
It seems git-gui (0.7.5 from git 1.5.2.4 tarball) ignores the global
ignore file configured with the core.excludesfile option. My
~/.gitconfig contains
[core]
excludesFile = /home/noschinski/.gitignore
which is honoured by git-status but not by git-gui.
Greetings,
Lars.
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Simon 'corecode' Schubert @ 2007-07-23 15:11 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910707230744u2d3a0a31t9f65d5c9e68c9805@mail.gmail.com>
Jon Smirl wrote:
> On 7/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Okay, I did not really test thoroughly, it seems. Sorry. Next try.
>
> It's working a lot better. People deal with $Id two different ways.
> One way they delete all of the $Id lines, that is the case of the
> Sonos patch. In the Phytec patch they left all of the $Id lines in
> place which caused them to get modified. In both cases you just want
> the lines with $Id to disappear in the patch.
>
> It doesn't catch the $Id case from the Phytec patch.
>
> diff -uarN linux-2.6.10/arch/cris/arch-v10/boot/rescue/head.S
> linux-2.6.10-lpc3180/arch/cris/arch-v10/boot/rescue/head.S
> --- linux-2.6.10/arch/cris/arch-v10/boot/rescue/head.S 2004-12-25
> 05:35:24.000000000 +0800
> +++ linux-2.6.10-lpc3180/arch/cris/arch-v10/boot/rescue/head.S
> 2006-11-20 15:49:30.000000000 +0800
> @@ -1,4 +1,5 @@
> /* $Id: head.S,v 1.6 2003/04/09 08:12:43 pkj Exp $
> +/* $Id: head.S,v 1.2 2005/02/18 13:06:31 mike Exp $
> *
> * Rescue code, made to reside at the beginning of the
> * flash-memory. when it starts, it checks a partition
>
> It's not catching all of the $Revision and $Date deltas.
>
> The output diff shouldn't contain any CVS keywords. It is somewhat
> tricky to catch all of the cases and fix up the diffs. This filter
> should get written and debugged once and then made part of something
> like git so that it doesn't get written over and over again. Perl is
> way better for this I had 1000 lines of C in my program and it was
> still missing 10% of the cases.
Maybe I am missing something, but apart from $Log$, what's so hard about collapsing the CVS keywords? That's something like
s/\$(Id|Date|Header|CVSHeader|Author|Revision):[^$]*\$/$\1$/
or not?
I see that people want to modify the patch text to remove the churn, but that seems wrong. It would be much easier to just collapse the keywords before applying the patch, and then work on a newly created diff (from the git repo).
cheers
simon
^ permalink raw reply
* Re: What is a reasonable mixed workflow for git/git-cvsserver?
From: Brian Gernhardt @ 2007-07-23 15:06 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Steffen Prohaska, Git Mailing List
In-Reply-To: <46a038f90707230719i106e0576j2868548ef0cb1739@mail.gmail.com>
On Jul 23, 2007, at 10:19 AM, Martin Langhoff wrote:
> On 7/23/07, Steffen Prohaska <prohaska@zib.de> wrote:
>> My question is how to deal with this shared branch on the git
>> side. Should a core developer rebuild a sane history from such
>> a shared/mixed/unsorted branch by cherry picking the commits
>> to one or more topic branches?
>
> I think that's usually frowned upon. As the committer did his/her work
> on a particular state of the tree, and tested it. So every commit at
> least *should* be of a working state. Once you rewrite history as a
> "normal" practice, that flies out of the window. And it's a big loss.
That's only somewhat true. First, there's never a guarantee that the
committer tested it, especially if they had to pull before committing
(less likely they tested the resulting merge than tested their
original code). Second, rewriting history isn't a big loss. It's
done all the time here on this list. The patches I've sent in rarely
appear applied on top of the commit I made them from. The mob branch
could just be viewed as a set of patches to use, and it becomes the
maintainer's job to test the results after cherry-picking from them.
~~ Brian
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Jon Smirl @ 2007-07-23 14:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707230136360.14781@racer.site>
On 7/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Okay, I did not really test thoroughly, it seems. Sorry. Next try.
It's working a lot better. People deal with $Id two different ways.
One way they delete all of the $Id lines, that is the case of the
Sonos patch. In the Phytec patch they left all of the $Id lines in
place which caused them to get modified. In both cases you just want
the lines with $Id to disappear in the patch.
It doesn't catch the $Id case from the Phytec patch.
diff -uarN linux-2.6.10/arch/cris/arch-v10/boot/rescue/head.S
linux-2.6.10-lpc3180/arch/cris/arch-v10/boot/rescue/head.S
--- linux-2.6.10/arch/cris/arch-v10/boot/rescue/head.S 2004-12-25
05:35:24.000000000 +0800
+++ linux-2.6.10-lpc3180/arch/cris/arch-v10/boot/rescue/head.S
2006-11-20 15:49:30.000000000 +0800
@@ -1,4 +1,5 @@
/* $Id: head.S,v 1.6 2003/04/09 08:12:43 pkj Exp $
+/* $Id: head.S,v 1.2 2005/02/18 13:06:31 mike Exp $
*
* Rescue code, made to reside at the beginning of the
* flash-memory. when it starts, it checks a partition
It's not catching all of the $Revision and $Date deltas.
The output diff shouldn't contain any CVS keywords. It is somewhat
tricky to catch all of the cases and fix up the diffs. This filter
should get written and debugged once and then made part of something
like git so that it doesn't get written over and over again. Perl is
way better for this I had 1000 lines of C in my program and it was
still missing 10% of the cases.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: What is a reasonable mixed workflow for git/git-cvsserver?
From: Martin Langhoff @ 2007-07-23 14:19 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <AD8AD244-0B20-44E9-AEE6-9D2A75BC5091@zib.de>
On 7/23/07, Steffen Prohaska <prohaska@zib.de> wrote:
> If several people commit to the same shared branch exported by
> git-cvsserver they most likely will generate a series of unsorted
> commits, as they did in the past on a single cvs branch. The
> commits will probably deal with various topics, include bug fixes,
> and some are likely more experimental and not really ready for a
> stable branch.
Keep the good commit message practices ;-) in my projects I tend to
mimic the linux and git "style" for commit msgs.
> My question is how to deal with this shared branch on the git
> side. Should a core developer rebuild a sane history from such
> a shared/mixed/unsorted branch by cherry picking the commits
> to one or more topic branches?
I think that's usually frowned upon. As the committer did his/her work
on a particular state of the tree, and tested it. So every commit at
least *should* be of a working state. Once you rewrite history as a
"normal" practice, that flies out of the window. And it's a big loss.
In a sense, it's a "history that looks tidy but is false". And it's
extra work too. I very strongly prefer good commit messages, and the
real history.
> If one did so, how could one
> bring the git-ish history back to the people connected by cvs?
> Am I allowed to reset branches exported by git-cvsserver?
> Probably not?
Indeed not. Junio rewinds/rebases pu (the proposed updates branch
mentioned earlier) regularly, but you can only do that in a pure-git
project, and with fairly experienced git users (so if they get caught
with commits on top of a rewound pu branch they'll know what to do).
cvsserver doesn't know what to do with rewinds/rebases and, more
importantly, cvs clients can't cope with it. And that is something we
cannot fix, unfortunately.
cheers,
martin
> Steffen
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox