* Re: [PATCH 4/4] Add new --diff-opts/-O flag to diff- and status-related commands.
From: Yann Dirson @ 2007-06-05 6:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0706041515l6114a015ye45d40478cc0e3ef@mail.gmail.com>
On Mon, Jun 04, 2007 at 11:15:23PM +0100, Catalin Marinas wrote:
> On 31/05/07, Yann Dirson <ydirson@altern.org> wrote:
> >This new flag allows to pass arbitrary flags to the git-diff calls
> >underlying several StGIT commands. It can be used to pass flags
> >affecting both diff- and status-generating commands (eg. -M or -C), or
> >flags only affecting diff-generating ones (eg. --color, --binary).
> >
> >It supercedes --binary for commands where it was allowed,
> >'-O --binary' is now available for the same functionality.
>
> BTW, should we add --binary by default to export and mail? Do you see
> any problem with this?
>
> Another idea would be to add support for a [stgit "options"] section
> with entries like "mail = -O --binary".
Right, but we have to think how flags in the config file interact with
flags on command line.
- does the command line shadow the config file completely (ie. "-O ''"
can be used for to not pass any flags), in which case, each time we
want a particular flag we need to pass all default ones again ?
- does the command line add to the flags specified from config file,
in which case we still need a way to override those ; I have 2 ideas
here: a flag that resets opts to '', or a flag to remove specific
flags (eg. if we have '--binary -w' in the config and we want
'--binary -C', we can say something like '-O -C --no-diff-opts -w').
Also useful would be to have different config defaults for the case
where we go through the pager, but then we may have to guess when the
pager will trigger (or maybe we can ask pydoc if the pager will
trigger ?).
Best regards,
--
Yann
^ permalink raw reply
* Re: [PATCH] Add git-filter-branch
From: Johannes Sixt @ 2007-06-05 7:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706041850350.4046@racer.site>
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.)
> In any case, for such a degenerated test case I would rather try to limit
> filtering in the filter expression. Remember: you don't have to change
> _every_ commit.
I don't think that this is a degenerate case. See the example above.
Please observe that the only reasonable way to limit the commits to
rewrite is by giving some --not arguments to the rev-list. The filter
scriptlets themselves have no easy way to tell whether a commit should
be rewritten or not. They just rewrite - with the final result perhaps
ending up identical to the original; but no labor was saved.
-- Hannes
^ permalink raw reply
* Re: [PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree
From: Junio C Hamano @ 2007-06-05 7:52 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Git Mailing List, Nguyen Thai Ngoc Duy
In-Reply-To: <20070603144714.GD20061@moooo.ath.cx>
Hmph.
When this series is applied on top of 'next' (or whatever
contains t7003-filter-branch.sh), this seems to break it quite
badly.
^ permalink raw reply
* git-svn and googlecode.com?
From: Rogan Dawes @ 2007-06-05 8:11 UTC (permalink / raw)
To: Git Mailing List
Hi,
Thanks to Martin, I got git svnimport working on the Spring Rich Client
Sourceforge repository. The published SVN checkout command line was:
svn co https://spring-rich-c.svn.sourceforge.net/svnroot/spring-rich-c \
spring-rich-c
This translated into a git svnimport invocation of:
git-svnimport -i -v -o origin -T trunk/spring-richclient -t tags \
-b branches \
https://spring-rich-c.svn.sourceforge.net/svnroot/spring-rich-c/
which works very well.
From this I assume that the usual translation from Sourceforge
published command lines works something like:
git svnimport -i -v -o origin -T trunk/<first path component> -t tags \
-b branches <URL>
Using a similar approach for a repo at code.google.com, I tried:
(Original) svn checkout http://webgoat.googlecode.com/svn/trunk/ webgoat
(Funny, the initial path component had a space in it?!)
0 $ git-svn clone -T "trunk/ webgoat"
https://webgoat.googlecode.com/svn/trunk/
Initialized empty Git repository in .git/
Using higher level of URL: https://webgoat.googlecode.com/svn/trunk =>
https://webgoat.googlecode.com/svn
W: Ignoring error from SVN, path probably does not exist: (175002): RA
layer request failed: REPORT request failed on '/svn/!svn/bc/100':
REPORT of '/svn/!svn/bc/100': 200 OK (https://webgoat.googlecode.com)
Path 'trunk/trunk/ webgoat' was probably deleted:
RA layer request failed: REPORT request failed on '/svn/!svn/bc/126':
REPORT of '/svn/!svn/bc/126': 200 OK (https://webgoat.googlecode.com)
Will attempt to follow revisions r101 .. r126 committed before the deletion
0 $
This didn't actually do anything other than creating the .git directory
structure, and creating one svn related file, even though it exited with
a zero status (the prompt above includes the exit status of the previous
command), and gave no diagnostics or error messages (other than "Using
higher level . . . ")
1 $ find .git
.git
.git/branches
.git/config
.git/description
.git/HEAD
.git/hooks
.git/hooks/applypatch-msg
.git/hooks/commit-msg
.git/hooks/post-commit
.git/hooks/post-receive
.git/hooks/post-update
.git/hooks/pre-applypatch
.git/hooks/pre-commit
.git/hooks/pre-rebase
.git/hooks/update
.git/info
.git/info/exclude
.git/objects
.git/objects/info
.git/objects/pack
.git/refs
.git/refs/heads
.git/refs/tags
.git/remotes
.git/svn
.git/svn/.metadata
.git/svn/trunk
.git/svn/trunk/.rev_db.4033779f-a91e-0410-96ef-6bf7bf53c507
However, the following command line does seem to work:
git-svn clone -T "trunk/ webgoat" https://webgoat.googlecode.com/svn/
Note that I manually removed the "trunk" component from the URL. This
suggests that there is something missing in the automatic "Using higher
level" detection code.
Hope this helps someone diagnose this bug, as well as use git for
accessing GoogleCode projects in the future.
Rogan
^ permalink raw reply
* Re: git-p4import.py robustness changes
From: Simon Hausmann @ 2007-06-05 7:21 UTC (permalink / raw)
To: Scott Lamb; +Cc: git
In-Reply-To: <99C09A45-EACF-43C0-8EF6-85450B109BF6@slamb.org>
[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]
On Monday 04 June 2007 09:19:56 Scott Lamb wrote:
> On Jun 3, 2007, at 10:54 PM, Shawn O. Pearce wrote:
> > I think writing data to fast-import is much easier than running
> > the raw Git commands, especially when you are talking about an
> > import engine where you need to set all of the special environment
> > variables for git-commit-tree or git-tag to do its job properly.
> > Its a good tool that simply doesn't get enough use, partly because
> > nobody is using it...
>
> Yeah, I'm sold. I read git-p4 more thoroughly and tried it out...it's
> pretty nice. The P4Sync command has a simpler, more trustworthy flow
> than git-p4import.py.
>
> On the Perforce side, I particularly like the use of "p4 print" to
> grab the files instead of "p4 sync". It avoids playing weird games
> with the client - I think nothing good can come of git-p4import.py's
> "p4 sync -k" and symlinks to map multiple branches into the same
> directory, which is not the Perforce way. Makes me nervous that
> what's submitted to git won't be the same as what's in the Perforce
> depot.
>
> I would have thought launching a "p4 print" on each file would be
> horribly slow with the network latency of each request, but...well,
> apparently not.
I've found it to be fast enough for "standard software development". When
importing big changes like integrations of an entire branch then it naturally
slows down. The workaround me and my colleague have come up with is to
combine git-p4 usage with the regular git protocol:
For imports of simple projects from perforce the direct use of git-p4 clone
and sync/rebase is good enough.
For big projects we have set up a dedicated (recycled old) machine that
continuously imports from the perforce server. That makes the initial clone
very fast thanks to the use of the git protocol, it still allows imports from
perforce afterwards and when the developer syncs the chances are very high
that the dedicated machine already imported the necessary changes/objects
from the perforce server and the faster git protocol instead of "p4 print" on
a lot of files can be used.
In order to avoid that machine constantly polling the p4 server we've come up
with a neat little trick by adding a change-commit trigger on the p4 server
that consists of a little perl script that just sends a single udp packet
with the latest change number as notification to the git machine, which upon
reception imports then.
That is why git-p4 sync/rebase call "git fetch" by default (configurable
through config key) if there is an origin remote present.
> Maybe I'll work up git-p4 patches for subcommand error handling, like
> my git-p4import.py ones. And fix some style - seriously, who puts
> semicolons at the end of Python commands? *grumble*
I'd be more than happy to apply style patches. I'm not a very experienced
python programmer and I admit that I certainly lack the style there :)
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Fix typo in remote branch example in git user manual
From: Gerrit Pape @ 2007-06-05 8:47 UTC (permalink / raw)
To: Junio C Hamano, git
In Documentation/user-manual.txt the example
$ git checkout --track -b origin/maint maint
under "Getting updates with git pull", should read
$ git checkout --track -b maint origin/maint
This was noticed by Ron, and reported through
http://bugs.debian.org/427502
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
Documentation/user-manual.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 7eaafa8..342de6d 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1682,7 +1682,7 @@ automatically set the default remote branch to pull from at the time
that a branch is created:
-------------------------------------------------
-$ git checkout --track -b origin/maint maint
+$ git checkout --track -b maint origin/maint
-------------------------------------------------
In addition to saving you keystrokes, "git pull" also helps you by
--
1.5.2
^ permalink raw reply related
* git branch --track and remote branches with / in the name
From: Gerrit Pape @ 2007-06-05 9:04 UTC (permalink / raw)
To: git
Hi, the --track option to git branch or git checkout doesn't work for
remote branches that contain a slash in the name:
$ tail -n6 .git/config
[remote "origin"]
url = /tmp/repo
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
$ git branch -r
origin/HEAD
origin/b
origin/foo/b
origin/master
$ git branch --track b origin/b
Branch b set up to track remote branch refs/remotes/origin/b.
$ git branch --track foo/b origin/foo/b
$ tail -n6 .git/config
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "b"]
remote = origin
merge = refs/heads/b
$
Regards, Gerrit.
^ permalink raw reply
* Re: git-svn and googlecode.com?
From: Andy Parkins @ 2007-06-05 9:05 UTC (permalink / raw)
To: git; +Cc: Rogan Dawes
In-Reply-To: <46651AAD.4010705@dawes.za.net>
On Tuesday 2007 June 05, Rogan Dawes wrote:
> (Original) svn checkout http://webgoat.googlecode.com/svn/trunk/ webgoat
>
> (Funny, the initial path component had a space in it?!)
I suspect that that is not the case. The form of svn checkout is:
svn checkout <url> <directory>
So your command is saying check out http://webgoat.googlecode.com/svn/trunk/
to the local directory "webgoat". That is to say - it doesn't have a space
in it and in fact is nothing to do with the URL at all.
> 0 $ git-svn clone -T "trunk/ webgoat"
> https://webgoat.googlecode.com/svn/trunk/
> Initialized empty Git repository in .git/
> Using higher level of URL: https://webgoat.googlecode.com/svn/trunk =>
> https://webgoat.googlecode.com/svn
> W: Ignoring error from SVN, path probably does not exist: (175002): RA
> layer request failed: REPORT request failed on '/svn/!svn/bc/100':
> REPORT of '/svn/!svn/bc/100': 200 OK (https://webgoat.googlecode.com)
> Path 'trunk/trunk/ webgoat' was probably deleted:
... which explains this error because there is no path "trunk/ webgoat".
> However, the following command line does seem to work:
>
> git-svn clone -T "trunk/ webgoat" https://webgoat.googlecode.com/svn/
Oh dear; I'm surprised it worked as well as it did. I just ran this command,
which seemed to work well:
$ git-svn clone -T trunk http://webgoat.googlecode.com/svn/ webgoat-local
This clones webgoat.googlecode.com/svn to the local directory webgoat-local;
you can change "webgoat-local" to anything you want, it's just naming the
directory on your own computer.
If you're the maintainer then perhaps you will want to change "http"
to "https" as well.
> Note that I manually removed the "trunk" component from the URL. This
> suggests that there is something missing in the automatic "Using higher
> level" detection code.
I think there is no bug; it's simply a misunderstanding. git-svn working
wonderfully for me.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* [PATCH 1/2] git-submodule: move cloning into a separate function
From: Lars Hjemli @ 2007-06-05 9:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11810357523435-git-send-email-hjemli@gmail.com>
This is just a simple refactoring of modules_init() with no change in
functionality.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
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 0/2] git-submodule: make it easier to use alternate urls
From: Lars Hjemli @ 2007-06-05 9:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch-series teaches git-submodule to register submodule urls in
.git/config during 'git-submodule init' and to perform the actual cloning
during 'git-submodule update', using the url stored in .git/config. So now
the downstream users can specify their preferred urls for each interesting
submodule by editing their .git/config after running 'git-submodule init'.
Documentation/git-submodule.txt | 16 ++++----
git-submodule.sh | 83 ++++++++++++++++++++------------------
t/t7400-submodule-basic.sh | 38 ++++++++++++------
3 files changed, 78 insertions(+), 59 deletions(-)
^ permalink raw reply
* [PATCH 2/2] git-submodule: clone during update, not during init
From: Lars Hjemli @ 2007-06-05 9:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <863f2ca67857bc2d09f46f1a5ef6f653d16d5256.1181034736.git.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>
---
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: [PATCH] git-svn: allow to specify svn branch for commands
From: Eric Wong @ 2007-06-05 9:56 UTC (permalink / raw)
To: Sam Vilain; +Cc: Sam Vilain, Git Central, stephen, Jonathan Rockway
In-Reply-To: <4664E546.5060304@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> Eric Wong wrote:
> > Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> >> "git-svn dcommit" ends up making an arbitrary decision when pushing
> >> back merges. Allow the user to specify which one is used, albeit in a
> >> rather hack-ish way.
> >
> > Frightening... Perhaps we should echo the final URL out
> > to the user and prompt them for confirmation.
>
> Actually in between sending this to the list, I figured that it should
> be possible to detect when this is happening, at the expense of an extra
> "git-log" command. Basically, take the first revision you found a
> commitlog entry in, and then do a log from the indicated head excluding
> that commit. If you find more valid tips then the user is merging in
> gitspace.
>
> Of course ideally you want to make sure that merge commits posted back
> are shipped with all of the necessary tokens for the various SVN-land
> tools out there. eg, svk:merge, svnmerge, and whatever kooky system the
> SVN dev team come up with. But that's a separate issue.
>
> The original patch had a fairly dire bug, so here's a version that at
> least doesn't break the test suite.
>
> Subject: [PATCH] git-svn: allow to specify svn branch for commands
>
> "git-svn dcommit" ends up making an arbitrary decision when pushing
> back merges. Allow the user to specify which one is used, albeit in a
> rather hack-ish way.
Actually, I believe 13c823fb520eaf1cded520213cf0ae4c3268208d already
solves this problem. In fact, I'm not certain if you can find a case
where this will help if 13c823fb520eaf1cded520213cf0ae4c3268208d is in
place. A test case to prove that this is actually needed would be
greatly appreciated :)
On the other hand (much to my chagrin), I haven't been working much on
git-svn lately and my knowledge could be rusty.
> ---
>
> Documentation/git-svn.txt | 11 +++++++++++
> git-svn.perl | 17 ++++++++++-------
> 2 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index c0d7d95..3e64522 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -69,6 +69,17 @@ COMMANDS
> argument if that is what you want. This is useful if
> you wish to track multiple projects that share a common
> repository.
> +-B<svn_branch>;;
> +--branch=<svn_branch>;;
> + Normally, git-svn is capable of figuring out which branch you
> + are working on. However, if you are doing merges between svn
> + branches using git then the decision about which branch to
> + dcommit to will end up being made based on which of the
> + branches you are merging has the newest upstream commit. This
> + option enables a global filter that tells git-svn what to look
> + for in the git-svn-id: line - specify a repository UUID or a
> + branch name here. So, it may be used with "git-svn log",
> + "git-svn dcommit", etc.
I think you missed my comment here on it being a regexp :)
> 'fetch'::
> Fetch unfetched revisions from the Subversion remote we are
> diff --git a/git-svn.perl b/git-svn.perl
> index e350061..906aa4b 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -54,7 +54,7 @@ $sha1 = qr/[a-f\d]{40}/;
> $sha1_short = qr/[a-f\d]{4,40}/;
> my ($_stdin, $_help, $_edit,
> $_message, $_file,
> - $_template, $_shared,
> + $_template, $_shared, $_branch,
> $_version, $_fetch_all, $_no_rebase,
> $_merge, $_strategy, $_dry_run, $_local,
> $_prefix, $_no_checkout, $_verbose);
> @@ -69,6 +69,7 @@ my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
> 'useSvmProps' => \$Git::SVN::_use_svm_props,
> 'useSvnsyncProps' => \$Git::SVN::_use_svnsync_props,
> 'log-window-size=i' => \$Git::SVN::Ra::_log_window_size,
> + 'branch|B=s' => \$_branch,
> 'no-checkout' => \$_no_checkout,
> 'quiet|q' => \$_q,
> 'repack-flags|repack-args|repack-opts=s' =>
> @@ -367,7 +368,7 @@ sub cmd_dcommit {
> my $head = shift;
> $head ||= 'HEAD';
> my @refs;
> - my ($url, $rev, $uuid, $gs) = working_head_info($head, \@refs);
> + my ($url, $rev, $uuid, $gs) = working_head_info($head, \@refs, $_branch);
> unless ($gs) {
> die "Unable to determine upstream SVN information from ",
> "$head history\n";
> @@ -441,7 +442,7 @@ sub cmd_find_rev {
> my $head = shift;
> $head ||= 'HEAD';
> my @refs;
> - my (undef, undef, undef, $gs) = working_head_info($head, \@refs);
> + my (undef, undef, undef, $gs) = working_head_info($head, \@refs, $_branch);
> unless ($gs) {
> die "Unable to determine upstream SVN information from ",
> "$head history\n";
> @@ -457,7 +458,7 @@ sub cmd_find_rev {
I don't think you need this hunk. You can already pass the remote
branch name here (same with "git svn log").
> sub cmd_rebase {
> command_noisy(qw/update-index --refresh/);
> - my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
> + my ($url, $rev, $uuid, $gs) = working_head_info('HEAD', undef, $_branch);
> unless ($gs) {
> die "Unable to determine upstream SVN information from ",
> "working tree history\n";
> @@ -474,7 +475,7 @@ sub cmd_rebase {
> }
>
> sub cmd_show_ignore {
> - my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
> + my ($url, $rev, $uuid, $gs) = working_head_info('HEAD', undef, $_branch);
> $gs ||= Git::SVN->new;
> my $r = (defined $_revision ? $_revision : $gs->ra->get_latest_revnum);
> $gs->traverse_ignore(\*STDOUT, $gs->{path}, $r);
> @@ -801,12 +802,14 @@ sub cmt_metadata {
> }
You need to put --branch/-B into %cmd directly, %fc_opts won't cover
this ('fc' => fetch/commit). On the other hand, we should probably make
this command take a $head from the command-line like "git svn log" and
"git svn find-rev"...
> sub working_head_info {
> - my ($head, $refs) = @_;
> + my ($head, $refs, $grep) = @_;
> my ($fh, $ctx) = command_output_pipe('rev-list', $head);
> while (my $hash = <$fh>) {
> chomp($hash);
> my ($url, $rev, $uuid) = cmt_metadata($hash);
> if (defined $url && defined $rev) {
> + next unless (!$grep or
> + $url =~ m{$grep} or $uuid =~ m{$grep});
> if (my $gs = Git::SVN->find_by_url($url)) {
> my $c = $gs->rev_db_get($rev);
> if ($c && $c eq $hash) {
This last 'if' statement here checking the rev_db (introduced in
13c823fb520eaf1cded520213cf0ae4c3268208d still allows what
this patch is intended to do?
> @@ -3394,7 +3397,7 @@ sub git_svn_log_cmd {
> last;
> }
>
> - my ($url, $rev, $uuid, $gs) = ::working_head_info($head);
> + my ($url, $rev, $uuid, $gs) = ::working_head_info($head, undef, $_branch);
> $gs ||= Git::SVN->_new;
> my @cmd = (qw/log --abbrev-commit --pretty=raw --default/,
> $gs->refname);
You don't need this last hunk. git svn log already takes
remote branches as an argument, and I don't think the -B switch is
passed here where you put it in %fc_opts.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: allow to specify svn branch for commands
From: Eric Wong @ 2007-06-05 9:56 UTC (permalink / raw)
To: Stephen Touset; +Cc: Sam Vilain, Git Central
In-Reply-To: <1181017002.27463.3.camel@megatron>
Stephen Touset <stephen@touset.org> wrote:
> On Tue, 2007-06-05 at 15:42 +1200, Sam Vilain wrote:
> > "git-svn dcommit" ends up making an arbitrary decision when pushing
> > back merges. Allow the user to specify which one is used, albeit in a
> > rather hack-ish way.
>
> I've been thinking about this. I'm rather new to git internals, but if
> I've created a local copy of a remote branch (git-checkout -b
> local-branch --track remote-branch), can't git-svn use the tracking
> metadata to determine which part of the tree to dcommit to?
Probably. --track didn't exist when "git-svn dcommit" was written
and I didn't even know about it until now. Needless to say,
not everybody uses or knows about it, but it would probably be
a good option to add to git-svn.
--
Eric Wong
^ permalink raw reply
* git "manifest" command
From: Csaba Henk @ 2007-06-05 10:03 UTC (permalink / raw)
To: git
Hi,
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).
Maybe it's there already and I just didn't find my way through git
glossary?
Anyway, I rolled my own. Chanches are you find it an useful addition.
Csaba
------[git-manifest.sh]---8<---------------------------------------
#!/bin/sh
#
# Copyright (c) 2007 Csaba Henk
display() {
if [ $verbose ]
then
echo -n $1 $2 $3" "
fi
echo "$4"
}
walk() {
git-ls-tree "$1" | while read -r mode type sha name
do
if [ "$type" = tree ]
then
display $mode $type $sha "$2$name/"
walk $sha "$2$name/"
else
display $mode $type $sha "$2$name"
fi
done
}
help() {
echo \
"List content of tree-ish recursively. Usage:
`basename "$0"` [-v] <tree-ish>
" >&2
exit
}
case $# in
1|2) ;;
*)
help
esac
verbose=
if [ $# -eq 2 ]
then
if [ "$1" = -v ]
then
verbose=1
else
help
fi
shift
else
case "$1" in
-h|--help) help
esac
fi
walk "$1"
^ permalink raw reply
* Re: git-svn and googlecode.com?
From: Rogan Dawes @ 2007-06-05 10:11 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200706051005.46603.andyparkins@gmail.com>
Andy Parkins wrote:
> On Tuesday 2007 June 05, Rogan Dawes wrote:
>
>> (Original) svn checkout http://webgoat.googlecode.com/svn/trunk/ webgoat
>>
>> (Funny, the initial path component had a space in it?!)
>
> I suspect that that is not the case. The form of svn checkout is:
>
> svn checkout <url> <directory>
>
> So your command is saying check out http://webgoat.googlecode.com/svn/trunk/
> to the local directory "webgoat". That is to say - it doesn't have a space
> in it and in fact is nothing to do with the URL at all.
>
I guess I didn't explain it very well. The checked out project had a
directory with a leading space in it:
0 $ ls -alp
total 0
drwxr-xr-x+ 3 rdawes Domain Users 0 Jun 4 14:20 webgoat/
drwxr-xr-x+ 4 rdawes Domain Users 0 Jun 4 14:20 ./
drwx------+ 28 rdawes ???????? 0 Jun 5 09:43 ../
drwxr-xr-x+ 10 rdawes Domain Users 0 Jun 4 14:20 .git/
Note the leading space before webgoat/?
i.e. the initial path component actually does have a space in it.
>> 0 $ git-svn clone -T "trunk/ webgoat"
>> https://webgoat.googlecode.com/svn/trunk/
>> Initialized empty Git repository in .git/
>> Using higher level of URL: https://webgoat.googlecode.com/svn/trunk =>
>> https://webgoat.googlecode.com/svn
>> W: Ignoring error from SVN, path probably does not exist: (175002): RA
>> layer request failed: REPORT request failed on '/svn/!svn/bc/100':
>> REPORT of '/svn/!svn/bc/100': 200 OK (https://webgoat.googlecode.com)
>> Path 'trunk/trunk/ webgoat' was probably deleted:
>
> ... which explains this error because there is no path "trunk/ webgoat".
Not so, see below.
>> However, the following command line does seem to work:
>>
>> git-svn clone -T "trunk/ webgoat" https://webgoat.googlecode.com/svn/
>
> Oh dear; I'm surprised it worked as well as it did. I just ran this command,
> which seemed to work well:
>
> $ git-svn clone -T trunk http://webgoat.googlecode.com/svn/ webgoat-local
>
> This clones webgoat.googlecode.com/svn to the local directory webgoat-local;
> you can change "webgoat-local" to anything you want, it's just naming the
> directory on your own computer.
Sure. But then you cd into webgoat-local/, do an "ls -l", and you'll see
exactly the same thing I showed above.
I'm still running your command above, but I'm seeing
W: -empty_dir: trunk/ webgoat/main/project/JavaSource/org
Note the space ^
> If you're the maintainer then perhaps you will want to change "http"
> to "https" as well.
>
>> Note that I manually removed the "trunk" component from the URL. This
>> suggests that there is something missing in the automatic "Using higher
>> level" detection code.
>
> I think there is no bug; it's simply a misunderstanding. git-svn working
> wonderfully for me.
Um, I think that you did exactly what I said I did, namely removing the
"trunk" component from the URL. Contrast:
Yours:
$ git-svn clone -T trunk http://webgoat.googlecode.com/svn/ \
webgoat-local
Mine (original):
$ git-svn clone -T "trunk/ webgoat" \
https://webgoat.googlecode.com/svn/trunk/
^^^^^
Mine (eventual):
$ git-svn clone -T "trunk/ webgoat" https://webgoat.googlecode.com/svn/
I'm sure there WAS a misunderstanding. It was me not understanding how
to translate an SVN command line to a proper git command line,
accounting for trunks, etc. That was one of the reasons I made the post,
to clear it up, and to make sure that anyone searching for hints on how
to use git to clone google code projects will find something, since I
didn't.
So, it seems that the rule for googlecode is something like:
If the published command line is:
svn checkout https://<project>.googlecode.com/svn/trunk/ <project>
You can clone this project using git-svn with the following command:
git-svn clone -T trunk https://<project>.googlecode.com/svn/ <localdir>
If this results in too many levels of directories in the checked out
project (e.g. "/workspace/webgoat/ webgoat/"), take the extra directory
component and add it to the -T parameter (e.g. "-T 'trunk/ webgoat'")
Hopefully this helps the next person.
Thanks for your response.
Rogan
^ permalink raw reply
* Re: git-svn dcommit failure
From: Eric Wong @ 2007-06-05 10:17 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87k5ur64hx.fsf@mid.deneb.enyo.de>
Florian Weimer <fw@deneb.enyo.de> wrote:
> * Pierre Habouzit:
>
> > On Tue, May 29, 2007 at 11:35:10AM +0200, Florian Weimer wrote:
> >> * Florian Weimer:
> >>
> >> > This with git-svn 1.5.1.4-2 on something that is quite close to Debian
> >> > etch.
> >>
> >> Same issue with 1.5.2~rc3-2.
> >
> > Are you using ControlMaster in your ssh setup in auto/autoask mode? (I
> > assume your repository is svn+ssh). If yes, then you *have* to start a
> > persistent ssh connection before you do anything else:
>
> No. It's svn+ssh (with a custom connect script), but without the
> controlchan extension. Subversion works fine and lets me commit
> changes.
>
> After manually committing the offending changes via Subversion, I
> git-svn has begun to work again, too (but I haven't yet tried to
> change the same files).
Would upgrading to 1.5.2 final have helped?
Looking at 6442754d6cc0056cf5b69b43d218f8b6d317e7f5 (which was made
right before 1.5.2 final), the bug it fixed could've actually affected
modification-only commits, too.
If it's a public repository, could I look at the changeset that was
giving you trouble, and the [svn-remote] section of your .git/config
file? Thanks.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Add git-filter-branch
From: Jonas Fonseca @ 2007-06-05 10:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0706030147520.4046@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote Sun, Jun 03, 2007:
> Second, it does not even need bash.
>
> At least that is what I tried to make sure. I replaced the only instance
> of a bashim I was aware, namely the arrayism of $unchanged. It can be a
> string just as well, as we are only storing object names in it.
>
> Tell me if it does not work for you.
>
> Or even better, provide me with a test case that fails for you.
I found a small problem when /bin/sh is linked to dash.
$ /bin/dash t*-filter-branch.sh
* ok 1: setup
* FAIL 2: rewrite identically
git-filter-branch H2
* FAIL 3: result is really identical
test $H = $(git-rev-parse H2)
* FAIL 4: rewrite, renaming a specific file
git-filter-branch --tree-filter "mv d doh || :" H3
* FAIL 5: test that the file was renamed
test d = $(git show H3:doh)
* failed 4 among 5 test(s)
$ cd trash/
$ rm -rf .git-rewrite/
$ git filter-branch H2
/home/fonseca/bin/git-filter-branch: 386: arith: syntax error: "i+1"
$
A possible fix that makes the test pass for me.
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 0c8a7df..5cf9d3c 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -339,7 +339,7 @@ test $commits -eq 0 && die "Found nothing to rewrite"
i=0
while read commit; do
- i=$((i+1))
+ i=$(echo i+1 | bc)
printf "$commit ($i/$commits) "
git-read-tree -i -m $commit
--
Jonas Fonseca
^ permalink raw reply related
* Re: git branch --track and remote branches with / in the name
From: Junio C Hamano @ 2007-06-05 10:22 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git, Paolo Bonzini
In-Reply-To: <20070605090404.24707.qmail@b58755fd627261.315fe32.mid.smarden.org>
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:
>
> $ tail -n6 .git/config
> [remote "origin"]
> url = /tmp/repo
> fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> $ git branch -r
> origin/HEAD
> origin/b
> origin/foo/b
> origin/master
> $ git branch --track b origin/b
> Branch b set up to track remote branch refs/remotes/origin/b.
> $ git branch --track foo/b origin/foo/b
> $ tail -n6 .git/config
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [branch "b"]
> remote = origin
> merge = refs/heads/b
> $
Indeed the "find matching remote tracking branch" code was
somewhat sloppy and needlessly complex/clever.
How about this patch?
-- >8 --
git-branch --track: fix tracking branch computation.
The original code did not take hierarchical branch names into account at all.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-branch.c | 67 ++++++++++++++++++++++++++++++++--------------------
t/t3200-branch.sh | 16 +++++++++---
2 files changed, 53 insertions(+), 30 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index a5b6bbe..4bed12b 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -317,8 +317,6 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev)
static char *config_repo;
static char *config_remote;
static const char *start_ref;
-static int start_len;
-static int base_len;
static int get_remote_branch_name(const char *value)
{
@@ -334,26 +332,41 @@ static int get_remote_branch_name(const char *value)
end = value + strlen(value);
- /* Try an exact match first. */
+ /*
+ * Try an exact match first. I.e. handle the case where the
+ * value is "$anything:refs/foo/bar/baz" and start_ref is exactly
+ * "refs/foo/bar/baz". Then the name at the remote is $anything.
+ */
if (!strcmp(colon + 1, start_ref)) {
- /* Truncate the value before the colon. */
+ /* Truncate the value before the colon. */
nfasprintf(&config_repo, "%.*s", colon - value, value);
return 1;
}
- /* Try with a wildcard match now. */
- if (end - value > 2 && end[-2] == '/' && end[-1] == '*' &&
- colon - value > 2 && colon[-2] == '/' && colon[-1] == '*' &&
- (end - 2) - (colon + 1) == base_len &&
- !strncmp(colon + 1, start_ref, base_len)) {
- /* Replace the star with the remote branch name. */
- nfasprintf(&config_repo, "%.*s%s",
- (colon - 2) - value, value,
- start_ref + base_len);
- return 1;
- }
+ /*
+ * Is this a wildcard match?
+ */
+ if ((end - 2 <= value) || end[-2] != '/' || end[-1] != '*' ||
+ (colon - 2 <= value) || colon[-2] != '/' || colon[-1] != '*')
+ return 0;
- return 0;
+ /*
+ * Value is "refs/foo/bar/<asterisk>:refs/baz/boa/<asterisk>"
+ * and start_ref begins with "refs/baz/boa/"; the name at the
+ * remote is refs/foo/bar/ with the remaining part of the
+ * start_ref. The length of the prefix on the RHS is (end -
+ * colon - 2), including the slash immediately before the
+ * asterisk.
+ */
+ if ((strlen(start_ref) < end - colon - 2) ||
+ memcmp(start_ref, colon + 1, end - colon - 2))
+ return 0; /* does not match prefix */
+
+ /* Replace the asterisk with the remote branch name. */
+ nfasprintf(&config_repo, "%.*s%s",
+ (colon - 1) - value, value,
+ start_ref + (end - colon - 2));
+ return 1;
}
static int get_remote_config(const char *key, const char *value)
@@ -363,10 +376,12 @@ static int get_remote_config(const char *key, const char *value)
return 0;
var = strrchr(key, '.');
- if (var == key + 6)
+ if (var == key + 6 || strcmp(var, ".fetch"))
return 0;
-
- if (!strcmp(var, ".fetch") && get_remote_branch_name(value))
+ /*
+ * Ok, we are looking at key == "remote.$foo.fetch";
+ */
+ if (get_remote_branch_name(value))
nfasprintf(&config_remote, "%.*s", var - (key + 7), key + 7);
return 0;
@@ -392,14 +407,14 @@ static void set_branch_merge(const char *name, const char *config_remote,
static void set_branch_defaults(const char *name, const char *real_ref)
{
- const char *slash = strrchr(real_ref, '/');
-
- if (!slash)
- return;
-
+ /*
+ * name is the name of new branch under refs/heads;
+ * real_ref is typically refs/remotes/$foo/$bar, where
+ * $foo is the remote name (there typically are no slashes)
+ * and $bar is the branch name we map from the remote
+ * (it could have slashes).
+ */
start_ref = real_ref;
- start_len = strlen(real_ref);
- base_len = slash - real_ref;
git_config(get_remote_config);
if (!config_repo && !config_remote &&
!prefixcmp(real_ref, "refs/heads/")) {
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 828d553..6f6d884 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -136,8 +136,8 @@ test_expect_success 'test tracking setup (non-wildcard, not matching)' \
git-config remote.local.fetch refs/heads/s:refs/remotes/local/s &&
(git-show-ref -q refs/remotes/local/master || git-fetch local) &&
git-branch --track my5 local/master &&
- ! test $(git-config branch.my5.remote) = local &&
- ! test $(git-config branch.my5.merge) = refs/heads/master'
+ ! test "$(git-config branch.my5.remote)" = local &&
+ ! test "$(git-config branch.my5.merge)" = refs/heads/master'
test_expect_success 'test tracking setup via config' \
'git-config branch.autosetupmerge true &&
@@ -155,14 +155,22 @@ test_expect_success 'test overriding tracking setup via --no-track' \
(git-show-ref -q refs/remotes/local/master || git-fetch local) &&
git-branch --no-track my2 local/master &&
git-config branch.autosetupmerge false &&
- ! test $(git-config branch.my2.remote) = local &&
- ! test $(git-config branch.my2.merge) = refs/heads/master'
+ ! test "$(git-config branch.my2.remote)" = local &&
+ ! test "$(git-config branch.my2.merge)" = refs/heads/master'
test_expect_success 'test local tracking setup' \
'git branch --track my6 s &&
test $(git-config branch.my6.remote) = . &&
test $(git-config branch.my6.merge) = refs/heads/s'
+test_expect_success 'test tracking setup via --track but deeper' \
+ 'git-config remote.local.url . &&
+ git-config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
+ (git-show-ref -q refs/remotes/local/o/o || git-fetch local) &&
+ git-branch --track my7 local/o/o &&
+ test "$(git-config branch.my7.remote)" = local &&
+ test "$(git-config branch.my7.merge)" = refs/heads/o/o'
+
# Keep this test last, as it changes the current branch
cat >expect <<EOF
0000000000000000000000000000000000000000 $HEAD $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000 branch: Created from master
--
1.5.2.1.116.g9f308
^ permalink raw reply related
* Re: git-svn adding too many blank lines during git-cherry-pick, and git-cherry getting confused
From: Eric Wong @ 2007-06-05 10:24 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: Git Mailing List
In-Reply-To: <20070602045007.GJ27013@curie-int.orbis-terrarum.net>
"Robin H. Johnson" <robbat2@gentoo.org> wrote:
> Hi,
>
> Bit of weirdness I ran into.
>
> I have a SVN tree, with a branch that gets some backported fixe (they
> usually apply cleanly).
>
> I commit the fix to the trunk + git-svn dcommit, and then switch to the
> other branch, and git-cherry-pick the fix.
>
> For git-svn commits, the log has:
> On the trunk side, there is a two blank line before git-svn-id.
> On the branch side, there are three blank lines before git-svn-id.
> If I cherry-pick from that branch to a third branch, I get 4 blank
> lines.
>
> For regular SVN commits, the log has:
> Only a single blank line before git-svn-id.
>
> I think the source of the problem is that git-svn-id is being removed
> when cherry-picking, but NOT the leading blank line.
>
> This all leads to the hashes of the commits diverging badly, and then
> git-cherry gets very confused when asked to compare the trunk vs. the
> branches.
>
> How do we solve it?
> This is only on a conceptual level here, looking at the present state of
> git-svn, I'm not sure how best to solve it.
>
> git-svn fetch:
> 1. Get commit message from SVN.
> 2. Trim ALL trailing blank lines (and existing git-svn-id lines).
> 3. If the last line was header-style (Signed-off-by, CC, etc)
> 3.1. if it was, do not add a blank line.
> 3.2. If not, add a single blank line.
> 4. Insert git-svn-id header.
Too much magic. I don't think this is a good idea, at least
not by default.
> git-svn dcommit:
> 1. Get commit message (git cat-file commit ....)
> 2. Remove the git-svn-id line.
> 3. Remove all trailing blank lines.
> 4. Commit.
We already do step 3. The problem is that we fail to remove the newline
*before* the git-svn-id line. I'll make a mental note to fix this
sometime this week, I hope.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Add git-filter-branch
From: David Kastrup @ 2007-06-05 10:26 UTC (permalink / raw)
To: git
In-Reply-To: <20070605101845.GA16160@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> A possible fix that makes the test pass for me.
>
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index 0c8a7df..5cf9d3c 100644
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -339,7 +339,7 @@ test $commits -eq 0 && die "Found nothing to rewrite"
>
> i=0
> while read commit; do
> - i=$((i+1))
> + i=$(echo i+1 | bc)
Would not work. You need $i instead.
> printf "$commit ($i/$commits) "
>
> git-read-tree -i -m $commit
More portable would be
i=`expr $i + 1`
since not everything has bc installed. Is $(...) available generally?
I thought it was a bashism, too.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Add git-filter-branch
From: Junio C Hamano @ 2007-06-05 10:30 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <20070605101845.GA16160@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> $ git filter-branch H2
> /home/fonseca/bin/git-filter-branch: 386: arith: syntax error: "i+1"
> $
>
> A possible fix that makes the test pass for me.
>
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index 0c8a7df..5cf9d3c 100644
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -339,7 +339,7 @@ test $commits -eq 0 && die "Found nothing to rewrite"
>
> i=0
> while read commit; do
> - i=$((i+1))
> + i=$(echo i+1 | bc)
Are you sure this is not "echo $i+1"???
There are quite a few $((arithmetic)) already in our shell code,
so I was initially a bit surprised. However, upon closer
inspection, this particular use is not kosher at all.
The portable ones we already have in the code say things like:
msgnum=$(($msgnum+1))
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.
^ permalink raw reply
* Re: [PATCH] Make the installation targets a little less chatty
From: Alex Riesen @ 2007-06-05 10:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0706041840460.4046@racer.site>
On 6/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> So, are you sure you want to force everybody who wants to compile Git to
> use a recent GNU make?
>
Dunno. I just didn't want to slap more workarounds onto Git's Makefile.
^ permalink raw reply
* Re: [PATCH] Add git-filter-branch
From: Jonas Fonseca @ 2007-06-05 10:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <7vzm3ebsnk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote Tue, Jun 05, 2007:
> Jonas Fonseca <fonseca@diku.dk> writes:
>
> > $ git filter-branch H2
> > /home/fonseca/bin/git-filter-branch: 386: arith: syntax error: "i+1"
> > $
> >
> > A possible fix that makes the test pass for me.
> >
> > diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> > index 0c8a7df..5cf9d3c 100644
> > --- a/git-filter-branch.sh
> > +++ b/git-filter-branch.sh
> > @@ -339,7 +339,7 @@ test $commits -eq 0 && die "Found nothing to rewrite"
> >
> > i=0
> > while read commit; do
> > - i=$((i+1))
> > + i=$(echo i+1 | bc)
>
> Are you sure this is not "echo $i+1"???
Yes, I noticed this right after sending the mail. People on this list
are just too damn fast for me to send a correction. ;)
> There are quite a few $((arithmetic)) already in our shell code,
> so I was initially a bit surprised. However, upon closer
> inspection, this particular use is not kosher at all.
>
> The portable ones we already have in the code say things like:
>
> msgnum=$(($msgnum+1))
Yes, I should have investigated before sending.
> 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.
--
Jonas Fonseca
^ permalink raw reply
* Re: Improved git-gui blame viewer
From: Alex Riesen @ 2007-06-05 10:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070605043824.GB9513@spearce.org>
On 6/5/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Don't we use git-config to edit the config file in git-branch?
Not routinely. Seldom, even
> In git-remote? git-gui has *always* used git-config to store
> its data. You are sort of asking me to replace a working config
> system with a new one that hasn't been tested...
Just divert the data someplace else.
> Now moving the git-gui config to say ~/.gitgui-config and
> .git/gitgui-config may have a good argument, as then git-gui
> is editing its own files.
Good argument on its own
> Unless the user changes user.name
> or user.email through git-gui, in which case we have to edit
> .git/config or ~/.gitconfig anyway...
Yes, then of course (in this case the user is even aware).
^ permalink raw reply
* 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
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