* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Marius Storm-Olsen @ 2009-08-18 17:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <alpine.DEB.1.00.0908181605370.4680@intel-tinevez-2-302>
Johannes Schindelin said the following on 18.08.2009 16:11:
> On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
>> So, instead of rely on these vcproj files which *will* go stale, we
>> can simply use the same Makefile system which everyone else is
>> using. :) After all, we're just compiling with a different
>> compiler. The end result will still rely on the *msysGit
>> environment* to function, so we already require it. Thus, GNU Make
>> is present, and we can use it.
>
> We can also use sed or perl to generate/modify the .vcproj files, or
> run CMake (once Pau got it to build), and package the stuff using zip
> (once I got that to build).
Really? That would be some script being able to parse the Makefile, and
create something reasonable as a vcproj script :) Keeping all the
options in sync, conditional files/libs, all the various end executables
(a separate .vcproj for each of them, and a solution file (.sln)to tie
them all together into a .. "solution", a complete product blah blah
blah) etc.
Just using the (GNU) Makefile as the 'default' way of compiling with
MSVC seems to be the most reasonable to me. Then we could just have a
contrib/vc/msvc2008.vcproj which someone can update when they feel like
it. The default way should be hard to get out-of-sync, IMO.
>> diff --git a/Makefile b/Makefile
>> +ifneq (,$(findstring Microsoft Visual Studio, $(INCLUDE)))
...
>> +else
>> ifneq (,$(findstring MINGW,$(uname_S)))
>> pathsep = ;
>> NO_PREAD = YesPlease
>
> This means that gcc is never used when Visual C++ is available? Hmm.
Yes it does :)
First, "This implementation is a quick hack to make it compile", so it
was all about just making it compile, not being 100% correct. There are
still some warnings and options which shouldn't be passed on to cl, so
it's by no means complete. Second, having MSVC include paths in INCLUDE
when you're compiling with MinGW would be plain wrong. I could use LIB
instead, which would be even wronger ;)
I was actually going to replace it with a USE_MSVC variable check
instead though, so you'd rather do 'make USE_MSVC=1'
>> diff --git a/compat/msvc.h b/compat/msvc.h
>> index 6071565..a9d5f7f 100644
>> --- a/compat/msvc.h
>> +++ b/compat/msvc.h
>> @@ -10,50 +10,120 @@
>>
>> /*Configuration*/
>>
>> +#ifndef NO_PREAD
>> #define NO_PREAD
>> +#endif
>
> Why? You now have the stuff in two places. If you want to keep them in
> compat/msvc.h to be able to generate .vcproj files, I'd rather not have
> them duplicated in the Makefile.
The changes to the msvc.h where added just keep Frank's vcproj project
working. I would have just nuked all that stuff in the msvc.h since the
Makefile would just provide it for me anyways..
--
.marius
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Paolo Bonzini @ 2009-08-18 17:44 UTC (permalink / raw)
To: Pau Garcia i Quiles
Cc: Johan 't Hart, Marius Storm-Olsen, Johannes.Schindelin,
msysgit, git, lznuaa, kusmabite
In-Reply-To: <3af572ac0908181006n2e00b561x374007bff2e2d31f@mail.gmail.com>
> CMake is also useful to create installers/tarballs (see CPack), run
> tests (see CTest; it's NOT a unit test library but a tests launcher on
> steroids) and submit the results of compilation, tests and
> installation to a dashboard where you can easily see what (if
> anything) went wrong (see CDash, formerly Dart).
If I know the git hackers, CMake will _never_ be used except _possibly_
for generating a .vcproj file.
Paolo
^ permalink raw reply
* Re: [RFC PATCH] stash: accept options also when subcommand 'save' is omitted
From: Jeff King @ 2009-08-18 17:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Johannes Schindelin
In-Reply-To: <vpqws51l1hb.fsf@bauges.imag.fr>
On Tue, Aug 18, 2009 at 03:01:52PM +0200, Matthieu Moy wrote:
> Hmm, googling a bit, I just noticed that there's already something in
> pu:
> ea41cfc4f (Make 'git stash -k' a short form for 'git stash save --keep-index')
> which also does the trick, while adding a -k alias for --keep-index.
>
> [...]
>
> Mine has at least two advantages:
>
> * It won't require changing the code again when new options are added
> to 'git stash save'.
>
> * It works with 'git stash -k -q' for example, while the other
> proposal checks that $# == 1, which won't work if there are more
> than one option.
I think yours is nicer, especially as we have just added the
'-p|--patch' option, as well. With what is there now, you can do "git
stash -p", but not "git stash -p -k".
> But I may have missed its drawbacks ;-)
The only I can think of is that bogus input will provoke 'save'. So
something like:
git stash --apply
will invoke "git stash save --apply", which doesn't even complain. It
just tries to make a stash with message --apply. Now of course this
input is obviously bogus, but probably the right thing to do is
complain.
OTOH, I think it is the fault of "git stash save --apply" for not doing
the complaining, so your patch really isn't making it worse. Probably it
should barf on anything unrecognized starting with a '-', and allow '--'
to separate the message from the rest of the options (in the rare case
that you want a message starting with '-').
-Peff
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johan 't Hart @ 2009-08-18 17:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa,
bonzini, kusmabite
In-Reply-To: <7vtz05dq0p.fsf@alter.siamese.dyndns.org>
Junio C Hamano schreef:
> Since use of make implies use of shell, this makes me wonder if it would
> make sense to go one step further by giving msvc users a thin shell
> wrapper mcvc-cc that turns bog-standard cc command line into whatever cl
> uses.
Just using the msvc toolchain for building git misses the whole purpose
of what VC is used for. MSVC would be used because of the IDE, not for
the compiler IMO. msysgit already has a nice toolchain, using gcc, to
build git. I think there is no reason to use MSVC for that purpose.
The purpose of CMake was to build an .vcproj file to be used by the IDE,
not for a batch process that builds git with the VC toolchain. Users
could than hack git with the IDE from MSVC. And ofcource git should then
also be compilable by MSVC's cl.exe, because the IDE is not capable of
using another toolchain then its own...
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Marius Storm-Olsen @ 2009-08-18 17:38 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Johannes.Schindelin, msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <alpine.LNX.2.00.0908181226160.7195@iabervon.org>
Daniel Barkalow said the following on 18.08.2009 18:51:
> On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
>
>> From: Marius Storm-Olsen <mstormo@gmail.com>
>>
>> By using GNU Make we can also compile with the MSVC toolchain.
>> This is a rudementary patch, only meant as an RFC for now!!
>>
>> !! DO NOT COMMIT THIS UPSTREAM !!
>> ---
>> So, instead of rely on these vcproj files which *will* go stale, we can
>> simply use the same Makefile system which everyone else is using. :)
>> After all, we're just compiling with a different compiler. The end result
>> will still rely on the *msysGit environment* to function, so we already
>> require it. Thus, GNU Make is present, and we can use it.
>>
>> This implementation is a quick hack to make it compile (hence the RFC
>> subject), so please don't even consider basing anything ontop of it ;)
>>
>> But, do point out all the do's and don'ts, and I'll try to polish it up
>> to something which we can add to Frank's series..
>>
>>
>> Makefile | 97 +++++++++++++++++++++++++++++++++++++++++++++++---------
>> compat/msvc.h | 77 +++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 158 insertions(+), 16 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index daf4296..2e14976 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -214,9 +214,13 @@ uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
>>
>> CFLAGS = -g -O2 -Wall
>> LDFLAGS =
>> +ARFLAGS = rcs\ # whitespace intentional
>> ALL_CFLAGS = $(CFLAGS)
>> ALL_LDFLAGS = $(LDFLAGS)
>> STRIP ?= strip
>> +COMPFLAG = -c
>> +COBJFLAG = -o\ # whitespace intended
>> +LOBJFLAG = -o\ # whitespace intended
>
> I think it's nicer to write the significant whitespace with non-whitespace
> text using something like:
>
> empty=
> space=$(empty) $(empty)
>
> (...)
>
> ARFLAGS = rcs$(space)
>
> COBJFLAG = -o$(space)
>
> On the other hand, I think it would be clearer to put the "rcs" in the
> default version of $(AR), and have a $(AROBJFLAG) set to nothing there,
> since the "rcs" isn't actually at all like the "-OUT:" with respect to
> what it's doing there.
>
> Possibly also to have two variables for the output of the toolchain
> wrapper, one that is before the name of the file and one that's attached
> to the name of the file.
I agree on all accounts. If we don't go for a wrapper script, as Junio
suggested, then I'll definitely do it like you suggested.
--
.marius
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Marius Storm-Olsen @ 2009-08-18 17:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes.Schindelin, msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <7vtz05dq0p.fsf@alter.siamese.dyndns.org>
Junio C Hamano said the following on 18.08.2009 18:51:
> Marius Storm-Olsen <mstormo@gmail.com> writes:
>
> Marius Storm-Olsen <mstormo@gmail.com> writes:
>
>> +ARFLAGS = rcs\ # whitespace intentional
>> +COMPFLAG = -c
>> +COBJFLAG = -o\ # whitespace intended
>> +LOBJFLAG = -o\ # whitespace intended
>> ...
>> +ifneq (,$(findstring Microsoft Visual Studio, $(INCLUDE)))
>> + CC = cl
>> + COBJFLAG = -Fo
>> + LOBJFLAG = -OUT:
>> + CFLAGS =
>> git.o: git.c common-cmds.h GIT-CFLAGS
>> ...
>> - $(ALL_CFLAGS) -c $(filter %.c,$^)
>> + $(ALL_CFLAGS) $(COMPFLAG) $(COBJFLAG)git.o $(filter %.c,$^)
>
> Since use of make implies use of shell, this makes me wonder if it would
> make sense to go one step further by giving msvc users a thin shell
> wrapper mcvc-cc that turns bog-standard cc command line into whatever cl
> uses.
That, of course, is also a feasible option :)
However, there are still things you wouldn't want to pass on to this
script, for example, we don't pass on all the CFLAGS to the linker on
Windows.
The "whitespace intended" in the patch are quite nasty though..
--
.marius
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Pau Garcia i Quiles @ 2009-08-18 17:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marius Storm-Olsen, msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <alpine.DEB.1.00.0908181605370.4680@intel-tinevez-2-302>
On Tue, Aug 18, 2009 at 4:11 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
>
>> So, instead of rely on these vcproj files which *will* go stale, we can
>> simply use the same Makefile system which everyone else is using. :)
>> After all, we're just compiling with a different compiler. The end
>> result will still rely on the *msysGit environment* to function, so we
>> already require it. Thus, GNU Make is present, and we can use it.
>
> We can also use sed or perl to generate/modify the .vcproj files, or run
> CMake (once Pau got it to build), and package the stuff using zip (once I
> got that to build).
Re: package the stuff using ZIP, it's trivial to do with CPack (part
of the CMake chain). Just tell me what you want to get and I'll
implement it.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Pau Garcia i Quiles @ 2009-08-18 17:06 UTC (permalink / raw)
To: Johan 't Hart
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa,
bonzini, kusmabite
In-Reply-To: <4A8AD561.1020303@gmail.com>
On Tue, Aug 18, 2009 at 6:22 PM, Johan 't Hart<johanthart@gmail.com> wrote:
> Marius Storm-Olsen schreef:
>>
>> From: Marius Storm-Olsen <mstormo@gmail.com>
>>
>> By using GNU Make we can also compile with the MSVC toolchain.
>> This is a rudementary patch, only meant as an RFC for now!!
>>
>
> Would this mean that only the MSVC toolchain is used to build git in batch?
> Or does GNU Make create a .vcproj file like CMake?
That patch uses GNU Make but invoking the MSVC compiler, linker, etc
instead of the GNU compiler, linker, etc. It'd be the same if you
wanted to use the Intel compiler, the Sun compiler, etc.
> Because that ofcource is
> the whole purpose of using CMake. One can use the Visual Studio IDE to hack
> on git.
CMake is also useful to create installers/tarballs (see CPack), run
tests (see CTest; it's NOT a unit test library but a tests launcher on
steroids) and submit the results of compilation, tests and
installation to a dashboard where you can easily see what (if
anything) went wrong (see CDash, formerly Dart).
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Junio C Hamano @ 2009-08-18 17:05 UTC (permalink / raw)
To: Sebastian Schuberth
Cc: Nicolas Pitre, Junio C Hamano, Artur Skawina, Johannes Sixt,
msysGit, Linus Torvalds, Git Mailing List
In-Reply-To: <bdca99240908180959h69f37671k4d526fbf4814e8d1@mail.gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> I like the idea of making bswap available more globally, but I'm not
> sure if it's worth to introduce a new file for only that purpose.
> Isn't there already a central header for such things?
>
> Moreover, including compat/bswap.h would only give you ntohl()/htonl()
> on one platform.
We do not include compat/ directly from the source; git-compat-util.h is
supposed to be the first thing included (as some platforms have peculiar
requirements on the order in which system header files are included, and
one of the reasons git-compat-util.h is there). Hence by including it,
you get ntohl/htonl everywhere.
To reduce confusion, you may want to rename compat/bswap.h to something
like compat/ntohl-htonl-fix.h ;-)
^ permalink raw reply
* Re: Git User's Survey 2009 partial summary, part 2 - from first 10
From: Jakub Narebski @ 2009-08-18 17:00 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: git
In-Reply-To: <20090818155452.GA12938@vidovic>
On Tue, 18 Aug 2009, Nicolas Sebrecht wrote:
> The 17/08/09, Jakub Narebski wrote:
>
> > Git User's Survey 2009 partial summary, part 2 - git difficulty,
> > proficiency, uses, install, OS, editors.
>
> Thanks for these partial summaries.
You are welcome. Next summary either around 1 September (3/4 duration),
or after passing number of responses in previous survey; it also depends
when I would have time.
> > 3) Have you found Git easy to learn?
> > 4) Have you found Git easy to use?
> > (Choice - Single answer)
> >
> > ================================================
> > Answer | to learn [%] | to use [%]
> > ------------------------------------------------
> > Very easy | 4% | 9%
> > Easy | 20% | 36%
> > Reasonably easy | 55% | 45%
> > Hard | 19% | 8%
> > Very hard | 2% | 1%
> > ------------------------------------------------
> > Total respondents | 2942 | 2959
> > ================================================
>
> <...>
>
> > What's interesting is comparing (percentage) results for questions
> > 3. and 4.; how hard is git to learn versus how hard is to use. It
> > seems like Git is reasonably easy to learn, and reasonably easy to
> > easy to use. So it looks like Git just have somewhat steep learning
> > curve, and the difficulty to learn pays in being more powerful to
> > use.
>
> I believe it would be interesting to know who (from the question 6.)
> think what later. We may expect that people of the grade 4 and 5 ("can
> offer advice" and "know it very well") underestimate the difficulty to
> learn Git.
Well, you can do some analysis yourself, using just created filters at
http://www.survs.com/shareResults?survey=2PIMZGU0&rndm=678J66QRA2
For example:
================================================|
| proficiency with Git |
To learn |-----------------------------|
| any*[%] | 1-3 [%] | 4-5 [%] |
------------------------------------------------|
Very easy | 4% | 3% | 5% |
Easy | 20% | 19% | 22% |
Reasonably easy | 55% | 55% | 56% |
Hard | 19% | 20% | 16% |
Very hard | 2% | 3% | 1% |
------------------------------------------------|
Total respondents | 3005 | 1786 | 1212 |
================================================|
Footnote:
^^^^^^^^^
[*] This means no filter, which includes people who didn't answered
question about proficiency, but answered this one.
> Also (and as you said), this "Git's users" survey won't have answers
> from unsatisfied users who left Git. We can't rate the number of users
> who left Git because they found it too much hard to learn.
Here also you have to be careful about the fact that "correlation does
not imply causation" (or, if you prefer Latin version, "cum hoc ergo
propter hoc"). The causation might be both ways: gurus don't find
git hard to learn, or don't remember that it was hard to learn; people
who find git hard to learn do not become git gurus.
--
Jakub Narebski
http://git.or.cz/gitwiki/GitSurvey2009
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Sebastian Schuberth @ 2009-08-18 16:59 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908181240400.6044@xanadu.home>
On Tue, Aug 18, 2009 at 18:43, Nicolas Pitre<nico@cam.org> wrote:
>> Well... Given that git already uses ntohl/htonl quite extensively in
>> its core already, I'd suggest making this more globally available
>> instead.
>
> What about something like this?
I like the idea of making bswap available more globally, but I'm not
sure if it's worth to introduce a new file for only that purpose.
Isn't there already a central header for such things?
Moreover, including compat/bswap.h would only give you ntohl()/htonl()
on one platform. For consistency, I'd expect to get those for any
platform if I include compat/bswap.h, but maybe I'm not aware of some
Git source code rules.
Finally, there's a typo in your comment saying "sinple" instead of "simple".
--
Sebastian Schuberth
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function
From: Matthieu Moy @ 2009-08-18 16:52 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660908180911m7469ac20w48a28b90262d25f6@mail.gmail.com>
Frank Li <lznuaa@gmail.com> writes:
>> Okay, I will wait for Frank's updates (just fetched tgit.git and it still
>> contains the old branch), merge the early part and add the compiler flags.
>>
> Today, I just update 5 patch according review feedback.
> Do I need send it again?
Yes, this is the use here. Preferably edit the message to replace
[PATCH] with [PATCH v2] or so.
> How do I know if patch has been applied main line?
Answering the question with another: shouldn't we add a section like
this to SubmittingPatches ?
>From 3ee45ab5992fd084c130460f07454061ce3cf057 Mon Sep 17 00:00:00 2001
From: Matthieu Moy <Matthieu.Moy@imag.fr>
Date: Tue, 18 Aug 2009 18:48:47 +0200
Subject: [PATCH] SubmittingPatches: draft section to know patches status
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/SubmittingPatches | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 76fc84d..c686f86 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -280,6 +280,20 @@ people play with it without having to pick up and apply the patch to
their trees themselves.
------------------------------------------------
+Know the status of your patch after submission
+
+* You can use Git itself to find out when your patch is merged in
+ master. 'git pull --rebase' will automatically skip already-applied
+ patches, and will let you know. This works only if you rebase on top
+ of the branch in which your patch has been merged (i.e. it will not
+ tell you if your patch is merged in pu if you rebase on top of
+ master).
+
+* Read the git mailing list, the maintainer regularly posts messages
+ entitled "What's cooking in git.git" and "What's in git.git" giving
+ the status of various proposed changes.
+
+------------------------------------------------
MUA specific hints
Some of patches I receive or pick up from the list share common
--
1.6.4.313.g38b9
--
Matthieu
^ permalink raw reply related
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Daniel Barkalow @ 2009-08-18 16:51 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Johannes.Schindelin, msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <1250600335-8642-1-git-send-email-mstormo@gmail.com>
On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
> From: Marius Storm-Olsen <mstormo@gmail.com>
>
> By using GNU Make we can also compile with the MSVC toolchain.
> This is a rudementary patch, only meant as an RFC for now!!
>
> !! DO NOT COMMIT THIS UPSTREAM !!
> ---
> So, instead of rely on these vcproj files which *will* go stale, we can
> simply use the same Makefile system which everyone else is using. :)
> After all, we're just compiling with a different compiler. The end result
> will still rely on the *msysGit environment* to function, so we already
> require it. Thus, GNU Make is present, and we can use it.
>
> This implementation is a quick hack to make it compile (hence the RFC
> subject), so please don't even consider basing anything ontop of it ;)
>
> But, do point out all the do's and don'ts, and I'll try to polish it up
> to something which we can add to Frank's series..
>
>
> Makefile | 97 +++++++++++++++++++++++++++++++++++++++++++++++---------
> compat/msvc.h | 77 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 158 insertions(+), 16 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index daf4296..2e14976 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -214,9 +214,13 @@ uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
>
> CFLAGS = -g -O2 -Wall
> LDFLAGS =
> +ARFLAGS = rcs\ # whitespace intentional
> ALL_CFLAGS = $(CFLAGS)
> ALL_LDFLAGS = $(LDFLAGS)
> STRIP ?= strip
> +COMPFLAG = -c
> +COBJFLAG = -o\ # whitespace intended
> +LOBJFLAG = -o\ # whitespace intended
I think it's nicer to write the significant whitespace with non-whitespace
text using something like:
empty=
space=$(empty) $(empty)
(...)
ARFLAGS = rcs$(space)
COBJFLAG = -o$(space)
On the other hand, I think it would be clearer to put the "rcs" in the
default version of $(AR), and have a $(AROBJFLAG) set to nothing there,
since the "rcs" isn't actually at all like the "-OUT:" with respect to
what it's doing there.
Possibly also to have two variables for the output of the toolchain
wrapper, one that is before the name of the file and one that's attached
to the name of the file.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Junio C Hamano @ 2009-08-18 16:51 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Johannes.Schindelin, msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <1250600335-8642-1-git-send-email-mstormo@gmail.com>
Marius Storm-Olsen <mstormo@gmail.com> writes:
Marius Storm-Olsen <mstormo@gmail.com> writes:
> +ARFLAGS = rcs\ # whitespace intentional
> +COMPFLAG = -c
> +COBJFLAG = -o\ # whitespace intended
> +LOBJFLAG = -o\ # whitespace intended
> ...
> +ifneq (,$(findstring Microsoft Visual Studio, $(INCLUDE)))
> + CC = cl
> + COBJFLAG = -Fo
> + LOBJFLAG = -OUT:
> + CFLAGS =
> git.o: git.c common-cmds.h GIT-CFLAGS
> ...
> - $(ALL_CFLAGS) -c $(filter %.c,$^)
> + $(ALL_CFLAGS) $(COMPFLAG) $(COBJFLAG)git.o $(filter %.c,$^)
Since use of make implies use of shell, this makes me wonder if it would
make sense to go one step further by giving msvc users a thin shell
wrapper mcvc-cc that turns bog-standard cc command line into whatever cl
uses.
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Junio C Hamano @ 2009-08-18 16:50 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908181240400.6044@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 18 Aug 2009, Nicolas Pitre wrote:
>
>> Well... Given that git already uses ntohl/htonl quite extensively in
>> its core already, I'd suggest making this more globally available
>> instead.
>
> What about something like this?
For git's own use, I would be much happier with this change.
But given that there are some people wanting to snarf block-sha1/*.[ch]
out to use them standalone, I have a slight hesitation against introducing
the dependency to git-compat-util.h, making it unclear to them that all
this file wants from outside are ntohl, htonl and memcpy.
^ permalink raw reply
* Re: [PATCH v5 0/6] {checkout,reset,stash} --patch
From: Jeff King @ 2009-08-18 16:48 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, git, Sverre Rabbelier, Nanako Shiraishi,
Nicolas Sebrecht, Pierre Habouzit
In-Reply-To: <200908151204.36709.trast@student.ethz.ch>
On Sat, Aug 15, 2009 at 12:04:35PM +0200, Thomas Rast wrote:
> > Getting greedy, is there a reason not to have "stash apply -p" as well?
>
> Should be doable, I'll look at it.
I took a look at this today. It is actually a bit harder than I had
hoped. The problem is that a stash is not a _state_, but rather two
states whose difference is of interest to us.
So it's not right to just pick hunks out of the stash as compared with
the current tree. You will get "false" hunks for the changes between
the current tree and the base upon which the stash was created. In fact,
we actually do a full 3-way merge with the current state and the new
state with the stash base as the ancestor.
The strategy I employ in the patch below is to actually just prune the
stash tree against the base, and then use that result to do the merge.
For example, consider the following situation:
$ echo base >file && git add file && git commit -m base
$ echo stash >file && git stash
$ echo tree >file && git add file
Now you have a stash whose base has 'base' and whose content has
'stash', and your current tree has 'tree'. Applying the stash should
therefore cause a conflict (but I am using such a simple example because
we can still illustrate what's happening).
You can see that ignoring the base creates an incorrect result. You
would see that the stash has 'stash' and we have 'tree', and ask about
applying the hunk
-tree
+stash
but that's not right. We should have a conflict.
So what I do instead is to load the base tree into a temporary index,
then git-add--interactive the changes from the stashed tree, then put
write the result into a new tree, which becomes our new merge point. So
you will be asked if you want to apply the hunk
-base
+stash
If not, then the resulting tree will have 'base'. Since the base also
has 'base', the stash has done nothing, and the 3-way merge will keep
your tree contents. If you do, then the resulting tree will have
'stash', and you will have a 3-way merge with a conflict.
Now there is a slight problem with that. What if you had already applied
or recreated part of the stash? In other words, instead of 'tree' in
your current content, you had 'stash'? We would _still_ ask if you
wanted to replace 'base' with 'stash', even though when we get to the
three-way merge, it will be a no-op.
Hmm. I was about to write "so we need some clever way of integrating the
interactive hunk selection with a 3-way merge". But I just had a
thought: we should do it in the reverse order. We do the three-way merge
into a temporary index, and then ask the user to apply the result of
_that_ tree into the working tree. Or maybe I am missing something else
obvious and you can enlighten me.
I'll try to experiment with merging first, though I doubt I will have
any more time for the next day or two. In the meantime, you can peek at
the current patch I have below. It has two additional problems:
1. For --index mode, it actually invokes add--interactive twice. It
would be nice to do both passes at the same time, but I don't think
it is possible with the current add--interactive infrastructure.
2. You will notice a hack-ish 'sleep' in the test; because of the
double add--interactive, when piping from stdin, the first one eats
the responses in its input buffer and the second one never sees
them.
-Peff
---
git-add--interactive.perl | 28 ++++++++++++++++++++++++++++
git-stash.sh | 35 +++++++++++++++++++++++++++++------
t/t3905-stash-apply-patch.sh | 42 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 99 insertions(+), 6 deletions(-)
create mode 100755 t/t3905-stash-apply-patch.sh
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 392efb9..cbbf0a7 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -97,6 +97,28 @@ my %patch_modes = (
PARTICIPLE => 'stashing',
FILTER => undef,
},
+ 'stash-apply-tree' => {
+ DIFF => 'diff-index -R -p --cached',
+ APPLY => sub {
+ apply_patch 'apply --cached', $patch_mode_revision, @_;
+ },
+ APPLY_CHECK => 'apply --cached',
+ VERB => 'Apply',
+ TARGET => ' to working tree',
+ PARTICIPLE => 'applying',
+ FILTER => undef,
+ },
+ 'stash-apply-index' => {
+ DIFF => 'diff-index -R -p --cached',
+ APPLY => sub {
+ apply_patch 'apply --cached', $patch_mode_revision, @_;
+ },
+ APPLY_CHECK => 'apply --cached',
+ VERB => 'Apply',
+ TARGET => ' to index',
+ PARTICIPLE => 'applying',
+ FILTER => undef,
+ },
'reset_head' => {
DIFF => 'diff-index -p --cached',
APPLY => sub { apply_patch 'apply -R --cached', @_; },
@@ -1507,6 +1529,12 @@ sub process_args {
'checkout_head' : 'checkout_nothead');
$arg = shift @ARGV or die "missing --";
}
+ } elsif ($1 eq 'stash-apply-tree'
+ || $1 eq 'stash-apply-index') {
+ $patch_mode = $1;
+ $arg = shift @ARGV or die "missing --";
+ $patch_mode_revision = $arg;
+ $arg = shift @ARGV or die "missing --";
} elsif ($1 eq 'stage' or $1 eq 'stash') {
$patch_mode = $1;
$arg = shift @ARGV or die "missing --";
diff --git a/git-stash.sh b/git-stash.sh
index 9efc46d..8090bbf 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -214,8 +214,19 @@ show_stash () {
git diff $flags $b_commit $w_commit
}
+munge_tree_interactive () {
+ (
+ GIT_INDEX_FILE="$TMP-index"
+ export GIT_INDEX_FILE
+ git read-tree --reset "$2" &&
+ git add--interactive --patch=stash-apply-$1 "$3" -- >&3 &&
+ git write-tree
+ )
+}
+
apply_stash () {
unstash_index=
+ patch_mode=
while test $# != 0
do
@@ -226,6 +237,9 @@ apply_stash () {
-q|--quiet)
GIT_QUIET=t
;;
+ -p|--patch)
+ patch_mode=t
+ ;;
*)
break
;;
@@ -258,12 +272,21 @@ apply_stash () {
if test -n "$unstash_index" && test "$b_tree" != "$i_tree" &&
test "$c_tree" != "$i_tree"
then
- git diff-tree --binary $s^2^..$s^2 | git apply --cached
- test $? -ne 0 &&
- die 'Conflicts in index. Try without --index.'
- unstashed_index_tree=$(git write-tree) ||
- die 'Could not save index tree'
- git reset
+ if test -n "$patch_mode"; then
+ i_tree=`munge_tree_interactive index $b_tree $i_tree` 3>&1
+ fi
+ if test "$b_tree" != "$i_tree"; then
+ git diff-tree --binary $b_tree $i_tree | git apply --cached
+ test $? -ne 0 &&
+ die 'Conflicts in index. Try without --index.'
+ unstashed_index_tree=$(git write-tree) ||
+ die 'Could not save index tree'
+ git reset
+ fi
+ fi
+
+ if test -n "$patch_mode"; then
+ w_tree=`munge_tree_interactive tree $b_tree $w_tree` 3>&1
fi
eval "
diff --git a/t/t3905-stash-apply-patch.sh b/t/t3905-stash-apply-patch.sh
new file mode 100755
index 0000000..07cd69b
--- /dev/null
+++ b/t/t3905-stash-apply-patch.sh
@@ -0,0 +1,42 @@
+#!/bin/sh
+
+test_description='git stash apply --patch'
+. ./lib-patch-mode.sh
+
+test_expect_success 'setup' '
+ test_commit one bar bar_head &&
+ test_commit two foo foo_head &&
+ set_state bar bar_work bar_index &&
+ set_state foo foo_work foo_index &&
+ save_head &&
+ git stash
+'
+
+test_expect_success 'saying "n" does nothing' '
+ git reset --hard &&
+ (echo n; echo n) | git stash apply -p &&
+ verify_state bar bar_head bar_head &&
+ verify_state foo foo_head foo_head
+'
+
+# n/y will apply foo but not bar
+test_expect_success 'git stash apply -p' '
+ git reset --hard &&
+ (echo n; echo y) | git stash apply -p &&
+ verify_state bar bar_head bar_head &&
+ verify_state foo foo_work foo_head
+'
+
+# we need two per file, for index and working tree
+test_expect_success 'git stash apply -p --index' '
+ git reset --hard &&
+ (echo n; echo y; sleep 2; echo n; echo y) | git stash apply -p --index &&
+ verify_state bar bar_head bar_head &&
+ verify_state foo foo_work foo_index
+'
+
+test_expect_success 'none of this moved HEAD' '
+ verify_saved_head
+'
+
+test_done
--
1.6.4.304.ge0c3be.dirty
^ permalink raw reply related
* Re: Windows & executable bit
From: Johan 't Hart @ 2009-08-18 16:47 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Erik Faye-Lund, Thomas Rast, Ferry Huberts, msysgit, git
In-Reply-To: <alpine.DEB.1.00.0908181459380.4680@intel-tinevez-2-302>
Johannes Schindelin schreef:
> Hi,
> Bah, you're right. I let myself fool by the lowercase 'm'. Sorry.
Haha. Looking with developer eyes. I know that problem from someone...
Oh yea, me.
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Junio C Hamano @ 2009-08-18 16:43 UTC (permalink / raw)
To: Sebastian Schuberth
Cc: Linus Torvalds, Junio C Hamano, Artur Skawina, Johannes Sixt,
msysGit, Nicolas Pitre, Git Mailing List
In-Reply-To: <bdca99240908180923x49213f30q79cf9424c6aa8202@mail.gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> On Tue, Aug 18, 2009 at 18:08, Linus
> Torvalds<torvalds@linux-foundation.org> wrote:
>
>>> I'd suggest not using a gcc builtin, since if you're using gcc you might
>>> as well just use inline asm that has been around forever (unlike the
>>> builtin).
>>
>> That seems to be what glibc does too.
>>
>> Here's a patch.
>
> Looks good to me, compiles & runs fine on Windows (with Hannes' patch
> also applied).
But the Windows part that avoids arpa/inet.h and includes winsock2.h, only
to undef the two macros immediately after doing so, now looks quite silly.
Are there non i386/amd64 Windows we care about?
Squashing Linus's and Hannes's patch here is what I came up with.
-- >8 --
block-sha1: avoid potentially inefficient ntohl/htonl on i386/x86-64
Johannes Sixt reports that on Windows ntohl()/htonl() are not found in
<arpa/inet.h>, and minimally we need to include <winsock2.h> instead.
Sebastian Schuberth points out that they are implemented as out-of-line
functions on Windows, which defeats the use of these byteorder "macros"
for performance.
Use bswap instruction through gcc inline asm instead on i386/x86-64
as a generic solution to this.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>,
---
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index a1228cf..fa909a3 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -7,8 +7,6 @@
*/
#include <string.h>
-#include <arpa/inet.h>
-
#include "sha1.h"
#if defined(__i386__) || defined(__x86_64__)
@@ -24,8 +22,15 @@
#define SHA_ROL(x,n) SHA_ASM("rol", x, n)
#define SHA_ROR(x,n) SHA_ASM("ror", x, n)
+#undef htonl
+#undef ntohl
+#define htonl(x) ({ unsigned int __res; __asm__("bswap %0":"=r" (__res):"0" (x)); __res; })
+#define ntohl(x) htonl(x)
+
#else
+#include <arpa/inet.h>
+
#define SHA_ROT(X,l,r) (((X) << (l)) | ((X) >> (r)))
#define SHA_ROL(X,n) SHA_ROT(X,n,32-(n))
#define SHA_ROR(X,n) SHA_ROT(X,32-(n),n)
^ permalink raw reply related
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Nicolas Pitre @ 2009-08-18 16:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908181147510.6044@xanadu.home>
On Tue, 18 Aug 2009, Nicolas Pitre wrote:
> Well... Given that git already uses ntohl/htonl quite extensively in
> its core already, I'd suggest making this more globally available
> instead.
What about something like this?
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index 464cb25..51a27c1 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -4,9 +4,7 @@
* and to avoid unnecessary copies into the context array.
*/
-#include <string.h>
-#include <arpa/inet.h>
-
+#include "../git-compat-util.h"
#include "sha1.h"
#if defined(__i386__) || defined(__x86_64__)
diff --git a/compat/bswap.h b/compat/bswap.h
new file mode 100644
index 0000000..b436360
--- /dev/null
+++ b/compat/bswap.h
@@ -0,0 +1,19 @@
+/*
+ * Let's make sure we always have a sane definition for ntohl()/htonl().
+ * Some libraries define those as a function call, just to perform byte
+ * shifting, bringing significant overhead to what should be a sinple
+ * operation.
+ */
+
+#if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))
+
+#define bswap32(x) ({ \
+ unsigned int __res; \
+ __asm__("bswap %0" : "=r" (__res) : "0" (x)); \
+ __res; })
+#undef ntohl
+#undef htonl
+#define ntohl(x) bswap32(x)
+#define htonl(x) bswap32(x)
+
+#endif
diff --git a/git-compat-util.h b/git-compat-util.h
index 9f941e4..000859e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -176,6 +176,8 @@ extern char *gitbasename(char *);
#endif
#endif
+#include "compat/bswap.h"
+
/* General helper functions */
extern void usage(const char *err) NORETURN;
extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
^ permalink raw reply related
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Nicolas Pitre @ 2009-08-18 16:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <7v4os5gs0p.fsf@alter.siamese.dyndns.org>
On Tue, 18 Aug 2009, Junio C Hamano wrote:
> Sebastian Schuberth <sschuberth@gmail.com> writes:
>
> > On Tue, Aug 18, 2009 at 14:56, Artur Skawina<art.08.09@gmail.com> wrote:
> > ...
> >> I'd limit it to windows and any other ia32 platform that doesn't pick the
> >> bswaps itself; as is, it just adds an unnecessary hidden gcc dependency.
> >>
> >> Hmm, it's actually a gcc-4.3+ dependency, so it won't even build w/ gcc 4.2;
> >> something like this would be required: "(__GNUC__>=4 && __GNUC_MINOR__>=3)" .
> >
> > So, as you say the code makes no difference under Linux, would you be
> > OK with just testing for GCC 4.3+, and not for Windows? That would get
> > rid of the "hidden" GCC dependency and not make the preprocessor
> > checks overly complex. Moreover, limiting my patch to any "platform
> > that doesn't pick the bswaps itself" could possibly require
> > maintenance on compiler / CRT updates.
>
> I would say that should be fine, but I'd let Linus and Nico to overrule me
> on this if they have any input.
Well... Given that git already uses ntohl/htonl quite extensively in
its core already, I'd suggest making this more globally available
instead.
Nicolas
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Reece Dunn @ 2009-08-18 16:28 UTC (permalink / raw)
To: Johan 't Hart
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa,
bonzini, kusmabite
In-Reply-To: <4A8AD561.1020303@gmail.com>
2009/8/18 Johan 't Hart <johanthart@gmail.com>:
> Marius Storm-Olsen schreef:
>>
>> From: Marius Storm-Olsen <mstormo@gmail.com>
>>
>> By using GNU Make we can also compile with the MSVC toolchain.
>> This is a rudementary patch, only meant as an RFC for now!!
>>
>
> Would this mean that only the MSVC toolchain is used to build git in batch?
> Or does GNU Make create a .vcproj file like CMake? Because that ofcource is
> the whole purpose of using CMake. One can use the Visual Studio IDE to hack
> on git.
... unless you add a file to the vcproj, or change the project
settings: you'll need to update the CMake file and the Make file (for
the POSIX builds), otherwise you're going to break things.
- Reece
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Sebastian Schuberth @ 2009-08-18 16:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Artur Skawina, Johannes Sixt, msysGit,
Nicolas Pitre, Git Mailing List
In-Reply-To: <alpine.LFD.2.01.0908180906441.3162@localhost.localdomain>
On Tue, Aug 18, 2009 at 18:08, Linus
Torvalds<torvalds@linux-foundation.org> wrote:
>> I'd suggest not using a gcc builtin, since if you're using gcc you might
>> as well just use inline asm that has been around forever (unlike the
>> builtin).
>
> That seems to be what glibc does too.
>
> Here's a patch.
Looks good to me, compiles & runs fine on Windows (with Hannes' patch
also applied).
--
Sebastian Schuberth
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johan 't Hart @ 2009-08-18 16:22 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Johannes.Schindelin, msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <1250600335-8642-1-git-send-email-mstormo@gmail.com>
Marius Storm-Olsen schreef:
> From: Marius Storm-Olsen <mstormo@gmail.com>
>
> By using GNU Make we can also compile with the MSVC toolchain.
> This is a rudementary patch, only meant as an RFC for now!!
>
Would this mean that only the MSVC toolchain is used to build git in
batch? Or does GNU Make create a .vcproj file like CMake? Because that
ofcource is the whole purpose of using CMake. One can use the Visual
Studio IDE to hack on git.
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function
From: Frank Li @ 2009-08-18 16:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marius Storm-Olsen, Reece Dunn, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908181132470.4680@intel-tinevez-2-302>
> Okay, I will wait for Frank's updates (just fetched tgit.git and it still
> contains the old branch), merge the early part and add the compiler flags.
>
Today, I just update 5 patch according review feedback.
Do I need send it again?
I have push my change to tgit
git://repo.or.cz/tgit.git
branch vcpatch2
How do I know if patch has been applied main line?
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Linus Torvalds @ 2009-08-18 16:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Nicolas Pitre, Git Mailing List
In-Reply-To: <alpine.LFD.2.01.0908180836440.3162@localhost.localdomain>
On Tue, 18 Aug 2009, Linus Torvalds wrote:
>
> I'd suggest not using a gcc builtin, since if you're using gcc you might
> as well just use inline asm that has been around forever (unlike the
> builtin).
That seems to be what glibc does too.
Here's a patch.
Linus
---
block-sha1/sha1.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index 464cb25..e6e7170 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -22,6 +22,11 @@
#define SHA_ROL(x,n) SHA_ASM("rol", x, n)
#define SHA_ROR(x,n) SHA_ASM("ror", x, n)
+#undef htonl
+#undef ntohl
+#define htonl(x) ({ unsigned int __res; __asm__("bswap %0":"=r" (__res):"0" (x)); __res; })
+#define ntohl(x) htonl(x)
+
#else
#define SHA_ROT(X,l,r) (((X) << (l)) | ((X) >> (r)))
^ permalink raw reply related
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