* [PATCH 2/3] block-sha1: split the different "hacks" to be individually selected
From: Nicolas Pitre @ 2009-08-12 19:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
This is to make it easier for them to be selected individually depending
on the architecture instead of the other way around i.e. having each
architecture select a list of hacks up front. That makes for clearer
documentation as well.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
block-sha1/sha1.c | 23 ++++++++++++++++++-----
1 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index c3f1ae5..67c9bd0 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -11,10 +11,16 @@
#if defined(__i386__) || defined(__x86_64__)
+/*
+ * Force usage of rol or ror by selecting the one with the smaller constant.
+ * It _can_ generate slightly smaller code (a constant of 1 is special), but
+ * perhaps more importantly it's possibly faster on any uarch that does a
+ * rotate with a loop.
+ */
+
#define SHA_ASM(op, x, n) ({ unsigned int __res; __asm__(op " %1,%0":"=r" (__res):"i" (n), "0" (x)); __res; })
#define SHA_ROL(x,n) SHA_ASM("rol", x, n)
#define SHA_ROR(x,n) SHA_ASM("ror", x, n)
-#define SMALL_REGISTER_SET
#else
@@ -24,9 +30,6 @@
#endif
-/* This "rolls" over the 512-bit array */
-#define W(x) (array[(x)&15])
-
/*
* If you have 32 registers or more, the compiler can (and should)
* try to change the array[] accesses into registers. However, on
@@ -43,13 +46,23 @@
* Ben Herrenschmidt reports that on PPC, the C version comes close
* to the optimized asm with this (ie on PPC you don't want that
* 'volatile', since there are lots of registers).
+ *
+ * On ARM we get the best code generation by forcing a full memory barrier
+ * between each SHA_ROUND, otherwise gcc happily get wild with spilling and
+ * the stack frame size simply explode and performance goes down the drain.
*/
-#ifdef SMALL_REGISTER_SET
+
+#if defined(__i386__) || defined(__x86_64__)
#define setW(x, val) (*(volatile unsigned int *)&W(x) = (val))
+#elif defined(__arm__)
+ #define setW(x, val) do { W(x) = (val); __asm__("":::"memory"); } while (0)
#else
#define setW(x, val) (W(x) = (val))
#endif
+/* This "rolls" over the 512-bit array */
+#define W(x) (array[(x)&15])
+
/*
* Where do we get the source from? The first 16 iterations get it from
* the input data, the next mix it from the 512-bit array.
--
1.6.4.189.g282fa
^ permalink raw reply related
* Re: [JGIT PATCH 1/1] Fix for Repository.stripWorkDir when using partial paths
From: Robin Rosenberg @ 2009-08-12 19:47 UTC (permalink / raw)
To: Adam W. Hawks; +Cc: git
In-Reply-To: <4A821167.6030107@writeme.com>
onsdag 12 augusti 2009 02:48:39 skrev "Adam W. Hawks" <awhawks@writeme.com>:
>
> From ef993e633cdcb1dddda5e71db1b62306df7ce83f Mon Sep 17 00:00:00 2001
> Date: Tue, 11 Aug 2009 20:02:56 -0400
>
> When you call stripWorkDir with a relative path
> you can get a string out of bounds error.
>
> This change fixes that problem by using the absolute paths
> of the file instead of its relative name.
>
> Signed-off-by: Adam W. Hawks <awhawks@writeme.com>
> ---
> .../src/org/spearce/jgit/lib/Repository.java | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> index 468cf4c..a68817b 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> @@ -1036,7 +1036,7 @@ public static boolean isValidRefName(final String refName) {
> * @return normalized repository relative path
> */
> public static String stripWorkDir(File wd, File f) {
> - String relName = f.getPath().substring(wd.getPath().length() + 1);
> + String relName = f.getAbsolutePath().substring(wd.getPath().length() + 1);
> relName = relName.replace(File.separatorChar, '/');
> return relName;
> }
Why not convert both paths? A trickier issue is that getAbsolutePath is very slow when
the path is not absolute. I don't think we will always need to normalize in order to
fix this. A few unit tests to show the cases solved would help.
-- robin
^ permalink raw reply
* [PATCH 3/3] block-sha1: support for architectures with memory alignment restrictions
From: Nicolas Pitre @ 2009-08-12 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
This is needed on architectures with poor or non-existent unaligned memory
support and/or no fast byte swap instruction (such as ARM) by using byte
accesses to memory and shifting the result together.
This also makes the code portable, therefore the byte access methods are
the defaults. Any architecture that properly supports unaligned word
accesses in hardware simply has to enable the alternative methods.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
block-sha1/sha1.c | 32 ++++++++++++++++++++++++++++++--
1 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index 67c9bd0..d3121f7 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -60,6 +60,34 @@
#define setW(x, val) (W(x) = (val))
#endif
+/*
+ * Performance might be improved if the CPU architecture is OK with
+ * unaligned 32-bit loads and a fast ntohl() is available.
+ * Otherwise fall back to byte loads and shifts which is portable,
+ * and is faster on architectures with memory alignment issues.
+ */
+
+#if defined(__i386__) || defined(__x86_64__)
+
+#define get_be32(p) ntohl(*(unsigned int *)(p))
+#define put_be32(p, v) do { *(unsigned int *)(p) = htonl(v); } while (0)
+
+#else
+
+#define get_be32(p) ( \
+ (*((unsigned char *)(p) + 0) << 24) | \
+ (*((unsigned char *)(p) + 1) << 16) | \
+ (*((unsigned char *)(p) + 2) << 8) | \
+ (*((unsigned char *)(p) + 3) << 0) )
+#define put_be32(p, v) do { \
+ unsigned int __v = (v); \
+ *((unsigned char *)(p) + 0) = __v >> 24; \
+ *((unsigned char *)(p) + 1) = __v >> 16; \
+ *((unsigned char *)(p) + 2) = __v >> 8; \
+ *((unsigned char *)(p) + 3) = __v >> 0; } while (0)
+
+#endif
+
/* This "rolls" over the 512-bit array */
#define W(x) (array[(x)&15])
@@ -67,7 +95,7 @@
* Where do we get the source from? The first 16 iterations get it from
* the input data, the next mix it from the 512-bit array.
*/
-#define SHA_SRC(t) htonl(data[t])
+#define SHA_SRC(t) get_be32(data + t)
#define SHA_MIX(t) SHA_ROL(W(t+13) ^ W(t+8) ^ W(t+2) ^ W(t), 1)
#define SHA_ROUND(t, input, fn, constant, A, B, C, D, E) do { \
@@ -245,5 +273,5 @@ void blk_SHA1_Final(unsigned char hashout[20], blk_SHA_CTX *ctx)
/* Output hash */
for (i = 0; i < 5; i++)
- ((unsigned int *)hashout)[i] = htonl(ctx->H[i]);
+ put_be32(hashout + i*4, ctx->H[i]);
}
--
1.6.4.189.g282fa
^ permalink raw reply related
* Re: [ANNOUNCE] Scumd
From: Jakub Narebski @ 2009-08-12 20:26 UTC (permalink / raw)
To: Michael Gaffney; +Cc: git
In-Reply-To: <4A8309D9.8070008@gmail.com>
Michael Gaffney <mr.gaffo@gmail.com> writes:
> This is an initial announcement of SCuMD, a pure java git sshd
> daemon. The source is at git://github.com/gaffo/scumd. The impetus
> behind SCuMD is to provide a highly configurable git daemon which can
> authenticate and authorize off of flat files, databases, LDAP, web
> services, or any other resource you can think of. SCuMD's other goal
> is to remove the need to serve off of normal sshd which some find to
> be a security risk on the open Internet. Currently SCuMD supports LDAP
> as the authentication module but coding other modules is quite simple.
>
> I would welcome any feedback including a better name. SCuMD stands
> for SCM Daemon.
Could you add information about this tool to Git Wiki:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
perhaps below entry for gitosis?
TIA
--
Jakub Narebski
Git User's Survey 2009
http://tinyurl.com/GitSurvey2009
^ permalink raw reply
* Re: Tie a CVS-aware app into GIT?
From: Robin Rosenberg @ 2009-08-12 20:30 UTC (permalink / raw)
To: david.hagood; +Cc: git
In-Reply-To: <b988339dcd1bf764f0da46db763552d8.squirrel@localhost>
onsdag 12 augusti 2009 20:01:45 skrev david.hagood@gmail.com:
> I have an application (closed source, unfortunately) that can use CVS to
> manage its files (specifically, Enterprise Architect by Sparx).
>
> I'd rather use GIT to manage the files, but EA doesn't "speak" git - just
> CVS and Subversion (and Microsoft's SCC protocol, but...)
>
> Are there any programs which
> 1) accept the same command line parameters as CVS or Subversion
> and
> 2) access a GIT repository.
>
> git-svn is almost exactly NOT what I need, as it accepts "git" type
> command line parameters and access a SVN repo, rather than accepting SVN
> command line parameters and accessing a GIT repo.
>
> Now, obviously, such a tool wouldn't have access to all the things that
> GIT can do, and that is NOT what I am expecting - what I want is just to
> enable EA to do the things it needs to do, namely adding/removing/moving
> files from a repo. Branching, commits, and so on can be done manually.
>
> I've thought about git-cvsserver as a solution, but I don't know if it can
> be run on a local machine to access a local repository.
What makes you there would be an issue here?
-- robin
^ permalink raw reply
* Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs
From: Junio C Hamano @ 2009-08-12 20:30 UTC (permalink / raw)
To: Jakub Narebski
Cc: Jeff King, Johannes Schindelin, Bert Wesarg, Daniel Barkalow, git,
Brian Gernhardt
In-Reply-To: <m363ctpedr.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> 1. Is there some other syntax that _doesn't_ have this breakage
>> but that similarly helps the "vast majority of Git users".
>
> Well, proposed possible syntax was:
> 1. <vcs>:<repository location>
> ...
> 2. <vcs>::<repository location>
> ...
> 3. <vcs>+<repository location>
>
> e.g.
>
> svn+http://svn.example.com/project
>
> but
>
> http+svn://svn.example.com/project
> svn+path/to/repo
I do not think these are valid examples to demonstrate that 3 is bad.
We do not have (and we will not create) "http+svn://" native transport, so
the former can only mean "Feed 'svn://svn.example.com/project' to the vcs
helper whose name is 'http'". Similarly I do not see any way to read the
latter other than "Feed 'path/to/repo' to 'svn' vcs helper".
We do have a pair of synonyms "git+ssh://foo" and "ssh+git://bar" that
could make the use of '+' ambiguous. They could be feeding 'ssh://foo'
and 'git://bar' to 'git' and 'ssh' vcs helpers respectively, but
(1) they are not even advertised in Documentation/ anywhere as far as I
can see; and
(2) these are the only two existing ones that are misdesigned, and we can
easily special case them to keep backward compatibility.
Double-colon (your 2) is also workable. It probably is slightly better
than plus because it does not have to grandfather "git+ssh" and "ssh+git"
and that would be beneficial for requiring less complexity in both code
(i.e. special case logic) and more importantly in mental burden to the end
users (i.e. '::' would stand out more than '+' and clearly different from
traditional git URLs in all cases).
As Jeff said (your 1.), a single colon ':' has a rather bad ambiguity
between <vcs> and hostname part in the existing scp-style repository
naming.
^ permalink raw reply
* Re: [PATCH] Re: [TRIVIAL] Documentation: merge: one <remote> is required
From: Junio C Hamano @ 2009-08-12 20:31 UTC (permalink / raw)
To: Paul Bolle; +Cc: Nicolas Sebrecht, git
In-Reply-To: <1250074578.7545.2.camel@localhost.localdomain>
Paul Bolle <pebolle@tiscali.nl> writes:
> Confusingly, as far as I can see, the manpages of the following commands
> seem to use the "one or more" meaning:
> git merge-base
> ...
> ("git mv" uses both meanings in its synopsis. The two "git tag"
> invocations seem to do nothing with zero arguments and do not return an
> error.)
>
> If the above commands really use the "one or more" meaning, that would
> mean both versions are used in the documentation. I'd say it would be
> better to stick to one meaning throughout the manpages.
You are absolutely right. We would want consistency.
I do not have any objection to make sure that we uniformly use ellipses
for one-or-more (and enclose them in [] if we want zero-or-more). Are
these two that your patch touched the only ones that need fixing?
^ permalink raw reply
* Re: git index: how does it work?
From: Junio C Hamano @ 2009-08-12 20:31 UTC (permalink / raw)
To: Shaun Cutts; +Cc: git
In-Reply-To: <436D5ED1-2F0E-4227-AC4A-3A5FD16B2DCF@cuttshome.net>
Shaun Cutts <shaun@cuttshome.net> writes:
> Are renames being tracked by the index, and is there a more basic
> interface than "status" to query about them?
No. Index, nor git in general, never records renames. git records
contents, not content changes. The index records a state, so does the
tree object pointed at by the HEAD commit.
When you ask for "status", git will notice that you have lost a file, and
added a new one, between these two states, by comparing them. The
contents of these lost files and added files are then compared, and ones
with similar contents are paired up.
That way, you do not have to use "git mv A B" to "rename" A to B. You can
just as well "mv A B; git rm A; git add B", and get the same outcome,
exactly because git does not record renames.
Instead, we track them by deducing that you renamed from the result.
The tree-vs-index comparison "git status" does to figure all this out is
"git diff-index -M --cached HEAD".
As it should be obvious from the above description,
git diff-index -M --cached HEAD -- A
is *NOT* the way for you to ask about "possible renames of A". You need
to run the diff for the whole tree without path limitation so that you can
pair deletions and creations up in order to deduce renames.
^ permalink raw reply
* Re: [JGIT PATCH] Rename RevTag.getName() to RevTag.getTagName()
From: Robin Rosenberg @ 2009-08-12 20:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1250105956-17795-1-git-send-email-spearce@spearce.org>
onsdag 12 augusti 2009 21:39:16 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> The method getName() conflicts semantically with the method name()
> we have inherited from our base class, ObjectId. It is a rather
> unfortunate turn of events that for performance reasons we wind up
> subclassing what should be a property of this class, but since we
> do that we need to pay attention to the methods declared on our
> base class.
>
> We want to use getName() to be a mirror of name() on AnyObjectId,
> as it has a more JavaBeans style feel to the accessing of that
> particular value. So, rename getTagName() so it doesn't wind up
> conflicting with the SHA-1 hex formatted string.
> @@ -204,7 +204,7 @@ public final RevObject getObject() {
> * @return name of the tag, according to the tag header.
> */
> public final String getName() {
> - return name;
> + return tagName;
> }
>
> final void disposeBody() {
You forgot the rename of the method here, and all uses of it.
-- robin
^ permalink raw reply
* Re: git-gui translation pushed
From: Jimmy Angelakos @ 2009-08-12 20:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090810154429.GU1033@spearce.org>
On Mon, 2009-08-10 at 08:44 -0700, Shawn O. Pearce wrote:
> Jimmy Angelakos <vyruss@hellug.gr> wrote:
> > I have pushed a Greek translation for git-gui on repo.or.cz's
> > git-gui-i18n (mob branch).
>
> Thanks, I have cherry-picked this through to master. The charset
> was set wrong in the files, it was "CHARSET", which isn't a valid
> charset. I modified to UTF-8 before applying. I suspect something
> is up with your PO editor.
>
Thanks for mentioning that, I'll check it out. It's either something
wrong with Lokalize or my mistake.
Regards
Jimmy
^ permalink raw reply
* Re: [PATCH] Re: [TRIVIAL] Documentation: merge: one <remote> is required
From: Paul Bolle @ 2009-08-12 20:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Sebrecht, git
In-Reply-To: <7vhbwcydtn.fsf@alter.siamese.dyndns.org>
On Wed, 2009-08-12 at 13:31 -0700, Junio C Hamano wrote:
> Paul Bolle <pebolle@tiscali.nl> writes:
> I do not have any objection to make sure that we uniformly use ellipses
> for one-or-more (and enclose them in [] if we want zero-or-more). Are
> these two that your patch touched the only ones that need fixing?
I guess not (these two were the ones that annoyed me enough to write
patches when I read them in order to learn more about the commands they
described).
What is the best way to fix small issues like this: one set of patches
that tries to fix as much as possible in one go or a stream of little
patches whenever similar issues are found in one of the documents?
^ permalink raw reply
* [JGIT PATCH v2] Rename RevTag.getName() to RevTag.getTagName()
From: Shawn O. Pearce @ 2009-08-12 20:51 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200908122237.37148.robin.rosenberg.lists@dewire.com>
The method getName() conflicts semantically with the method name()
we have inherited from our base class, ObjectId. It is a rather
unfortunate turn of events that for performance reasons we wind up
subclassing what should be a property of this class, but since we
do that we need to pay attention to the methods declared on our
base class.
We want to use getName() to be a mirror of name() on AnyObjectId,
as it has a more JavaBeans style feel to the accessing of that
particular value. So, rename getTagName() so it doesn't wind up
conflicting with the SHA-1 hex formatted string.
Noticed-by: Alex Blewitt <alex.blewitt@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> You forgot the rename of the method here, and all uses of it.
Quite right. #@*!! Eclipse. I thought I refactored that method,
but I guess it didn't actually do the work, and I failed to read
the diff closely enough to notice. *sigh* That's what I get for
trying to quickly bang out a "simple" change.
.../org/spearce/jgit/revwalk/RevTagParseTest.java | 8 ++++----
.../src/org/spearce/jgit/revwalk/RevTag.java | 10 +++++-----
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevTagParseTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevTagParseTest.java
index 66bc901..9f91154 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevTagParseTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevTagParseTest.java
@@ -75,7 +75,7 @@ private void testOneType(final int typeCode) throws Exception {
c = new RevTag(id("9473095c4cb2f12aefe1db8a355fe3fafba42f67"));
assertNull(c.getObject());
- assertNull(c.getName());
+ assertNull(c.getTagName());
c.parseCanonical(rw, b.toString().getBytes("UTF-8"));
assertNotNull(c.getObject());
@@ -117,15 +117,15 @@ public void testParseAllFields() throws Exception {
c = new RevTag(id("9473095c4cb2f12aefe1db8a355fe3fafba42f67"));
assertNull(c.getObject());
- assertNull(c.getName());
+ assertNull(c.getTagName());
c.parseCanonical(rw, body.toString().getBytes("UTF-8"));
assertNotNull(c.getObject());
assertEquals(treeId, c.getObject().getId());
assertSame(rw.lookupTree(treeId), c.getObject());
- assertNotNull(c.getName());
- assertEquals(name, c.getName());
+ assertNotNull(c.getTagName());
+ assertEquals(name, c.getTagName());
assertEquals("", c.getFullMessage());
final PersonIdent cTagger = c.getTaggerIdent();
diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevTag.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevTag.java
index 2fab266..204e9b1 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevTag.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevTag.java
@@ -56,7 +56,7 @@
private byte[] buffer;
- private String name;
+ private String tagName;
/**
* Create a new tag reference.
@@ -96,7 +96,7 @@ void parseCanonical(final RevWalk walk, final byte[] rawTag)
int p = pos.value += 4; // "tag "
final int nameEnd = RawParseUtils.nextLF(rawTag, p) - 1;
- name = RawParseUtils.decode(Constants.CHARSET, rawTag, p, nameEnd);
+ tagName = RawParseUtils.decode(Constants.CHARSET, rawTag, p, nameEnd);
if (walk.isRetainBody())
buffer = rawTag;
@@ -186,7 +186,7 @@ public final String getShortMessage() {
* @return parsed tag.
*/
public Tag asTag(final RevWalk walk) {
- return new Tag(walk.db, this, name, buffer);
+ return new Tag(walk.db, this, tagName, buffer);
}
/**
@@ -203,8 +203,8 @@ public final RevObject getObject() {
*
* @return name of the tag, according to the tag header.
*/
- public final String getName() {
- return name;
+ public final String getTagName() {
+ return tagName;
}
final void disposeBody() {
--
1.6.4.225.gb589e
^ permalink raw reply related
* situation codes (e.g. #16) in unpack-trees.c
From: Jeff Enderwick @ 2009-08-12 21:05 UTC (permalink / raw)
To: git
Newbie here. I'm trying to grok git's merge algorithms. Where are
those '#' codes written up (e.g. #16, #5ALT, etc)?
Is there a write-up anywhere on the merge logic?
TIA,
Jeff
^ permalink raw reply
* Re: situation codes (e.g. #16) in unpack-trees.c
From: Jeff King @ 2009-08-12 21:07 UTC (permalink / raw)
To: Jeff Enderwick; +Cc: git
In-Reply-To: <bb6059c00908121405t4f34c50eo532b928fa6d6f89c@mail.gmail.com>
On Wed, Aug 12, 2009 at 02:05:06PM -0700, Jeff Enderwick wrote:
> Newbie here. I'm trying to grok git's merge algorithms. Where are
> those '#' codes written up (e.g. #16, #5ALT, etc)?
> Is there a write-up anywhere on the merge logic?
Try Documentation/technical/trivial-merge.txt.
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] Scumd
From: Alex Riesen @ 2009-08-12 21:10 UTC (permalink / raw)
To: Michael Gaffney; +Cc: git
In-Reply-To: <4A8309D9.8070008@gmail.com>
On Wed, Aug 12, 2009 at 20:28, Michael Gaffney<mr.gaffo@gmail.com> wrote:
> ... SCuMD's other goal is to remove the need to serve
> off of normal sshd which some find to be a security risk on the open
> Internet. ...
I just wonder: how is your creation less of security risk than sshd?
^ permalink raw reply
* Re: [ANNOUNCE] Scumd
From: Michael Gaffney @ 2009-08-12 20:56 UTC (permalink / raw)
To: git
In-Reply-To: <m3ws58ok1r.fsf@localhost.localdomain>
Done, thanks.
Jakub Narebski wrote:
> Michael Gaffney <mr.gaffo@gmail.com> writes:
>
>
>> This is an initial announcement of SCuMD, a pure java git sshd
>> daemon. The source is at git://github.com/gaffo/scumd. The impetus
>> behind SCuMD is to provide a highly configurable git daemon which can
>> authenticate and authorize off of flat files, databases, LDAP, web
>> services, or any other resource you can think of. SCuMD's other goal
>> is to remove the need to serve off of normal sshd which some find to
>> be a security risk on the open Internet. Currently SCuMD supports LDAP
>> as the authentication module but coding other modules is quite simple.
>>
>> I would welcome any feedback including a better name. SCuMD stands
>> for SCM Daemon.
>>
>
> Could you add information about this tool to Git Wiki:
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
> perhaps below entry for gitosis?
>
> TIA
>
^ permalink raw reply
* Re: [PATCH 00/13] more changes to port rebase -i to C using sequencer code
From: Junio C Hamano @ 2009-08-12 21:49 UTC (permalink / raw)
To: Christian Couder
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski
In-Reply-To: <20090812051116.18155.70541.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> These is just the current state of my work.
> Some patches have already been sent but are not yet in pu.
It seems that some later patches in the series are "oops, the earlier one
made mistakes and this patch fixes them". Could you fix them where they
were introduced?
^ permalink raw reply
* Re: [RFC/PATCH 2/6] transport_get(): Don't SEGFAULT on missing url
From: Junio C Hamano @ 2009-08-12 22:24 UTC (permalink / raw)
To: Johan Herland; +Cc: git, barkalow, benji, Johannes.Schindelin
In-Reply-To: <1249985426-13726-3-git-send-email-johan@herland.net>
Johan Herland <johan@herland.net> writes:
> Signed-off-by: Johan Herland <johan@herland.net>
How does url end up to be NULL? At the beginning of transport_get(), you
do this:
ret->remote = remote;
if (!url && remote && remote->url)
url = remote->url[0];
ret->url = url;
if (remote && remote->foreign_vcs) {
transport_helper_init(ret);
return ret;
}
and the case where remote.$name.vcs is defined, we do not need
remote.$name.url.
When (!url && remote && remote->url), is remote->url[0] allowed to be
NULL? I am guessing it would be a bug in whoever prepared the remote, and
if that is indeed the case, the patch shifts the symptoms without fixing
the cause.
When (remote && remote->foreign_vcs) does not hold, iow, if no remote is
defined or the remote is defined but lacks remote.$name.url, you will go
to the last else clause in the function that sets up a git_transport_data
for the native transport, but it has ret->url == NULL.
Whom does that transport talk with? Is such a transport of any use, or
does it cause a segfault downstream in the call chain?
In other words, I am wondering if this patch should just diagnose the case
as an error, instead of pretending all is well.
^ permalink raw reply
* For review: git add --ignore-unmatch
From: Luke-Jr @ 2009-08-12 22:26 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: Text/Plain, Size: 1 bytes --]
[-- Attachment #2: 0001-port-ignore-unmatch-from-git-rm-to-git-add.patch --]
[-- Type: text/x-patch, Size: 2009 bytes --]
From 54768360aa7b1882dd2b76211661abb6014cbf23 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 12 Aug 2009 16:26:31 -0500
Subject: [PATCH 1/3] port --ignore-unmatch from "git rm" to "git add"
---
builtin-add.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 581a2a1..0597fb9 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -19,6 +19,7 @@ static const char * const builtin_add_usage[] = {
};
static int patch_interactive, add_interactive, edit_interactive;
static int take_worktree_changes;
+static int ignore_unmatch = 0;
static void fill_pathspec_matches(const char **pathspec, char *seen, int specs)
{
@@ -63,7 +64,7 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
fill_pathspec_matches(pathspec, seen, specs);
for (i = 0; i < specs; i++) {
- if (!seen[i] && pathspec[i][0] && !file_exists(pathspec[i]))
+ if (!seen[i] && pathspec[i][0] && !file_exists(pathspec[i]) && !ignore_unmatch)
die("pathspec '%s' did not match any files",
pathspec[i]);
}
@@ -108,7 +109,7 @@ static void refresh(int verbose, const char **pathspec)
refresh_index(&the_index, verbose ? REFRESH_SAY_CHANGED : REFRESH_QUIET,
pathspec, seen);
for (i = 0; i < specs; i++) {
- if (!seen[i])
+ if (!seen[i] && !ignore_unmatch)
die("pathspec '%s' did not match any files", pathspec[i]);
}
free(seen);
@@ -226,6 +227,8 @@ static struct option builtin_add_options[] = {
OPT_BOOLEAN('A', "all", &addremove, "add all, noticing removal of tracked files"),
OPT_BOOLEAN( 0 , "refresh", &refresh_only, "don't add, only refresh the index"),
OPT_BOOLEAN( 0 , "ignore-errors", &ignore_add_errors, "just skip files which cannot be added because of errors"),
+ OPT_BOOLEAN( 0 , "ignore-unmatch", &ignore_unmatch,
+ "exit with a zero status even if nothing matched"),
OPT_END(),
};
--
1.6.3.3
[-- Attachment #3: 0002-fix-git-add-ignore-errors-to-ignore-pathspec-errors.patch --]
[-- Type: text/x-patch, Size: 761 bytes --]
From c6cd06db8ab3b198eafffd5b0e94d2f338f10072 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 12 Aug 2009 16:31:37 -0500
Subject: [PATCH 2/3] fix "git add --ignore-errors" to ignore pathspec errors
---
builtin-add.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 0597fb9..e3132c8 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -280,6 +280,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)
add_interactive = 1;
if (add_interactive)
exit(interactive_add(argc - 1, argv + 1, prefix));
+ if (ignore_add_errors)
+ ignore_unmatch = 1;
if (edit_interactive)
return(edit_patch(argc, argv, prefix));
--
1.6.3.3
[-- Attachment #4: 0003-Document-ignore-unmatch-in-git-add.txt.patch --]
[-- Type: text/x-patch, Size: 1217 bytes --]
From 410a93cb61669304a0b1d10b8013d1635432e8a0 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 12 Aug 2009 17:23:44 -0500
Subject: [PATCH 3/3] Document --ignore-unmatch in git-add.txt
---
Documentation/git-add.txt | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index ab1943c..6b93b4e 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -10,7 +10,8 @@ SYNOPSIS
[verse]
'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
[--edit | -e] [--all | [--update | -u]] [--intent-to-add | -N]
- [--refresh] [--ignore-errors] [--] <filepattern>...
+ [--refresh] [--ignore-errors] [--ignore-unmatch] [--]
+ <filepattern>...
DESCRIPTION
-----------
@@ -119,6 +120,9 @@ apply.
them, do not abort the operation, but continue adding the
others. The command shall still exit with non-zero status.
+--ignore-unmatch::
+ Exit with a zero status even if no files matched.
+
\--::
This option can be used to separate command-line options from
the list of files, (useful when filenames might be mistaken
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Change mentions of "git programs" to "git commands"
From: Junio C Hamano @ 2009-08-12 22:39 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Ori Avtalion
In-Reply-To: <20090811125813.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> I copy-edited Ori's patch for your convenience, and tried to clarify
> the criteria you used to decide which "program" should become "command"
> in the updated commit log message, in case you forgot to apply it
> yourself.
>
> I just didn't want to see the time you and others spent on submitting
> and reviewing wasted due to lack of resubmission of a revised patch.
Very thoughtful. I appreciate your occasional "playing a capable project
secretary", and I wish I see more like you.
Indeed I've been swamped, and I tend to leave the final wrapping up to the
original submitter and then forget.
Thanks.
^ permalink raw reply
* Re: fatal: bad revision 'HEAD'
From: Junio C Hamano @ 2009-08-12 22:49 UTC (permalink / raw)
To: Jeff King; +Cc: Joel Mahoney, Johannes Schindelin, git
In-Reply-To: <20090812075833.GF15152@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Yeah, I think that is a better idea. Do you want to tweak the patch, or
> should I re-submit?
I'll do this then.
-- >8 --
From: Jeff King <peff@peff.net>
Date: Tue, 11 Aug 2009 23:27:40 -0400
Subject: [PATCH] Subject: [PATCH] allow pull --rebase on branch yet to be born
When doing a "pull --rebase", we check to make sure that the index and
working tree are clean. The index-clean check compares the index against
HEAD. The test erroneously reports dirtiness if we don't have a HEAD yet.
In such an "unborn branch" case, by definition, a non-empty index won't
be based on whatever we are pulling down from the remote, and will lose
the local change. Just check if $GIT_DIR/index exists and error out.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-pull.sh | 18 +++++++++++++-----
t/t5520-pull.sh | 11 +++++++++++
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 0f24182..0bbd5bf 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -119,11 +119,19 @@ error_on_no_merge_candidates () {
}
test true = "$rebase" && {
- git update-index --ignore-submodules --refresh &&
- git diff-files --ignore-submodules --quiet &&
- git diff-index --ignore-submodules --cached --quiet HEAD -- ||
- die "refusing to pull with rebase: your working tree is not up-to-date"
-
+ if ! git rev-parse -q --verify HEAD >/dev/null
+ then
+ # On an unborn branch
+ if test -f "$GIT_DIR/index"
+ then
+ die "updating an unborn branch with changes added to the index"
+ fi
+ else
+ git update-index --ignore-submodules --refresh &&
+ git diff-files --ignore-submodules --quiet &&
+ git diff-index --ignore-submodules --cached --quiet HEAD -- ||
+ die "refusing to pull with rebase: your working tree is not up-to-date"
+ fi
oldremoteref= &&
. git-parse-remote &&
remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" &&
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index e78d402..dd2ee84 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -149,4 +149,15 @@ test_expect_success 'pull --rebase dies early with dirty working directory' '
'
+test_expect_success 'pull --rebase works on branch yet to be born' '
+ git rev-parse master >expect &&
+ mkdir empty_repo &&
+ (cd empty_repo &&
+ git init &&
+ git pull --rebase .. master &&
+ git rev-parse HEAD >../actual
+ ) &&
+ test_cmp expect actual
+'
+
test_done
--
1.6.4.196.gd1fd8
^ permalink raw reply related
* Re: For review: git add --ignore-unmatch
From: Thomas Rast @ 2009-08-12 22:57 UTC (permalink / raw)
To: Luke-Jr; +Cc: git
In-Reply-To: <200908121726.52121.luke-jr@utopios.org>
Luke-Jr wrote:
>
> [0001-port-ignore-unmatch-from-git-rm-to-git-add.patch]
> [0002-fix-git-add-ignore-errors-to-ignore-pathspec-errors.patch]
> [0003-Document-ignore-unmatch-in-git-add.txt.patch]
I've already told you on IRC how to go about this, so please:
* send one patch per mail, inline
* write real commit messages
* sign off
* write tests
[Yeah, I'm tired and grumpy, but I'm also trying to save others the
work of saying this again more politely...]
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC/PATCH 2/6] transport_get(): Don't SEGFAULT on missing url
From: Johan Herland @ 2009-08-12 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, barkalow, benji, Johannes.Schindelin
In-Reply-To: <7vab24wtzo.fsf@alter.siamese.dyndns.org>
On Thursday 13 August 2009, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > Signed-off-by: Johan Herland <johan@herland.net>
>
> How does url end up to be NULL? At the beginning of transport_get(), you
> do this:
>
> ret->remote = remote;
> if (!url && remote && remote->url)
> url = remote->url[0];
> ret->url = url;
> if (remote && remote->foreign_vcs) {
> transport_helper_init(ret);
> return ret;
> }
>
> and the case where remote.$name.vcs is defined, we do not need
> remote.$name.url.
>
> When (!url && remote && remote->url), is remote->url[0] allowed to be
> NULL? I am guessing it would be a bug in whoever prepared the remote,
> and if that is indeed the case, the patch shifts the symptoms without
> fixing the cause.
>
> When (remote && remote->foreign_vcs) does not hold, iow, if no remote is
> defined or the remote is defined but lacks remote.$name.url, you will go
> to the last else clause in the function that sets up a git_transport_data
> for the native transport, but it has ret->url == NULL.
>
> Whom does that transport talk with? Is such a transport of any use, or
> does it cause a segfault downstream in the call chain?
>
> In other words, I am wondering if this patch should just diagnose the
> case as an error, instead of pretending all is well.
You are right. Instead of pushing the segfault downstream, we should verify
that the url is non-NULL before returning it as part of ret (modulo the
foreign case, of course).
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [RFCv3 2/4] Add Python support library for CVS remote helper
From: Michael Haggerty @ 2009-08-13 0:00 UTC (permalink / raw)
To: Johan Herland; +Cc: David Aguilar, git, barkalow, gitster, Johannes.Schindelin
In-Reply-To: <200908121108.28714.johan@herland.net>
Johan Herland wrote:
> On Wednesday 12 August 2009, David Aguilar wrote:
>> On Wed, Aug 12, 2009 at 02:13:49AM +0200, Johan Herland wrote:
>>> + def __init__ (self, date, author, message):
>>> + self.revs = {} # dict: path -> CvsRev object
>>> + self.date = date # CvsDate object
>>> + self.author = author
>>> + self.message = message # Lines of commit message
>> pep8 and other parts of the git codebase recommend against
>> lining up the equals signs like that. Ya, sorry for the nits
>> being that they're purely stylistic.
>
> I can't find a good rationale for this rule in PEP8 (other than Guido's
> personal style), and I personally find the above much more readable
> (otherwise I wouldn't go through the trouble of lining them all up...). Can
> I claim exception (1) (readability)?
I think you are missing the point. It may be true that the rules in
PEP8 were *originally* written according to the unjustified whims of the
BDFL, but now that they are established the reason for following them is
not that Guido likes them but rather to be consistent with the bulk of
other Python code on the planet.
With respect to the rule to use 4-space indents, there are serious
practical problems with using tabs *in addition to* the consistency
argument.
Michael
^ permalink raw reply
* Re: [RFCv3 2/4] Add Python support library for CVS remote helper
From: Johan Herland @ 2009-08-13 0:20 UTC (permalink / raw)
To: Michael Haggerty
Cc: David Aguilar, git, barkalow, gitster, Johannes.Schindelin,
Sverre Rabbelier
In-Reply-To: <4A83579E.70302@alum.mit.edu>
On Thursday 13 August 2009, Michael Haggerty wrote:
> Johan Herland wrote:
> > On Wednesday 12 August 2009, David Aguilar wrote:
> >> On Wed, Aug 12, 2009 at 02:13:49AM +0200, Johan Herland wrote:
> >>> + def __init__ (self, date, author, message):
> >>> + self.revs = {} # dict: path -> CvsRev object
> >>> + self.date = date # CvsDate object
> >>> + self.author = author
> >>> + self.message = message # Lines of commit message
> >>
> >> pep8 and other parts of the git codebase recommend against
> >> lining up the equals signs like that. Ya, sorry for the nits
> >> being that they're purely stylistic.
> >
> > I can't find a good rationale for this rule in PEP8 (other than Guido's
> > personal style), and I personally find the above much more readable
> > (otherwise I wouldn't go through the trouble of lining them all up...).
> > Can I claim exception (1) (readability)?
>
> I think you are missing the point. It may be true that the rules in
> PEP8 were *originally* written according to the unjustified whims of the
> BDFL, but now that they are established the reason for following them is
> not that Guido likes them but rather to be consistent with the bulk of
> other Python code on the planet.
Ok. I will try to follow PEP8 as closely as possible.
> With respect to the rule to use 4-space indents, there are serious
> practical problems with using tabs *in addition to* the consistency
> argument.
There are? What arguments? Assuming I don't mix spaces and tabs (which I
certainly don't), I can't see any "practical problems" with using tabs
(except for the PEP8/consistency issue).
...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