* 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
* [PATCH] Add commit.infodisplay option to give message editor empty file
From: James P. Howard, II @ 2009-12-04 23:04 UTC (permalink / raw)
To: git; +Cc: James P. Howard, II
This patch creates commit.infodisplay which causes git commit to
display the status information on the standard output rather
than in the temporary file for the commit message. By doing
this, it becomes feasible to set core.editor for commit messages
to be a line editor, e.g. ex or ed.
Signed-off-by: James P. Howard, II <jh@jameshoward.us>
---
Documentation/config.txt | 5 +++++
builtin-commit.c | 31 ++++++++++++++++++-------------
cache.h | 1 +
environment.c | 3 +++
4 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a1e36d7..56b3238 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -705,6 +705,11 @@ color.ui::
terminal. When more specific variables of color.* are set, they always
take precedence over this setting. Defaults to false.
+commit.infodisplay::
+ When true and a commit message is not specified on the command line,
+ the status information is not placed in the message template but is
+ printed to the standard output.
+
commit.template::
Specify a file to use as the template for new commit messages.
"{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the
diff --git a/builtin-commit.c b/builtin-commit.c
index e93a647..e4db374 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -463,7 +463,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
int commitable, saved_color_setting;
struct strbuf sb = STRBUF_INIT;
char *buffer;
- FILE *fp;
+ FILE *fp, *infofp;
const char *hook_arg1 = NULL;
const char *hook_arg2 = NULL;
int ident_shown = 0;
@@ -540,7 +540,12 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
if (fwrite(sb.buf, 1, sb.len, fp) < sb.len)
die_errno("could not write commit template");
-
+ if (info_display)
+ infofp = stdout;
+ else {
+ infofp = fp;
+ fprintf(infofp, "\n");
+ }
strbuf_release(&sb);
determine_author_info();
@@ -552,7 +557,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
const char *committer_ident;
if (in_merge)
- fprintf(fp,
+ fprintf(infofp,
"#\n"
"# It looks like you may be committing a MERGE.\n"
"# If this is not correct, please remove the file\n"
@@ -561,28 +566,27 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
"#\n",
git_path("MERGE_HEAD"));
- fprintf(fp,
- "\n"
+ fprintf(infofp,
"# Please enter the commit message for your changes.");
if (cleanup_mode == CLEANUP_ALL)
- fprintf(fp,
+ fprintf(infofp,
" Lines starting\n"
"# with '#' will be ignored, and an empty"
" message aborts the commit.\n");
else /* CLEANUP_SPACE, that is. */
- fprintf(fp,
+ fprintf(infofp,
" Lines starting\n"
"# with '#' will be kept; you may remove them"
" yourself if you want to.\n"
"# An empty message aborts the commit.\n");
if (only_include_assumed)
- fprintf(fp, "# %s\n", only_include_assumed);
+ fprintf(infofp, "# %s\n", only_include_assumed);
author_ident = xstrdup(fmt_name(author_name, author_email));
committer_ident = fmt_name(getenv("GIT_COMMITTER_NAME"),
getenv("GIT_COMMITTER_EMAIL"));
if (strcmp(author_ident, committer_ident))
- fprintf(fp,
+ fprintf(infofp,
"%s"
"# Author: %s\n",
ident_shown++ ? "" : "#\n",
@@ -590,18 +594,18 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
free(author_ident);
if (!user_ident_explicitly_given)
- fprintf(fp,
+ fprintf(infofp,
"%s"
"# Committer: %s\n",
ident_shown++ ? "" : "#\n",
committer_ident);
if (ident_shown)
- fprintf(fp, "#\n");
+ fprintf(infofp, "#\n");
saved_color_setting = s->use_color;
s->use_color = 0;
- commitable = run_status(fp, index_file, prefix, 1, s);
+ commitable = run_status(infofp, index_file, prefix, 1, s);
s->use_color = saved_color_setting;
} else {
unsigned char sha1[20];
@@ -1006,7 +1010,8 @@ static int git_commit_config(const char *k, const char *v, void *cb)
if (!strcmp(k, "commit.template"))
return git_config_pathname(&template_file, k, v);
-
+ if (!strcmp(k, "commit.infodisplay"))
+ info_display = git_config_bool(k, v);
return git_status_config(k, v, s);
}
diff --git a/cache.h b/cache.h
index bf468e5..2b36fb3 100644
--- a/cache.h
+++ b/cache.h
@@ -529,6 +529,7 @@ extern int auto_crlf;
extern int read_replace_refs;
extern int fsync_object_files;
extern int core_preload_index;
+extern int info_display;
enum safe_crlf {
SAFE_CRLF_FALSE = 0,
diff --git a/environment.c b/environment.c
index 5171d9f..ac7cfed 100644
--- a/environment.c
+++ b/environment.c
@@ -55,6 +55,9 @@ int grafts_replace_parents = 1;
/* Parallel index stat data preload? */
int core_preload_index = 0;
+/* Controls whether commit information is appended to message text or displayed */
+int info_display = 0;
+
/* This is set by setup_git_dir_gently() and/or git_default_config() */
char *git_work_tree_cfg;
static char *work_tree;
--
1.6.5.3
^ permalink raw reply related
* [PATCH] bash: update 'git commit' completion
From: SZEDER Gábor @ 2009-12-05 0:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, SZEDER Gábor
I just wanted to add the recently learnt '--reset-author' option, but
then noticed that there are many more options missing. This patch
adds support for all of 'git commit's options, except '--allow-empty',
because it is primarily there for foreign scm interfaces.
Furthermore, this patch also adds support for completing the arguments
of those options that take a non-filename argument: valid modes are
offered for '--cleanup' and '--untracked-files', while refs for
'--reuse-message' and '--reedit-message', because these two take a
commit as argument.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 11bf17a..7c18b0c 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -896,11 +896,31 @@ _git_commit ()
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
+ --cleanup=*)
+ __gitcomp "default strip verbatim whitespace
+ " "" "${cur##--cleanup=}"
+ return
+ ;;
+ --reuse-message=*)
+ __gitcomp "$(__git_refs)" "" "${cur##--reuse-message=}"
+ return
+ ;;
+ --reedit-message=*)
+ __gitcomp "$(__git_refs)" "" "${cur##--reedit-message=}"
+ return
+ ;;
+ --untracked-files=*)
+ __gitcomp "all no normal" "" "${cur##--untracked-files=}"
+ return
+ ;;
--*)
__gitcomp "
--all --author= --signoff --verify --no-verify
--edit --amend --include --only --interactive
- --dry-run
+ --dry-run --reuse-message= --reedit-message=
+ --reset-author --file= --message= --template=
+ --cleanup= --untracked-files --untracked-files=
+ --verbose --quiet
"
return
esac
--
1.6.6.rc1.54.g791207
^ permalink raw reply related
* Re: [ANNOUNCE] Git 1.6.5.4
From: Junio C Hamano @ 2009-12-05 7:28 UTC (permalink / raw)
To: Todd Zullinger; +Cc: Andreas Schwab, Michael J Gruber, git
In-Reply-To: <20091204193355.GC4629@inocybe.localdomain>
Todd Zullinger <tmz@pobox.com> writes:
> 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'd rather see it set to an empty string by default which will essentially
keep the old output. An alternative would be to default to the location
the install-html target installs, i.e. $HOME/share/doc/git-doc pointed by
$(htmldir) in Documentation/Makefile.
Distro people should be strongly encouraged to repoint the variable to
somewhere local that does not require connections to k.org or anywhere
outside the end-user's installation, but that is a slightly separate and
different topic.
^ permalink raw reply
* Re: [PATCH] Add commit.infodisplay option to give message editor empty file
From: Junio C Hamano @ 2009-12-05 7:30 UTC (permalink / raw)
To: James P. Howard, II; +Cc: git
In-Reply-To: <1259967879-65517-1-git-send-email-jh@jameshoward.us>
"James P. Howard, II" <jh@jameshoward.us> writes:
> This patch creates commit.infodisplay which causes git commit to
> display the status information on the standard output rather
> than in the temporary file for the commit message. By doing
> this, it becomes feasible to set core.editor for commit messages
> to be a line editor, e.g. ex or ed.
Two points and a half:
- Why does info_display need to be visible to everybody else by being in
cache.h and environment.c? Shouldn't its scope be similar to that of
template_file, that is static to builtin-commit.c?
- A configuration variable that does not allow the users to override from
the command line is a no-no. We usually do command line option first
and then (or at the same time) configuration variable as a typesaver.
- While the amount of change necessary for this change doesn't look too
bad, is it really worth it? What is wrong with "1,$p" while using ed
as your editor?
^ permalink raw reply
* Re: Git GUI client SmartGit released
From: Dilip M @ 2009-12-05 7:37 UTC (permalink / raw)
To: Marc Strapetz; +Cc: git
In-Reply-To: <4B161B15.2020106@syntevo.com>
2009/12/2 Marc Strapetz <marc.strapetz@syntevo.com>:
> We are proud to announce the general availability of our Git client
> SmartGit[1]:
>
> http://www.syntevo.com/smartgit/index.html
>
> Thank you, Git community, for the great DVCS you are building and the
> feed-back to SmartGit!
Man! this is what missing for GIT! Way to go!
--
Dilip
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Junio C Hamano @ 2009-12-05 7:39 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Johannes Schindelin, Junio C Hamano, Matthieu Moy,
Michael J Gruber, Michael Haggerty, git
In-Reply-To: <20091205062708.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> I think Junio is referring to this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/127923/focus=121874
Yes, that was the one I had in mind, and it is a shame that we somehow
ended up not taking it, perhaps in an improved form, back then. Even
today alone, I missed the "mark for later fixing/squashing and then rebase
at the end" feature twice at dayjob.
> 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").
There is a slight distinction between "Shawn's fix-up commits have garbage
message and he does not want any part of them in the final commit message"
and "Shawn is happy with the message of the original commit whose tree
these fix-up commits are meant to correct." He may still not be entirely
happy with the original message. Wanting to edit the commit log message,
and not wanting to use the messages from follow-up commits, are two
different things.
I would agree that it is a good idea for "rebase -i" with only "fix" and
not "squash" to skip the editing of the final message. You manually move,
or tell your "rebase --autosquash" option to automatically move, the
follow-up commits next to the ones they are meant to correct while editing
the rebase-i insn, and you change their "pick" to "fix" (or "fixup" as
Dscho and others suggested in the earlier round you quoted) only when you
know you want to keep the message of the original commit. Otherwise you
can change them to "squash" not to "fix", and you can edit the final log
message that way.
If Michael rolls his second round with your "--autosquash", or you do so
yourself on top of his patch, I think it _might_ be safer to mark the ones
automatically moved as "squash", and not as "fix", and have the users
explicitly change the "squash" they want to "fix" themselves.
Alternatively, you can also use two magic tokens (i.e. instead of one
"fixup!", allow people to use "squash!" and "fixup!") and change the
action chosen for the moved commits to "squash" and "fixup" respectively.
> 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?
The answer to the first question is "yes"---I did't understand why Dscho
objected to a feature he can choose not to use if he doesn't want to, and
I still don't (unless I was misreading your earlier patch back then and it
somehow forced all rebase-i users to decide upfront at the commit time,
but I highly doubt it).
I don't know about the second one but I am guessing it would also be
"yes".
^ permalink raw reply
* Re: git gsoc money
From: Christian Couder @ 2009-12-05 10:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, git, Junio C Hamano
In-Reply-To: <20091203153935.GB23281@spearce.org>
On jeudi 03 décembre 2009, Shawn O. Pearce wrote:
> Jeff King <peff@peff.net> wrote:
> > However, we still have about $500 USD remaining.
> >
> > Some possibilities are:
> >
> > 1. Become an affiliated project of an organization like The Software
> > Freedom Conservancy or Software in the Public Interest.
>
> Try to join the Software Freedom Conservancy and retain the funds
> for Git's use? Maybe you can slide in before the Dec 31st deadline.
Yeah, that would be a great. Thanks for doing that!
> I know a few users of Git have said they can't contribute code, but
> they would like to throw $25-50 towards a developer to say thank you.
> This would give them an easier vehicle to do that.
>
> I'm not saying we should actively seek donations, we have virtually
> no expenses and don't need them.
>
> But we do sometimes have these GitTogether things, or one of us is
> going to a Linux Plumbers conference or something to give a talk
> promoting Git. Having $500 from a handful of donations available
> to defray Git related travel costs for some of our more active
> developers is more useful than having a user send something from
> an Amazon wish list [1][2].
I benefited from the GSoC fund last year and much appreciated having my
travel expenses to go to the GitTogether reimbursed.
But I think it is ok too for developers to have an amazon wish list, so
donors can choose. And by the way Junio has one:
http://www.amazon.com/gp/registry/wishlist/1513KNZE30W63
so everyone is welcome to buy him something!
> At worst, if we collect a bunch of money and realize "Oh, wait,
> we have like $8000 USD and we haven't spent any of it in the past
> 5 years!" we can have the SFC do a big donation to FSF or something
> and say "thanks for GCC!".
>
> If joining the SFC proves too difficult, just donate the $500 to
> the FSF. That's what we did the first year we were in GSoC.
Another way we could perhaps use the funds (especially if we have to do that
before the end of the year) could be to defray membership costs if some
developers want to join (or are already member of) some related
organisation like the Linux Foundation:
http://www.linuxfoundation.org/about/join/individual/
or the FSF:
http://www.fsf.org/associate/
Best regards,
Christian.
^ permalink raw reply
* Re: [RFC PATCH v2 2/2] MSVC: Fix an "incompatible pointer types" compiler warning
From: Johannes Sixt @ 2009-12-05 11:57 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Marius Storm-Olsen, Johannes Schindelin, GIT Mailing-list
In-Reply-To: <4B1997A0.9000004@ramsay1.demon.co.uk>
[Removed Junio from Cc because IIUC, he prefers to be left out of the loop in
Windows related matters until they have settled.]
On Samstag, 5. Dezember 2009, Ramsay Jones wrote:
> 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?
If *not* using -D_USE_32BIT_TIME_T produces a build or code base that is in
some way superior, why should we require it? For example, its absence could
help a 64bit build.
-- Hannes
^ permalink raw reply
* Re: [RFC PATCH v2 4/8] Support remote helpers implementing smart transports
From: Ilari Liusvaara @ 2009-12-05 13:16 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091204183713.GE1483@spearce.org>
On Fri, Dec 04, 2009 at 10:37:13AM -0800, Shawn O. Pearce wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
>
> Why not 'fallback' to remain consistent with this protocol and many
> others in git where we stick to lowercase ASCII?
Changed.
> 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.
That's just extremely badly worded. The point is that only place where
buffering has even seemed useful is initial adverts. Those can
really trigger large numbers of small transfers if unbuffered.
Granted, small delay should work quite well.
I'll reword it.
> 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?
Actually, it can't be NULL (the code would have already die()'d in
that case). Fixed.
> 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.
Actually, there was bug in initializing git options struct. It was
properly initialized if one used foo://, but not with foo::bar://.
Tripping it caused NULL exec to be passed if you didn't override.
I fixed that bug and now the servpath code has just strcmp.
> 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.
This is exactly what happens (and yes, I tested). No --receive-pack
doesn't trip warning, with --receive-pack it does.
-Ilari
^ permalink raw reply
* Re: [RFC PATCH v2 1/8] Pass unknown protocols to external protocol handlers
From: Ilari Liusvaara @ 2009-12-05 13:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091204175545.GC1483@spearce.org>
On Fri, Dec 04, 2009 at 09:55:45AM -0800, Shawn O. Pearce wrote:
<fd dupping code>
> This is an entirely unrelated change. Please split it into its
> own commit so its easier to review, test, blah blah blah.
Moved to 3/8, since that's where it actually will be needed (latter
rearrangement renumbered that patch to 5/8).
-Ilari
^ permalink raw reply
* Re: [RFC PATCH v2 3/8] Support taking over transports
From: Ilari Liusvaara @ 2009-12-05 13:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091204182753.GD1483@spearce.org>
On Fri, Dec 04, 2009 at 10:27:53AM -0800, Shawn O. Pearce wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> > Add support for taking over transports that turn out to be smart.
>
> 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?
The code complexity difference is not big. The magic return was for
historic reasons that no longer apply (and didn't get fixed when
corresponding upstream changes happned).
Namely, the push/push_refs impedance mismatch. Helpers used push,
smart transports used push_refs. But now that both use push_refs,
the handler can be invoked directly from push_refs of helper.
Fixed.
-Ilari
^ 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