* Re: [PATCH] Add configuration variable for sign-off to format-patch
From: Jeff King @ 2009-03-31 20:04 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Junio C Hamano
In-Reply-To: <20090331185018.GD72569@macbook.lan>
On Tue, Mar 31, 2009 at 08:50:19PM +0200, Heiko Voigt wrote:
> If you regularly create patches which require a Signed-off: line you may
> want to make it your default to add that line. It also helps you not to forget
> to add the -s/--signoff switch.
I personally have no problem with such an option, but it has been argued
against before. E.g.:
http://article.gmane.org/gmane.comp.version-control.git/32522
http://article.gmane.org/gmane.comp.version-control.git/51780
There is also some discussion here indicating that it might be accepted:
http://article.gmane.org/gmane.comp.version-control.git/103939
-Peff
^ permalink raw reply
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: byrnejb @ 2009-03-31 20:17 UTC (permalink / raw)
To: git
In-Reply-To: <76718490903130918r733e3ef4meae49311883969b5@mail.gmail.com>
Hi,
I am attempting to build git-1.6.2-1 on CentOS5.3 and running into this problem:
parser error : PCDATA invalid Char value 7
I am using asciidoc-8.4.1 and yesterday, when I first built git from the src rpm, the process completed without error. The only thing that has happened to the build system since then is an update of perl packages from epel. I do not see how that would affect anything, but I include the information for completeness nonetheless.
In any case, I can live without the documentation if that will get the application built. I have tried the suggestions with respect to setting ENV variables without success:
$ set
ASCIIDOC8=YesPlease
...
DOCBOOK_XSL_172=YesPlease
So, have I misunderstood the instructions given here? Is there something else I should do? Is there a way to simply skip the documentation part of the build?
--
View this message in context: http://n2.nabble.com/git-doc-build-failure-on-OS-X-10.5.6-%28Leopard%29-during-xmlto-phase-tp2461534p2565224.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* strbuf name conflict on Mac OS
From: Joshua Juran @ 2009-03-31 20:17 UTC (permalink / raw)
To: git
Apple's OpenTransport.h from Universal Interfaces 3.4.2 defines its
own struct strbuf, with which git's collides.
Since OpenTransport.h also defines some POSIX constants (such as
O_NONBLOCK) as enums, it's necessary to include OpenTransport.h from
fcntl.h (and other affected headers) so as to control the order in
which the definitions appear in the translation unit.
This is the minimal patch:
diff --git a/strbuf.h b/strbuf.h
index 89bd36e..b8f380e 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -40,6 +40,8 @@
#include <assert.h>
+#define strbuf git_strbuf
+
extern char strbuf_slopbuf[];
struct strbuf {
size_t alloc;
Josh
^ permalink raw reply related
* Re: strbuf name conflict on Mac OS
From: Johannes Schindelin @ 2009-03-31 20:24 UTC (permalink / raw)
To: Joshua Juran; +Cc: git
In-Reply-To: <E5D92A5D-B2CC-44CE-B117-0BB88C0E663E@gmail.com>
Hi,
On Tue, 31 Mar 2009, Joshua Juran wrote:
> Apple's OpenTransport.h from Universal Interfaces 3.4.2 defines its own struct
> strbuf, with which git's collides.
>
> Since OpenTransport.h also defines some POSIX constants (such as O_NONBLOCK)
> as enums, it's necessary to include OpenTransport.h from fcntl.h (and other
> affected headers) so as to control the order in which the definitions appear
> in the translation unit.
>
> This is the minimal patch:
>
>
> diff --git a/strbuf.h b/strbuf.h
> index 89bd36e..b8f380e 100644
> --- a/strbuf.h
> +++ b/strbuf.h
> @@ -40,6 +40,8 @@
>
> #include <assert.h>
>
> +#define strbuf git_strbuf
> +
> extern char strbuf_slopbuf[];
> struct strbuf {
> size_t alloc;
How about this instead?
-- snip --
diff --git a/Makefile b/Makefile
index 32d6782..370c2d9 100644
--- a/Makefile
+++ b/Makefile
@@ -659,6 +659,7 @@ ifeq ($(uname_S),SCO_SV)
TAR = gtar
endif
ifeq ($(uname_S),Darwin)
+ BASIC_CFLAGS += -Dstrbuf=git_strbuf
NEEDS_SSL_WITH_CRYPTO = YesPlease
NEEDS_LIBICONV = YesPlease
ifeq ($(shell expr "$(uname_R)" : '[15678]\.'),2)
-- snap --
No need to let other platforms (and the C source) suffer...
Ciao,
Dscho
^ permalink raw reply related
* Re: bsd group semantics
From: Junio C Hamano @ 2009-03-31 20:26 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, git
In-Reply-To: <20090331184604.GA10701@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Mar 31, 2009 at 10:32:14AM -0700, Junio C Hamano wrote:
>
>> My point was if I belong only to my personal group and git.git work tree
>> is owned by junio.junio to begin with, you would never be able to notice
>> any breakage with such a test.
>
> Ah, I see. Yes, you would need to belong to at least two groups to make
> such a test feasible.
>
> Such a requirement is generally outside the scope of running the
> test suite; do you want to just ditch the g+s test, then, or do you want
> me to work up something conditional based on the Makefile flag?
For now, I'd suggest teaching the test not to care about g+s bit.
After all, they are about giving correct mode bits to files and
directories. Correct mode bits for group do not mean anything if you make
them owned by a wrong group, but that is not something we have tested so
far, and can be a separate test anyway.
^ permalink raw reply
* Re: strbuf name conflict on Mac OS
From: Brian Gernhardt @ 2009-03-31 20:26 UTC (permalink / raw)
To: Joshua Juran; +Cc: git
In-Reply-To: <E5D92A5D-B2CC-44CE-B117-0BB88C0E663E@gmail.com>
On Mar 31, 2009, at 4:17 PM, Joshua Juran wrote:
> Apple's OpenTransport.h from Universal Interfaces 3.4.2 defines its
> own struct strbuf, with which git's collides.
>
> Since OpenTransport.h also defines some POSIX constants (such as
> O_NONBLOCK) as enums, it's necessary to include OpenTransport.h from
> fcntl.h (and other affected headers) so as to control the order in
> which the definitions appear in the translation unit.
Just to be clear, this is related to your work on LAMP under Classic
and not OS X, correct? If so, perhaps you need to create a compat/
classic_mac.h file that's included (when the correct #defines are
seen) from git-compat-util.h in the manner of compat/
{cygwin,mingw}.h. I'm assuming that this naming conflict is not the
only such you'll find and it's better to keep platform specific tweaks
to a single place when possible.
~~ Brian
^ permalink raw reply
* Re: Implementing stat() with FindFirstFile()
From: Magnus Bäck @ 2009-03-31 20:32 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Heiko Voigt, Björn Steinbrink, Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0903310128410.10279@pacific.mpi-cbg.de>
On Tuesday, March 31, 2009 at 01:29 CEST,
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 31 Mar 2009, Heiko Voigt wrote:
>
> > On Mon, Mar 30, 2009 at 07:11:18AM +0200, Björn Steinbrink wrote:
> >
> > > Not official documentation, but at least from some MS guy it seems:
> > > http://www.osronline.com/showThread.cfm?link=73086 (last message).
> > >
> > > Apparently, it was in NT3.x, but they document only what's actually
> > > defined in the header.
> >
> > How about runtime checking? You could do GetProcAddress(...) and if
> > you don't get it use the old behaviour. I mean if it really is
> > faster why not let Users of recent systems benefit from it.
>
> While my first reaction was negative, I have to admit that thinking
> about it longer, it does seem to make a whole lot of sense.
If anything worries me it's forward compatibility should Microsoft
change the function signature. Backwards compatibility can always
be guaranteed by using GetProcAddress(). Again, I would be very
surprised but IF it could be quite fatal.
Anyway, we don't know for sure if it's faster or if it fixes the DST
problem of FindFirstFile(). I'll write some code to try it out.
--
Magnus Bäck
baeck@swipnet.se
^ permalink raw reply
* Re: bsd group semantics
From: Jeff King @ 2009-03-31 20:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vy6ul4exy.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 31, 2009 at 01:26:01PM -0700, Junio C Hamano wrote:
> For now, I'd suggest teaching the test not to care about g+s bit.
> After all, they are about giving correct mode bits to files and
> directories. Correct mode bits for group do not mean anything if you make
> them owned by a wrong group, but that is not something we have tested so
> far, and can be a separate test anyway.
Makes sense. How about this?
-- >8 --
Subject: [PATCH] t1301: loosen test for forced modes
One of the aspects of the test checked explicitly for the
g+s bit to be set on created directories. However, this is
only the means to an end (the "end" being having the correct
group set). And in fact, on systems where
DIR_HAS_BSD_GROUP_SEMANTICS is set, we do not even need to
use this "means" at all, causing the test to fail.
This patch removes that part of the test. In an ideal world
it would be replaced by a test to check that the group was
properly assigned, but that is difficult to automate because
it requires the user running the test suite be a member of
multiple groups.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t1301-shared-repo.sh | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
index 11ef302..9b18507 100755
--- a/t/t1301-shared-repo.sh
+++ b/t/t1301-shared-repo.sh
@@ -147,9 +147,6 @@ test_expect_success 'forced modes' '
# Everything must be unaccessible to others
test -z "$(sed -n -e "/^.......---/d" actual)" &&
- # All directories must have 2770
- test -z "$(sed -n -e "/^drwxrws---/d" -e "/^d/p" actual)" &&
-
# post-update hook must be 0770
test -z "$(sed -n -e "/post-update/{
/^-rwxrwx---/d
--
1.6.2.1.591.geb450
^ permalink raw reply related
* GSoC 2009 - Students - Submit Your Proposals...
From: Shawn O. Pearce @ 2009-03-31 20:37 UTC (permalink / raw)
To: git
If you are student who is considering applying for Google Summer of
Code 2009... please submit at least a draft proposal sooner rather
than later. You can still update it after submission, but you need
to submit a proposal to be considered.
Remember the deadline is April 3rd 19:00 UTC (this Saturday),
and a deadline extension isn't likely.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Add configuration variable for sign-off to format-patch
From: Heiko Voigt @ 2009-03-31 20:43 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20090331200457.GA23879@coredump.intra.peff.net>
On Tue, Mar 31, 2009 at 04:04:57PM -0400, Jeff King wrote:
> On Tue, Mar 31, 2009 at 08:50:19PM +0200, Heiko Voigt wrote:
>
> > If you regularly create patches which require a Signed-off: line you may
> > want to make it your default to add that line. It also helps you not to forget
> > to add the -s/--signoff switch.
>
> I personally have no problem with such an option, but it has been argued
> against before. E.g.:
>
> http://article.gmane.org/gmane.comp.version-control.git/32522
> http://article.gmane.org/gmane.comp.version-control.git/51780
>
> There is also some discussion here indicating that it might be accepted:
>
> http://article.gmane.org/gmane.comp.version-control.git/103939
I see, it is of course true that you should not just sign off
everything without thinking about it.
However I always read through my messages before sending them and it is
way easier to delete that line than typing/copying it.
I suppose if A changes a patch which originated from B he also needs to
be nice and delete that the sign-off line from B (at least initially).
I don't know but if I am preparing to send a patch and *see* my
signed-off line in the message I am conscious about it! I see this more
as another customization. Some people tend to forget to add the
signed-off and others might tend to forget to delete it. It should be on
you to find out what type you are.
cheers Heiko
^ permalink raw reply
* Re: Implementing stat() with FindFirstFile()
From: Johannes Schindelin @ 2009-03-31 20:49 UTC (permalink / raw)
To: Magnus Bäck; +Cc: Heiko Voigt, Björn Steinbrink, Johannes Sixt, git
In-Reply-To: <20090331203248.GE27249@jeeves.jpl.local>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1351 bytes --]
Hi,
On Tue, 31 Mar 2009, Magnus Bäck wrote:
> On Tuesday, March 31, 2009 at 01:29 CEST,
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Tue, 31 Mar 2009, Heiko Voigt wrote:
> >
> > > On Mon, Mar 30, 2009 at 07:11:18AM +0200, Björn Steinbrink wrote:
> > >
> > > > Not official documentation, but at least from some MS guy it seems:
> > > > http://www.osronline.com/showThread.cfm?link=73086 (last message).
> > > >
> > > > Apparently, it was in NT3.x, but they document only what's actually
> > > > defined in the header.
> > >
> > > How about runtime checking? You could do GetProcAddress(...) and if
> > > you don't get it use the old behaviour. I mean if it really is
> > > faster why not let Users of recent systems benefit from it.
> >
> > While my first reaction was negative, I have to admit that thinking
> > about it longer, it does seem to make a whole lot of sense.
>
> If anything worries me it's forward compatibility should Microsoft
> change the function signature. Backwards compatibility can always
> be guaranteed by using GetProcAddress(). Again, I would be very
> surprised but IF it could be quite fatal.
>
> Anyway, we don't know for sure if it's faster or if it fixes the DST
> problem of FindFirstFile(). I'll write some code to try it out.
Thank you very much, I appreciate it!
Ciao,
Dscho
^ permalink raw reply
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: byrnejb @ 2009-03-31 20:56 UTC (permalink / raw)
To: git
In-Reply-To: <1238530620384-2565224.post@n2.nabble.com>
Is there a way to simply skip the documentation part of the build?
$ rpmbuild -bb --without docs git.spec # this gets me the application at least.
Is there a fix or workaroung to get past the asciidoc error?
--
View this message in context: http://n2.nabble.com/git-doc-build-failure-on-OS-X-10.5.6-%28Leopard%29-during-xmlto-phase-tp2461534p2565413.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Git, C89, and older compilers
From: Jay Soffian @ 2009-03-31 21:32 UTC (permalink / raw)
To: Joshua Juran; +Cc: git
In-Reply-To: <9D199AAA-5EC6-4E7C-AC26-0CDA68341D00@gmail.com>
On Tue, Mar 31, 2009 at 3:26 PM, Joshua Juran <jjuran@gmail.com> wrote:
> Hello,
>
> I'm porting Git to Lamp (Lamp ain't Mac POSIX), a Unix-like environment
> which runs in classic Mac OS, much like Cygwin.
Call it morbid curiosity, but, why? (If I had to guess, I'd assume a
George Mallory answer.)
j.
^ permalink raw reply
* Re: bsd group semantics
From: Junio C Hamano @ 2009-03-31 21:33 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, git
In-Reply-To: <20090331203600.GA24340@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Mar 31, 2009 at 01:26:01PM -0700, Junio C Hamano wrote:
>
>> For now, I'd suggest teaching the test not to care about g+s bit.
>> After all, they are about giving correct mode bits to files and
>> directories. Correct mode bits for group do not mean anything if you make
>> them owned by a wrong group, but that is not something we have tested so
>> far, and can be a separate test anyway.
>
> Makes sense. How about this?
>
> -- >8 --
> Subject: [PATCH] t1301: loosen test for forced modes
>
> One of the aspects of the test checked explicitly for the
> g+s bit to be set on created directories. However, this is
> only the means to an end (the "end" being having the correct
> group set). And in fact, on systems where
> DIR_HAS_BSD_GROUP_SEMANTICS is set, we do not even need to
> use this "means" at all, causing the test to fail.
>
> This patch removes that part of the test. In an ideal world
> it would be replaced by a test to check that the group was
> properly assigned, but that is difficult to automate because
> it requires the user running the test suite be a member of
> multiple groups.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> t/t1301-shared-repo.sh | 3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
> index 11ef302..9b18507 100755
> --- a/t/t1301-shared-repo.sh
> +++ b/t/t1301-shared-repo.sh
> @@ -147,9 +147,6 @@ test_expect_success 'forced modes' '
> # Everything must be unaccessible to others
> test -z "$(sed -n -e "/^.......---/d" actual)" &&
>
> - # All directories must have 2770
> - test -z "$(sed -n -e "/^drwxrws---/d" -e "/^d/p" actual)" &&
Did you mean
- # All directories must have 2770
- test -z "$(sed -n -e "/^drwxrws---/d" -e "/^d/p" actual)" &&
+ # All directories must have either 2770 or 770
+ test -z "$(sed -n -e "/^drwxrw[sx]---/d" -e "/^d/p" actual)" &&
> -
> # post-update hook must be 0770
> test -z "$(sed -n -e "/post-update/{
> /^-rwxrwx---/d
> --
> 1.6.2.1.591.geb450
^ permalink raw reply
* Re: strbuf name conflict on Mac OS
From: Jay Soffian @ 2009-03-31 21:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Joshua Juran, git
In-Reply-To: <alpine.DEB.1.00.0903312222440.6616@intel-tinevez-2-302>
On Tue, Mar 31, 2009 at 4:24 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> How about this instead?
> ifeq ($(uname_S),Darwin)
> + BASIC_CFLAGS += -Dstrbuf=git_strbuf
Heh, wrong platform. See Joshua's other message about porting git to
Mac OS (not Mac OS X). :-)
j.
^ permalink raw reply
* Re: strbuf name conflict on Mac OS
From: Joshua Juran @ 2009-03-31 21:57 UTC (permalink / raw)
To: Jay Soffian; +Cc: Johannes Schindelin, git
In-Reply-To: <76718490903311436p5fe81ce3k31f18170d9388e8e@mail.gmail.com>
On Mar 31, 2009, at 2:36 PM, Jay Soffian wrote:
> On Tue, Mar 31, 2009 at 4:24 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> How about this instead?
>> ifeq ($(uname_S),Darwin)
>> + BASIC_CFLAGS += -Dstrbuf=git_strbuf
>
> Heh, wrong platform. See Joshua's other message about porting git to
> Mac OS (not Mac OS X). :-)
That, and I'm not using make. There's no need for this to be any
more painful than necessary. :-)
I've added compat/lamp.h, following Brian's suggestion.
Josh
^ permalink raw reply
* Re: [PATCH 6/8 v2] sh-tools: add a run_merge_tool function
From: Markus Heidelberg @ 2009-03-31 22:11 UTC (permalink / raw)
To: James Pickens; +Cc: David Aguilar, gitster, git
In-Reply-To: <885649360903311115o6131988emdcba6ef215ec0ab0@mail.gmail.com>
James Pickens, 31.03.2009:
> On Mon, Mar 30, 2009 at 1:11 AM, David Aguilar <davvid@gmail.com> wrote:
> > This function launches merge tools and will be used to refactor
> > git-(diff|merge)tool.
>
> Thanks for writing difftool; I find it quite useful. I tried it with
> tkdiff, and noticed that it shows the 'merge preview' window even though it
> isn't doing a merge. If a user with unstaged changes were to carelessly
> click the 'save and exit' button, his changes could be lost. So I think
> it's a good idea to stop the merge preview window from showing up under
> difftool. To do that I think you just have to remove the '-o "$MERGED"'
> option to tkdiff.
This mail made me see an issue with your patch series. Sorry, I haven't
seen this earlier, my review was just scratching the surface, I merely
applied it and looked through it, but didn't actually test it. Lack of
time.
The invocations seem to be appropriate only for mergetool, it is just
the invocations from the old git-mergetool.sh, not from the old
git-difftool-helper.sh. This means, git-difftool opens 3 files instead
of 2.
I think there are preset diff tools, which opened 3 files instead of 2
before this series (I just tested kdiff3, it opened 3 files). Seems to
be originated from the fact, that they were initially copied from
git-mergetool.sh.
Markus
^ permalink raw reply
* Re: [PATCHv3 1/6] pretty.c: add %f format specifier to format_commit_message()
From: René Scharfe @ 2009-03-31 22:17 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano
In-Reply-To: <baa327d88b54efae40b6d9df09a2fe482672101e.1237773604.git.bebarino@gmail.com>
Stephen Boyd schrieb:
> This specifier represents the sanitized and filename friendly subject
> line of a commit. No checks are made against the length of the string,
> so users may need to trim the result to the desired length if using as a
> filename. This is commonly used by format-patch to massage commit
> subjects into filenames and output patches to files.
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
> Documentation/pretty-formats.txt | 1 +
> pretty.c | 38 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 39 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
> index 5c6e678..2a845b1 100644
> --- a/Documentation/pretty-formats.txt
> +++ b/Documentation/pretty-formats.txt
> @@ -121,6 +121,7 @@ The placeholders are:
> - '%d': ref names, like the --decorate option of linkgit:git-log[1]
> - '%e': encoding
> - '%s': subject
> +- '%f': sanitized subject line, suitable for a filename
> - '%b': body
> - '%Cred': switch color to red
> - '%Cgreen': switch color to green
> diff --git a/pretty.c b/pretty.c
> index efa7024..97de415 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -493,6 +493,41 @@ static void parse_commit_header(struct format_commit_context *context)
> context->commit_header_parsed = 1;
> }
>
> +static int istitlechar(char c)
> +{
> + return (c >= 'a' && c <= 'z') || (c >= 'A' && c <= 'Z') ||
> + (c >= '0' && c <= '9') || c == '.' || c == '_';
How about this?
return isalnum(c) || c == '.' || c == '_';
> +}
> +
> +static void format_sanitized_subject(struct strbuf *sb, const char *msg)
> +{
> + size_t trimlen;
> + int space = 0;
> +
> + for (; *msg && *msg != '\n'; msg++) {
> + if (istitlechar(*msg))
> + {
> + if (space) {
> + strbuf_addch(sb, '-');
> + space = 0;
> + }
> + strbuf_addch(sb, *msg);
> + if (*msg == '.')
> + while (*(msg+1) == '.')
> + msg++;
> + }
> + else
> + space = 1;
> + }
> +
> + // trim any trailing '.' or '-' characters
> + trimlen = 0;
> + while (sb->buf[sb->len - 1 - trimlen] == '.'
> + || sb->buf[sb->len - 1 - trimlen] == '-')
> + trimlen++;
> + strbuf_remove(sb, sb->len - trimlen, trimlen);
You need to make sure that trimming stops as soon as the strbuf has been
shortened to its original length. E.g. for a subject line of "..."
you'd access the char before the first dot currently, or sb->buf[-1] if
the strbuf was empty initially.
(One could also check for sb->len > 0 to just prevent the buffer
underrun, but %f sometimes eating preceding dots and dashes is
counter-intuitive to me.)
> +}
> +
> const char *format_subject(struct strbuf *sb, const char *msg,
> const char *line_separator)
> {
> @@ -683,6 +718,9 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
> case 's': /* subject */
> format_subject(sb, msg + c->subject_off, " ");
> return 1;
> + case 'f': /* sanitized subject */
> + format_sanitized_subject(sb, msg + c->subject_off);
> + return 1;
> case 'b': /* body */
> strbuf_addstr(sb, msg + c->body_off);
> return 1;
^ permalink raw reply
* Re: Git, C89, and older compilers
From: Joshua Juran @ 2009-03-31 22:22 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718490903311432l7fba411fw4a0afff10fdf3da4@mail.gmail.com>
On Mar 31, 2009, at 2:32 PM, Jay Soffian wrote:
> On Tue, Mar 31, 2009 at 3:26 PM, Joshua Juran <jjuran@gmail.com>
> wrote:
>> Hello,
>>
>> I'm porting Git to Lamp (Lamp ain't Mac POSIX), a Unix-like
>> environment
>> which runs in classic Mac OS, much like Cygwin.
>
> Call it morbid curiosity, but, why? (If I had to guess, I'd assume a
> George Mallory answer.)
Well, there's a degree of that.
Even more succinctly, I could add "inertia". I started writing a
replacement for Apple's MPW (one that would actually be useful for
real work) over ten years ago, and never reached a point where I was
ready to quit, even after switching to OS X.
Admittedly, there's an element of retro-programming. I want to see
how far I can go with this. (One of my major hurdles will be git's
use of fork().)
But there's also a sense of awe and wonder in knowing that I'm (most
probably) the only person in the world working on such a project.
Finally, I've begun using it as a research platform. With
inspiration from Plan 9, I'm mapping the GUI into the filesystem, so
you can write an application as a collection of shell scripts.
Josh
^ permalink raw reply
* Re: bsd group semantics
From: Jeff King @ 2009-03-31 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vr60d4btl.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 31, 2009 at 02:33:26PM -0700, Junio C Hamano wrote:
> > - # All directories must have 2770
> > - test -z "$(sed -n -e "/^drwxrws---/d" -e "/^d/p" actual)" &&
>
> Did you mean
>
> - # All directories must have 2770
> - test -z "$(sed -n -e "/^drwxrws---/d" -e "/^d/p" actual)" &&
> + # All directories must have either 2770 or 770
> + test -z "$(sed -n -e "/^drwxrw[sx]---/d" -e "/^d/p" actual)" &&
No, I meant what I said, but I was wrong. ;) I was thinking that bit
only tested for one thing, but it was actually testing for two. Sorry.
Can you fix it up when you apply, then?
-Peff
^ permalink raw reply
* Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]
From: P Baker @ 2009-03-31 22:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.DEB.1.00.0903311749160.7052@intel-tinevez-2-302>
Thanks for the comments, my replies are included. It's good to see
some core folks are big users!
On Tue, Mar 31, 2009 at 11:57 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> I am a rather intense user of submodules, so I am quite interested.
>
I'm curious, where/under what circumstances do you tend to use it?
> Please take my comments as encouragement rather than discouragement.
>
Always.
>> *move objects of submodules into base .git/ directory
>> **This would, as I understand it: protect submodules from being
>> overwritten and changes lost when switching between branches of the
>> superproject that might or might not contain the submodules and
>> centralize their management into one location. The added benefits of
>> fully using git's ability to branch and merge submodules makes it
>> worth adding some complexity within the .git directory.
>
> The main problem with renaming/deleting is not the repository of the
> submodule, but the working directoy.
>
My understanding is that since the submodule objects (history) is
stored in a .git directory in the subdirectory where the submodule is
located, removing that subdirectory during checkout of a branch that
does not include that submodule eliminates the .git directory as well.
Moving the objects from the submodule's .git directory to the base
.git directory would seem to alleviate this problem.
>> *use .git instead of .gitmodules
>> **I actually don't know why this was included with the project
>> description, I searched for an explanation of the desired name change
>> on the mailing list and in commit messages, but came up with nothing.
>
> AFAICT somebody thought that the information about the locations of the
> submodules should be in .git/ rather than in the working directory. But
> of course, that is wrong: you want it to be tracked.
>
So, in looking back through the archives of the mailing list there
seems to be some disagreement between using .gitmodules and
.git/config to track submodules.
>> *git submodule update --init should initialize nested levels of submodules
>> **As an ease of use command, either an additional flag to recurse can
>> be added, or it can act by default. As a requested feature on the
>> mailing list, this is worth implementing.
>
> I thought there was a patch to support "git submodule recurse"? That
> would be rather less limited than yet another option to submodule update.
>
There is a git submodule foreach command, but it doesn't look like the
patch for git submodule recurse
(http://marc.info/?l=git&m=120997867213008&w=2) has been incorporated
into a public release.
That is one route, on the other hand, the default action is also open
to question. When I update a submodule, I would probably expect that
anything it depends on is also updated. The default action probably
should be recursive.
>> *ability to update submodule pulled from svn repo
>> **One workaround is to clone it as local copy using git-svn and then
>> import that local clone as a submodule; clearly a clunky solution.
>> There are many requests for this feature (see
>> http://panthersoftware.com/articles/view/4/git-svn-dcommit-workaround-for-git-submodules
>> for a typical example), and it makes sense integrating git-submodule
>> with git-svn would expand submodule's usefulness.
>
> I do not think that this would be good. Both "git svn" and "git
> submodule" are rather complex by now, and mixing them would only
> complicate code.
>
Hm, point well taken, but it would seem to have enormous benefit for a
lot of people. I can move it down the priority list, but I'd like to
include it in the proposal - complexity alone isn't a good reason to
avoid something.
I also believe that the workaround described, if incorporated into
git-submodules.sh in an appropriate way might open up possibilities
for further improvement. The UI would change much, seems like it'd
just be detection of pointing to a SVN repo instead of a git repo and
then hooking into git svn calls instead of regular git calls. This
brings up the possibility that git submodules should abstract its
repository handling in much the same way that git does. I'm not
familiar with the code, but this seems more like calling other
plumbing hooks than anything else.
>> *make submodules deal with updated references
>> **Instead of issuing merge conflicts on updated submodule references,
>> this will allow submodules on default detached HEAD so that changes
>> from the local repo can be committed without first pulling changes
>> from the shared repo.
>
> I'd rather call this "make git-submodule help with merging".
>
Better name. Duly noted. Will change.
>> *protect changes in local submodules when doing “git submodule update”
>> **This is similar to the previous point, in that changes need to be
>> protected or merged or warnings issued when updating the submodule.
>> The potential to lose work with no warning is a big no-no.
>
> One word: Reflogs.
>
I haven't used reflogs, but it doesn't seem to fix the problem (maybe
you can explain?): simply knowing where/what the reference is, doesn't
mean that git-submodule looks at it, obeys the reference or issues
warnings when it should. The problem as stated
(http://flavoriffic.blogspot.com/2008/05/managing-git-submodules-with-gitrake.html?showComment=1211380200000#c3897235118548537475)
was that git submodule update would silently overwrite any local
changes with the remote version (i.e. git did not check to see if the
local reference was different than the remote reference when
updating).
>> *make git submodules easy to remove
>> ** See http://pitupepito.homelinux.org/?p=24, for an example of why
>> this is a pain. Adding a submodule has ui, removing one should as
>> well.
>
> AFAIR there was already a patch to implement this, but the OP apparently
> did not address all issues.
>
Yep, found it on the mailing list. Obviously, part of the project
would be to resolve those final issues.
Phillip Baker
^ permalink raw reply
* Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]
From: Johannes Schindelin @ 2009-03-31 23:05 UTC (permalink / raw)
To: P Baker; +Cc: Shawn O. Pearce, git
In-Reply-To: <526944450903311532u24eb74fby1f558c1bef5c653a@mail.gmail.com>
Hi,
On Tue, 31 Mar 2009, P Baker wrote:
> On Tue, Mar 31, 2009 at 11:57 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> >> *move objects of submodules into base .git/ directory
> >> **This would, as I understand it: protect submodules from being
> >> overwritten and changes lost when switching between branches of the
> >> superproject that might or might not contain the submodules and
> >> centralize their management into one location. The added benefits of
> >> fully using git's ability to branch and merge submodules makes it
> >> worth adding some complexity within the .git directory.
> >
> > The main problem with renaming/deleting is not the repository of the
> > submodule, but the working directoy.
> >
>
> My understanding is that since the submodule objects (history) is
> stored in a .git directory in the subdirectory where the submodule is
> located, removing that subdirectory during checkout of a branch that
> does not include that submodule eliminates the .git directory as well.
> Moving the objects from the submodule's .git directory to the base
> .git directory would seem to alleviate this problem.
My point was more about "you cannot just remove the subdirectory, or you
_will_ lose data".
> >> *use .git instead of .gitmodules
> >> **I actually don't know why this was included with the project
> >> description, I searched for an explanation of the desired name change
> >> on the mailing list and in commit messages, but came up with nothing.
> >
> > AFAICT somebody thought that the information about the locations of the
> > submodules should be in .git/ rather than in the working directory. But
> > of course, that is wrong: you want it to be tracked.
>
> So, in looking back through the archives of the mailing list there
> seems to be some disagreement between using .gitmodules and
> .git/config to track submodules.
No. .gitmodules has the default information, and "git submodule init"
brings that into .git/config, to be overridden by the user if she so
likes.
> >> *git submodule update --init should initialize nested levels of submodules
> >> **As an ease of use command, either an additional flag to recurse can
> >> be added, or it can act by default. As a requested feature on the
> >> mailing list, this is worth implementing.
> >
> > I thought there was a patch to support "git submodule recurse"? That
> > would be rather less limited than yet another option to submodule update.
>
> There is a git submodule foreach command, but it doesn't look like the
> patch for git submodule recurse
> (http://marc.info/?l=git&m=120997867213008&w=2) has been incorporated
> into a public release.
>
> That is one route, on the other hand, the default action is also open
> to question. When I update a submodule, I would probably expect that
> anything it depends on is also updated. The default action probably
> should be recursive.
No. Not at all. At least in my usage, submodules are mostly optional.
IOW I have ways in my projects to cope with the absence of a checkout.
> >> *ability to update submodule pulled from svn repo
> >> **One workaround is to clone it as local copy using git-svn and then
> >> import that local clone as a submodule; clearly a clunky solution.
> >> There are many requests for this feature (see
> >> http://panthersoftware.com/articles/view/4/git-svn-dcommit-workaround-for-git-submodules
> >> for a typical example), and it makes sense integrating git-submodule
> >> with git-svn would expand submodule's usefulness.
> >
> > I do not think that this would be good. Both "git svn" and "git
> > submodule" are rather complex by now, and mixing them would only
> > complicate code.
>
> Hm, point well taken, but it would seem to have enormous benefit for a
> lot of people. I can move it down the priority list, but I'd like to
> include it in the proposal - complexity alone isn't a good reason to
> avoid something.
Complexity is often a good sign of bad design.
In this case, I want to point out that there has been a better design
already:
http://thread.gmane.org/gmane.comp.version-control.git/114545
(Unfortunately, Daniel decided to post the follow-up patches in different
threads; that will make it hard for you to find them.)
Ciao,
Dscho
^ permalink raw reply
* [PATCH] format_sanitized_subject: Don't trim past initial length of strbuf
From: Stephen Boyd @ 2009-03-31 23:24 UTC (permalink / raw)
To: René Scharfe; +Cc: git, Junio C Hamano
In-Reply-To: <49D2968D.6010108@lsrfire.ath.cx>
If the subject line is '...' the strbuf will be accessed before the
first dot is added; potentially changing the strbuf passed into the
function or accessing sb->buf[-1] if it was originally empty.
Reported-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
---
I was thinking about this today actually. Thanks.
With regards to the isalnum(), I kept the original code because I wasn't sure
if the functionality would be different.
pretty.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/pretty.c b/pretty.c
index c57cef4..a0ef356 100644
--- a/pretty.c
+++ b/pretty.c
@@ -502,6 +502,7 @@ static int istitlechar(char c)
static void format_sanitized_subject(struct strbuf *sb, const char *msg)
{
size_t trimlen;
+ size_t start_len = sb->len;
int space = 2;
for (; *msg && *msg != '\n'; msg++) {
@@ -519,8 +520,9 @@ static void format_sanitized_subject(struct strbuf *sb, const char *msg)
/* trim any trailing '.' or '-' characters */
trimlen = 0;
- while (sb->buf[sb->len - 1 - trimlen] == '.'
- || sb->buf[sb->len - 1 - trimlen] == '-')
+ while (sb->len - trimlen > start_len &&
+ (sb->buf[sb->len - 1 - trimlen] == '.'
+ || sb->buf[sb->len - 1 - trimlen] == '-'))
trimlen++;
strbuf_remove(sb, sb->len - trimlen, trimlen);
}
--
1.6.2
^ permalink raw reply related
* Re: [PATCH] format_sanitized_subject: Don't trim past initial length of strbuf
From: Stephen Boyd @ 2009-03-31 23:29 UTC (permalink / raw)
To: rene.scharfe; +Cc: Junio C Hamano, git
Forgot to say this is based on next.
^ permalink raw reply
* Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]
From: P Baker @ 2009-03-31 23:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.DEB.1.00.0904010058490.6616@intel-tinevez-2-302>
I'll paraphrase to see if I understand your points:
*Moving objects from submodule .git directories into the base .git/
directory would protect the submodules and is a good idea.
*Moving to a .git/ file from .gitmodules should be taken off of the
goal list (I went back and read this thread:
http://thread.gmane.org/gmane.comp.version-control.git/78605; seemed
to clear things up).
*git submodule recurse would be a good option (not as a default), if
the remaining issues are resolved.
*It would be a good idea for git submodule to work with foreign VCS,
through Daniel's patches.
I appreciate the guidance, it's helping me to see that some of this
work has already been done, it needs to be finished and pushed into a
public release. As an intense user of submodules, what does it do
poorly/not do for your needs?
Thanks,
Phillip Baker
On Tue, Mar 31, 2009 at 7:05 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 31 Mar 2009, P Baker wrote:
>
>> On Tue, Mar 31, 2009 at 11:57 AM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>
>> >> *move objects of submodules into base .git/ directory
>> >> **This would, as I understand it: protect submodules from being
>> >> overwritten and changes lost when switching between branches of the
>> >> superproject that might or might not contain the submodules and
>> >> centralize their management into one location. The added benefits of
>> >> fully using git's ability to branch and merge submodules makes it
>> >> worth adding some complexity within the .git directory.
>> >
>> > The main problem with renaming/deleting is not the repository of the
>> > submodule, but the working directoy.
>> >
>>
>> My understanding is that since the submodule objects (history) is
>> stored in a .git directory in the subdirectory where the submodule is
>> located, removing that subdirectory during checkout of a branch that
>> does not include that submodule eliminates the .git directory as well.
>> Moving the objects from the submodule's .git directory to the base
>> .git directory would seem to alleviate this problem.
>
> My point was more about "you cannot just remove the subdirectory, or you
> _will_ lose data".
>
>> >> *use .git instead of .gitmodules
>> >> **I actually don't know why this was included with the project
>> >> description, I searched for an explanation of the desired name change
>> >> on the mailing list and in commit messages, but came up with nothing.
>> >
>> > AFAICT somebody thought that the information about the locations of the
>> > submodules should be in .git/ rather than in the working directory. But
>> > of course, that is wrong: you want it to be tracked.
>>
>> So, in looking back through the archives of the mailing list there
>> seems to be some disagreement between using .gitmodules and
>> .git/config to track submodules.
>
> No. .gitmodules has the default information, and "git submodule init"
> brings that into .git/config, to be overridden by the user if she so
> likes.
>
>> >> *git submodule update --init should initialize nested levels of submodules
>> >> **As an ease of use command, either an additional flag to recurse can
>> >> be added, or it can act by default. As a requested feature on the
>> >> mailing list, this is worth implementing.
>> >
>> > I thought there was a patch to support "git submodule recurse"? That
>> > would be rather less limited than yet another option to submodule update.
>>
>> There is a git submodule foreach command, but it doesn't look like the
>> patch for git submodule recurse
>> (http://marc.info/?l=git&m=120997867213008&w=2) has been incorporated
>> into a public release.
>>
>> That is one route, on the other hand, the default action is also open
>> to question. When I update a submodule, I would probably expect that
>> anything it depends on is also updated. The default action probably
>> should be recursive.
>
> No. Not at all. At least in my usage, submodules are mostly optional.
> IOW I have ways in my projects to cope with the absence of a checkout.
>
>> >> *ability to update submodule pulled from svn repo
>> >> **One workaround is to clone it as local copy using git-svn and then
>> >> import that local clone as a submodule; clearly a clunky solution.
>> >> There are many requests for this feature (see
>> >> http://panthersoftware.com/articles/view/4/git-svn-dcommit-workaround-for-git-submodules
>> >> for a typical example), and it makes sense integrating git-submodule
>> >> with git-svn would expand submodule's usefulness.
>> >
>> > I do not think that this would be good. Both "git svn" and "git
>> > submodule" are rather complex by now, and mixing them would only
>> > complicate code.
>>
>> Hm, point well taken, but it would seem to have enormous benefit for a
>> lot of people. I can move it down the priority list, but I'd like to
>> include it in the proposal - complexity alone isn't a good reason to
>> avoid something.
>
> Complexity is often a good sign of bad design.
>
> In this case, I want to point out that there has been a better design
> already:
>
> http://thread.gmane.org/gmane.comp.version-control.git/114545
>
> (Unfortunately, Daniel decided to post the follow-up patches in different
> threads; that will make it hard for you to find them.)
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox