* Re: [WIP/PATCH v3] gitweb: add test suite with Test::WWW::Mechanize::CGI
From: Lea Wiemann @ 2008-06-20 13:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200806201408.05254.jnareb@gmail.com>
Jakub Narebski wrote:
> First, it is not XML validation[*1*], but check if XML is well-formed.
> Second, I think it would be better if adding XML checks (RSS, Atom,
> OPML) would be left as separate commit.
Sure; FWIW I'm generally in favor of having a large initial commit for
new independent files (and since we don't need to worry about conflicts
I'm not fervent about getting this into the next branch ASAP), but we
can definitely add XML checking separately.
>> +# set up test repository
>
> I have created this part as a copy of older t9500 gitweb test, thinking
> about what we might want to test, but the WIP of Mechanize based t9503
> doesn't have yet tests for those specific features.
I was thinking about that. Right now the tests are so generic that you
can replace the test repository with anything else as long as it has
some commits (and later some tags, etc.). That's kinda nice.
>> +# We don't count properly when skipping, so no_plan is necessary.
>> +use Test::More qw(no_plan);
>
> Actually it is not that we cannot could properly when skipping, because
> there are two ways to have skipped tests and test count upfront,
We're skipping tests if a page-load fails to prevent a slew of failure,
using constructs like if(test_page '?...') { ... inspect the page ...}.
It's my impression that we shouldn't end up with a wrong test count even
if one test fails; but then we'd have to replace those ifs with
cumbersome skip blocks.
I'm generally not in favor of maintaining any test count plans; they're
an unnecessary failure source, and I don't think they buy us much, if
anything -- correct me if I'm missing something Perl-specific here.
> Why do you use shortened SHA1 identifier, instead of full SHA1?
> Links in gitweb use full SHA1.
That's for readability in the test output; links get checked anyway,
don't they? If you think we should be testing against full SHA1s,
that's fine too.
> Errr, HEAD would be $revisions[0], $revisions[-1] would be $root.
Fixed, thanks.
> Another solution would be to copy relevant parts of cgi_application
> (without all the checks for example), and use $mech->cgi( sub { ... } );
> here (without the cgi_application bug).
ISTR that using cgi(sub ...) gives us problems with untrappable exits in
gitweb.cgi (and possibly more things), right? I'm fine with the
workarounds we have in place, they don't seem brittle.
>> +our $baseurl = "http://localhost";
>> +our($params, $url, $pagedesc, $status);
>
> I think we can use 'my' here;
They're used in subroutines, so I believe 'our' is correct here.
> Style: I would write "our (", with space [...]
>> +# if (test_page '?p=.git;a=summary', 'repository summary') {
>
> Style: I would use function call form, i.e. "test_page(...)", not
> command-like (or script-like) form.
Both fixed, thanks.
> As to the rest of the test: I think as preliminary test it is a good
> thing to have. We can think about what tests to add later (unless you
> rather have exhaustive test suite now...).
I'll be writing tests as I go and change parts of gitweb. I won't be
able to write exhaustive tests, but I at least want to make sure that
the code I'm changing is covered somehow.
-- Lea
^ permalink raw reply
* Re: git svn --add-author-from implies --use-log-author
From: Mircea Bardac @ 2008-06-20 13:31 UTC (permalink / raw)
To: git; +Cc: Fredrik Skolmli
In-Reply-To: <20080620113147.GC27940@frsk.net>
Hi,
Fredrik Skolmli wrote:
> when running git svn dcommit --add-author-from on a git-svn repository,
> --use-log-author is not implied by itself. This causes the rewritten history
> to not show the author in the way most users would expect it to be, "Name
> <email@domain.tld>", but instead "<user@uuid>".
>
> Instead of forcing people to write "svn dcommit --add-author-from
> --use-log-author", is it a bad move to imply the last argument, making the
> history look more user-friendly to start with?
The documentation mentions that these 2 parameters are for init and,
like other parameters, I had the feeling they will affect either the
"init" process or the entire existance of the repository. Now that I
look better, I see that there is no "config" note next to them.
From my point of view, they should be repository config options,
affecting all commits. I can't see a reason for having only sometimes
--add-author-from. If you want to commit information about the authors
in regards to a SVN repository, you'll always want that option to be on.
If you want to have authors properly identified when getting something
out of the SVN repository, you'll always want to have --use-log-author on.
I would also like some option to stop pushing a commit if it doesn't
have any From/Signed-off-by line in it.
Mircea
P.S. I am very curious why using From and not Signed-off-by. I had the
feeling that Signed-off-by is being used to also mark the path of a
patch. Also, is there a centralized list of all the ways a patch can be
"marked"
--
http://mircea.bardac.net
^ permalink raw reply
* Re: [PATCH 09/11] Introduce filter_independent() in commit.c
From: Miklos Vajna @ 2008-06-20 13:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LSU.1.00.0806201350000.32725@wbgn129.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 484 bytes --]
On Fri, Jun 20, 2008 at 01:53:06PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> A test case would be desirable, but probably pretty complicated. Hmm. I
> like tests when they are simple, because they are easy to verify by a
> human. Miklos, any chance for such a test case?
Not that complicated:
http://repo.or.cz/w/git/vmiklos.git?a=commit;h=c19b568714c7141e9f96ebea3990f7dae615223b
At the moment it passes on master and fails on mv/merge-in-c.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Add SVN->Git conversion example to documentation, and cleanup the doc
From: Heikki Orsila @ 2008-06-20 13:23 UTC (permalink / raw)
To: git; +Cc: Miklos Vajna, Karl Hasselstrom, Junio C Hamano
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
---
This is the fourth round of the patch. Changes to earlier attempts:
* Explain git<>svn process better (Junio C Hamano)
* Don't mention git-svnimport unnecessarily. And where mentioned,
mark it as deprecated. (Karl Hasselström, Junio C Hamano)
* Remove unnecessary words from description
* Rename foo.git -> foo (Miklos Vajna)
* Remove refs/remotes/git-svn (Miklos Vajna)
* Don't set unnecessary fetch sources
* Use proper syntax for marking command line options in the text.
Use "`--no-metadata`" instead of "--no-metadata". (Junio C Hamano)
* Improve explanation of "`--no-metadata`"
* This patch explains how to do one step transition to Git repository.
Further updates from the SVN repo are not possible. A later patch may
explain the process of incremental updates, but it doesn't really
address the issue of moving from SVN to Git as Git should be
self-sufficient. (Miklos Vajna)
Documentation/git-svn.txt | 56 +++++++++++++++++++++++++++++++++++++--------
1 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 97bed54..551f1df 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -11,15 +11,15 @@ SYNOPSIS
DESCRIPTION
-----------
-git-svn is a simple conduit for changesets between Subversion and git.
-It is not to be confused with linkgit:git-svnimport[1], which is
-read-only.
+git-svn is a simple bidirectional conduit for changesets between
+Subversion and git. It is used to develop SVN hosted projects with Git tools.
+Changes are committed to a Git repository as would be normally done with
+Git, but the tool converts these commits later to SVN commits.
+It can also be used to convert a Subversion repository to a Git repository.
-git-svn was originally designed for an individual developer who wants a
-bidirectional flow of changesets between a single branch in Subversion
-and an arbitrary number of branches in git. Since its inception,
-git-svn has gained the ability to track multiple branches in a manner
-similar to git-svnimport.
+git-svn was designed for developers who want
+bidirectional flow of changesets between multiple branches in Subversion
+and an arbitrary number of branches in git.
git-svn is especially useful when it comes to tracking repositories
not organized in the way Subversion developers recommend (trunk,
@@ -219,7 +219,7 @@ Any other arguments are passed directly to `git log'
'commit-diff'::
Commits the diff of two tree-ish arguments from the
command-line. This command is intended for interoperability with
- git-svnimport and does not rely on being inside an git-svn
+ git-svnimport (deprecated) and does not rely on being inside an git-svn
init-ed repository. This command takes three arguments, (a) the
original tree to diff against, (b) the new tree result, (c) the
URL of the target Subversion repository. The final argument
@@ -317,7 +317,7 @@ config key: svn.findcopiesharder
-A<filename>::
--authors-file=<filename>::
-Syntax is compatible with the files used by git-svnimport and
+Syntax is compatible with the files used by git-svnimport (deprecated) and
git-cvsimport:
------------------------------------------------------------------------
@@ -521,6 +521,42 @@ have each person clone that repository with 'git clone':
git-svn rebase
------------------------------------------------------------------------
+CONVERTING A SUBVERSION REPOSITORY TO A GIT REPOSITORY
+------------------------------------------------------
+
+When converting a Subversion repository to a Git repository
+"`--no-metadata`" prevents git-svn from adding "git-svn-id:" comments to
+the log. "`-A`" option is used to convert SVN pseudonyms to real names
+and email addresses. The whole repository, or a part of it can be
+converted. Two examples below show how to convert the whole repo
+with all branches, or only the SVN trunk. Note, this way it is
+impossible to update Git repository incrementally from the SVN repository.
+This is a one-step, one-way conversion.
+
+------------------------------------------------------------------------
+# Convert all branches of an SVN repository to a Git repository:
+
+ git svn clone --no-metadata -A authors.txt SVN_URL foo
+
+# Convert only the trunk of an SVN repository to a Git repository:
+
+ git svn clone --no-metadata -A authors.txt SVN_URL/trunk foo
+------------------------------------------------------------------------
+Next, the new repository should be verified to match what was
+expected. Go through the repository and logs to do that.
+Also, there may have been typos in the author file. It is crucial to
+get authors correctly in the conversion step, because it is very
+awkward and inconvenient to do it later (with rewrite).
+The last step is to remove the svn data from the repository,
+and repack the repository.
+------------------------------------------------------------------------
+ cd foo/.git
+ rm -rf svn
+ rm -f refs/remotes/git-svn
+ git config --remove-section svn-remote.svn
+ git gc
+------------------------------------------------------------------------
+
REBASE VS. PULL/MERGE
---------------------
--
1.5.5.1.1.ga5e5c
^ permalink raw reply related
* Re: [PATCH 3/3] Make rebase--interactive use OPTIONS_SPEC
From: Johannes Schindelin @ 2008-06-20 13:15 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Christian Couder
In-Reply-To: <1213929935-15093-4-git-send-email-s-beyer@gmx.net>
Hi,
I like the patch. Just a couple comments:
On Fri, 20 Jun 2008, Stephan Beyer wrote:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index e8ac2ae..aeb9628 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -10,10 +10,25 @@
> # 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 (--continue | --abort | --skip)
Here, "-i" is not an error, but not required either, so it should be
+git-rebase [-i] (--continue | --abort | --skip)
> +--
> +continue Continue rebasing process
> +abort Abort rebasing process and restore original branch
> +skip Skip current patch and continue rebasing process
I wonder if these options (which really should be subcommands) should not
go below the options, for chronological reasons: you are likely to need
the other options before --continue and friends.
> +p,preserve-merges Try to recreate merges instead of ignoring
s/$/ them/
> +t,preserve-tags Update tags to the new commit object
> +m,merge Used anyways (no-op)
> +i,interactive Used anyways (no-op)
s/anyways/always/
Hmm?
> +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
> +'
>
> -OPTIONS_SPEC=
> . git-sh-setup
> require_work_tree
>
> @@ -595,32 +611,36 @@ do
>
> [...]
>
> + --onto)
> + shift
> + ONTO=$(git rev-parse --verify "$1") ||
> + die "Does not point to a valid commit: $1"
> + ;;
You probably need to introduce checks against "git rebase --continue
--onto blabla", then.
> ''|-h)
> usage
> ;;
> - *)
> + --)
> + shift
> + test $# -eq 1 -o $# -eq 2 || usage
I consider this a bugfix. Thanks.
> @@ -720,6 +731,7 @@ EOF
> die_abort "Nothing to do"
>
> output git checkout $ONTO && do_rest
> + exit 0
> ;;
> esac
> shift
This exit is not really necessary, is it? Besides, a simple "exit" would
be more correct: it reuses the exit status of the most recently executed
command, which is what we want here.
Thanks,
Dscho
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Jakub Narebski @ 2008-06-20 13:13 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: git
In-Reply-To: <237967ef0806200602v6b95939fm2663be849799e2de@mail.gmail.com>
Mikael Magnusson wrote:
> 2008/6/20 Jakub Narebski <jnareb@gmail.com>:
>
>> There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is
>> documented anywhere, though), so you could have used
>>
>> git diff 7def2be1^!
>>
>>> [ time passes as i read the manpage - the final thing i do when
>>> every other measure fails ;-) ]
>
> With some grepping, i found this in git-rev-parse,
>
> Two other shorthands for naming a set that is formed by a commit and its parent
> commits exists. r1^@ notation means all parents of r1. r1^! includes commit r1
> but excludes its all parents.
A bit strange is that neither "git rev-parse pu^!" nor "git rev-parse pu^@"
work, while the same works with git-rev-list. WTF?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/3] t3404: slight improvements
From: Johannes Schindelin @ 2008-06-20 13:05 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Christian Couder
In-Reply-To: <1213929935-15093-2-git-send-email-s-beyer@gmx.net>
Hi,
On Fri, 20 Jun 2008, Stephan Beyer wrote:
> This patch adds some extra checks into some
> test cases and changes "! git ..." into
> "test_must_fail git".
I think your oneline should read "t3404: be more anal".
> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
> index e6f3fad..daba5fd 100755
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -107,7 +107,8 @@ chmod a+x fake-editor.sh
>
> test_expect_success 'no changes are a nop' '
> git rebase -i F &&
> - test $(git rev-parse I) = $(git rev-parse HEAD)
> + test $(git rev-parse I) = $(git rev-parse HEAD) &&
> + test "$(git symbolic-ref -q HEAD)" = "refs/heads/branch2"
> '
You could have saved some diff-screen-estate by putting the extra check
_before_ the original one.
Other than that, I think this patch is fine.
Ciao,
Dscho
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Mikael Magnusson @ 2008-06-20 13:04 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080620082034.GA24913@elte.hu>
2008/6/20 Ingo Molnar <mingo@elte.hu>:
>
> A couple of stupid Git questions (using git-1.5.4.3-2.fc8).
>
> Sometimes i want to see the reverse diff of a particular commit.
>
> If i want to see the normal diff i do:
>
> git-log -1 -p 7def2be1
git show 7def2b1 is a bit easier to type.
--
Mikael Magnusson
^ permalink raw reply
* Re: Are C++ contributions welcome?
From: Johannes Schindelin @ 2008-06-20 13:03 UTC (permalink / raw)
To: jose maria gomez vergara; +Cc: git
In-Reply-To: <4c88165dd0077363a30b4f98fed16c2f@localhost>
Hi,
On Fri, 20 Jun 2008, jose maria gomez vergara wrote:
> I know that C++ code was not welcome sometime ago, but I don't know if
> this have changed.
You probably mean
http://article.gmane.org/gmane.comp.version-control.git/58929
but I cannot help but wonder why anything should have changed since then.
> I don't feel comfortable programing in C and I prefer C++ only because I
> have more experience using this one. May I contribute to this project in
> that language?.
Of course, you can try to contribute something in C++, but that will
probably only trigger someone rewriting your stuff in (portable) C and
take all your credit.
Heck, I might do it myself ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Mikael Magnusson @ 2008-06-20 13:02 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3d4mcmq20.fsf@localhost.localdomain>
2008/6/20 Jakub Narebski <jnareb@gmail.com>:
> There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is
> documented anywhere, though), so you could have used
>
> git diff 7def2be1^!
>
>> [ time passes as i read the manpage - the final thing i do when
>> every other measure fails ;-) ]
With some grepping, i found this in git-rev-parse,
Two other shorthands for naming a set that is formed by a
commit and its parent
commits exists. r1^@ notation means all parents of r1. r1^!
includes commit r1
but excludes its all parents.
--
Mikael Magnusson
^ permalink raw reply
* [PATCH v2] bash: Add more option completions for 'git log'
From: Teemu Likonen @ 2008-06-20 13:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Dan McGee, git, gitster
In-Reply-To: <20080620063104.GA3307@mithlond.arda.local>
Options added: --walk-reflogs --stat --numstat --shortstat
--decorate --diff-filter= --color-words
Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
---
Here's a non-conflicting version.
contrib/completion/git-completion.bash | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 72575cf..f108ede 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -762,6 +762,9 @@ _git_log ()
--not --all
--left-right --cherry-pick
--graph
+ --stat --numstat --shortstat
+ --decorate --diff-filter=
+ --color-words --walk-reflogs
"
return
;;
--
1.5.6.2.g3c3a
^ permalink raw reply related
* Re: Importing non-version controlled bits and pieces to Git
From: Johannes Schindelin @ 2008-06-20 13:00 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Miklos Vajna, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0806201339330.4004@ds9.cixit.se>
Hi,
On Fri, 20 Jun 2008, Peter Karlsson wrote:
> One complicating factor is that I am working with DOS/Windows source
> code, so all text files have CRLF line-endings, which means converting
> before feeding to fast-import, or manually doing "git add" with
> core.autocrlf == true. fast-import can't be set up to do CRLF
> auto-conversion, can it?
Why not import everything with a CR/LF, and then use filter-branch with a
really simple tree-filter? It is slow, alright, but it is safe, too.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] git-merge-recursive-{ours,theirs}
From: Johannes Schindelin @ 2008-06-20 12:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: geoffrey.russell, sverre, Johannes Sixt, Miklos Vajna, git
In-Reply-To: <7vbq1wo8ck.fsf_-_@gitster.siamese.dyndns.org>
Hi,
On Fri, 20 Jun 2008, Junio C Hamano wrote:
> diff --git a/builtin-merge-recursive.c b/builtin-merge-recursive.c
> index 4aa28a1..a355e7a 100644
> --- a/builtin-merge-recursive.c
> +++ b/builtin-merge-recursive.c
> @@ -650,9 +655,26 @@ static int merge_3way(mmbuffer_t *result_buf,
> fill_mm(a->sha1, &src1);
> fill_mm(b->sha1, &src2);
>
> + if (index_only)
> + favor = 0;
> + else {
> + switch (merge_recursive_variants) {
> + case MERGE_RECURSIVE_OURS:
> + favor = XDL_MERGE_FAVOR_OURS;
> + break;
> + case MERGE_RECURSIVE_THEIRS:
> + favor = XDL_MERGE_FAVOR_THEIRS;
> + break;
> + default:
> + favor = 0;
> + break;
> + }
Hrm. I would have preferred something like this:
if (!index_only && merge_recursive_variants == MERGE_RECURSIVE_OURS)
favor = XDL_MERGE_FAVOR_OURS;
if (!index_only && merge_recursive_variants == MERGE_RECURSIVE_THEIRS)
favor = XDL_MERGE_FAVOR_THEIRS;
else
favor = 0;
> + }
> + flag = LL_MERGE_FLAGS(index_only, favor);
> +
> merge_status = ll_merge(result_buf, a->path, &orig,
> &src1, name1, &src2, name2,
> - index_only);
> + flag);
Sorry, but in my opinion this flag mangling makes the whole code uglier.
Why not just add another parameter?
Or if you are really concerned about future enhancements to ll_merge(),
use a struct.
> @@ -1379,11 +1401,18 @@ int cmd_merge_recursive(int argc, const char **argv, const char *prefix)
> struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
> int index_fd;
>
> + merge_recursive_variants = 0;
> if (argv[0]) {
> int namelen = strlen(argv[0]);
> if (8 < namelen &&
> !strcmp(argv[0] + namelen - 8, "-subtree"))
> - subtree_merge = 1;
> + merge_recursive_variants = MERGE_RECURSIVE_SUBTREE;
> + else if (5 < namelen &&
> + !strcmp(argv[0] + namelen - 5, "-ours"))
> + merge_recursive_variants = MERGE_RECURSIVE_OURS;
> + else if (7 < namelen &&
> + !strcmp(argv[0] + namelen - 7, "-theirs"))
> + merge_recursive_variants = MERGE_RECURSIVE_THEIRS;
This just cries out loud for a new function suffixcmp().
I will not say anything about the long lines in git-merge.sh, since I
fully expect builtin-merge to happen Real Soon Now.
Anyhow, your comments about this driving the wrong workflow still apply.
Maybe we want to display them really, really prominently in
Documentation/merge-strategies.txt.
Ciao,
Dscho
^ permalink raw reply
* Re: Importing non-version controlled bits and pieces to Git
From: Johannes Sixt @ 2008-06-20 12:57 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Johannes Schindelin, Miklos Vajna, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0806201339330.4004@ds9.cixit.se>
Peter Karlsson schrieb:
> One complicating factor is that I am working with DOS/Windows source
> code, so all text files have CRLF line-endings, which means converting
> before feeding to fast-import, or manually doing "git add" with
> core.autocrlf == true. fast-import can't be set up to do CRLF
> auto-conversion, can it?
No, but you can put `tr -d '\015'` in the pipeline in front of
fast-import. (Unless, of course, you also have to feed binary data.)
-- Hannes
^ permalink raw reply
* Are C++ contributions welcome?
From: jose maria gomez vergara @ 2008-06-20 12:23 UTC (permalink / raw)
To: git
I think Git is a really good project and I would like to contribute to it.
I have been having a look to the source and I have realized on that all
code is C(well and perl for some scripts and so..). I know that C++ code
was not welcome sometime ago, but I don't know if this have changed.
I don't feel comfortable programing in C and I prefer C++ only because I
have more experience using this one. May I contribute to this project in
that language?.
Thanks a lot.
^ permalink raw reply
* Re: [PATCH 2/3] rebase-i: slight internal improvements
From: Johannes Schindelin @ 2008-06-20 12:46 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Johannes Sixt, git, Christian Couder
In-Reply-To: <20080620080153.GC7369@leksak.fem-net>
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 (just think of
dash in Ubuntu!), it is no fun.
Better to use something portable, such as C.
Which is the whole point of your project, right? You want to turn the
real engine into a builtin.
So would you not agree that PATCH 2/3 is rather unnecessary?
Ciao,
Dscho
^ permalink raw reply
* Re: Importing non-version controlled bits and pieces to Git
From: Peter Karlsson @ 2008-06-20 12:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0806201323390.6439@racer>
Johannes Schindelin:
> On Fri, 20 Jun 2008, Miklos Vajna wrote:
> > Maybe contrib/fast-import/import-tars.perl?
As I noted, I have used that before, and it works best with linear
histories, even if I managed to hack it to create a branch for a
project that had a simple branching structure (an update was created
for version n.x after version n+1.x was released).
> You should be able to use git-fast-import from a simple script
> yourself; if you would like to see an example how to feed
> fast-import, just export a few commits with "git fast-export
> HEAD~5..".
Yeah, that is what I am currently planning on doing. I was just trying
to be lazy and see if someone already had solved the problem for me :-)
One complicating factor is that I am working with DOS/Windows source
code, so all text files have CRLF line-endings, which means converting
before feeding to fast-import, or manually doing "git add" with
core.autocrlf == true. fast-import can't be set up to do CRLF
auto-conversion, can it?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH 09/11] Introduce filter_independent() in commit.c
From: Johannes Schindelin @ 2008-06-20 12:37 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20080620120643.GX29404@genesis.frugalware.org>
Hi,
On Fri, 20 Jun 2008, Miklos Vajna wrote:
> On Fri, Jun 20, 2008 at 01:53:06PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > 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.
> >
> > That is a valid point, methinks. Probably the octopus_merge_base and
> > the cleanup have to be decoupled here. The cleanup should be nothing
> > more than calling clear_commit_marks() for every head.
>
> Actually get_octopus_merge_bases() _needs_ to clean up the flags as it
> calls get_merge_bases() multiple times and get_merge_bases() expects
> empty flags.
Oh darn, you are right.
> > A test case would be desirable, but probably pretty complicated.
> > Hmm. I like tests when they are simple, because they are easy to
> > verify by a human. Miklos, any chance for such a test case?
>
> Sure, I'll write one.
Thanks,
Dscho
^ permalink raw reply
* Re: Importing non-version controlled bits and pieces to Git
From: Johannes Schindelin @ 2008-06-20 12:25 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Peter Karlsson, Git Mailing List
In-Reply-To: <20080620115102.GW29404@genesis.frugalware.org>
Hi,
On Fri, 20 Jun 2008, Miklos Vajna wrote:
> On Fri, Jun 20, 2008 at 10:42:22AM +0100, Peter Karlsson <peter@softwolves.pp.se> wrote:
> > I am looking at moving a project that has not been version-controlled
> > in the regular sense into Git. I have found it to currently consist of
> > 40 directories with copies of the set of files in various shapes.
> >
> > I have reconstructed something that looks like a probable revision
> > tree for these 40 directories, and I want to put this into Git so that
> > I can examine what changes have been made where, and merge the various
> > versions back together so that there can be one version with all the
> > various fixes.
>
> Maybe contrib/fast-import/import-tars.perl?
BTW this is a relatively simple script showing how to import commits into
a Git repository using git-fast-import.
You should be able to use git-fast-import from a simple script yourself;
if you would like to see an example how to feed fast-import, just export a
few commits with "git fast-export HEAD~5..".
Hth,
Dscho
^ permalink raw reply
* Re: [WIP/PATCH v3] gitweb: add test suite with Test::WWW::Mechanize::CGI
From: Jakub Narebski @ 2008-06-20 12:08 UTC (permalink / raw)
To: Lea Wiemann; +Cc: git
In-Reply-To: <1213931911-15860-1-git-send-email-LeWiemann@gmail.com>
On Fri, 20 Jun 2008, Lea Wiemann wrote:
> From: Jakub Narebski <jnareb@gmail.com>
If you have rewritten the patch I won't mind if you change authorship
to you (remove this From: line); signoff is IMHO enough.
> ---
> I haven't gotten around to merging Jakub's recent XML validation patch
> yet, but I think it'd be good to have some review now; I'll merge it
> tomorrow and send another patch.
First, it is not XML validation[*1*], but check if XML is well-formed.
Second, I think it would be better if adding XML checks (RSS, Atom,
OPML) would be left as separate commit.
[*1*] There is W3C feed validation service, http://validator.w3.org/feed/
which provides also standalone Python script for feed validation, and
also SOAP interface with WebService::Validator::Feed::W3C wrapper (but
it would require having Internet connection), or we can try validate
against XML Schema Definition (there exists one for RSS, and there is
one for Atom derived from Relax-NG schema).
> diff --git a/t/t9503-gitweb-Mechanize.sh b/t/t9503-gitweb-Mechanize.sh
[...]
> +# set up test repository
> +test_expect_success 'set up test repository' '
[cut]
I have created this part as a copy of older t9500 gitweb test, thinking
about what we might want to test, but the WIP of Mechanize based t9503
doesn't have yet tests for those specific features.
> diff --git a/t/t9503/test.pl b/t/t9503/test.pl
[...]
> +# We don't count properly when skipping, so no_plan is necessary.
> +use Test::More qw(no_plan);
Actually it is not that we cannot could properly when skipping, because
there are two ways to have skipped tests and test count upfront, both
implemented in my initial version (v1) of t/t9503/test.pl.
You can set number of tests upfront depending if some feature is
available, e.g. "plan tests => <n> - $use_lint*<m2> - $check_xml*<m2>"
or just "if ($use_lint) { plan tests => <m> } else ...".
Or you can explicitly skip tests using SKIP: BLOCK (see Test::More(3pm)).
What we have here is that we don't know number of tests upfront,
because it is complicated, and that's what I'd like to see in the
comment instead (but I don't have idea for exact wording).
> +my @revisions = map { substr $_, 0, 10 } split /\s/, `git-rev-list --first-parent HEAD`;
Why do you use shortened SHA1 identifier, instead of full SHA1? Links
in gitweb use full SHA1.
> +my $head = $revisions[-1];
Errr, HEAD would be $revisions[0], $revisions[-1] would be $root.
> +my $gitweb = File::Spec->catfile('..','..','gitweb','gitweb.cgi');
> +# the followin two lines of code are workaround for 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);
Another solution would be to copy relevant parts of cgi_application
(without all the checks for example), and use $mech->cgi( sub { ... } );
here (without the cgi_application bug).
> +our $baseurl = "http://localhost";
> +our($params, $url, $pagedesc, $status);
I think we can use 'my' here; gitweb uses 'our' only to be able to run
it correctly as "legacy CGI" mod_perl script.
> +our($params, $url, $pagedesc, $status);
Style: I would write "our (", with space between keyword and opening
parenthesis.
> +# test_page ( <params>, <page_description>, <expected_status> )
> +# Example:
> +# if (test_page '?p=.git;a=summary', 'repository summary') {
> +# $mech->...;
> +# $mech->...;
> +# }
Style: I would use function call form, i.e. "test_page(...)", not
command-like (or script-like) form.
As to the rest of the test: I think as preliminary test it is a good
thing to have. We can think about what tests to add later (unless you
rather have exhaustive test suite now...).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 09/11] Introduce filter_independent() in commit.c
From: Miklos Vajna @ 2008-06-20 12:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LSU.1.00.0806201350000.32725@wbgn129.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 879 bytes --]
On Fri, Jun 20, 2008 at 01:53:06PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > 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.
>
> That is a valid point, methinks. Probably the octopus_merge_base and the
> cleanup have to be decoupled here. The cleanup should be nothing more
> than calling clear_commit_marks() for every head.
Actually get_octopus_merge_bases() _needs_ to clean up the flags as it
calls get_merge_bases() multiple times and get_merge_bases() expects
empty flags.
> A test case would be desirable, but probably pretty complicated. Hmm. I
> like tests when they are simple, because they are easy to verify by a
> human. Miklos, any chance for such a test case?
Sure, I'll write one.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git svn --use-log-author misbehavior?
From: Mircea Bardac @ 2008-06-20 12:04 UTC (permalink / raw)
To: Git Mailing List; +Cc: Fredrik Skolmli
In-Reply-To: <20080620105729.GB27940@frsk.net>
Fredrik Skolmli wrote:
> On Fri, Jun 20, 2008 at 11:13:17AM +0100, Mircea Bardac wrote:
>> My Git commits (not dcommits) already have "Signed-off-by:" at the end,
>> added with "git commit -s". When I do a "git svn dcommit" they get
>> pushed to SVN and the entire commit is rewritten. I have
>> --add-author-from added on git clone, but nothing else is being added to
>> the commit except the git-svn-id - from my point of view, according to
>> the documentation, this is the correct behavior (since there already is
>> a Signed-off-by line)
>
> Did you mean "git svn clone" here, not "git clone"?
Yes, I meant "git svn clone".
> And if --use-log-author
> is to be used to get retrieve info from the commits, it should be used
> instead of --add-author-from when doing a clone. (Which as far as I can see
> behaves correctly.)
That is right. I am using them like this, but according to Stephen's
reply the --use-log-author option is not being saved. I assumed they
were saved as an option of the git svn clone so that they would affect
all future dcommits.
--
Mircea
http://mircea.bardac.net
^ permalink raw reply
* Re: [PATCH 09/11] Introduce filter_independent() in commit.c
From: Johannes Schindelin @ 2008-06-20 11:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vabhgq02p.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 19 Jun 2008, Junio C Hamano wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > 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>
> > ---
> > commit.c | 16 ++++++++++++++++
> > commit.h | 1 +
> > 2 files changed, 17 insertions(+), 0 deletions(-)
> >
> > diff --git a/commit.c b/commit.c
> > index 6052ca3..0dbf4b7 100644
> > --- a/commit.c
> > +++ b/commit.c
> > @@ -705,3 +705,19 @@ 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 *i, *bases, *ret = NULL;
> > + struct commit_list **pptr = &ret;
> > +
> > + commit_list_insert(lookup_commit(head), &heads);
> > +
> > + bases = get_octopus_merge_bases(heads);
> > +
> > + 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?
>
> Because RESULT is an implementation detail of merge_bases(), I do not
> think we would want to expose it outside of it.
Well, filter_independent() lives in commit.c, too, so it is in the same
scope as merge_branches().
> 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.
That is a valid point, methinks. Probably the octopus_merge_base and the
cleanup have to be decoupled here. The cleanup should be nothing more
than calling clear_commit_marks() for every head.
A test case would be desirable, but probably pretty complicated. Hmm. I
like tests when they are simple, because they are easy to verify by a
human. Miklos, any chance for such a test case?
Ciao,
Dscho
^ permalink raw reply
* Re: Importing non-version controlled bits and pieces to Git
From: Miklos Vajna @ 2008-06-20 11:51 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0806201036440.24013@ds9.cixit.se>
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
On Fri, Jun 20, 2008 at 10:42:22AM +0100, Peter Karlsson <peter@softwolves.pp.se> wrote:
> I am looking at moving a project that has not been version-controlled
> in the regular sense into Git. I have found it to currently consist of
> 40 directories with copies of the set of files in various shapes.
>
> I have reconstructed something that looks like a probable revision tree
> for these 40 directories, and I want to put this into Git so that I can
> examine what changes have been made where, and merge the various
> versions back together so that there can be one version with all the
> various fixes.
Maybe contrib/fast-import/import-tars.perl?
It imports tar.{gz,bz2,Z} files, but you can tar up your trees or it can
just serve as an example and you can write your own script that does the
same with directories.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git svn: how to recover from checksum mismatch?
From: Alexander Gladysh @ 2008-06-20 11:36 UTC (permalink / raw)
To: git
In-Reply-To: <c6c947f60806200356s285ac4s7a4affc108c7f311@mail.gmail.com>
> I have reverted back to git 1.5.5.1, but I still get that checksum
> error. I'm fetching a fresh git svn init+fetch from svn, but it takes
> a few hours, and I have to do it twice (for each of my two repos). Any
> advice on how can I recover less painlessly?
That is more painlessly of course, not less, sorry :)
^ 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