* Re: [RFC/PATCH] Use compatibility regex library for OSX/Darwin
From: Brandon Casey @ 2008-09-16 17:49 UTC (permalink / raw)
To: Arjen Laarhoven
Cc: git, Mike Ralphson, Johannes Sixt, Jeff King, Junio C Hamano
In-Reply-To: <20080907184537.GA4148@regex.yaph.org>
Arjen Laarhoven wrote:
> The standard libc regex library on OSX does not support alternation
> in POSIX Basic Regular Expression mode. This breaks the diff.funcname
> functionality on OSX.
>
> To fix this, we use the GNU regex library which is already present in
> the compat/ diretory for the MinGW port. However, simply adding compat/
> to the COMPAT_CFLAGS variable causes a conflict between the system
> fnmatch.h and the one present in compat/. To remedy this, move the
> regex and fnmatch functionality to their own subdirectories in compat/
> so they can be included seperately.
I wonder if this is the right fix? Right now the GNU regex library is
necessary for Darwin, FreeBSD and AIX. I can add IRIX6.5 and Solaris 7
to that list. Have newer Solaris's been tested yet? (Jeff?) I wonder if
the new test which triggers this flaw has been tested on the other
non-GNU platforms in the Makefile which have not been updated. Boyd
Lynn Gerber and his 12 platforms comes to mind.
It seems POSIX only mentions alternation under Extended Regular Expressions.
Likewise for the vertical-line character '|'.
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_04_07
A look at compat/regex/regex.c: line 4723 shows that the default mode is
RE_SYNTAX_POSIX_BASIC.
>From the description in regex.h this mode includes "...bits common to both
basic and extended POSIX regex syntax". It seems this mode allows backslashed
versions of the extended regular expression operators ?, +, and |.
Other platforms which adhere more strictly to the POSIX spec do not interpret
the backslashed Ext-RE operators in Basic Regular Expression mode. Similar
to GNU RE_SYNTAX_POSIX_MINIMAL_BASIC.
If I'm interpreting things correctly, then all non-GNU platforms may need the
compat regex library.
On a related note: Is there any reason why extended regular expressions
were not used by default? Wouldn't they have looked prettier (fewer backslashes)?
It's too late to change diff.*.funcname now, but an alternative fix which would
probably not require every other platform to use GNU regex, is to introduce a
new funcname option which would allow extended regular expression syntax and to
convert the internal regular expressions to that format.
-brandon
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: Daniel Barkalow @ 2008-09-16 17:32 UTC (permalink / raw)
To: David Brown; +Cc: Junio C Hamano, dhruva, GIT SCM, Simon Hausmann
In-Reply-To: <alpine.LNX.1.00.0809161211440.19665@iabervon.org>
On Tue, 16 Sep 2008, Daniel Barkalow wrote:
> p4 keeps track of which revision of each file you have synced to in your
> client (so that it can fail to update it sometimes, as you mention above),
> and will complain if the synced-to version isn't the latest when you try
> to submit. That's how it avoids having people accidentally back out each
> other's changes in ordinary operation. As long as we can be sure that the
> client hasn't been synced to a later version than what the parent of the
> commit we're submitting is an import of, which should be done with "p4
> sync <changenumber>", rather than trying to spot check for having
> accidentally acknowledged more p4 history than we've accounted for.
That is, "p4 sync <path>@<change>", of course.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: Daniel Barkalow @ 2008-09-16 17:26 UTC (permalink / raw)
To: dhruva; +Cc: David Brown, Junio C Hamano, GIT SCM, Simon Hausmann
In-Reply-To: <98627.82548.qm@web95002.mail.in2.yahoo.com>
On Tue, 16 Sep 2008, dhruva wrote:
> Hi,
>
>
>
> ----- Original Message ----
> > From: David Brown <git@davidb.org>
> > Part of the problem is that p4 isn't very good at knowing whether
> > files have changed or not. 'p4 sync' will update the file _if_ if
> > thinks your version is out of date, but it does nothing if someone has
> > locally modified the file, hence the need for the 'p4 sync -f'.
>
> If you have modified a file without doing a 'p4 edit' and if there is a
> new version of the edited file on p4 (from what you have got from a
> previous 'p4 sync'), 'p4 sync' will overwrite your changes (if the file
> does not have write perm set or if you have enabled clobbering of
> writable files). Whereas 'p4 sync -f' will always overwrite all unopened
> files if a newer version is available.
p4 sync -f will overwrite all unopened files. It will clobber writable
files, and it will clobber files where there isn't a newer file (it's one
of the ways of dealing with accidentally erasing your workspace).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: Daniel Barkalow @ 2008-09-16 17:12 UTC (permalink / raw)
To: David Brown; +Cc: Junio C Hamano, dhruva, GIT SCM, Simon Hausmann
In-Reply-To: <20080916041201.GA25033@linode.davidb.org>
On Mon, 15 Sep 2008, David Brown wrote:
> On Mon, Sep 15, 2008 at 03:22:33PM -0400, Daniel Barkalow wrote:
>
> >I think the right solution is for git-p4 to check that p4 thinks the file is
> >the correct file and then simply replace it rather than trying to generate
> >the right result by patching. To be a bit more careful, git-p4 could check
> >that the contents it's replacing actually would exactly match the git
> >contents if the keywords were callapsed (if the p4 setting is to use keywords
> >in this file).
>
> Part of the problem is that p4 isn't very good at knowing whether
> files have changed or not. 'p4 sync' will update the file _if_ if
> thinks your version is out of date, but it does nothing if someone has
> locally modified the file, hence the need for the 'p4 sync -f'.
I think losing those changes are what we're trying to be careful to avoid.
What matter for making the submission correctly is that p4 think that your
version is the version you want to replace, and that the file contents are
what you want it to end up with.
> A simple way to be paranoid would be something (shell-ish) like:
>
> p4 print filename | collapse-keywords | git hash-object --stdin
>
> and make sure that is the version we think the file should have
> started with. I think we're really just making sure we didn't miss a
> P4 change that someone else made underneath, and we're about to back
> out.
p4 keeps track of which revision of each file you have synced to in your
client (so that it can fail to update it sometimes, as you mention above),
and will complain if the synced-to version isn't the latest when you try
to submit. That's how it avoids having people accidentally back out each
other's changes in ordinary operation. As long as we can be sure that the
client hasn't been synced to a later version than what the parent of the
commit we're submitting is an import of, which should be done with "p4
sync <changenumber>", rather than trying to spot check for having
accidentally acknowledged more p4 history than we've accounted for.
> Even this isn't robust from p4's point of view. The p4 model is to do
> a 'p4 edit' on the file, and then the later 'p4 submit' will give an
> error if someone else has updated the file. This would require using
> p4's conflict resolution, and I'm guessing someone using git-p4 would
> rather abort the submit and rebase.
p4 doesn't let you submit files that you don't do a "p4 edit" on (or an
equivalent like add), so we can't help but do it correctly (assuming that
we haven't synced to a later version that the parent, of course). If you
get an error on the submit, you just revert everything you editted, rebase
the git side, and try again (sync to the new parent of the git commit,
edit the files, replace with the git content, and submit).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git User's Survey 2008 partial summary, part 5 - other SCM
From: Jakub Narebski @ 2008-09-16 17:12 UTC (permalink / raw)
To: David Lang; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.DEB.1.10.0809142038190.19489@asgard.lang.hm>
On Mon, 15 Sep 2008, David Lang <david@lang.hm> napisał:
> On Sun, 14 Sep 2008, Nguyen Thai Ngoc Duy wrote:
>> On 9/12/08, Jakub Narebski <jnareb@gmail.com> wrote:
>>> 15) Do you miss features in git that you know from other SCMs?
>>> If yes, what features are these (and from which SCM)?
>>> (Open ended text - Essay)
>>>
>>> Total respondents 1046 (some/many of them wrote 'no')
>>> skipped this question 1249
>>>
>>> This is just a very quick summary, based on a first few pages of
>>> responses, Full analysis is I think best left for after closing the
>>> survey, because I think this would be a lot of work...
>>>
>>> So here is preliminary list, or rather beginning of one:
>>> * sparse/partial checkout and clone (e.g. Perforce)
>>
>> Have not read the survey result, but do you recall what is the most
>> used term for sparse/partial checkout? What SCMs do sparse/partial
>> checkout? I think it could be usable as it is now in my
>> will-be-sent-again series, but I don't really know how people want it
>> to from that.
>
> the most common use-case is people who want to follow a project but
> (at least think that they) don't need the history. so they want to
> save time/bandwideth/disk space by not downloading things they don't
> need.
Errr... the idea is to implement partial (sparse, narrow) _checkout_,
which is doable, not partial/lazy _clone_, which is very, very
difficult.
Partial checkout *might* help reduce disk space because usually
repository database (which is compressed and deltaified) is smaller
than checkout; and if it isn't you can always use _shallow_ clone (only
part of history) and/or remote alternates (with reference repository
not on your quota, or on different filesystem). And it might help
checkout/commit/diff/status times (performance) on slow filesystems,
with extremely large number of files in full checkout. But contrary to
centralized SCM, where server is usually net away from working area,
partial checkout doesn't affect network usage _at all_.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 16/16] ls-files: add --overlay option
From: Junio C Hamano @ 2008-09-16 17:00 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0809160500y4b67c621g45b0c6ddf3745a84@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>> By the way, I do not see an easy way to review what paths are marked with
>> no-checkout easily from your command set. It might be worthwhile to add a
>> new option that iterates over the index, finds a set of common prefixes to
>> no-checkout entries and reports that set.
>
> What is it for? I can only think of it (actually the opposite, find a
> set of common prefixes to checkout entries) as a way to reconstruct
> narrow spec (simple rules only).
That's the list you can use as input to "find $them -type f" to see what
stale files from previous unnarrowed checkout are on the filesystem.
I agree that the opposite is also interesting and could be useful. Only
the individual index entries remember the area the user told us to check
out, and I expect that "what's my narrow area right now?" would be a
common question users may want to ask. A full answer can be obtained with
ls-files --narrow, but if we can summarize it into a more concise form, it
would be a useful thing to do.
^ permalink raw reply
* Re: [PATCH] Documentation: replace [^~] with escapes everywhere
From: Junio C Hamano @ 2008-09-16 16:48 UTC (permalink / raw)
To: git; +Cc: Avery Pennarun, Thomas Rast
In-Reply-To: <32541b130809160858k3c019f6pdc4831c831e22b55@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> Hmm, browsing around through a newer asciidoc package from Ubuntu, it
> appears that in asciidoc 8, those lines are in an
> "ifdef::asciidoc7compatible[]" section. But the quoting mechanism in
> 8 appears to be improved.
>
> Perhaps a section like this (guessing from the new
> /etc/asciidoc/asciidoc.conf) will do the job instead (or in addition,
> if we're trying to support both versions):
>
> [quotes]
> ^=
> ~=
Ok, how about this patch? I do not have an access to the box with
AsciiDoc 8 handy right now, so I cannot test this myself, but there must
be somebody on the list who can give a quick test to this.
The procedure would be:
$ cd Documentation
$ rm -fr ./+old ./+new && mkdir ./+old ./+new
$ make git-{bundle,show-ref}.{html,1}
$ mv git-{bundle,show-ref}.{html,1} ./+old
$ git apply < this-patch
$ make git-{bundle,show-ref}.{html,1}
$ mv git-{bundle,show-ref}.{html,1} ./+new
$ git diff --no-index --color-words ./+old ./+new
Then eyeball the output, ignoring the timestamps and see if <sup>/<sub>
disappears and there is no other change. Other documentation pages should
also be verified, but these two are I know of with the issue.
diff --git i/Documentation/asciidoc.conf w/Documentation/asciidoc.conf
index 40d43b7..36b6509 100644
--- i/Documentation/asciidoc.conf
+++ w/Documentation/asciidoc.conf
@@ -15,6 +15,21 @@ startsb=[
endsb=]
tilde=~
+[replacements]
+# Disable superscripts.
+\^(.+?)\^=^\1^
+# Disable subscripts.
+~(.+?)~=~\1~
+
+# We define asciidoc7compatible macro when running with AsciiDoc 8;
+# this ifdef protects the "empty" quotes rule that AsciiDoc 7 does
+# not know how to handle.
+ifdef::asciidoc7compatible[]
+[quotes]
+^=
+~=
+endif::asciidoc7compatible[]
+
ifdef::backend-docbook[]
[linkgit-inlinemacro]
{0%{target}}
^ permalink raw reply related
* Re: [PATCH] Documentation: replace [^~] with escapes everywhere
From: Junio C Hamano @ 2008-09-16 16:34 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Thomas Rast, git
In-Reply-To: <32541b130809160858k3c019f6pdc4831c831e22b55@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> Hmm, browsing around through a newer asciidoc package from Ubuntu, it
> appears that in asciidoc 8, those lines are in an
> "ifdef::asciidoc7compatible[]" section. But the quoting mechanism in
> 8 appears to be improved.
Yeah, the thing is that we cannot say "ifdef::asciidoc7compatible[]"
and feed it to asciidoc7 X-<.
^ permalink raw reply
* Re: git-branch manpage question
From: Michael J Gruber @ 2008-09-16 16:25 UTC (permalink / raw)
To: Mark Struberg; +Cc: git
In-Reply-To: <957350.34177.qm@web27803.mail.ukl.yahoo.com>
Mark Struberg venit, vidit, dixit 16.09.2008 16:46:
> Hi!
>
> I think i found an inconsistency in the documentation of the
> git-branch command:
>
> *snip* --track:: .... Set the branch.autosetupmerge configuration
> variable to `false` if you want 'git-checkout' and 'git-branch' to
> always behave as if '--no-track' were given... *snip*
>
> and
>
> *snip* --no-track:: Ignore the branch.autosetupmerge configuration
> variable.
>
> *snip*
>
> So, the description of branch.autosetupmerge is referencing
> --no-track and vice versa, thus the effective documentation is
> essentially missing as far as I understand.
Well, what's missing is the explanation that "--no-track" is the
opposite of "--track". Do we really need to stress that?
The explanation of "--track" is in the "....", you left it out in your
quote.
Maybe the formulation is a bit suboptimal because it's squeezed more or
less forcibly into the option list concept. At "--track" there is a
description of what is meant by a tracking branch configuration. Now,
the logical flow is:
If --track is given, set up tracking.
If --no-track is given, don't set up tracking.
If none is given, check branch.autosetupmerge:
If it is false, don't set up tracking.
If it is always, set up tracking.
If it is unset (or true), check what kind of start point we branch off from:
If it is a remote, set up tracking.
If it is not a remote, don't set up tracking.
Admittedly, the description at --track is a bit contrived. But if you
read the DESCRIPTION section before the options things should become
clear. Maybe git-branch(1) should reference git-config(1).
Cheers,
Michael
^ permalink raw reply
* Re: Management of opendocument (openoffice.org) files in git
From: Avery Pennarun @ 2008-09-16 16:04 UTC (permalink / raw)
To: Sergio Callegari; +Cc: Johannes Sixt, git
In-Reply-To: <48CF630F.4090808@gmail.com>
On Tue, Sep 16, 2008 at 3:41 AM, Sergio Callegari
<sergio.callegari@gmail.com> wrote:
> Johannes Sixt wrote:
>>
>> You don't need a temporay zip filename in filter mode:
>>
>> unzip $UNZIP_OPTS /dev/stdin # works for me, but not 100% portable
>> zip $ZIP_OPTS - . # writes to stdout
>>
>>
>
> The unzip documentation says "Archives read from standard input are not yet
> supported", so I was a bit worried about using the /dev/stdin thing. Might
> it be that there are subtle cases where unzip needs to seek or rewind?
IIRC zip files keep their index at the end of the file, which means
zipping in a pipeline is efficient (you can write all the blocks
first, then drop the final index at the end) but unzipping that way is
really hard.
unzipping from /dev/stdin seems to work if stdin is seekable, otherwise not.
unzip /dev/stdin <filename.zip # works
cat filename.zip | unzip /dev/stdin # doesn't work
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] Documentation: replace [^~] with escapes everywhere
From: Avery Pennarun @ 2008-09-16 15:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7vy71s7b26.fsf@gitster.siamese.dyndns.org>
On Tue, Sep 16, 2008 at 4:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Sorry, but this unfortunately does not seem to help asciidoc 8.2.5 on FC9
> at all, which is the combination used at k.org machine that feeds the
> html/man branches to everybody else.
>
> asciidoc 7.1.2 on Deb does not have the problem in git-bundle.html to
> begin with, but it does have the same issue in git-show-ref.html, which
> the patch does fix.
>
> diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
> index 40d43b7..8fcdb54 100644
> --- a/Documentation/asciidoc.conf
> +++ b/Documentation/asciidoc.conf
> @@ -15,6 +15,12 @@ startsb=[
> endsb=]
> tilde=~
>
> +[replacements]
> +# Disable superscripts.
> +\^(.+?)\^=^\1^
> +# Disable subscripts.
> +~(.+?)~=~\1~
> +
> ifdef::backend-docbook[]
> [linkgit-inlinemacro]
> {0%{target}}
Hmm, browsing around through a newer asciidoc package from Ubuntu, it
appears that in asciidoc 8, those lines are in an
"ifdef::asciidoc7compatible[]" section. But the quoting mechanism in
8 appears to be improved.
Perhaps a section like this (guessing from the new
/etc/asciidoc/asciidoc.conf) will do the job instead (or in addition,
if we're trying to support both versions):
[quotes]
^=
~=
HTH. I don't have a real system with asciidoc 8 installed, and now's
not a good time to risk breaking my asciidoc setup, so I definitely
can't test the above.
Have fun,
Avery
^ permalink raw reply
* [JGIT PATCH 2/2] Add support for ~/.ssh/config BatchMode
From: Shawn O. Pearce @ 2008-09-16 15:44 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1221579869-27835-1-git-send-email-spearce@spearce.org>
Connections created through batch processes (e.g. those started by
cron) don't have a terminal to interact with a user through. A
common way to disable password prompting with OpenSSH is to setup
a Host block in ~/.ssh/config with "BatchMode yes" enabled, thus
telling the client not to prompt for passphases or passwords.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../spearce/egit/ui/EclipseSshSessionFactory.java | 2 +-
.../spearce/jgit/transport/OpenSshConfigTest.java | 21 +++++++++++++++++++
.../jgit/transport/DefaultSshSessionFactory.java | 2 +-
.../org/spearce/jgit/transport/OpenSshConfig.java | 22 ++++++++++++++++++++
4 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java
index 67c5f16..098d234 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java
@@ -48,7 +48,7 @@ public Session getSession(String user, String pass, String host, int port)
addIdentity(hc.getIdentityFile());
if (pass != null)
session.setPassword(pass);
- else
+ else if (!hc.isBatchMode())
new UserInfoPrompter(session);
final String pauth = hc.getPreferredAuthentications();
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java
index 1a71d08..959b6b7 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java
@@ -148,4 +148,25 @@ config("Host orcz\n" + "\tHostName repo.or.cz\n" + "\n" + "Host *\n"
assertNotNull(h);
assertEquals("publickey,hostbased", h.getPreferredAuthentications());
}
+
+ public void testAlias_BatchModeDefault() throws Exception {
+ final Host h = osc.lookup("orcz");
+ assertNotNull(h);
+ assertEquals(false, h.isBatchMode());
+ }
+
+ public void testAlias_BatchModeYes() throws Exception {
+ config("Host orcz\n" + "\tBatchMode yes\n");
+ final Host h = osc.lookup("orcz");
+ assertNotNull(h);
+ assertEquals(true, h.isBatchMode());
+ }
+
+ public void testAlias_InheritBatchMode() throws Exception {
+ config("Host orcz\n" + "\tHostName repo.or.cz\n" + "\n" + "Host *\n"
+ + "\tBatchMode yes\n");
+ final Host h = osc.lookup("orcz");
+ assertNotNull(h);
+ assertEquals(true, h.isBatchMode());
+ }
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java b/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java
index b6f58f0..89beab7 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java
@@ -101,7 +101,7 @@ public synchronized Session getSession(String user, String pass,
addIdentity(hc.getIdentityFile());
if (pass != null)
session.setPassword(pass);
- else
+ else if (!hc.isBatchMode())
session.setUserInfo(new AWT_UserInfo());
final String pauth = hc.getPreferredAuthentications();
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java b/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
index 2f41e56..df38e18 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
@@ -224,6 +224,10 @@ else if (sp < 0)
for (final Host c : current)
if (c.preferredAuthentications == null)
c.preferredAuthentications = nows(dequote(argValue));
+ } else if ("BatchMode".equalsIgnoreCase(keyword)) {
+ for (final Host c : current)
+ if (c.batchMode == null)
+ c.batchMode = yesno(dequote(argValue));
}
}
@@ -260,6 +264,12 @@ private static String nows(final String value) {
return b.toString();
}
+ private static Boolean yesno(final String value) {
+ if ("yes".equalsIgnoreCase(value))
+ return Boolean.TRUE;
+ return Boolean.FALSE;
+ }
+
private File toFile(final String path) {
if (path.startsWith("~/"))
return new File(home, path.substring(2));
@@ -293,6 +303,8 @@ private File toFile(final String path) {
String preferredAuthentications;
+ Boolean batchMode;
+
void copyFrom(final Host src) {
if (hostName == null)
hostName = src.hostName;
@@ -304,6 +316,8 @@ void copyFrom(final Host src) {
user = src.user;
if (preferredAuthentications == null)
preferredAuthentications = src.preferredAuthentications;
+ if (batchMode == null)
+ batchMode = src.batchMode;
}
/**
@@ -342,5 +356,13 @@ public String getUser() {
public String getPreferredAuthentications() {
return preferredAuthentications;
}
+
+ /**
+ * @return true if batch (non-interactive) mode is preferred for this
+ * host connection.
+ */
+ public boolean isBatchMode() {
+ return batchMode != null && batchMode.booleanValue();
+ }
}
}
--
1.6.0.2.389.g421e0
^ permalink raw reply related
* [JGIT PATCH 1/2 v2] Add support for ~/.ssh/config PreferredAuthentications
From: Shawn O. Pearce @ 2008-09-16 15:44 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
Some configurations may wish to disable interactive methods of
authentication, such as when running from automated cron or batch
style jobs that have no user available.
Typically in an OpenSSH based system this would be configured on a
per-host basis in the current user's ~/.ssh/config file, by setting
PreferredAuthentications to the list of authentication methods
(e.g. just "publickey") that are reasonable.
JSch honors this configuration setting, but we need to transfer it
from our own OpenSshConfig class, otherwise it has no knowledge of
the setting.
http://code.google.com/p/egit/issues/detail?id=33
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This replaces my earlier patch of the same title from about 14
hours ago. This v2 patch actually parses the data from the
config file and includes unit tests to verify it is parsing.
.../spearce/egit/ui/EclipseSshSessionFactory.java | 4 +++
.../spearce/jgit/transport/OpenSshConfigTest.java | 22 ++++++++++++++++-
.../jgit/transport/DefaultSshSessionFactory.java | 4 +++
.../org/spearce/jgit/transport/OpenSshConfig.java | 25 ++++++++++++++++++++
4 files changed, 54 insertions(+), 1 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java
index 640a165..67c5f16 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java
@@ -50,6 +50,10 @@ public Session getSession(String user, String pass, String host, int port)
session.setPassword(pass);
else
new UserInfoPrompter(session);
+
+ final String pauth = hc.getPreferredAuthentications();
+ if (pauth != null)
+ session.setConfig("PreferredAuthentications", pauth);
return session;
}
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java
index a250f9d..1a71d08 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/transport/OpenSshConfigTest.java
@@ -103,7 +103,6 @@ config("Host orcz\n" + "\tHostName repo.or.cz\n" + "\tPort 2222\n"
assertEquals(new File(home, ".ssh/id_jex"), h.getIdentityFile());
}
-
public void testAlias_OptionsKeywordCaseInsensitive() throws Exception {
config("hOsT orcz\n" + "\thOsTnAmE repo.or.cz\n" + "\tPORT 2222\n"
+ "\tuser jex\n" + "\tidentityfile .ssh/id_jex\n"
@@ -128,4 +127,25 @@ config("Host orcz\n" + "\tHostName repo.or.cz\n" + "\n" + "Host *\n"
assertEquals(2222, h.getPort());
assertEquals(new File(home, ".ssh/id_jex"), h.getIdentityFile());
}
+
+ public void testAlias_PreferredAuthenticationsDefault() throws Exception {
+ final Host h = osc.lookup("orcz");
+ assertNotNull(h);
+ assertNull(h.getPreferredAuthentications());
+ }
+
+ public void testAlias_PreferredAuthentications() throws Exception {
+ config("Host orcz\n" + "\tPreferredAuthentications publickey\n");
+ final Host h = osc.lookup("orcz");
+ assertNotNull(h);
+ assertEquals("publickey", h.getPreferredAuthentications());
+ }
+
+ public void testAlias_InheritPreferredAuthentications() throws Exception {
+ config("Host orcz\n" + "\tHostName repo.or.cz\n" + "\n" + "Host *\n"
+ + "\tPreferredAuthentications publickey, hostbased\n");
+ final Host h = osc.lookup("orcz");
+ assertNotNull(h);
+ assertEquals("publickey,hostbased", h.getPreferredAuthentications());
+ }
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java b/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java
index 74fca66..b6f58f0 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java
@@ -103,6 +103,10 @@ public synchronized Session getSession(String user, String pass,
session.setPassword(pass);
else
session.setUserInfo(new AWT_UserInfo());
+
+ final String pauth = hc.getPreferredAuthentications();
+ if (pauth != null)
+ session.setConfig("PreferredAuthentications", pauth);
return session;
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java b/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
index cf7c388..2f41e56 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
@@ -220,6 +220,10 @@ else if (sp < 0)
for (final Host c : current)
if (c.identityFile == null)
c.identityFile = toFile(dequote(argValue));
+ } else if ("PreferredAuthentications".equalsIgnoreCase(keyword)) {
+ for (final Host c : current)
+ if (c.preferredAuthentications == null)
+ c.preferredAuthentications = nows(dequote(argValue));
}
}
@@ -247,6 +251,15 @@ private static String dequote(final String value) {
return value;
}
+ private static String nows(final String value) {
+ final StringBuilder b = new StringBuilder();
+ for (int i = 0; i < value.length(); i++) {
+ if (!Character.isSpaceChar(value.charAt(i)))
+ b.append(value.charAt(i));
+ }
+ return b.toString();
+ }
+
private File toFile(final String path) {
if (path.startsWith("~/"))
return new File(home, path.substring(2));
@@ -278,6 +291,8 @@ private File toFile(final String path) {
String user;
+ String preferredAuthentications;
+
void copyFrom(final Host src) {
if (hostName == null)
hostName = src.hostName;
@@ -287,6 +302,8 @@ void copyFrom(final Host src) {
identityFile = src.identityFile;
if (user == null)
user = src.user;
+ if (preferredAuthentications == null)
+ preferredAuthentications = src.preferredAuthentications;
}
/**
@@ -317,5 +334,13 @@ public File getIdentityFile() {
public String getUser() {
return user;
}
+
+ /**
+ * @return the preferred authentication methods, separated by commas if
+ * more than one authentication method is preferred.
+ */
+ public String getPreferredAuthentications() {
+ return preferredAuthentications;
+ }
}
}
--
1.6.0.2.389.g421e0
^ permalink raw reply related
* Re: [PATCH] help git-upload-pack find git
From: Michael J Gruber @ 2008-09-16 15:38 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <48CFB81A.5060108@viscovery.net>
Johannes Sixt venit, vidit, dixit 16.09.2008 15:43:
> Michael J Gruber schrieb:
>> Why is it that setup_path() cannot be done before commit_pager_choice()?
>> We need the pager in case list_common_cmds_help() is triggered, but why
>> can't setup_path() be before that? Not because of "--", really.
>
> I think that setup_path() must be called *after* handle_options() because
> of this use-case:
>
> $ git --exec-path=/some/where foo
>
> and git_set_argv0_path() must be called *before* handle_options() because
> of this use-case:
>
> $ git --exec-path
>
> -- Hannes
Tricky, I see. But still I'm getting more and more confused:
handle_options() calls git_exec_path() in this case, which does (unless
there is argv_exec_path or the variable):
return system_path(GIT_EXEC_PATH)
Duh, that comes from the Makefile, -DGIT_EXEC_PATH... Back to somewhat
less confused state.
OK, now how about
A: path as submitted
or
B: leave git.c as is, except that setup_path(NULL) is used; have
setup_path(argv0path) call git_set_argv0_path() unless the arg is NULL;
tell upload-pack etc. to stuff (other setup_path() callers) their
argv[0] into setup_path(). Junio, is that what you meant?
Michael
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Catalin Marinas @ 2008-09-16 14:59 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080916074024.GA2454@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: text/plain, Size: 4494 bytes --]
2008/9/16 Karl Hasselström <kha@treskal.com>:
> On 2008-09-15 17:44:38 +0100, Catalin Marinas wrote:
>
>> Since we are talking about this, the transactions documentation
>> doesn't explain when to use a iw and when to pass allow_conflicts. I
>> kind of figured out but I'm not convinced. At a first look, passing
>> allow_conflicts = True would seem that it may allow conflicts and not
>> revert the changes, however, this only works if I pass an "iw". But
>> passing it doesn't allow the default case where I want the changes
>> reverted.
>
> In my experimental branch, one of the patches adds the following piece
> of documentation:
>
> + @param allow_conflicts: Whether to allow pre-existing conflicts
> + @type allow_conflicts: bool or function of L{StackTransaction}"""
>
> That is, allow_conflicts decides whether to abort the transaction in
> case there already were conflicts -- undo and friends need to allow
> existing conflicts, but most other commands just want to abort in that
> case.
OK, it is clearer now.
> iw is the index+worktree object. The idea is that you provide one if
> your branch is checked out, and not if not. Operations that have no
> need of index+worktree, like pop, and push in case automatic merging
> succeeds, will just work anyway, while operations that need
> index+worktree, such as a conflicting push, will cause the whole
> transaction to abort.
Ah, that's the difference. I thought that even if iw isn't passed, it
uses the default one.
> ( Oh, and note that what I just said talks about the "patch stack
> log", meaning that I'm talking about the code in kha/experimental.
> The code in kha/safe doesn't look quite the same -- in particular,
> there's no obvious place to place code that ignores the conflicting
> push. Unless you really don't want your sink changes to depend on
> the stack log stuff (e.g. because you doubt you'll be merging it
> anytime soon), I suggest we do this: I'll prepare, and ask you to
> pull, a "stacklog" branch, and once you've pulled it we won't rebase
> it anymore. You can merge it directly to your master or publish it
> as a separate development branch, whichever you feel is best. )
I think we could merge your experimental branch into master. I gave it
a try and seems OK. The only issue I had was that I had an older
version of Git and it failed in really weird ways (stg pop still
busy-looping after 4 minutes and in another case it failed with broken
pipe). Once I pulled the latest Git, it was fine but we should try to
be compatible at least with the Git version in the Debian testing
distribution. It might be the patch at the top with diff-ing several
trees at once but I haven't checked.
BTW, I ran some benchmarks on stable/master/kha-experimental branches
with 300 patches from the 2.6.27-rc5-mm1 kernel. See attached for the
results. Since performance was my worry with the stack log stuff, it
turns out that there isn't a big difference with real patches. I think
pushing can be made even faster by trying a git-apply first and taking
the diff from the saved blobs in the log.
>> I would rather add support for patch dependency tracking (which used
>> to be on the long term wish list). It might be useful for other
>> things as well like mailing a patch together with those on which it
>> depends (like darcs).
>
> Do you mean automatically detected dependencies, or dependencies that
> the user has told us about?
Automatic dependency - if two patches cannot be reorder with regards
to each-other, one of the depends on the other.
>> + if options.conflict:
>> + iw = stack.repository.default_iw
>> + else:
>> + iw = None
>
> As I said above, this doesn't (or at least isn't supposed to) work.
It should work since the trans.run() command without iw is equivalent
to trans.run(iw=None).
> Have you seen the reorder_patches() function last in transaction.py?
> It seems you could save a lot of work here by using it.
No, I haven't. I'll have a look.
>> + except transaction.TransactionHalted:
>> + if not options.conflict:
>> + raise
>
> Not catching TransactionHalted will have the effect of rolling back
> the whole transaction if it stops half-way through. But what you
> really wanted was the new flag I described above, I think.
OK, if you prepare the stack log, I'll merge it and have a look.
Thanks.
--
Catalin
[-- Attachment #2: stack-log-benchmarks.txt --]
[-- Type: text/plain, Size: 951 bytes --]
CPU: Intel Pentium 4 @ 2.5GHz
Memory: 1GB
2.6.27-rc5-mm1 kernel, 300 patches uncommitted
pop/push ran a few times to heat the caches before running the
benchmarks.
Stable stgit (v0.14.3 + some fixes)
$ time stg pop -a
real 0m1.775s
user 0m0.956s
sys 0m0.724s
$ time stg push -a (fast-forward)
real 0m5.001s
user 0m1.844s
sys 0m2.860s
$ time stg push -a (no fast-forward)
real 1m27.133s
user 0m36.998s
sys 0m34.894s
Current stgit master (no stack log):
$ time stg pop -a
real 0m1.621s
user 0m0.820s
sys 0m0.688s
$ time stg push -a (fast-forward)
real 0m27.205s
user 0m8.741s
sys 0m16.849s
$ time stg push -a (no fast-forward)
real 2m8.209s
user 0m46.031s
sys 0m57.260s
kha/experimantal stgit (with stack log):
$ time stg pop -a
real 0m2.419s
user 0m1.144s
sys 0m1.132s
$ time stg push -a (fast-forward)
real 0m29.594s
user 0m9.217s
sys 0m17.145s
$ time stg push -a (no fast-forward)
real 2m10.270s
user 0m50.919s
sys 1m2.088s
^ permalink raw reply
* git-branch manpage question
From: Mark Struberg @ 2008-09-16 14:46 UTC (permalink / raw)
To: git
Hi!
I think i found an inconsistency in the documentation of the git-branch command:
*snip*
--track::
.... Set the
branch.autosetupmerge configuration variable to `false` if you want
'git-checkout' and 'git-branch' to always behave as if
'--no-track' were given...
*snip*
and
*snip*
--no-track::
Ignore the branch.autosetupmerge configuration variable.
*snip*
So, the description of branch.autosetupmerge is referencing --no-track and vice versa, thus the effective documentation is essentially missing as far as I understand.
txs and LieGrue,
strub
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
^ permalink raw reply
* multi-threading or processing of converts
From: dhruva @ 2008-09-16 14:23 UTC (permalink / raw)
To: GIT SCM
Hi,
I am running git-p4 to import around 11147 changes from perforce, it has done 38% in 4h39m. Wonder if it would have been faster to get a bunch of changes in parallel and import them sequentially. I do understand that importing of full history does not happen too often by still it might be a good idea.
Have a multi-threaded fetcher from source SCM and dump it in some format locally. git fast-import can pull it from the local at its own speed (which will be real fast). Basically, I am suggesting better using the available bandwidth and CPU resources for doing network IO.
-dhruva
Cricket on your mind? Visit the ultimate cricket website. Enter http://in.sports.yahoo.com/cricket/
^ permalink raw reply
* Re: Grafts workflow for a "shallow" repository...?
From: Björn Steinbrink @ 2008-09-16 13:50 UTC (permalink / raw)
To: Michael J Gruber
Cc: Junio C Hamano, Shawn O. Pearce, Martin Langhoff,
Git Mailing List
In-Reply-To: <48CFB44F.8060609@drmicha.warpmail.net>
On 2008.09.16 15:27:43 +0200, Michael J Gruber wrote:
> Björn Steinbrink venit, vidit, dixit 16.09.2008 10:09:
> > On 2008.09.15 23:25:10 -0700, Junio C Hamano wrote:
> >> "Shawn O. Pearce" <spearce@spearce.org> writes:
> >>
> >>> Martin Langhoff <martin.langhoff@gmail.com> wrote:
> >>>> Here is my attempt at a "let's publish a shallow repository for branch
> >>>> of moodle". Let me show you what I did...
> >>> ...
> >>>> # 1.7 was a significant release, anything earlier than that
> >>>> # is just not interesting -- even for pickaxe/annotate purposes
> >>>> # so add a graft point right at the branching point.
> >>> ...
> >>>> Is this kind of workflow (or a variation of it) supported? For this to
> >>>> work, we should communicate the grafts in some push operations and
> >>>> read them in clone ops - and perhaps in fetch too.
> >>> ...
> >>> I think that in this case the best thing to do is give users
> >>> a shell script that does roughly:
> >>>
> >>> git init
> >>> echo $BASE >.git/info/grafts
> >>> git remote add -f origin $url
> >>> git checkout -b master origin/master
> >>>
> >>> Sign the script, and let users verify it before executing. You may
> >>> also want a script to drag in the history behind by removing the
> >>> graft and fetching $BASE^, but that is hard because your repository
> >>> already "has" that.
> >> Why not just filter-branch _once at the origin_ and publish the result?
> >
> > I think the idea was to have a shallow clone starting at a certain
> > point, as opposed to the --depth option, where you cannot specify a
> > starting point, but only the depth of the clone.
>
> That's what Junio suggests:
>
> chop the history by introducing an appropriate graft
> make it "permanent" by filter-branching (and remove from info/grafts).
>
> Now you have a disconnect dag. clone/push/whatever works on the
> "components" given by connected branches.
>
> Note that in this approach all history after the "chopping point" will
> be rewritten, i.e. get new sha1's.
But shallow clones using --depth don't get alterted hashed. They have
"graft-like" entries in .git/shallow (or whatever it is called) instead.
Assuming that using a shallow clone is worth the hassle (ie. you have to
fetch significantly less data than with a full clone), I can imagine
some use-cases for that, for example bisecting a bug of which you know
that it was introduced after the last release. Just shallow clone the
repo from that version's tag onwards and bisect locally, while still
being able to use the original hash to report the broken version. Or
genrally anything for which you need a recent part of the history and
which requires you to talk about certain commits. The hashes are useful
for that, and filter-branch'ing breaks that.
Maybe instead of providing "pre-shallowed" repos to clone from, that
should have been an RFE to support shallow clones starting at a given
commit in the DAG? I have no idea whether that's feasible though.
Björn
^ permalink raw reply
* Re: [PATCH] help git-upload-pack find git
From: Johannes Sixt @ 2008-09-16 13:43 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <48CFB183.1090205@drmicha.warpmail.net>
Michael J Gruber schrieb:
> Why is it that setup_path() cannot be done before commit_pager_choice()?
> We need the pager in case list_common_cmds_help() is triggered, but why
> can't setup_path() be before that? Not because of "--", really.
I think that setup_path() must be called *after* handle_options() because
of this use-case:
$ git --exec-path=/some/where foo
and git_set_argv0_path() must be called *before* handle_options() because
of this use-case:
$ git --exec-path
-- Hannes
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: dhruva @ 2008-09-16 13:33 UTC (permalink / raw)
To: Jing Xue, David Brown
Cc: Daniel Barkalow, Junio C Hamano, GIT SCM, Simon Hausmann
Hello,
----- Original Message ----
> From: Jing Xue <jingxue@digizenstudio.com>
> To: David Brown <git@davidb.org>
> Cc: Daniel Barkalow <barkalow@iabervon.org>; Junio C Hamano <gitster@pobox.com>; dhruva <dhruva@ymail.com>; GIT SCM <git@vger.kernel.org>; Simon Hausmann <simon@lst.de>
> Sent: Tuesday, 16 September, 2008 6:28:56 PM
> Subject: Re: [PATCH] Optional shrinking of RCS keywords in git-p4
>
> On Mon, Sep 15, 2008 at 09:12:01PM -0700, David Brown wrote:
> > A simple way to be paranoid would be something (shell-ish) like:
> >
> > p4 print filename | collapse-keywords | git hash-object --stdin
> >
>
> How about collapsing the keywords in the _p4_ version after "p4 edit"
> but before applying the patch, and just "p4 submit" the collapsed
> version if patching succeeds? As pointed out earlier in this thread, p4
> submit doesn't care about whether keywords are expanded or not anyway.
That is feasible but would require more changes. I still feel having an option to disable the keyword from collapsing is a move forward followed by your suggestion as a bug fix to fix the issue with 'p4 submit' when rcs keywords are collapsed. Would that be an acceptable approach?
-dhruva
Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/
^ permalink raw reply
* Re: Grafts workflow for a "shallow" repository...?
From: Michael J Gruber @ 2008-09-16 13:27 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Junio C Hamano, Shawn O. Pearce, Martin Langhoff,
Git Mailing List
In-Reply-To: <20080916080908.GA14272@atjola.homenet>
Björn Steinbrink venit, vidit, dixit 16.09.2008 10:09:
> On 2008.09.15 23:25:10 -0700, Junio C Hamano wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>
>>> Martin Langhoff <martin.langhoff@gmail.com> wrote:
>>>> Here is my attempt at a "let's publish a shallow repository for branch
>>>> of moodle". Let me show you what I did...
>>> ...
>>>> # 1.7 was a significant release, anything earlier than that
>>>> # is just not interesting -- even for pickaxe/annotate purposes
>>>> # so add a graft point right at the branching point.
>>> ...
>>>> Is this kind of workflow (or a variation of it) supported? For this to
>>>> work, we should communicate the grafts in some push operations and
>>>> read them in clone ops - and perhaps in fetch too.
>>> ...
>>> I think that in this case the best thing to do is give users
>>> a shell script that does roughly:
>>>
>>> git init
>>> echo $BASE >.git/info/grafts
>>> git remote add -f origin $url
>>> git checkout -b master origin/master
>>>
>>> Sign the script, and let users verify it before executing. You may
>>> also want a script to drag in the history behind by removing the
>>> graft and fetching $BASE^, but that is hard because your repository
>>> already "has" that.
>> Why not just filter-branch _once at the origin_ and publish the result?
>
> I think the idea was to have a shallow clone starting at a certain
> point, as opposed to the --depth option, where you cannot specify a
> starting point, but only the depth of the clone.
That's what Junio suggests:
chop the history by introducing an appropriate graft
make it "permanent" by filter-branching (and remove from info/grafts).
Now you have a disconnect dag. clone/push/whatever works on the
"components" given by connected branches.
Note that in this approach all history after the "chopping point" will
be rewritten, i.e. get new sha1's.
Michael
^ permalink raw reply
* Re: [PATCH] help git-upload-pack find git
From: Michael J Gruber @ 2008-09-16 13:15 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <48CF4F6A.6080604@viscovery.net>
Johannes Sixt venit, vidit, dixit 16.09.2008 08:17:
> Michael J Gruber schrieb:
>> I was actually surprised that setup_path() uses argv0_path without
>> setting it, same as with argv_exec_path. I assumed this is for a good
>> reason, I'm lacking the code base overview to judge this myself.
>
> It argv_exec_path comes from git --exec-path=..., hence, git (via git.c)
> is the only caller of setup_path() that is able to set it. We can leave
> that one out of the equation.
>
>> In any case, git.c sets argv0_path early, messes a bit with argv[0] and
>> calls setup_path afterwards anyways. So adding the path in setup_path()
>> should not hurt any "git foo" command.
>>
>> One could construe situations where even that wouldn't help, because
>> git-upload-pack can't pass --exec-dir to git and they can be in
>> different locations - but I think that's crazy.
>>
>> git.c, upload-pack.c, receive.pack.c and shell.c are the only callers.
>> setup_path() needs to get a parameter. If shell.c should profit from the
>> change then it needs to be taught how to pass an absolute path to
>> do_{generic,cvs}_cmd().
>>
>> So, I guess the general approach (change setup() path and have every
>> caller profit) is OK. OK with you?
>
> Have you studied the commit message of e1464ca7bb0d (Record the command
> invocation path early) and the context in which this commit occurs? It's
> about relocatable git installations and how system_path() derives various
> other paths from argv[0].
That is what I meant by my lack of overview ;)
I might have implemented what amounts to a revert of e1464ca7bb0d otherwise.
> Please show how you think you could change setup_path(), but keep in mind
> that in git.c you neither can do the equivalent of git_set_argv0_path()
> later nor setup_path() earlier.
Well, I'd be happy with the change in upload-pack as submitted. Junio
suggested the more general approach. In fact I'd prefer everyone set
their path, but not everyone seems to be allowed to in their restricted
environments.
Why is it that setup_path() cannot be done before commit_pager_choice()?
We need the pager in case list_common_cmds_help() is triggered, but why
can't setup_path() be before that? Not because of "--", really.
Michael
^ permalink raw reply
* Re: [PATCH 15/16] checkout: add new options to support narrow checkout
From: Nguyen Thai Ngoc Duy @ 2008-09-16 13:13 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <48CF879F.6020006@viscovery.net>
On 9/16/08, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Nguyễn Thái Ngọc Duy schrieb:
>
> > +--full::
> > + Quit narrow checkout mode. Return to full checkout.
> > +
> > +--path=<narrow_spec>::
> > + Re-apply new narrow spec on current working directory to
> > + form new checkout area.
> > +
> > +--add-path=<narrow_spec>::
> > + Checkout more areas specified by narrow spec to current
> > + checkout area.
> > +
> > +--remove-path=<narrow_spec>::
> > + Narrow checkout area by removing files specified by narrow spec
> > + from current checkout area. This operation will fail if there
> > + is unmerged or modified files in the removing areas.
>
>
> The option --path is named a bit too generic for my taste. How about
> --narrow=...?
--narrow or --narrow-template (or --checkout-template?) seems good.
> And how would you like --more= instead of --add-path= and
> --less= instead of --remove-path=?
Now these --more/--less are too generic to me ;)
> I do think that --full is OK.
>
> -- Hannes
>
>
--
Duy
^ permalink raw reply
* [EGIT] Checking out signed tags fails
From: Jonas Flodén @ 2008-09-16 12:58 UTC (permalink / raw)
To: git
When trying to check-out a signed tag I get the following Error:
Unable to switch branches
Reason:
Mapping commit: refs/tags/v1.3.1.1
And in details:
Object XXX is not a commit.
The object ID shown is actually the id for the tag object and not the
tagged commit.
This was tested with the latest master. It seemed commit 1f460e2 (Tests
and fixes for dereferencing tags in Repository.resolve(), 2008-09-12)
would fix it, but it didn't.
Thanks,
Jonas
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: Jing Xue @ 2008-09-16 12:58 UTC (permalink / raw)
To: David Brown
Cc: Daniel Barkalow, Junio C Hamano, dhruva, GIT SCM, Simon Hausmann
In-Reply-To: <20080916041201.GA25033@linode.davidb.org>
On Mon, Sep 15, 2008 at 09:12:01PM -0700, David Brown wrote:
> A simple way to be paranoid would be something (shell-ish) like:
>
> p4 print filename | collapse-keywords | git hash-object --stdin
>
> and make sure that is the version we think the file should have
> started with. I think we're really just making sure we didn't miss a
> P4 change that someone else made underneath, and we're about to back
> out.
> Even this isn't robust from p4's point of view. The p4 model is to do
> a 'p4 edit' on the file, and then the later 'p4 submit' will give an
> error if someone else has updated the file. This would require using
> p4's conflict resolution, and I'm guessing someone using git-p4 would
> rather abort the submit and rebase.
How about collapsing the keywords in the _p4_ version after "p4 edit"
but before applying the patch, and just "p4 submit" the collapsed
version if patching succeeds? As pointed out earlier in this thread, p4
submit doesn't care about whether keywords are expanded or not anyway.
Cheers.
--
Jing Xue
^ 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