* Re: [PATCH 1/2] git-submodule: move cloning into a separate function
From: Johannes Sixt @ 2007-06-05 10:40 UTC (permalink / raw)
To: git
In-Reply-To: <11810357522478-git-send-email-hjemli@gmail.com>
Lars Hjemli wrote:
> + module_clone "$path" "$url" || exit $?
Minor nit: The idiom that is commonly used in situations like this (see
other git-* shell scripts):
module_clone "$path" "$url" || exit
because exit without argument uses the code of the last command
executed.
-- Hannes
^ permalink raw reply
* Re: How to use git-svn to clone from a mirror?
From: Eric Wong @ 2007-06-05 10:41 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86r6oqoqdd.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 4 Jun 2007, Raja R Harinath wrote:
> >
> >> David Kastrup <dak@gnu.org> writes:
> >>
> >> > I have used something like
> >> >
> >> > git-svn clone -T trunk -b branches -t tags file:///tmp/rsync-mirror
> >> >
> >> > to clone an rsync mirror of an SVN repository. Now I want to have
> >> > fetch revert to pulling from the upstream repository in future.
> >> > However, if I change the respective line in .git/config to
> >> > svn://the.svn.link/whatever, git-rebase will fetch the right updates,
> >> > but then says that it can't work with the objects in the git
> >> > repository.
> >> >
> >> > Changing the config back will make git-rebase -l work.
> >> >
> >> > So what would be the right procedure to shift the SVN source from an
> >> > rsync mirror to the original, without git-svn breaking?
> >>
> >> I think you'll have to
> >>
> >> -------------8<------------
> >> # remove stored revision db, since we're going to change all the commit ids
> >> rm .git/svn/git-svn/.rev_db.*
> >>
> >> # rewrite git-svn-id: lines
> >> cg-admin-rewritehist \
> >> --msg-filter \
> >> 'sed "s,file:///tmp/rsync-mirror,svn://the.svn.link/whatever,"'
> >>
> >> # recreate new revision db, and fetch updates, if any
> >> git-svn rebase
> >> -------------8<------------
> >
> > <shameless plug>
> > Or you use the just-rewritten version of it, git-filter-branch.
> > </shameless>
>
> Well, part of the reason I worked from an rsynced copy was to be able
> to repeat the experiment by just wasting a few hours of time each
> time, without wasting more bandwidth.
>
> What I arrived at was to use
> git-svn init -T trunk -t tags -b branches
> --rewrite-root svn://tug.org/texlive file:///mirror/texlive
> git-svn fetch --all
> [edit .git/config and replace the url and rewrite-root lines with a
> single url line pointing to the root]
> git-reset --hard [don't ask me why]
> and afterwards fetches worked online.
Yes, sorry for the late response, but --rewrite-root was written
with this purpose in mind.
> I liked the commit messages when using --no-metadata better than with
> --rewrite-root, but I found no way to get the resulting archive
> operative for git-svn rebase afterwards.
You should be able to use git-svn fetch and then plain git-rebase <remote>
> Could someone explain to me why git needs to know the upstream URL
> history, whether by --rewrite-root or rewrite-hist or
> git-filter-branch?
>
> I find this rather hard to understand, so I would like to get an idea
> where this fits naturally into the overall design of git, and how it
> makes sense.
Having the git-svn-id: lines in commits allows commits to be made to the
upstream SVN repository more easily and without user interaction or
configuraton. I put git-svn-id: in the commit objects themselves
because they're immutable and robust.
The URL portion of git-svn-id: is useful when I'm using many throwaway
branches and I've forgotten which upstream (SVN) branch I need to
dcommit against, and git-svn can easily figure it out for me
without needing to remember to use git-checkout --track on my part
or memorization.
It's possible to clone the refs and objects over to a new repository
over the native git:// protocol and have it fully usable from git-svn
without needing additional setup or having to copy the .git/config or
.git/svn (neither of which are transferred over the git protocol).
Cloning the refs is a bit of a pain these days because of the "remotes/"
convention in the name, but still possible.
The .rev_db files in .git/svn can get corrupted or deleted, and since
they're not managed by git, they're next to impossible to recover
if the git-svn-id: lines didn't exist.
I'll be the first to admit that the git-svn-id: lines are ugly, but
that's why I wrote "git svn log" :)
--
Eric Wong
^ permalink raw reply
* [PATCH 1/2] git-submodule: move cloning into a separate function
From: Lars Hjemli @ 2007-06-05 11:13 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git@vger.kernel.org
In-Reply-To: <46653DB2.997A3ABD@eudaptics.com>
This is just a simple refactoring of modules_init() with no change in
functionality.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
On Tue, 05 Jun 2007 12:40:50 +0200, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Lars Hjemli wrote:
>> + module_clone "$path" "$url" || exit $?
>
> Minor nit: The idiom that is commonly used in situations like this (see
> other git-* shell scripts):
>
> module_clone "$path" "$url" || exit
>
> because exit without argument uses the code of the last command
> executed.
>
Thanks, I'll follow up with matching changes to [patch 2/2].
git-submodule.sh | 44 ++++++++++++++++++++++++++++----------------
1 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 6ed5a6c..a89ea88 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -25,6 +25,33 @@ say()
fi
}
+
+#
+# Clone a submodule
+#
+module_clone()
+{
+ path=$1
+ url=$2
+
+ # If there already is a directory at the submodule path,
+ # expect it to be empty (since that is the default checkout
+ # action) and try to remove it.
+ # Note: if $path is a symlink to a directory the test will
+ # succeed but the rmdir will fail. We might want to fix this.
+ if test -d "$path"
+ then
+ rmdir "$path" 2>/dev/null ||
+ die "Directory '$path' exist, but is neither empty nor a git repository"
+ fi
+
+ test -e "$path" &&
+ die "A file already exist at path '$path'"
+
+ git-clone -n "$url" "$path" ||
+ die "Clone of submodule '$path' failed"
+}
+
#
# Run clone + checkout on missing submodules
#
@@ -40,20 +67,6 @@ modules_init()
# repository
test -d "$path"/.git && continue
- # If there already is a directory at the submodule path,
- # expect it to be empty (since that is the default checkout
- # action) and try to remove it.
- # Note: if $path is a symlink to a directory the test will
- # succeed but the rmdir will fail. We might want to fix this.
- if test -d "$path"
- then
- rmdir "$path" 2>/dev/null ||
- die "Directory '$path' exist, but is neither empty nor a git repository"
- fi
-
- test -e "$path" &&
- die "A file already exist at path '$path'"
-
url=$(GIT_CONFIG=.gitmodules git-config module."$path".url)
test -z "$url" &&
die "No url found for submodule '$path' in .gitmodules"
@@ -69,8 +82,7 @@ modules_init()
# logical modulename (if present) as key. But this would need
# another fallback mechanism if the module wasn't named.
- git-clone -n "$url" "$path" ||
- die "Clone of submodule '$path' failed"
+ module_clone "$path" "$url" || exit
(unset GIT_DIR && cd "$path" && git-checkout -q "$sha1") ||
die "Checkout of submodule '$path' failed"
--
1.5.2.841.gc9eafb
^ permalink raw reply related
* [PATCH 2/2] git-submodule: clone during update, not during init
From: Lars Hjemli @ 2007-06-05 11:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <11810357523233-git-send-email-hjemli@gmail.com>
This teaches 'git-submodule init' to register submodule paths and urls in
.git/config instead of actually cloning them. The cloning is now handled
as part of 'git-submodule update'.
With this change it is possible to specify preferred/alternate urls for
the submodules in .git/config before the submodules are cloned.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Changed from '|| exit @?' to '|| exit'.
Documentation/git-submodule.txt | 16 +++++++-------
git-submodule.sh | 41 ++++++++++++++++----------------------
t/t7400-submodule-basic.sh | 38 ++++++++++++++++++++++++-----------
3 files changed, 51 insertions(+), 44 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index cb0424f..f8fb80f 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -23,15 +23,15 @@ status::
repository. This command is the default command for git-submodule.
init::
- Initialize the submodules, i.e. clone the git repositories specified
- in the .gitmodules file and checkout the submodule commits specified
- in the index of the containing repository. This will make the
- submodules HEAD be detached.
+ Initialize the submodules, i.e. register in .git/config each submodule
+ path and url found in .gitmodules. The key used in git/config is
+ `submodule.$path.url`. This command does not alter existing information
+ in .git/config.
update::
- Update the initialized submodules, i.e. checkout the submodule commits
- specified in the index of the containing repository. This will make
- the submodules HEAD be detached.
+ Update the registered submodules, i.e. clone missing submodules and
+ checkout the commit specified in the index of the containing repository.
+ This will make the submodules HEAD be detached.
OPTIONS
@@ -50,7 +50,7 @@ OPTIONS
FILES
-----
-When cloning submodules, a .gitmodules file in the top-level directory
+When initializing submodules, a .gitmodules file in the top-level directory
of the containing repository is used to find the url of each submodule.
This file should be formatted in the same way as $GIR_DIR/config. The key
to each submodule url is "module.$path.url".
diff --git a/git-submodule.sh b/git-submodule.sh
index a89ea88..e7b6978 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -53,7 +53,7 @@ module_clone()
}
#
-# Run clone + checkout on missing submodules
+# Register submodules in .git/config
#
# $@ = requested paths (default to all)
#
@@ -62,37 +62,23 @@ modules_init()
git ls-files --stage -- "$@" | grep -e '^160000 ' |
while read mode sha1 stage path
do
- # Skip submodule paths that already contain a .git directory.
- # This will also trigger if $path is a symlink to a git
- # repository
- test -d "$path"/.git && continue
+ # Skip already registered paths
+ url=$(git-config submodule."$path".url)
+ test -z "$url" || continue
url=$(GIT_CONFIG=.gitmodules git-config module."$path".url)
test -z "$url" &&
die "No url found for submodule '$path' in .gitmodules"
- # MAYBE FIXME: this would be the place to check GIT_CONFIG
- # for a preferred url for this submodule, possibly like this:
- #
- # modname=$(GIT_CONFIG=.gitmodules git-config module."$path".name)
- # alturl=$(git-config module."$modname".url)
- #
- # This would let the versioned .gitmodules file use the submodule
- # path as key, while the unversioned GIT_CONFIG would use the
- # logical modulename (if present) as key. But this would need
- # another fallback mechanism if the module wasn't named.
+ git-config submodule."$path".url "$url" ||
+ die "Failed to register url for submodule '$path'"
- module_clone "$path" "$url" || exit
-
- (unset GIT_DIR && cd "$path" && git-checkout -q "$sha1") ||
- die "Checkout of submodule '$path' failed"
-
- say "Submodule '$path' initialized"
+ say "Submodule '$path' registered with url '$url'"
done
}
#
-# Checkout correct revision of each initialized submodule
+# Update each submodule path to correct revision, using clone and checkout as needed
#
# $@ = requested paths (default to all)
#
@@ -101,14 +87,21 @@ modules_update()
git ls-files --stage -- "$@" | grep -e '^160000 ' |
while read mode sha1 stage path
do
- if ! test -d "$path"/.git
+ url=$(git-config submodule."$path".url)
+ if test -z "$url"
then
# Only mention uninitialized submodules when its
# path have been specified
test "$#" != "0" &&
say "Submodule '$path' not initialized"
- continue;
+ continue
fi
+
+ if ! test -d "$path"/.git
+ then
+ module_clone "$path" "$url" || exit
+ fi
+
subsha1=$(unset GIT_DIR && cd "$path" &&
git-rev-parse --verify HEAD) ||
die "Unable to find current revision of submodule '$path'"
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 6274729..3940433 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -40,7 +40,7 @@ test_expect_success 'Prepare submodule testing' '
git-add a lib z &&
git-commit -m "super commit 1" &&
mv lib .subrepo &&
- GIT_CONFIG=.gitmodules git-config module.lib.url ./.subrepo
+ GIT_CONFIG=.gitmodules git-config module.lib.url git://example.com/lib.git
'
test_expect_success 'status should only print one line' '
@@ -52,41 +52,55 @@ test_expect_success 'status should initially be "missing"' '
git-submodule status | grep "^-$rev1"
'
-test_expect_success 'init should fail when path is used by a file' '
+test_expect_success 'init should register submodule url in .git/config' '
+ git-submodule init &&
+ url=$(git-config submodule.lib.url) &&
+ if test "$url" != "git://example.com/lib.git"
+ then
+ echo "[OOPS] init succeeded but submodule url is wrong"
+ false
+ elif ! git-config submodule.lib.url ./.subrepo
+ then
+ echo "[OOPS] init succeeded but update of url failed"
+ false
+ fi
+'
+
+test_expect_success 'update should fail when path is used by a file' '
echo "hello" >lib &&
- if git-submodule init
+ if git-submodule update
then
- echo "[OOPS] init should have failed"
+ echo "[OOPS] update should have failed"
false
elif test -f lib && test "$(cat lib)" != "hello"
then
- echo "[OOPS] init failed but lib file was molested"
+ echo "[OOPS] update failed but lib file was molested"
false
else
rm lib
fi
'
-test_expect_success 'init should fail when path is used by a nonempty directory' '
+test_expect_success 'update should fail when path is used by a nonempty directory' '
mkdir lib &&
echo "hello" >lib/a &&
- if git-submodule init
+ if git-submodule update
then
- echo "[OOPS] init should have failed"
+ echo "[OOPS] update should have failed"
false
elif test "$(cat lib/a)" != "hello"
then
- echo "[OOPS] init failed but lib/a was molested"
+ echo "[OOPS] update failed but lib/a was molested"
false
else
rm lib/a
fi
'
-test_expect_success 'init should work when path is an empty dir' '
+test_expect_success 'update should work when path is an empty dir' '
rm -rf lib &&
mkdir lib &&
- git-submodule init &&
+ git-submodule update &&
head=$(cd lib && git-rev-parse HEAD) &&
if test -z "$head"
then
@@ -99,7 +113,7 @@ test_expect_success 'init should work when path is an empty dir' '
fi
'
-test_expect_success 'status should be "up-to-date" after init' '
+test_expect_success 'status should be "up-to-date" after update' '
git-submodule status | grep "^ $rev1"
'
--
1.5.2.841.gc9eafb
^ permalink raw reply related
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Theodore Tso @ 2007-06-05 11:19 UTC (permalink / raw)
To: Joel Becker
Cc: Linus Torvalds, Olivier Galibert, Thomas Glanzmann, Bryan Childs,
git
In-Reply-To: <20070604223003.GJ6528@ca-server1.us.oracle.com>
On Mon, Jun 04, 2007 at 03:30:03PM -0700, Joel Becker wrote:
> It survives because it is well-known. Everyone expects it to
> break. ocfs2 has an "ALL" branch that is everything we have working,
> sort of a "test this bleeding edge" thing. It gets rebased all the
> time, and everyone knows that they can't trust it to update linearly.
> Other developers have similar things in their repositories.
I wonder if it would be useful to be able to be able to flag a
branches as "jumping around a lot", where this flag would be
downloaded from another repository when it is cloned, so that a naive
user could get some kind of warning before committing a patch on top
of one of these branches that is known jump around.
"This branch gets rebased all the time and is really meant for
testing. If you really want to commit this changeset, please
configure yourself for expert mode or use the --force."
Or maybe just a warning, ala what we do with detached heads.
- Ted
^ permalink raw reply
* Re: git branch --track and remote branches with / in the name
From: Gerrit Pape @ 2007-06-05 11:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4plmd7kg.fsf@assigned-by-dhcp.cox.net>
On Tue, Jun 05, 2007 at 03:22:39AM -0700, Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> writes:
> > Hi, the --track option to git branch or git checkout doesn't work for
> > remote branches that contain a slash in the name:
> Indeed the "find matching remote tracking branch" code was
> somewhat sloppy and needlessly complex/clever.
>
> How about this patch?
Works fine for me, including the selftest. Thanks, Gerrit.
^ permalink raw reply
* Re: git "manifest" command
From: Martin Waitz @ 2007-06-05 11:44 UTC (permalink / raw)
To: Csaba Henk; +Cc: git
In-Reply-To: <slrnf6ad74.4vk.csaba-ml@beastie.creo.hu>
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]
hoi :)
On Tue, Jun 05, 2007 at 10:03:18AM +0000, Csaba Henk wrote:
> I was lacking a "manifest" like command, one which operates like
> git-ls-files just you can use it with arbitrary tree-ish (or, put it
> otherwise, one which opererates like git-ls-tree just acts recursively).
like git ls-tree -r?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git "manifest" command
From: Csaba Henk @ 2007-06-05 12:18 UTC (permalink / raw)
To: git
In-Reply-To: <20070605114454.GI16637@admingilde.org>
On 2007-06-05, Martin Waitz <tali@admingilde.org> wrote:
> like git ls-tree -r?
Yes. I knew this functionality must be there somewehere...
Thanks.
Csaba
^ permalink raw reply
* [PATCH] add git-filter-branch to .gitignore
From: Matthias Lederhofer @ 2007-06-05 13:26 UTC (permalink / raw)
To: git
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 15aed70..ff907de 100644
--- a/.gitignore
+++ b/.gitignore
@@ -40,6 +40,7 @@ git-fast-import
git-fetch
git-fetch--tool
git-fetch-pack
+git-filter-branch
git-findtags
git-fmt-merge-msg
git-for-each-ref
--
1.5.2.1.122.g91581
^ permalink raw reply related
* [PATCH] make clean should remove all the test programs too
From: Matthias Lederhofer @ 2007-06-05 13:43 UTC (permalink / raw)
To: git
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
There seems to be another test program lying around which is not
included in the Makefile: dump-tree-cache.c. I've no idea what this
does or what it is used for, it was just dropped from the Makefile
during some cleanup. If it should stay I'd recommend to do:
- git mv dump-cache-tree.c test-dump-cache-trees.c
- add dump-cache-trees to TEST_PROGRAMS
- s/dump-cache-tree/dump-cache-trees/ in .gitignore
---
Makefile | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 69f3b66..cd620b0 100644
--- a/Makefile
+++ b/Makefile
@@ -1052,8 +1052,9 @@ dist-doc:
clean:
rm -f *.o mozilla-sha1/*.o arm/*.o ppc/*.o compat/*.o xdiff/*.o \
- test-chmtime$X test-genrandom$X $(LIB_FILE) $(XDIFF_LIB)
+ $(LIB_FILE) $(XDIFF_LIB)
rm -f $(ALL_PROGRAMS) $(BUILT_INS) git$X
+ rm -f $(TEST_PROGRAMS)
rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
rm -rf autom4te.cache
rm -f configure config.log config.mak.autogen config.mak.append config.status config.cache
--
1.5.2.1.122.g91581
^ permalink raw reply related
* Re: [PATCH] Add git-filter-branch
From: Johannes Schindelin @ 2007-06-05 13:55 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <20070605103421.GB16160@diku.dk>
Hi,
On Tue, 5 Jun 2007, Jonas Fonseca wrote:
> Junio C Hamano <gitster@pobox.com> wrote Tue, Jun 05, 2007:
>
> > The one in filter-branch that bit you does not dereference 'i'.
> > I am reasonably sure if you fix it to read:
> >
> > i=$(( $i+1 ))
> >
> > dash would grok it.
>
> This works here. Even without the spaces.
Thanks for fixing up so quickly after me.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] filter-branch: prevent filters from reading from stdin
From: Matthias Lederhofer @ 2007-06-05 14:12 UTC (permalink / raw)
To: git
stdin is the list of commits when the env, tree and index
filter are executed. The filters are not supposed to read
anything from stdin so the best is to give them /dev/null
for reading.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
git-filter-branch.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index f4cfbea..e220b85 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -352,21 +352,21 @@ while read commit; do
eval "$(set_ident AUTHOR <../commit)"
eval "$(set_ident COMMITTER <../commit)"
- eval "$filter_env"
+ eval "$filter_env" < /dev/null
if [ "$filter_tree" ]; then
git-checkout-index -f -u -a
# files that $commit removed are now still in the working tree;
# remove them, else they would be added again
git-ls-files -z --others | xargs -0 rm -f
- eval "$filter_tree"
+ eval "$filter_tree" < /dev/null
git-diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \
xargs -0 git-update-index --add --replace --remove
git-ls-files -z --others | \
xargs -0 git-update-index --add --replace --remove
fi
- eval "$filter_index"
+ eval "$filter_index" < /dev/null
parentstr=
for parent in $(get_parents $commit); do
--
1.5.2.1.120.g3877-dirty
^ permalink raw reply related
* Re: [PATCH] Add git-filter-branch
From: Johannes Schindelin @ 2007-06-05 15:58 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <46650A58.4934C07C@eudaptics.com>
Hi,
On Tue, 5 Jun 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
> > On Mon, 4 Jun 2007, Johannes Sixt wrote:
> > > But this makes only sense if you have a linear history. Consider this
> > > history, where you want to rewrite the commits that are only on branch
> > > 'next':
> > >
> > > --A--B--C--D--E--F--G--H <- master
> > > \ \ \ \ \ \ \ \
> > > X--o--o--o--o--o--o--o--o <- next
> > >
> > > How would you go about with the current calling convention?
> >
> > Are you actually sure that this scenario makes sense? When is the last
> > time you wanted to filter a branch?
>
> Oh, this makes a lot of sense. For example after I've imported a CVS
> repository I had installed grafts for a number of merges that were made
> in CVS (but we all know that CVS doesn't record them, so I did that
> manually this way). That would be the merge commits in 'next' of the
> example above. Now a simple
>
> git filter-branch -k master new-next
>
> could "implant" the grafts into the commits. In this scenario I don't
> need to rewrite 'master' because I know in advance that nothing would
> actually be rewritten.
>
> (Since 'master' was about 8000 commits I really didn't want to wait
> until the no-ops would be completed, so I did it by actually fixing
> cg-admin-rewritehist to not complain about the unmapped parents.)
Okay, then. Are you okay with keeping the same options? (See proposed
patch below.)
Just out of curiousity, do you have any timing data?
Ciao,
Dscho
-- snipsnap --
[PATCH] filter-branch: fix behaviour of '-k'
The option '-k' says that the given commit and _all_ of its ancestors
are kept as-is.
However, if a to-be-rewritten commit branched from an ancestor of an
ancestor of a commit given with '-k', filter-branch would fail.
Example:
A - B
\
C
If filter-branch was called with '-k B -s C', it would actually keep
B (and A as its parent), but would rewrite C, and its parent.
Noticed by Johannes Sixt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-filter-branch.sh | 29 +++++++++++++++++------------
t/t7003-filter-branch.sh | 9 +++++++++
2 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 0c8a7df..6807782 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -327,11 +327,6 @@ ret=0
mkdir ../map # map old->new commit ids for rewriting parents
-# seed with identity mappings for the parents where we start off
-for commit in $unchanged; do
- echo $commit > ../map/$commit
-done
-
git-rev-list --reverse --topo-order $srcbranch --not $unchanged >../revs
commits=$(cat ../revs | wc -l | tr -d " ")
@@ -372,7 +367,8 @@ while read commit; do
parentstr="$parentstr -p $reparent"
done
else
- die "assertion failed: parent $parent for commit $commit not found in rewritten ones"
+ # if it was not rewritten, take the original
+ parentstr="$parentstr -p $parent"
fi
done
if [ "$filter_parent" ]; then
@@ -385,12 +381,21 @@ while read commit; do
tee ../map/$commit
done <../revs
-git-update-ref refs/heads/"$dstbranch" $(head -n 1 ../map/$(tail -n 1 ../revs))
-if [ "$(cat ../map/$(tail -n 1 ../revs) | wc -l)" -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/$(tail -n 1 ../revs) >&2
- ret=1
-fi
+src_head=$(tail -n 1 ../revs)
+target_head=$(head -n 1 ../map/$src_head)
+case "$target_head" in
+'')
+ echo Nothing rewritten
+ ;;
+*)
+ git-update-ref refs/heads/"$dstbranch" $target_head
+ if [ $(cat ../map/$src_head | wc -l) -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
+ ;;
+esac
if [ "$filter_tag_name" ]; then
git-for-each-ref --format='%(objectname) %(objecttype) %(refname)' refs/tags |
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 9a4dae4..520963a 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -44,4 +44,13 @@ test_expect_success 'test that the file was renamed' '
test d = $(git show H3:doh)
'
+git tag oldD H3~4
+test_expect_success 'rewrite one branch, keeping a side branch' '
+ git-filter-branch --tree-filter "mv b boh || :" -k D -s oldD modD
+'
+
+test_expect_success 'common ancestor is still common (unchanged)' '
+ test "$(git-merge-base modD D)" = "$(git-rev-parse B)"
+'
+
test_done
--
1.5.2.1.2627.g8eec-dirty
^ permalink raw reply related
* Re: [PATCH] filter-branch: prevent filters from reading from stdin
From: Johannes Schindelin @ 2007-06-05 16:10 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20070605141208.GA23605@moooo.ath.cx>
Hi,
On Tue, 5 Jun 2007, Matthias Lederhofer wrote:
> stdin is the list of commits when the env, tree and index
> filter are executed. The filters are not supposed to read
> anything from stdin so the best is to give them /dev/null
> for reading.
ACK. After chatting with Matthias on IRC, I agree that there is more
damage than benefit from being able to (accidentally) take stdin in these
filters.
Ciao,
Dscho
^ permalink raw reply
* Git requires zip?
From: Linus Torvalds @ 2007-06-05 16:16 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
It really shouldn't, but "make test" seems very unhappy if the machine
doesn't have it, and I don't see anything that disables the tests for that
case..
Linus
^ permalink raw reply
* Re: clarify git clone --local --shared --reference
From: Brandon Casey @ 2007-06-05 16:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070605045008.GC9513@spearce.org>
Shawn O. Pearce wrote:
> Brandon Casey <casey@nrlssc.navy.mil> wrote:
[snip]
>> 2) Does --shared imply shared write access? Does --local?
>> I'll point out that git-init has an option with the same name.
>
> No. --shared means something entirely different in git-clone
> than it does in git-init.
This did cause the thought that git-init --shared and git-clone --shared
may be pairs to be used together in some special way.
ok. Rather selfish "sharing" in my opinion :)
--reference did not cause any confusion and implied to me exactly
what it does: Use supplied repository as a reference for objects
which cannot be resolved locally.
> The --shared here implies adds the source repository to the new
> repository's .git/objects/info/alternates. This means that the
> new clone doesn't copy the object database; instead it just accesses
> the source repository when it needs data.
>
> This exposes two risks:
>
> a) Don't delete the source repository. If you delete the source
> repository then the clone repository is "corrupt" as it won't be
> able to access object data.
>
> b) Don't repack the source repository without accounting for the
> refs and reflogs of all --shared repositories that came from it.
> Otherwise you may delete objects that the source repository no
> longer needs, but that one or more of the --shared repositories
> still needs.
How should this be accomplished? Does this mean never run
git-gc/git-repack on the source repository? Or is there a way to
cause the sharing repositories to copy over objects no longer
required by the source repository?
[snip]
>> 4) is space savings obtained only at initial clone? or is it on going?
>> does a future git pull from the source repository create new hard
>> links where possible?
>
> Only on initial clone. Later pulls will copy. You can try using
> git-relink to redo the hardlinks after the pull.
How about with --shared? Particularly with a fast-forward not much
would need to be copied over. Do later pulls into a repository with
configured objects/info/alternates take advantage of space savings
when possible?
If the answer above is "yes", then this brings up an interesting use
case. I assume that clone, fetch, etc follow the alternates of the
source repository? Otherwise a --shared repository would be unclone-able
right? And only pull-able from the source repository? So if that is the
case (that remote alternates are followed), then a group of developers
could add all of the other developers to their alternates list (if
multiple alternates are supported) and reference their objects when
possible. To the extent that it is possible, each developer would end up
only storing their commit objects. This would then create a distributed
repository.
Of course, this new distributed repository may be somewhat fragile since
the entire thing could become unusable if any portion was corrupted.
Just because you can do a thing, doesn't mean you should.
thanks for your excellent reply,
-brandon
^ permalink raw reply
* [PATCH] filter-branch: always export GIT_DIR if it is set
From: Matthias Lederhofer @ 2007-06-05 16:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodjudei2.fsf@assigned-by-dhcp.cox.net>
Currently filter-branch exports GIT_DIR only if it is a
relative path but git-sh-setup might also set GIT_DIR to an
absolute path that is not exported yet. Additionally we need
to export GIT_WORK_TREE with GIT_DIR to ensure that the
current working directory is used as working tree even for
bare repositories.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
Junio C Hamano <gitster@pobox.com> wrote:
> Hmph.
>
> When this series is applied on top of 'next' (or whatever
> contains t7003-filter-branch.sh), this seems to break it quite
> badly.
With the GIT_WORK_TREE patch series a relative path in GIT_DIR is
expanded to an absolute path. Therefore
GIT_DIR=$(GIT_DIR=.git git rev-parse --git-dir)
in git-sh-setup will give the full path to the repository.
git-filter-branch exports GIT_DIR only if the path is relative. In
consequence GIT_DIR was not set at all and the following git commands
failed. Additionally GIT_WORK_TREE has to be exported because to make
sure that the current directory is used as working tree even for bare
repositories.
I merged the worktree branch to next and applied the patch, all tests
passed.
This problem reveals a small change which might cause trouble with other
scripts. I looked at the git repository and found no other script which
should have problems with this series. With
$ git grep -e export --and -e GIT_DIR
I found:
Documentation/install-doc-quick.sh
git-clone.sh
git-instaweb.sh
These do not need a working tree.
git-cvsexportcommit.perl
git apply is used with GIT_DIR='', this forces git-apply not to
use the git repository.
I'm not sure if any other script out there tries to do this. Perhaps we
should just keep the old behaviour and use the current directory as
working tree when the repository name ends in /.git even though
core.bare is true?
---
git-filter-branch.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 0c8a7df..f4cfbea 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -313,9 +313,12 @@ workdir="$(pwd)"
case "$GIT_DIR" in
/*)
+ export GIT_DIR
+ export GIT_WORK_TREE=.
;;
*)
export GIT_DIR="$(pwd)/../../$GIT_DIR"
+ export GIT_WORK_TREE=.
;;
esac
--
1.5.2.1.120.g3877-dirty
^ permalink raw reply related
* [PATCH] filter-branch: use sh -c instead of eval
From: Matthias Lederhofer @ 2007-06-05 16:57 UTC (permalink / raw)
To: git
If filters use variables with the same name as variables
used in the script the script breaks. Executing the filters
in a separate process prevents accidential modification of
the variables in the main process.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
This one goes on top of the last patch, adding the < /dev/null.
Example:
% git filter-branch --tree-filter 'commit=foo' bar
94ddd5151901a2b62820facc1bcf578abf842c8a (1/2) fatal: ambiguous argument 'foo': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
fatal: ambiguous argument 'foo': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
94ddd5151901a2b62820facc1bcf578abf842c8a
[..]
head: cannot open `../map/81208e18e22e0f1c7c73a4ea5bbd5150c0ee65c2'
for reading: No such file or directory
usage: git-update-ref [-m <reason>] (-d <refname> <value> | [--no-deref] <refname> <value> [<oldval>])
---
git-filter-branch.sh | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 73e7c01..b446011 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -54,9 +54,9 @@
# 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
+# argument is always evaluated in shell using sh -c "$filter". 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
@@ -349,21 +349,21 @@ while read commit; do
eval "$(set_ident AUTHOR <../commit)"
eval "$(set_ident COMMITTER <../commit)"
- eval "$filter_env" < /dev/null
+ sh -c "$filter_env" < /dev/null
if [ "$filter_tree" ]; then
git-checkout-index -f -u -a
# files that $commit removed are now still in the working tree;
# remove them, else they would be added again
git-ls-files -z --others | xargs -0 rm -f
- eval "$filter_tree" < /dev/null
+ sh -c "$filter_tree" < /dev/null
git-diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \
xargs -0 git-update-index --add --replace --remove
git-ls-files -z --others | \
xargs -0 git-update-index --add --replace --remove
fi
- eval "$filter_index" < /dev/null
+ sh -c "$filter_index" < /dev/null
parentstr=
for parent in $(get_parents $commit); do
@@ -376,11 +376,11 @@ while read commit; do
fi
done
if [ "$filter_parent" ]; then
- parentstr="$(echo "$parentstr" | eval "$filter_parent")"
+ parentstr="$(echo "$parentstr" | sh -c "$filter_parent")"
fi
sed -e '1,/^$/d' <../commit | \
- eval "$filter_msg" | \
+ sh -c "$filter_msg" | \
sh -c "$filter_commit" git-commit-tree $(git-write-tree) $parentstr | \
tee ../map/$commit
done <../revs
@@ -410,7 +410,7 @@ if [ "$filter_tag_name" ]; then
[ -f "../map/$sha1" ] || continue
new_sha1="$(cat "../map/$sha1")"
export GIT_COMMIT="$sha1"
- new_ref="$(echo "$ref" | eval "$filter_tag_name")"
+ new_ref="$(echo "$ref" | sh -c "$filter_tag_name")"
echo "$ref -> $new_ref ($sha1 -> $new_sha1)"
--
1.5.2.1.860.g78ab5-dirty
^ permalink raw reply related
* git-svn fetch hangs or gives broken pipe on a specific "branch"
From: Bill Priest @ 2007-06-05 16:53 UTC (permalink / raw)
To: git
All,
I'm trying to use git to try out its merging
capabilities as I'm not "happy" w/ what svn provides.
From Linus discussion at google (from YouTube) he
indicated that many people use it to manage merges
between branches and then push back into the
subversion repository. I'd like to do this as
converting to git from svn (less than 6 months after
converting from cvs to svn isn't an easy sell to
management).
We have a small team (~5 developers) and a fairly
small project (a few hundred files). From a web
site/wiki I found the following instructions (tweaked
for my setup).
I downloaded the latest release of git 1.5.2 and built
it on RHEL box. Subversion version is 1.4.2. The
repository and the git working directory are on the
same machine (taking networking out of the picture).
mkdir git_test
cd git_test
git-svn init -t tags -b branches -T trunk "my URL"
Initialized empty Git repository in .git/
git-svn fetch
all tags were processed w/o error AFAICT; the first
branch it tries to work on causes either a hang or a
"Broken Pipe". I changed from an http:// to svn:// on
the git-svn init and everything worked correctly.
This would seem to indicate some type of problem w/
apache/httpd problem. I looked in the httpd logs and
didn't see any errors.
Is this a known problem?
TIA,
Bill
____________________________________________________________________________________
Get the Yahoo! toolbar and be alerted to new email wherever you're surfing.
http://new.toolbar.yahoo.com/toolbar/features/mail/index.php
^ permalink raw reply
* "stgit rebase" should check for errors before changing tree
From: Andrey Borzenkov @ 2007-06-05 16:59 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
{pts/0}% stg rebase 2.6.22-rc4
Checking for changes in the working directory... done
Popping all applied patches... done
Rebasing to "2.6.22-rc4"...
stg rebase: Unknown revision: 2.6.22-rc4^{commit}
well, now user is forced to reapply (push) all patches by hand, "stg rebase"
lost history and state. It probably should check before popping patches.
stgit-0.12.1
-andrey
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] $EMAIL is a last resort fallback, as it's system-wide.
From: Pierre Habouzit @ 2007-06-05 16:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pierre Habouzit
Rationale: $EMAIL is a system-wide setup that is used for many many many
applications. If the git user chose a specific user.email setup, then _this_
should be honoured rather than $EMAIL.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
ident.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ident.c b/ident.c
index 69a04b8..3d49608 100644
--- a/ident.c
+++ b/ident.c
@@ -196,9 +196,9 @@ const char *fmt_ident(const char *name, const char *email,
if (!name)
name = git_default_name;
if (!email)
- email = getenv("EMAIL");
- if (!email)
email = git_default_email;
+ if (!email)
+ email = getenv("EMAIL");
if (!*name) {
struct passwd *pw;
--
1.5.2.1
^ permalink raw reply related
* Re: git "manifest" command
From: Matthias Lederhofer @ 2007-06-05 17:11 UTC (permalink / raw)
To: Csaba Henk; +Cc: git
In-Reply-To: <slrnf6al3s.4vk.csaba-ml@beastie.creo.hu>
Csaba Henk <csaba-ml@creo.hu> wrote:
> On 2007-06-05, Martin Waitz <tali@admingilde.org> wrote:
> > like git ls-tree -r?
>
> Yes. I knew this functionality must be there somewehere...
If you use this from a script note that ls-tree shows the subdirectory
of a tree that corresponds to the current directory in the repository.
This one should always show the full tree:
$ git ls-tree --full-name -r HEAD $(git rev-parse --show-cdup)
^ permalink raw reply
* Re: Git requires zip?
From: Johannes Schindelin @ 2007-06-05 17:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706050908520.23741@woody.linux-foundation.org>
Hi,
On Tue, 5 Jun 2007, Linus Torvalds wrote:
> It really shouldn't, but "make test" seems very unhappy if the machine
> doesn't have it, and I don't see anything that disables the tests for
> that case..
I seem to remember that I patched it already.
http://thread.gmane.org/gmane.comp.version-control.git/46854/focus=46899
Unfortunately, the patch was incorrect, and I forgot to do it properly.
Will try this afternoon.
Sorry,
Dscho
^ permalink raw reply
* [PATCH] +test-sha1 to .gitignore
From: Randal L. Schwartz @ 2007-06-05 17:24 UTC (permalink / raw)
To: git
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 15aed70..8e75c99 100644
--- a/.gitignore
+++ b/.gitignore
@@ -151,6 +151,7 @@ test-delta
test-dump-cache-tree
test-genrandom
test-match-trees
+test-sha1
common-cmds.h
*.tar.gz
*.dsc
--
1.5.2.1.111.gc94b
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply related
* Re: [PATCH] filter-branch: always export GIT_DIR if it is set
From: Johannes Schindelin @ 2007-06-05 17:27 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Junio C Hamano, git
In-Reply-To: <20070605164957.GA12358@moooo.ath.cx>
Hi,
On Tue, 5 Jun 2007, Matthias Lederhofer wrote:
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index 0c8a7df..f4cfbea 100644
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -313,9 +313,12 @@ workdir="$(pwd)"
>
> case "$GIT_DIR" in
> /*)
> + export GIT_DIR
> + export GIT_WORK_TREE=.
> ;;
Doesn't it strike somebody else as intrusive, if GIT_WORK_TREE has to
touch that many places?
IMHO there should be a less intrusive, and possibly simpler, way to do it.
I am not at all interested in that feature, and I don't want to suffer
bugs from it either.
Ciao,
Dscho
^ 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