* [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
* Re: How-to checkin git hook
From: Alex Riesen @ 2009-08-17 20:27 UTC (permalink / raw)
To: Joe D'Abbraccio; +Cc: git
In-Reply-To: <4A89BA5D.1000608@gmail.com>
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: How-to checkin git hook
From: Erik Faye-Lund @ 2009-08-17 20:26 UTC (permalink / raw)
To: Joe D'Abbraccio; +Cc: git
In-Reply-To: <4A89BA5D.1000608@gmail.com>
On Mon, Aug 17, 2009 at 10:15 PM, Joe D'Abbraccio<dajoe13@gmail.com> wrote:
> 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?
No, it's security. Hooks are executable files and shouldn't blindly be
copied around for security reasons.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH 10/11] Add MSVC Project file
From: Pau Garcia i Quiles @ 2009-08-17 20:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Erik Faye-Lund, Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172149480.8306@pacific.mpi-cbg.de>
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.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* How-to checkin git hook
From: Joe D'Abbraccio @ 2009-08-17 20:15 UTC (permalink / raw)
To: git
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.
Regards,
Joe
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 09/11] Add MSVC porting header files.
From: Johannes Sixt @ 2009-08-17 20:07 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: msysgit, Johannes Schindelin, Frank Li, git
In-Reply-To: <3af572ac0908171231n30864c85ud67454a03ca08fbe@mail.gmail.com>
On Montag, 17. August 2009, Pau Garcia i Quiles wrote:
> What about having a CMake build system, ...
No, thank you. I have to use it for the little bit of KDE development that I
do, and it is a horror. With autotools I at least was able to reuse my shell
programming skills, but cmake is an entirely new language, and an absolutely
horrible one (IMHO, of course).
-- Hannes
^ permalink raw reply
* Re: [PATCH 10/11] Add MSVC Project file
From: Paolo Bonzini @ 2009-08-17 20:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Erik Faye-Lund, Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172149480.8306@pacific.mpi-cbg.de>
> 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. Of course, there are chances of bitrotting, but it cannot be
worse than having failures every time a builtin is added or otherwise a
file is added.
The main problem I see with the script is that the output would
naturally be a .gitignore-d file, but it will not be for the reason you
mention.
> 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.
Yes, it's not very far from what I had in mind.
Paolo
^ permalink raw reply
* Re: CMake, was Re: [PATCH 09/11] Add MSVC porting header files.
From: Pau Garcia i Quiles @ 2009-08-17 19:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171251y355a1e2bjf2d10192bc3eca2e@mail.gmail.com>
On Mon, Aug 17, 2009 at 9:51 PM, Pau Garcia i
Quiles<pgquiles@elpauer.org> 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.
>
> 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.
I forgot to say CMake would be a build-dependency, not a runtime
dependency, in case anyone is wondering.
More info about CMake:
http://www.cmake.org
Tutorial:
http://www.elpauer.org/stuff/learning_cmake.pdf
--
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 19:53 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <40aa078e0908171040g5718a809o88b093fe5a4a0e28@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1221 bytes --]
Hi,
On Mon, 17 Aug 2009, Erik Faye-Lund wrote:
> On Mon, Aug 17, 2009 at 7:34 PM, Paolo Bonzini<bonzini@gnu.org> wrote:
> > Also, a cleaner XML without verbosities like
> >
> > + <Tool
> > + Name="VCMIDLTool"
> > + />
> >
> > would make the patch easier to review.
>
> ...but will it make it more annoying to maintain in the long run? It
> might be painful to work with a mixture of hand-written and
> msdev-written XML. Of course, if we get some scripts in place to
> generate the vcproj-files this might not be a problem...
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.
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.
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 19:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172147240.8306@pacific.mpi-cbg.de>
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.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: [PATCH 2/2 (v2)] reset: make the output more user-friendly.
From: Junio C Hamano @ 2009-08-17 19:50 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqljlipcs6.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>>>
>>>> cat > expect << EOF
>>>> -file2: locally modified
>>>> +Unstaged changes after reset:
>>>> +M file2
>>>
>>> It simply feels backwards when plumbing output says something in human
>>> language (e.g. "needs update") while Porcelain output spits out a cryptic
>>> M or U. If the goal is human-readability and user-friendliness,
>>
>> The goal here is just consistency.
>>
>> And I do consider 'git diff --name-status' as porcelain.
Ok.
^ permalink raw reply
* Re: [PATCH] git-config: Parse config files leniently
From: Junio C Hamano @ 2009-08-17 19:49 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, David Reitter, Jakub Narebski
In-Reply-To: <4A89A5B8.9040405@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Junio C Hamano venit, vidit, dixit 14.08.2009 21:52:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>> ...
>> But I may be being overly cautious.
>
> My first version had the lenient mode for "git config -e" only, which
> required a new global int (or, alternatively, changing all callers).
Without looking at the actual patch, that "single global that is only used
by builtin_config() when using -e" sounds safer.
But still I think I may be being overly cautious.
>> By the way, why did you have to change s/echo/printf/? Can't you give two
>> lines in a single argument without "\n" escape?
>
> Because "printf" is more portable then "echo -e". At least I hope so ;)
> [ One could use a "here document", of course. Is that preferable? ]
What I meant was to give literally two lines, like this:
check section.key 'warning: bad config file line 2 in .git/config
warning: bad config file line 2 in .git/config'
I do not see a need for a here-doc.
The rest is tangent you can ignore.
>>> Instead, issue a warning only and treat the rest of the line as a
>>> comment (ignore it). This benefits not only git config -e users.
>>
>> ... a broken sentence in the middle? I would have expected the "not only"
>> followed by "but also"; the question is "but also what?"
>
> I don't see any broken sentence here. "Benefit" is a verb as well as a noun.
Yes, and I think you read me correctly.
s/broken/chopped in the middle, missing 'but also X'/;
and you just explained that you meant "everyone else" by that X in the
missing part of the sentence.
^ permalink raw reply
* CMake, was Re: [PATCH 09/11] Add MSVC porting header files.
From: Johannes Schindelin @ 2009-08-17 19:48 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Frank Li, git, msysgit
In-Reply-To: <3af572ac0908171231n30864c85ud67454a03ca08fbe@mail.gmail.com>
Hi,
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?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 05/11] Remove va_copy at MSVC because there are va_copy.
From: Johannes Schindelin @ 2009-08-17 19:46 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Paolo Bonzini, Frank Li, git, msysgit
In-Reply-To: <40aa078e0908171002j4b610fe4j34a4e7d3081a9efa@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 467 bytes --]
Hi,
On Mon, 17 Aug 2009, Erik Faye-Lund wrote:
> On Mon, Aug 17, 2009 at 6:53 PM, Paolo Bonzini<bonzini@gnu.org> wrote:
> > #ifndef va_copy
> > #define va_copy(dst, src) ((dst) = (src))
> > #endif
>
> Are you sure va_copy is always a preprocessor symbol? How about
>
> #ifdef _MSC_VER
> #define va_copy(dst, src) ((dst) = (src))
> #endif
Why not #define it in compat/msvc.h? Or introduce a
DEFINE_VA_COPY_TRIVIALLY symbol or some such?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 02/11] Fix declare variable at mid of function
From: Johannes Schindelin @ 2009-08-17 19:36 UTC (permalink / raw)
To: Reece Dunn; +Cc: Frank Li, git, msysgit
In-Reply-To: <3f4fd2640908170934w4c48ada1o66745f845ecb7d49@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 985 bytes --]
Hi,
On Mon, 17 Aug 2009, Reece Dunn wrote:
> 2009/8/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Tue, 18 Aug 2009, Frank Li wrote:
> >
> >> Some compiler such as MSVC can't support declear variable at mid of
> >> funtion at c file.
> >
> > Please wrap your commit messages after 76 characters.
> >
> >>
> >> Signed-off-by: Frank Li <lznuaa@gmail.com>
> >> ---
> >
> > How about this instead?
> >
> > Avoid declaration after instruction
> >
> > Microsoft Visual C++ does not understand this C99 style.
> >
> > ?
> >
> > The patch itself is good.
>
> Shouldn't GCC be changed to use -std=c89 as well to pick up errors for
> compilers that don't support c99 (like the Microsoft Visual C++ C
> compiler)?
Hmm. I played with the thought of adding -Werror -Wno-pointer-to-int-cast
-Wold-style-definition -Wdeclaration-after-statement like Junio described
in one of his mails for MinGW (as we _know_ what compiler we have there).
Dunno.
Ciao,
Dscho
^ permalink raw reply
* Re: Linus' sha1 is much faster!
From: Nicolas Pitre @ 2009-08-17 19:34 UTC (permalink / raw)
To: George Spelvin; +Cc: art.08.09, bdonlan, git, johnflux, P, torvalds
In-Reply-To: <20090817185448.30254.qmail@science.horizon.com>
On Mon, 17 Aug 2009, George Spelvin wrote:
> > I don't think this trick of making source code textually different from
> > another work while still intimately mimicking the same structure entitles
> > you to any copyright (or non copyright) claims over that other work. I
> > certainly wouldn't bet any dime for this standing up in court.
>
> <div type="legal digression">
> Actually, I would. I did a lot more than text search and replace;
> I re-implemented it from FIPS 180-2 (work of U.S. government, no copyright)
> and then merged in the *ideas* from the mailing list.
>
> (And from elsewhere; the idea of a five-round macro is from Brian Gladman.)
>
> Remember, to the extent that something is *functional*, it is not
> copyrightable; copyright only covers the non-functional expressive bits.
> The vast majority of that code is simply required by the standard,
> or the desired calling interface.
>
> For a large portion of the rest, remember that standard programming
> conventions (e.g. brace style, macro names IN CAPS, etc.) that's also
> non-copyrightable "scene a faire" material.
>
> It's well established that paraphrasing a recipe avoids copyright;
> the proportions and treatment of the ingredients is not copyrightable.
>
> For more details, see the extensive coverage of the NEC v. Intel decision
> (1989) regarding the firmware for NEC's 8086-clone V20 microprocessor.
> It was found non-infringing despite non-clean-room implementation and
> substantial similarities.
> </div>
Whatever. NEC and Intel were certainly commercial competitors. They
were far from being friends. So if you feel like having too many
friends then just go ahead with that stance.
> As for politeness, that's exactly why I did post it and solicit
> objections.
You said:
|It uses Linus's and Artur's performance ideas, and some of Linus' macro
|ideas (in the rotate implementation), but tries to be textually
|different. Is there anything recognizable that anyone cares to clam
|copyright to?
the "try to be textually different" in order to ask for "anything
recognizable that anyone cares to clam copyright to" is what I find
dubious.
> The purpose of the rewrite is to avoid having to make
> pessimistic assumptions about people who don't respond.
>
> I suppose I should have made that request clearer:
> Is there anyone who claims copyright on anything here?
> Or would just like credit?
> If so, are you willing to donate it to the public domain?
I think this is much nicer to everyone involved.
As far as I'm concerned, I'm OK with giving any small copyright I might
have in this SHA1 implementation, if any, to the public domain.
Credits are always nice.
Nicolas
^ permalink raw reply
* Re: [PATCH 09/11] Add MSVC porting header files.
From: Pau Garcia i Quiles @ 2009-08-17 19:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908171902300.4991@intel-tinevez-2-302>
>> diff --git a/compat/msvc.h b/compat/msvc.h
>> new file mode 100644
>> index 0000000..6071565
>> --- /dev/null
>> +++ b/compat/msvc.h
>> @@ -0,0 +1,95 @@
>> +#ifndef __MSVC__HEAD
>> +#define __MSVC__HEAD
>> +
>> +#define WINVER 0x0500
>> +#define _WIN32_WINNT 0x0500
>> +#define _WIN32_WINDOWS 0x0410
>> +#define _WIN32_IE 0x0700
>> +#define NTDDI_VERSION NTDDI_WIN2KSP1
>> +#include <winsock2.h>
>> +
>> +/*Configuration*/
>> +
>> +#define NO_PREAD
>> +#define NO_OPENSSL
>> +#define NO_LIBGEN_H
>> +#define NO_SYMLINK_HEAD
>> +#define NO_IPV6
>> +#define NO_SETENV
>> +#define NO_UNSETENV
>> +#define NO_STRCASESTR
>> +#define NO_STRLCPY
>> +#define NO_MEMMEM
>> +#define NO_C99_FORMAT
>> +#define NO_STRTOUMAX
>> +#define NO_MKDTEMP
>> +#define NO_MKSTEMPS
>> +
>> +#define RUNTIME_PREFIX
>> +#define NO_ST_BLOCKS_IN_STRUCT_STAT
>> +#define NO_NSEC
>> +#define USE_WIN32_MMAP
>> +#define USE_NED_ALLOCATOR
>> +
>> +#define NO_REGEX
>> +
>> +#define NO_SYS_SELECT_H
>> +#define NO_PTHEADS
>> +#define HAVE_STRING_H 1
>> +#define STDC_HEADERS
>> +#define NO_ICONV
>
> These would normally be defined in the Makefile. You might want to state
> that in a comment.
>
> Or maybe move the definitions (along with vsnprintf) to the .vcproj file,
> which is the logical pendant of the Makefile?
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.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: [PATCH 02/11] Fix declare variable at mid of function
From: Junio C Hamano @ 2009-08-17 19:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908171827040.4991@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> How about this instead?
>
> Avoid declaration after instruction
It's called declaration-after-statement.
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.
^ permalink raw reply
* Re: [PATCH 06/11] Add miss git-compat-util.h at regex.c and fnmatch.c Add git-compat-util.h to enable build at MSVC environment
From: Johannes Sixt @ 2009-08-17 19:23 UTC (permalink / raw)
To: msysgit; +Cc: Frank Li, git, Johannes.Schindelin
In-Reply-To: <1250525103-5184-1-git-send-email-lznuaa@gmail.com>
On Montag, 17. August 2009, Frank Li wrote:
> Signed-off-by: Frank Li <lznuaa@gmail.com>
> ---
> compat/fnmatch/fnmatch.c | 4 ++++
> compat/regex/regex.c | 4 ++++
> 2 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c
> index 14feac7..5cbd49c 100644
> --- a/compat/fnmatch/fnmatch.c
> +++ b/compat/fnmatch/fnmatch.c
> @@ -16,6 +16,10 @@
> write to the Free Software Foundation, Inc., 59 Temple Place - Suite
> 330, Boston, MA 02111-1307, USA. */
>
> +#ifdef _MSC_VER
> +#include "git-compat-util.h"
> +#endif
There is a *lot* to explain: Why the *heck* is this needed?
> diff --git a/compat/regex/regex.c b/compat/regex/regex.c
> index 5728de1..2298a3a 100644
> --- a/compat/regex/regex.c
> +++ b/compat/regex/regex.c
> @@ -20,6 +20,10 @@
> Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */
>
> /* AIX requires this to be the first thing in the file. */
> +#ifdef _MSC_VER
> +#include "git-compat-util.h"
> +#endif
Same here.
-- Hannes
^ permalink raw reply
* Re: [msysGit] [PATCH 09/11] Add MSVC porting header files.
From: Johannes Sixt @ 2009-08-17 19:21 UTC (permalink / raw)
To: msysgit; +Cc: Frank Li, git, Johannes.Schindelin
In-Reply-To: <1250525103-5184-4-git-send-email-lznuaa@gmail.com>
On Montag, 17. August 2009, Frank Li wrote:
> diff --git a/compat/msvc.h b/compat/msvc.h
> new file mode 100644
> index 0000000..6071565
> --- /dev/null
> +++ b/compat/msvc.h
> @@ -0,0 +1,95 @@
> +#ifndef __MSVC__HEAD
...
> +#endif
> \ No newline at end of file
Please fix these "No newline at end of file" an all cases (I quoted only one
instance where I saw this).
-- Hannes
^ permalink raw reply
* Re: [PATCH 0/6] "git commit --dry-run" updates
From: Thomas Rast @ 2009-08-17 19:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vljlixwkz.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > If it's not too much work, it would be nice to somehow detect if -u
> > can have any influence at all. For example,
> >
> > $ git status bar
> > # Not currently on any branch.
> > nothing to commit (use -u to show untracked files)
> >
> > is a bit misleading if 'bar' is tracked because adding a -u won't make
> > any difference.
[...]
> It is not about "we know that there are untracked files but you told me
> not to show it, so I am not telling". We simply do not know at the point
> we give that message. In other words, conditional removal of that message
> is fundamentally incompatible with the use of -uno.
Ok. I hoped there would be an easy way to know that all pathspecs
exactly matched a tracked file, and thus no untracked files can
possibly change the listing.
But you convinced me that it doesn't fit into the current scheme, and
it doesn't really matter...
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Linus' sha1 is much faster!
From: George Spelvin @ 2009-08-17 18:54 UTC (permalink / raw)
To: linux, nico; +Cc: art.08.09, bdonlan, git, johnflux, P, torvalds
In-Reply-To: <alpine.LFD.2.00.0908171228570.6044@xanadu.home>
> I don't think this trick of making source code textually different from
> another work while still intimately mimicking the same structure entitles
> you to any copyright (or non copyright) claims over that other work. I
> certainly wouldn't bet any dime for this standing up in court.
<div type="legal digression">
Actually, I would. I did a lot more than text search and replace;
I re-implemented it from FIPS 180-2 (work of U.S. government, no copyright)
and then merged in the *ideas* from the mailing list.
(And from elsewhere; the idea of a five-round macro is from Brian Gladman.)
Remember, to the extent that something is *functional*, it is not
copyrightable; copyright only covers the non-functional expressive bits.
The vast majority of that code is simply required by the standard,
or the desired calling interface.
For a large portion of the rest, remember that standard programming
conventions (e.g. brace style, macro names IN CAPS, etc.) that's also
non-copyrightable "scene a faire" material.
It's well established that paraphrasing a recipe avoids copyright;
the proportions and treatment of the ingredients is not copyrightable.
For more details, see the extensive coverage of the NEC v. Intel decision
(1989) regarding the firmware for NEC's 8086-clone V20 microprocessor.
It was found non-infringing despite non-clean-room implementation and
substantial similarities.
</div>
> It is probably much safer to simply ask the people involved to agree
> with your relicensing. And so far I don't see anyone with a stake in
> this fiercely wanting to stick to a particular license.
As for politeness, that's exactly why I did post it and solicit
objections. The purpose of the rewrite is to avoid having to make
pessimistic assumptions about people who don't respond.
I suppose I should have made that request clearer:
Is there anyone who claims copyright on anything here?
Or would just like credit?
If so, are you willing to donate it to the public domain?
I like the GPL, but some code is generally applicable enough, and unlikely
to be improved on by others enough, that I'd rather just let everyone
use the same version.
> It's not quite 100% finished, as I haven't benchmarked it against Linus's
> code yet, but it's functionally correct.
>
> It's also clean with -W -Wall -Wextra.
> Not if you try with the unaligned put_be32() as the destination pointer
> is marked const.
Oops. And the "||" in get_be32() doesn't help either.
There was another major bug I found, too.
And I'm still trying to match "linusv" performance.
> As to the actual result on ARM... Well, the assembly _looks_ much worse
> than Linus' version. It uses a stack frame of 152 bytes instead of 64
> bytes. The resulting binary is also 6868 bytes large compared to 6180
> bytes. Surprisingly, the performance is not that bad (the reason for
> the underlined "looks" above) albeit still a bit worse, like 5% slower.
> I was expecting much worse than that.
Thanks, I'll work on it.
> Also, wrt skipping the last 3 write back to the 16 word array... For
> all the (limited) attempts I've made so far to do that, it always ended
> up making things worse. I've yet to investigate why though.
Thanks. That's certainly surprising!
If anyone cares, my current code (adapted to fit sha1bench) is appended.
/*
* Secure Hash Algorith SHA-1, as published in FIPS PUB 180-2.
*
* This implementation is in the public domain. Copyright abandoned.
* You may do anything you like with it, including evil things.
*
* This is a rewrite from scratch, based on Linus Torvalds' "block-sha1"
* from the git mailing list (August, 2009). Additional optimization
* ideas cribbed from
* - Artur Skawina (x86, particularly P4, and much benchmarking)
* - Nicolas Pitre (ARM)
*
* Contributors to this code are requested to donate their changes to
* the public domain to avoid version skew. If you don't want to, be
* sure to change the copyright waiver above.
*/
#include <string.h> /* For memcpy() */
#include <arpa/inet.h> /* For ntohl() */
#include "pdsha1.h"
#define SHA_CTX pd_SHA_CTX
#define SHA_context pd_SHA_context
#define SHA1_Init pd_SHA1_Init
#define SHA1_Update pd_SHA1_Update
#define SHA1_Final pd_SHA1_Final
static void sha1_core(uint32_t iv[5], unsigned char const *p);
void SHA1_Init(struct SHA_context *c)
{
/* This is a prefix of the SHA_context structure */
static struct {
uint64_t len;
uint32_t iv[5];
} const iv = { 0,
{ 0x67452301, 0xEFCDAB89, 0x98BADCFE, 0x10325476, 0xC3D2E1F0 }
};
memcpy(c, &iv, sizeof iv);
}
void SHA1_Update(struct SHA_context *c, void const *p, size_t n)
{
size_t pos = c->len & 63; /* Offset into current input block */
size_t nblocks;
c->len += n;
/* Initial partial block (if any) */
if (pos) {
size_t space = 63 - pos;
if (n < space)
goto end;
memcpy(c->buf + pos, p, space);
sha1_core(c->iv, c->buf);
n -= space;
p = (char const *)p + space;
}
/* The large middle piece */
nblocks = n >> 6;
while (nblocks--) {
sha1_core(c->iv, p);
p += 64;
}
n &= 63;
pos = 0;
end:
/* Final partial block (may be zero size) */
memcpy(c->buf + pos, p, n);
}
/* Machine specific hacks */
#if defined(__i386__) || defined(__x86_64__) || defined (__ppc__) || \
defined(__ppc64__) || defined(__powerpc__) || defined (__powerpc64__) || \
defined(__s390__) || defined(__s390x__)
/* Unaligned access is okay */
#define GET_BE32(p) ntohl(*(uint32_t const *)(p))
#define PUT_BE32(p,v) (*(uint32_t *)(p) = htonl(v))
#else
/*
* Unaligned access is not okay; do conversion as byte fetches
* These macros are IN_CAPS, as they are not side-effect safe
* The argument p must be an "unsigned char *" or "uint8_t *"
*/
#define GET_BE32(p) \
((uint32_t)(p)[0]<<24 | (p)[1]<<16 | (p)[2]<<8 | (p)[3])
#define PUT_BE32(p,v) \
( (p)[0] = (v)>>24, (p)[1] = (v)>>16, (p)[2] = (v)>>8, (p)[3] = (v) )
#endif
void SHA1_Final(unsigned char hash[20], struct SHA_context *c)
{
size_t pos = c->len & 63;
unsigned i;
/* Append a single 1 bit */
c->buf[pos++] = 0x80;
/* Append 0 bits until 64 bits remain in a block */
if (pos > 56) {
memset(c->buf + pos, 0, 64 - pos);
sha1_core(c->iv, c->buf);
pos = 0;
}
memset(c->buf + pos, 0, 56 - pos);
/* Append total input length in bits */
((uint32_t *)c->buf)[14] = htonl((uint32_t)(c->len >> 29));
((uint32_t *)c->buf)[15] = htonl((uint32_t)c->len << 3);
/* Final hash round */
sha1_core(c->iv, c->buf);
/* Copy hash result out */
for (i = 0; i < 5; i++)
PUT_BE32(hash + 4*i, c->iv[i]);
}
/*
* Helper macros for sha1_core function. To avoid clutter, these macros
* are NOT fully parenthesized if it doesn't matter to the actual use.
*/
#if __GNUC__ && (defined(__i386__) || defined(__x86_64__))
/*
* GCC by itself only generates left rotates. Use right rotates if
* possible to be kinder to dinky implementations with iterative rotate
* instructions.
*/
#define ROT(op, x, k) \
({ uint32_t y; __asm__(op " %1,%0" : "=r" (y) : "I" (k), "0" (x)); y; })
#define ROL(x,k) ROT("roll", x, k)
#define ROR(x,k) ROT("rorl", x, k)
#else
/* Generic C equivalent */
#define ROT(x,l,r) ((x) << (l) | (x) >> (r))
#define ROL(x,k) ROT(x,k,32-(k))
#define ROR(x,k) ROT(x,32-(k),k)
#endif
/*
* An important temporary array in SHA-1 is the working array W[],
* which holds a scheduled key word per round. Only the last 16 words
* are relevant, so only use 16 words...
*/
#define W(i) w[(i) & 15]
/*
* If you have a small register set, it helps GCC to force stores to
* the w[] array to memory. Given 22 or more registers (e.g. PowerPC),
* GCC can map the entire w[] array to registers and this becomes
* counterproductive.
*
* The optimal kludge seems to differ between x86 and ARM. On the latter,
* forcing a full memory barrier is required to stop GCC from splitting
* live ranges for each round and generating a separate stack slot for
* each. (Which produces a huge stack frame and kills performance.)
*/
#if __GNUC__ && defined(__i386__) || defined(__x86_64__)
#define STORE(i, x) W(i) = x; __asm__ volatile("" : "+m" (W(x)))
#elif defined(__i386__) || defined(__x86_64__)
#define STORE(i, x) *(volatile uint32_t *)&W(i) = x
#elif __GNUC__ && defined(__arm__)
#define STORE(i, x) W(i) = x; __asm__("":::"memory")
#else
#define STORE(i, x) W(i) = x
#endif
/* The three round functions. F2 is also used as F4 */
#define F1(b,c,d) (((d ^ c) & b) ^ d) /* Bitwise b ? c : d */
#define F2(b,c,d) (d ^ c ^ b) /* Even parity */
#define F3(b,c,d) (d & c) + ((d ^ c) & b) /* Majority function */
/* The four round constants */
#define K1 0x5a827999 /* 2^30 * sqrt(2) */
#define K2 0x6ed9eba1 /* 2^30 * sqrt(3) */
#define K3 0x8f1bbcdc /* 2^30 * sqrt(5) */
#define K4 0xca62c1d6 /* 2^30 * sqrt(10) */
/* Rounds 0..15 fetch a word from the input */
#define FETCH(t,i) t = GET_BE32(p + 4*(i)); STORE(i,t)
//#define FETCH(t,i) t = W(i)
/* Rounds 16..79 mix previous words to get a new one */
#define MIX(t,i) t = W(i) ^ W(i+2) ^ W(i+8) ^ W(i+13); t = ROL(t, 1)
/* Rounds 16..76 have to store back the result */
#define CALC(t,i) MIX(t,i); STORE(i,t)
/* The basic SHA-1 round */
#if 0
#define SHA_ROUND(a,b,c,d,e,f,k,src,t,i) \
src(t,i); \
e += t + f(b,c,d) + k + ROL(a,5); \
b = ROR(b,2)
#elif 0
#define SHA_ROUND(a,b,c,d,e,f,k,src,t,i) do { \
uint32_t t; \
src(t,i); \
e += f(b,c,d); \
e += t + k; \
b = ROR(b,2); \
e += ROL(a,5); } while (0)
#else
#define SHA_ROUND(a,b,c,d,e,f,k,src,t,i) do { \
uint32_t t = ROL(a,5); \
e += f(b,c,d); \
e += k + t; \
src(t,i); \
b = ROR(b,2); \
e += t; } while(0)
#endif
/* An aligned group of 5 rounds */
#define SHA_ROUND5(f,k,src,t,i) \
SHA_ROUND(a,b,c,d,e, f,k,src,t,i); \
SHA_ROUND(e,a,b,c,d, f,k,src,t,i+1); \
SHA_ROUND(d,e,a,b,c, f,k,src,t,i+2); \
SHA_ROUND(c,d,e,a,b, f,k,src,t,i+3); \
SHA_ROUND(b,c,d,e,a, f,k,src,t,i+4)
/*
* The core SHA-1 transform.
*
* iv[5] = Current SHA-1 hash state.
* p = Pointer to 64 bytes of source data. Not necessarily aligned.
*/
static void
sha1_core(uint32_t iv[5], unsigned char const *p)
{
//uint32_t e = iv[4], d = iv[3], c = iv[2], b = iv[1], a = iv[0];
uint32_t a = iv[0], b = iv[1], c = iv[2], d = iv[3], e = iv[4];
uint32_t w[16];
#if 0
{
int i;
for (i = 0; i < 16; i++) {
STORE(i, get_be32(p + 4*i));
}
}
#endif
SHA_ROUND5(F1, K1, FETCH, t, 0);
SHA_ROUND5(F1, K1, FETCH, t, 5);
SHA_ROUND5(F1, K1, FETCH, t, 10);
SHA_ROUND(a,b,c,d,e, F1, K1, FETCH, t, 15);
SHA_ROUND(e,a,b,c,d, F1, K1, CALC, t, 16);
SHA_ROUND(d,e,a,b,c, F1, K1, CALC, t, 17);
SHA_ROUND(c,d,e,a,b, F1, K1, CALC, t, 18);
SHA_ROUND(b,c,d,e,a, F1, K1, CALC, t, 19);
SHA_ROUND5(F2, K2, CALC, t, 20);
SHA_ROUND5(F2, K2, CALC, t, 25);
SHA_ROUND5(F2, K2, CALC, t, 30);
SHA_ROUND5(F2, K2, CALC, t, 35);
SHA_ROUND5(F3, K3, CALC, t, 40);
SHA_ROUND5(F3, K3, CALC, t, 45);
SHA_ROUND5(F3, K3, CALC, t, 50);
SHA_ROUND5(F3, K3, CALC, t, 55);
SHA_ROUND5(F2, K4, CALC, t, 60);
SHA_ROUND5(F2, K4, CALC, t, 65);
SHA_ROUND5(F2, K4, CALC, t, 70);
SHA_ROUND(a,b,c,d,e, F2, K4, CALC, t, 75);
SHA_ROUND(e,a,b,c,d, F2, K4, CALC, t, 76);
/* Last 3 rounds don't need to store mixed value */
SHA_ROUND(d,e,a,b,c, F2, K4, MIX, t, 77);
SHA_ROUND(c,d,e,a,b, F2, K4, MIX, t, 78);
SHA_ROUND(b,c,d,e,a, F2, K4, MIX, t, 79);
iv[0] += a;
iv[1] += b;
iv[2] += c;
iv[3] += d;
iv[4] += e;
}
/* Compile with -DUNITTEST for self-tests */
#if UNITTEST
#include <stdio.h>
#include <stdlib.h>
/* Known answer test */
static void katest(char const *text, size_t len, unsigned char const hash[20])
{
SHA_CTX c;
unsigned char hash2[20];
int i;
SHA1_Init(&c);
SHA1_Update(&c, text, len);
SHA1_Final(hash2, &c);
for (i = 0; i < 20; i++)
if (hash[i] != hash2[i])
goto mismatch;
printf("%u-byte known answer test PASSED\n", len);
return;
mismatch:
printf("%u-byte known answer test FAILED:\n", len);
if (len < 64)
printf("Input: \"%.*s\"\n", len, text);
else
printf("Input: \"%.64s\"...\n", text);
printf("Computed:");
for (i = 0; i < 20; i++)
printf(" %02x", hash2[i]);
printf("\nExpected:");
for (i = 0; i < 20; i++)
printf(" %02x", hash[i]);
putchar('\n');
}
int
main(void)
{
/* FIPS PUB 180.1 example A.1 */
static char const text1[3] = "abc";
static unsigned char const hash1[20] = {
0xa9, 0x99, 0x3e, 0x36, 0x47, 0x06, 0x81, 0x6a, 0xba, 0x3e,
0x25, 0x71, 0x78, 0x50, 0xc2, 0x6c, 0x9c, 0xd0, 0xd8, 0x9d };
/* FIPS PUB 180.1 example A.2 */
static char const text2[56] =
"abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq";
static unsigned char const hash2[20] = {
0x84, 0x98, 0x3e, 0x44, 0x1c, 0x3b, 0xd2, 0x6e, 0xba, 0xae,
0x4a, 0xa1, 0xf9, 0x51, 0x29, 0xe5, 0xe5, 0x46, 0x70, 0xf1 };
/* FIPS PUB 180.1 example A.3 */
char *text3;
static unsigned char const hash3[20] = {
0x34, 0xaa, 0x97, 0x3c, 0xd4, 0xc4, 0xda, 0xa4, 0xf6, 0x1e,
0xeb, 0x2b, 0xdb, 0xad, 0x27, 0x31, 0x65, 0x34, 0x01, 0x6f };
katest(text1, sizeof text1, hash1);
katest(text2, sizeof text2, hash2);
text3 = malloc(1000000);
memset(text3, 'a', 1000000);
katest(text3, 1000000, hash3);
return 0;
}
#endif
^ permalink raw reply
* Re: [PATCH] git-config: Parse config files leniently
From: Michael J Gruber @ 2009-08-17 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Reitter, Jakub Narebski
In-Reply-To: <7veirejhqq.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 14.08.2009 21:52:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Currently, git config dies as soon as there is a parsing error. This is
>> especially unfortunate in case a user tries to correct config mistakes
>> using git config -e.
>>
>> Instead, issue a warning only and treat the rest of the line as a
>> comment (ignore it). This benefits not only git config -e users.
>
> ... a broken sentence in the middle? I would have expected the "not only"
> followed by "but also"; the question is "but also what?"
I don't see any broken sentence here. "Benefit" is a verb as well as a noun.
"not only git config -e users" but also everyone else: Unparseable lines
are ignored, the rest is parsed.
>
> Hopefully the benefit is not that it now allows all the other commands to
> cause unspecified types of damage to the repository by following iffy
> settings obtained from a broken configuration file.
The only possible problem that I see is when a section heading is not
parsed because of a forgotten "[", say, and the following settings are
put in the wrong section because of that.
>> Reported-by: David Reitter <david.reitter@gmail.com>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>
>> Test had to be adjusted as well.
>
> The change to the test demonstrates the issue rather well. The check()
> shell function does not check the exit value from "git config --get", but
> in a real script that cares to check and stop on error, this change will
> now let the script go on, leaving the breakage unnoticed. I suspect
> command implemented in C, that call git_config(), will also have the same
> issue, and I cannot convince myself this is a good change in general,
> outside the scope of helping "git config -e".
>
> But I may be being overly cautious.
My first version had the lenient mode for "git config -e" only, which
required a new global int (or, alternatively, changing all callers).
One could issue a warning and return -1 rather than success. I'm afraid
git_config() callers don't check return values but rely on git_config()
dieing in case there are parsing problems.
>
> By the way, why did you have to change s/echo/printf/? Can't you give two
> lines in a single argument without "\n" escape?
Because "printf" is more portable then "echo -e". At least I hope so ;)
[ One could use a "here document", of course. Is that preferable? ]
Michael
^ permalink raw reply
* Re: [RFC PATCH v3 8/8] --sparse for porcelains
From: Junio C Hamano @ 2009-08-17 18:39 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Jakub Narebski, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.DEB.1.00.0908171817570.4991@intel-tinevez-2-302>
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.
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").
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.
^ permalink raw reply
* Re: [PATCH 2/2 (v2)] reset: make the output more user-friendly.
From: Matthieu Moy @ 2009-08-17 17:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <vpq7hxeu4un.fsf@bauges.imag.fr>
[ back from holiday ]
Any opinion/update on this? I don't think I got any reply ...
Thanks,
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>>
>>> cat > expect << EOF
>>> -file2: locally modified
>>> +Unstaged changes after reset:
>>> +M file2
>>
>> It simply feels backwards when plumbing output says something in human
>> language (e.g. "needs update") while Porcelain output spits out a cryptic
>> M or U. If the goal is human-readability and user-friendliness,
>
> The goal here is just consistency.
>
> And I do consider 'git diff --name-status' as porcelain.
>
>> shouldn't we rather say:
>>
>> Path with local modifications:
>> file2
>>
>> or something?
>
> Why not, but if we do, we should also remove this "M" from other
> places. It was already there in one error message given by 'git
> rebase' in a non-clean tree (and you just accepted a patch giving the
> same output for another one).
--
Matthieu
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox