* Re: [PATCH] Adding rebase merge strategy
From: Johannes Schindelin @ 2007-10-01 15:50 UTC (permalink / raw)
To: Tom Clarke; +Cc: gitster, git
In-Reply-To: <11912513203420-git-send-email-tom@u2i.com>
Hi,
On Mon, 1 Oct 2007, Tom Clarke wrote:
> Incorporated comments from Johannes Schindlen.
Thanks.
> +# Give up if we are given two or more remotes -- not handling octopus.
> +test $# = 1 || exit 2
I think the user wants to know in this case, too. How about
test $# = 1 || {
echo "Cannot handle octopus." >&2
exit 2
}
> diff --git a/t/t3031-merge-rebase.sh b/t/t3031-merge-rebase.sh
> new file mode 100755
> index 0000000..daa03b1
> --- /dev/null
> +++ b/t/t3031-merge-rebase.sh
>
> [...]
>
> + ( git log --pretty=oneline ) >actual &&
Please lose the parentheses here.
> + (
> + echo "4db7a5a013e67aa623d1fd294e8d46e89b3ace8f onbranch"
> + echo "893371811dbd13e85c098b72d1ab42bcfd24c2db update"
> + echo "0e960b10429bf3f1e168ee2cc7d531ac7c622580 initial"
> + ) >expected &&
Why not do it as is done elsewhere in the test suit: use a "cat << EOF"
before "test_expect_success"?
> + (
> + echo "warning: Message is not used for rebase merge strategy"
> + ) >expected &&
Same here.
Other than that, I like it.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Prevent purely-numeric ref names from breaking Javascript.
From: David Symonds @ 2007-10-01 15:37 UTC (permalink / raw)
To: pasky; +Cc: git, David Symonds
When the server reply carrying JSON data to the client browser to render has
a string that looks like a decimal number, it doesn't get quoted. The
client-side Javascript code assumes, however, that all the ref names are
strings, and so calls string functions on decimal number objects if the ref
name is purely numeric (e.g. "2.5"). This patch simply forces the objects that
are escaped for HTML presentation to be coerced into strings, which catches
this case (and possibly others).
---
by-commit.html | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/by-commit.html b/by-commit.html
index d759c3e..0aa69b9 100644
--- a/by-commit.html
+++ b/by-commit.html
@@ -35,6 +35,7 @@ format_log_date=function( date )
}
escape_html=function( s )
{
+ s=s+""; // ensure it's a string
s=s.replace( /\&/g, "&" );
s=s.replace( /\</g, "<" );
s=s.replace( /\>/g, ">" );
--
1.5.3.1
^ permalink raw reply related
* Re: git-browser and branch names
From: David Symonds @ 2007-10-01 15:34 UTC (permalink / raw)
To: Jean-François Veillette; +Cc: Git
In-Reply-To: <C4186BBD-11BA-4A58-9230-00076FF6F8F7@yahoo.ca>
On 01/10/2007, Jean-François Veillette <jean_francois_veillette@yahoo.ca> wrote:
> Le 07-10-01 à 07:24, David Symonds a écrit :
> >
> > Can anyone give me pointers or suggestions as to where to start
> > debugging this? Anyone else encountered this?
>
> To debug html/javascript use Firefox and Firebug.
> http://www.getfirebug.com/
Great, thanks for the pointer. My first real foray into Javascript has
been successful -- a patch will soon follow.
Dave.
^ permalink raw reply
* Re: Referring a commit-id remote repo.
From: David Brown @ 2007-10-01 15:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git
In-Reply-To: <Pine.LNX.4.64.0710011122500.28395@racer.site>
On Mon, Oct 01, 2007 at 11:25:13AM +0100, Johannes Schindelin wrote:
>On Sun, 30 Sep 2007, David Brown wrote:
>
>> The question I have: is there any way I can look at this particular
>> commit ID on the remote repo? I couldn't come up with any way to get
>> git fetch to retrieve it.
>
>Unless you have push access, no. And this is very much by design. For
>example, when somebody mistakenly pushed a secret (like what lines in the
>kernel infringe on M$ patents, if any) it should be possible to rebase (in
>a hurry), force a push, and have the safe feeling that nobody can fetch
>the secret any longer.
I've found the commits in the 'master' branch, and it looks like the
developer had done a rebase on Sept 3. I've informed the person asking me
the question to use these commit IDs, and hopefully they won't be doing any
rebasing on their master branch.
Dave
^ permalink raw reply
* [PATCH] Adding rebase merge strategy
From: Tom Clarke @ 2007-10-01 15:08 UTC (permalink / raw)
To: gitster; +Cc: Johannes.Schindelin, git, Tom Clarke
In-Reply-To: <Pine.LNX.4.64.0709281751390.28395@racer.site>
In addition to adding git-merge-rebase.sh, git-merge.sh is modified
to handle the rebase strategy specially and avoids running update-ref
as rebase won't generate a merge commit. It also adds a warning
if a message is supplied when the rebase isn't used as this
will be ignored.
Signed-off-by: Tom Clarke <tom@u2i.com>
---
Incorporated comments from Johannes Schindlen.
.gitignore | 1 +
Documentation/merge-strategies.txt | 6 +++++
Makefile | 2 +-
git-merge-rebase.sh | 17 ++++++++++++++
git-merge.sh | 24 +++++++++++++++++--
t/t3031-merge-rebase.sh | 44 ++++++++++++++++++++++++++++++++++++
6 files changed, 90 insertions(+), 4 deletions(-)
create mode 100755 git-merge-rebase.sh
create mode 100755 t/t3031-merge-rebase.sh
diff --git a/.gitignore b/.gitignore
index e0b91be..fe5cdc4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -73,6 +73,7 @@ git-merge-tree
git-merge-octopus
git-merge-one-file
git-merge-ours
+git-merge-rebase
git-merge-recursive
git-merge-resolve
git-merge-stupid
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 7df0266..dff1909 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -33,3 +33,9 @@ ours::
merge is always the current branch head. It is meant to
be used to supersede old development history of side
branches.
+
+rebase::
+ This rebases the current branch based on a single head.
+ Commits are rewritten as with git-rebase. This doesn't
+ produce a merge. The procedure for dealing with conflicts
+ is the same as with git-rebase.
diff --git a/Makefile b/Makefile
index 8db4dbe..e6d3812 100644
--- a/Makefile
+++ b/Makefile
@@ -215,7 +215,7 @@ SCRIPT_SH = \
git-sh-setup.sh \
git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
- git-merge-resolve.sh git-merge-ours.sh \
+ git-merge-resolve.sh git-merge-ours.sh git-merge-rebase.sh \
git-lost-found.sh git-quiltimport.sh git-submodule.sh \
git-filter-branch.sh \
git-stash.sh
diff --git a/git-merge-rebase.sh b/git-merge-rebase.sh
new file mode 100755
index 0000000..b75be3f
--- /dev/null
+++ b/git-merge-rebase.sh
@@ -0,0 +1,17 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Tom Clarke
+#
+# Resolve two trees with rebase
+
+# The first parameters up to -- are merge bases ignore them
+while test $1 != "--"; do shift; done
+shift
+
+# ignore the first head, it's not needed in a rebase merge
+shift
+
+# Give up if we are given two or more remotes -- not handling octopus.
+test $# = 1 || exit 2
+
+git rebase $1 || exit 2
diff --git a/git-merge.sh b/git-merge.sh
index 6c513dc..b58bee2 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -16,11 +16,12 @@ test -z "$(git ls-files -u)" ||
LF='
'
-all_strategies='recur recursive octopus resolve stupid ours subtree'
+all_strategies='recur recursive octopus resolve stupid ours subtree rebase'
default_twohead_strategies='recursive'
default_octopus_strategies='octopus'
no_fast_forward_strategies='subtree ours'
-no_trivial_strategies='recursive recur subtree ours'
+no_trivial_strategies='recursive recur subtree ours rebase'
+no_update_ref='rebase'
use_strategies=
allow_fast_forward=t
@@ -81,11 +82,18 @@ finish () {
echo "No merge message -- not updating HEAD"
;;
*)
- git update-ref -m "$rlogm" HEAD "$1" "$head" || exit 1
+ case " $wt_strategy " in
+ *" $no_update_ref "*)
+ ;;
+ *)
+ git update-ref -m "$rlogm" HEAD "$1" "$head" || exit 1
+ ;;
+ esac
;;
esac
;;
esac
+
case "$1" in
'')
;;
@@ -418,6 +426,16 @@ do
;;
esac
+ # Check to see if there's a message in a merge type that won't produce a commit
+ if test $have_message = "t"
+ then
+ case " $strategy " in
+ *" $no_update_ref "*)
+ echo >&2 "warning: Message is not used for $strategy merge strategy"
+ ;;
+ esac
+ fi
+
# Remember which strategy left the state in the working tree
wt_strategy=$strategy
diff --git a/t/t3031-merge-rebase.sh b/t/t3031-merge-rebase.sh
new file mode 100755
index 0000000..daa03b1
--- /dev/null
+++ b/t/t3031-merge-rebase.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+
+test_description='merge-rebase backend test'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo hello >a &&
+ git add a &&
+ test_tick && git commit -m initial &&
+
+ git checkout -b branch &&
+ echo hello >b &&
+ git add b &&
+ test_tick && git commit -m onbranch &&
+
+ git checkout master &&
+ echo update >a &&
+ git add a &&
+ test_tick && git commit -m update
+'
+test_expect_success 'merging using rebase does not create merge commit' '
+ git checkout branch &&
+ git merge -s rebase master &&
+
+ ( git log --pretty=oneline ) >actual &&
+ (
+ echo "4db7a5a013e67aa623d1fd294e8d46e89b3ace8f onbranch"
+ echo "893371811dbd13e85c098b72d1ab42bcfd24c2db update"
+ echo "0e960b10429bf3f1e168ee2cc7d531ac7c622580 initial"
+ ) >expected &&
+ git diff -w -u expected actual
+'
+git reset --hard HEAD@{2}
+
+test_expect_success 'merging using rebase with message gives warning' '
+ git merge -m "a message" -s rebase master 2> actual &&
+ (
+ echo "warning: Message is not used for rebase merge strategy"
+ ) >expected &&
+ git diff -w -u expected actual
+'
+
+test_done
--
1.5.3.rc7.3.g850f-dirty
^ permalink raw reply related
* Re: [PATCH 1/4] Add a simple option parser for use by builtin-commit.c.
From: Jeff King @ 2007-10-01 15:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jonas Fonseca, Kristian Høgsberg, gitster, git
In-Reply-To: <Pine.LNX.4.64.0710011114310.28395@racer.site>
On Mon, Oct 01, 2007 at 11:14:48AM +0100, Johannes Schindelin wrote:
> We _have_ to modify argv. For example, "git log master -p" is perfectly
> valid.
We're not going to support POSIXLY_CORRECT!? ;)
-Peff
^ permalink raw reply
* Re: merging .gitignore
From: Johannes Schindelin @ 2007-10-01 13:57 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20071001130314.GA5932@lapse.madduck.net>
Hi,
On Mon, 1 Oct 2007, martin f krafft wrote:
> Feature branch A has a .gitignore file, and it's been merged into
> master for a while. Today, feature branch B failed to merge into
> master because it also provides a .gitignore file.
You might be interested in writing a merge driver. See
Documentation/gitattributes.txt.
Hth,
Dscho
^ permalink raw reply
* Re: merging .gitignore
From: Andy Parkins @ 2007-10-01 13:48 UTC (permalink / raw)
To: git; +Cc: martin f krafft
In-Reply-To: <20071001130314.GA5932@lapse.madduck.net>
On Monday 2007 October 01, martin f krafft wrote:
> Feature branch A has a .gitignore file, and it's been merged into
> master for a while. Today, feature branch B failed to merge into
> master because it also provides a .gitignore file. We can obviously
> resolve the conflict, but I wonder whether there is a better way to
> deal with this since we deal with quite a large number of new
> feature branches and it's only a matter of time until the next one
> will conflict because of .gitignore.
But it _is_ a conflict. Conflicts have to be resolved. I'm having difficulty
understanding what you think git should be doing in these cases?
> (and yes, this is basically a reincarnation of my case for
> .gitignore.d [http://lists.zerezo.com/git/msg627581.html]).
I don't see that that would help. All you are doing with a gitignore.d is
swapping lines for files, the conflicts would still exist. Presumably you
are hoping that the separate branches will make different files in
gitignore.d and hence can't conflict; but then you've just pushed the
conflict to a place where it won't be seen (and also made a terrible mess of
the merged branch gitignore.d).
branchA:.gitignore.d/branchAignores
branchB:.gitignore.d/branchBignores
Over time you would get:
master:.gitignore.d/branchAignores
master:.gitignore.d/branchBignores
master:.gitignore.d/branchCignores
master:.gitignore.d/branchDignores
master:.gitignore.d/branchEignores
master:.gitignore.d/branchFignores
Then, assuming the conflicts you get now occur for a reason, you will get
conflicts within the .gitignore.d/ directory. Let's say branchCignores adds
*.o and branchFignores removes *.o from the ignores. Who is right? Who
knows, and worse than that you didn't see the conflict when it happened so it
wasn't resolved and the master branch was left with conflicts in it.
Of course the conflicts in that case aren't in the form of "<<<<<" markers,
but they are no less conflicts just because they're invisible.
Eventually someone is going to want to combine this ever-increasing set of
ignore files into one. i.e. they'll merge them. In which case why couldn't
you do the merge at the correct time - when the branch was merged?
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: How to re-use setups in multiple tests?
From: Karl Hasselström @ 2007-10-01 13:40 UTC (permalink / raw)
To: Tom Clarke; +Cc: Johannes Schindelin, git
In-Reply-To: <550f9510710010546q55209759k4770cd3e78121cfc@mail.gmail.com>
On 2007-10-01 14:46:46 +0200, Tom Clarke wrote:
> On 10/1/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > > I suppose I could find the old pre-rebase head and work with
> > > that, but that doesn't seem that clean to me.
> >
> > You can use "git reset --hard master@{1}", and it really escapes
> > me why this should not be clean, and why you want to jump through
> > hoops instead using a much more complicated technique.
>
> That'll be because my git knowledge isn't good enough to make it
> clean. Thanks for the suggestion :-)
Another even more foolproof way would be to have the setup create a
(lightweight) tag, and let each subtest reset to that tag.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* git-http-push / webDAV
From: Thomas Pasch @ 2007-10-01 13:31 UTC (permalink / raw)
To: git
Hello,
trying to set up a webDAV enabled http push
git server (1.5.3.3) like it is described in
http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt
Tested the apache2 (2.2.6) DAV setup with
cadaver (and tried the browser as well).
With cadaver I could lock files, download
and upload content.
However,
> git push -v upload master
Pushing to http://test@x.x.x.x/git/DepTrack.git/
Fetching remote heads...
refs/
refs/heads/
refs/tags/
updating 'refs/heads/master'
from 0000000000000000000000000000000000000000
to d75dce3fe0e9ec5915feda5574f214bd432ccb14
sending 89 objects
done
Updating remote server info
UNLOCK HTTP error 400
Also tried:
> git-http-push --all --verbose http://x.x.x.x/git/DepTrack.git/ master
Getting pack list
Fetching remote heads...
refs/
refs/heads/
refs/tags/
'refs/heads/master': up-to-date
... and then tried to clone:
> git clone http://test@x.x.x.x/git/DepTrack.git
Initialized empty Git repository in /home/tpasch/tmp/tmp/DepTrack/.git/
Getting alternates list for http://test@x.x.x.x/git/DepTrack.git
Getting pack list for http://test@x.x.x.x/git/DepTrack.git
error: Unable to find d75dce3fe0e9ec5915feda5574f214bd432ccb14 under
http://test@x.x.x.x/git/DepTrack.git
Cannot obtain needed object d75dce3fe0e9ec5915feda5574f214bd432ccb14
Finally, tried a *non-empty* repo at the server:
> git clone --bare /home/tpasch/tmp/tmp/trunk DepTrack.git
Initialized empty Git repository in /data/git/DepTrack.git/
22911 blocks
> cd DepTrack.git/
> git --bare update-server-info
> chmod a+x hooks/post-update
> chown -R wwwrun:www /data/git
... cloned:
> git clone http://test@x.x.x.x/git/DepTrack.git
Initialized empty Git repository in /home/tpasch/tmp/tmp/DepTrack/.git/
got d75dce3fe0e9ec5915feda5574f214bd432ccb14
walk d75dce3fe0e9ec5915feda5574f214bd432ccb14
got 8a459da1fb520cbc2534b87d3c0d8539fa010f45
got 31c3b20e1d7d7ca414a273fe80f4c49466250709
walk 31c3b20e1d7d7ca414a273fe80f4c49466250709
got ca647ac42188a8ed859260503abc41f98fd21be6
[...]
got 7e089ccc1819d4e69b228b3359690f685728248b
Checking 66 files out...
100% (66/66) done
... then modified a file and pushed:
> git add test.txt
> git commit
> git push -v
Pushing to http://test@x.x.x.x/git/DepTrack.git
But this never returns. (Also tried:
> git-http-push --all --verbose http://x.x.x.x/git/DepTrack.git/ master
Getting pack list
Fetching remote heads...
refs/
refs/heads/
refs/tags/
updating 'refs/heads/master'
from d75dce3fe0e9ec5915feda5574f214bd432ccb14
to 07002e0423e803096eb07eb5c46651b00ed20725
sending 3 objects
done
Updating remote server info
UNLOCK HTTP error 400
)
Any suggestions?
Cheers,
Thomas
PS:
This is how I initialized the repo:
> git --bare init
Initialized empty Git repository in /data/git/DepTrack.git/
> git --bare update-server-info
> chmod a+x hooks/post-update
> chown -R wwwrun:www /data/git
> /etc/init.d/apache2 restart
^ permalink raw reply
* Re: [PATCH] Don't checkout the full tree if avoidable
From: Steven Walter @ 2007-10-01 13:12 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20071001110855.GB10079@muzzle>
On Mon, Oct 01, 2007 at 04:08:55AM -0700, Eric Wong wrote:
> Steven Walter wrote:
> > One criticism of the patch: the trees_match function probably needs to
> > be re-written. My SVN::Perl-foo is weak.
>
> Yep :)
>
> Steven:
>
> How does the following work for you? Which version of SVN do you have,
> by the way? I just found a bug with the way SVN::Client::diff() is
> exported for SVN 1.1.4, hence the SVN::Pool->new_default_sub usage.
swalter@sentra:~% svn --version
svn, version 1.3.2 (r19776)
This version works great; seems to have exactly the same behavior as my
patch. Verified that it still falls back to the do_update code when
trees_match fails.
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ permalink raw reply
* merging .gitignore
From: martin f krafft @ 2007-10-01 13:03 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]
Dear gits (oh dear…),
we just ran into a problem in a git-managed project and I'd be
interested to learn how you approach this.
Our main line ("upstream"), which tracks a remote repository, does
not have a .gitignore file. For new features, we use feature
branches, and we merge those into an integration branch ("master")
and track them separately of upstream.
Feature branch A has a .gitignore file, and it's been merged into
master for a while. Today, feature branch B failed to merge into
master because it also provides a .gitignore file. We can obviously
resolve the conflict, but I wonder whether there is a better way to
deal with this since we deal with quite a large number of new
feature branches and it's only a matter of time until the next one
will conflict because of .gitignore.
(and yes, this is basically a reincarnation of my case for
.gitignore.d [http://lists.zerezo.com/git/msg627581.html]).
Thoughts,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
kermit: why are there so many songs about rainbows?
fozzy: that's part of what rainbows do.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: How to re-use setups in multiple tests?
From: Tom Clarke @ 2007-10-01 12:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710011336530.28395@racer.site>
On 10/1/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > I suppose I could find the old pre-rebase head and work with that, but
> > that doesn't seem that clean to me.
>
> You can use "git reset --hard master@{1}", and it really escapes me why
> this should not be clean, and why you want to jump through hoops instead
> using a much more complicated technique.
That'll be because my git knowledge isn't good enough to make it
clean. Thanks for the suggestion :-)
-Tom
^ permalink raw reply
* [PATCH] git-send-email: add a new sendemail.to configuration variable
From: Miklos Vajna @ 2007-10-01 12:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
Several projects prefers to receive patches via a given email address. In these
cases it's handy to configure that address once.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-send-email.txt | 3 +++
git-send-email.perl | 1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 3727776..e38b702 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -159,6 +159,9 @@ sendemail.aliasfiletype::
Format of the file(s) specified in sendemail.aliasesfile. Must be
one of 'mutt', 'mailrc', 'pine', or 'gnus'.
+sendemail.to::
+ Email address (or alias) to always send to.
+
sendemail.cccmd::
Command to execute to generate per patch file specific "Cc:"s.
diff --git a/git-send-email.perl b/git-send-email.perl
index 62e1429..96051bc 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -191,6 +191,7 @@ my %config_settings = (
"smtpserverport" => \$smtp_server_port,
"smtpuser" => \$smtp_authuser,
"smtppass" => \$smtp_authpass,
+ "to" => \@to,
"cccmd" => \$cc_cmd,
"aliasfiletype" => \$aliasfiletype,
"bcc" => \@bcclist,
--
1.5.3.2.111.g5166-dirty
^ permalink raw reply related
* Re: How to re-use setups in multiple tests?
From: Johannes Schindelin @ 2007-10-01 12:39 UTC (permalink / raw)
To: Tom Clarke; +Cc: git
In-Reply-To: <550f9510710010516s305c843br53da294f65318862@mail.gmail.com>
Hi,
On Mon, 1 Oct 2007, Tom Clarke wrote:
> In this case the first test rebases the branch created in setup (it's
> testing the rebase merge strategy), the second test should do the same
> thing, except check there is a warning if a --message option is passed.
>
> I suppose I could find the old pre-rebase head and work with that, but
> that doesn't seem that clean to me.
You can use "git reset --hard master@{1}", and it really escapes me why
this should not be clean, and why you want to jump through hoops instead
using a much more complicated technique.
Ciao,
Dscho
^ permalink raw reply
* Re: git-browser and branch names
From: Jean-François Veillette @ 2007-10-01 12:34 UTC (permalink / raw)
To: Git
In-Reply-To: <ee77f5c20710010424x1f83aa10kcde7033711b02093@mail.gmail.com>
Le 07-10-01 à 07:24, David Symonds a écrit :
>
> Can anyone give me pointers or suggestions as to where to start
> debugging this? Anyone else encountered this?
To debug html/javascript use Firefox and Firebug.
http://www.getfirebug.com/
- jfv
^ permalink raw reply
* Re: How to re-use setups in multiple tests?
From: Tom Clarke @ 2007-10-01 12:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710011243230.28395@racer.site>
In this case the first test rebases the branch created in setup (it's
testing the rebase merge strategy), the second test should do the same
thing, except check there is a warning if a --message option is
passed.
I suppose I could find the old pre-rebase head and work with that, but
that doesn't seem that clean to me.
Here's the code (non-working):
#!/bin/sh
test_description='merge-rebase backend test'
. ./test-lib.sh
test_expect_success setup '
echo hello >a &&
git add a &&
test_tick && git commit -m initial &&
git checkout -b branch &&
echo hello >b &&
git add b &&
test_tick && git commit -m onbranch &&
git checkout master &&
echo update >a &&
git add a &&
test_tick && git commit -m update
'
test_expect_success 'merging using rebase does not create merge
commit' '
git checkout branch &&
git merge -s rebase master &&
( git log --pretty=oneline ) >actual &&
(
echo "4db7a5a013e67aa623d1fd294e8d46e89b3ace8f
onbranch"
echo "893371811dbd13e85c098b72d1ab42bcfd24c2db update"
echo "0e960b10429bf3f1e168ee2cc7d531ac7c622580
initial"
) >expected &&
git diff -w -u expected actual
'
test_expect_success 'merging using rebase with message gives warning'
'
#doesn't work because the branch has already been rebased and
is therefore up to date
git checkout branch &&
git merge -m "a message" -s rebase master 2>&1 expected &&
(
echo "warning: Message is not used for rebase merge
strategy"
) >expected &&
git diff -w -u expected actual
'
test_done
-Tom
On 10/1/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 1 Oct 2007, Tom Clarke wrote:
>
> > I'm wondering if there's a pattern for re-using setups across several
> > tests, similar to how a setUp function is used in xUnit. The problem is
> > I need the setup to actually be re-run, for each test to start from a
> > clean slate, so using the following doesn't work as the setup is just
> > run before the first test.
>
> We typically do the clean up phase explicitely. Or avoid it.
>
> Example: you want to do something to a branch, but the next step should
> use the original state of the branch.
>
> Solution: "git checkout -b new-branch HEAD~5"
>
> Sorry, unless you are a little less mysterious about the exact use case
> you have in mind, I cannot help more.
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: [PATCH v2] git stash: document apply's --index switch
From: Johannes Schindelin @ 2007-10-01 11:49 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Bruno Haible, git
In-Reply-To: <1191239139-26992-1-git-send-email-vmiklos@frugalware.org>
Hi,
On Mon, 1 Oct 2007, Miklos Vajna wrote:
> > - the lines are a bit too long, no?
>
> all lines are shorter than 80 chars, i think it is correct. or am i
> wrong?
No, you are not. But judging from the lines before your change:
> @@ -71,6 +71,11 @@ apply [<stash>]::
> +
> This operation can fail with conflicts; you need to resolve them
> by hand in the working tree.
> ++
> +If the `--index` option is used, this command tries to reinstate not only the
> [...]
it seemed to me that the lines were meant to be shorter. At least they
are easier to read when quoted as a diff in an email.
But it really does not matter much to me.
Ciao,
Dscho
^ permalink raw reply
* Re: How to re-use setups in multiple tests?
From: Johannes Schindelin @ 2007-10-01 11:45 UTC (permalink / raw)
To: Tom Clarke; +Cc: git
In-Reply-To: <550f9510710010327l3e729ff1tbbb9b6c674c1cb11@mail.gmail.com>
Hi,
On Mon, 1 Oct 2007, Tom Clarke wrote:
> I'm wondering if there's a pattern for re-using setups across several
> tests, similar to how a setUp function is used in xUnit. The problem is
> I need the setup to actually be re-run, for each test to start from a
> clean slate, so using the following doesn't work as the setup is just
> run before the first test.
We typically do the clean up phase explicitely. Or avoid it.
Example: you want to do something to a branch, but the next step should
use the original state of the branch.
Solution: "git checkout -b new-branch HEAD~5"
Sorry, unless you are a little less mysterious about the exact use case
you have in mind, I cannot help more.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn and hierarchal branches.
From: Sam Vilain @ 2007-10-01 11:45 UTC (permalink / raw)
To: David Brown; +Cc: git
In-Reply-To: <20070930070754.GA10264@old.davidb.org>
David Brown wrote:
> I'm trying to use git-svn to track the 'Tango' SVN repository
> <http://www.dsource.org/projects/tango/wiki/Download>
>
> Their layout is mostly standard, except that they have an extra hierarchy
> in the branch directory (branch/user1, branch/user2, branch/D1_0 for a
> release).
>
> Is this something I can easily track with git-svn, or am I best trying to
> do it manually?
Track each branch with a separate git-svn remote.
Sam.
^ permalink raw reply
* Re: [PATCH] shortlog: remove --help option parsing
From: Johannes Schindelin @ 2007-10-01 11:42 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20071001102020.GA8315@diku.dk>
Hi,
On Mon, 1 Oct 2007, Jonas Fonseca wrote:
> - else if (!strcmp(argv[1], "-h") || !strcmp(argv[1], "--help"))
> + else if (!strcmp(argv[1], "-h"))
I see that this is my fault.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 1/4] Add a simple option parser for use by builtin-commit.c.
From: Johannes Schindelin @ 2007-10-01 11:39 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Kristian Høgsberg, gitster, git
In-Reply-To: <20071001103148.GC8315@diku.dk>
Hi,
On Mon, 1 Oct 2007, Jonas Fonseca wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote Mon, Oct 01, 2007:
>
> > On Sun, 30 Sep 2007, Jonas Fonseca wrote:
> >
> > > Also, I think for this to be more usable for other built-in programs
> > > it shouldn't modify argv, but instead take both argc and argv (so we
> > > don't need to have code like "*++(*argv)" ;), parse _all_ options in
> > > one go, and return the index (of argv) for any remaining options.
> >
> > We _have_ to modify argv. For example, "git log master -p" is
> > perfectly valid.
>
> Ah, yes this could be nice to also finally have (more universally) in
> git. But for this to be possible I don't see any reason for it to modify
> the pointer to argv. Instead, it can just reshuffle entries in argv.
In that case, I misunderstood you. Indeed, I'd only reshuffle the
entries of argv.
Ciao,
Dscho
^ permalink raw reply
* git-browser and branch names
From: David Symonds @ 2007-10-01 11:24 UTC (permalink / raw)
To: Git
Hi,
I've been using git-browser hooked up to gitweb for several weeks now
(git 1.5.2.1), and it's going great. However, I've hit my first bug:
it seems that certain branch head names cause the whole diagram (and
log lines, etc.) to fail to render, only displaying the "Starting
from: all <repo>.git heads" stuff down the bottom. As to the various
names I've tested:
okay: master, 2.5j, 2.5-dev, a.b, 2-5, 2.b, b.2, 2.5.0
fails: 2.5, 2.6
I've experimented by just using 'git branch -m <old> <new>' to rename
a branch that I'd prefer to just call '2.5', so I'm pretty sure that
I'm not causing things to break myself.
It seems that it's when the branch name looks like a decimal number,
but there's nothing that appears in Apache's error_log. This leads me
to believe it's a Javascript bug.
Can anyone give me pointers or suggestions as to where to start
debugging this? Anyone else encountered this?
Thanks,
Dave.
^ permalink raw reply
* Re: [PATCH] Support tags in uncommit - use git_id instead of rev_parse
From: Karl Hasselström @ 2007-10-01 11:16 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Catalin Marinas, git
In-Reply-To: <20070930172647.18972.49369.stgit@tt.roinet.com>
Sounds like a good idea. Test? :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Don't checkout the full tree if avoidable
From: Eric Wong @ 2007-10-01 11:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Steven Walter
In-Reply-To: <7vejgftgef.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Steven Walter <stevenrwalter@gmail.com> writes:
>
> > In most cases of branching, the tree is copied unmodified from the trunk
> > to the branch. When that is done, we can simply start with the parent's
> > index and apply the changes on the branch as usual.
> >
> > Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
>
> Eric, do you like this one?
Junio, thanks for pinging me about it, I haven't been following the ML
very closely and forgot about this issue.
Steven Walter wrote:
> One criticism of the patch: the trees_match function probably needs to
> be re-written. My SVN::Perl-foo is weak.
Yep :)
Steven:
How does the following work for you? Which version of SVN do you have,
by the way? I just found a bug with the way SVN::Client::diff() is
exported for SVN 1.1.4, hence the SVN::Pool->new_default_sub usage.
From: Steven Walter <stevenrwalter@gmail.com>
Date: Fri, 28 Sep 2007 13:24:19 -0400
Subject: [PATCH] Don't checkout the full tree if avoidable
In most cases of branching, the tree is copied unmodified from the trunk
to the branch. When that is done, we can simply start with the parent's
index and apply the changes on the branch as usual.
[ew: rewritten from Steven's original to use SVN::Client instead
of the command-line svn client.
Since SVN::Client connects separately, we'll share our
authentication providers array between our usages of
SVN::Client and SVN::Ra, too. Bypassing the high-level
SVN::Client library can avoid this, but the code will be
much more complex. Regardless, any implementation of this
seems to require restarting a connection to the remote
server.
Also of note is that SVN 1.4 and later allows a more
efficient diff_summary to be done instead of a full diff,
but since this code is only to support SVN < 1.4.4, we'll
ignore it for now.]
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 64 +++++++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 48 insertions(+), 16 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 484b057..777e436 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1847,6 +1847,16 @@ sub find_parent_branch {
$gs->ra->gs_do_switch($r0, $rev, $gs,
$self->full_url, $ed)
or die "SVN connection failed somewhere...\n";
+ } elsif ($self->ra->trees_match($new_url, $r0,
+ $self->full_url, $rev)) {
+ print STDERR "Trees match:\n",
+ " $new_url\@$r0\n",
+ " ${\$self->full_url}\@$rev\n",
+ "Following parent with no changes\n";
+ $self->tmp_index_do(sub {
+ command_noisy('read-tree', $parent);
+ });
+ $self->{last_commit} = $parent;
} else {
print STDERR "Following parent with do_update\n";
$ed = SVN::Git::Fetcher->new($self);
@@ -3027,28 +3037,32 @@ BEGIN {
}
}
+sub _auth_providers () {
+ [
+ SVN::Client::get_simple_provider(),
+ SVN::Client::get_ssl_server_trust_file_provider(),
+ SVN::Client::get_simple_prompt_provider(
+ \&Git::SVN::Prompt::simple, 2),
+ SVN::Client::get_ssl_client_cert_file_provider(),
+ SVN::Client::get_ssl_client_cert_prompt_provider(
+ \&Git::SVN::Prompt::ssl_client_cert, 2),
+ SVN::Client::get_ssl_client_cert_pw_prompt_provider(
+ \&Git::SVN::Prompt::ssl_client_cert_pw, 2),
+ SVN::Client::get_username_provider(),
+ SVN::Client::get_ssl_server_trust_prompt_provider(
+ \&Git::SVN::Prompt::ssl_server_trust),
+ SVN::Client::get_username_prompt_provider(
+ \&Git::SVN::Prompt::username, 2)
+ ]
+}
+
sub new {
my ($class, $url) = @_;
$url =~ s!/+$!!;
return $RA if ($RA && $RA->{url} eq $url);
SVN::_Core::svn_config_ensure($config_dir, undef);
- my ($baton, $callbacks) = SVN::Core::auth_open_helper([
- SVN::Client::get_simple_provider(),
- SVN::Client::get_ssl_server_trust_file_provider(),
- SVN::Client::get_simple_prompt_provider(
- \&Git::SVN::Prompt::simple, 2),
- SVN::Client::get_ssl_client_cert_file_provider(),
- SVN::Client::get_ssl_client_cert_prompt_provider(
- \&Git::SVN::Prompt::ssl_client_cert, 2),
- SVN::Client::get_ssl_client_cert_pw_prompt_provider(
- \&Git::SVN::Prompt::ssl_client_cert_pw, 2),
- SVN::Client::get_username_provider(),
- SVN::Client::get_ssl_server_trust_prompt_provider(
- \&Git::SVN::Prompt::ssl_server_trust),
- SVN::Client::get_username_prompt_provider(
- \&Git::SVN::Prompt::username, 2),
- ]);
+ my ($baton, $callbacks) = SVN::Core::auth_open_helper(_auth_providers);
my $config = SVN::Core::config_get_config($config_dir);
$RA = undef;
my $self = SVN::Ra->new(url => $url, auth => $baton,
@@ -3112,6 +3126,24 @@ sub get_log {
$ret;
}
+sub trees_match {
+ my ($self, $url1, $rev1, $url2, $rev2) = @_;
+ my $ctx = SVN::Client->new(auth => _auth_providers);
+ my $out = IO::File->new_tmpfile;
+
+ # older SVN (1.1.x) doesn't take $pool as the last parameter for
+ # $ctx->diff(), so we'll create a default one
+ my $pool = SVN::Pool->new_default_sub;
+
+ $ra_invalid = 1; # this will open a new SVN::Ra connection to $url1
+ $ctx->diff([], $url1, $rev1, $url2, $rev2, 1, 1, 0, $out, $out);
+ $out->flush;
+ my $ret = (($out->stat)[7] == 0);
+ close $out or croak $!;
+
+ $ret;
+}
+
sub get_commit_editor {
my ($self, $log, $cb, $pool) = @_;
my @lock = $SVN::Core::VERSION ge '1.2.0' ? (undef, 0) : ();
--
Eric Wong
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox