* [PATCH v2 05/13] Add a config option for remotes to specify a foreign vcs
From: Sverre Rabbelier @ 2009-11-04 19:48 UTC (permalink / raw)
To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
Cc: Daniel Barkalow, Sverre Rabbelier
In-Reply-To: <1257364098-1685-1-git-send-email-srabbelier@gmail.com>
From: Daniel Barkalow <barkalow@iabervon.org>
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.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Unchanged.
Documentation/config.txt | 4 ++++
remote.c | 4 +++-
remote.h | 2 ++
transport.c | 5 +++++
4 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d1e2120..0d9d369 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1408,6 +1408,10 @@ remote.<name>.tagopt::
Setting this value to \--no-tags disables automatic tag following when
fetching from remote <name>
+remote.<name>.vcs::
+ Setting this to a value <vcs> will cause git to interact with
+ the remote with the git-remote-<vcs> helper.
+
remotes.<group>::
The list of remotes which are fetched by "git remote update
<group>". See linkgit:git-remote[1].
diff --git a/remote.c b/remote.c
index 15c9cec..09bb79c 100644
--- a/remote.c
+++ b/remote.c
@@ -54,7 +54,7 @@ static char buffer[BUF_SIZE];
static int valid_remote(const struct remote *remote)
{
- return !!remote->url;
+ return (!!remote->url) || (!!remote->foreign_vcs);
}
static const char *alias_url(const char *url, struct rewrites *r)
@@ -444,6 +444,8 @@ static int handle_config(const char *key, const char *value, void *cb)
} else if (!strcmp(subkey, ".proxy")) {
return git_config_string((const char **)&remote->http_proxy,
key, value);
+ } else if (!strcmp(subkey, ".vcs")) {
+ return git_config_string(&remote->foreign_vcs, key, value);
}
return 0;
}
diff --git a/remote.h b/remote.h
index 5db8420..ac0ce2f 100644
--- a/remote.h
+++ b/remote.h
@@ -11,6 +11,8 @@ struct remote {
const char *name;
int origin;
+ const char *foreign_vcs;
+
const char **url;
int url_nr;
int url_alloc;
diff --git a/transport.c b/transport.c
index 5ae8db6..13bab4e 100644
--- a/transport.c
+++ b/transport.c
@@ -818,6 +818,11 @@ struct transport *transport_get(struct remote *remote, const char *url)
url = remote->url[0];
ret->url = url;
+ if (remote && remote->foreign_vcs) {
+ transport_helper_init(ret, remote->foreign_vcs);
+ return ret;
+ }
+
if (!prefixcmp(url, "rsync:")) {
ret->get_refs_list = get_refs_via_rsync;
ret->fetch = fetch_objs_via_rsync;
--
1.6.5.2.295.g0d105
^ permalink raw reply related
* [PATCH v2 06/13] Allow specifying the remote helper in the url
From: Sverre Rabbelier @ 2009-11-04 19:48 UTC (permalink / raw)
To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
Cc: Johannes Schindelin, Sverre Rabbelier
In-Reply-To: <1257364098-1685-1-git-send-email-srabbelier@gmail.com>
From: Johannes Schindelin <johannes.schindelin@gmx.de>
The common case for remote helpers will be to import some repository
which can be specified by a single URL. Support this use case by
allowing users to say:
git clone hg::https://soc.googlecode.com/hg/ soc
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Reworded commit message to be more neutral.
transport.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/transport.c b/transport.c
index 13bab4e..5d814b5 100644
--- a/transport.c
+++ b/transport.c
@@ -818,6 +818,16 @@ struct transport *transport_get(struct remote *remote, const char *url)
url = remote->url[0];
ret->url = url;
+ /* maybe it is a foreign URL? */
+ if (url) {
+ const char *p = url;
+
+ while (isalnum(*p))
+ p++;
+ if (!prefixcmp(p, "::"))
+ remote->foreign_vcs = xstrndup(url, p - url);
+ }
+
if (remote && remote->foreign_vcs) {
transport_helper_init(ret, remote->foreign_vcs);
return ret;
--
1.6.5.2.295.g0d105
^ permalink raw reply related
* [PATCH v2 03/13] Use a function to determine whether a remote is valid
From: Sverre Rabbelier @ 2009-11-04 19:48 UTC (permalink / raw)
To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
Cc: Daniel Barkalow
In-Reply-To: <1257364098-1685-1-git-send-email-srabbelier@gmail.com>
From: Daniel Barkalow <barkalow@iabervon.org>
Currently, it only checks url, but it will allow other things in the future.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Unchanged.
remote.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/remote.c b/remote.c
index 73d33f2..15c9cec 100644
--- a/remote.c
+++ b/remote.c
@@ -52,6 +52,11 @@ static struct rewrites rewrites_push;
#define BUF_SIZE (2048)
static char buffer[BUF_SIZE];
+static int valid_remote(const struct remote *remote)
+{
+ return !!remote->url;
+}
+
static const char *alias_url(const char *url, struct rewrites *r)
{
int i, j;
@@ -688,14 +693,14 @@ struct remote *remote_get(const char *name)
ret = make_remote(name, 0);
if (valid_remote_nick(name)) {
- if (!ret->url)
+ if (!valid_remote(ret))
read_remotes_file(ret);
- if (!ret->url)
+ if (!valid_remote(ret))
read_branches_file(ret);
}
- if (name_given && !ret->url)
+ if (name_given && !valid_remote(ret))
add_url_alias(ret, name);
- if (!ret->url)
+ if (!valid_remote(ret))
return NULL;
ret->fetch = parse_fetch_refspec(ret->fetch_refspec_nr, ret->fetch_refspec);
ret->push = parse_push_refspec(ret->push_refspec_nr, ret->push_refspec);
--
1.6.5.2.295.g0d105
^ permalink raw reply related
* [PATCH v2 00/13] Reroll of the remote-vcs-helper series
From: Sverre Rabbelier @ 2009-11-04 19:48 UTC (permalink / raw)
To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
Major changes include removal of the cvs specific code as well incorperation
of most of Daniel's comments. For details see the post-triple-dash of the
individual patches.
Daniel, I haven't yet had time to write the 'refspec' part, but that is
something that can definitely go on top of the current series.
Daniel Barkalow (7):
Fix memory leak in helper method for disconnect
Allow programs to not depend on remotes having urls
Use a function to determine whether a remote is valid
Allow fetch to modify refs
Add a config option for remotes to specify a foreign vcs
Add support for "import" helper command
Allow helpers to report in "list" command that the ref is unchanged
Johan Herland (1):
Basic build infrastructure for Python scripts
Johannes Schindelin (1):
Allow specifying the remote helper in the url
Sverre Rabbelier (4):
Write local refs written by the "import" helper command only once
Honour the refspec when updating refs after import
Allow helpers to request the path to the .git directory
Add Python support library for remote helpers
Documentation/config.txt | 4 +
Documentation/git-remote-helpers.txt | 14 +-
Makefile | 51 +++
builtin-clone.c | 8 +-
builtin-fetch.c | 7 +-
builtin-ls-remote.c | 4 +-
builtin-push.c | 68 ++--
configure.ac | 3 +
git_remote_helpers/.gitignore | 2 +
git_remote_helpers/Makefile | 35 ++
git_remote_helpers/__init__.py | 16 +
git_remote_helpers/git/git.py | 678 ++++++++++++++++++++++++++++++++++
git_remote_helpers/setup.py | 17 +
git_remote_helpers/util.py | 194 ++++++++++
remote.c | 15 +-
remote.h | 2 +
t/test-lib.sh | 10 +
transport-helper.c | 99 +++++-
transport.c | 31 ++-
transport.h | 43 ++-
20 files changed, 1253 insertions(+), 48 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/2] Set Makefile variables from configure
From: Ben Walton @ 2009-11-04 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jrnieder, git
In-Reply-To: <7v7hu6gjzz.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]
Excerpts from Junio C Hamano's message of Wed Nov 04 14:36:32 -0500 2009:
> I am a bit puzzled about the "warning" logic. Is this because you expect
> variables we typically give YesPlease/NoThanks as their values will not be
> handled with this new PARSE_WITH_SET_MAKE_VAR() macro?
No, this is because it's perfectly acceptable, in my opinion for a
user to say:
--with-pager=no
or
--with-editor=yes
Neither of those are smart things to do, but they're not necessarily
wrong, either. I'm open to bailing on error for these, but I thought
leaving these as unvalidated, but with a warning, was more
flexible...if say a user wanted to have a pager called 'no' or
something.
For the variables that are accepting YesPlease/NoThanks, I think it's
more suitable to use the standard autoconf header/function/library
detection as it stands now. This macro is more for 'oddball'
variables like DEFAULT_PAGER, DEFAULT_EDITOR, etc that aren't
necessarily easily detectable. In some cases, even if it were
detectable, the detection might not be right.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Set Makefile variables from configure
From: Junio C Hamano @ 2009-11-04 19:36 UTC (permalink / raw)
To: Ben Walton; +Cc: jrnieder, git
In-Reply-To: <1257357960-12763-1-git-send-email-bwalton@artsci.utoronto.ca>
Ben Walton <bwalton@artsci.utoronto.ca> writes:
> Ok, a second attempt, taking into account Jonathan's feedback and
> proposed updates. The revised macro allows for specified help text.
>
> I opted to use a more 'dry' approach to the macro instead of repeating
> the boilerplate AC_WITH_ARG bits when calling this feature.
>
> Additionally, I only WARN when 'yes' or 'no' is passed. Bailing on
> errors in most cases is reasonable, but I don't think it's globally
> appropriate.
>
> As to why I want this...It's cleaner, in my opinion, to do all build
> configuration through a single mechanism than to do most with
> ./configure and the rest with variables passed to make. In other
> words, this is purely a style issue.
Sorry, I wasn't following the discussion primarily because I am totally
uninterested in autoconf myself (it's purely a style issue and using a
single mechanism of echoing into config.mak is just as clean), so allow me
to ask a stupid question that might have been already answered while the
initial round was discussed.
I am a bit puzzled about the "warning" logic. Is this because you expect
variables we typically give YesPlease/NoThanks as their values will not be
handled with this new PARSE_WITH_SET_MAKE_VAR() macro?
^ permalink raw reply
* Re: thoughts on setting core.logAllRefUpdates default true for bare repos
From: Matthieu Moy @ 2009-11-04 19:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sitaram Chamarty, git
In-Reply-To: <alpine.DEB.1.00.0911041422170.2788@felix-maschine>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I did not have time yet to investigate, but it seems that there are
> problems with the permissions of shared bare repositories when activating
> the reflogs.
I can't think of any, and I just tried launching two
while true; do git pull; date > foo.txt ; git add .; git commit -m "xxx"; git push; done
in parallel, with two different users pushing to a --bare --shared
repository, and it did work well. But I may very well have missed
something.
(and actually, if it causes problem, it's an argument in favor of
defaulting to false when core.shared is true, not when core.bare).
Unless I missed something, I think core.logAllRefUpdates should be
enabled for bare repos.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option
From: Junio C Hamano @ 2009-11-04 19:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Christian Couder, git
In-Reply-To: <alpine.LFD.2.01.0911041033530.31845@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 4 Nov 2009, Linus Torvalds wrote:
>>
>> Yes, it is a behavioral change, but is it a bad one?
>
> .. and perhaps we could introduce --bisect-refs as the "old behavior" of
> '--bisect' to git rev-list?
>
> I kind of suspect that it is unlikely that people are using 'git rev-list
> --bisect' while _inside_ a bisection, but then wanting to bisect someting
> that is outside the set of commits we're currently actively bisecting.
>
> But maybe I'm wrong.
Maybe I'm wrong too, but I do not think that is plausible that people are
doing nested bisection that way. It is probably a useful thing to do, but
if somebody has thought of doing so we would have at least seen a request
to add a way to tell "git-bisect" what names to use to record the good/bad
set of commits under to make their implementation easier. I haven't, and
I take it an indication that it is very implausible that such scripts by
people exist to be broken by this change.
I was more worried about people who reinvented the wheel and are using
their own git-bisect.sh derivative. It probably was forked from the
version that still used 'git rev-list --bisect", manually feeding good and
bad set of commits to it from the command line. But then what they are
feeding would be the same as the new --bisect option implicitly gives them
anyway, so there won't be a regression either.
^ permalink raw reply
* Re: Accessing the reflog remotely
From: Matthieu Moy @ 2009-11-04 19:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpjii2ur.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> A distribution point repository like this is often bare, and reflogs are
> not enabled in bare repositories (primarily due to my stupidity^Wbeing
> overly cautious---I was very skeptical about reflogs when we introduced
> it).
Thanks for reminding it (I knew it, but I could very well have
forgotten at the last minute ...) :-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Accessing the reflog remotely
From: Matthieu Moy @ 2009-11-04 19:06 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0911041243350.10340@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> You could checkout the first revision which committer's date is older
> than midnight. Of course that means you have to trust that students
> didn't mess up with time stamps.
Not only that: they could have commited something the day before, and
pushed it the day after. In the particular case I have in mind, the
deliverable is an intermediate one, and we insist a lot on testing, so
the senario is not unlikely: commit dangerous code the day of the
deadline, and push it the day after. So, the reflog is definitely the
answer here.
But thanks anyway!
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Problem signing a tag
From: Joshua J. Kugler @ 2009-11-04 18:47 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Alex Riesen, git
In-Reply-To: <4AF18F7A.2000904@drmicha.warpmail.net>
On Wednesday 04 November 2009, Michael J Gruber said something like:
> > gpg: problem with the agent - disabling agent use
> > error: gpg failed to sign the tag
> > error: unable to sign the tag
> > $ echo $?
> > 128
> >
> > And when I sign at the prompt:
> >
> > $ gpg -sa
> >
> > You need a passphrase to unlock the secret key for
> > user: "Joshua J. Kugler <joshua@azariah.com>"
> > 1024-bit DSA key, ID 14EA086E, created 2009-08-09
> >
> > gpg: problem with the agent - disabling agent use
> > Blah blah blah blah
> > Blah blah blah blah
> > $ echo $?
> > 2
>
> [...]
>
> I assume you don't want to use gpg-agent, that should be the easy way
> out.
Well, I could, but I just haven't set it up. :)
> If that helps you can put "--no-use-agent" in your gpg config.
I commented out use-agent in the config. That worked. THANKS!
> 2 is a non-fatal error, 128 a fatal one, btw.
Well, the 2 was from running gpg alone, and 128 was from git erroring
out. According to the gpg docs:
"The program returns 0 if everything was fine, 1 if at least a signature
was bad, and other error codes for fatal errors."
So, the docs consider 2 a fatal error, even though it appears it isn't.
It seems that
http://github.com/git/git/blob/a6dbf8814f433a7fbfa9cde6333c98019f6db1e4/builtin-tag.c#L202
needs to be patched to something along the lines of:
rv = finish_command(&gpg)
if ((rv && rv !=2) || !len || len < 0)
Probably digging in to the gpg source code to figure out what errors are
and aren't fatal would be in order.
Thanks again for your help! Glad to know what I needed to do to sign my
tags!
j
--
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ ID 0x14EA086E
^ permalink raw reply
* Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option
From: Linus Torvalds @ 2009-11-04 18:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git
In-Reply-To: <alpine.LFD.2.01.0911041030080.31845@localhost.localdomain>
On Wed, 4 Nov 2009, Linus Torvalds wrote:
>
> Yes, it is a behavioral change, but is it a bad one?
.. and perhaps we could introduce --bisect-refs as the "old behavior" of
'--bisect' to git rev-list?
I kind of suspect that it is unlikely that people are using 'git rev-list
--bisect' while _inside_ a bisection, but then wanting to bisect someting
that is outside the set of commits we're currently actively bisecting.
But maybe I'm wrong.
Linus
^ permalink raw reply
* Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option
From: Linus Torvalds @ 2009-11-04 18:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git
In-Reply-To: <7vljimgnaz.fsf@alter.siamese.dyndns.org>
On Wed, 4 Nov 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
>
> > So I suggest to use '--bisect-refs' instead of '--bisect' as the new
> > bisect revision machinery option, because otherwise I think we get a
> > regression when we call "git rev-list --bisect BAD --not GOOD" and we
> > are already bisecting with bisect refs different than BAD and GOOD.
> > This also simplifies the code a little bit.
>
> Just to make sure that I read you correctly, do you mean that Linus now
> would say:
>
> $ git bisect ...
> ... inside bisect session
> $ gitk --bisect-refs arch/x86
I'd really rather prefer to keep '--bisect' for that, it doesn't make
sense to export '--bisect-refs' to be the user-visible switch, and then
have '--bisect' as some internal switch just for 'git rev-list'.
In fact, I'd argue that the ne wbehavior of 'git rev-list' is to some
degree _better_ (ie the existing bad/good ones are implicit while doing
bisection).
Yes, it is a behavioral change, but is it a bad one?
Linus
^ permalink raw reply
* Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option
From: Junio C Hamano @ 2009-11-04 18:25 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <20091104034312.4545.2176.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> So I suggest to use '--bisect-refs' instead of '--bisect' as the new
> bisect revision machinery option, because otherwise I think we get a
> regression when we call "git rev-list --bisect BAD --not GOOD" and we
> are already bisecting with bisect refs different than BAD and GOOD.
> This also simplifies the code a little bit.
Just to make sure that I read you correctly, do you mean that Linus now
would say:
$ git bisect ...
... inside bisect session
$ gitk --bisect-refs arch/x86
^ permalink raw reply
* Re: [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Nicolas Pitre @ 2009-11-04 18:10 UTC (permalink / raw)
To: Andrzej K. Haczewski; +Cc: git, Johannes Sixt
In-Reply-To: <1257350100-29281-1-git-send-email-ahaczewski@gmail.com>
On Wed, 4 Nov 2009, Andrzej K. Haczewski wrote:
> + NO_STATIC_PTHREADS_INIT = YesPlease
Let's not go that route please. If Windows can't get away without
runtime initializations then let's use them on all platforms. There is
no gain in exploding the code path combinations here wrt testing
coverage.
> +static THREAD_RET_TYPE threaded_find_deltas(void *arg)
Why can't you just cast the function pointer in your pthread_create
wrapper instead? No one cares about the returned value anyway.
> @@ -2327,6 +2354,8 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
> #ifdef THREADED_DELTA_SEARCH
> if (!delta_search_threads) /* --threads=0 means autodetect */
> delta_search_threads = online_cpus();
> +
> + init_threaded_delta_search();
What about doing this at the beginning of ll_find_deltas() instead?
And similarly for cleanup_threaded_delta_search(): call it right before
leaving ll_find_deltas(). This way thread issues would remain more
localized. In fact I'd move the whole thing above in ll_find_deltas()
as well (separately from this patch though).
Nicolas
^ permalink raw reply
* Re: [PATCH bg/format-patch-p-noop] log-tree: always add --- marker when options are patch and a stat
From: Junio C Hamano @ 2009-11-04 18:10 UTC (permalink / raw)
To: Jeff King; +Cc: Stephen Boyd, git, Björn Gustavsson
In-Reply-To: <20091104073731.GA15408@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> I don't imagine we want this option in the messaging group though.
>> Can you move it up?
>
> Thanks, good catch. I just tacked it onto the end, forgetting that we
> were using grouping. Junio, can you tweak it, or do you want a resend?
Just ater "no-binary" would be a good place for this to go; done.
^ permalink raw reply
* Re: [PATCH 0/2] Set Makefile variables from configure
From: Ben Walton @ 2009-11-04 18:07 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: gitster, git
In-Reply-To: <20091103222123.GA17097@progeny.tock>
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]
Excerpts from Jonathan Nieder's message of Tue Nov 03 17:21:23 -0500 2009:
> Would the --sysconfdir option work for you here? Setting --sysconfdir
> currently does nothing, so the question is kind of moot without some
> change like this (untested):
I think this is a generally useful patch.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2/2] configure: add settings for gitconfig, editor and pager
From: Ben Walton @ 2009-11-04 18:06 UTC (permalink / raw)
To: gitster, jrnieder, git; +Cc: Ben Walton
In-Reply-To: <1257357960-12763-2-git-send-email-bwalton@artsci.utoronto.ca>
Use the new GIT_PARSE_WITH_SET_MAKE_VAR macro to allow configuration
settings for ETC_GITCONFIG, DEFAULT_PAGER and DEFAULT_EDITOR.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
configure.ac | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index a305d0b..78345eb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -247,6 +247,29 @@ GIT_PARSE_WITH(iconv))
# change being considered an inode change from the update-index perspective.
#
+# Allow user to set ETC_GITCONFIG variable
+GIT_PARSE_WITH_SET_MAKE_VAR(gitconfig, ETC_GITCONFIG,
+ Use VALUE instead of /etc/gitconfig as the
+ global git configuration file.
+ If VALUE is not fully qualified it will be interpretted
+ as a path relative to the computed prefix at runtime.)
+
+#
+# Allow user to set the default pager
+GIT_PARSE_WITH_SET_MAKE_VAR(pager, DEFAULT_PAGER,
+ Use VALUE as the fall-back pager instead of 'less'.
+ This is used by things like 'git log' when the user
+ does not specify a pager to use through alternate
+ methods. eg: /usr/bin/pager)
+#
+# Allow user to set the default editor
+GIT_PARSE_WITH_SET_MAKE_VAR(editor, DEFAULT_EDITOR,
+ Use VALUE as the fall-back editor instead of 'vi'.
+ This is used by things like 'git commit' when the user
+ does not specify a preferred editor through other
+ methods. eg: /usr/bin/editor)
+
+#
# Define SHELL_PATH to provide path to shell.
GIT_ARG_SET_PATH(shell)
#
--
1.6.5.1
^ permalink raw reply related
* [PATCH 1/2] configure: add macro to set arbitrary make variables
From: Ben Walton @ 2009-11-04 18:05 UTC (permalink / raw)
To: gitster, jrnieder, git; +Cc: Ben Walton
In-Reply-To: <1257357960-12763-1-git-send-email-bwalton@artsci.utoronto.ca>
Add macro GIT_PARSE_WITH_SET_MAKE_VAR to configure.ac to allow --with
style options that set values for variables used during the make
process.
Arguments are the $name part of --with-$name, the name of
the variable to set in the Makefile (config.mak.autogen) and
the help text for the option.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
configure.ac | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 84b6cf4..a305d0b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -68,6 +68,26 @@ else \
GIT_CONF_APPEND_LINE(${PACKAGE}DIR=$withval); \
fi \
])# GIT_PARSE_WITH
+#
+# GIT_PARSE_WITH_SET_MAKE_VAR(WITHNAME, VAR, HELP_TEXT)
+# ---------------------
+# Set VAR to the value specied by --with-WITHNAME.
+# No verification of arguments is performed, but warnings are issued
+# if either 'yes' or 'no' is specified.
+# HELP_TEXT is presented when --help is called.
+# This is a direct way to allow setting variables in the Makefile.
+AC_DEFUN([GIT_PARSE_WITH_SET_MAKE_VAR],
+[AC_ARG_WITH([$1],
+ [AS_HELP_STRING([--with-$1=VALUE], $3)],
+ if test -n "$withval"; then \
+ if test "$withval" = "yes" -o "$withval" = "no"; then \
+ AC_MSG_WARN([You likely do not want either 'yes' or 'no' as]
+ [a value for $1 ($2). Maybe you do...?]); \
+ fi; \
+ \
+ AC_MSG_NOTICE([Setting $2 to $withval]); \
+ GIT_CONF_APPEND_LINE($2=$withval); \
+ fi)])# GIT_PARSE_WITH_SET_MAKE_VAR
dnl
dnl GIT_CHECK_FUNC(FUNCTION, IFTRUE, IFFALSE)
--
1.6.5.1
^ permalink raw reply related
* [PATCH 0/2] Set Makefile variables from configure
From: Ben Walton @ 2009-11-04 18:05 UTC (permalink / raw)
To: gitster, jrnieder, git; +Cc: Ben Walton
In-Reply-To: <20091103222123.GA17097@progeny.tock>
Ok, a second attempt, taking into account Jonathan's feedback and
proposed updates. The revised macro allows for specified help text.
I opted to use a more 'dry' approach to the macro instead of repeating
the boilerplate AC_WITH_ARG bits when calling this feature.
Additionally, I only WARN when 'yes' or 'no' is passed. Bailing on
errors in most cases is reasonable, but I don't think it's globally
appropriate.
As to why I want this...It's cleaner, in my opinion, to do all build
configuration through a single mechanism than to do most with
./configure and the rest with variables passed to make. In other
words, this is purely a style issue.
I like the extension of config.mak.in to support more of the autoconf
variables as well and would like to see it applied.
Ben Walton (2):
configure: add macro to set arbitrary make variables
configure: add settings for gitconfig, editor and pager
configure.ac | 43 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 43 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: Automatically remote prune
From: Junio C Hamano @ 2009-11-04 18:04 UTC (permalink / raw)
To: John Tapsell; +Cc: Git List
In-Reply-To: <43d8ce650911040242l44bbf87dm35494e04ce9039aa@mail.gmail.com>
John Tapsell <johnflux@gmail.com> writes:
> $> git branch -r
> origin/blah1 [Deleted]
> origin/blah2
>
> (Some branches have been deleted on the remote server. Use "git
> remote prune origin" to remove these)
There is no information locally available to do this, unless you are
willing to contact the remote every time somebody says "branch -r" (or
"branch -a"). I tend to think it is not very nice for the branch command
that has long been a "local" command to suddenly start talking to outside
world.
You could store necessary information somewhere else when you contacted
the remote the last time, but we need to consider what the benefits are to
give this information in the first place.a
The [Deleted] mark in your suggestion tells the user:
This is already removed in the remote, and this tracking copy is the
only way for you to view it ever again. Do not run 'remote prune
origin' blindly otherwise you will lose it.
But that is already possible with "git remote show origin", isn't it?
^ permalink raw reply
* Re: Accessing the reflog remotely
From: Junio C Hamano @ 2009-11-04 18:03 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqljimpr95.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> I guess the answer is "no", but I'll still ask in case ...
>
> Is it possible to access the reflog of a remote repository other than
> logging into this repository?
>
> My use-case is the following: I want to checkout "the last revision
> pushed in master on ssh://host/repo/ on day D at midnight" (to fetch
> the project of my students ;-) ). If it were locally, I'd do
This won't solve your problem but I'll mention it anyway as it may be
related.
A distribution point repository like this is often bare, and reflogs are
not enabled in bare repositories (primarily due to my stupidity^Wbeing
overly cautious---I was very skeptical about reflogs when we introduced
it). It may make sense to enable reflogs everywhere by default in some
major version bump.
Also a distribution point repository is often served by gitweb and it
would be really nice if there were an option to allow its summary view
to show commits annotated with reflog entries, e.g.
----------------------------------------------------------------
2 days ago JCH Merge branch 'maint'
(pushed 6 hrs ago)
----------------------------------------------------------------
2 days ago DVL Makefile: add compat/bswap.h to LIB_H
----------------------------------------------------------------
3 days ago JCH Revert "Don't create the $GIT_DIR/branches directory on init"
(pushed 60 hours ago)
----------------------------------------------------------------
4 days ago JCH fixup tr/stash-format merge
----------------------------------------------------------------
...
^ permalink raw reply
* Re: [PATCH] gitk: disable checkout of remote branch
From: Junio C Hamano @ 2009-11-04 18:03 UTC (permalink / raw)
To: Jeff King; +Cc: Sverre Rabbelier, Tim Mazid, git
In-Reply-To: <20091104072709.GC24263@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 04, 2009 at 07:41:28AM +0100, Sverre Rabbelier wrote:
>
>> On Wed, Nov 4, 2009 at 07:17, Tim Mazid <timmazid@hotmail.com> wrote:
>> > So instead of invoking 'git checkout REMOTE/BRANCH', do 'git checkout -b
>> > BRANCH REMOTE/BRANCH'.
>>
>> Automagically doing 'git checkout -t remote/branch' when asked to do
>> 'git checkout remote/branch' was suggested earlier on the list and I
>> think there was even a patch that implemented it, not sure what the
>> outcome of the series was. I do remember that Peff was annoyed by it
>> at the GitTogether though so it might be a bad idea.
>
> It's in 'next' now.
Isn't it quite different? What's in 'next' for 1.7.0 is to guess the
user's intention when:
- he says 'git checkout BRANCH'; and
- BRANCH does not yet exist; and
- BRANCH does not name a commit so the request cannot be to detach HEAD
at some commit (like REMOTE/BRANCH); and
- there is a unique REMOTE that has BRANCH.
The user wants to check out his own BRANCH (the request lacks REMOTE to
start with) but such a branch does not exist yet, and there is only one
sensible commit to start that new branch, hence we DWIM it and helpfully
run "git branch -t BRANCH REMOTE/BRANCH" automatically before performing
"git checkout BRANCH" that was asked.
We never claim to allow checking out the remote tracking branch itself.
The new guessing is only about a local branch that does not exist yet.
> ... I am still not convinced that we won't later regret leaving the
> stale local branch sitting around, or that users won't find it confusing
> to see:
>
> $ git checkout foo
> Branch foo set up to track remote branch foo from origin.
> Switched to a new branch 'foo'
>
> ... time passes ...
>
> $ git checkout foo
> Switched to branch 'foo'
> Your branch is behind 'origin/foo' by 1 commit, and can be fast-forwarded.
>
> (i.e., you do the same thing, but get two very different results,...
I think this is primarily because the way this DWIM is totally silent in
the transcript is misleading. If you explain it the way I outlined above,
I do not think there is any confusion. That is, there is no way for the
user to get confused if the command sequence were like so:
$ git branch -t foo origin/foo
Branch foo set up to track remote branch foo from origin.
$ git checkout foo
Switched to a new branch 'foo'
... time passes ...
$ git checkout foo
Switched to branch 'foo'
Your branch is behind 'origin/foo' by 1 commit, and can be fast-forwarded.
It could just be a matter of telling what we are doing a bit more
explicitly when this DWIM kicks in. How about this?
$ git checkout foo
(first forking your own 'foo' from 'origin/foo')
Branch foo set up to track remote branch foo from origin.
Switched to a new branch 'foo'
In any case, I do not think the DWIM would kick in when you try to detach
at remote branch head. I did not check gitk code to find out the exact
command line it uses, but I do not think it runs "checkout BRANCH". The
command needs to be at least "checkout REMOTE/BRANCH" to work the way it
does now with any released version of git, and I would not be surprised if
paulus was cautious enough to have spelled it as "refs/REMOTE/BRANCH" to
avoid any potential ambiguity issues.
^ permalink raw reply
* Re: [PATCH v2] format-patch: autonumber by default
From: Brian Gernhardt @ 2009-11-04 17:48 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Git List, Giuseppe Bilotta, Jakub Narebski, Johannes Schindelin,
Shawn O. Pearce, Andreas Ericsson
In-Reply-To: <m1ws261qqi.fsf@fess.ebiederm.org>
On Nov 4, 2009, at 6:20 AM, Eric W. Biederman wrote:
> Grumble. I updated git last night and this change just bit me.
> Grumble.
> Grumble.
>
> It is probably a good change, but it was unexpected.
> Grumble. Grumble. Grumble.
The change is a year old, and mentioned in the release notes from
1.6.1. If you're updating from old versions of git, it can be
extremely useful to read the release notes as we do periodically have
changes like this. (In the git repository, they can be found as
Documentation/RelNotes-*.txt)
If you wish to go back to the old default for a single project, use
`git config format.numbered false`. If you use the --global flag, it
will set it for you all the time. For a single set of unrelated
patches being output at once, use the --no-numbered (short: -N) option
to format-patch.
Sorry it caught you unawares. Having it auto-number seemed like the
most useful default.
~~ Brian
^ permalink raw reply
* Re: Accessing the reflog remotely
From: Sverre Rabbelier @ 2009-11-04 17:55 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqljimpr95.fsf@bauges.imag.fr>
Heya,
On Wed, Nov 4, 2009 at 10:35, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> My use-case is the following: I want to checkout "the last revision
> pushed in master on ssh://host/repo/ on day D at midnight" (to fetch
> the project of my students ;-) ). If it were locally, I'd do
I think your best bet here would be to either run a cronjob at the
target time that tags all submissions, or to deny pushes after the
target time with a pre-push hook.
--
Cheers,
Sverre Rabbelier
^ 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