* Re: git-blame.el: what is format-spec?
From: David Kågedal @ 2009-12-04 17:36 UTC (permalink / raw)
To: Sergei Organov; +Cc: git, Andreas Schwab
In-Reply-To: <87ljhi3cao.fsf@osv.gnss.ru>
Sergei Organov <osv@javad.com> writes:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>> Sergei Organov <osv@javad.com> writes:
>>
>>> What is format-spec function in current git-blame.el? Neither my GNU
>>> Emacs 22.2.1 nor Google knows anything about it.
>>
>> It's part of Emacs since more than 9 years, imported from Gnus.
>>
>
> Thanks, I now see it in Gnus on my own computer, in
> lisp/gnus/format-spec.el.gz.
>
> GNU Emacs 22.2.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) of 2008-11-10
> on raven, modified by Debian
>
> However, isn't it a bad idea to require Gnus(!) for git-blame to run? Gnus
> is not installed on our server where I've encountered the problem. Was
> format-spec actually moved to core emacs recently?
That was not my intention when I posted the patch. I seem to recall that
I asked for testing, in particular from users with older Emacsen than
23. But I got no response, and only recently discovered that the patch
hade been accepted.
format-spec is included in Emacs 23, and is a useful function. But we
can rewrite git-blame.el to do the formatting manuall instead.
--
David Kågedal
^ permalink raw reply
* Re: git-blame.el: what is format-spec?
From: Matthieu Moy @ 2009-12-04 18:18 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Sergei Organov, git
In-Reply-To: <m2bpieab67.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Sergei Organov <osv@javad.com> writes:
>
>> However, isn't it a bad idea to require Gnus(!) for git-blame to run? Gnus
>> is not installed on our server where I've encountered the problem.
>
> Gnus has been part of Emacs since more than 10 years.
... but Linux distros often cut it out by default, so if you just ask
for Emacs as a package, you don't get the Gnus package.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC PATCH v2 3/8] Support taking over transports
From: Shawn O. Pearce @ 2009-12-04 18:27 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1259942168-24869-6-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> Add support for taking over transports that turn out to be smart.
I really don't like this disown strategy and its magic ref return
value from fetch.
> @@ -1020,7 +1089,13 @@ int transport_fetch_refs(struct transport *transport, struct ref *refs)
> heads[nr_heads++] = rm;
> }
>
> +retry:
> rc = transport->fetch(transport, nr_heads, heads);
> + if(rc == TRANSPORT_LAYER6_READY) {
> + git_take_over_transport(transport);
> + goto retry;
> + }
Why can't you expose git_take_over_transport as a public function
and then the transport-helper.c code can instead do:
... setup connect with helper ...
transport_takeover(transport, child);
return transport->fetch(....);
Would this make the code simpler?
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v2 4/8] Support remote helpers implementing smart transports
From: Shawn O. Pearce @ 2009-12-04 18:37 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1259942168-24869-7-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
>
> +'connect' <service>::
> + Connects to given service. Stdin and stdout of helper are
> + connected to specified service (git prefix is included in service
> + name so e.g. fetching uses 'git-upload-pack' as service) on
> + remote side. Valid replies to this command are empty line
> + (connection established), 'FALLBACK' (no smart transport support,
Why not 'fallback' to remain consistent with this protocol and many
others in git where we stick to lowercase ASCII?
> + fall back to dumb transports) and just exiting with error message
> + printed (can't connect, don't bother trying to fall back). After
> + line feed terminating the positive (empty) response, the output
> + of service starts. After the connection ends, the remote
> + helper exits. Note that to prevent deadlocking, all read data
> + should be immediately flushed to outgoing connection (excepting
> + remote initial advertisments, which should be flushed on first
> + flush packet (0000 as length) encountered.
Why is the initial advertisement special? If the helper always
flushes both sides, it shouldn't ever deadlock the protocol. Also,
note that a helper should be able to implement a tiny delay like
Nagle's algorithm does in TCP. It just can't sit on a byte forever.
> @@ -72,7 +73,10 @@ static struct child_process *get_helper(struct transport *transport)
> helper->argv = xcalloc(4, sizeof(*helper->argv));
> strbuf_addf(&buf, "remote-%s", data->name);
> helper->argv[0] = strbuf_detach(&buf, NULL);
> - helper->argv[1] = transport->remote->name;
> + if(transport->remote)
> + helper->argv[1] = transport->remote->name;
> + else
> + helper->argv[1] = "";
This hunk appears to be unrelated. And actually, if transport has
no remote, shouldn't the arg here be NULL so the helper gets only
1 argument and not 2 arguments?
> +static int _process_connect(struct transport *transport,
> + const char *name, const char *exec)
> +{
> + struct helper_data *data = transport->data;
> + struct strbuf cmdbuf = STRBUF_INIT;
> + struct child_process *helper;
> + int r;
> +
> + helper = get_helper(transport);
> +
> + /* Handle --upload-pack and friends. This is fire and forget...
> + just warn if it fails. */
> + if(exec && strcmp(name, exec)) {
> + r = set_helper_option(transport, "servpath", exec);
> + if(r > 0)
> + fprintf(stderr, "Warning: Setting remote service path "
> + "not supported by protocol.\n");
> + else if(r < 0)
> + fprintf(stderr, "Warning: Invalid remote service "
> + "path.\n");
> + }
I think exec winds up defaulting to name if --upload-pack was not
used on the command line, and remote.$name.uploadpack was not set.
See transport.c where you initialize the git options struct, these
fields were defaulted in.
My point is, we shouldn't send option servpath to the helper if
name is equal to servpath, because the helper might not support
servpath and the option command will issue a warning above for no
reason at all.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/3] Add a command "fix" to rebase --interactive.
From: Johannes Schindelin @ 2009-12-04 18:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git
In-Reply-To: <7v638mskmx.fsf@alter.siamese.dyndns.org>
Hi,
On Fri, 4 Dec 2009, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> > index 0bd3bf7..539413d 100755
> > --- a/git-rebase--interactive.sh
> > +++ b/git-rebase--interactive.sh
> > @@ -302,7 +302,7 @@ nth_string () {
> >
> > make_squash_message () {
> > if test -f "$SQUASH_MSG"; then
> > - COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
> > + COUNT=$(($(sed -n "s/^# Th[^0-9]*\([1-9][0-9]*\)\(th\|st\|nd\|rd\) commit message.*:/\1/p" \
> > < "$SQUASH_MSG" | sed -ne '$p')+1))
>
> This sed replacement worries me. I don't have a time to check myself
> today but do we use \(this\|or\|that\) alternates with our sed script
> already elsewhere in the codebase (test scripts do not count)?
>
> Otherwise this may suddenly be breaking a platform that has an
> implementation of sed that may be substandard but so far has been
> sufficient to work with git.
IIRC "|" was not correctly handled by BSD sed (used e.g. in MacOSX).
So maybe it would be best to just look for "commit message"? I agree with
Michael that the regex should not be too loose.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Johannes Schindelin @ 2009-12-04 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, Michael J Gruber, Michael Haggerty, git
In-Reply-To: <7vws12r5v2.fsf@alter.siamese.dyndns.org>
Hi,
On Fri, 4 Dec 2009, Junio C Hamano wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
> > Michael J Gruber <git@drmicha.warpmail.net> writes:
> >
> >>> If the idea of a "fix" command is acceptable, then I would like to
> >>> implement a further convenience: if a group of commits to be folded
> >>> together includes *only* "fix" commits, then the first log message
> >>> should be used without even opening an editor. But I would like to
> >>> get a reaction to the "fix" command in general before doing so.
> >>
> >> I'd say that would make a useful command ("fix") even more useful, being
> >> just the right counterpart to "reword" for trivial commit message fixes.
> >
> > +1 for fix, and +1 for the "don't even launch the editor" too.
>
> I like it, too. Also I vaguely recall that there was a series that died
> that would have allowed you to give hints to help this behaviour at the
> time you make "fix-up" commits; we may want to resurrect it on top of this
> feature.
I'll just repeat this exactly one more time: it is not always possible to
know whether you make a fix-up commit, and it is not always possible to be
sure that you want to amend the next time you do a rebase.
So: Commit time is definitely a bad time to decide on the action in some
future rebase event.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.6.5.4
From: Todd Zullinger @ 2009-12-04 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Schwab, Michael J Gruber, git
In-Reply-To: <7vzl5ysm11.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> I think it depends on the likelihood that a distro has xmlto so old that
>>> it does not understand --stringparam yet it uses stylesheet so new that
>>> setting the parameter makes a positive difference (either it gives the
>>> full URL or at least squelches the "You should define the parameter"
>>> noise) in the output.
>>
>> openSUSE 11.2, for example. Its xmlto has a non-standard --xsltopts
>> option that passes its argument down to xsltproc.
>
> Ok, as I said that I've been wrong before in this area ;-)
>
> I don't think I will have much time for git today, and it would be
> appreciated if somebody can work on this and send a tested patch that
> applies cleanly on top of 'maint' to implement the @@MAN_BASE_URL@@
> replacement from manpage-base.xsl.in to manpage-base.xsl as Todd suggested
> earlier.
Something like this perhaps? I tested it with 1.6.5.4 on Fedora 10,
12 and CentOS 5.4 but it could surely use more eyes and testing to
ensure it works as it should and doesn't have unintended negative
effects on make clean and such.
This does set MAN_BASE_URL unconditionally, pointing to kernel.org.
That way anyone building with recent DocBook and taking no new action
will have something useful in the man page links.
I noticed on Fedora 12 that email addresses get added to the NOTES
section. For example, git-branch(1) has:
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org[4]>.
...
NOTES
...
4. git@vger.kernel.org
mailto:git@vger.kernel.org
That must be something new in DocBook, as it doesn't occur in the
Fedora 10 builds. It's a little extraneous, but not harmful I guess.
--- >8 ---
From: Todd Zullinger <tmz@pobox.com>
Date: Fri, 4 Dec 2009 12:53:21 -0500
Subject: [PATCH] Documentation: Avoid use of xmlto --stringparam
The --stringparam option is not available on older xmlto versions.
Instead, set man.base.url.for.relative.links via a .xsl file. Older
docbook versions will ignore this without causing grief to users of
older xmlto versions.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
Documentation/.gitignore | 1 +
Documentation/Makefile | 23 ++++++++++++-----------
Documentation/manpage-base-url.xsl.in | 10 ++++++++++
3 files changed, 23 insertions(+), 11 deletions(-)
create mode 100644 Documentation/manpage-base-url.xsl.in
diff --git a/Documentation/.gitignore b/Documentation/.gitignore
index d8edd90..1c3a9fe 100644
--- a/Documentation/.gitignore
+++ b/Documentation/.gitignore
@@ -8,3 +8,4 @@ gitman.info
howto-index.txt
doc.dep
cmds-*.txt
+manpage-base-url.xsl
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 1c9dfce..1c867fa 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -104,18 +104,15 @@ XMLTO_EXTRA += -m manpage-suppress-sp.xsl
endif
# Newer DocBook stylesheet emits warning cruft in the output when
-# this is not set, and if set it shows an absolute link. We can
-# use MAN_BASE_URL=http://www.kernel.org/pub/software/scm/git/docs/
-# but distros may want to set it to /usr/share/doc/git-core/docs/ or
-# something like that.
+# this is not set, and if set it shows an absolute link. Older
+# stylesheets simply ignore this parameter.
#
-# As older stylesheets simply ignore this parameter, it ought to be
-# safe to set it to empty string when the base URL is not specified,
-# but unfortunately we cannot do so unconditionally because at least
-# xmlto 0.0.18 is reported to lack --stringparam option.
-ifdef MAN_BASE_URL
-XMLTO_EXTRA += --stringparam man.base.url.for.relative.links=$(MAN_BASE_URL)
+# Distros may want to use MAN_BASE_URL=file:///path/to/git/docs/
+# or similar.
+ifndef MAN_BASE_URL
+MAN_BASE_URL = http://www.kernel.org/pub/software/scm/git/docs/
endif
+XMLTO_EXTRA += -m manpage-base-url.xsl
# If your target system uses GNU groff, it may try to render
# apostrophes as a "pretty" apostrophe using unicode. This breaks
@@ -244,6 +241,7 @@ clean:
$(RM) howto-index.txt howto/*.html doc.dep
$(RM) technical/api-*.html technical/api-index.txt
$(RM) $(cmds_txt) *.made
+ $(RM) manpage-base-url.xsl
$(MAN_HTML): %.html : %.txt
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
@@ -251,7 +249,10 @@ $(MAN_HTML): %.html : %.txt
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \
mv $@+ $@
-%.1 %.5 %.7 : %.xml
+manpage-base-url.xsl: manpage-base-url.xsl.in
+ sed "s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|" $< > $@
+
+%.1 %.5 %.7 : %.xml manpage-base-url.xsl
$(QUIET_XMLTO)$(RM) $@ && \
xmlto -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<
diff --git a/Documentation/manpage-base-url.xsl.in b/Documentation/manpage-base-url.xsl.in
new file mode 100644
index 0000000..e800904
--- /dev/null
+++ b/Documentation/manpage-base-url.xsl.in
@@ -0,0 +1,10 @@
+<!-- manpage-base-url.xsl:
+ special settings for manpages rendered from newer docbook -->
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ version="1.0">
+
+<!-- set a base URL for relative links -->
+<xsl:param name="man.base.url.for.relative.links"
+ >@@MAN_BASE_URL@@</xsl:param>
+
+</xsl:stylesheet>
--
1.6.6.rc1
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The world keeps ending but new people too dumb to know it keep showing
up as if the fun's just started.
^ permalink raw reply related
* Wrong damage counting in diffcore_count_changes?
From: Linus Torvalds @ 2009-12-04 20:07 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Ok, so I had somebody actually ask me about '--dirstat', and as a result I
ended up looking at how well the numbers it calculates really reflect the
damage done to a file.
And to my horror, it doesn't necessarily reflect the damage well at all!
Now, dirstat just takes the same damage numbers that git uses to estimate
similarity for renames, so if dirstat gets odd numbers, then that implies
that file similarity will also be somewhat odd.
So looking at _why_ the dirstat numbers were odd, I came up with this
patch that seems to make much sense. What used to happen is that
diffcore_count_changes() simply ignored any hashes in the destination that
didn't match hashes in the source. EXCEPT if the source hash didn't exist
at all, in which case it would count _one_ destination hash that happened
to have the "next" hash value.
This changes it so that
- whenever it bypasses a destination hash (because it doesn't match a
source), it counts the bytes associated with that as "literal added"
- at the end (once we have used up all the source hashes), we do the same
thing with the remaining destination hashes.
- when hashes do match, and we use the difference in counts as a value,
we also use up that destination hash entry (the 'd++'
This _seems_ to make --dirstat output more sensible, and I'd hope that
that in turn should mean that file rename detection should also be more
sensible. But I haven't actually verified it in any way. Maybe I just
screwed up file rename detection entirely.
Did I miss something?
Linus
---
diffcore-delta.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/diffcore-delta.c b/diffcore-delta.c
index e670f85..7cf431d 100644
--- a/diffcore-delta.c
+++ b/diffcore-delta.c
@@ -201,10 +201,15 @@ int diffcore_count_changes(struct diff_filespec *src,
while (d->cnt) {
if (d->hashval >= s->hashval)
break;
+ la += d->cnt;
d++;
}
src_cnt = s->cnt;
- dst_cnt = d->hashval == s->hashval ? d->cnt : 0;
+ dst_cnt = 0;
+ if (d->cnt && d->hashval == s->hashval) {
+ dst_cnt = d->cnt;
+ d++;
+ }
if (src_cnt < dst_cnt) {
la += dst_cnt - src_cnt;
sc += src_cnt;
@@ -213,6 +218,10 @@ int diffcore_count_changes(struct diff_filespec *src,
sc += dst_cnt;
s++;
}
+ while (d->cnt) {
+ la += d->cnt;
+ d++;
+ }
if (!src_count_p)
free(src_count);
^ permalink raw reply related
* Re: Endianness bug in git-svn or called component?
From: Andreas Schwab @ 2009-12-04 20:16 UTC (permalink / raw)
To: Nathaniel W Filardo; +Cc: git
In-Reply-To: <20091204174458.GV17192@gradx.cs.jhu.edu>
Nathaniel W Filardo <nwf@cs.jhu.edu> writes:
> On this machine,
>
> mirrors hydra:/tank0/mirrors/misc% uname -a
> FreeBSD hydra.priv.oc.ietfng.org 9.0-CURRENT FreeBSD 9.0-CURRENT #13: Sat Nov 14 19:40:25 EST 2009 root@hydra.priv.oc.ietfng.org:/systank/obj/systank/src/sys/NWFKERN sparc64
>
> attempting to fetch from an svn source yields the following error:
>
> rs hydra:/tank0/mirrors/misc% git svn init -s https://joshua.svn.sourceforge.net/svnroot/joshua test-joshua
> Initialized empty Git repository in /tank0/mirrors/misc/test-joshua/.git/
> mirrors hydra:/tank0/mirrors/misc% cd test-joshua
> mirrors hydra:/tank0/mirrors/misc/test-joshua% git svn fetch
> A scripts/distributedLM/config.template
> [...]
> A build.xml
> r1 = fe84a7d821ec6d92da75133ac7ad1deb476b6484 (refs/remotes/trunk)
> error: index uses extension, which we do not understand
> fatal: index file corrupt
> write-tree: command returned error: 128
I could not reproduce that on powerpc (both 32bit and 64bit).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Endianness bug in git-svn or called component?
From: Nathaniel W Filardo @ 2009-12-04 20:29 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Nathaniel W Filardo, git
In-Reply-To: <m23a3qa40n.fsf@igel.home>
[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]
On Fri, Dec 04, 2009 at 09:16:40PM +0100, Andreas Schwab wrote:
> Nathaniel W Filardo <nwf@cs.jhu.edu> writes:
>
> > On this machine,
> >
> > mirrors hydra:/tank0/mirrors/misc% uname -a
> > FreeBSD hydra.priv.oc.ietfng.org 9.0-CURRENT FreeBSD 9.0-CURRENT #13: Sat Nov 14 19:40:25 EST 2009 root@hydra.priv.oc.ietfng.org:/systank/obj/systank/src/sys/NWFKERN sparc64
> >
> > attempting to fetch from an svn source yields the following error:
> >
> > rs hydra:/tank0/mirrors/misc% git svn init -s https://joshua.svn.sourceforge.net/svnroot/joshua test-joshua
> > Initialized empty Git repository in /tank0/mirrors/misc/test-joshua/.git/
> > mirrors hydra:/tank0/mirrors/misc% cd test-joshua
> > mirrors hydra:/tank0/mirrors/misc/test-joshua% git svn fetch
> > A scripts/distributedLM/config.template
> > [...]
> > A build.xml
> > r1 = fe84a7d821ec6d92da75133ac7ad1deb476b6484 (refs/remotes/trunk)
> > error: index uses extension, which we do not understand
> > fatal: index file corrupt
> > write-tree: command returned error: 128
>
> I could not reproduce that on powerpc (both 32bit and 64bit).
>
> Andreas.
Hm. I seem to have forgotten to mention that I am running
% git --version
git version 1.6.5.3
built from the FreeBSD ports tree, in case that matters, using
% gcc --version
gcc (GCC) 4.2.1 20070719 [FreeBSD]
Knowing nothing of git's internals, how should I start to investigate what's
going on here?
Thanks again.
--nwf;
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Wrong damage counting in diffcore_count_changes?
From: Junio C Hamano @ 2009-12-04 20:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0912041200120.24579@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> This changes it so that
>
> - whenever it bypasses a destination hash (because it doesn't match a
> source), it counts the bytes associated with that as "literal added"
>
> - at the end (once we have used up all the source hashes), we do the same
> thing with the remaining destination hashes.
>
> - when hashes do match, and we use the difference in counts as a value,
> we also use up that destination hash entry (the 'd++'
>
> This _seems_ to make --dirstat output more sensible, and I'd hope that
> that in turn should mean that file rename detection should also be more
> sensible. But I haven't actually verified it in any way. Maybe I just
> screwed up file rename detection entirely.
>
> Did I miss something?
Well, the current loop structure largely comes from your eb4d0e3 (optimize
diffcore-delta by sorting hash entries., 2007-10-02) so you would be the
best judge of the change ;-), even though it seems that the current code
inherited the "skipping of dst when src does not exist" bug from c06c796
(diffcore-rename: somewhat optimized., 2006-03-12).
Earlier code, e.g. as of ba23bbc (diffcore-delta: make change counter to
byte oriented again., 2006-03-04), used to be very simple minded and
inefficient and iterated over src_count[] and dst_count[] arrays for the
entire hash value namespace and there was no such "missing, skipped,
happened to have the next value" issue.
I think you understand the original intention of the function correctly
and from a cursory look of the patch I think it fixes the bug in the
current code, and any changes to renames/breaks should be improvements.
But my lunchbreak is over, and my evening is booked, so I unfortunately
cannot spend more time thinking about any possible fallouts from this
change until tomorrow.
Sorry, and thanks.
> Linus
> ---
> diffcore-delta.c | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/diffcore-delta.c b/diffcore-delta.c
> index e670f85..7cf431d 100644
> --- a/diffcore-delta.c
> +++ b/diffcore-delta.c
> @@ -201,10 +201,15 @@ int diffcore_count_changes(struct diff_filespec *src,
> while (d->cnt) {
> if (d->hashval >= s->hashval)
> break;
> + la += d->cnt;
> d++;
> }
> src_cnt = s->cnt;
> - dst_cnt = d->hashval == s->hashval ? d->cnt : 0;
> + dst_cnt = 0;
> + if (d->cnt && d->hashval == s->hashval) {
> + dst_cnt = d->cnt;
> + d++;
> + }
> if (src_cnt < dst_cnt) {
> la += dst_cnt - src_cnt;
> sc += src_cnt;
> @@ -213,6 +218,10 @@ int diffcore_count_changes(struct diff_filespec *src,
> sc += dst_cnt;
> s++;
> }
> + while (d->cnt) {
> + la += d->cnt;
> + d++;
> + }
>
> if (!src_count_p)
> free(src_count);
^ permalink raw reply
* git-svn breakage on repository rename
From: Guido Stevens @ 2009-12-04 20:26 UTC (permalink / raw)
To: normalperson, git; +Cc: George Kuk
Hi Eric e.a.,
I have a weird git-svn corner case that might interest you (or not at
all). I'd appreciate any help or hints for moving beyond this problem.
I'm using git-svn to do a full commit history analysis of the Zope +
Plone CMS code bases as part of a research project with the University
of Nottingham into open source knowledge dynamics.
One of the repositories I'm importing breaks with a "Checksum mismatch",
indicating a corruption. However, this error message occurs exactly at
the point where the repository was renamed: from "Products.CMFPlone" to
"Plone" (22715->22716). (Yes, it's the Plone core itself that resists
analysis :-()
The git-svn url for the later commits would be:
http://svn-mirror.plone.org/svn/plone/Plone/trunk
Whereas an older part of the code base lives at:
http://svn-mirror.plone.org/svn/plone/Products.CMFPlone/trunk
Funny thing is, git-svn detects this rename upfront but then breaks
anyway. Which raises the questions:
- is this breakage caused by the rename?
- or does git-svn handle the rename, and there is an actual corruption?
- is there any way I can work around this and get a valid or semi-valid
git history for this project?
I don't mind missing a few commits, since I'm not doing code development
on this repository, only statistical analysis.
Solving this would also be helpful for anyone who wants to work on Plone
development through git rather than through raw svn.
:*CU#
----------------------------------------------------
To reconstruct this error:
----------------------------------------------------
$ git svn init https://svn-mirror.plone.org/svn/plone/Plone/trunk Plone
$ cd Plone
$ git svn fetch
... Error message: (reformatted to wrap 78 cols):
Found possible branch point:
https://svn.plone.org/svn/plone/Plone/branches/4.0 =>
https://svn.plone.org/svn/plone/Plone/trunk, 30966
Initializing parent: git-svn@30966
Found possible branch point:
https://svn.plone.org/svn/plone/Plone/branches/3.3 =>
https://svn.plone.org/svn/plone/Plone/branches/4.0, 27288
Initializing parent: git-svn@27288
Found possible branch point:
https://svn.plone.org/svn/plone/Plone/branches/3.2 =>
https://svn.plone.org/svn/plone/Plone/branches/3.3, 25119
Initializing parent: git-svn@25119
Found possible branch point:
https://svn.plone.org/svn/plone/Plone/branches/3.1 =>
https://svn.plone.org/svn/plone/Plone/branches/3.2, 22725
Initializing parent: git-svn@22725
branch_from: /Products.CMFPlone => /Products.CMFPlone/branches/3.1
Found possible branch point:
https://svn.plone.org/svn/plone/Products.CMFPlone/branches/3.1 =>
https://svn.plone.org/svn/plone/Plone/branches/3.1, 22715
Initializing parent: git-svn@22715
Found branch parent: (git-svn@22725)
e477345f83a0f2cc7e27348e01493a841c9cd587
Following parent with do_switch
Checksum mismatch: Products/CMFPlone/HISTORY.txt
expected: 69106809d879e7370dd133c7ba338670
got: 7b1a0641d429f0c567acf7a3a4be5a45
--
*** Guido A.J. Stevens *** tel: +31.43.3618933 ***
*** guido.stevens@cosent.net *** Postbus 619 ***
*** http://www.cosent.nl *** 6200 AP Maastricht ***
s h a r i n g m a k e s s e n s e
^ permalink raw reply
* Re: git-blame.el: what is format-spec?
From: Sergei Organov @ 2009-12-04 20:54 UTC (permalink / raw)
To: David Kågedal; +Cc: git, Andreas Schwab
In-Reply-To: <87fx7q4p6h.fsf@lysator.liu.se>
David Kågedal <davidk@lysator.liu.se> writes:
> Sergei Organov <osv@javad.com> writes:
>
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>> Sergei Organov <osv@javad.com> writes:
>>>
>>>> What is format-spec function in current git-blame.el? Neither my GNU
>>>> Emacs 22.2.1 nor Google knows anything about it.
>>>
>>> It's part of Emacs since more than 9 years, imported from Gnus.
>>>
>>
>> Thanks, I now see it in Gnus on my own computer, in
>> lisp/gnus/format-spec.el.gz.
>>
>> GNU Emacs 22.2.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) of 2008-11-10
>> on raven, modified by Debian
>>
>> However, isn't it a bad idea to require Gnus(!) for git-blame to run? Gnus
>> is not installed on our server where I've encountered the problem. Was
>> format-spec actually moved to core emacs recently?
>
> That was not my intention when I posted the patch. I seem to recall that
> I asked for testing, in particular from users with older Emacsen than
> 23. But I got no response, and only recently discovered that the patch
> hade been accepted.
>
> format-spec is included in Emacs 23, and is a useful function.
Then there should be (require 'format-spec) in git-blame.el, right? Due
to:
$ emacs --version
GNU Emacs 23.1.1
[...]
$ emacs --batch -Q -f format-spec
Symbol's function definition is void: format-spec
$
Now, I've evaluated (require 'format-spec) in my Emacs 22 (yes, 22, not
23), and now git-blame almost works there. The problem I see is that it
doesn't output anything in the echo area. It color-codes the buffer, it
does show correct pop-up when mouse is over a region, but it doesn't
print anything in the echo area when I move cursor through the regions.
Any idea how to debug/fix this?
-- Sergei.
^ permalink raw reply
* [PATCH RESEND] git gui: make current branch default in "remote delete branch" merge check
From: Heiko Voigt @ 2009-12-04 21:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Jens Lehmann, Junio C Hamano
We already do the same when locally deleting a branch.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
lib/remote_branch_delete.tcl | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/lib/remote_branch_delete.tcl b/lib/remote_branch_delete.tcl
index 31e0947..2416420 100644
--- a/lib/remote_branch_delete.tcl
+++ b/lib/remote_branch_delete.tcl
@@ -250,6 +250,8 @@ method _write_url {args} { set urltype url }
method _write_check_head {args} { set checktype head }
method _write_head_list {args} {
+ global current_branch
+
$head_m delete 0 end
foreach abr $head_list {
$head_m insert end radiobutton \
@@ -258,7 +260,11 @@ method _write_head_list {args} {
-variable @check_head
}
if {[lsearch -exact -sorted $head_list $check_head] < 0} {
- set check_head {}
+ if {[lsearch -exact -sorted $head_list $current_branch] < 0} {
+ set check_head {}
+ } else {
+ set check_head $current_branch
+ }
}
}
--
1.6.4.m4.4
^ permalink raw reply related
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Nanako Shiraishi @ 2009-12-04 21:27 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Matthieu Moy, Michael J Gruber, Michael Haggerty,
git
In-Reply-To: <alpine.DEB.1.00.0912041945161.21557@intel-tinevez-2-302>
Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Hi,
>
> On Fri, 4 Dec 2009, Junio C Hamano wrote:
>
>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>
>> > Michael J Gruber <git@drmicha.warpmail.net> writes:
>> >
>> >>> If the idea of a "fix" command is acceptable, then I would like to
>> >>> implement a further convenience: if a group of commits to be folded
>> >>> together includes *only* "fix" commits, then the first log message
>> >>> should be used without even opening an editor. But I would like to
>> >>> get a reaction to the "fix" command in general before doing so.
>> >>
>> >> I'd say that would make a useful command ("fix") even more useful, being
>> >> just the right counterpart to "reword" for trivial commit message fixes.
>> >
>> > +1 for fix, and +1 for the "don't even launch the editor" too.
>>
>> I like it, too. Also I vaguely recall that there was a series that died
>> that would have allowed you to give hints to help this behaviour at the
>> time you make "fix-up" commits; we may want to resurrect it on top of this
>> feature.
>
> I'll just repeat this exactly one more time: it is not always possible to
> know whether you make a fix-up commit, and it is not always possible to be
> sure that you want to amend the next time you do a rebase.
>
> So: Commit time is definitely a bad time to decide on the action in some
> future rebase event.
I think Junio is referring to this thread:
http://thread.gmane.org/gmane.comp.version-control.git/127923/focus=121874
The old patch added a convention to mark a fix-up commit
with a special string "!fixup" and refer to which commit
in the series it is fixing. It added --autosquash option
to rebase--interactive that tells it to move such a commit
to an appropriate place in the series and change its 'pick'
to 'squash'. I think with Michael's patches, it can change
'pick' to 'fix' instead.
I too think Michael's "fix" is a good feature, and in the
workflow by Shawn, he knows he is fixing up an earlier
commit, and he knows he doesn't want to add anything to
the message by the fix-up commit when he makes that commit
(how else would he have messages like "a", "s", or "foo").
I don't think your objection should block *others* (like
Shawn and Junio) who can decide when they make commits
from using the feature from my old patch to make it even
easier to clean up their topics. If *you* can't decide if
you want to amend or not when you make a fix-up commit, you
can leave your fix-up commits unmarked, run interactive
rebase without the --autosquash option, and use Michael's
'fix' manually. People who can sometimes but not always
decide when they make commits can do the same when they
can't.
Isn't it what Junio suggested by his "on top of this feature",
and wouldn't that make everybody happy?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Re: [RFC PATCH v2 0/2] git-gui: (un)stage a range of changes at once
From: Heiko Voigt @ 2009-12-04 22:07 UTC (permalink / raw)
To: Peter Baumann; +Cc: Jeff Epler, Shawn O. Pearce, git
In-Reply-To: <20091029073454.GA25843@m62s10.vlinux.de>
Hi,
On Thu, Oct 29, 2009 at 08:34:54AM +0100, Peter Baumann wrote:
> On Wed, Oct 21, 2009 at 04:20:21PM -0500, Jeff Epler wrote:
> >
> > Jeff Epler (2):
> > Fix applying a line when all following lines are deletions
> > Make it possible to apply a range of changes at once
> >
> > git-gui.sh | 15 +++-
> > lib/diff.tcl | 224 ++++++++++++++++++++++++++++++++--------------------------
> > 2 files changed, 135 insertions(+), 104 deletions(-)
>
> Cc ing Shawn as the git gui maintainer, as he might have missed this series
> during his away time.
>
> The original series including user comments can be found at
>
> http://thread.gmane.org/gmane.comp.version-control.git/130732
>
> whereas the newest version is here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/130968
Ping? A short reminder for Shawn as I do not see the patches in his
tree.
cheers Heiko
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Björn Gustavsson @ 2009-12-04 22:19 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, gitster, Johannes.Schindelin
In-Reply-To: <cover.1259934977.git.mhagger@alum.mit.edu>
On Fri, Dec 4, 2009 at 3:36 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> If the idea of a "fix" command is acceptable, then I would like to
> implement a further convenience: if a group of commits to be folded
> together includes *only* "fix" commits, then the first log message
> should be used without even opening an editor. But I would like to
> get a reaction to the "fix" command in general before doing so.
I would really prefer that the editor is not entered at all if there
are only "fix" commands in a group of commits to be folded.
> Michael Haggerty (3):
> Better document the original repository layout.
> Set a couple more tags in the original repository.
> Add a command "fix" to rebase --interactive.
Nitpick: the recommended style is to leave out the full stop
at the end of the first line of the commit message.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Junio C Hamano @ 2009-12-04 22:29 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: Michael Haggerty, git, Johannes.Schindelin
In-Reply-To: <6672d0160912041419s2cbcb8ech49f69250b99386ae@mail.gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
> On Fri, Dec 4, 2009 at 3:36 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>
>> If the idea of a "fix" command is acceptable, then I would like to
>> implement a further convenience: if a group of commits to be folded
>> together includes *only* "fix" commits, then the first log message
>> should be used without even opening an editor. But I would like to
>> get a reaction to the "fix" command in general before doing so.
>
> I would really prefer that the editor is not entered at all if there
> are only "fix" commands in a group of commits to be folded.
I think all of these ideas were already discussed in the earlier thread
from mid June this year, so I do not think there is no need for any more
"me too like it" comments to show the support for this feature, unless it
adds any new ideas of value. I think "fixup and nothing else shouldn't
open editor" and "an option to pay attention to specially marked commit"
are good ideas but they both appear in the old thread already.
IIRC, the end result of the bikeshedding for the name of the command was
won by Dscho's "fixup":
http://thread.gmane.org/gmane.comp.version-control.git/127923/focus=121820
^ permalink raw reply
* Re: Wrong damage counting in diffcore_count_changes?
From: Linus Torvalds @ 2009-12-04 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vljhio4a3.fsf@alter.siamese.dyndns.org>
On Fri, 4 Dec 2009, Junio C Hamano wrote:
>
> Well, the current loop structure largely comes from your eb4d0e3 (optimize
> diffcore-delta by sorting hash entries., 2007-10-02) so you would be the
> best judge of the change ;-), even though it seems that the current code
> inherited the "skipping of dst when src does not exist" bug from c06c796
> (diffcore-rename: somewhat optimized., 2006-03-12).
Yeah, I think the sorting thing tried to not change any logic, so the
counting predates that whole thing.
> But my lunchbreak is over, and my evening is booked, so I unfortunately
> cannot spend more time thinking about any possible fallouts from this
> change until tomorrow.
>
> Sorry, and thanks.
No problem. Just an example of the fallout here on the kernel:
- totally made-up trivial differences in two different kernel
directories:
[torvalds@nehalem linux]$ git diff -p --stat >
kernel/sched.c | 1 +
mm/memory.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index 3c11ae0..7a86f4f 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -1,3 +1,4 @@
+123
/*
* kernel/sched.c
*
diff --git a/mm/memory.c b/mm/memory.c
index 6ab19dd..0de58a6 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1,3 +1,4 @@
+aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
/*
* linux/mm/memory.c
*
- Here's what current git reports (which is obviously garbage):
[torvalds@nehalem linux]$ git diff --dirstat
100.0% kernel/
- Here's what a fixed git with that patch reports:
[torvalds@nehalem linux]$ ~/git/git diff --dirstat
8.6% kernel/
91.3% mm/
and notice how the fixed diff now sees the change to mm/memory.c as a real
change (it used to dismiss it entirely because it was a new previously
non-existent pattern, so the hash didn't exist in the source), and gives
reasonable percentages as to how much damage has been done (ie the
mm/memory.c changes were obviously bigger: 42 new characters vs 4 new
characters).
So the patch definitely improves dirstat, although for a rather made-up
example (I normally use it for much bigger diffs, where the impact of this
bug is not nearly as noticeable).
But that patch also changes the end result (in major ways) for real
examples too - probably exactly because it undercounted additions of new
code. I can't prove that the new numbers are "better", but I think they
are:
- old and presumably broken:
[torvalds@nehalem linux]$ git diff -M --dirstat --cumulative v2.6.32-rc8..v2.6.32
5.8% arch/
3.5% drivers/net/e1000e/
9.6% drivers/net/
3.9% drivers/staging/
34.8% drivers/
4.1% fs/cachefiles/
24.9% fs/fscache/
32.6% fs/
14.5% kernel/
3.7% net/
- new and hopefully fixed:
[torvalds@nehalem linux]$ ~/git/git diff -M --dirstat --cumulative v2.6.32-rc8..v2.6.32
3.3% Documentation/filesystems/caching/
3.5% Documentation/filesystems/
7.6% Documentation/
3.2% arch/arm/
4.2% arch/blackfin/
10.1% arch/
3.1% drivers/gpu/drm/
7.8% drivers/net/
3.1% drivers/staging/
30.0% drivers/
5.6% fs/cachefiles/
19.9% fs/fscache/
28.4% fs/
3.1% include/
12.9% kernel/
so it really does seem like the old code is crud. It just never really
mattered, because from a "is this a copy" standpoint, we don't care all
that much about the "added" content, we care mostly about the original
size and how much of it still remains.
(Sanity check: the diffstat for that thing says:
277 files changed, 4426 insertions(+), 1244 deletions(-)
and diffstat for just Documentation/ says
5 files changed, 289 insertions(+), 14 deletions(-)
so you'd expect that the Documentation changes would be at _least_
(289+14)/(4426+1244), ie ~5%, and since text documentation lines tend to
be more dense than actual code (with lines with just curly braces etc), I
do think that 7.6% Documentation/ sounds much more likely than <3%
(invisible).
I also did a "git log -M --summary" on the current kernel git tree, and it
didn't actually change any of _that_. So it seems that rename detection
still ends up spitting out the same numbers.
Which is actually not surprising, because rename detection doesn't even
end up _using_ the "literal_added" part at all (it just does:
score = (int)(src_copied * MAX_SCORE / max_size);
ie it bases it's score on the amount of copied data, scaling it by the
bigger of the two src/dst sizes).
So just fixing the "literal added" count should not mess anything up, and
seems to fix dirstat.
It also looks a bit like diffcore-break actually worked around this whole
thing, and does
/* sanity */
if (src->size < src_copied)
src_copied = src->size;
if (dst->size < literal_added + src_copied) {
if (src_copied < dst->size)
literal_added = dst->size - src_copied;
else
literal_added = 0;
}
src_removed = src->size - src_copied;
so this _may_ change what -B does, but I get the feeling that it should
improve that too. I'm running a before-and-after "git log -M -B --summary"
on the kernel now, but it's a pretty expensive operation, so it hasn't
finished yet.
Linus
^ permalink raw reply
* Re: git archive without path
From: René Scharfe @ 2009-12-04 23:11 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Junio C Hamano
In-Reply-To: <20091130123203.GA11235@dpotapov.dyndns.org>
Dmitry Potapov schrieb:
> I have never run "git archive" inside of a subdirectory but somehow I
> have always assumed that it creates an archive containing all files in
> it regardless the current directory. In fact, the git-archive man page
> says so:
>
> path
> If one or more paths are specified, include only these in the
> archive, otherwise include all files and subdirectories.
This sentence doesn't specify whose files and subdirectories are to be
included -- those in the repository's root or those in the current
directory. Let's fix that.
-- >8 --
Subject: archive: clarify description of path parameter
Mention that path parameters are based on the current working directory.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
--
Documentation/git-archive.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 3d1c1e7..e579791 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -74,8 +74,9 @@ OPTIONS
The tree or commit to produce an archive for.
path::
- If one or more paths are specified, include only these in the
- archive, otherwise include all files and subdirectories.
+ Without an optional path parameter, all files and subdirectories
+ of the current working directory are included in the archive.
+ If one or more paths are specified, only these are included.
BACKEND EXTRA OPTIONS
---------------------
^ permalink raw reply related
* [PATCH] Cast &cp to eliminate a compile-time warning on FreeBSD 8-STABLE.
From: James P. Howard, II @ 2009-12-04 23:12 UTC (permalink / raw)
To: git; +Cc: James P. Howard, II
Signed-off-by: James P. Howard, II <jh@jameshoward.us>
---
utf8.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/utf8.c b/utf8.c
index 7ddff23..a6cc280 100644
--- a/utf8.c
+++ b/utf8.c
@@ -449,7 +449,7 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
cp = (iconv_ibp)in;
while (1) {
- size_t cnt = iconv(conv, &cp, &insz, &outpos, &outsz);
+ size_t cnt = iconv(conv, (const char **)&cp, &insz, &outpos, &outsz);
if (cnt == -1) {
size_t sofar;
--
1.6.5.3
^ permalink raw reply related
* Re: [RFC PATCH 2/2] MSVC: Fix an "incompatible pointer types" compiler warning
From: Ramsay Jones @ 2009-12-04 22:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Marius Storm-Olsen, GIT Mailing-list
In-Reply-To: <4B18BDE7.3050004@viscovery.net>
Johannes Sixt wrote:
> Ramsay Jones schrieb:
>> In order to avoid the compiler warning, we use the appropriate
>> structure type names (and function names) from the msvc headers.
>> This allows us to compile with -D_USE_32BIT_TIME_T if necessary.
>
> "if necessary"? Who defines when -D_USE_32BIT_TIME_T is necessary?
If I'm reading the msdn documentation correctly, from msvc 2005 onwards,
the time_t type is 64-bits by default. In order to support "legacy apps"
which break with a 64-bit time_t, the _USE_32BIT_TIME_T macro may be set
in the makefile/project-file to enable the old 32-bit time_t type.
(The headers contain a lot of appropriately defined "static __inline"
functions which call 32- or 64-bit versions of the main time related
functions; eg. mktime() will call either _mktime64() or _mktime32()).
Note that 64-bit windows does not support a 32-bit time_t.
So, the "if necessary" means: if git is broken with a 64-bit time_t and it
may take some time to fix it (or we can defer fixing it for a long time).
And the "Who" is: er... well "us" ;-)
>> Also, I added the "&& defined(_stati64)" in the hope that it would work with
>> older msvc/sdk versions.
>
> I think that this is an unnecessary complication and I did wonder why you
> added this extra check. Anybody doing some serious development with MS's
> tools is using VS2005 at least.
Great! So, I will drop that part of the patch.
> But isn't the .vcproj file made for VS2008
> anyway?
I don't know - I don't use it. (Marius?)
>> The reason for the RFC is:
>>
>> - maybe we don't need the flexibility of compiling with/without the 32-bit
>> time_t definition (which *works* BTW) and can revert to the original patch?
>
> Indeed I'm wondering why we should cater for 64 bit time_t. It is an
> unnessary complication as long as MinGW gcc supports only 32 bit time_t
> and the old MSVCRT.DLL.
Ah, so you want to add -D_USE_32BIT_TIME_T to the Makefile?
Do we care about 64-bit Windows?
>
>> - I've tried to be careful not to break the MinGW build, but again I can't
>> test it. (I will be shocked if I have ;-)
>
> It compiles without warnings and doesn't break t/t[01]* ;)
Thanks! v2 of patch comming soon.
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [RFC PATCH 2/2] MSVC: Fix an "incompatible pointer types" compiler warning
From: Ramsay Jones @ 2009-12-04 22:58 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Marius Storm-Olsen, Johannes Sixt,
GIT Mailing-list
In-Reply-To: <alpine.DEB.1.00.0912041144470.4985@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> On Thu, 3 Dec 2009, Ramsay Jones wrote:
>
>> compat/mingw.h | 27 ++++++++++++++++++++++++++-
>> compat/msvc.h | 25 +------------------------
>> 2 files changed, 27 insertions(+), 25 deletions(-)
>
> I'd prefer to have the MSVC-specific definitions in msvc.h, along with a
> definition of, say, ALREADY_DEFINED_STATI64 or some such (which tells
> mingw.h not to do anything about those types). There is no need to
> clutter mingw.h with stuff for MSVC.
Ah, yeah, I did think about this. As I said, the original patch was much
simpler and I thought the change to mingw.h was just this side of being
objectionable ;-) However, as the patch continued to gain weight I should
have re-evaluated that... my bad.
New version of the patch coming soon.
ATB,
Ramsay Jones
^ permalink raw reply
* [RFC PATCH v2 2/2] MSVC: Fix an "incompatible pointer types" compiler warning
From: Ramsay Jones @ 2009-12-04 23:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marius Storm-Olsen, Johannes Sixt, Johannes Schindelin,
GIT Mailing-list
In particular, the following warning is issued while compiling
compat/msvc.c:
...mingw.c(223) : warning C4133: 'function' : incompatible \
types - from '_stati64 *' to '_stat64 *'
which relates to a call of _fstati64() in the mingw_fstat()
function definition.
This is caused by various layers of macro magic and attempts to
avoid macro redefinition compiler warnings. For example, the call
to _fstati64() mentioned above is actually a call to _fstat64(),
since macro _USE_32BIT_TIME_T is not defined, and expects a pointer
to a struct _stat64 rather than the struct _stati64 which is passed
to mingw_fstat().
The definition of struct _stati64 given in compat/msvc.h had the
same "shape" as the definition of struct _stat64, so the call to
_fstat64() does not actually cause any runtime errors, but the
structure types are indeed incompatible. Also, the "shape" of
struct _stati64 changes, depending on the _USE_32BIT_TIME_T
macro, since the time_t type is defined as either __time64_t or
__time32_t.
When _USE_32BIT_TIME_T is defined, the call to _fstati64() is
actually a call to _fstat32i64() and expects a struct _stat32i64
pointer parameter. (struct _stati64 would again have the same
"shape" as struct _stat32i64).
The _USE_32BIT_TIME_T macro, along with all of the additional
structure type definitions, function definitions, and overloading
macro magic was introduced in msvc 2005.
In order to avoid the compiler warning, we add declarations for the
mingw_lstat() and mingw_fstat() functions and supporting macros to
msvc.h, suppressing the corresponding declarations in mingw.h, so
that we can use the appropriate structure type (and function) names
from the msvc headers.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Changes from v1:
- moved the new declarations to msvc.h rather than clutter mingw.h
with msvc related code.
- don't even attempt to support older msvc compilers
The patch is still marked RFC because:
- I'm still not sure if the flexibility to support both 32- and 64-bit
time_t is required.
- should -D_USE_32BIT_TIME_T be added to the Makefile?
ATB,
Ramsay Jones
compat/mingw.h | 4 +++-
compat/msvc.h | 54 +++++++++++++++++++++++++++++-------------------------
2 files changed, 32 insertions(+), 26 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 5b5258b..b5cec7f 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -175,13 +175,15 @@ int mingw_getpagesize(void);
* mingw_fstat() instead of fstat() on Windows.
*/
#define off_t off64_t
-#define stat _stati64
#define lseek _lseeki64
+#ifndef ALREADY_DECLARED_STAT_FUNCS
+#define stat _stati64
int mingw_lstat(const char *file_name, struct stat *buf);
int mingw_fstat(int fd, struct stat *buf);
#define fstat mingw_fstat
#define lstat mingw_lstat
#define _stati64(x,y) mingw_lstat(x,y)
+#endif
int mingw_utime(const char *file_name, const struct utimbuf *times);
#define utime mingw_utime
diff --git a/compat/msvc.h b/compat/msvc.h
index 9c753a5..f431007 100644
--- a/compat/msvc.h
+++ b/compat/msvc.h
@@ -21,30 +21,34 @@ static __inline int strcasecmp (const char *s1, const char *s2)
}
#undef ERROR
-#undef stat
-#undef _stati64
+
+/* Use mingw_lstat() instead of lstat()/stat() and mingw_fstat() instead
+ * of fstat(). We add the declaration of these functions here, suppressing
+ * the corresponding declarations in mingw.h, so that we can use the
+ * appropriate structure type (and function) names from the msvc headers.
+ */
+#if defined(_USE_32BIT_TIME_T)
+# define stat _stat32i64
+#else
+# define stat _stat64
+#endif
+
+int mingw_lstat(const char *file_name, struct stat *buf);
+int mingw_fstat(int fd, struct stat *buf);
+
+#define fstat mingw_fstat
+#define lstat mingw_lstat
+
+#if defined(_USE_32BIT_TIME_T)
+# define _stat32i64(x,y) mingw_lstat(x,y)
+#else
+# define _stat64(x,y) mingw_lstat(x,y)
+#endif
+
+#define ALREADY_DECLARED_STAT_FUNCS
+
#include "compat/mingw.h"
-#undef stat
-#define stat _stati64
-#define _stat64(x,y) mingw_lstat(x,y)
-
-/*
- Even though _stati64 is normally just defined at _stat64
- on Windows, we specify it here as a proper struct to avoid
- compiler warnings about macro redefinition due to magic in
- mingw.h. Struct taken from ReactOS (GNU GPL license).
-*/
-struct _stati64 {
- _dev_t st_dev;
- _ino_t st_ino;
- unsigned short st_mode;
- short st_nlink;
- short st_uid;
- short st_gid;
- _dev_t st_rdev;
- __int64 st_size;
- time_t st_atime;
- time_t st_mtime;
- time_t st_ctime;
-};
+
+#undef ALREADY_DECLARED_STAT_FUNCS
+
#endif
--
1.6.5
^ permalink raw reply related
* Re: Wrong damage counting in diffcore_count_changes?
From: Linus Torvalds @ 2009-12-04 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0912041419540.24579@localhost.localdomain>
On Fri, 4 Dec 2009, Linus Torvalds wrote:
>
> It also looks a bit like diffcore-break actually worked around this whole
> thing, and does
>
> /* sanity */
> if (src->size < src_copied)
> src_copied = src->size;
> if (dst->size < literal_added + src_copied) {
> if (src_copied < dst->size)
> literal_added = dst->size - src_copied;
> else
> literal_added = 0;
> }
> src_removed = src->size - src_copied;
>
> so this _may_ change what -B does, but I get the feeling that it should
> improve that too. I'm running a before-and-after "git log -M -B --summary"
> on the kernel now, but it's a pretty expensive operation, so it hasn't
> finished yet.
Ok, somewhat confirmed. Before-and-after changes:
- commit 2def7b8bcd4c49ca71a950611c9d456fd35282d2
- 2 files changed, 187 insertions(+), 218 deletions(-)
- delete mode 100644 drivers/staging/hv/include/ChannelMessages.h
+ 1 files changed, 109 insertions(+), 4 deletions(-)
+ rename drivers/staging/hv/{include/ChannelMessages.h => ChannelMgmt.h} (70%)
ie it _used_ to get broken up, now it shows up as a rename, presumably
due to better scoring.
- commit 64a1403d797d38c0bd18ba43bda5653c012c0d58. Similar.
- commit 3ce0a23d2d253185df24e22e3d5f89800bb3dd1c
- 34 files changed, 8316 insertions(+), 633 deletions(-)
- create mode 100644 drivers/gpu/drm/radeon/avivod.h
+ 34 files changed, 8287 insertions(+), 643 deletions(-)
+ copy drivers/gpu/drm/radeon/{radeon_share.h => avivod.h} (50%)
that looks like a smaller diff, judging by the line counts
- commit 9f77da9f40045253e91f55c12d4481254b513d2d
- 4 files changed, 358 insertions(+), 328 deletions(-)
+ 4 files changed, 132 insertions(+), 420 deletions(-)
rewrite include/linux/rcutree.h (73%)
+ rename {include/linux => kernel}/rcutree.h (80%)
- commit d15dd3e5d74186a3b0a4db271b440bbdc0f6da36
- 6 files changed, 75 insertions(+), 41 deletions(-)
- create mode 100644 drivers/net/wireless/ath/ath.h
+ 6 files changed, 59 insertions(+), 47 deletions(-)
+ copy drivers/net/wireless/ath/{main.c => ath.h} (73%)
- commit cf4f1e76c49dacfde0680b170b9a9b6a42f296bb
- 2 files changed, 716 insertions(+), 714 deletions(-)
+ 2 files changed, 371 insertions(+), 1034 deletions(-)
rewrite drivers/usb/host/r8a66597.h (62%)
+ rename {drivers/usb/host => include/linux/usb}/r8a66597.h (65%)
- commit d69864158e24f323e818403c6b89ad4871aea6f6
- 4 files changed, 172 insertions(+), 238 deletions(-)
+ 3 files changed, 90 insertions(+), 106 deletions(-)
+ rename arch/sparc/include/asm/{dma-mapping_64.h => dma-mapping.h} (71%)
delete mode 100644 arch/sparc/include/asm/dma-mapping_32.h
- delete mode 100644 arch/sparc/include/asm/dma-mapping_64.h
etc. From what I can see, it looks like in general it picked better things
with the new diffcore_count_changes() implementation, Looking at just the
"files changed" summaries, it tends to look like this:
- 21 files changed, 5659 insertions(+), 3227 deletions(-)
+ 19 files changed, 5723 insertions(+), 2285 deletions(-)
- 3 files changed, 645 insertions(+), 654 deletions(-)
+ 3 files changed, 387 insertions(+), 820 deletions(-)
- 11 files changed, 187 insertions(+), 177 deletions(-)
+ 10 files changed, 166 insertions(+), 109 deletions(-)
- 100 files changed, 1114 insertions(+), 3388 deletions(-)
+ 99 files changed, 1102 insertions(+), 3337 deletions(-)
- 2 files changed, 127 insertions(+), 106 deletions(-)
+ 2 files changed, 113 insertions(+), 92 deletions(-)
- 7 files changed, 128 insertions(+), 59 deletions(-)
+ 7 fileas changed, 87 insertions(+), 69 deletions(-)
- 154 files changed, 3641 insertions(+), 4232 deletions(-)
+ 154 files changed, 3635 insertions(+), 4233 deletions(-)
- 24 files changed, 162 insertions(+), 226 deletions(-)
+ 23 files changed, 61 insertions(+), 77 deletions(-)
- 4 files changed, 1995 insertions(+), 2114 deletions(-)
+ 3 files changed, 796 insertions(+), 814 deletions(-)
- 3 files changed, 1104 insertions(+), 1114 deletions(-)
+ 3 files changed, 886 insertions(+), 1038 deletions(-)
- 46 files changed, 17743 insertions(+), 5986 deletions(-)
+ 46 files changed, 16239 insertions(+), 6636 deletions(-)
- 9 files changed, 295 insertions(+), 284 deletions(-)
+ 9 files changed, 203 insertions(+), 291 deletions(-)
ie I can see several cases where the new break choice resulted in fewer
files changed and/or fewer over-all lines changed (due to better rename
choices), and I haven't seen any going the other way. There's probably
some, but it does seem that in general the patch results in better picks
(when it makes any difference in the first place - there seems to be only
71 commits in the kernel git tree that are affected at all)
Linus
^ 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