* Re: [PATCH 2/2] status: only touch path we may need to check
From: Sverre Rabbelier @ 2010-01-14 16:02 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1263481341-28401-3-git-send-email-pclouds@gmail.com>
Heya,
2010/1/14 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
> $ time git st eclass/
> real 0m3.211s
> $ time ~/w/git/git st eclass/
> real 0m1.587s
Wow, nice reduction!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 01/18] rebase -i: Make the condition for an "if" more transparent
From: Eric Blake @ 2010-01-14 15:42 UTC (permalink / raw)
To: git
In-Reply-To: <aa37ee8a68d460df172b23b4999fbe4ce7d77c1e.1263447037.git.mhagger@alum.mit.edu>
Michael Haggerty <mhagger <at> alum.mit.edu> writes:
> current_sha1=$(git rev-parse --verify HEAD)
> - if test "$no_ff$current_sha1" = "$parent_sha1"; then
> + if test -z "$no_ff" -a "$current_sha1" = "$parent_sha1"
'test cond1 -a cond2' is not portable. Use 'test cond1 && test cond2'.
--
Eric Blake
^ permalink raw reply
* Re: [PATCH] git push --track
From: Andreas Krey @ 2010-01-14 15:27 UTC (permalink / raw)
To: Matthieu Moy
Cc: Johannes Schindelin, Martin Langhoff, Miles Bader, Rudolf Polzer,
git
In-Reply-To: <vpqiqb4lq4q.fsf@bauges.imag.fr>
On Thu, 14 Jan 2010 15:25:57 +0000, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Of course it'd only work if you have full ssh access, unless the git
> >> server learns a new command to mkdir (in sane and approved locations).
> >
> > You mean a new "init" command a la "git --git-dir=bla.git init", which
> > _does_ mkdir the directory.
>
> I think he meant
>
> git --git-dir=git+ssh://foo.bar/var/git/mynewthing.git init
>
> which doesn't.
But 'ssh foo.bar git --git-dir=/var/git/mynewthing.git init' likely would.
Probably missing a --bare somewhere; and I think that repo creation
potentially needs too many things (like custom hook or access rights
setup) to be done via git push. Especially since you really only need
to create an empty repo, and only if you didn't clone from the push
target in the first place.
Andreas
^ permalink raw reply
* Re: [PATCH 0/2] Improve Git performance on big trees
From: Martin Langhoff @ 2010-01-14 15:21 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1263481341-28401-1-git-send-email-pclouds@gmail.com>
2010/1/14 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
> Almost 1 sec for "git rm foo" still seems too long though,
> probably due to writing a 9MB index.
One of the main issues there is that the Gentoo dir tree seems to be
very flat. The kernel tree is huge, but much deeper, and does not have
a huge top-level directory -- and git handles it fairly well.
Perhaps the Gentoo tree can be rearranged to be more nested? If your
devs strongly prefer a flat view of it, that could be arranged with
symlinks.
Alternatively, each port can be in its own repo, and you can make a
"top level repo" using git submodules -- this is what Fedora/RH is
exploring at the moment.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* [PATCH 0/2] Improve Git performance on big trees
From: Nguyễn Thái Ngọc Duy @ 2010-01-14 15:02 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
The discussion about using Git on Gentoo comes up again [1] and it
looks like we can improve Git a bit if user only works on some
subdirectories. In such cases, Git still does whole-tree check, which
takes quite some time. "git status" takes 3 seconds on my machine, but
I suspect lstat() is not the only culprit, "git diff --exit-code" is
about 1 sec.
These patches makes "git rm <path>" and "git status <path>" a bit
faster. Almost 1 sec for "git rm foo" still seems too long though,
probably due to writing a 9MB index.
[1] http://article.gmane.org/gmane.linux.gentoo.devel/64522
Nguyễn Thái Ngọc Duy (2):
rm: only refresh entries that we may touch
status: only touch path we may need to check
builtin-commit.c | 2 +-
builtin-rm.c | 2 +-
wt-status.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 2/2] status: only touch path we may need to check
From: Nguyễn Thái Ngọc Duy @ 2010-01-14 15:02 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1263481341-28401-1-git-send-email-pclouds@gmail.com>
This patch gets rid of whole-tree cache refresh and untracked file
search. Instead only specified path will be looked at.
Again some numbers on gentoo-x86, ~80k files:
Unmodified Git:
$ time git st eclass/
nothing to commit (working directory clean)
real 0m3.211s
user 0m1.977s
sys 0m1.135s
Modified Git:
$ time ~/w/git/git st eclass/
nothing to commit (working directory clean)
real 0m1.587s
user 0m1.426s
sys 0m0.111s
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-commit.c | 2 +-
wt-status.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 6199db7..dae6cb3 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -1024,7 +1024,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
s.pathspec = get_pathspec(prefix, argv);
read_cache();
- refresh_cache(REFRESH_QUIET|REFRESH_UNMERGED);
+ refresh_index(&the_index, REFRESH_QUIET|REFRESH_UNMERGED, s.pathspec, NULL, NULL);
s.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;
s.in_merge = in_merge;
wt_status_collect(&s);
diff --git a/wt-status.c b/wt-status.c
index 5d56988..65feb29 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -343,7 +343,7 @@ static void wt_status_collect_untracked(struct wt_status *s)
DIR_SHOW_OTHER_DIRECTORIES | DIR_HIDE_EMPTY_DIRECTORIES;
setup_standard_excludes(&dir);
- fill_directory(&dir, NULL);
+ fill_directory(&dir, s->pathspec);
for (i = 0; i < dir.nr; i++) {
struct dir_entry *ent = dir.entries[i];
if (!cache_name_is_other(ent->name, ent->len))
--
1.6.6.181.g5ee6
^ permalink raw reply related
* [PATCH 1/2] rm: only refresh entries that we may touch
From: Nguyễn Thái Ngọc Duy @ 2010-01-14 15:02 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1263481341-28401-1-git-send-email-pclouds@gmail.com>
This gets rid of the whole tree cache refresh. Instead only path that
we touch will get refreshed. We may still lstat() more than needed,
but it'd be better playing safe.
This potentially reduces a large number of lstat() on big trees. Take
gentoo-x86 tree for example, which has roughly 80k files:
Unmodified Git:
$ time git rm --cached skel.ChangeLog
rm 'skel.ChangeLog'
real 0m1.323s
user 0m0.806s
sys 0m0.517s
Modified Git:
$ time git rm --cached skel.ChangeLog
rm 'skel.ChangeLog'
real 0m0.903s
user 0m0.780s
sys 0m0.100s
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-rm.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-rm.c b/builtin-rm.c
index 57975db..4cac3d1 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -169,7 +169,6 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
if (read_cache() < 0)
die("index file corrupt");
- refresh_cache(REFRESH_QUIET);
pathspec = get_pathspec(prefix, argv);
seen = NULL;
@@ -181,6 +180,7 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
struct cache_entry *ce = active_cache[i];
if (!match_pathspec(pathspec, ce->name, ce_namelen(ce), 0, seen))
continue;
+ refresh_cache_entry(ce, 1);
add_list(ce->name);
}
--
1.6.6.181.g5ee6
^ permalink raw reply related
* Re: [PATCH v2 3/3] commit: show interesting ident information in summary
From: Thomas Rast @ 2010-01-14 15:02 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Jeff King, Junio C Hamano, Adam Megacz, git
In-Reply-To: <5722BD3D-E7C9-47F7-B547-09B14D87DA39@wincent.com>
Wincent Colaiuta wrote:
>
> Fair enough, but I'm sighing here at the thought of people jumping in
> and using git commands without even having looked at _any_ of the
> zillions of "your first 10 minutes with Git" tutorials out there,
> which pretty much _all_ start with how to set up your user.name and
> user.email...
If you really are shocked by that thought, try hanging out on #git for
six hours on any given day...
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] git push --track
From: Martin Langhoff @ 2010-01-14 14:35 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Johannes Schindelin, Miles Bader, Rudolf Polzer, git
In-Reply-To: <vpqiqb4lq4q.fsf@bauges.imag.fr>
On Thu, Jan 14, 2010 at 3:25 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> I think he meant
>
> git --git-dir=git+ssh://foo.bar/var/git/mynewthing.git init
exacto. And push --track, all in one cmd.
Zooper easy for users.
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH v2 1/3] strbuf_expand: convert "%%" to "%"
From: Jeff King @ 2010-01-14 14:32 UTC (permalink / raw)
To: Chris Johnsen; +Cc: Junio C Hamano, Adam Megacz, git
In-Reply-To: <CABC23EF-410F-461C-936F-7BE72E9822BC@pobox.com>
On Thu, Jan 14, 2010 at 05:47:09AM -0600, Chris Johnsen wrote:
> On 2010 Jan 13, at 11:35, Jeff King wrote:
> >Signed-off-by: Jeff King <peff@coredump.intra.peff.net>
>
> The patches of the v2 of this series (well, except "4/3") all use
> this surprising, "extended" hostname in their Signed-off-by lines. I
> suppose you unset user.email while testing the series and sent these
> out before restoring your normal configuration.
Heh. Yes, thank you for noticing. That is exactly what happened. Perhaps
the next series should be a huge nag about implicit ident for S-o-b
lines. ;)
Junio, can you please fix up s/coredump.intra.// in your copies before
pushing out?
-Peff
^ permalink raw reply
* Re: [PATCH] git push --track
From: Matthieu Moy @ 2010-01-14 14:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, Miles Bader, Rudolf Polzer, git
In-Reply-To: <alpine.DEB.1.00.1001141509230.3029@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Of course it'd only work if you have full ssh access, unless the git
>> server learns a new command to mkdir (in sane and approved locations).
>
> You mean a new "init" command a la "git --git-dir=bla.git init", which
> _does_ mkdir the directory.
I think he meant
git --git-dir=git+ssh://foo.bar/var/git/mynewthing.git init
which doesn't.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] git push --track
From: Johannes Schindelin @ 2010-01-14 14:16 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Miles Bader, Rudolf Polzer, git
In-Reply-To: <46a038f91001140544u64dd7eefn94625cdc40881cd6@mail.gmail.com>
Hi,
On Thu, 14 Jan 2010, Martin Langhoff wrote:
> <wishlist>Can we take this further and say
>
> git push --make-a-new-repo-and-track-it --shared
> git+ssh://foo.bar/var/git/mynewthing.git master:master
>
> ...?
>
> </wishlist>
You mean just like http pushing?
> Of course it'd only work if you have full ssh access, unless the git
> server learns a new command to mkdir (in sane and approved locations).
You mean a new "init" command a la "git --git-dir=bla.git init", which
_does_ mkdir the directory.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git push --track
From: Martin Langhoff @ 2010-01-14 13:44 UTC (permalink / raw)
To: Miles Bader; +Cc: Rudolf Polzer, git
In-Reply-To: <871vht7cs2.fsf@catnip.gol.com>
On Thu, Jan 14, 2010 at 1:25 AM, Miles Bader <miles@gnu.org> wrote:
> Yay!!
Yay too!
>> git push --track origin mybranch:mybranch
>
> Does it default to the current branch so you can just say "git push --track origin"?
<wishlist>Can we take this further and say
git push --make-a-new-repo-and-track-it --shared
git+ssh://foo.bar/var/git/mynewthing.git master:master
...?
</wishlist>
Of course it'd only work if you have full ssh access, unless the git
server learns a new command to mkdir (in sane and approved locations).
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH 1/5] MSVC: Windows-native implementation for subset of Pthreads API
From: Peter Harris @ 2010-01-14 13:43 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Johannes Sixt, kusmabite, msysgit, git, Andrzej K. Haczewski
In-Reply-To: <20100114051241.GF10586@dpotapov.dyndns.org>
On Thu, Jan 14, 2010 at 12:12 AM, Dmitry Potapov wrote:
> On Wed, Jan 13, 2010 at 07:40:43PM +0100, Johannes Sixt wrote:
>> Is there "InterlockedRead()"? I suppose no, but I would get confirmation that
>> a simple memory mov instruction is atomic WRT Interlocked* functions.
>
> If I were writing Interlocked API, I would certainly add InterlockedRead()
> and InterlockedWrite() functions, but somehow Microsoft decided that these
> functions are redundant.
InterlockedWrite is spelt InterlockedExchange.
> Finally, there is a paranoiac implementation of InterlockedRead(&foo):
>
> result = InterlockedAdd(&foo, 0)
>
> but, IMHO, it is pathetic...
Agreed. Another pathetic implementation:
result = InterlockedCompareExchange(&foo, 0, 0);
Peter Harris
^ permalink raw reply
* Re: Syncing a git working tree with Dropbox?
From: chombee @ 2010-01-14 13:40 UTC (permalink / raw)
To: git
In-Reply-To: <be6fef0d1001132139p56944cdax22674ca773af0199@mail.gmail.com>
Ok, I was aware that I would have to sync the .git directories also, but
my plan was to do that in the normal way (git pull and git push) but
sync the working tree automatically with Dropbox. However, I'm now
imagining all kinds of mind-bending problems this might cause. If I
commit and push some changes on machine A, and Dropbox syncs the working
copy, then I go to machine B, git status will show that machine B has
changes to commit, until I do git pull on machine B. As Geoffrey points
out, changing branches could be even worse!
In any case, I've had problems with detached working trees. With an
older version of git it was refusing to checkout a detached working
tree. I upgraded git and checkout worked, but it refused to do git pull.
Ah well.
I'm not too sure about keeping the .git directory itself in Dropbox.
Googling it, it seems lots of people do it without any problems, but
there are some reports of it going haywire.
On Thu, Jan 14, 2010 at 01:39:10PM +0800, Tay Ray Chuan wrote:
> Hi,
>
> On Thu, Jan 14, 2010 at 7:57 AM, chombee <chombee@lavabit.com> wrote:
> > My idea is that I keep my .git folder safely outside of my Dropbox
> > folder, but my git repository has a detached working tree that is
> > located in the Dropbox folder. On machine B it would be the same setup.
> > So the two machines each have their own clone of the git repo and these
> > are synchronised by git push and git pull with a 'central' remote repo.
> > But the two clones share the same working tree, or more accurately their
> > working trees are synced by Dropbox.
> >
> > The working tree is just files, I don't see how it's different from
> > Dropbox syncing any other files. Dropbox and git ought not to collide in
> > any way. So this should work fine shouldn't it?
>
> Your changes in git (like new commits) won't be synced.
>
> --
> Cheers,
> Ray Chuan
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 14, 2010 at 05:19:08AM -0800, Geoffrey Lee wrote:
> On Wed, Jan 13, 2010 at 9:39 PM, Tay Ray Chuan <rctay89@gmail.com> wrote:
> > On Thu, Jan 14, 2010 at 7:57 AM, chombee <chombee@lavabit.com> wrote:
> >> My idea is that I keep my .git folder safely outside of my Dropbox
> >> folder, but my git repository has a detached working tree that is
> >> located in the Dropbox folder. On machine B it would be the same setup.
> >> So the two machines each have their own clone of the git repo and these
> >> are synchronised by git push and git pull with a 'central' remote repo.
> >> But the two clones share the same working tree, or more accurately their
> >> working trees are synced by Dropbox.
> >>
> >> The working tree is just files, I don't see how it's different from
> >> Dropbox syncing any other files. Dropbox and git ought not to collide in
> >> any way. So this should work fine shouldn't it?
> >
> > Your changes in git (like new commits) won't be synced.
>
> You have to sync your .git directory. For example, using your setup,
> if you switch branches on Machine A, your working directory will
> change on Machine B, but Machine B will still think it's on the
> previous branch. This scenario would cause a lot of problems for Git.
>
> There shouldn't be any problems with placing your entire repository
> (working tree and .git directory) inside Dropbox as long as you only
> use one computer at a time.
>
> -Geoffrey Lee
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Syncing a git working tree with Dropbox?
From: Geoffrey Lee @ 2010-01-14 13:19 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: chombee, git
In-Reply-To: <be6fef0d1001132139p56944cdax22674ca773af0199@mail.gmail.com>
On Wed, Jan 13, 2010 at 9:39 PM, Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Thu, Jan 14, 2010 at 7:57 AM, chombee <chombee@lavabit.com> wrote:
>> My idea is that I keep my .git folder safely outside of my Dropbox
>> folder, but my git repository has a detached working tree that is
>> located in the Dropbox folder. On machine B it would be the same setup.
>> So the two machines each have their own clone of the git repo and these
>> are synchronised by git push and git pull with a 'central' remote repo.
>> But the two clones share the same working tree, or more accurately their
>> working trees are synced by Dropbox.
>>
>> The working tree is just files, I don't see how it's different from
>> Dropbox syncing any other files. Dropbox and git ought not to collide in
>> any way. So this should work fine shouldn't it?
>
> Your changes in git (like new commits) won't be synced.
You have to sync your .git directory. For example, using your setup,
if you switch branches on Machine A, your working directory will
change on Machine B, but Machine B will still think it's on the
previous branch. This scenario would cause a lot of problems for Git.
There shouldn't be any problems with placing your entire repository
(working tree and .git directory) inside Dropbox as long as you only
use one computer at a time.
-Geoffrey Lee
^ permalink raw reply
* Re: [PATCH v2 1/3] strbuf_expand: convert "%%" to "%"
From: Chris Johnsen @ 2010-01-14 11:47 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Adam Megacz, git
In-Reply-To: <20100113173531.GA16786@coredump.intra.peff.net>
On 2010 Jan 13, at 11:35, Jeff King wrote:
> Signed-off-by: Jeff King <peff@coredump.intra.peff.net>
The patches of the v2 of this series (well, except "4/3") all use
this surprising, "extended" hostname in their Signed-off-by lines. I
suppose you unset user.email while testing the series and sent these
out before restoring your normal configuration.
Sorry for the noise if this was intentional (a small joke about the
auto-configured ident info?).
--
Chris
^ permalink raw reply
* Re: [RFC] Git Wiki Move
From: Wincent Colaiuta @ 2010-01-14 10:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20100114012449.GB3299@machine.or.cz>
El 14/01/2010, a las 02:24, Petr Baudis escribió:
> (i) wiki.kernel.org is actually maintained! Thus, there should
> be less spam or upgrade issues and better support in case of
> problems.
>
> (ii) Also, I personally think MediaWiki is so much nicer than
> ikiwiki...
+1 for MediaWiki.
Cheers,
Wincent
^ permalink raw reply
* Re: [RFC] Git Wiki Move
From: Johannes Schindelin @ 2010-01-14 11:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: J.H., git
In-Reply-To: <20100114104843.GC3299@machine.or.cz>
Hi,
On Thu, 14 Jan 2010, Petr Baudis wrote:
> On Thu, Jan 14, 2010 at 02:28:48AM -0800, J.H. wrote:
> > Just a heads up I've got an initial import of the current wiki up at
> > http://git.wiki.kernel.org - some of it was quite a clean conversion,
> > some of it not so much. Please note that user accounts were not
> > carried over but edit histories were. I'll work on cleaning up the
> > rest of if tomorrow, assuming that there isn't any objections to
> > Petr's e-mail above.
>
> Are you going to do a lot of manual work there? Since I haven't disabled
> editing the current wiki yet, so maybe I should already do that... (If I
> can figure out how. ;-)
It would be good: I just verified that warthog imported everything up to
and including the latest 4 changes on January 12.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Git Wiki Move
From: Johannes Schindelin @ 2010-01-14 11:01 UTC (permalink / raw)
To: J.H.; +Cc: Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.1001141136450.4985@pacific.mpi-cbg.de>
Hi,
On Thu, 14 Jan 2010, Johannes Schindelin wrote:
> I note that "<<<!-- ! TOC here -->(2)>>" could be converted to
> "__TOC__", I believe.
Several more things: external links only take single brackets, the
separator between URL and text is a space, not a pipe symbol, and you have
to translate brackets in link texts to [ and ] respectively (see
my test edits on your Wiki).
Likewise, <<BR>> in MoinMoin is <BR> in MediaWiki (the case actually does
not matter).
Probably it would also be good to inform the author of the gitbot on #git
of the change. Was it 'pieter'?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Git Wiki Move
From: Petr Baudis @ 2010-01-14 10:48 UTC (permalink / raw)
To: J.H.; +Cc: git
In-Reply-To: <4B4EF1E0.3040808@eaglescrag.net>
On Thu, Jan 14, 2010 at 02:28:48AM -0800, J.H. wrote:
> Just a heads up I've got an initial import of the current wiki up at
> http://git.wiki.kernel.org - some of it was quite a clean conversion,
> some of it not so much. Please note that user accounts were not carried
> over but edit histories were. I'll work on cleaning up the rest of if
> tomorrow, assuming that there isn't any objections to Petr's e-mail
> above.
Are you going to do a lot of manual work there? Since I haven't disabled
editing the current wiki yet, so maybe I should already do that... (If I
can figure out how. ;-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [RFC] Git Wiki Move
From: Matthieu Moy @ 2010-01-14 10:35 UTC (permalink / raw)
To: J.H.; +Cc: Petr Baudis, git
In-Reply-To: <4B4EF1E0.3040808@eaglescrag.net>
"J.H." <warthog19@eaglescrag.net> writes:
> Just a heads up I've got an initial import of the current wiki up at
> http://git.wiki.kernel.org - some of it was quite a clean conversion,
> some of it not so much. Please note that user accounts were not carried
> over but edit histories were. I'll work on cleaning up the rest of if
> tomorrow, assuming that there isn't any objections to Petr's e-mail
> above.
My only objection would be "Oh, migrating to another wiki engine will
be much conversion work", but if you're willing to do it ;-).
This page seems to be an interesting test-case:
http://git.wiki.kernel.org/index.php/GitFaq
full of miss-imported formatting, links, ...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC] Git Wiki Move
From: Johannes Schindelin @ 2010-01-14 10:43 UTC (permalink / raw)
To: J.H.; +Cc: Petr Baudis, git
In-Reply-To: <4B4EF1E0.3040808@eaglescrag.net>
Hi,
On Thu, 14 Jan 2010, J.H. wrote:
> On 01/13/2010 05:24 PM, Petr Baudis wrote:
>
> > On Thu, Jan 14, 2010 at 12:29:08AM +0100, Petr Baudis wrote:
> >> I would like to notify you that unfortunately, Czech UPC terminated
> >> the sponsorship of the hardware and connectivity hosting the Git Wiki
> >> and repo.or.cz (after generously donating it for several years).
> >
> > ...please scratch the Git Wiki part, you would be supporting just
> > repo.or.cz - we are considering to move the Git wiki to
> > wiki.kernel.org MediaWiki installation and I would like to ask if
> > anyone disagrees with this. The motivation is that:
> >
> > (i) wiki.kernel.org is actually maintained! Thus, there should be
> > less spam or upgrade issues and better support in case of problems.
> >
> > (ii) Also, I personally think MediaWiki is so much nicer than
> > ikiwiki...
... not to mention than MoinMoin...
> > (iii) ...and OBTW, no CamelCase!
> >
> > Of course, there will be compatibility redirects.
>
> Just a heads up I've got an initial import of the current wiki up at
> http://git.wiki.kernel.org - some of it was quite a clean conversion,
> some of it not so much.
Did you use a script? And did you leech the sources, or did you get a
dump?
I note that "<<<!-- ! TOC here -->(2)>>" could be converted to "__TOC__",
I believe.
> Please note that user accounts were not carried over but edit histories
> were.
IIUC there are no email addresses stored in the Git Wiki, so I think that
we'll have to live with that. You might get the occasional complaint of a
stolen account.
> I'll work on cleaning up the rest of if tomorrow, assuming that there
> isn't any objections to Petr's e-mail above.
I like it. Especially since there is a fun project waiting for me to
get some time to do it, to convert the full history of a MediaWiki
instance into a Git repository. Maybe via the git-remote* mechanism, once
Sverre and Ilari manage to flush out the last remnants of clumsy design.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Git Wiki Move
From: J.H. @ 2010-01-14 10:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20100114012449.GB3299@machine.or.cz>
On 01/13/2010 05:24 PM, Petr Baudis wrote:
> Hi!
>
> On Thu, Jan 14, 2010 at 12:29:08AM +0100, Petr Baudis wrote:
>> I would like to notify you that unfortunately, Czech UPC terminated the
>> sponsorship of the hardware and connectivity hosting the Git Wiki and
>> repo.or.cz (after generously donating it for several years).
>
> ...please scratch the Git Wiki part, you would be supporting just
> repo.or.cz - we are considering to move the Git wiki to wiki.kernel.org
> MediaWiki installation and I would like to ask if anyone disagrees with
> this. The motivation is that:
>
> (i) wiki.kernel.org is actually maintained! Thus, there should
> be less spam or upgrade issues and better support in case of
> problems.
>
> (ii) Also, I personally think MediaWiki is so much nicer than
> ikiwiki...
>
> (iii) ...and OBTW, no CamelCase!
>
> Of course, there will be compatibility redirects.
>
>
> P.S.: Sorry for such hasty mail, I just want to avoid extracting money
> from someone on false pretenses. ;-) Let me know if you already sent
> some money and wished to support just the wiki.
Just a heads up I've got an initial import of the current wiki up at
http://git.wiki.kernel.org - some of it was quite a clean conversion,
some of it not so much. Please note that user accounts were not carried
over but edit histories were. I'll work on cleaning up the rest of if
tomorrow, assuming that there isn't any objections to Petr's e-mail
above. If there is I'm more than happy to drop the wiki if need be, but
I figured plowing ahead was reasonably easy and it at least gets the
ball rolling.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: [PATCH] git push --track
From: Johannes Schindelin @ 2010-01-14 10:31 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Rudolf Polzer, git
In-Reply-To: <20100114154154.6117@nanako3.lavabit.com>
Hi,
On Thu, 14 Jan 2010, Nanako Shiraishi wrote:
> Quoting Rudolf Polzer <divVerent@alientrap.org>
>
> > I'd like a feature to automatically "transform" a non-tracking local
> > branch into a tracking branch on push. A patch to do that is attached.
>
> How well does this take earlier discussions on the same topic into account? For example, did you study the design discussion in
> http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=135390
Thank you for looking up that reference.
Do you remember what the outcome was? (Peff mentioned that there was some
talk about putting this code into transport.c and some needed
restructurings, but I do not remember the details, and I did not have time
to follow the development of that file in the recent months.)
Ciao,
Dscho
^ 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