* Re: [PATCH 10/11] Add MSVC Project file
From: Johannes Schindelin @ 2009-08-17 22:10 UTC (permalink / raw)
To: Pau Garcia i Quiles
Cc: Reece Dunn, Erik Faye-Lund, Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171423ye08efa8m6666ddb922d5ee92@mail.gmail.com>
Hi,
On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:
> On Mon, Aug 17, 2009 at 11:05 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>
> > You are putting an undue burden on the already overloaded maintainer.
>
> Sorry, but I'm a bit lost now. What maintainer are we talking about now?
> Junio?
I was talking about me, as maintainer of msysGit.
> As I would be providing a turn-key CMake build system, the only burden I
> would be putting on the maintainer would be learning CMake.
>
> Given that I'm providing a comprehensive (100+ slides) CMake tutorial
> ( http://www.elpauer.org/stuff/learning_cmake.pdf ) , which I use in
> my CMake workshops, I think I'm making that burden a bit lighter.
>
> If the next git conference is somewhere in Europe, I could also fly
> there and we'd have a CMake tutorial, if people would feel more
> comfortable that way.
This is exactly what I mean by burden. Why do I have to learn a new
system, and suffer the hassle of integrating it into the current build
system, which works quite well thankyouverymuch?
Never run a changing system.
> > Well, let's see if you can provide a /src/cmake/release.sh that
> > compiles CMake from scratch, and _then_ I'll look into CMake again.
>
> Again, I'm a bit lost. What '/src/cmake/release.sh' are we talking about
> now? Would that be part of CMake or git ?
Maybe this:
http://article.gmane.org/gmane.comp.version-control.git/126286
and this:
http://repo.or.cz/w/msysgit.git?a=blob;f=src/curl/release.sh;h=d7516cbf6e92af4de138ce405d88561fbe1e92a8;hb=968336eddac1874c56cd934d10783566af5a3e26
helps.
To quote myself (as you appear to have missed that):
Having said that, a CMake-based system _in addition_ to what is
tried-and-tested to be able to support all those different kinds of
Microsoft Visual Studio (took me 3 attempts to write that without a
Freudian) would be welcome, _if_ you succeed in making it compile out
of the box on msysGit.
By out-of-the-box I mean: you send a patch that adds
/src/cmake/release.sh, I apply the patch (after briefly scanning
that it does not install a backdoor on a machine that is not even
mine, and therefore will never see even a single of my passwords
typed in), run it, it compiles installs and commits cmake and cmake
works.
Short form: if you make it easy for me, I will look at it again, if you
make it hard on me, you will just have done to me what you now try
to avoid yourself: wasted time.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH v3 8/8] --sparse for porcelains
From: Johannes Schindelin @ 2009-08-17 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vws52uvxq.fsf@alter.siamese.dyndns.org>
Hi,
On Mon, 17 Aug 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > However, my illustration of the scenario was only to one end, namely
> > to convince all of you that assume-changed != sparse.
> >
> > And maybe to the end to explain that sparse checkout could help this
> > guy.
>
> How? If sparse is _not to check it out_, then that is not what the
> person is doing either. It feels to me that you are suggesting an
> inappropriate hack to replace another inappropriate hack, suggesting to
> use a hacksaw because an earlier attempt to use a hammer did not quite
> work to drive the screw in.
Not exactly.
What does "sparse checkout" mean, really? It means that Git should only
check out a part of the tracked files, and not even so much as look
outside. It means to me that everything outside of that focus is clearly
to be handled as all the other untracked data.
And here comes the problem: if something is treated untracked because it
was outside of the sparse checkout, then I want it to be treated as
untracked _even if_ I happened to broaden the checkout by editing
.git/info/sparse. The file did not just magically become subject to
overwriting just because I edited .git/info/sparse (which could be a
simple mistake). So the index _needs_ to know that the sparse'd-out
attribute is something completely different from the assume-unchanged
attribute, even if Git should _handle_ the files with those attributes
pretty similar _most_ of the time.
> I never said assume-unchanged _is_ sparse. You cannot mark an index
> entry that does not exist, obviously you need more (either the earlier
> "hook that tells what should/shouldn't exist", or "the pattern").
Right.
> But I think the work-tree semantics you need to _implement_ sparse
> matches what you would want from assume-unchanged. Not the original,
> draconian one that updates the work tree by saying "you promised me you
> wouldn't change them", but the updated one that tells git to pretend
> that the local change is not there but still keep the local
> modification, including deletion. The work-tree "local changes" sparse
> makes is a small subset of possible local changes assume-unchanged would
> need to support. It only deletes work tree files.
As I tried to convince you already, it is not wise to mix up the two
meanings. They _are_ different: in one case, we _have_ a file, and we
even _expect_ the file to actually have the same contents as what is
recorded in the index. In the other case, we do _not_ have a file, so we
do _not_ even expect the file to have the same contents.
In fact, in the latter case (the sparse case) we do not want to look for
the file; not for the reason that we expect the contents to be the same
anyway, but because we expect it not even to be there!
So while the _technical_ side is pretty much the same (most of the time, I
illustrated a corner case, it it is very easy to think of other corner
cases that might even be inadvertent, all the more reason to protect the
user) -- don't look for the file -- the _semantics_ are _very_ different.
And you see that they are different when all of a sudden you cannot take
the _absence_ of the file as the indicator for "assume-unchanged" and
"sparse".
In fact, with the semantics implied by the label 'assume-unchanged', it
could well be argued that making the file _absent_ (for the sparse
checkout) is a dirty trick. This is not what "assume that the file is
unchanged" implies at all.
So let's just keep the semantics utterly simple and stupid, and have an
- assumed-unchanged bit, which assumes that a file is there, but that the
contents need not to be checked for performance reasons, and
- a no-checkout bit, which assumes that the user never checked out that
file (if it exists, it comes from somewhere else, and needs to be
protected like untracked files that would be overwritten by a branch
switch).
I hope this explanation was clear.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH v3 8/8] --sparse for porcelains
From: Johannes Schindelin @ 2009-08-17 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vvdkmwfqs.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5107 bytes --]
Hi,
On Mon, 17 Aug 2009, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Local changes in git do not belong to any particular branch. They
> > belong to the work tree and the index. Hence you (1) can switch from
> > branch A to branch B iff the branches do not have difference in the
> > path with local changes, and (2) have to stash save, switch branches
> > and then stash pop if you have local changes to paths that are
> > different between branches you are switching between.
> >
> > How should assume-unchanged play with this philosophy?
> >
> > I'd say that assume-unchanged is a promise you make git that you won't
> > change these paths, and in return to the promise git will give you
> > faster response by not running lstat on them. Having changes in such
> > paths is your problem and you deserve these chanegs to be lost. At
> > least, that is the interpretation according to the original
> > assume-unchanged semantics.
>
> Having said that, we could (re)define assume-unchanged to mean "I may or
> may not have changes to these paths, but I do not mean to commit them, so
> do not show them as modified when I ask you for diff. But the changes are
> precious nevertheless"
I am hesitant. The feature was introduced because of some report that Git
was too slow. While the speed has increased dramatically (the report was
for Windows), we cannot work miracles: the file system layer is just not
cooperative.
So I could imagine that redefining the meaning of assume-unchanged results
in a substantially longer runtime again, which some people (yours truly)
might interpret as regression.
> I think the writeout codepath pays attention to assume-unchanged bit
> already for that reason (CE_MATCH_IGNORE_VALID is all about this issue).
If I were that reporter, I would not be happy, I guess. Basically, when
new files come in and I marked all the files as "assume unchanged; I know
what I'm doing!" Git would tell me "no you're an idiot, dummy, I know
better, and I will check all over again!".
> So with that, how should assume-unchanged play with the "local changes
> belong to the index and the work tree"?
>
> - When adding to the index, the changes should be ignored;
>
> - When checking out of the index? I.e. the user tells "git checkout
> path" when path is marked as assume-unchanged. Such an explicit
> request should probably lose the local changes in the work tree.
>
> - When checking out of a commit? The same deal.
>
> - When switching branches?
>
> - If the branches do not touch assume-unchanged paths, we should keep
> changes _and_ assume-unchanged bit. I do not know if that is what
> the current code does.
>
> - If the branches do touch assume-unchanged paths, what should happen?
> We shouldn't blindly overwrite the local changes, so at least we
> should change the code to error out if we do not already do so. But
> then what? How does the user deal with this? Perhaps...
>
> - Drop assume-unchanged temporarily;
> - Stash save;
> - Switch;
> - Stash pop;
> - Add assume-unchanged again.
>
> ???
In my book all this is overly complicated. If I tell Git to assume a file
is unchanged, it is not Git's business to question me.
> Is such an updated (or "corrected") assume-unchanged any different from a
> sparse checkout? After all, paths that are not to be checked out in a
> sparse checkout are "pretend that the lack of these paths are illusion--they
> are logically there. I do not intend to commit their removal, and I do not
> want to lose the sparseness across branch switch".
>
> There is one nit about this. If a path is outside the checkout area,
> should it unconditionally stay outside the checkout area when you switch
> branches? I may be interested in not checking out Documentation/
> subdirectory and that may hold true for all _my_ branches, and it is a
> sane thing not to complain "Oops, you actually removed Makefile in
> Documentation/ in your work tree in reality, and you are switching to
> another branch that has a different Makefile --- it is a delete-modify
> conflict you need to resolve, and we won't let you switch branches" in
> such a case.
>
> But is that generally true in all "sparse checkout" settings?
>
> It is unfortunate that this message raises more questions than it answers,
> but I think a sparse checkout will have to answer them, whether it uses a
> bit separate from assume-unchanged or it reuses the assume-unchanged bit.
I think you will come around and agree that the original, very simple
therefore powerful, concept of "assume-unchanged" should be, well,
unchanged, and not be bent to half-fit the original intention and half-fit
the sparse intention.
Rather, I agree with Nguyễn that the no-checkout bit (which is definitely
free to behave differently from assume-unchanged) is needed.
Maybe I contradict myself here with what I said after the third iteration
of the sparse checkout series, but that only proves that I am able to
learn.
Ciao,
Dscho
^ permalink raw reply
* Re: Linus' sha1 is much faster!
From: Steven Noonan @ 2009-08-17 21:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: Giuseppe Scrivano, Pádraig Brady, Bug-coreutils,
Git Mailing List
In-Reply-To: <alpine.LFD.2.01.0908170852320.3162@localhost.localdomain>
On Mon, Aug 17, 2009 at 9:22 AM, Linus
Torvalds<torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 17 Aug 2009, Steven Noonan wrote:
>>
>> Interesting. I compared Linus' implementation to the public domain one
>> by Steve Reid[1]
>
> You _really_ need to talk about what kind of environment you have.
>
> There are three major issues:
> - Netburst vs non-netburst
> - 32-bit vs 64-bit
> - compiler version
Right. I'm running a Core 2 "Merom" 2.33GHz. The code was compiled for
x86_64 with GCC 4.2.1. I didn't _expect_ it to compile for x86_64, but
apparently the version of GCC that ships with Xcode 3.2 defaults to
compiling 64-bit code on machines that are capable of running it.
>
> Steve Reid's code looks great, but the way it is coded, gcc makes a mess
> of it, which is exactly what my SHA1 tries to avoid.
>
> [ In contrast, gcc does very well on just about _any_ straightforward
> unrolled SHA1 C code if the target architecture is something like PPC or
> ia64 that has enough registers to keep it all in registers.
>
> I haven't really tested other compilers - a less aggressive compiler
> would actually do _better_ on SHA1, because the problem with gcc is that
> it turns the whole temporary 16-entry word array into register accesses,
> and tries to do register allocation on that _array_.
>
> That is wonderful for the above-mentioned PPC and IA64, but it makes gcc
> create totally crazy code when there aren't enough registers, and then
> gcc starts spilling randomly (ie it starts spilling a-e etc). This is
> why the compiler and version matters so much. ]
>
>> (average of 5 runs)
>> Linus' sha1: 283MB/s
>> Steve Reid's sha1: 305MB/s
>
> So I get very different results:
>
> # TIME[s] SPEED[MB/s]
> Reid 2.742 222.6
> linus 1.464 417
Added -m32:
Steve Reid: 156MB/s
Linus: 209MB/s
So on x86, your code really kicks butt.
> this is Intel Nehalem, but compiled for 32-bit mode (which is the more
> challenging one because x86-32 only has 7 general-purpose registers), and
> with gcc-4.4.0.
>
> Linus
>
^ permalink raw reply
* Re: [PATCH] GIT_SSH does not override ssh in git-svn
From: Junio C Hamano @ 2009-08-17 21:40 UTC (permalink / raw)
To: Karthik R; +Cc: git
In-Reply-To: <4A89C6F8.3010100@fastmail.fm>
Karthik R <karthikr@fastmail.fm> writes:
> +my $git_ssh_user_set = 1 if defined $ENV{GIT_SSH};
> +if ($git_ssh_user_set) {
> + # If GIT_SSH is set, also set SVN_SSH...
> + $ENV{SVN_SSH} = $ENV{GIT_SSH};
> + # ... and escape \s in shell-variable on Windows
> + if ($^O eq 'MSWin32' || $^O eq 'msys') {
> + $ENV{SVN_SSH} =~ s/\\/\\\\/g;
> + }
> +}
> +
Why not just
if (defined $ENV{GIT_SSH}) {
...
???
> $Git::SVN::Log::TZ = $ENV{TZ};
> $ENV{TZ} = 'UTC';
> $| = 1; # unbuffer STDOUT
> --
> 1.5.4.3
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function
From: Junio C Hamano @ 2009-08-17 21:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172258580.8306@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Of course, msysGit was not there yet to allow me to compile my tree (and
> more importantly, pass the test suite), so I did not realize the
> violations in compat/.
>
> Hence my intention to set the compiler flags just after merging the early
> commits of Frank's work.
Sounds very sensible.
^ permalink raw reply
* Re: [PATCH] GIT_SSH does not override ssh in git-svn
From: Johannes Schindelin @ 2009-08-17 21:38 UTC (permalink / raw)
To: Karthik R; +Cc: git
In-Reply-To: <4A89C6F8.3010100@fastmail.fm>
Hi,
On Mon, 17 Aug 2009, Karthik R wrote:
>
>
> Signed-off-by: Karthik R <karthikr@fastmail.fm>
> ---
>
> Setting GIT_SSH when using "git svn clone svn+ssh://..." does not override the
> default ssh; SVN_SSH needs to be set instead. Corrected this.
>
> Also, on Windows, SVN_SSH needs to be set with \ escaped
> e.g., "C:\\PuTTY\\plink.exe"
>
> See http://code.google.com/p/msysgit/issues/detail?id=305
This probably all wants to go into the commit message: it is very useful
information!
Besides, I think you would like to formulate the commit subject more
positive: "Respect GIT_SSH in git-svn" or some such. After all, you fix
the issue. IOW use the imperative: you command git-svn to behave ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Git User's Survey 2009 partial summary, part 2 - from first 10
From: Jakub Narebski @ 2009-08-17 21:39 UTC (permalink / raw)
To: Johan Herland; +Cc: git, msysgit
In-Reply-To: <200908171244.21693.johan@herland.net>
On Mon, 17 Aug 2009, Johan Herland wrote:
> On Monday 17 August 2009, Jakub Narebski wrote:
> > 9) On which operating system(s) do you use Git?
> > (Choice - Multiple answers)
> >
> > On Unix-based operating system you can get the name of operation
> > system by running 'uname'.
>
> I find it interesting to compare the answers to this question against
> previous years' surveys:
>
> =============================================================
> Operating system | 2009 [%] | 2008 [%] | 2007 [%]
> -------------------------------------------------------------
> Linux | 88% | 86% | 90%
> MacOS X (Darwin) | 44% | 47% | 15%
> MS Windows/Cygwin | 9% | 10% | >3%?
> MS Windows/msysGit (MINGW) | 21% | 16% | >0%?
> ............................|..........|..........|..........
> MS Windows (any) | 27% | <26%?| 9%
Whet might be also interesting is to have (also) bare numbers of
responses. Percentage alone wouldn't tell full story. If you have
(for example) 1000 Linux users, and there gets released native MacOS X
binary installer, and here comes 500 MacOS X users, the percentage
would decrease, because there are now more users, some of which are
not Linux users.
=================================================
Operating system | 2009 | 2008 | 2007#
-------------------------------------------------
Linux | 2623 | 2434 | 582
MacOS X (Darwin) | 1304 | 1330 | 94
MS Windows/Cygwin | 279 | 297 | 22
MS Windows/msysGit (MINGW) | 625 | 452 | 1
............................|......|......|......
MS Windows (any) | 820 | 749?| 58*
----------------------------+------+------+------
Answers | 2991 | 2842 | 645
=================================================
Footnotes:
[#] First download on current msysGit page is from Aug 2007
[*] Including unspecified version of Git for MS Windows.
[?] "Other, please specify" not included. It also doesn't
take into account overlap (one might use both msysGit and Cygwin
version, e.g. on different computers)
--
Jakub Narebski
Git User's Survey 2009: http://tinyurl.com/GitSurvey2009
^ permalink raw reply
* Re: CMake, was Re: [PATCH 09/11] Add MSVC porting header files.
From: Pau Garcia i Quiles @ 2009-08-17 21:29 UTC (permalink / raw)
To: Reece Dunn; +Cc: Johannes Schindelin, Frank Li, git, msysgit
In-Reply-To: <3f4fd2640908171420j2a359e99ga3d6fc3109547af6@mail.gmail.com>
On Mon, Aug 17, 2009 at 11:20 PM, Reece Dunn<msclrhd@googlemail.com> wrote:
> Realistically, you'd need CMake for Windows/msvc and autotools for
> POSIX systems. I know that CMake is supported on POSIX, but not
> everyone has access to it. Poppler, for example, has this dual build
> system to support Windows as well as other systems (that, and it has
> KDE4 bindings, so CMake is pretty much a given).
It's not exactly like that. It would be more accurate to say "if you
have POSIX, CMake will work; if you don't have POSIX, it may or may
not work".
I'd say 99% of git users run git on a platform which supports enough
POSIX to build CMake.
Please note if you are cross-compiling git, you need CMake (hence
POSIX) on the platform you are cross-compiling on (the "host
platform"), not on the platform you are cross-compiling for (the
"target platform").
> For CMake to work, it would need to support building all of git
> (including the man, html and pdf documents from the asciidoc sources),
> the localisation support and the optional packages (OpenSSL, CURL). I
> know that KDE uses CMake, so this should all be possible.
All possible. Plus using CMake would make easier to build installers
(NSIS, WiX, .deb, .rpm, etc), submit the results of the tests to a
dashboard ( http://my.cdash.org/ ), and more.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: [PATCH 10/11] Add MSVC Project file
From: Pau Garcia i Quiles @ 2009-08-17 21:23 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Reece Dunn, Erik Faye-Lund, Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172304200.8306@pacific.mpi-cbg.de>
On Mon, Aug 17, 2009 at 11:05 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:
>
>> On Mon, Aug 17, 2009 at 10:43 PM, Reece Dunn<msclrhd@googlemail.com> wrote:
>> > 2009/8/17 Pau Garcia i Quiles <pgquiles@elpauer.org>:
>> >> On Mon, Aug 17, 2009 at 9:53 PM, Johannes
>> >> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>> >>
>> >>> Of course, we could have a script that verifies that the .vcproj
>> >>> files contain reference the appropriate files (which it would know
>> >>> about by being called from the Makefile and being passed the file
>> >>> names), maybe even be able to edit the .vcproj file if it is missing
>> >>> some. Should not be too hard in Perl.
>> >>
>> >> You'll need to special-case for Visual C++ 2010, which is different
>> >> and incompatible with previous versions. Hence my suggestion for
>> >> CMake: appropriate project files would be generated for the tool the
>> >> user chooses, be it VC++ 2005, VC++2010, gcc, Borland C++ or anything
>> >> else.
>> >
>> > The problem is that you'd still need the Visual Studio projects (one
>> > each for 6, 7 (2002), 7.1 (2003), 8 (2005), 9 (2008) and 10 (2010) --
>> > yes, there'll need to be one for each version of Visual Studio) as
>> > people who use Visual Studio tend to primarily use the IDE. CMake
>> > (which Windows users will need to download & install from somewhere)
>> > will sit outside this -- unless you mean making the project files be
>> > the "Makefile project" type and simply use it to invoke CMake and host
>> > the source files to ease access to them from the IDE?
>>
>> If a CMake build system is provided, you will not need a single Visual
>> Studio project, or the autotools build system, or anything else. Just
>> CMake and the CMake build system (which are a bunch of CMakeLists.txt
>> plain text files).
>
> You are putting an undue burden on the already overloaded maintainer.
Sorry, but I'm a bit lost now. What maintainer are we talking about now? Junio?
As I would be providing a turn-key CMake build system, the only burden
I would be putting on the maintainer would be learning CMake.
Given that I'm providing a comprehensive (100+ slides) CMake tutorial
( http://www.elpauer.org/stuff/learning_cmake.pdf ) , which I use in
my CMake workshops, I think I'm making that burden a bit lighter.
If the next git conference is somewhere in Europe, I could also fly
there and we'd have a CMake tutorial, if people would feel more
comfortable that way.
> Well, let's see if you can provide a /src/cmake/release.sh that compiles
> CMake from scratch, and _then_ I'll look into CMake again.
Again, I'm a bit lost. What '/src/cmake/release.sh' are we talking
about now? Would that be part of CMake or git ?
If you want to build CMake from scratch, you only need to download the
source from http://cmake.org/cmake/resources/software.html , then run
"./bootstrap" in the source directory. That's true for every platform
but Visual C++, which requires you to download a pre-built CMake
binary to build CMake.
If you mean you want to bootstrap git (i. e. download the git tarball,
which would include the CMake sources, then bootstrap CMake, then
build git using the CMake build system), I'd say that makes no sense
at all. That would be like saying you want to include the autotools
sources, the OpenSSL sources, the curl sources, the Subversion
sources, etc in the git tarball. Insane.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: CMake, was Re: [PATCH 09/11] Add MSVC porting header files.
From: Reece Dunn @ 2009-08-17 21:20 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Johannes Schindelin, Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171251y355a1e2bjf2d10192bc3eca2e@mail.gmail.com>
2009/8/17 Pau Garcia i Quiles <pgquiles@elpauer.org>:
> On Mon, Aug 17, 2009 at 9:48 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>
>> On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:
>>
>>> What about having a CMake build system, which would work on every
>>> platform (including cross-compiling), and would produce an appropriate
>>> config.h and makefiles/vcproj/Eclipse projects/XCode projects/whatever
>>> is fit for each platform? If it's OK to include such a build system
>>> upstream, I'm volunteering to implement it.
>>
>> And reap in another dependency?
>>
>> First Python, then CMake, what tomorrow? Is it the month of adding
>> dependencies?
>
> I'd say it's the month of getting problems solved.
>
> CMake would make git a lot easier to build on Windows, particularly
> with Visual C++. Replace autotools with CMake and suddenly you need to
> maintain a single build system for every platform and compiler git
> supports/will support. That's a sound advantage to me.
Realistically, you'd need CMake for Windows/msvc and autotools for
POSIX systems. I know that CMake is supported on POSIX, but not
everyone has access to it. Poppler, for example, has this dual build
system to support Windows as well as other systems (that, and it has
KDE4 bindings, so CMake is pretty much a given).
For CMake to work, it would need to support building all of git
(including the man, html and pdf documents from the asciidoc sources),
the localisation support and the optional packages (OpenSSL, CURL). I
know that KDE uses CMake, so this should all be possible.
- Reece
^ permalink raw reply
* Re: [PATCH 10/11] Add MSVC Project file
From: Reece Dunn @ 2009-08-17 21:05 UTC (permalink / raw)
To: Pau Garcia i Quiles
Cc: Johannes Schindelin, Erik Faye-Lund, Paolo Bonzini, Frank Li, git,
msysgit
In-Reply-To: <3af572ac0908171354i6dd231etb576859ab8941214@mail.gmail.com>
2009/8/17 Pau Garcia i Quiles <pgquiles@elpauer.org>:
> On Mon, Aug 17, 2009 at 10:43 PM, Reece Dunn<msclrhd@googlemail.com> wrote:
>> 2009/8/17 Pau Garcia i Quiles <pgquiles@elpauer.org>:
>>> On Mon, Aug 17, 2009 at 9:53 PM, Johannes
>>> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>>>
>>>> Of course, we could have a script that verifies that the .vcproj files
>>>> contain reference the appropriate files (which it would know about by
>>>> being called from the Makefile and being passed the file names), maybe
>>>> even be able to edit the .vcproj file if it is missing some. Should not
>>>> be too hard in Perl.
>>>
>>> You'll need to special-case for Visual C++ 2010, which is different
>>> and incompatible with previous versions. Hence my suggestion for
>>> CMake: appropriate project files would be generated for the tool the
>>> user chooses, be it VC++ 2005, VC++2010, gcc, Borland C++ or anything
>>> else.
>>
>> The problem is that you'd still need the Visual Studio projects (one
>> each for 6, 7 (2002), 7.1 (2003), 8 (2005), 9 (2008) and 10 (2010) --
>> yes, there'll need to be one for each version of Visual Studio) as
>> people who use Visual Studio tend to primarily use the IDE. CMake
>> (which Windows users will need to download & install from somewhere)
>> will sit outside this -- unless you mean making the project files be
>> the "Makefile project" type and simply use it to invoke CMake and host
>> the source files to ease access to them from the IDE?
>
> If a CMake build system is provided, you will not need a single Visual
> Studio project, or the autotools build system, or anything else. Just
> CMake and the CMake build system (which are a bunch of CMakeLists.txt
> plain text files).
Note that I said that people who use Visual Studio are more likely to
build and develop things through the Visual Studio IDE. Unless there
is IDE integration for it, they are not likely to use it.
For an automated build, CMake would probably work.
Looking around, it seems that CMake on Windows assumes that Microsoft
Visual C is used; that is, you have to explicitly specify CC for MinGW
or cygwin to build.
> CMake takes the CMakeLists.txt file(s) as the input and generates
> makefiles for gcc, vcproj files for Visual C++, makefiles for NMake,
> Eclipse projects for Eclipse, XCode projects for XCode, etc.
>
>> Also, not every posix system will have CMake installed (e.g. Linux
>> From Scratch systems) and that's not including "exotic" systems like
>> Solaris and the *BSDs.
>
> CMake is available for many platforms (Linux x86-32 and x86-64, PPC,
> Solaris Sparc, HP-UX, Irix, AIX PPC) as a binary from the CMake site (
> http://cmake.org/cmake/resources/software.html ) and as source for the
> rest.
>
> *BSD? It is available in the ports section (and maybe as a binary,
> too) in FreeBSD(
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/cmake/ ), NetBSD and
> OpenBSD.
Ok, I stand corrected there.
> Linux from scratch? If people are brave enough to build and use LFS,
> they are brave enough to build CMake (CMake is autocontained and
> bootstraps itself, it only depends on a C++ compiler to build itself).
At what about at the bootstrap stage? A C compiler will be available,
but a C++ one may not.
- Reece
^ permalink raw reply
* Re: [PATCH 10/11] Add MSVC Project file
From: Johannes Schindelin @ 2009-08-17 21:11 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Erik Faye-Lund, Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171359o33f6ca70n599bdc27be74784a@mail.gmail.com>
Hi,
On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:
> On Mon, Aug 17, 2009 at 10:56 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>
> > The problem is that this will bitrot even more, as nobody will use it
> > for gcc, Borland C++, XCode, Eclipse or anything else, except for
> > Microsoft Visual C++.
>
> How do you know? Also, please note I'm not talking about *adding* a
> CMake build system, I'm talking about *replacing* the existing autotools
> build system with a CMake build system, even if they coexist for some
> time.
You are mistaken. We do not require using the autotools. I _never_ call
"./configure" yet the Makefile magically works. Cool, huh?
But here's a clue: you will probably _never_ succeed in getting a
replacement of the make-based build in git.git by the maintainer. Make is
just too ubiquitous and well-established for that.
Having said that, a CMake-based system _in addition_ to what is
tried-and-tested to be able to support all those different kinds of
Microsoft Visual Studio (took me 3 attempts to write that without a
Freudian) would be welcome, _if_ you succeed in making it compile out of
the box on msysGit.
By out-of-the-box I mean: you send a patch that adds
/src/cmake/release.sh, I apply the patch (after briefly scanning that it
does not install a backdoor on a machine that is not even mine, and
therefore will never see even a single of my passwords typed in), run it,
it compiles installs and commits cmake and cmake works.
If that's not possible, I refuse to add another problem rather than
solving one.
If you succeed, I will ask you to do the same for Python, as you clearly
proved by that point that you are a magician.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] GIT_SSH does not override ssh in git-svn
From: Karthik R @ 2009-08-17 21:09 UTC (permalink / raw)
To: git
Signed-off-by: Karthik R <karthikr@fastmail.fm>
---
Setting GIT_SSH when using "git svn clone svn+ssh://..." does not
override the
default ssh; SVN_SSH needs to be set instead. Corrected this.
Also, on Windows, SVN_SSH needs to be set with \ escaped
e.g., "C:\\PuTTY\\plink.exe"
See http://code.google.com/p/msysgit/issues/detail?id=305
git-svn.perl | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index b0bfb74..c932b6e 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -21,6 +21,16 @@ $Git::SVN::default_ref_id = $ENV{GIT_SVN_ID} ||
'git-svn';
$Git::SVN::Ra::_log_window_size = 100;
$Git::SVN::_minimize_url = 'unset';
+my $git_ssh_user_set = 1 if defined $ENV{GIT_SSH};
+if ($git_ssh_user_set) {
+ # If GIT_SSH is set, also set SVN_SSH...
+ $ENV{SVN_SSH} = $ENV{GIT_SSH};
+ # ... and escape \s in shell-variable on Windows
+ if ($^O eq 'MSWin32' || $^O eq 'msys') {
+ $ENV{SVN_SSH} =~ s/\\/\\\\/g;
+ }
+}
+
$Git::SVN::Log::TZ = $ENV{TZ};
$ENV{TZ} = 'UTC';
$| = 1; # unbuffer STDOUT
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH 10/11] Add MSVC Project file
From: Johannes Schindelin @ 2009-08-17 21:05 UTC (permalink / raw)
To: Pau Garcia i Quiles
Cc: Reece Dunn, Erik Faye-Lund, Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171354i6dd231etb576859ab8941214@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1985 bytes --]
Hi,
On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:
> On Mon, Aug 17, 2009 at 10:43 PM, Reece Dunn<msclrhd@googlemail.com> wrote:
> > 2009/8/17 Pau Garcia i Quiles <pgquiles@elpauer.org>:
> >> On Mon, Aug 17, 2009 at 9:53 PM, Johannes
> >> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> >>
> >>> Of course, we could have a script that verifies that the .vcproj
> >>> files contain reference the appropriate files (which it would know
> >>> about by being called from the Makefile and being passed the file
> >>> names), maybe even be able to edit the .vcproj file if it is missing
> >>> some. Should not be too hard in Perl.
> >>
> >> You'll need to special-case for Visual C++ 2010, which is different
> >> and incompatible with previous versions. Hence my suggestion for
> >> CMake: appropriate project files would be generated for the tool the
> >> user chooses, be it VC++ 2005, VC++2010, gcc, Borland C++ or anything
> >> else.
> >
> > The problem is that you'd still need the Visual Studio projects (one
> > each for 6, 7 (2002), 7.1 (2003), 8 (2005), 9 (2008) and 10 (2010) --
> > yes, there'll need to be one for each version of Visual Studio) as
> > people who use Visual Studio tend to primarily use the IDE. CMake
> > (which Windows users will need to download & install from somewhere)
> > will sit outside this -- unless you mean making the project files be
> > the "Makefile project" type and simply use it to invoke CMake and host
> > the source files to ease access to them from the IDE?
>
> If a CMake build system is provided, you will not need a single Visual
> Studio project, or the autotools build system, or anything else. Just
> CMake and the CMake build system (which are a bunch of CMakeLists.txt
> plain text files).
You are putting an undue burden on the already overloaded maintainer.
Well, let's see if you can provide a /src/cmake/release.sh that compiles
CMake from scratch, and _then_ I'll look into CMake again.
Ciao,
Dscho
^ permalink raw reply
* Re: CMake, was Re: [PATCH 09/11] Add MSVC porting header files.
From: Pau Garcia i Quiles @ 2009-08-17 21:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172256560.8306@pacific.mpi-cbg.de>
> In any case, before you get CMake to compile in msysGit, I think we do not
> need to talk about getting problems solved.
At this moment I feel like developing a CMake build system for git
would be a waste of time, it would never be accepted upstream. I'm not
sure I want to spend my time in such an effort (it would easily take
2-3 days full time) and see it trashed. Sorry for being so clear, but
I tend to contribute only to projects where my help and time are
appreciated.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function
From: Johannes Schindelin @ 2009-08-17 21:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Frank Li, git, msysgit
In-Reply-To: <7v1vnauto6.fsf@alter.siamese.dyndns.org>
Hi,
On Mon, 17 Aug 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > How about this instead?
> >
> > Avoid declaration after instruction
>
> It's called declaration-after-statement.
Of course. Thank you.
> I always compile with "-Wall -Wdeclaration-after-statement -Werror"
> (among other things; if you are interested, see "Make" script in 'todo'
> branch for details) but this being in compat/mingw.c, obviously it is
> outside of my coverage.
I have this in my own tree since long ago, back when you sent a mail whose
reference I did not record, unfortunately.
Of course, msysGit was not there yet to allow me to compile my tree (and
more importantly, pass the test suite), so I did not realize the
violations in compat/.
Hence my intention to set the compiler flags just after merging the early
commits of Frank's work.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 10/11] Add MSVC Project file
From: Pau Garcia i Quiles @ 2009-08-17 20:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Erik Faye-Lund, Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172255140.8306@pacific.mpi-cbg.de>
On Mon, Aug 17, 2009 at 10:56 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:
>
>> On Mon, Aug 17, 2009 at 9:53 PM, Johannes
>> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>>
>> > Of course, we could have a script that verifies that the .vcproj files
>> > contain reference the appropriate files (which it would know about by
>> > being called from the Makefile and being passed the file names), maybe
>> > even be able to edit the .vcproj file if it is missing some. Should
>> > not be too hard in Perl.
>>
>> You'll need to special-case for Visual C++ 2010, which is different
>> and incompatible with previous versions.
>
> Ah, my beloved Microsoft time tax!
Sorry, but I make a living developing cross-platform software and
porting stuff among any funny combination of Linux, Windows, gcc,
mingw, Intel C++ and Visual C++ you can think of. CMake makes my life
easier (possible!). Given that the patches we are talking about happen
to add support for Visual C++, I'd say it stepped in at the right
moment.
>> Hence my suggestion for CMake: appropriate project files would be
>> generated for the tool the user chooses, be it VC++ 2005, VC++2010, gcc,
>> Borland C++ or anything else.
>
> The problem is that this will bitrot even more, as nobody will use it for
> gcc, Borland C++, XCode, Eclipse or anything else, except for Microsoft
> Visual C++.
How do you know? Also, please note I'm not talking about *adding* a
CMake build system, I'm talking about *replacing* the existing
autotools build system with a CMake build system, even if they coexist
for some time.
What would be the point of having two build-systems, one (autotools)
useless for Visual C++, the other one (CMake) apt for every platform ?
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: CMake, was Re: [PATCH 09/11] Add MSVC porting header files.
From: Johannes Schindelin @ 2009-08-17 20:58 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171251y355a1e2bjf2d10192bc3eca2e@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1257 bytes --]
Hi,
On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:
> On Mon, Aug 17, 2009 at 9:48 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>
> > On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:
> >
> >> What about having a CMake build system, which would work on every
> >> platform (including cross-compiling), and would produce an appropriate
> >> config.h and makefiles/vcproj/Eclipse projects/XCode projects/whatever
> >> is fit for each platform? If it's OK to include such a build system
> >> upstream, I'm volunteering to implement it.
> >
> > And reap in another dependency?
> >
> > First Python, then CMake, what tomorrow? Is it the month of adding
> > dependencies?
>
> I'd say it's the month of getting problems solved.
What? I beg your _pardon_?
> CMake would make git a lot easier to build on Windows, particularly with
> Visual C++. Replace autotools with CMake and suddenly you need to
> maintain a single build system for every platform and compiler git
> supports/will support. That's a sound advantage to me.
Well, I heard some pretty different opinions, and they are from quite
recently.
In any case, before you get CMake to compile in msysGit, I think we do not
need to talk about getting problems solved.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 10/11] Add MSVC Project file
From: Johannes Schindelin @ 2009-08-17 20:56 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Erik Faye-Lund, Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171317s3ef1506fpb3df11916f8a6ee9@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 983 bytes --]
Hi,
On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote:
> On Mon, Aug 17, 2009 at 9:53 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>
> > Of course, we could have a script that verifies that the .vcproj files
> > contain reference the appropriate files (which it would know about by
> > being called from the Makefile and being passed the file names), maybe
> > even be able to edit the .vcproj file if it is missing some. Should
> > not be too hard in Perl.
>
> You'll need to special-case for Visual C++ 2010, which is different
> and incompatible with previous versions.
Ah, my beloved Microsoft time tax!
> Hence my suggestion for CMake: appropriate project files would be
> generated for the tool the user chooses, be it VC++ 2005, VC++2010, gcc,
> Borland C++ or anything else.
The problem is that this will bitrot even more, as nobody will use it for
gcc, Borland C++, XCode, Eclipse or anything else, except for Microsoft
Visual C++.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 10/11] Add MSVC Project file
From: Pau Garcia i Quiles @ 2009-08-17 20:54 UTC (permalink / raw)
To: Reece Dunn
Cc: Johannes Schindelin, Erik Faye-Lund, Paolo Bonzini, Frank Li, git,
msysgit
In-Reply-To: <3f4fd2640908171343s6e2796a8le0455e02fd8386d9@mail.gmail.com>
On Mon, Aug 17, 2009 at 10:43 PM, Reece Dunn<msclrhd@googlemail.com> wrote:
> 2009/8/17 Pau Garcia i Quiles <pgquiles@elpauer.org>:
>> On Mon, Aug 17, 2009 at 9:53 PM, Johannes
>> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>>
>>> Of course, we could have a script that verifies that the .vcproj files
>>> contain reference the appropriate files (which it would know about by
>>> being called from the Makefile and being passed the file names), maybe
>>> even be able to edit the .vcproj file if it is missing some. Should not
>>> be too hard in Perl.
>>
>> You'll need to special-case for Visual C++ 2010, which is different
>> and incompatible with previous versions. Hence my suggestion for
>> CMake: appropriate project files would be generated for the tool the
>> user chooses, be it VC++ 2005, VC++2010, gcc, Borland C++ or anything
>> else.
>
> The problem is that you'd still need the Visual Studio projects (one
> each for 6, 7 (2002), 7.1 (2003), 8 (2005), 9 (2008) and 10 (2010) --
> yes, there'll need to be one for each version of Visual Studio) as
> people who use Visual Studio tend to primarily use the IDE. CMake
> (which Windows users will need to download & install from somewhere)
> will sit outside this -- unless you mean making the project files be
> the "Makefile project" type and simply use it to invoke CMake and host
> the source files to ease access to them from the IDE?
If a CMake build system is provided, you will not need a single Visual
Studio project, or the autotools build system, or anything else. Just
CMake and the CMake build system (which are a bunch of CMakeLists.txt
plain text files).
CMake takes the CMakeLists.txt file(s) as the input and generates
makefiles for gcc, vcproj files for Visual C++, makefiles for NMake,
Eclipse projects for Eclipse, XCode projects for XCode, etc.
> Also, not every posix system will have CMake installed (e.g. Linux
> From Scratch systems) and that's not including "exotic" systems like
> Solaris and the *BSDs.
CMake is available for many platforms (Linux x86-32 and x86-64, PPC,
Solaris Sparc, HP-UX, Irix, AIX PPC) as a binary from the CMake site (
http://cmake.org/cmake/resources/software.html ) and as source for the
rest.
*BSD? It is available in the ports section (and maybe as a binary,
too) in FreeBSD(
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/cmake/ ), NetBSD and
OpenBSD.
Linux from scratch? If people are brave enough to build and use LFS,
they are brave enough to build CMake (CMake is autocontained and
bootstraps itself, it only depends on a C++ compiler to build itself).
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: [PATCH 10/11] Add MSVC Project file
From: Johannes Schindelin @ 2009-08-17 20:54 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Erik Faye-Lund, Frank Li, git, msysgit
In-Reply-To: <4A89B772.8060307@gnu.org>
Hi,
On Mon, 17 Aug 2009, Paolo Bonzini wrote:
> > I think the killer argument against such a script (I actually though
> > of that myself, but decided against it for that very reason) is that
> > the result is to be used by Microsoft Visual Studio users, who do not
> > typically have a scripting language, and who would not want to use it
> > anyway.
>
> But the script could run whenever the Makefile is updated, even under
> Unix.
But that would have to be kept in mind by the maintainer, and he could not
test it.
Besides, IIUC you were proposing a generator, while I suggested a
rewriter. My idea would require much less work, as the changes to the
original, known good, .vcproj are minimal.
So let's have a script (if anybody feels compelled enough) that we can run
from time to time and when it updates at least one of the .vcproj file, we
throw the result at Frank Li for testing.
Ciao,
Dscho
^ permalink raw reply
* Re: How-to checkin git hook
From: Joe D'Abbraccio @ 2009-08-17 20:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0908171327l1dd1a36n5e58828d70b18bfe@mail.gmail.com>
Thanks for the info.
How do people typically manage the hooks for their projects? These may
change over the life of the project and may be project version
dependent. Is the best way to place them into another subdir within
your project with instructions on updating the hooks files? Looks like
a step that would be prone to errors though.
And how about the fact that post-checkout.sample is missing in the
release I am using. Is this the only one missing or are there others?
It would also be a good idea if the githooks man page explains this.
Maybe when I better understand how hooks are best managed, I will
provide my thoughts on the man page.
Regards,
Joe
Alex Riesen wrote:
> On Mon, Aug 17, 2009 at 22:15, Joe D'Abbraccio<dajoe13@gmail.com> wrote:
>> I have not been able to find out how to commit and push a hook to my git
>> server archive for everyone's benefit. The githooks man page does not
>> describe this and I have not turned up any fruitful google searches on the
>> topic.
>>
>> I am trying to add a post-checkout hook. I also noticed that the
>> post-checkout sample does not exist when I init a new archive. Is this a
>> bug? I am running git version 1.6.0.2.
>
> No. It didn't occurred to anyone before to push repository's configuration
> and service files (the hooks). Everybody just copied them into the server
> repositories or edited them in place.
>
> If the server is a public place like github, it is not very likely they allow
> you to run anything you like on their servers (and hooks are programs).
>
^ permalink raw reply
* Re: [PATCH 10/11] Add MSVC Project file
From: Reece Dunn @ 2009-08-17 20:43 UTC (permalink / raw)
To: Pau Garcia i Quiles
Cc: Johannes Schindelin, Erik Faye-Lund, Paolo Bonzini, Frank Li, git,
msysgit
In-Reply-To: <3af572ac0908171317s3ef1506fpb3df11916f8a6ee9@mail.gmail.com>
2009/8/17 Pau Garcia i Quiles <pgquiles@elpauer.org>:
> On Mon, Aug 17, 2009 at 9:53 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>
>> Of course, we could have a script that verifies that the .vcproj files
>> contain reference the appropriate files (which it would know about by
>> being called from the Makefile and being passed the file names), maybe
>> even be able to edit the .vcproj file if it is missing some. Should not
>> be too hard in Perl.
>
> You'll need to special-case for Visual C++ 2010, which is different
> and incompatible with previous versions. Hence my suggestion for
> CMake: appropriate project files would be generated for the tool the
> user chooses, be it VC++ 2005, VC++2010, gcc, Borland C++ or anything
> else.
The problem is that you'd still need the Visual Studio projects (one
each for 6, 7 (2002), 7.1 (2003), 8 (2005), 9 (2008) and 10 (2010) --
yes, there'll need to be one for each version of Visual Studio) as
people who use Visual Studio tend to primarily use the IDE. CMake
(which Windows users will need to download & install from somewhere)
will sit outside this -- unless you mean making the project files be
the "Makefile project" type and simply use it to invoke CMake and host
the source files to ease access to them from the IDE?
Also, not every posix system will have CMake installed (e.g. Linux
From Scratch systems) and that's not including "exotic" systems like
Solaris and the *BSDs.
- Reece
^ permalink raw reply
* [PATCH] filter-branch: add an example how to add ACKs to a range of commits
From: Johannes Schindelin @ 2009-08-17 20:38 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <cover.1250541493u.git.johannes.schindelin@gmx.de>
When you have to add certain lines like ACKs (or for that matter,
Signed-off-by:s) to a range of commits starting with HEAD, you might
be tempted to use 'git rebase -i -10', but that is a waste of your
time.
It is better to use 'git filter-branch' with an appropriate message
filter, and this commit adds an example how to do so to
filter-branch's man page.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/git-filter-branch.txt | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index ab527b5..32ea856 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -305,6 +305,16 @@ range in addition to the new branch name. The new branch name will
point to the top-most revision that a 'git-rev-list' of this range
will print.
+If you need to add 'Acked-by' lines to, say, the last 10 commits (none
+of which is a merge), use this command:
+
+--------------------------------------------------------
+git filter-branch --msg-filter '
+ cat &&
+ echo "Acked-by: Bugs Bunny <bunny@bugzilla.org>"
+' HEAD~10..HEAD
+--------------------------------------------------------
+
*NOTE* the changes introduced by the commits, and which are not reverted
by subsequent commits, will still be in the rewritten branch. If you want
to throw out _changes_ together with the commits, you should use the
--
1.6.4.313.g3d9e3
^ 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