* [PATCH] Gitweb: Provide Git links in project list
From: Robert Richter @ 2008-08-04 10:06 UTC (permalink / raw)
To: J.H.; +Cc: Junio C Hamano, git, Robert Richter
In-Reply-To: <1217796793.32240.36.camel@localhost.localdomain>
Signed-off-by: Robert Richter <robert.richter@amd.com>
---
gitweb/gitweb.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 90cd99b..6d9b7aa 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3558,6 +3558,9 @@ sub fill_project_list_info {
if (!defined $pr->{'owner'}) {
$pr->{'owner'} = git_get_project_owner("$pr->{'path'}") || "";
}
+ if (!defined $pr->{'url_link'}) {
+ $pr->{'url_link'} = (git_get_project_url_list("$pr->{'path'}"))[0] || "";
+ }
if ($check_forks) {
my $pname = $pr->{'path'};
if (($pname =~ s/\.git$//) &&
@@ -3661,6 +3664,7 @@ sub git_project_list_body {
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"shortlog")}, "shortlog") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"log")}, "log") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"tree")}, "tree") .
+ ($pr->{'url_link'} ? " | " . $cgi->a({-href => $pr->{'url_link'}}, "git") : '') .
($pr->{'forks'} ? " | " . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '') .
"</td>\n" .
"</tr>\n";
--
1.5.5.4
^ permalink raw reply related
* Re: Gitweb: Provide Git links in project list?
From: Robert Richter @ 2008-08-04 10:12 UTC (permalink / raw)
To: J.H.; +Cc: git
In-Reply-To: <1217796793.32240.36.camel@localhost.localdomain>
On 03.08.08 13:53:13, J.H. wrote:
> Working on refactoring the patch so that it can go upstream, one of the
> things I'm definitely making an assumption about (in my original code)
> is that the base url will be uniform for the entire project_list (as it
> is on kernel.org). If that's acceptable I will probably be able to
> submit something today, if not I will need to muck about and read out
> the url from .git/cloneurl (which would be a rather hefty performance
> hit - needing to read that from each repository)
John,
I just sent out a patch that implements this using cloneurl. It seemed
small and easy to implement and so I just made the change myself.
Thank you anyway.
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@amd.com
^ permalink raw reply
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: Rogan Dawes @ 2008-08-04 10:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Junio C Hamano, git, H. Peter Anvin
In-Reply-To: <alpine.DEB.1.00.0808041208060.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 4 Aug 2008, Rogan Dawes wrote:
>
>> I don't understand why you would want to keep the commands in the URL
>> when you are doing a POST?
>
> Caching.
>
> Hth,
> Dscho
>
If you are expecting something to be cacheable, then should you not be
using a GET anyway?
Anyway, from RFC 2616:
> 13.10 Invalidation After Updates or Deletions
>
> ...
>
> Some HTTP methods MUST cause a cache to invalidate an entity. This is
> either the entity referred to by the Request-URI, or by the Location
> or Content-Location headers (if present). These methods are:
>
> - PUT
> - DELETE
> - POST
This doesn't seem negotiable to me.
Unless I am misunderstanding your "Caching" comment to mean "To enable
caching", as opposed to "To prevent caching"?
Rogan
^ permalink raw reply
* [PATCH] Add output flushing before fork()
From: Anders Melchiorsen @ 2008-08-04 10:18 UTC (permalink / raw)
To: gitster; +Cc: git, Anders Melchiorsen
In-Reply-To: <alpine.LFD.1.10.0808032241260.3668@nehalem.linux-foundation.org>
This adds fflush(NULL) before fork() in start_command(), to keep
the generic interface safe.
A remaining use of fork() with no flushing is in a comment in
show_tree(). Rewrite that comment to use start_command().
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
This fixes up the remaining two spots that Linus suggested.
builtin-ls-tree.c | 13 ++++++-------
run-command.c | 1 +
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index d25767a..cb61717 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -66,17 +66,16 @@ static int show_tree(const unsigned char *sha1, const char *base, int baselen,
/*
* Maybe we want to have some recursive version here?
*
- * Something like:
+ * Something similar to this incomplete example:
*
if (show_subprojects(base, baselen, pathname)) {
- if (fork()) {
- chdir(base);
- exec ls-tree;
- }
- waitpid();
+ struct child_process ls_tree;
+
+ ls_tree.dir = base;
+ ls_tree.argv = ls-tree;
+ start_command(&ls_tree);
}
*
- * ..or similar..
*/
type = commit_type;
} else if (S_ISDIR(mode)) {
diff --git a/run-command.c b/run-command.c
index 6af83c5..bbb9c77 100644
--- a/run-command.c
+++ b/run-command.c
@@ -68,6 +68,7 @@ int start_command(struct child_process *cmd)
trace_argv_printf(cmd->argv, "trace: run_command:");
#ifndef __MINGW32__
+ fflush(NULL);
cmd->pid = fork();
if (!cmd->pid) {
if (cmd->no_stdin)
--
1.5.6.4
^ permalink raw reply related
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: Johannes Schindelin @ 2008-08-04 10:26 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Shawn O. Pearce, Junio C Hamano, git, H. Peter Anvin
In-Reply-To: <4896D669.30402@dawes.za.net>
Hi,
On Mon, 4 Aug 2008, Rogan Dawes wrote:
> Johannes Schindelin wrote:
>
> > On Mon, 4 Aug 2008, Rogan Dawes wrote:
> >
> > > I don't understand why you would want to keep the commands in the
> > > URL when you are doing a POST?
> >
> > Caching.
>
> If you are expecting something to be cacheable, then should you not be
> using a GET anyway?
Yes.
And I think the wget thing is not an issue: we should not try to prevent
every single idiocy.
Ciao,
Dscho
^ permalink raw reply
* Re: git-gui translators - please update translations if necessary
From: Peter Krefting @ 2008-08-04 11:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20080802214930.GA25311@spearce.org>
Shawn O. Pearce:
> > Perhaps you wanted to update git-gui.pot first before sending this request
> > out?
> Oh. Its updated now, but msgmerge on my system is busted and won't
> update the po files themselves. *sigh*
In that case I would recommend submitting the translation to
translationsproject.org, which helps both you and us translators in
handling all the uninteresting tool-bashing itself. Submit an updated
POT file when strings are frozen, and download all the updated
translations before releasing.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Jan Nieuwenhuizen @ 2008-08-04 11:30 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080804090309.GD5435@hand.yhbt.net>
On ma, 2008-08-04 at 02:03 -0700, Eric Wong wrote:
> In the one-shot case, a git filter-branch script would probably be ideal
> and reusable for other projects.
That's a nice idea!
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
^ permalink raw reply
* [PATCH] Git.pm: localise $? in command_close_bidi_pipe()
From: Abhijit Menon-Sen @ 2008-08-04 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vhca12n2l.fsf@gitster.siamese.dyndns.org>
Git::DESTROY calls _close_cat_blob and _close_hash_and_insert_object,
which in turn call command_close_bidi_pipe, which calls waitpid, which
alters $?. If this happens during global destruction, it may alter the
program's exit status unexpectedly. Making $? local to the function
solves the problem.
(The problem was discovered due to a failure of test #8 in
t9106-git-svn-commit-diff-clobber.sh.)
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
At 2008-08-04 01:37:06 -0700, gitster@pobox.com wrote:
>
> After queueing it, I actually had to revert it, because it seems to
> break git-svn (t9106-git-svn-commit-diff-clobber.sh, test #8), and I
> am about to go to bed.
This patch in addition to my earlier one should solve the problem.
For test #8 to fail, the "git svn dcommit" must succeed, but in both
cases (i.e. without my patch applied, or with), the rebase fails:
rebase refs/remotes/git-svn: command returned error: 1
This results in a call to "fatal $@" on git-svn.perl:254, which calls
"exit 1", and test_must_fail is happy.
With my patch, however, Git::DESTROY calls the two _close functions
during global destruction, which in turn call command_close_bidi_pipe,
which calls waitpid with sensible arguments this time, which alters $?,
thus altering the exit status of the dcommit itself to 0. Oops.
All of "make test" passes for me after this change.
-- ams
perl/Git.pm | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 2ef437f..3b6707b 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -417,6 +417,7 @@ have more complicated structure.
=cut
sub command_close_bidi_pipe {
+ local $?;
my ($pid, $in, $out, $ctx) = @_;
foreach my $fh ($in, $out) {
unless (close $fh) {
--
1.6.0.rc0.43.g2aa74
^ permalink raw reply related
* [PATCH] Make "tg help cmd" print cmd help
From: Russell Steicke @ 2008-08-04 12:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
"tg help" looked like it needed help, and stuff it needed to know
about was already in README.
Use awk to extract help information from the README file. Store
the help files in $(PREFIX)/share/topgit. "tg help foo" will cat
$(PREFIX)/share/topgit/tg-foo.txt.
Signed-off-by: Russell Steicke <russellsteicke@gmail.com>
---
.gitignore | 6 ++++++
Makefile | 11 +++++++++--
create-help.sh | 17 +++++++++++++++++
tg.sh | 16 ++++++++++++++--
4 files changed, 46 insertions(+), 4 deletions(-)
diff --git a/.gitignore b/.gitignore
index 53ca141..6f0727f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,8 +1,14 @@
hooks/pre-commit
tg-create
+tg-create.txt
tg-delete
+tg-delete.txt
tg-info
+tg-info.txt
tg-patch
+tg-patch.txt
tg-summary
+tg-summary.txt
tg-update
+tg-update.txt
tg
diff --git a/Makefile b/Makefile
index 3913d66..238d07d 100644
--- a/Makefile
+++ b/Makefile
@@ -2,6 +2,7 @@
PREFIX = $(HOME)
bindir = $(PREFIX)/bin
cmddir = $(PREFIX)/libexec/topgit
+sharedir = $(PREFIX)/share/topgit
hooksdir = $(cmddir)/hooks
@@ -10,18 +11,22 @@ hooks_in = hooks/pre-commit.sh
commands_out = $(patsubst %.sh,%,$(commands_in))
hooks_out = $(patsubst %.sh,%,$(hooks_in))
+help_out = $(patsubst %.sh,%.txt,$(commands_in))
-all:: tg $(commands_out) $(hooks_out)
+all:: tg $(commands_out) $(hooks_out) $(help_out)
tg $(commands_out) $(hooks_out): % : %.sh
@echo "[SED] $@"
@sed -e 's#@cmddir@#$(cmddir)#g;' \
-e 's#@hooksdir@#$(hooksdir)#g' \
-e 's#@bindir@#$(bindir)#g' \
+ -e 's#@sharedir@#$(sharedir)#g' \
$@.sh >$@+ && \
chmod +x $@+ && \
mv $@+ $@
+$(help_out): README
+ ./create-help.sh `echo $@ | sed -e 's/tg-//' -e 's/\.txt//'`
install:: all
install tg "$(bindir)"
@@ -29,6 +34,8 @@ install:: all
install $(commands_out) "$(cmddir)"
install -d -m 755 "$(hooksdir)"
install $(hooks_out) "$(hooksdir)"
+ install -d -m 755 "$(sharedir)"
+ install $(help_out) "$(sharedir)"
clean::
- rm -f tg $(commands_out) $(hooks_out)
+ rm -f tg $(commands_out) $(hooks_out) $(help_out)
diff --git a/create-help.sh b/create-help.sh
new file mode 100755
index 0000000..0c40ee2
--- /dev/null
+++ b/create-help.sh
@@ -0,0 +1,17 @@
+#!/bin/sh
+
+# Create the tg-foo.txt files which contain help for the tg-foo command.
+
+if [ $# -ne 1 ] ; then
+ echo "Usage: $0 tgcommand" 1>&2
+ exit 1
+fi
+
+< README awk '
+ BEGIN { incommand = 0; }
+ /^tg '"$1"'$/ { incommand = 1; next; }
+ /^tg/ { incommand = 0; next; }
+ /^~/ { next; } # Ignore the title underlines.
+ { if (incommand) { print $0; } }
+' > tg-"$1".txt
+
diff --git a/tg.sh b/tg.sh
index e7c42cd..03a392b 100644
--- a/tg.sh
+++ b/tg.sh
@@ -148,6 +148,19 @@ switch_to_base()
git symbolic-ref HEAD "$_base"
}
+# Show the help messages.
+do_help()
+{
+ if [ -z "$1" ] ; then
+ echo "TopGit v0.1 - A different patch queue manager"
+ echo "Usage: tg (create|delete|info|patch|summary|update|help) ..."
+ elif [ -f "@sharedir@/tg-$1.txt" ] ; then
+ cat "@sharedir@/tg-$1.txt"
+ else
+ echo "`basename $0`: no help for $1" 1>&2
+ fi
+}
+
## Initial setup
@@ -171,8 +184,7 @@ shift
case "$cmd" in
help)
- echo "TopGit v0.1 - A different patch queue manager"
- echo "Usage: tg (create|delete|info|patch|summary|update|help) ..."
+ do_help "$1"
exit 1;;
create|delete|info|patch|summary|update)
. "@cmddir@"/tg-$cmd;;
--
tg: (24367cc..) t/help (depends on: master)
--
Russell Steicke
-- Fortune says:
There's certainly precedent for that already too. (Not claiming it's
*good* precedent, mind you. :-)
-- Larry Wall in <199709021744.KAA12428@wall.org>
^ permalink raw reply related
* Re: [StGit] stg import documentation incorrect.
From: Karl Hasselström @ 2008-08-04 12:48 UTC (permalink / raw)
To: Jurko Gospodneti?; +Cc: git, catalin.marinas
In-Reply-To: <48907221.5030608@docte.hr>
On 2008-07-30 15:52:33 +0200, Jurko Gospodneti? wrote:
> StGIT 'stg import' documentation at
> http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT_Tutorial states that
> this command is equivalent to:
>
> > "stg new" followed by "patch -i <file>", then "stg refresh -e"
>
> However, 'stg refresh' does not accept the -e option (which most
> likely has something to do with calling an external editor to edit
> the a log message).
That's right: stg refresh lost the -e option in the 0.14 release.
It'll be added back for the 0.15 release.
Until then, do stg refresh && stg edit.
> Hope this helps.
Yes, the tutorial is in sore need of a fresh coat of paint.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-08-04 12:29 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Schindelin, git
In-Reply-To: <20080803183749.GA3482@efreet.light.src>
On 8/4/08, Jan Hudec <bulb@ucw.cz> wrote:
> Hello,
>
> sorry for replying to an old thread, but I am a bit puzzled here,
>
>
> On Wed, Jul 23, 2008 at 17:55:14 +0100, Johannes Schindelin wrote:
> > On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> > > On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:
> > > >
> > > > > So in short, sparse prefix will be stored in config,
> > > > > core.sparsecheckout.
> > > >
> > > > Do you really think the prefix should be stored anywhere else than the
> > > > index?
> > > >
> > > > With core.sparseCheckout you have to introduce a _sh*tload_ of config
> > > > loaders.
> > > >
> > > > And with core.sparseCheckout you are at the whim of the user, since
> > > > .git/config is _supposed_ to be user-editable.
> > > >
> > > > From a logical point of view, I'd say that the sparse prefix has
> > > > nothing to do with the "configuration" of the local repository.
> > >
> > > Well, whatever place. I chose .git/config because I did not want to
> > > introduce a new config place. But then how about .git/sparsecheckout?
> >
> > No, I did mean the index. This is an attribute of the index: either it is
> > sparsely checked out or not. You can even have multiple indices
> > (switching between them by setting GIT_INDEX_FILE) which have different
> > prefixes.
>
>
> Um, but does the prefix we want to use depend on what files are physically
> present in the tree? That would however imply that it's /not/ an attribute of
> the index, but the tree and therefore should be stored in a separate object.
>
> The question whether it goes in the .git/config or .git/sparsecheckout is
> than that of semantics -- if it's in .git/config, than user changes that by
> editing the file or git config and no other way, while if it's in
> .git/sparsecheckout, user changes it by running checkout with appropriate
> arguments.
Please see the post Junio talked about narrow/sparse checkout [1].
With that approach (that is finer grain checkout than my approach), it
becomes clear that "prefix" is an attribute of index.
[1] http://article.gmane.org/gmane.comp.version-control.git/90016/match=narrow+checkout
> By the way, why is it *prefix*? Wouldn't a *path limit* be better?
Well, yes "path limiter" seems a better term. But it's irrelevant now
because this approach won't fly. I'm going to wait to see if anyone
takes the task as part of hackontest. Otherwise I will redo my series,
using assume unchanged bit.
> --
> Jan 'Bulb' Hudec <bulb@ucw.cz>
>
--
Duy
^ permalink raw reply
* Re: [ANNOUNCE] TopGit - A different patch queue manager
From: Karl Hasselström @ 2008-08-04 13:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: Petr Baudis, git
In-Reply-To: <9e4733910808030745j275eaffdib8a412fa95911bb3@mail.gmail.com>
On 2008-08-03 10:45:06 -0400, Jon Smirl wrote:
> It is very helpful to block git commands that will mess up the state
> of topgit. For example 'git rebase' is a good way to mess up stgit.
> Instead you need to do 'stg rebase'. It is quite easy to type the
> wrong command when switching between trees and some are under stgit
> and others aren't.
Indeed. This is mitigated somewhat by the new "stg undo" command, but
it's still perhaps StGit's largest UI wart.
> I believe there is a stgit rewrite due any day now that completely
> changes how it deals with the index.
The master branch contains an infrastructure rewrite that makes it
easy to make the various commands handle the index nicely. A lot of
commands have been fixed to take advantage of it, but a bunch still
remain.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Fwd: [PATCH] git-p4: chdir now properly sets PWD environment variable in msysGit
From: Robert Blum @ 2008-08-04 13:04 UTC (permalink / raw)
To: git
In-Reply-To: <bad7471c0808040601y10cceb44idcde5a4a8f415769@mail.gmail.com>
Forgot reply-all - forwarding to list....
> Missing full stop at the end of sentence aside, this comment makes me
> wonder if there is an optional way to have it set it, as opposed to the
> inconvenient way it behaves "by defualt".
Not that I'm aware of. My 'by default' comment refers to a default
Python installation, i.e. unpatched. As far as I know, the real
culprit in this is p4. I'd argue it's a bug, since they should be
using getcwd(), not getpwd(). Moot point - I don't want to wait for
git-p4 until I have convinced perforce to fix this and a new p4 rolls
around ;)
> If there is none, I think your
> patch, even though it looks ugly, is the least evil approach.
Warms the cockles of my heart ;)
> Another way
> might be to wrap callsites of system() by introducing a "run_p4" function,
> like:
>
> def run_p4(arg):
> os.environ['PWD'] = os.getcwd() if os.name == 'nt'
> return system(arg)
Happy to submit a new patch with that, if that's preferred.
> Thanks. I've been waiting for an Ack from somewhere or success reports
> from p4 users on Windows.
Han-Wen seems OK with it. (BTW: Who *is* the maintainer of git-p4?)
But hold off on applying - I'll resubmit with the run_p4 approach
today.
(Oh, and of course: Works for me ;)
- Robert
^ permalink raw reply
* Re: Merging submodules
From: H.Merijn Brand @ 2008-08-04 13:24 UTC (permalink / raw)
To: Santi Béjar; +Cc: Petr Baudis, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <8aa486160808010434g7f3c187arc107b994e737cd74@mail.gmail.com>
On Fri, 1 Aug 2008 13:34:42 +0200, "Santi Béjar" <sbejar@gmail.com>
wrote:
> On Fri, Aug 1, 2008 at 12:35, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
>
> >
> > After we join/merge these into the super-project, we're going to remove
> > the sup-repos, so all new commits will be made in the super-repo.
>
> If you'll remove the subrepos, the best thing would be to rewrite the
> history on those subrepos just moving all the path to the
> corresponding subfolder (with git-filter-branch, and you have exactly
> what you need at the end of the example section in the manpage). And
> then just do a normal merge. Or, even, you could try to create a
> project with everything there in the correct order and location, I
> don't know if git-filter-branch or git-fast-import/export (you have
> some examples in git.git in contrib/fast-import) can do it, but if you
> get it, please, post it here because it can be useful for others).
I gave up, even thought I'm not satisfied with the result: Merging with
subtrees works, but completely ruins my view over the history, cause
gitk shows the branches as a whole, and not `merged' by date. I did
change the merging process to merge the repo with the least recent
change date first, so that it would show up at the bottom and the
newest on top. This is workable, but far from perfect.
The fast-export/fast import with renaming started out fine, but
fast-import does not merge. For the latter I (tried to) use the
following approach:
--8<---
#!/pro/bin/perl
use strict;
use warnings;
sub usage
{
my $err = shift and select STDERR;
print "usage: $0 dir|repo.tar\n";
@_ and print join "\n", @_, "";
exit $err;
} # usage
-d "new" and die "Dir new already exists\n";
use Cwd;
use File::Find;
use Getopt::Long qw(:config bundling nopermute);
my $opt_v = 1;
GetOptions (
"help|?" => sub { usage (0); },
"v:2" => \$opt_v,
) or usage (1);
@ARGV == 1 or usage (1);
my $tmp_archive = "/tmp/git-join-$$.tgz";
END { unlink $tmp_archive };
my $archive = shift;
if (-d $archive) {
my $cwd = getcwd;
my @dir;
chdir $archive or die "$archive: $!\n";
find (sub {
$_ eq ".git" && -d $_ and push @dir, $File::Find::name;
}, ".");
qx{ tar czf $tmp_archive @dir };
$archive = $tmp_archive;
chdir $cwd;
}
sub pr_time
{
my @d = @_;
sprintf "%4d-%02d-%02d %02d:%02d:%02d", 1900 + $d[5], ++$d[4], @d[3,2,1,0];
} # pr_time
-f $archive && -s _ or usage (1, "Archive is not a file");
my @cmd =
$archive =~ m/\.tar$/ ? qw( tar xf ) :
$archive =~ m/\.t(ar\.)?gz$/ ? qw( tar xzf ) :
$archive =~ m/\.t(ar\.)?bz2?$/ ? qw( tar xhf ) :
usage (1, "$archive is not a recognized archive type");
print STDERR "Creating merge environment\n";
mkdir "new", 0777;
chdir "new" or die "Canot use folder new\n";
print STDERR "Recovering original repo's\n";
system @cmd, $archive;
my %modules;
find (sub {
(my $f = $File::Find::name) =~ s{^\./}{};
$f =~ s{/\.git$}{};
$_ eq ".git" && -d $_ && !$modules{$f} or return;
print "Found $f\n";
system "git-log '--pretty=format:%ct' | head -1";
chomp ($modules{$f} = `git-log '--pretty=format:%ct' | head -1`);
}, ".");
my @modules = sort { $modules{$a} <=> $modules{$b} } keys %modules;
sub git
{
system "git", @_;
} # git
my $top = getcwd;
print STDERR "Initializing new repo\n";
git "init";
foreach my $mod (@modules) {
print STDERR "Merging ", pr_time (localtime $modules{$mod}), " $mod ...\n";
chdir $mod;
git "checkout", "-f";
git "filter-branch", "--index-filter",
qq{git ls-files -s | sed "s-\t-&$mod/-" | }.
q{GIT_INDEX_FILE=$GIT_INDEX_FILE.new }.
q{git update-index --index-info && }.
q{mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE}, "HEAD";
git "fast-export", "--all", ">/tmp/git-export-$$.bin";
chdir $top;
git "fast-import", "</tmp/git-export-$$.bin";
}
print STDERR "Done\n";
-->8---
Which looks perfect after the first import, but fails on every next
Using --force for fast-import removes every previous import, so it is
useless for this process.
I do have to work with the repo, and that is more important than having
a perfect repo.
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: Merging submodules
From: Petr Baudis @ 2008-08-04 13:40 UTC (permalink / raw)
To: H.Merijn Brand
Cc: Santi Béjar, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080804152443.4418b3e0@pc09.procura.nl>
On Mon, Aug 04, 2008 at 03:24:43PM +0200, H.Merijn Brand wrote:
> I do have to work with the repo, and that is more important than having
> a perfect repo.
You might consider adopting a (relatively?) common strategy when
importing historical projects: Actually start the history from scratch
(git init && git add . && git commit -m"Initial commit") and fine-tune
your historical import in a separate repository. Then, provide a script
that people interested in the old history can run and it will graft the
imported history to your pure-git history.
Conceptually, it should be pretty simple:
git fetch git://perl-company.nl/sccs-import.git
echo initial_git_commit_sha1 last_imported_commit_sha1 \
>>$(git rev-parse --git-dir)/info/grafts
Example of a fine-tuned script:
http://repo.or.cz/w/elinks.git?a=blob;f=contrib/grafthistory.sh
If you find out that the import is not perfect later on, you can just
redo it, refetch and rewrite the info/grafts line.
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* [StGit PATCH] Add some tests of refreshing removed files
From: Karl Hasselström @ 2008-08-04 13:41 UTC (permalink / raw)
To: Jon Smirl; +Cc: git, Catalin Marinas
In-Reply-To: <9e4733910807311902nd3a02bep68c8a26a7e6303cd@mail.gmail.com>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
These four tests all pass on Catalin's current master. Do they fail
for you, or did I miss something in your problem description?
t/t2702-refresh-rm.sh | 101 +++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 101 insertions(+), 0 deletions(-)
create mode 100755 t/t2702-refresh-rm.sh
diff --git a/t/t2702-refresh-rm.sh b/t/t2702-refresh-rm.sh
new file mode 100755
index 0000000..896ebf3
--- /dev/null
+++ b/t/t2702-refresh-rm.sh
@@ -0,0 +1,101 @@
+#!/bin/sh
+
+test_description='"stg refresh" with removed files'
+
+. ./test-lib.sh
+
+# Ignore our own temp files.
+cat >> .git/info/exclude <<EOF
+expected*.txt
+files*.txt
+status*.txt
+EOF
+
+reset () {
+ stg pop -a > /dev/null
+ git reset --hard > /dev/null
+}
+
+test_expect_success 'Initialize StGit stack' '
+ stg init &&
+ echo x > x.txt &&
+ echo y > y.txt &&
+ git add x.txt y.txt &&
+ git commit -m "Add some files"
+'
+
+cat > expected0.txt <<EOF
+D y.txt
+EOF
+printf '' > expected1.txt
+test_expect_success 'git-rm a file' '
+ stg new -m p0 &&
+ git rm y.txt &&
+ stg status > status0.txt &&
+ test_cmp expected0.txt status0.txt &&
+ stg refresh &&
+ stg status > status1.txt &&
+ test_cmp expected1.txt status1.txt &&
+ stg files | sort > files.txt &&
+ test_cmp expected0.txt files.txt
+'
+
+reset
+
+cat > expected0.txt <<EOF
+D y.txt
+M x.txt
+EOF
+printf '' > expected1.txt
+test_expect_success 'git-rm a file together with other changes' '
+ stg new -m p1 &&
+ echo x2 >> x.txt &&
+ git rm y.txt &&
+ stg status > status0.txt &&
+ test_cmp expected0.txt status0.txt &&
+ stg refresh &&
+ stg status > status1.txt &&
+ test_cmp expected1.txt status1.txt &&
+ stg files | sort > files.txt &&
+ test_cmp expected0.txt files.txt
+'
+
+reset
+
+cat > expected0.txt <<EOF
+D y.txt
+EOF
+printf '' > expected1.txt
+test_expect_success 'rm a file' '
+ stg new -m p2 &&
+ rm y.txt &&
+ stg status > status0.txt &&
+ test_cmp expected0.txt status0.txt &&
+ stg refresh &&
+ stg status > status1.txt &&
+ test_cmp expected1.txt status1.txt &&
+ stg files | sort > files.txt &&
+ test_cmp expected0.txt files.txt
+'
+
+reset
+
+cat > expected0.txt <<EOF
+D y.txt
+M x.txt
+EOF
+printf '' > expected1.txt
+test_expect_success 'rm a file together with other changes' '
+ stg new -m p3 &&
+ echo x2 >> x.txt &&
+ rm y.txt &&
+ stg status > status0.txt &&
+ test_cmp expected0.txt status0.txt &&
+ stg refresh &&
+ stg status > status1.txt &&
+ test_cmp expected1.txt status1.txt &&
+ stg files | sort > files.txt &&
+ test_cmp expected0.txt files.txt
+'
+
+test_done
^ permalink raw reply related
* Re: [StGIT PATCH] Do not mess-up with commit message formatting when sending email
From: Karl Hasselström @ 2008-08-04 14:16 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: git, Catalin Marinas
In-Reply-To: <20080731125005.894.10592.stgit@dawn.rfc1149.net>
On 2008-07-31 14:50:05 +0200, Samuel Tardieu wrote:
> The short description, which will be used as the email subject, gets
> its leading and trailing whitespaces removed.
OK, good.
> The long description only gets its trailing whitespaces removed to
> preserve commit message formatting, e.g. in the case of a
> ChangeLog-style commit message, as well as empty leading lines.
I'd like a better description of this change, please. If I'm not
mistaken, we used to do _only_ left stripping of the body. You change
that to left stripping of only newlines, but also add right stripping
for each line. I'm all for these changes, but the commit message
confused me a lot.
> - long_descr = '\n'.join(descr_lines[1:]).lstrip()
> + long_descr = '\n'.join([l.rstrip() for l in descr_lines[1:]]).lstrip('\n')
We require Python 2.4 or later, so you can skip the square brackets
here.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Merging submodules
From: H.Merijn Brand @ 2008-08-04 13:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: Santi Béjar, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080804134053.GK10151@machine.or.cz>
On Mon, 4 Aug 2008 15:40:53 +0200, Petr Baudis <pasky@suse.cz> wrote:
> On Mon, Aug 04, 2008 at 03:24:43PM +0200, H.Merijn Brand wrote:
> > I do have to work with the repo, and that is more important than having
> > a perfect repo.
>
> You might consider adopting a (relatively?) common strategy when
> importing historical projects: Actually start the history from scratch
> (git init && git add . && git commit -m"Initial commit") and fine-tune
> your historical import in a separate repository. Then, provide a script
> that people interested in the old history can run and it will graft the
> imported history to your pure-git history.
We already changed the approach for converting projects from SCCS to
create a recursive repo from all SCCS repo's. And that *is* perfect.
Problem with the current join/merge is that there already have been
commits to the git repo after the SCCS convert that I do not want to
loose.
> Conceptually, it should be pretty simple:
>
> git fetch git://perl-company.nl/sccs-import.git
> echo initial_git_commit_sha1 last_imported_commit_sha1 \
> >>$(git rev-parse --git-dir)/info/grafts
>
> Example of a fine-tuned script:
>
> http://repo.or.cz/w/elinks.git?a=blob;f=contrib/grafthistory.sh
>
> If you find out that the import is not perfect later on, you can just
> redo it, refetch and rewrite the info/grafts line.
I'll have a look at this anyway.
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [StGIT PATCH] Do not insert an empty line before the diffstat info
From: Karl Hasselström @ 2008-08-04 14:20 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: git, Catalin Marinas
In-Reply-To: <20080731125010.894.84022.stgit@dawn.rfc1149.net>
On 2008-07-31 14:50:10 +0200, Samuel Tardieu wrote:
> To make the format of stg output closer to the plain git one, do not
> insert an empty line between the "---" separator and the diffstat
> information.
Thanks, will apply. (IMO it's slightly uglier, but it's better to be
consistent. And it does save some space.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Merging submodules
From: Petr Baudis @ 2008-08-04 14:06 UTC (permalink / raw)
To: H.Merijn Brand
Cc: Santi Béjar, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080804155733.46fd3982@pc09.procura.nl>
On Mon, Aug 04, 2008 at 03:57:33PM +0200, H.Merijn Brand wrote:
> We already changed the approach for converting projects from SCCS to
> create a recursive repo from all SCCS repo's. And that *is* perfect.
Yes, but that's orthogonal to whether to separate the imported history
from the pure history? (Not that I'd want to force it upon you. If you
have a lot of nested repositories, the grafting can get a bit obnoxious
if you don't automate it well, I suppose.)
> Problem with the current join/merge is that there already have been
> commits to the git repo after the SCCS convert that I do not want to
> loose.
You could rebase these to the new initial commit. But if you already use
Git intensively and rewriting history would create big headache for you
at this point already, it's too late, I guess.
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [StGit PATCH] Add some tests of refreshing removed files
From: Jon Smirl @ 2008-08-04 14:07 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Catalin Marinas
In-Reply-To: <20080804134050.19457.96613.stgit@yoghurt>
On 8/4/08, Karl Hasselström <kha@treskal.com> wrote:
> Signed-off-by: Karl Hasselström <kha@treskal.com>
>
> ---
>
> These four tests all pass on Catalin's current master. Do they fail
> for you, or did I miss something in your problem description?
I just updated to current git and stg and retested. Tracking a remove
is working now for me. Tools were about three months old before
updating.
Not sure what changed. But I definitely couldn't get stgit to do it
and had to use git commands to generate the patch. I would remove the
file, refresh and the patch was empty.
stg status would show the file in D state. As soon as I touched
something else and refreshed the rm would appear in the patch.
Maybe there is more to the triggering sequence than a simple rm. I'll
keep a watch out and see if I can figure out how I got into the state.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [StGit PATCH] Add some tests of refreshing removed files
From: Jon Smirl @ 2008-08-04 14:08 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Catalin Marinas
In-Reply-To: <9e4733910808040707u2ef8992eha629ebca9c41730b@mail.gmail.com>
On 8/4/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 8/4/08, Karl Hasselström <kha@treskal.com> wrote:
> > Signed-off-by: Karl Hasselström <kha@treskal.com>
> >
> > ---
> >
> > These four tests all pass on Catalin's current master. Do they fail
> > for you, or did I miss something in your problem description?
>
>
> I just updated to current git and stg and retested. Tracking a remove
> is working now for me. Tools were about three months old before
> updating.
>
> Not sure what changed. But I definitely couldn't get stgit to do it
> and had to use git commands to generate the patch. I would remove the
> file, refresh and the patch was empty.
> stg status would show the file in D state. As soon as I touched
> something else and refreshed the rm would appear in the patch.
The file I was trying to rm was a hidden file, .mailmap
>
> Maybe there is more to the triggering sequence than a simple rm. I'll
> keep a watch out and see if I can figure out how I got into the state.
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [StGit RFC] Pull request for build/install work
From: Karl Hasselström @ 2008-08-04 14:38 UTC (permalink / raw)
To: Daniel White; +Cc: Catalin Marinas, git
In-Reply-To: <20080731162916.14ffc9fd@whitehouse.id.au>
On 2008-07-31 16:29:16 +1000, Daniel White wrote:
> Changes are on my experimental branch
> at git://repo.or.cz/stgit/dwhite.git.
Thanks. Have merged, and will push out sometime soon.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFH] - git-svn auth bug (possibly SVN 1.5.0-related)
From: Dmitry Potapov @ 2008-08-04 14:18 UTC (permalink / raw)
To: Eric Wong; +Cc: Brad King, git
In-Reply-To: <20080803220251.GB3006@untitled>
On Sun, Aug 03, 2008 at 03:02:51PM -0700, Eric Wong wrote:
>
> It could be another incompatibility introduced in SVN 1.5.0.
>
> I'll try to dist-upgrade a machine to Lenny sometime in the next two
> weeks so I can test; I'm pretty busy these days but if anybody else
> wants to figure this out in the meantime, please do :)
The problem happens only if you use FS format 3 regardless what version
of SVN perl binding you use. Also, there is no problem with using SVN
1.5 (I tried 1.5.1) as long as you use FS format 2 (I tested git-svn
with libsvn-perl 1.4.2 and 1.5.1 works fine) but if your repository is
initialized to use FS format 3 (which is the default in SVN 1.5) then
this problem happens with all versions of SVN perl binding, and it
happens exactly in the same place:
/home/dpotapov/git/git-svn:3333: my @ce = $opts->{ra}->get_commit_editor($opts->{log},
sub get_commit_editor {
/home/dpotapov/git/git-svn:3909: my ($self, $log, $cb, $pool) = @_;
/home/dpotapov/git/git-svn:3910: my @lock = $SVN::Core::VERSION ge '1.2.0' ? (undef, 0) : ();
/home/dpotapov/git/git-svn:3911: $self->SUPER::get_commit_editor($log, $cb, @lock, $pool);
sub AUTOLOAD {
/usr/lib/perl5/SVN/Ra.pm:74: my $class = ref($_[0]);
/usr/lib/perl5/SVN/Ra.pm:75: my $method = $AUTOLOAD;
/usr/lib/perl5/SVN/Ra.pm:76: $method =~ s/.*:://;
/usr/lib/perl5/SVN/Ra.pm:77: return unless $method =~ m/[^A-Z]/;
/usr/lib/perl5/SVN/Ra.pm:79: my $self = shift;
/usr/lib/perl5/SVN/Ra.pm:82: my $func = $self->{session}->can ($method)
/usr/lib/perl5/SVN/Ra.pm:85: my @ret = $func->($self->{session}, @_);
Numbers of lines may be different for different versions of libsvn-perl,
but the effect is exactly the same. Instead of going to the next line
and completing AUTOLOAD, if you use FS format 3 then you end up in
croak_on_error(), which uses some uninitialized value in string
concatenation (which produces an additional warning) and then calls
croak(). End of the story :(
Dmitry
^ permalink raw reply
* StGit and charsets
From: Jon Smirl @ 2008-08-04 14:21 UTC (permalink / raw)
To: Git Mailing List, Karl Hasselström
Do you have tests in place to handle the names and comments in patches
being in different charsets? When I was working with the mailmap file
a large source of errors was from mangling names in alternate
charsets. I recall errors in Finnish, Japanese and Chinese names for
sure. I don't know which tools did the charset mangling.
I don't work much with international charsets. If someone is using
something like Russian or Finish locally, is the metadata in the patch
converted to UTF8 before exporting or sending it as mail? Comments
should be in English, but people's names may need UTF8. And what about
email addresses, does DNS allow Unicode names now?
--
Jon Smirl
jonsmirl@gmail.com
^ 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