* Re: Is git-imap-send able to use SSL?
From: Alam Arias @ 2008-06-21 5:16 UTC (permalink / raw)
To: git
In-Reply-To: <D3F1364D-68DC-457D-AC54-AE4B70B1B5AB@gmail.com>
On Fri, 20 Jun 2008 18:08:42 +0200
Cristian Peraferrer <corellian.c@gmail.com> wrote:
> I am trying to use git-imap-send to send a Draft to my GMail account
> which uses SSL to connect, I have put the correct port (993 in that
> case) in the config file but it seems it doesn't work. I figure that
> git-imap-send is not able to connect using SSL.
>
well, there a patch by for SSL support for git-imap-send by Rob
Shearman "robertshearman@gmail.com" over two weeks ago but it did not
apply cleanly on master at the time, well, maybe I can send
my version of this patch? or do I need to ask Rob Shearman?
^ permalink raw reply
* [PATCH] Documentation cvs: Clarify when a bare repository is needed
From: Matthew Ogilvie @ 2008-06-21 4:52 UTC (permalink / raw)
To: git; +Cc: le_wen, Matthew Ogilvie
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
This was inspired because periodically someone asks about the
"Index already exists in git repo" error message from git-cvsserver,
and I noticed that two relevant and common starting points in the
documentation (git-cvsserver and get-cvsimport) do not mention
that a shared repository should be bare.
Maybe someone should write up something similar for things like
git-push, git-svn, various other import scripts, etc. I don't really
know enough about any of them and how they interact with non-bare
repositories to write reliable documentation.
While in gitcvs-migration, I also noticed that it doesn't mention
git-cvsexportcommit at all, but I'm not sure if it should just
have a link in the "SEE ALSO" section, a sentence or two near where
it talks about incremental imports (since if you need incrementatl
import, you likely also need incremental export), or a whole new section.
Since I've never used cvsexportcommit at all, I'm not real
confident on what to say about how to use it with incremental import.
- Matthew Ogilvie
Documentation/git-cvsimport.txt | 6 ++++++
Documentation/git-cvsserver.txt | 3 +++
Documentation/gitcvs-migration.txt | 5 +++++
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 2f9b35f..c90de06 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -31,6 +31,12 @@ to work with; after that, you need to 'git merge' incremental imports, or
any CVS branches, yourself. It is advisable to specify a named remote via
-r to separate and protect the incoming branches.
+If you intend to set up a shared public repository that all developers can
+read/write, or if you want to use linkgit:git-cvsserver[1], then you
+probably want to make a bare clone of the imported repository,
+and use the clone as the shared repository.
+See linkgit:gitcvs-migration[7][CVS migration].
+
OPTIONS
-------
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 3310ae2..e22e107 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -133,6 +133,9 @@ write access to the log file and to the database (see
<<dbbackend,Database Backend>>. If you want to offer write access over
SSH, the users of course also need write access to the git repository itself.
+You also need to ensure that each repository is "bare" (without a git index
+file) for `cvs commit` to work. See linkgit:gitcvs-migration[7][CVS migration].
+
[[configaccessmethod]]
All configuration variables can also be overridden for a specific method of
access. Valid method names are "ext" (for SSH access) and "pserver". The
diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt
index 1db3f52..64c7550 100644
--- a/Documentation/gitcvs-migration.txt
+++ b/Documentation/gitcvs-migration.txt
@@ -143,6 +143,11 @@ work, you must not modify the imported branches; instead, create new
branches for your own changes, and merge in the imported branches as
necessary.
+If you want a shared repository, you will need to make a bare clone
+of the imported directory, as described above. Merging incremental
+imports could then be handled much like any other development clone of
+the shared repository.
+
Advanced Shared Repository Management
-------------------------------------
--
1.5.5.1.385.g2f071
^ permalink raw reply related
* Re: Still have problem with index file.
From: Matthew M. Ogilvie @ 2008-06-21 4:49 UTC (permalink / raw)
To: Le; +Cc: git
In-Reply-To: <485BD988.8040201@distributel.ca>
On Fri, Jun 20, 2008 at 12:23:36PM -0400, Le wrote:
> Hi, Matthew,
>
> I am using the latest version of git cvsserver:
> md5sum /usr/bin/git-cvsserver
> fdb0396298d51b37791161f4e62536ce /usr/bin/git-cvsserver
>
> which has your patch. But I still have the problem of index file by
> commit new change:
> cvs commit: Examining .
> Index already exists in git repo
>
> I have heard that one can delete the index file in .git.
> Is it the right solution for this problem?
> After deleted this file the git repository is still working as before?
> I mean it is available for cvs client sand git clients
> at the same time?
>
>
> Thank you!
>
> Le
I hadn't seen this message before, and it is not really related to my
crlf patch, but I did find some limited information via google:
http://www.gelato.unsw.edu.au/archives/git/0605/21177.html
My own take on it:
git-cvsserver has always expected to serve up a "bare"
repository (without an index file or checked out
files, using the plain git [no CVS] notion of "checked out").
git-cvsserver uses a simple hueristic of checking for a ".git/index"
file to check for a bare repository before allowing commits,
otherwise it could mess up the HEAD for the checkout.
In answer to your question, if you haven't made any uncommitted
changes to the working files in your git repository, then it should
be safe to delete those working files and the .git/index file that
goes with them. Just make sure you have backups, and be careful
not to delete anything else under .git. If you do have
uncommitted changes, you may want to "git commit" them first.
You may also want to look up "gitcvs-migration",
especially the part about "Setting Up a Shared Repository".
http://www.kernel.org/pub/software/scm/git/docs/gitcvs-migration.html
I noticed that neither the man page for git-cvsimport nor for
git-cvsserver mention anything about bare repositories. I'll look
into improving the documentation.
- Matthew Ogilvie
PS: Also, in the future it might be better to at least CC the git
mailing list, as I've just done: git@vger.kernel.org. I've read some
of the git documentation and source code, and even submitted
a few patches, but haven't really used it much.
^ permalink raw reply
* [PATCH] Correct documentation for git-push --mirror
From: Shawn O. Pearce @ 2008-06-21 3:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Marek Zawirski
This option behaves more like:
git push $url +refs/*:refs/*
then it does like:
git push $url +refs/heads/*:refs/heads/* +refs/tags/*:refs/tags/*
so we should document it to be more clear about that.
Suggested-by: Marek Zawirski <marek.zawirski@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/git-push.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 89e0049..f3d5d88 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -67,7 +67,8 @@ nor in any Push line of the corresponding remotes file---see below).
--mirror::
Instead of naming each ref to push, specifies that all
- refs under `$GIT_DIR/refs/heads/` and `$GIT_DIR/refs/tags/`
+ refs under `$GIT_DIR/refs/` (which includes but is not
+ limited to `refs/heads/`, `refs/remotes/`, and `refs/tags/`)
be mirrored to the remote repository. Newly created local
refs will be pushed to the remote end, locally updated refs
will be force updated on the remote end, and deleted refs
--
1.5.6.153.g07215
^ permalink raw reply related
* Re: [PATCH] git-gui: Fix accidental staged state toggle when clicking top pixel row
From: Shawn O. Pearce @ 2008-06-21 3:21 UTC (permalink / raw)
To: Richard Quirk; +Cc: git
In-Reply-To: <1213973895-10264-1-git-send-email-richard.quirk@gmail.com>
Richard Quirk <richard.quirk@gmail.com> wrote:
> If a text widget is asked the index at x,y with y == 0 or y == 1 it will
> always return 1.0 as the nearest index, regardless of the x position.
>
> This means that clicking the top 2 pixels of the Unstaged/Staged Changes
> lists caused the state of the file there to be toggled. This patch
> checks that the pixel clicked is greater than 1, so there is less chance
> of accidentally staging or unstaging changes.
Thanks. Its in my master branch now.
--
Shawn.
^ permalink raw reply
* Are C++ contributions welcome?
From: David Aguilar @ 2008-06-21 1:57 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <402731c90806201853x1c57ec5fib39bd92810072611@mail.gmail.com>
On Fri, Jun 20, 2008 at 9:29 AM, David Kastrup <dak@gnu.org> wrote:
> Jose María Gómez Vergara <josemaria@jmgv.org> writes:
>
>> Before starting, do you have any preference for Qt or Gtk in Git. I feel quite
>> confortable with both of them.
>>
>> Qt . C++ GPL
>> Gtk+. C - LGPL
>>
>> The quality is good for both of them
>
> Please take a look at
> <URL:http://developer.imendio.com/projects/giggle>. It might be
> worthwhile not to start from scratch here.
>
> --
> David Kastrup
And if you don't mind Python, Qt, LGPL...
http://cola.tuxfamily.org/
http://gitorious.org/projects/git-cola/
enjoy,
--
David
--
David
^ permalink raw reply
* Re: [PATCH 1/2] t3404: extra checks and s/! git/test_must_fail git/
From: Stephan Beyer @ 2008-06-21 1:46 UTC (permalink / raw)
To: nanako3; +Cc: Brandon Casey, git, Johannes Schindelin, Christian Couder
In-Reply-To: <20080621071812.6117@nanako3.lavabit.com>
Hi,
> > Perhaps I'm not consequent, but I thought that it's not worth it ;-)
>
> Doesn't that logic make the other s/!/test_must_fail/ changes
> also not worth it? What is the reason behind the change?
The s/!/test_must_fail/ is just an "extra" like
"Hey, you're currently standing, can you bring me some tea?"
In this case:
"Oh, I'm currently adding some tests, so I can s/!/test_must_fail/"
> I think your subject line and the message is worse than your
> previous one. You are saying *HOW* you changed it,
Not exactly.
In the previous one I said, what my patch does: improve t3404.
The latter one said it, too, but a little more specific.
> without saying *WHY* nor *WHAT FOR*.
That's right.
The s/!/test_must_fail/ is, as I said, just an "extra".
And one that does no harm at all.
The others are tests that were useful during git sequencer prototype
development, because once a test in the middle of the test suite failed
because the branch was not correctly reset in one of the invocations of
rebase-i in the first tests.
Well, but I wonder if a long explanation is always necessary.
It is on feature patches and bugfix patches. But here?
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Move deletion of configure generated files to distclean
From: Stephan Beyer @ 2008-06-21 1:35 UTC (permalink / raw)
To: shire; +Cc: git
In-Reply-To: <D4D1BF84-3D3F-4DEC-87C0-F926228E0BF5@tekrat.com>
Hi,
whitespace and linebreaks are broken in your patch.
(Just noticed because I needed a quick patch to test something and I
took yours.)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Move deletion of configure generated files to distclean
From: Miklos Vajna @ 2008-06-21 1:28 UTC (permalink / raw)
To: shire; +Cc: git
In-Reply-To: <D4D1BF84-3D3F-4DEC-87C0-F926228E0BF5@tekrat.com>
[-- Attachment #1: Type: text/plain, Size: 554 bytes --]
On Fri, Jun 20, 2008 at 05:57:45PM -0700, shire <shire@tekrat.com> wrote:
> Running "make clean" also requires a run of "./configure ..." again because
> it deletes auto-generated files, which I found a little unexpected. I
> figured I'd mention it as I'm not sure if this is confusing for other users
> or intended functionality of "make clean" vs. "make distclean", I would
> assume that the first would not revert configuration changes.
I remember I was surprised as well when first time I noticed this
behaviour, so I like your patch.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Move deletion of configure generated files to distclean
From: shire @ 2008-06-21 0:57 UTC (permalink / raw)
To: git
Running "make clean" also requires a run of "./configure ..." again
because it deletes auto-generated files, which I found a little
unexpected. I figured I'd mention it as I'm not sure if this is
confusing for other users or intended functionality of "make clean"
vs. "make distclean", I would assume that the first would not revert
configuration changes.
Signed-off-by: Brian Shire <shire@tekrat.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index b003e3e..f868b0b 100644
--- a/Makefile
+++ b/Makefile
@@ -1346,6 +1346,7 @@ dist-doc:
### Cleaning rules
distclean: clean
+ $(RM) config.log config.mak.autogen config.mak.append config.status
config.cache
$(RM) configure
clean:
@@ -1355,7 +1356,6 @@ clean:
$(RM) $(TEST_PROGRAMS)
$(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
cscope*
$(RM) -r autom4te.cache
- $(RM) config.log config.mak.autogen config.mak.append config.status
config.cache
$(RM) -r $(GIT_TARNAME) .doc-tmp-dir
$(RM) $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
$(RM) $(htmldocs).tar.gz $(manpages).tar.gz
--
1.5.6.dirty
^ permalink raw reply related
* Re: [PATCH 00/11] Build in merge
From: Miklos Vajna @ 2008-06-21 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4p7oq029.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 997 bytes --]
On Thu, Jun 19, 2008 at 08:04:14PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > As usual, comments are welcome. :-)
>
> Thanks.
>
> I take that last line of comment to mean "this is still RFC and not for
> inclusion yet" ;-) I think the series is fine up to eighth patch (get
> octopus merge base).
In fact only the version that had "WIP" in the subject was sent not for
inclusion. ;-)
> I'll queue the whole thing (still strictly as "test merge" basis) to 'pu';
> I've fixed 3 "old-style C function definition" issues you have in the
> tenth patch (build in merge), and I have some other issues with the ninth
> one (filter independent).
Thanks. I'm using the kernel's scripts/checkpatch.pl, but it does not
have such a check, and I missed it.
Currently I have 12 patches in my branch; if there will be no objections
to the new "filter independent" one, then I will resend the series
excluding the first 8 to avoid unnecessary traffic, if that is OK to
you.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Introduce filter_independent() in commit.c
From: Miklos Vajna @ 2008-06-21 0:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabhgq02p.fsf@gitster.siamese.dyndns.org>
This is similar to git-show-branch --independent: It filters out commits
which are reachable from any other item from the input list.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Thu, Jun 19, 2008 at 08:03:58PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > + for (i = heads; i; i = i->next)
> > + if (!(i->item->object.flags & RESULT))
> > + pptr = &commit_list_insert(i->item, pptr)->next;
>
> Hmm. How well was this function tested?
As Dscho pointed out in an other mail there was no testcase for it, I
wrote one and it pointed out what you said: it was buggy.
> Because RESULT is an implementation detail of merge_bases(), I do not
> think we would want to expose it outside of it.
The new version does not have this problem, either.
> More worryingly, the flag is supposed to be cleaned from the objects
> after get_merge_bases() returns. I am not sure what you'll learn by
> looking at the flag here.
Yes, you are right. In fact the idea to use get_octopus_merge_bases()
was wrong, since it does not do what we need.
Here is an example:
A - B
\ C
\ D
\ E - F
In this case get_octopus_merge_bases() will return only A, which is what
it should do, but we need E in filter_indepenent() as well.
Below is what I pushed to my working branch.
This version now passes the test that was failed for the previous one.
commit.c | 32 ++++++++++++++++++++++++++++++++
commit.h | 1 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/commit.c b/commit.c
index 6052ca3..17e18d7 100644
--- a/commit.c
+++ b/commit.c
@@ -705,3 +705,35 @@ int in_merge_bases(struct commit *commit, struct commit **reference, int num)
free_commit_list(bases);
return ret;
}
+
+struct commit_list *filter_independent(unsigned char *head,
+ struct commit_list *heads)
+{
+ struct commit_list *b, *i, *j, *k, *bases = NULL, *ret = NULL;
+ struct commit_list **pptr = &ret;
+
+ commit_list_insert(lookup_commit(head), &heads);
+
+ for (i = heads; i; i = i->next) {
+ for (j = heads; j; j = j->next) {
+ if (i == j)
+ continue;
+ b = get_merge_bases(i->item, j->item, 1);
+ for (k = b; k; k = k->next)
+ commit_list_insert(k->item, &bases);
+ }
+ }
+
+ for (i = heads; i; i = i->next) {
+ int found = 0;
+ for (b = bases; b; b = b->next) {
+ if (!hashcmp(i->item->object.sha1, b->item->object.sha1)) {
+ found = 1;
+ break;
+ }
+ }
+ if (!found)
+ pptr = &commit_list_insert(i->item, pptr)->next;
+ }
+ return ret;
+}
diff --git a/commit.h b/commit.h
index dcec7fb..0aef7e4 100644
--- a/commit.h
+++ b/commit.h
@@ -131,6 +131,7 @@ extern struct commit_list *get_shallow_commits(struct object_array *heads,
int depth, int shallow_flag, int not_shallow_flag);
int in_merge_bases(struct commit *, struct commit **, int);
+struct commit_list *filter_independent(unsigned char *head, struct commit_list *heads);
extern int interactive_add(int argc, const char **argv, const char *prefix);
extern int rerere(void);
--
1.5.6
^ permalink raw reply related
* Re: [PATCH 1/2] t3404: extra checks and s/! git/test_must_fail git/
From: しらいしななこ @ 2008-06-20 22:18 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Brandon Casey, git, Johannes Schindelin, Christian Couder
In-Reply-To: <20080620190037.GE7369@leksak.fem-net>
Quoting Stephan Beyer <s-beyer@gmx.net>:
> Hi,
>
>> > @@ -380,7 +397,7 @@ test_expect_success 'interrupted squash works as expected' '
>> > ! FAKE_LINES="1 squash 3 2" git rebase -i HEAD~3 &&
>>
>> These can be converted to use test_must_fail by using a sub-shell
>> as Junio demonstrated:
>>
>> (
>> FAKE_LINES="1 squash 3 2" &&
>> export FAKE_LINES &&
>> test_must_fail git rebase -i HEAD~3
>> ) &&
>
> Perhaps I'm not consequent, but I thought that it's not worth it ;-)
Doesn't that logic make the other s/!/test_must_fail/ changes
also not worth it? What is the reason behind the change?
I think your subject line and the message is worse than your
previous one. You are saying *HOW* you changed it, without
saying *WHY* nor *WHAT FOR*.
I may have written your log message like this:
Subject: t3404: tighten git-rebase tests
In preparation for rewriting git-rebase in C, replace the way a
failure is currently detected with "! git" to use test_must_fail
so that we do not confuse a broken rebase that dumps core with a
correctly failing one.
although I do not know if you are rewriting git-rebase in C
(^_^). The point I learned from this project is to say why it
is done that way, not how you did it. The latter can be seen in
the diff.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [WIP/PATCH v4] gitweb: add test suite with Test::WWW::Mechanize::CGI
From: Lea Wiemann @ 2008-06-20 22:18 UTC (permalink / raw)
To: git; +Cc: Lea Wiemann, Jakub Narebski
In-Reply-To: <485C2989.6060406@gmail.com>
This test uses Test::WWW::Mechanize::CGI to check gitweb's output. It
also uses HTML::Lint (if present) to validate the HTML.
TOOD: Make this runnable even when the path to the git tree (i.e. your
working copy) contains blanks.
http://mid.gmane.org/200806202003.55919.jnareb@gmail.com
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
---
This for everyone's reference so you have my most recent version to
base changes on.
Changed since v3: applied Jakub's suggestions, and added TODO note to
commit message so this doesn't get applied accidentally.
t/t9503-gitweb-Mechanize.sh | 128 +++++++++++++++++++++++++++++++++++++++++++
t/t9503/test.pl | 128 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 256 insertions(+), 0 deletions(-)
create mode 100755 t/t9503-gitweb-Mechanize.sh
create mode 100755 t/t9503/test.pl
diff --git a/t/t9503-gitweb-Mechanize.sh b/t/t9503-gitweb-Mechanize.sh
new file mode 100755
index 0000000..abcf987
--- /dev/null
+++ b/t/t9503-gitweb-Mechanize.sh
@@ -0,0 +1,128 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Jakub Narebski
+# Copyright (c) 2008 Lea Wiemann
+#
+
+test_description='gitweb as CGI (using WWW::Mechanize)
+
+This test uses Perl module Test::WWW::Mechanize::CGI to
+check gitweb output, using HTML::Lint to validate HTML.'
+
+# helper functions
+
+safe_chmod () {
+ chmod "$1" "$2" &&
+ if [ "$(git config --get core.filemode)" = false ]
+ then
+ git update-index --chmod="$1" "$2"
+ fi
+}
+
+. ./test-lib.sh
+
+# check if test can be run
+perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
+ test_expect_success \
+ 'skipping gitweb tests, perl version is too old' :
+ test_done
+ exit
+}
+
+perl -MTest::WWW::Mechanize::CGI -e '' >/dev/null 2>&1 || {
+ test_expect_success \
+ 'skipping gitweb tests, Test::WWW::Mechanize::CGI not found' :
+ test_done
+ exit
+}
+
+# set up test repository
+test_expect_success 'set up test repository' '
+
+ echo "Not an empty file." > file &&
+ git add file &&
+ test_tick && git commit -a -m "Initial commit." &&
+ git branch b &&
+
+ echo "New file" > new_file &&
+ git add new_file &&
+ test_tick && git commit -a -m "File added." &&
+
+ safe_chmod +x new_file &&
+ test_tick && git commit -a -m "Mode changed." &&
+
+ git mv new_file renamed_file &&
+ test_tick && git commit -a -m "File renamed." &&
+
+ rm renamed_file &&
+ ln -s file renamed_file &&
+ test_tick && git commit -a -m "File to symlink." &&
+ git tag with-symlink &&
+
+ git rm renamed_file &&
+ rm -f renamed_file &&
+ test_tick && git commit -a -m "File removed." &&
+
+ cp file file2 &&
+ git add file2 &&
+ test_tick && git commit -a -m "File copied." &&
+
+ echo "New line" >> file2 &&
+ safe_chmod +x file2 &&
+ test_tick && git commit -a -m "Mode change and modification." &&
+
+ git checkout b &&
+ echo "Branch" >> b &&
+ git add b &&
+ test_tick && git commit -a -m "On branch" &&
+ git checkout master &&
+ test_tick && git pull . b
+'
+
+# set up empty repository
+# TODO!
+
+# set up repositories for gitweb
+# TODO!
+
+# set up gitweb configuration
+safe_pwd="$(perl -MPOSIX=getcwd -e 'print quotemeta(getcwd)')"
+cat >gitweb_config.perl <<EOF
+#!/usr/bin/perl
+
+# gitweb configuration for tests
+
+our \$version = "current";
+our \$GIT = "$GIT_EXEC_PATH/git";
+our \$projectroot = "$safe_pwd";
+our \$project_maxdepth = 8;
+our \$home_link_str = "projects";
+our \$site_name = "[localhost]";
+our \$site_header = "";
+our \$site_footer = "";
+our \$home_text = "indextext.html";
+our @stylesheets = ("file:///$safe_pwd/../../gitweb/gitweb.css");
+our \$logo = "file:///$safe_pwd/../../gitweb/git-logo.png";
+our \$favicon = "file:///$safe_pwd/../../gitweb/git-favicon.png";
+our \$projects_list = "";
+our \$export_ok = "";
+our \$strict_export = "";
+
+1;
+__END__
+EOF
+
+cat >.git/description <<EOF
+$0 test repository
+EOF
+
+GITWEB_CONFIG="$(pwd)/gitweb_config.perl"
+export GITWEB_CONFIG
+
+# run tests
+
+test_external \
+ 'test gitweb output' \
+ perl ../t9503/test.pl
+
+test_done
diff --git a/t/t9503/test.pl b/t/t9503/test.pl
new file mode 100755
index 0000000..7e7c98c
--- /dev/null
+++ b/t/t9503/test.pl
@@ -0,0 +1,128 @@
+#!/usr/bin/perl
+use lib (split(/:/, $ENV{GITPERLLIB}));
+
+use warnings;
+use strict;
+
+use Cwd qw(abs_path);
+use File::Spec;
+
+# We don't count properly when skipping, so no_plan is necessary.
+use Test::More qw(no_plan);
+use Test::WWW::Mechanize::CGI;
+
+my $long_tests = $ENV{GIT_TEST_LONG};
+
+eval { require HTML::Lint };
+my $use_lint = !$@;
+diag('HTML::Lint is not installed; no HTML validation tests')
+ unless $use_lint;
+
+my @revisions = split /\s/, `git-rev-list --first-parent HEAD`;
+my $head = $revisions[0];
+
+my $gitweb = File::Spec->catfile('..','..','gitweb','gitweb.cgi');
+# The following two lines of code are a workaround for a bug in
+# Test::WWW::Mechanize::CGI::cgi_application version up to 0.3
+# (http://rt.cpan.org/Ticket/Display.html?id=36654) for pathnames with
+# spaces (because of "trash directory")
+$gitweb = File::Spec->rel2abs($gitweb);
+$gitweb = Cwd::abs_path($gitweb);
+
+my $mech = new Test::WWW::Mechanize::CGI;
+$mech->cgi_application($gitweb);
+# On some systems(?) it's necessary to have %ENV here, otherwise the
+# CGI process won't get *any* of the current environment variables
+# (not even PATH, etc.)
+$mech->env(%ENV, GITWEB_CONFIG => $ENV{'GITWEB_CONFIG'}, $mech->env);
+
+# import config, predeclaring config variables
+my $site_name = '';
+require_ok($ENV{'GITWEB_CONFIG'})
+ or diag('Could not load gitweb config; some tests would fail');
+
+my %checked_pages;
+# Validate and spider the current page, if --long-tests (-l) is given.
+sub check_page {
+ my $uri = $mech->uri;
+ if (not $checked_pages{$uri}) {
+ $mech->html_lint_ok('validate') or return 0 if $long_tests && $use_lint;
+ $mech->page_links_ok("check links on $uri") if $long_tests;
+ $checked_pages{$uri} = 1;
+ }
+ return 1
+}
+
+my $baseurl = "http://localhost";
+my ($params, $url, $pagedesc, $status);
+
+# test_page ( <params>, <page_description>, <expected_status> )
+# Example:
+# if (test_page('?p=.git;a=summary', 'repository summary')) {
+# $mech->...;
+# $mech->...;
+# }
+#
+# Test that the page can be opened (and if --long-tests is given that
+# it validates and has valid links), and return true if it does. Also
+# set the global variables $params, $pagedesc, and $url for use in the
+# if block. Optionally pass a third parameter $status to test the
+# HTTP status code of the page (useful for error pages).
+sub test_page {
+ ($params, $pagedesc, $status) = @_;
+ $url = "$baseurl$params";
+ if($status) {
+ $mech->get($url);
+ } else {
+ $mech->get_ok($url, "GET \"$params\" -- $pagedesc") or return 0;
+ }
+ check_page or return 0;
+ if($status) {
+ return is($mech->status, $status, "GET \"$params\" -- $pagedesc -- yields $status");
+ } else {
+ return 1;
+ }
+}
+
+if (test_page '', 'project list (implicit)') {
+ $mech->title_like(qr!$site_name!,
+ "title contains $site_name");
+ $mech->content_contains('./t9503-gitweb-Mechanize.sh test repository',
+ 'lists test repository (by description)');
+}
+
+# Test repository summary: implicit, implicit with pathinfo, explicit.
+for my $sumparams ('?p=.git', '/.git', '?p=.git;a=summary') {
+ if (test_page $sumparams, 'repository summary') {
+ $mech->title_like(qr!$site_name.*\.git/summary!,
+ "title contains $site_name and \".git/summary\"");
+ }
+}
+
+# Search form (on summary page).
+$mech->get_ok('?p=.git', 'get repository summary');
+if ($mech->submit_form_ok( { form_number => 1,
+ fields => { 's' => 'Initial' }
+ }, "submit search form (default)")) {
+ check_page;
+ $mech->content_contains('Initial commit',
+ 'content contains searched commit');
+}
+
+test_page('?p=non-existent.git', 'non-existent project', 404);
+test_page('?p=.git;a=commit;h=non-existent', 'non-existent commit', 404);
+
+# Summary page.
+
+# Check short log. To do: Extract into separate test_short_log
+# function since the short log occurs on several pages.
+$mech->get_ok('?p=.git', 'get repository summary');
+for my $revision (@revisions[0..2]) {
+ for my $link_text qw( commit commitdiff tree snapshot ) {
+ ok($mech->find_link(url_abs_regex => qr/h=$revision/, text => $link_text), "$link_text link for $revision");
+ }
+}
+
+
+1;
+__END__
--
1.5.6.80.g3141.dirty
^ permalink raw reply related
* Re: [PATCH] git-send-pack: don't consider branch lagging behind as errors.
From: しらいしななこ @ 2008-06-20 22:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, Jeff King, git
In-Reply-To: <7vhcbpuvfb.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> The issue of "many refs in the repo but I work only on a few" has already
> been resolved by being able to say "I push only the current branch" in the
> previous thread, I think, but I am too busy to go back to re-study the
> history, so could you kindly do that for us?
I almost agreed with Pierre before I read your response, but as
always you are right. If the only thing I know is that my
current branch is ready to be pushed and I do not know if other
branches are, I do not have to push all branches (I am not sure
how exactly it works. Do we push all the branches, or do we push
branches that exist on both sides?). Pushing the one I want to
push is the right thing to do, and I can easily say it.
> You might argue that the case where you are truly behind _could_ be
> ignored and pretend as if the user did not even _ask_ to push it (hence,
> return success without doing anything to that branch), but I am not
> convinced even that is a good idea.
But I think that is a reasonable new feature and is close to
what Pierre is asking for. He wants to be able to push "all
except for the ones that he does not want to push", wants
git to guess which ones are the ones he does not, and wants to
make the logic of guessing to consider stale ones are unwanted.
But I do agree with you that it is wrong to replace existing
"push all" with such a new feature. When people want to push
all, they do want to push all and see the command report error
when some branches are not updated. Even though I think what
Pierre wants to have may be a reasonable new feature, it should
not break "push all" for people who rely on the existing
behavior.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [WIP/PATCH v3] gitweb: add test suite with Test::WWW::Mechanize::CGI
From: Lea Wiemann @ 2008-06-20 22:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200806202003.55919.jnareb@gmail.com>
Jakub Narebski wrote:
> Lea Wiemann wrote:
>> Sure; FWIW I'm generally in favor of having a large initial commit for
>> new independent files [...]
>
> I just think that having this separate could help bisectability in
> the case of errors.
Hm... I wouldn't think that bisect could be necessary for a long linear
(sequential) test script, where the errors are clearly locatable.
> What could be added is different types of stage output: filenames with
> '*', '+', '=', ':', '?', whitespace, etc. Checking if submodules
> doesn't trip gitweb would be good idea too.
Yup, filenames with ampersands and semicolons would be fun, too.
(Submodules seem to work, but that should be covered as well of course.)
> [Full SHA1s] would reduce number of operations when crawling gitweb output.
Right; changed.
> Actually ->cgi_application(<path>) is implemented using ->cgi(<sub>)
> in TWM::CGI. The bug is that it uses straight "system($application)",
>
> [it] would fail if you run test from the directory which contains spaces,
OK, now I see what you mean. Well, awesome, borked lirbareis. I've put
this as a TODO into the commit message; will take care of it later.
>>>> +our $baseurl = "http://localhost";
>>>> +our($params, $url, $pagedesc, $status);
>>> I think we can use 'my' here;
Fixed, and thanks for the offline explanations.
-- Lea
^ permalink raw reply
* [PATCH] t/README: Add 'Skipping Tests' section below 'Running Tests'
From: Jakub Narebski @ 2008-06-20 21:10 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano
Add description of GIT_SKIP_TESTS variable, taken almost verbatim
(adjusting for conventions in t/README) from the commit message in
04ece59 (GIT_SKIP_TESTS: allow users to omit tests that are known to break)
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
So I don't have to look it up every time I want to use it...
t/README | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/t/README b/t/README
index dc89263..8f12d48 100644
--- a/t/README
+++ b/t/README
@@ -59,6 +59,34 @@ Running Tests
available), for more exhaustive testing.
+Skipping Tests
+--------------
+
+In some environments, certain tests have no way of succeeding
+due to platform limitation, such as lack of 'unzip' program, or
+filesystem that do not allow arbitrary sequence of non-NUL bytes
+as pathnames.
+
+You should be able to say something like
+
+ $ GIT_SKIP_TESTS=t9200.8 sh ./t9200-git-cvsexport-commit.sh
+
+and even:
+
+ $ GIT_SKIP_TESTS='t[0-4]??? t91?? t9200.8' make
+
+to omit such tests. The value of the environment variable is a
+SP separated list of patterns that tells which tests to skip,
+and either can match the "t[0-9]{4}" part to skip the whole
+test, or t[0-9]{4} followed by ".$number" to say which
+particular test to skip.
+
+Note that some tests in the existing test suite rely on previous
+test item, so you cannot arbitrarily disable one and expect the
+remainder of test to check what the test originally was intended
+to check.
+
+
Naming Tests
------------
--
1.5.6
^ permalink raw reply related
* Re: Newbie question about making a bare repository
From: D. Stuart Freeman @ 2008-06-20 20:53 UTC (permalink / raw)
To: stuart.freeman; +Cc: git
In-Reply-To: <4856B7A6.50508@et.gatech.edu>
[-- Attachment #1: Type: text/plain, Size: 819 bytes --]
D. Stuart Freeman wrote:
> I have a repository that I made with 'git-svn clone' that I'd like to
> make bare but retain the svn info. Would I just change the "bare" in
> .git/config to true? Is there anything I have to do to remove the
> working copy info?
>
> I plan to do this so that a co-worker and I can clone the git repo, and
> push our changes back to it, and maintain the "proxy" to svn from that
> central location.
>
I think I've found a flaw in my plan. Now that the repo is bare I can't
get any changes from upstream. I run 'git --bare svn fetch' and that
works, but then I have no way to rebase those changes into a local
branch because I don't have a working copy. Is there a way to see a
remote repo's remotes, and merge/rebase from there?
--
D. Stuart Freeman
Georgia Institute of Technology
[-- Attachment #2: stuart_freeman.vcf --]
[-- Type: text/x-vcard, Size: 162 bytes --]
begin:vcard
fn:D. Stuart Freeman
n:Freeman;Douglas
email;internet:stuart.freeman@et.gatech.edu
tel;work:(404)385-1473
x-mozilla-html:FALSE
version:2.1
end:vcard
^ permalink raw reply
* [RFC/PATCH v2] gitweb: respect $GITPERLLIB
From: Lea Wiemann @ 2008-06-20 19:35 UTC (permalink / raw)
To: git; +Cc: Lea Wiemann
In-Reply-To: <1213990547-7585-1-git-send-email-LeWiemann@gmail.com>
gitweb/gitweb.cgi now respects $GITPERLLIB, like the Perl-based Git
commands.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
---
Changed since v1: Added missing INSTLIBDIR initialization.
I just noticed that as of now Gitweb isn't using any Perl modules, so
this change is actually not necessary yet; hence I'm making it an RFC
patch. I'll probably squash this into a larger "gitweb: use new
Git::Repo API" patch (which I'll publish in a few days).
Comments on this change to the Makefile are still appreciated, of
course. :)
-- Lea
Makefile | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 85c0846..64eeac1 100644
--- a/Makefile
+++ b/Makefile
@@ -1083,7 +1083,15 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
gitweb/gitweb.cgi: gitweb/gitweb.perl
$(QUIET_GEN)$(RM) $@ $@+ && \
- sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C perl -s --no-print-directory instlibdir` && \
+ sed -e '1{' \
+ -e ' s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+ -e ' h' \
+ -e ' s=.*=use lib (split(/:/, $$ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
+ -e ' H' \
+ -e ' x' \
+ -e '}' \
+ -e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
-e 's|++GIT_VERSION++|$(GIT_VERSION)|g' \
-e 's|++GIT_BINDIR++|$(bindir)|g' \
-e 's|++GITWEB_CONFIG++|$(GITWEB_CONFIG)|g' \
--
1.5.6.79.g01e9.dirty
^ permalink raw reply related
* [RFC/PATCH v2] gitweb: respect $GITPERLLIB
From: Lea Wiemann @ 2008-06-20 19:35 UTC (permalink / raw)
To: git; +Cc: Lea Wiemann
In-Reply-To: <1213929117-32037-1-git-send-email-LeWiemann@gmail.com>
gitweb/gitweb.cgi now respects $GITPERLLIB, like the Perl-based Git
commands.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
---
Changed since v1: Added missing INSTLIBDIR initialization.
I just noticed that as of now Gitweb isn't using any Perl modules, so
this change is actually not necessary yet; hence I'm making it an RFC
patch. I'll probably squash this into a larger "gitweb: use new
Git::Repo API" patch (which I'll publish in a few days).
Comments on this change to the Makefile are still appreciated, of
course. :)
-- Lea
Makefile | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 85c0846..64eeac1 100644
--- a/Makefile
+++ b/Makefile
@@ -1083,7 +1083,15 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
gitweb/gitweb.cgi: gitweb/gitweb.perl
$(QUIET_GEN)$(RM) $@ $@+ && \
- sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C perl -s --no-print-directory instlibdir` && \
+ sed -e '1{' \
+ -e ' s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+ -e ' h' \
+ -e ' s=.*=use lib (split(/:/, $$ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
+ -e ' H' \
+ -e ' x' \
+ -e '}' \
+ -e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
-e 's|++GIT_VERSION++|$(GIT_VERSION)|g' \
-e 's|++GIT_BINDIR++|$(bindir)|g' \
-e 's|++GITWEB_CONFIG++|$(GITWEB_CONFIG)|g' \
--
1.5.6.79.g01e9.dirty
^ permalink raw reply related
* Re: [PATCH 1/2] t3404: extra checks and s/! git/test_must_fail git/
From: Stephan Beyer @ 2008-06-20 19:00 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Johannes Schindelin, Christian Couder
In-Reply-To: <X-0hXtX7hZGzbL_zS7e4VUMsiMfWiIfABUCFp28XZx0@cipher.nrlssc.navy.mil>
Hi,
> > @@ -380,7 +397,7 @@ test_expect_success 'interrupted squash works as expected' '
> > ! FAKE_LINES="1 squash 3 2" git rebase -i HEAD~3 &&
>
> These can be converted to use test_must_fail by using a sub-shell
> as Junio demonstrated:
>
> (
> FAKE_LINES="1 squash 3 2" &&
> export FAKE_LINES &&
> test_must_fail git rebase -i HEAD~3
> ) &&
Perhaps I'm not consequent, but I thought that it's not worth it ;-)
(There is also another reason: I use a dirty test-lib.sh _hack_ locally,
that allows me to exactly see where a failing test_expect_success patch
fails (that saves some time), but the hack does not work on tests with a
subshell invocation.)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH 1/2] t3404: extra checks and s/! git/test_must_fail git/
From: Brandon Casey @ 2008-06-20 18:48 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Johannes Schindelin, Christian Couder
In-Reply-To: <1213986614-19536-1-git-send-email-s-beyer@gmx.net>
Stephan Beyer wrote:
> @@ -380,7 +397,7 @@ test_expect_success 'interrupted squash works as expected' '
> ! FAKE_LINES="1 squash 3 2" git rebase -i HEAD~3 &&
These can be converted to use test_must_fail by using a sub-shell
as Junio demonstrated:
(
FAKE_LINES="1 squash 3 2" &&
export FAKE_LINES &&
test_must_fail git rebase -i HEAD~3
) &&
-brandon
^ permalink raw reply
* Re: [PATCH 2/3] rebase-i: slight internal improvements
From: Stephan Beyer @ 2008-06-20 18:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git, Christian Couder
In-Reply-To: <alpine.DEB.1.00.0806201344180.6439@racer>
On Fri, Jun 20, 2008 at 01:46:29PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote to Cc git@vger.kernel.org:
> Hi,
>
> On Fri, 20 Jun 2008, Stephan Beyer wrote:
>
> > Looks like *portable* shell programming is no fun :\
>
> That is right. That's one of the reasons why I prefer moving scripts to
> builtins: prototyping is good and well, but when you need to put it into
> production, where people have all kinds of weird setups
Right.
> (just think of dash in Ubuntu!)
Well, I'm using dash as /bin/sh in Debian.
What's so weird about it? IIRC it allows POSIX + some Berkeley extensions
and so it is far less weird as the least common demoninator of shell
portability ;-)
Hmm,
For shell portability it'd be cool to have something like a "badsh" (bad
shell) with the whole XCU Utilities as builtins without features and
warnings if features want to be used that are not supported by at least
95% of the systems. So that scripts could be checked using badsh and
then you know, that it is portable.
I guess nobody ever wrote something like that. ;-)
> Better to use something portable, such as C.
Right.
> So would you not agree that PATCH 2/3 is rather unnecessary?
We wanted to make some upfront patches to am/rebase-i, so that, when the
git-sequencer prototype swoops in, it's easier to see, what is
taken from am and what is taken from rebase-i.
But this seems to be not so easy, so I'm currently thinking that I skip
that and concentrate on the builtin.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* [PATCH 2/2] Make rebase--interactive use OPTIONS_SPEC
From: Stephan Beyer @ 2008-06-20 18:30 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Christian Couder, Stephan Beyer
In-Reply-To: <1213986614-19536-1-git-send-email-s-beyer@gmx.net>
Also add some checks that --continue/--abort/--skip
actions are used without --onto, -p, -t, etc.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Hi,
Dscho wrote:
> You probably need to introduce checks against "git rebase --continue
> --onto blabla", then.
Now the is_standalone function does that.
Regards,
Stephan
PS: I wondered that nobody moaned that the patch is for pu.
git-rebase--interactive.sh | 71 +++++++++++++++++++++++++++++--------------
1 files changed, 48 insertions(+), 23 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 3f926d8..1894c37 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -10,10 +10,27 @@
# The original idea comes from Eric W. Biederman, in
# http://article.gmane.org/gmane.comp.version-control.git/22407
-USAGE='(--continue | --abort | --skip | [--preserve-merges] [--first-parent]
- [--preserve-tags] [--verbose] [--onto <branch>] <upstream> [<branch>])'
+OPTIONS_KEEPDASHDASH=
+OPTIONS_SPEC="\
+git-rebase [-i] [options] [--] <upstream> [<branch>]
+git-rebase [-i] (--continue | --abort | --skip)
+--
+ Available options are:
+p,preserve-merges Try to recreate merges instead of ignoring them
+t,preserve-tags Update tags to the new commit object
+m,merge Always used (no-op)
+i,interactive Always used (no-op)
+onto= Rebase onto given branch instead of upstream
+v,verbose Display a diffstat of what changed upstream
+ When preserving merges:
+f,first-parent Show only commits following the first parent of each commit
+s,strategy= Use the given merge strategy
+ Actions:
+continue Continue rebasing process
+abort Abort rebasing process and restore original branch
+skip Skip current patch and continue rebasing process
+"
-OPTIONS_SPEC=
. git-sh-setup
require_work_tree
@@ -25,6 +42,8 @@ SQUASH_MSG="$DOTEST"/message-squash
PRESERVE_MERGES=
STRATEGY=
VERBOSE=
+ONTO=
+MARK_PREFIX='refs/rebase-marks'
test -f "$DOTEST"/strategy && STRATEGY="$(cat "$DOTEST"/strategy)"
test -f "$DOTEST"/verbose && VERBOSE=t
@@ -515,10 +534,19 @@ create_extended_todo_list () {
done
}
+is_standalone () {
+ test $# -eq 2 -a "$2" = '--' &&
+ test -z "$ONTO" &&
+ test -z "$PRESERVE_TAGS" &&
+ test -z "$PRESERVE_MERGES" &&
+ test -z "$FIRST_PARENT"
+}
+
while test $# != 0
do
case "$1" in
--continue)
+ is_standalone "$@" || usage
comment_for_reflog continue
test -d "$DOTEST" || die "No interactive rebase running"
@@ -551,6 +579,7 @@ do
do_rest
;;
--abort)
+ is_standalone "$@" || usage
comment_for_reflog abort
git rerere clear
@@ -568,6 +597,7 @@ do
exit
;;
--skip)
+ is_standalone "$@" || usage
comment_for_reflog skip
git rerere clear
@@ -575,7 +605,7 @@ do
output git reset --hard && do_rest
;;
- -s|--strategy)
+ -s)
case "$#,$1" in
*,*=*)
STRATEGY="-s "$(expr "z$1" : 'z-[^=]*=\(.*\)') ;;
@@ -586,32 +616,36 @@ do
shift ;;
esac
;;
- -m|--merge)
+ -m)
# we use merge anyway
;;
- -C*)
- die "Interactive rebase uses merge, so $1 does not make sense"
- ;;
- -v|--verbose)
+ -v)
VERBOSE=t
;;
- -p|--preserve-merges)
+ -p)
PRESERVE_MERGES=t
;;
- -f|--first-parent)
+ -f)
FIRST_PARENT=t
PRESERVE_MERGES=t
;;
- -t|--preserve-tags)
+ -t)
PRESERVE_TAGS=t
;;
- -i|--interactive)
+ -i)
# yeah, we know
;;
+ --onto)
+ shift
+ ONTO=$(git rev-parse --verify "$1") ||
+ die "Does not point to a valid commit: $1"
+ ;;
''|-h)
usage
;;
- *)
+ --)
+ shift
+ test $# -eq 1 -o $# -eq 2 || usage
test -d "$DOTEST" &&
die "Interactive rebase already started"
@@ -620,15 +654,6 @@ do
comment_for_reflog start
- ONTO=
- case "$1" in
- --onto)
- ONTO=$(git rev-parse --verify "$2") ||
- die "Does not point to a valid commit: $2"
- shift; shift
- ;;
- esac
-
require_clean_work_tree
UPSTREAM=$(git rev-parse --verify "$1") || die "Invalid base"
--
1.5.6.167.g86f2
^ permalink raw reply related
* [PATCH 1/2] t3404: extra checks and s/! git/test_must_fail git/
From: Stephan Beyer @ 2008-06-20 18:30 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Christian Couder, Stephan Beyer
In-Reply-To: <alpine.DEB.1.00.0806201407230.6439@racer>
This patch adds some extra checks (especially branch checks)
test cases and changes "! git ..." into "test_must_fail git".
Also a --onto test case is added.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Dscho,
as you've comman^Wwished ;-)
(except the analism)
Note that I've also added a --onto test.
t/t3404-rebase-interactive.sh | 31 ++++++++++++++++++++++++-------
1 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index e6f3fad..96985ff 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -107,6 +107,7 @@ chmod a+x fake-editor.sh
test_expect_success 'no changes are a nop' '
git rebase -i F &&
+ test "$(git symbolic-ref -q HEAD)" = "refs/heads/branch2" &&
test $(git rev-parse I) = $(git rev-parse HEAD)
'
@@ -115,14 +116,26 @@ test_expect_success 'test the [branch] option' '
git rm file6 &&
git commit -m "stop here" &&
git rebase -i F branch2 &&
+ test "$(git symbolic-ref -q HEAD)" = "refs/heads/branch2" &&
+ test $(git rev-parse I) = $(git rev-parse branch2) &&
test $(git rev-parse I) = $(git rev-parse HEAD)
'
+test_expect_success 'test --onto <branch>' '
+ git checkout -b test-onto branch2 &&
+ git rebase -i --onto branch1 F &&
+ test "$(git symbolic-ref -q HEAD)" = "refs/heads/test-onto" &&
+ test $(git rev-parse HEAD^) = $(git rev-parse branch1) &&
+ test $(git rev-parse I) = $(git rev-parse branch2)
+'
+
test_expect_success 'rebase on top of a non-conflicting commit' '
git checkout branch1 &&
git tag original-branch1 &&
git rebase -i branch2 &&
test file6 = $(git diff --name-only original-branch1) &&
+ test "$(git symbolic-ref -q HEAD)" = "refs/heads/branch1" &&
+ test $(git rev-parse I) = $(git rev-parse branch2) &&
test $(git rev-parse I) = $(git rev-parse HEAD~2)
'
@@ -155,9 +168,12 @@ EOF
test_expect_success 'stop on conflicting pick' '
git tag new-branch1 &&
- ! git rebase -i master &&
+ test_must_fail git rebase -i master &&
+ test "$(git rev-parse HEAD~3)" = "$(git rev-parse master)" &&
test_cmp expect .git/.dotest-merge/patch &&
test_cmp expect2 file1 &&
+ test "$(git-diff --name-status |
+ sed -n -e "/^U/s/^U[^a-z]*//p")" = file1 &&
test 4 = $(grep -v "^#" < .git/.dotest-merge/done | wc -l) &&
test 0 = $(grep -c "^[^#]" < .git/.dotest-merge/git-rebase-todo)
'
@@ -165,6 +181,7 @@ test_expect_success 'stop on conflicting pick' '
test_expect_success 'abort' '
git rebase --abort &&
test $(git rev-parse new-branch1) = $(git rev-parse HEAD) &&
+ test "$(git symbolic-ref -q HEAD)" = "refs/heads/branch1" &&
! test -d .git/.dotest-merge
'
@@ -331,7 +348,7 @@ test_expect_success 'interactive -t preserves tags' '
test_expect_success '--continue tries to commit' '
git checkout to-be-rebased &&
test_tick &&
- ! git rebase -i --onto new-branch1 HEAD^ &&
+ test_must_fail git rebase -i --onto new-branch1 HEAD^ &&
echo resolved > file1 &&
git add file1 &&
FAKE_COMMIT_MESSAGE="chouette!" git rebase --continue &&
@@ -342,7 +359,7 @@ test_expect_success '--continue tries to commit' '
test_expect_success 'verbose flag is heeded, even after --continue' '
git reset --hard HEAD@{1} &&
test_tick &&
- ! git rebase -v -i --onto new-branch1 HEAD^ &&
+ test_must_fail git rebase -v -i --onto new-branch1 HEAD^ &&
echo resolved > file1 &&
git add file1 &&
git rebase --continue > output &&
@@ -380,7 +397,7 @@ test_expect_success 'interrupted squash works as expected' '
! FAKE_LINES="1 squash 3 2" git rebase -i HEAD~3 &&
(echo one; echo two; echo four) > conflict &&
git add conflict &&
- ! git rebase --continue &&
+ test_must_fail git rebase --continue &&
echo resolved > conflict &&
git add conflict &&
git rebase --continue &&
@@ -398,10 +415,10 @@ test_expect_success 'interrupted squash works as expected (case 2)' '
! FAKE_LINES="3 squash 1 2" git rebase -i HEAD~3 &&
(echo one; echo four) > conflict &&
git add conflict &&
- ! git rebase --continue &&
+ test_must_fail git rebase --continue &&
(echo one; echo two; echo four) > conflict &&
git add conflict &&
- ! git rebase --continue &&
+ test_must_fail git rebase --continue &&
echo resolved > conflict &&
git add conflict &&
git rebase --continue &&
@@ -449,7 +466,7 @@ test_expect_success 'rebase a commit violating pre-commit' '
chmod a+x $PRE_COMMIT &&
echo "monde! " >> file1 &&
test_tick &&
- ! git commit -m doesnt-verify file1 &&
+ test_must_fail git commit -m doesnt-verify file1 &&
git commit -m doesnt-verify --no-verify file1 &&
test_tick &&
FAKE_LINES=2 git rebase -i HEAD~2
--
1.5.6.167.g86f2
^ 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