* Re: [PATCH v2] push: point to 'git pull' and 'git push --force' in case of non-fast forward
From: Junio C Hamano @ 2009-08-10 8:49 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Teemu Likonen, git
In-Reply-To: <vpq8whsawjs.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> If you read "Integrate them with your changes" and understand that it is
>> talking about "git pull" or "git pull --rebase", then you do not have to
>> read the doc. It should "click".
>
> But what's the point is being so vague, while you could just add "(see
> git pull)"? See what you've just wrote: one should "understand that it
> is about ...". So, why write Y thinking that the user should
> understand that it is about X while you could write X directly?
In order to cover both "pull" and "pull --rebase"?
^ permalink raw reply
* Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs
From: Junio C Hamano @ 2009-08-10 8:47 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Brian Gernhardt, Johan Herland, Johannes Schindelin
In-Reply-To: <alpine.LNX.2.00.0908092153520.27553@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I think that users should never need to know the names of the helpers. I
> mean, the native protocol uses helpers that most users are completely
> unaware of. The users do need to know what the
... heck ;-)?
But seriously, why not?
> The problem is not that foreign systems don't have "urls" in particular.
> The problem is that there are foreign systems, like perforce, where the
> lines between different repositories in the git sense are drawn in very
> different ways. In perforce, for example, there is a single namespace for
> all branches of all projects hosted on the same server. It's like...
> ...
> (and hundreds more, mixing all the branches of all of the repositories
> for all of the projects, without any conventions beyond what the
> community on the particular server made up)
That looks similar to a subversion server with multiple projects with
multiple branches, and they seem to be able to use
"svn://<whatever svn uses as its own convention>"
just fine.
Why p4 cannot do what svn can? Doesn't p4 ever "name" a repository/branch
inside that "single namespace" with a simple string that is easy to
remember for users? And if there is one, I do not see what prevents you
from using "p4://<whatever information p4 users use>"?
> You really need a different sort of configuration option to specify what
> we think of as "the git.git repository", which includes certain branches
> and doesn't include other projects hosted on kernel.org. And in order to
> find the server, it uses an arbitrary shell command line that acts like
> rsh (and often consists of "ssh" as the command and a bunch of complicated
> options to connect to the right port of the right host to get the right
> restricted shell with the right preset environment). So there's nothing
> you can put in the <whatever string the helper understands> part, because
> the helper really has to figure out what it's doing from a bunch of
> options.
>
> Furthermore, I don't want to just use "p4:" as what people should use in
> remote.*.url in order to select the right helper, because then people are
> going to have different remotes with the same url option value in order to
> access entirely different data.
Maybe it is the _primary_ itch you would want to scratch, but this does
sound like a very special case that wants to have multiple pieces of
pre-parsed information to identify a "repository".
Perhaps in such a case it would be equally valid if you said "p4:hello"
and "p4:goodbye" to identify two "repositories", with p4-helper specific
configuration option that is keyed off of of p4.hello.* and p4.goodbye.*
namespace, e.g. (without knowing p4 at all)
[remote "origin"]
url = p4:hello
[p4 "hello"]
find-server-command = ssh bunch of complicated options
random-p4-option = ...
random-other-p4-option = ...
Of course it does not have to be called "url", and you could do the same
thing with:
[remote "origin"]
vcs = p4
[p4 "origin"]
find-server-command = ssh bunch of complicated options
random-p4-option = ...
random-other-p4-option = ...
And probably there aren't much difference either way between these two
appraoches. The former gives an extra name ("hello") that may simply be
redundant, or perhaps adds value by descriptive, depending on your
viewpoint.
^ permalink raw reply
* Re: [PATCH v2] push: point to 'git pull' and 'git push --force' in case of non-fast forward
From: Matthieu Moy @ 2009-08-10 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Teemu Likonen, git
In-Reply-To: <7vljls7n4v.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> If you read "Integrate them with your changes" and understand that it is
> talking about "git pull" or "git pull --rebase", then you do not have to
> read the doc. It should "click".
But what's the point is being so vague, while you could just add "(see
git pull)"? See what you've just wrote: one should "understand that it
is about ...". So, why write Y thinking that the user should
understand that it is about X while you could write X directly?
--
Matthieu
^ permalink raw reply
* Re: [PATCH] svn: allow git-svn to update remotes outside of refs/remotes
From: Eric Wong @ 2009-08-10 8:38 UTC (permalink / raw)
To: Adam Brewster; +Cc: git
In-Reply-To: <1249350039-7338-4-git-send-email-adambrewster@gmail.com>
Adam Brewster <adambrewster@gmail.com> wrote:
> It may be convenient for some users to store svn remote tracking
> branches outside of the refs/remotes/ heirarchy. [1] and [2] indicate
> that there is interest in making this possible.
>
> [1] http://www.gitready.com/advanced/2009/02/16/convert-git-svn-tag-branches-to-real-tags.html
> [2] http://kerneltrap.org/mailarchive/git/2007/8/30/256359
I definitely agree with the direction of this...
We'll need a mechanism for migrating existing repos from
.git/svn/foo/* => .git/svn/refs/remotes/foo/* to avoid breaking
things for people with existing repos. I guess that's why
you've been looking at (and helping fix) the migrate test :)
--
Eric Wong
^ permalink raw reply
* backups with git
From: Roald de Vries @ 2009-08-10 8:27 UTC (permalink / raw)
To: git
Dear all,
I'm thinking of using git as a backup solution for my whole system,
setting my $GIT_DIR to something like "/backupdisc/backup". Does that
seem sensible? In his Google tech talk, Linus said that git was not
good at huge projects; I guess that would apply to backups. On the
other hand, maybe a backup doesn't need to be as fast as he wants git
to be for projects. Has anybody used git like this? And was it a good
experience?
Kind regards,
Roald
^ permalink raw reply
* Re: [PATCH] svn: Add && to t9107-git-svn-migrarte.sh
From: Eric Wong @ 2009-08-10 8:32 UTC (permalink / raw)
To: Adam Brewster; +Cc: git
In-Reply-To: <20090806212841.GA13437@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> Adam Brewster <adambrewster@gmail.com> wrote:
> > It was probably intended for the test to fail unless all of the
> > commands succeed.
>
> I think you've uncovered some major breakage in this test that never got
> noticed until now. I'll try to take a harder look tonight or this
> weekend.
>
> Fortunately, this functionality is rarely needed these days :)
> Thanks for the heads up!
Actually, the test should look like this, I'll push it out
along with the other one in a few.
>From 4ebe6e92c3b62d5192b6cc8158fde701bf2c0dcb Mon Sep 17 00:00:00 2001
From: Adam Brewster <adambrewster@gmail.com>
Date: Mon, 3 Aug 2009 21:40:37 -0400
Subject: [PATCH] svn: Add && to t9107-git-svn-migrate.sh
It was probably intended for the test to fail unless all of the
commands succeed.
[ew: fixed tests to actually work]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t9107-git-svn-migrate.sh | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/t/t9107-git-svn-migrate.sh b/t/t9107-git-svn-migrate.sh
index 3a9e077..c0098d9 100755
--- a/t/t9107-git-svn-migrate.sh
+++ b/t/t9107-git-svn-migrate.sh
@@ -56,7 +56,15 @@ test_expect_success 'initialize a multi-repository repo' '
git config --add svn-remote.svn.fetch "branches/b:refs/remotes/b" &&
for i in tags/0.1 tags/0.2 tags/0.3; do
git config --add svn-remote.svn.fetch \
- $i:refs/remotes/$i || exit 1; done
+ $i:refs/remotes/$i || exit 1; done &&
+ git config --get-all svn-remote.svn.fetch > fetch.out &&
+ grep "^trunk:refs/remotes/trunk$" fetch.out &&
+ grep "^branches/a:refs/remotes/a$" fetch.out &&
+ grep "^branches/b:refs/remotes/b$" fetch.out &&
+ grep "^tags/0\.1:refs/remotes/tags/0\.1$" fetch.out &&
+ grep "^tags/0\.2:refs/remotes/tags/0\.2$" fetch.out &&
+ grep "^tags/0\.3:refs/remotes/tags/0\.3$" fetch.out &&
+ grep "^:refs/${remotes_git_svn}" fetch.out
'
# refs should all be different, but the trees should all be the same:
@@ -86,14 +94,14 @@ test_expect_success 'migrate --minimize on old inited layout' '
echo "$svnrepo"$path > "$GIT_DIR"/svn/$ref/info/url ) || exit 1;
done &&
git svn migrate --minimize &&
- test -z "`git config -l |grep -v "^svn-remote\.git-svn\."`" &&
+ test -z "`git config -l | grep "^svn-remote\.git-svn\."`" &&
git config --get-all svn-remote.svn.fetch > fetch.out &&
grep "^trunk:refs/remotes/trunk$" fetch.out &&
grep "^branches/a:refs/remotes/a$" fetch.out &&
grep "^branches/b:refs/remotes/b$" fetch.out &&
grep "^tags/0\.1:refs/remotes/tags/0\.1$" fetch.out &&
grep "^tags/0\.2:refs/remotes/tags/0\.2$" fetch.out &&
- grep "^tags/0\.3:refs/remotes/tags/0\.3$" fetch.out
+ grep "^tags/0\.3:refs/remotes/tags/0\.3$" fetch.out &&
grep "^:refs/${remotes_git_svn}" fetch.out
'
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs
From: Johan Herland @ 2009-08-10 8:32 UTC (permalink / raw)
To: git; +Cc: Daniel Barkalow, Junio C Hamano, Brian Gernhardt,
Johannes Schindelin
In-Reply-To: <alpine.LNX.2.00.0908092153520.27553@iabervon.org>
On Monday 10 August 2009, Daniel Barkalow wrote:
> On Sun, 9 Aug 2009, Junio C Hamano wrote:
> > Daniel Barkalow <barkalow@iabervon.org> writes:
> > > If this is set, the url is not required, and the transport always
> > > uses a helper named "git-remote-<value>".
> > >
> > > It is a separate configuration option in order to allow a sensible
> > > configuration for foreign systems which either have no meaningful
> > > urls for repositories or which require urls that do not specify the
> > > system used by the repository at that location. However, this only
> > > affects how the name of the helper is determined, not anything about
> > > the interaction with the helper, and the contruction is such that, if
> > > the foreign scm does happen to use a co-named url method, a url with
> > > that method may be used directly.
> >
> > Personally, I do not like this.
> >
> > Why isn't it enough to define the canonical remote name git takes as
> > "<name of the helper>:<whatever string the helper understands>"?
>
> [...]
>
> The only way I've been able to come up with to support this at all
> usefully is to have a bunch of helper-specific options that specify what
> the helper needs to know about the locations you consider to be part of
> the project and an option that tells git that this remote uses the p4
> helper. I'm not sure what makes sense for other helpers, but the case I
> actually use needs something like what's in this patch.
I'm somewhat agnostic on this issue. At the moment, I follow the P4 cues,
and use a config like this:
[remote "foo"]
vcs = cvs
cvsRoot = ":pserver:user@cvs.server.example.com/var/cvs/cvsroot"
cvsModule = "bar"
...
But I could just as well use a config like this instead:
[remote "foo"]
url = "cvs::pserver:user@cvs.server.example.com/var/cvs/cvsroot#bar"
...
Either is fine with me, although I suspect users might find the
current/first alternative easier to parse.
> I think it makes sense for svn access to support just having a url
> option like "svn://something (svn native protocol)", or
> "svn+ssh://something (svn protocol over ssh)" or "svn+https://something
> (https access to a svn repo)", or some other similar syntax, but this is
> a poor fit for p4.
>
> In order to support this, there just needs to be a call to check whether
> "remote-<something>" is an available git command (without running it or
> giving an error), and the helper code should be used if it is. This is
> actually required so that people with workstations whose domain is
> .kernel.org and who have cloned "master:/home/linus/something.git" don't
> start getting "remote-master isn't a git command" errors (that is,
> misinterpreting ssh-format location hostnames as helper names. Johan,
> perhaps you could write that for your CVS helper?
Sorry, not following you here. Write exactly what?
- The code in the transport layer for checking if "remote-<something>"
is an available git command?
- The code in my CVS helper for handling the ssh-format misinterpretation,
i.e. the case where someone has a git/ssh server called "cvs"? If so,
how should this be handled?
> I think that, ideally, helpers for foreign systems would be portable
> across multiple native systems. The svn helper could be a program
> "svn-remote-access-helper", and anything that speaks fast-import (e.g.,
> bzr or hg) would be able to use it. When installing it for git, you'd
> symlink it to git-remote-svn; if you decided to install
> "svn-remote-access-helper-ng", you'd change the symlink.
In that case, helpers must keep their metadata in a repo-independent
format. Currently that is outside the scope of my CVS helper, since I'm
leveraging git-notes for most of the CVS helper's metadata.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* gitweb stops working sometimes
From: Erez Zilber @ 2009-08-10 8:01 UTC (permalink / raw)
To: git
Hi,
I'm running gitweb on a centos 5.3 server and it works well 99% of the
time. Sometimes, I see the following behavior:
1. I'm able to load the page that shows all git trees.
2. When I click on one of the links that should show a specific tree,
it opens a page with the following text: "<div
class="title"> </div>
"
If I restart httpd, it doesn't help. The only solution that I found so
far is to reboot the server and then everything works. However,
rebooting the server is a bad solution.
Any idea?
Thanks,
Erez
^ permalink raw reply
* Re: [PATCH] fix potential infinite loop given large unsigned integer
From: Christian Couder @ 2009-08-10 5:24 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Junio C Hamano, Ryan Flynn, git
In-Reply-To: <40aa078e0908090525h7b4d6efeh658e2edcfbe16c7e@mail.gmail.com>
On Sunday 09 August 2009, Erik Faye-Lund wrote:
> On Sun, Aug 9, 2009 at 9:38 AM, Junio C Hamano<gitster@pobox.com> wrote:
> > + static char num_buf[64];
> > rev.total = total + start_number - 1;
> > + sprintf(num_buf, "%d", rev.total);
> > + rev.num_width = strlen(num_buf);
>
> how about
> rev.num_width = (int)log10((double)rev.total) + 1;
>
> hm?
>
> log10() appears to be C99, but can be emulated on earlier C-versions by
> doing #define log10(x) (log(x) / log(10.0))
That would mean linking with -lm?
Regards,
Christian.
^ permalink raw reply
* [PATCH] git-instaweb: detect difference between mod_cgi and mod_cgid for apache2
From: Mark A Rada @ 2009-08-10 5:19 UTC (permalink / raw)
To: git
I'm not sure if this should have been two patches or just one.
First I changed the check of whether mod_cgi is built in or not from
matching against
'mod_cgi.c' to 'mod_cgi' because I made the assumption that mod_cgid
would be called
'mod_cgid.c' (I haven't actually checked this, but it sounds
reasonable). Then, the
second change handles the two cases when no cgi module is built in,
which I did try
(for mod_cgid that is).
Also, should the socket needed for mod_cgid be put in $GIT_DIR or
somewhere else?
tl;dr I only actually tried 1/4 cases, everything else looks reasonable
--
Mark A Rada (ferrous26)
marada@uwaterloo.ca
--->8---
Some people have mod_cgid in place of mod_cgi, this will check which one
the user has available to them first, and then act accordingly.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
---
git-instaweb.sh | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 5f5cac7..fdac0d0 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -297,8 +297,14 @@ EOF
# plain-old CGI
resolve_full_httpd
list_mods=$(echo "$full_httpd" | sed "s/-f$/-l/")
- $list_mods | grep 'mod_cgi\.c' >/dev/null 2>&1 || \
- echo "LoadModule cgi_module $module_path/mod_cgi.so" >> "$conf"
+ $list_mods | grep 'mod_cgi' >/dev/null 2>&1 || \
+ if test -f "$module_path/mod_cgi.so"
+ then
+ echo "LoadModule cgi_module $module_path/mod_cgi.so" >> "$conf"
+ else
+ echo "LoadModule cgi_module $module_path/mod_cgid.so" >> "$conf"
+ echo "ScriptSock $GIT_DIR/gitweb.sock" >> "$conf"
+ fi
cat >> "$conf" <<EOF
AddHandler cgi-script .cgi
<Location /gitweb.cgi>
--
1.6.4
^ permalink raw reply related
* Re: Implementing $Date$ substitution - problem with git status
From: Peter Krefting @ 2009-08-10 4:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git List
In-Reply-To: <200908092252.58363.j6t@kdbg.org>
Johannes Sixt:
> The clean filter is applied before 'git diff' generates the diff. Since you
> have unstaged changes (I take [...] to mean this), you see a new date on
> every invocation.
Sorry for being unclear; no, the $Date$ line is the only change that shows
up. I removed the surrounding context because I didn't want to publish them.
On another machine, there is another file that exhibits the same problem.
> After 'git add .htaccess' subsequent 'git diff' should not show any changes.
But then I need to check it in again, and I'd like to avoid that, if possible.
Is it possible to have a filter run on "commit" instead of "add"? (Or is
"commit" just moving changes from the index to the repository, making that
impossible?)
>> Doing "git reset --hard" or "git checkout master filename" does not
>> help, the file is still believed to be modified by git.
>
> Now, that's an entirely different problem, and I think that there is a
> bug. I have observed this as well with my own clean filter sometimes, but
> not always. I haven't found a recipe that reliably exhibits the problem.
It seems to be triggered by using my date script and doing
git add file
git commit file
git reset --hard file
the last command gives me a local copy with the keyword expanded, but marked
dirty.
Is it possible to have "git add" expand the keyword (both the Git-internal
"ident", i.e "$Id$", and my "$Date$")? Would duplicating the "clean" filter
as a "smudge" one accomplish that?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* [JGIT PATCH 1/1] Generate javadoc when making jgit. Also, package docs into a zip for distribution.
From: Nicholas Campbell @ 2009-08-10 4:32 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Robin Rosenberg
Runs through defined "PLUGINS" and creates Javadoc. Assumes src is a subdir.
Signed-off-by: Nick Campbell <nicholas.j.campbell@gmail.com>
---
make_jgit.sh | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/make_jgit.sh b/make_jgit.sh
index baaa3af..25ac15c 100755
--- a/make_jgit.sh
+++ b/make_jgit.sh
@@ -3,6 +3,7 @@
O_CLI=jgit
O_JAR=jgit.jar
O_SRC=jgit_src.zip
+O_DOC=jgit_docs.zip
PLUGINS="
org.spearce.jgit
@@ -119,3 +120,12 @@ mv $O_CLI+ $O_CLI &&
echo "Created $O_CLI." || die "Build failed."
cleanup_bin
+
+echo "Build Docs"
+for p in $PLUGINS; do
+ javadoc -sourcepath "$p/src/" -d "docs/$p/" `find "$p/src" -name "*.java"`
+done
+
+jar cf "$O_DOC" docs/
+echo "Created $O_DOC."
+
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs
From: Daniel Barkalow @ 2009-08-10 4:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brian Gernhardt, Johan Herland, Johannes Schindelin
In-Reply-To: <7v1vnk79lt.fsf@alter.siamese.dyndns.org>
On Sun, 9 Aug 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > If this is set, the url is not required, and the transport always uses
> > a helper named "git-remote-<value>".
> >
> > It is a separate configuration option in order to allow a sensible
> > configuration for foreign systems which either have no meaningful urls
> > for repositories or which require urls that do not specify the system
> > used by the repository at that location. However, this only affects
> > how the name of the helper is determined, not anything about the
> > interaction with the helper, and the contruction is such that, if the
> > foreign scm does happen to use a co-named url method, a url with that
> > method may be used directly.
>
> Personally, I do not like this.
>
> Why isn't it enough to define the canonical remote name git takes as
> "<name of the helper>:<whatever string the helper understands>"?
I think that users should never need to know the names of the helpers. I
mean, the native protocol uses helpers that most users are completely
unaware of. The users do need to know what the
> Then <whatever string the helper understands> part does not have to
> resemble URL at all, if the foreign system does not have such a concept
> (i.e. "have no meaning urls for repositories").
The problem is not that foreign systems don't have "urls" in particular.
The problem is that there are foreign systems, like perforce, where the
lines between different repositories in the git sense are drawn in very
different ways. In perforce, for example, there is a single namespace for
all branches of all projects hosted on the same server. It's like if
kernel.org had branches:
- git-master
- linux-master
- git-next
- linux-next
- linux-rt
- git-pu
- linux-stable
- sparse-master
(and hundreds more, mixing all the branches of all of the repositories
for all of the projects, without any conventions beyond what the
community on the particular server made up)
You really need a different sort of configuration option to specify what
we think of as "the git.git repository", which includes certain branches
and doesn't include other projects hosted on kernel.org. And in order to
find the server, it uses an arbitrary shell command line that acts like
rsh (and often consists of "ssh" as the command and a bunch of complicated
options to connect to the right port of the right host to get the right
restricted shell with the right preset environment). So there's nothing
you can put in the <whatever string the helper understands> part, because
the helper really has to figure out what it's doing from a bunch of
options.
Furthermore, I don't want to just use "p4:" as what people should use in
remote.*.url in order to select the right helper, because then people are
going to have different remotes with the same url option value in order to
access entirely different data.
The only way I've been able to come up with to support this at all
usefully is to have a bunch of helper-specific options that specify what
the helper needs to know about the locations you consider to be part of
the project and an option that tells git that this remote uses the p4
helper. I'm not sure what makes sense for other helpers, but the case I
actually use needs something like what's in this patch.
I think it makes sense for svn access to support just having a url
option like "svn://something (svn native protocol)", or
"svn+ssh://something (svn protocol over ssh)" or "svn+https://something
(https access to a svn repo)", or some other similar syntax, but this is a
poor fit for p4.
In order to support this, there just needs to be a call to check whether
"remote-<something>" is an available git command (without running it or
giving an error), and the helper code should be used if it is. This is
actually required so that people with workstations whose domain is
.kernel.org and who have cloned "master:/home/linus/something.git" don't
start getting "remote-master isn't a git command" errors (that is,
misinterpreting ssh-format location hostnames as helper names. Johan,
perhaps you could write that for your CVS helper?
> Your "let's eject curl based transport out of core" helper (already in
> 'next') will become something like these in the canonical form:
>
> curl:http://git.kernel.org/pub/scm/git/git.git
> curl:ftp://git.kernel.org/pub/scm/git/git.git
> curl:https://git.kernel.org/pub/scm/git/git.git
>
> that are handled by a single helper binary git-remote-curl, but nobody has
> to use these canonical forms for well-known transports, because we can
> have an obvious set of backward-compatible synonyms that are understood by
> the transport layer to choose that helper program, so that usual
>
> http://git.kernel.org/pub/scm/git/git.git
>
> will be understood to choose git-remote-curl backend. We do not need to
> have three git-remote-{http,https,ftp} helpers at all.
>
> That way, a Subversion repository people may want to interact with would
> be spelled, if the helper is "git-remote-svn", like this:
>
> svn:https://scummvm.svn.sourceforge.net/svnroot/scummvm/
>
> and it would be crystal clear that it is not a git native repository that
> is accessed over curl based walkers, and also the folks who still have not
> migrated to git can simply drop the leading "svn:" and learn the name of
> the repository they could access natively with Subversion. Nobody on the
> Subversion side would think svn:https://... is the URL to use with
> Subversion (after all they will see that on the communication in the git
> circle).
>
> And from the git side, we can tell users: "if you want to interact with
> Subversion repositories, you can use traditional git-svn, or you can use
> the unified remote mechanism. To use the latter, just prefix 'svn:' in
> front of the URL used to refer to the repository in the Subversion world".
>
> If you spell the "URL" as https://scummvm.svn.sourceforge.net/svnroot/scummvm/
> then you wouldn't be able to give that directly to git from the command
> line, without using this new configuration. I do not quite understand why
> this indirection is desired. I think it only confuses users.
As I said above, I think that just picking the start off of the URL is a
good solution for systems where the remote repository has a location, but
that's not every system, and not the one that's my personal itch.
> I recall somebody earlier mentioned a possibility to have more than one
> helper that deals with one type of foreign system. In such a case, a pair
> of URL and vcs configuration can be used to identify what helper to use on
> what foreign "repository":
>
> (https://scummvm.svn.sourceforge.net/svnroot/scummvm/, svn)
> (https://scummvm.svn.sourceforge.net/svnroot/scummvm/, svn-ng)
>
> and it might become easier to switch the helper without changing the URL
> part. But I do not particularly think that would be a practical
> advantage, unless we can assume that the next-generation version of the
> helper can somehow reuse the metadata the old version of the helper left
> in the repository and incrementally operate on the repository. Even in
> that case, I think spelling everything out in a single configuration
> (i.e.. remote.$name.url) would make it clearer to see what is going on.
I think that, ideally, helpers for foreign systems would be portable
across multiple native systems. The svn helper could be a program
"svn-remote-access-helper", and anything that speaks fast-import (e.g.,
bzr or hg) would be able to use it. When installing it for git, you'd
symlink it to git-remote-svn; if you decided to install
"svn-remote-access-helper-ng", you'd change the symlink.
Of course, there's a long way to go before helpers can be portable in this
direction, but I think it's mostly tractable and good for making the code
clean.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Check return value of ftruncate call in http.c. Remove possible mem leak
From: Junio C Hamano @ 2009-08-10 1:54 UTC (permalink / raw)
To: Jeff Lasslett; +Cc: git
In-Reply-To: <1249709881-31334-1-git-send-email-jeff.lasslett@gmail.com>
Jeff Lasslett <jeff.lasslett@gmail.com> writes:
> In new_http_object_request(), check ftruncate() call return value and
> handle possible errors. Remove possible leak of mem pointed to by url.
Are you assuming that everybody is running libcurl 7.17.0 or later?
Before that version strings given to easy_setopt() were not copied and you
needed to keep them around.
I think freeing url is fine but you would probably need to then give
freq->url to easy_setopt(CURLOPT_URL) if you wanted to do so.
^ permalink raw reply
* Instaweb using ModPerl::Registry over ModPerl::RegistryBB
From: Mark A Rada @ 2009-08-10 1:51 UTC (permalink / raw)
To: git
Hi,
I've noticed that the instaweb script uses ModPerl::Registry over
ModPerl::RegistryBB.
RegistryBB is supposed to be a bit lighter (read faster) by not
performing some checks
(according to the documentation), and appears to not break gitweb. So
my question is
that I am wondering if this has come up in the past, or someone else
knows a reason
why Registry should be used over RegistryBB (safety, breaks something
I haven't
tried)?
--
Mark A Rada (ferrous26)
marada@uwaterloo.ca
^ permalink raw reply
* Re: [PATCH] git-instaweb: fix mod_perl detection for apache2
From: Junio C Hamano @ 2009-08-10 1:38 UTC (permalink / raw)
To: Mark A Rada; +Cc: git
In-Reply-To: <4C22ECF8-8FBE-4E45-A7CF-EA1203B49AA7@mailservices.uwaterloo.ca>
Mark A Rada <marada@uwaterloo.ca> writes:
> The script was looking for something that matched the '^our $gitbin'
> regex, which no longer exists in gitweb.cgi.
>
> Now it looks for 'MOD_PERL', which should be on the line that checks
> to see if the script is running in a mod_perl environment.
Thanks. That sounds like an ancient bug that in turn perhaps suggests
nobody uses instaweb. Will apply to 'maint'..
^ permalink raw reply
* Re: [PATCH] gitk: new option to hide remote refs
From: Thell Fowler @ 2009-08-10 0:14 UTC (permalink / raw)
To: Thomas Rast; +Cc: Paul Mackerras, git
In-Reply-To: <55b7e43bcd59aa64c70edde83ac87147aa0091bb.1249336225.git.trast@student.ethz.ch>
Thomas Rast (trast@student.ethz.ch) wrote on Aug 3, 2009:
> In repositories with lots of remotes, looking at the history in gitk
> can be borderline insane with all the red labels for remote refs.
> Introduce a new option in the preferences that hides them.
Thanks for doing this! It definitely is saving the sanity and is working
great!
--
Thell
^ permalink raw reply
* Re: fatal: bad revision 'HEAD'
From: Jeff King @ 2009-08-10 1:18 UTC (permalink / raw)
To: Joel Mahoney; +Cc: git
In-Reply-To: <06DCECD0-45F0-4695-86D4-7C54EFE4E640@gmail.com>
On Sun, Aug 09, 2009 at 03:15:46PM -0600, Joel Mahoney wrote:
> I am having trouble installing Ruby on Rails plugins from github.
> when I run e.g. script/install plugin git://github.com/thoughtbot/
> paperclip.git I get:
>
> > Initialized empty Git repository in /path/to/my/project/vendor/
> plugins/paperclip/.git/
> > fatal: bad revision 'HEAD'
> > refusing to pull with rebase: your working tree is not up-to-date
I can "git clone" that repository just fine. What is it exactly that
installing a Rails plugin does with git? Can you try setting GIT_TRACE=1
in the environment and running your script to show us what git commands
it is executing?
-Peff
^ permalink raw reply
* Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs
From: Junio C Hamano @ 2009-08-10 1:15 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Brian Gernhardt
In-Reply-To: <alpine.LNX.2.00.0908091526060.27553@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> If this is set, the url is not required, and the transport always uses
> a helper named "git-remote-<value>".
>
> It is a separate configuration option in order to allow a sensible
> configuration for foreign systems which either have no meaningful urls
> for repositories or which require urls that do not specify the system
> used by the repository at that location. However, this only affects
> how the name of the helper is determined, not anything about the
> interaction with the helper, and the contruction is such that, if the
> foreign scm does happen to use a co-named url method, a url with that
> method may be used directly.
Personally, I do not like this.
Why isn't it enough to define the canonical remote name git takes as
"<name of the helper>:<whatever string the helper understands>"?
Then <whatever string the helper understands> part does not have to
resemble URL at all, if the foreign system does not have such a concept
(i.e. "have no meaning urls for repositories").
Your "let's eject curl based transport out of core" helper (already in
'next') will become something like these in the canonical form:
curl:http://git.kernel.org/pub/scm/git/git.git
curl:ftp://git.kernel.org/pub/scm/git/git.git
curl:https://git.kernel.org/pub/scm/git/git.git
that are handled by a single helper binary git-remote-curl, but nobody has
to use these canonical forms for well-known transports, because we can
have an obvious set of backward-compatible synonyms that are understood by
the transport layer to choose that helper program, so that usual
http://git.kernel.org/pub/scm/git/git.git
will be understood to choose git-remote-curl backend. We do not need to
have three git-remote-{http,https,ftp} helpers at all.
That way, a Subversion repository people may want to interact with would
be spelled, if the helper is "git-remote-svn", like this:
svn:https://scummvm.svn.sourceforge.net/svnroot/scummvm/
and it would be crystal clear that it is not a git native repository that
is accessed over curl based walkers, and also the folks who still have not
migrated to git can simply drop the leading "svn:" and learn the name of
the repository they could access natively with Subversion. Nobody on the
Subversion side would think svn:https://... is the URL to use with
Subversion (after all they will see that on the communication in the git
circle).
And from the git side, we can tell users: "if you want to interact with
Subversion repositories, you can use traditional git-svn, or you can use
the unified remote mechanism. To use the latter, just prefix 'svn:' in
front of the URL used to refer to the repository in the Subversion world".
If you spell the "URL" as https://scummvm.svn.sourceforge.net/svnroot/scummvm/
then you wouldn't be able to give that directly to git from the command
line, without using this new configuration. I do not quite understand why
this indirection is desired. I think it only confuses users.
I recall somebody earlier mentioned a possibility to have more than one
helper that deals with one type of foreign system. In such a case, a pair
of URL and vcs configuration can be used to identify what helper to use on
what foreign "repository":
(https://scummvm.svn.sourceforge.net/svnroot/scummvm/, svn)
(https://scummvm.svn.sourceforge.net/svnroot/scummvm/, svn-ng)
and it might become easier to switch the helper without changing the URL
part. But I do not particularly think that would be a practical
advantage, unless we can assume that the next-generation version of the
helper can somehow reuse the metadata the old version of the helper left
in the repository and incrementally operate on the repository. Even in
that case, I think spelling everything out in a single configuration
(i.e.. remote.$name.url) would make it clearer to see what is going on.
^ permalink raw reply
* Re: [PATCH] fix potential infinite loop given large unsigned integer
From: Ryan Flynn @ 2009-08-10 0:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3a81a13z.fsf@alter.siamese.dyndns.org>
On Sun, Aug 9, 2009 at 3:38 AM, Junio C Hamano<gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Ryan Flynn <parseerror@gmail.com> writes:
>>
>>> given n, tried to find i greater than n via i=1, iterate i *= 10.
>>> given n sufficiently close to UINT_MAX this will overflow; which can
>>> produce i==0, which results in an infinite loop. iteratively dividing
>>> n /= 10 does not have this problem, and though division is slower than
>>> multiplication this only runs once per `git format-patch
>>> --cover-letter`
>>>
>>> Signed-off-by: pizza <parseerror@gmail.com>
>>
>> Pizza?
>>
>> This is somewhat amusing.
>>
>> - digits_in_number() is called only with opt->total that is "int";
>>
>> - opt->total is the total number of patches.
>>
>> - the return value is used like this:
>>
>> sprintf(buf, "%0*d", digits_in_number(opt->total), opt->nr);
>>
>> and opt->nr runs from 1 to opt->total; the use of "d" would be already
>> wrong anyway even if you computed digits_in_number() correctly.
>>
>> Perhaps we should get rid of this function altogether?
>
> Or perhaps something stupid like this...
>
> builtin-log.c | 6 +++++-
> log-tree.c | 12 +-----------
> revision.h | 2 +-
> 3 files changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/builtin-log.c b/builtin-log.c
> index 3817bf1..321e8f5 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -1096,8 +1096,12 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> total = nr;
> if (!keep_subject && auto_number && total > 1)
> numbered = 1;
> - if (numbered)
> + if (numbered) {
> + static char num_buf[64];
> rev.total = total + start_number - 1;
> + sprintf(num_buf, "%d", rev.total);
> + rev.num_width = strlen(num_buf);
> + }
> if (in_reply_to || thread || cover_letter)
> rev.ref_message_ids = xcalloc(1, sizeof(struct string_list));
> if (in_reply_to) {
> diff --git a/log-tree.c b/log-tree.c
> index 6f73c17..0d32a6c 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -158,16 +158,6 @@ static void append_signoff(struct strbuf *sb, const char *signoff)
> strbuf_addch(sb, '\n');
> }
>
> -static unsigned int digits_in_number(unsigned int number)
> -{
> - unsigned int i = 10, result = 1;
> - while (i <= number) {
> - i *= 10;
> - result++;
> - }
> - return result;
> -}
> -
> static int has_non_ascii(const char *s)
> {
> int ch;
> @@ -212,7 +202,7 @@ void log_write_email_headers(struct rev_info *opt, struct commit *commit,
> snprintf(buffer, sizeof(buffer),
> "Subject: [%s %0*d/%d] ",
> opt->subject_prefix,
> - digits_in_number(opt->total),
> + opt->num_width,
> opt->nr, opt->total);
> subject = buffer;
> } else if (opt->total == 0 && opt->subject_prefix && *opt->subject_prefix) {
> diff --git a/revision.h b/revision.h
> index fb74492..21e4d9d 100644
> --- a/revision.h
> +++ b/revision.h
> @@ -84,7 +84,7 @@ struct rev_info {
> unsigned int abbrev;
> enum cmit_fmt commit_format;
> struct log_info *loginfo;
> - int nr, total;
> + int nr, total, num_width;
> const char *mime_boundary;
> const char *patch_suffix;
> int numbered_files;
>
why carry around a piece of information that is only used in one place
and is not expensive to calculate? how about a middle-ground such as:
diff --git a/log-tree.c b/log-tree.c
index 6f73c17..4888518 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -158,14 +158,11 @@ static void append_signoff(struct strbuf *sb,
const char *signoff)
strbuf_addch(sb, '\n');
}
-static unsigned int digits_in_number(unsigned int number)
+static int digits_in_number(int number)
{
- unsigned int i = 10, result = 1;
- while (i <= number) {
- i *= 10;
- result++;
- }
- return result;
+ static char num_buf[64];
+ sprintf(num_buf, "%u", number);
+ return (int)strlen(num_buf);
}
static int has_non_ascii(const char *s)
^ permalink raw reply related
* Re: [PATCH] fix potential infinite loop given large unsigned integer
From: Ryan Flynn @ 2009-08-09 23:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6pta4rd.fsf@alter.siamese.dyndns.org>
> Perhaps we should get rid of this function altogether?
I was thinking of something like that, but figured i'd start small and
fix the bug first.
^ permalink raw reply
* [PATCH v4 0/5] Re: {checkout,reset,stash} --patch
From: Nicolas Sebrecht @ 2009-08-09 22:26 UTC (permalink / raw)
To: Thomas Rast
Cc: Nicolas Sebrecht, Jeff King, git, Junio C Hamano,
Sverre Rabbelier, Nanako Shiraishi
In-Reply-To: <200908092342.31733.trast@student.ethz.ch>
The 09/08/09, Thomas Rast wrote:
> Nicolas Sebrecht wrote:
>
> Yes, you can, precisely as I wrote:
>
> > > covered by 'git checkout -p HEAD'.
I did my tests including "HEAD" but only with "-- file" too...
> I figured this makes sense:
>
> git checkout -- file # copy file from index to worktree
> git checkout -p [file] # copy hunks from index to worktree
> git checkout HEAD -- file # copy file from HEAD to index&worktree
> git checkout -p HEAD -- file # copy hunks from HEAD to index&worktree
...and I don't have what's expected
Current branch: my_branch (clean)
nicolas@vidovic git % echo 'Hi Thomas' >> Documentation/SubmittingPatches
Current branch: my_branch (dirty: working_tree)
nicolas@vidovic git % git add Documentation/SubmittingPatches
Current branch: my_branch (dirty: index)
nicolas@vidovic git % git checkout -p HEAD -- Documentation/SubmittingPatches
No changes.
where "checkout -p HEAD" works fine.
> Note that the patch application stage has no guarantees that what you
> picked will also apply to the index; it tries first, and if it
> doesn't, it asks if it should apply to the worktree anyway (and leave
> the index unchanged).
Ok. All of what you say above makes sense and I'm actually fine with
your whole answer. That said,
% git checkout -p HEAD
and
% git checkout -p HEAD -- file
behave differently here in my test above.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] merge: indicate remote tracking branches in merge message
From: Jeff King @ 2009-08-09 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprb47pam.fsf@alter.siamese.dyndns.org>
On Sun, Aug 09, 2009 at 12:36:17PM -0700, Junio C Hamano wrote:
> > Previously, merging a tag directly via "git merge tag" would
> > get you the message "Merge commit 'tag'". It is a little
> > more descriptive to note that it was actually a tag (i.e.,
> > "Merge tag 'tag'").
>
> Maybe "Merge version 'v1.6.3'" or "Merge commit tagged as 'v1.6.3'"?
> I dunno.
Definitely "Merge version" is bad. Doing "git tag feature-x-working" and
merging it would lead to "Merge version 'feature-x-working'", which
doesn't really make sense. I don't think the developer would refer to
such a tag as a "version".
Your "Merge commit tagged as..." version is reasonable to me. I'm
dubious whether the additional information that it was a tag is actually
worth anything. That is, given
(1) Merge commit '1234abcd'
(2) Merge commit 'v1.6.3'
(3) Merge tag 'v1.6.3'
where (1) is what we do now and will do in the future for arbitrary
commits, (2) is what we do now for tags, and (3) is the proposed change.
I am not sure that (3) really tells the reader anything useful over the
other two. And your "Merge commit tagged as" is just the same
information written slightly differently.
So maybe this patch should simply be dropped. I don't feel strongly
either way.
-Peff
^ permalink raw reply
* Re: [PATCH v4 0/5] Re: {checkout,reset,stash} --patch
From: Thomas Rast @ 2009-08-09 21:42 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Jeff King, git, Junio C Hamano, Sverre Rabbelier,
Nanako Shiraishi
In-Reply-To: <20090809212831.GA12932@vidovic>
Nicolas Sebrecht wrote:
> The 09/08/09, Thomas Rast wrote:
> >
> > Since you can't say 'git reset --hard -- file', you have to do 'git
> > checkout HEAD -- file' to achieve this effect. So this usage is
> > covered by 'git checkout -p HEAD'.
>
> So, we can discard a hunk from the index with 'git reset -p' without
> touching the WT. And we can discard a hunk from the WT with 'git
> checkout -p' without touching the index. But we can't discard a hunk
> from both the index and the WT.
Yes, you can, precisely as I wrote:
> > covered by 'git checkout -p HEAD'.
^^^^
I figured this makes sense:
git checkout -- file # copy file from index to worktree
git checkout -p [file] # copy hunks from index to worktree
git checkout HEAD -- file # copy file from HEAD to index&worktree
git checkout -p HEAD -- file # copy hunks from HEAD to index&worktree
Note that the patch application stage has no guarantees that what you
picked will also apply to the index; it tries first, and if it
doesn't, it asks if it should apply to the worktree anyway (and leave
the index unchanged).
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 0/8] Foreign VCS helpers
From: Johan Herland @ 2009-08-09 21:31 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <alpine.LNX.2.00.0908091525210.27553@iabervon.org>
On Sunday 09 August 2009, Daniel Barkalow wrote:
> This is a replacement for the db/foreign-scm series in pu, now based
> on next. The behavior specified for helpers is the same, so I'm not
> reposting the particular helpers this time.
Thanks. I'll clean up and rebase my CVS series on top of this.
Thanks again for your work. Really appreciated!
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ 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