* Re: sparse support in pu
From: Nguyen Thai Ngoc Duy @ 2009-08-17 10:21 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0908170149o425544dcw52aeb6ac6ee1437d@mail.gmail.com>
[I haven't read the rest of the mail, will read it through later]
On Mon, Aug 17, 2009 at 3:49 PM, <skillzero@gmail.com> wrote:
> It would be nice if .git/info/sparse is there by default (like
> .git/info/exclude) with some commented out instructions (also like
> .git/info/exclude).
No it can't be there by default. An empty .git/info/sparse means clear
assume-unchanged bit out of all files in index. It's not the same as
lacking .git/info/sparse (which does disable sparse checkout feature).
--
Duy
^ permalink raw reply
* Git User's Survey 2009 partial summary, part 2 - from first 10
From: Jakub Narebski @ 2009-08-17 10:24 UTC (permalink / raw)
To: git
Git User's Survey 2009 partial summary, part 2 - git difficulty,
proficiency, uses, install, OS, editors.
It more than a month since Git User's Suvey 2009 was started (it was
started on 15 July 2009), which is a half of planned duration time of
the survey.
So I think this is time for second part partial summary of Git User's
Survey 2009. The previous part can be found at
http://thread.gmane.org/gmane.comp.version-control.git/124599
Subject: Git User's Survey 2009 partial summary, part 1 -
- announcing survey, participation
Message-Id: <200907312246.12134.jnareb@gmail.com>
You can see summary of Git User's Survey 2009 responses (and make your
own analysis) at the following URL:
http://www.survs.com/shareResults?survey=2PIMZGU0&rndm=678J66QRA2
http://tinyurl.com/GitSurvey2009Analyze
After the survey ends (or earlier, if it is requested) the raw data
would be published on GitSurvey2009 page on Git Wiki in CSV and XLS
formats (like for GitSurvey2008).
We have currently (at the time I have checked this) around 3089
responses, as compared to 3236 individual responses (including 21
responses in 'test' channel) for survey in 2008, 683 individual
responses in 2007, and around 117 responses in 2006.
Below there is analysis of few questions from this survey; note that
results might do not add to 100% because of replies during using live
analysis tool, and the rounding.
3) Have you found Git easy to learn?
4) Have you found Git easy to use?
(Choice - Single answer)
================================================
Answer | to learn [%] | to use [%]
------------------------------------------------
Very easy | 4% | 9%
Easy | 20% | 36%
Reasonably easy | 55% | 45%
Hard | 19% | 8%
Very hard | 2% | 1%
------------------------------------------------
Total respondents | 2942 | 2959
================================================
As you can see the myth that Git is hard to learn was busted ;-) Not.
When analyzing this data you should take into account that somebody
considering or finding Git to hard to learn wouldn't be probably Git
user, and thus wouldn't fill this survey. So because it is
*Git User's* Survey we should consider that results can be skewed
towards lower value (easier).
What's interesting is comparing (percentage) results for questions
3. and 4.; how hard is git to learn versus how hard is to use. It
seems like Git is reasonably easy to learn, and reasonably easy to
easy to use. So it looks like Git just have somewhat steep learning
curve, and the difficulty to learn pays in being more powerful to
use.
6) Rate your own proficiency with Git:
(Choice - Single answer)
You can think of it as 1-5 numerical grade of your proficiency in Git.
================================================
Proficiency | resp [%] | resp [n]
------------------------------------------------
1. novice | 4% | 114
2. casual, needs advice | 17% | 520
3. everyday use | 38% | 1138
4. can offer advice | 34% | 1020
5. know it very well | 6% | 192
--------------------------+---------------------
Total respondents | 2984
Skipped this question | 105
================================================
As you can see most responders know Git enough for everyday use, or
can even offer some Git advice. If we treat possible answers as a
proficiency grade, the average proficiency is around 3.2.
Either Git users don't stay novices long, or survey announcement(s)
didn't reach novice users.
This data could be useful later to be able to check how it differs
git usage for novices and for gurus (what commands they run, what
features they use at different levels of proficiency).
7) I use Git for (check all that apply):
(Choice - Multiple answers)
Note that above choices are neither orthogonal nor exclusive. One
might want to check multiple answers even for a single repository.
============================================
Answer | resp [%] | resp [n]
--------------------------------------------
work projects | 79% | 2366
unpaid projects | 80% | 2391
............................................
work and unpaid | 66% | 1960
only work | 14% | 407
only unpaid | 15% | 432
not answered | 6% | 190
--------------------------------------------
proprietary projects | 37% | 1108
OSS development | 69% | 2054
private code | 77% | 2315
--------------------------------------------
code (programming) | 87% | 2591
web app | 43% | 1274
configuration files | 34% | 1010
personal data | 33% | 972
documents | 32% | 956
static website | 29% | 881
--------------------------------------------
frontend to other SCM | 32% | 971
sharing data or sync | 22% | 645
backup | 24% | 722
backend for web app | 9% | 263
............................................
--------------------------------------------
other | 3% | 84
============================================
Total respondents | 2989
Skipped this question | 104
============================================
The answers in the table above are in slightly different order than in
original, i.e. in the survey. Analysis of correlations was done here
only for work / unpaid part of answer (see table above).
This question joins together (to reduce number of questions in the
survey) few separate issues:
* Whether one use Git for work, or for unpaid projects: this survey
results shows that the amount of paid and unpaid projects are about
the same, and that most of people (most of responders) us Git for
both work (paid) and free (unpaid) projects.
* The question of openess / license: whether one uses Git for
proprietary projects or for FLOSS (Free/Libre/Open Source
Software), or perhaps for private code (not covered by license).
Here OSS development and private code/data dominates over using Git
for proprietary code, with around twice as much answers. This may
be caused by the fact that Git is / feels more suited to opensource
(like) development (proprietary code can use proprietary SCM), but
it might be that announcement didn't make it to people using Git
for proprietary works.
* Whether one uses Git for code (for something it was created for),
or for other things like documents etc. Here code dominates,
having around twice as many replies as the next in turn, 'web app'
(which is also code, but a special case, and not only code).
* next is UGFWIINI part: using Git for what it was not intended.
Well, except perhaps using Git as frontend or fat-client for other
SCM (e.g. git-svn for Subversion). Using Git for other SCM
dominates with 32%, next are using Git for sharing, and for backup
(both with around 23% of responses).
* The "other (please specify)" is not yet analyzed (nor even began
analysis so far).
8) How do/did you obtain Git (install and/or upgrade)?
(Choice - Multiple answers)
Explanation: binary package covers pre-compiled binary (e.g. from rpm
or deb binary packages); source package covers things like deb-src and
SRPMS/*.src.rpm; source script is meant to cover installation in
source-based distributions, like 'emerge' in Gentoo.
Automatic update (apt, yum, etc.) in most cases means binary package
install; unless one uses source-based distribution like Gentoo, CRUX,
or SourceMage, where automatic update means using source package (or
source script).
The option named "preinstalled / sysadmin job" means that either you
didn't need to install git because it was preinstalled (and you didn't
upgrade); or that you have to ask system administrator to have git
installed or upgraded.
Note that this question is multiple choices question because one can
install Git in different ways on different machines or on different
operating systems.
==================================================
Answer | resp [%] | resp [n]
--------------------------------------------------
binary package | 71% | 2118
source package or script | 24% | 704
source tarball | 20% | 588
pull from repository | 18% | 527
preinstalled / sysadmin job | 6% | 185
other - please specify | 4% | 123
----------------------------+---------------------
Total respondents | 2975
Skipped this question | 118
==================================================
Most people (71%) use ready binary packages, which was kind of
expected; that is the easiest way.
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'.
============================================================
Operating system | resp [%] | resp [n]
------------------------------------------------------------
Linux | 88% | 2623
MacOS X (Darwin) | 44% | 1304
MS Windows/Cygwin | 9% | 279
MS Windows/msysGit (MINGW) | 21% | 625
*BSD (FreeBSD, OpenBSD, NetBSD, etc.) | 7% | 213
OpenSolaris | 3% | 101
other Unix | 2% | 60
Other, please specify | 2% | 46
......................................|..........|..........
MS Windows (any) | 27% | 820
--------------------------------------+---------------------
Total respondents | 2991
Respondents who skipped this question | 102
============================================================
Most common used operating system is Linux, next is MacOS X, and then
MS Windows (on MS Window dominates msysGit version). This is quite
understandable, as Git was created on Linux and for Linux, and it
works best there.
The "other" answer include Solaris, AIX, HP-UX (other Unix), GNU/Linux
(Linux), Debian, NixOS (Linux distributions), none (?); iPod, OpenVMS,
QNX, Hurd and "my toaster" (?). And some commentaries and
clarifications.
10) What do you use to edit contents under version control with Git?
What kind of editor, IDE or RAD you use working with Git?
(Choice - Multiple answers)
* "simple text editor" option includes editors such as pico, nano,
joe, Notepad,
* "programmers editor" option includes editors such as Emacs/XEmacs,
Vim, TextMate, SciTE (syntax highlighting, autoindentation,
integration with other programmers tools, etc.)
* "IDE (Integrated Development Environment) and RAD (Rapid Application
Development)" option includes tools such as Eclipse, NetBeans IDE,
IntelliJ IDE, MS Visual Studio, KDevelop, Anjuta, Xcode,
Code::Blocks but also tools such as Quanta+, BlueFish or Screem (for
editing HTML, CSS, PHP etc.), and Kile or LEd for LaTeX.
* "WYSIWYG tools" option includes word processors such as MS Office or
OpenOffice.org, but also tools such as Adobe Acrobat (for PDF) or
GIMP (for images), or WYSIWYG DTP tools such as QuarkXPress,
PageMaker or Scribus, or WYSIWYG HTML editors such as FrontPage,
Dreamweaver or KompoZer.
============================================================
Answer | resp [%] | resp [n]
------------------------------------------------------------
simple text editor | 25% | 752
programmers editor | 88% | 2641
IDE or RAD | 32% | 960
WYSIWYG tool | 5% | 159
other kind - please specify | 3% | 95
--------------------------------------+---------------------
Total respondents | 2985
Respondents who skipped this question | 108
============================================================
Most popular kind of tool is programmer's editor with very strong 88%
lead. Next in turn are IDE or RAD with 32%, followed by simple text
editor, with 25%. The WYSIWYG tools are last, with very small 5% of
replies; also people who use WYSIWYG tools also use other kind of
tools to edit (presumably to edit commit message at least).
>From browsing through "other tool" responses it seem like there should
be included 'web interface' among possible tools (written as: wiki
frontend, GitHub editor, <textarea>). Other responses include Xournal
(note taking application for graphic tablet, using stylus), Tinderbox
(also note taking application), Git GUI tool: GitX (?), custom
git-aware CMS (probably also 'web interface'), scripts and oneliners,
command line and 'On occasion, Unix text manipulation tools'. Also
there is "audio editors" answer (which probably should fall under
"WYSIWYG tool)...
Many answers in 'other tool' falls in one of ready categories; perhaps
they are clarification?
--
Jakub Narebski
Git User's Survey 2009: http://tinyurl.com/GitSurvey2009
^ permalink raw reply
* Re: [PATCH 0/6] "git commit --dry-run" updates
From: Thomas Rast @ 2009-08-17 10:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <1250330803-22171-1-git-send-email-gitster@pobox.com>
Junio C Hamano wrote:
> The third and the fourth ones tentatively introduce "git stat". The
> former is an incomplete implementation that ignores the pathspec, and the
> latter adds pathspec limiting to it. In the final form before it goes to
> 'next', these two should probably be squashed.
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.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: sparse support in pu
From: Johannes Schindelin @ 2009-08-17 9:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: skillzero, Nguyen Thai Ngoc Duy, git
In-Reply-To: <4A89282A.3020907@viscovery.net>
Hi,
On Mon, 17 Aug 2009, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > On Mon, 17 Aug 2009, skillzero@gmail.com wrote:
> >> On Mon, Aug 17, 2009 at 1:17 AM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
> >>> On Mon, Aug 17, 2009 at 1:09 PM, <skillzero@gmail.com> wrote:
> >>>> 1. Have people decided whether it should be on by default if you have
> >>>> a .git/info/sparse file? I'd definitely like it to be on by
> >>>> default. When I first tried it, I didn't realize I had to use
> >>>> --sparse to git checkout to get it to use the sparse rules. The
> >>>> same goes for a merge I did that happened to have a file in the
> >>>> excluded area (it included it because I didn't use --sparse to git
> >>>> merge).
> >>> I tend to make it enabled by default too. I have made it stricter to
> >>> trigger reading sparse in unpack_trees() -- only do it when
> >>> unpack_opts.update is TRUE. This should make it safer to be enabled by
> >>> default.
> >> Other than it being new and not-widely-tested code, is there any
> >> additional risk to having it enabled by default if there are no sparse
> >> patterns defined?
> >
> > I think that in and of itself is reason enough to turn off the feature
> > when .git/info/sparse is not present.
>
> I might have missed something: Would there be any observable difference
> between whether .git/info/sparse is absent and whether it is empty?
There _should_ not be an _observable_ difference.
> If not, what do you mean by "turn the feature off"?
There is a global variable which triggers the code path that looks through
the sparse patterns. I'd like this variable to be "off" by default.
> >> It would be nice if .git/info/sparse is there by default (like
> >> .git/info/exclude) with some commented out instructions (also like
> >> .git/info/exclude).
> >
> > I'm not a fan of this idea.
>
> For any particular reason?
First, it is an experimental feature. I'd hate it if people who do not
want to use the sparse feature are affected.
Second, even if the sparse pattern list is empty, an additional call to
the function that matches files against the pattern would take additional
runtime.
If I had time, I could think of a third reason.
Ciao,
Dscho
^ permalink raw reply
* Re: sparse support in pu
From: Johannes Sixt @ 2009-08-17 9:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: skillzero, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.DEB.1.00.0908171113420.4991@intel-tinevez-2-302>
Johannes Schindelin schrieb:
> On Mon, 17 Aug 2009, skillzero@gmail.com wrote:
>> On Mon, Aug 17, 2009 at 1:17 AM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
>>> On Mon, Aug 17, 2009 at 1:09 PM, <skillzero@gmail.com> wrote:
>>>> 1. Have people decided whether it should be on by default if you have
>>>> a .git/info/sparse file? I'd definitely like it to be on by
>>>> default. When I first tried it, I didn't realize I had to use
>>>> --sparse to git checkout to get it to use the sparse rules. The
>>>> same goes for a merge I did that happened to have a file in the
>>>> excluded area (it included it because I didn't use --sparse to git
>>>> merge).
>>> I tend to make it enabled by default too. I have made it stricter to
>>> trigger reading sparse in unpack_trees() -- only do it when
>>> unpack_opts.update is TRUE. This should make it safer to be enabled by
>>> default.
>> Other than it being new and not-widely-tested code, is there any
>> additional risk to having it enabled by default if there are no sparse
>> patterns defined?
>
> I think that in and of itself is reason enough to turn off the feature
> when .git/info/sparse is not present.
I might have missed something: Would there be any observable difference
between whether .git/info/sparse is absent and whether it is empty? If
not, what do you mean by "turn the feature off"?
>> It would be nice if .git/info/sparse is there by default (like
>> .git/info/exclude) with some commented out instructions (also like
>> .git/info/exclude).
>
> I'm not a fan of this idea.
For any particular reason?
-- Hannes
^ permalink raw reply
* Re: sparse support in pu
From: skillzero @ 2009-08-17 9:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.DEB.1.00.0908171113420.4991@intel-tinevez-2-302>
On Mon, Aug 17, 2009 at 2:15 AM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 17 Aug 2009, skillzero@gmail.com wrote:
>
>> On Mon, Aug 17, 2009 at 1:17 AM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
>> > On Mon, Aug 17, 2009 at 1:09 PM, <skillzero@gmail.com> wrote:
>> >> 1. Have people decided whether it should be on by default if you have
>> >> a .git/info/sparse file? I'd definitely like it to be on by
>> >> default. When I first tried it, I didn't realize I had to use
>> >> --sparse to git checkout to get it to use the sparse rules. The
>> >> same goes for a merge I did that happened to have a file in the
>> >> excluded area (it included it because I didn't use --sparse to git
>> >> merge).
>> >
>> > I tend to make it enabled by default too. I have made it stricter to
>> > trigger reading sparse in unpack_trees() -- only do it when
>> > unpack_opts.update is TRUE. This should make it safer to be enabled by
>> > default.
>>
>> Other than it being new and not-widely-tested code, is there any
>> additional risk to having it enabled by default if there are no sparse
>> patterns defined?
>
> I think that in and of itself is reason enough to turn off the feature
> when .git/info/sparse is not present.
>
> It also may have a runtime cost, dunno.
I was thinking that it would effectively do this:
Try to read .git/info/sparse
if valid patterns read
Sparse is enabled
else (e.g. file missing or nothing but empty lines/comments)
Sparse is disabled
I wouldn't think there would be any additional cost or risk (other
than the extra code to read the .git/info/sparse file) because the
result is the same as if sparse had been disabled by being defaulted
to off since even in the default off case, it's still a runtime check.
I would think --sparse would really only be useful as a way to negate
--no-sparse (i.e. act as if .git/info/sparse didn't exist
temporarily).
^ permalink raw reply
* Re: sparse support in pu
From: Johannes Schindelin @ 2009-08-17 9:15 UTC (permalink / raw)
To: skillzero; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <2729632a0908170149o425544dcw52aeb6ac6ee1437d@mail.gmail.com>
Hi,
On Mon, 17 Aug 2009, skillzero@gmail.com wrote:
> On Mon, Aug 17, 2009 at 1:17 AM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
> > On Mon, Aug 17, 2009 at 1:09 PM, <skillzero@gmail.com> wrote:
> >> 1. Have people decided whether it should be on by default if you have
> >> a .git/info/sparse file? I'd definitely like it to be on by
> >> default. When I first tried it, I didn't realize I had to use
> >> --sparse to git checkout to get it to use the sparse rules. The
> >> same goes for a merge I did that happened to have a file in the
> >> excluded area (it included it because I didn't use --sparse to git
> >> merge).
> >
> > I tend to make it enabled by default too. I have made it stricter to
> > trigger reading sparse in unpack_trees() -- only do it when
> > unpack_opts.update is TRUE. This should make it safer to be enabled by
> > default.
>
> Other than it being new and not-widely-tested code, is there any
> additional risk to having it enabled by default if there are no sparse
> patterns defined?
I think that in and of itself is reason enough to turn off the feature
when .git/info/sparse is not present.
It also may have a runtime cost, dunno.
> It would be nice if .git/info/sparse is there by default (like
> .git/info/exclude) with some commented out instructions (also like
> .git/info/exclude).
I'm not a fan of this idea.
> >> 3. One thing that was confusing is that I needed a trailing slash on
> >> directories in .git/info/sparse to get them excluded. This seems
> >> different than .gitignore, which works for me without the trailing
> >> slash.
> >
> > Hmm.. probably because Git feeds directories to .gitignore handling
> > functions. There is not much I can do, index does not have
> > directories. I don't know if it's worth generating "directories" from
> > index.
>
> Maybe just add a note in the documentation? If there's a default
> .git/info/sparse file then it might be good place to put a note as well.
I rather think that this should be fixed. Maybe you can come up with a
patch to the tests which shows this behavior (with test_expect_failure)?
Then it will be much easier to come up with a fix.
Ciao,
Dscho
^ permalink raw reply
* Re: [msysGit] quick question about __stdcall at run-command.c mingw.c
From: Johannes Schindelin @ 2009-08-17 9:12 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Pat Thoyts, Frank Li, git, msysGit
In-Reply-To: <4A891840.4050403@viscovery.net>
Hi,
On Mon, 17 Aug 2009, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > On Mon, 17 Aug 2009, Johannes Sixt wrote:
> >> Pat Thoyts schrieb:
> >>> 2009/8/17 Frank Li <lznuaa@gmail.com>:
> >>>> I am tring to clear VC build patch.
> >>>>
> >>>> I found __stdcall position break MSVC build.
> >>>>
> >>>> static __stdcall unsigned run_thread(void *data)
> >>>>
> >>>> MSVC require __stdcall should be between return type and function
> >>>> name. like static unsigned __stdcall run_thread(void *data)
> >>>>
> >>>> I think msys gcc should support MSVC format.
> >
> > I think that it does.
> >
> > But it is _your_ duty to check.
>
> Cool down. Asking for "please could you check whether this works" *if*
> you don't have the infrastructure to test it yourself is certainly
> dutyful enough.
>
> Do you have an Irix, Solaris, HP box on your desk next to your Linux, so
> that you don't have to ask others to test your patches?
This is Windows. Frank has Windows.
Downloading msysGit does not incur any cost. Actually running the whole
thing from the net installer just takes a little time and a two-digit
megabyte download.
I put a lot of work into making this procedure as painless to use (for
other people, it caused me a lot of pain). So Frank might just as well
not let my effort go to hell.
Of course, Frank could ask one of the few msysGit contributors to try to
compile something he prepared, wait for the results and possibly fix
things for another round. This appears as a rather poor use of
everybody's time, methinks.
Ciao,
Dscho
^ permalink raw reply
* Re: git http-push and MKCOL error (22/409)
From: Tay Ray Chuan @ 2009-08-17 9:09 UTC (permalink / raw)
To: Thomas Schlichter; +Cc: Junio C Hamano, willievu, Sean Davis, git
In-Reply-To: <200908170725.09592.thomas.schlichter@web.de>
Hi,
On Mon, Aug 17, 2009 at 1:25 PM, Thomas Schlichter<thomas.schlichter@web.de> wrote:
> Hmm. I hope you won't take this as an argument for not fixing it, because it
> is a clear regression! I tried git version 1.6.3.4, and it works flawlessly
> with exactly this server! Even during bisecting, some versions worked, some
> didn't (these after the mentioned commit...)
>
> So I think this commit didn't only refactor things, but unintentionally
> changed the behavior. And this must be the problem. As I'm not into this code,
> and the refactoring was not completely trivial, I was not able to quickly find
> the place where the behavior was changed...
Thomas, indeed you're right about this, the commit you noted in your
earlier email (5424bc5) was indeed at fault.
The commit changed how urls was handled, and resulted (incorrectly) in
an extra slash being added to the url. In other words, urls now look
like this:
http://server/repo.git//objects/2a/
This problem occurs only in http-push.c, because repo urls
(http://server/repo.git) are always made to end with a slash there.
Btw, on my Apache 2.2.x server, this didn't crop up when I tested,
while Thomas worked with a 2.0.x.
I've attached a patch below that hopefully fixes it.
-- >8 --
Subject: [PATCH] http.c: don't assume that urls don't end with slash
Make append_remote_object_url() (and by implication,
get_remote_object_url) use end_url_with_slash() to ensure that the url
ends with a slash.
Previously, they assumed that the url did not end with a slash and
as a result appended a slash, sometimes errorneously.
This fixes an issue introduced in 5424bc5 ("http*: add helper methods
for fetching objects (loose)"), where the append_remote_object_url()
implementation in http-push.c, which assumed that urls end with a
slash, was replaced by another one in http.c, which assumed urls did
not end with a slash.
The above issue was raised by Thomas Schlichter:
http://marc.info/?l=git&m=125043105231327
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
http.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/http.c b/http.c
index 14d5357..eb0c669 100644
--- a/http.c
+++ b/http.c
@@ -719,7 +719,9 @@ void append_remote_object_url(struct strbuf *buf, const char *url,
const char *hex,
int only_two_digit_prefix)
{
- strbuf_addf(buf, "%s/objects/%.*s/", url, 2, hex);
+ end_url_with_slash(buf, url);
+
+ strbuf_addf(buf, "objects/%.*s/", 2, hex);
if (!only_two_digit_prefix)
strbuf_addf(buf, "%s", hex+2);
}
--
1.6.4.dirty
^ permalink raw reply related
* Re: [RFC PATCH v3 8/8] --sparse for porcelains
From: Johannes Schindelin @ 2009-08-17 9:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.DEB.1.00.0908161002460.8306@pacific.mpi-cbg.de>
Hi,
On Sun, 16 Aug 2009, Johannes Schindelin wrote:
> [...] if you want to say that assume-unchanged and sparse are two
> fundamentally different things, I would be interested in some equally
> convincing argument as for the shallow/graft issue.
>
> There is a fundamental difference, I grant you that: the working
> directory does not contain the "sparse'd away" files while the same is
> not true for assume-unchanged files.
>
> But does that matter? The corresponding files are still in the index
> and the repository.
>
> IOW under what circumstances would you want to be able to discern
> between assume-unchanged and "sparse'd away" files in the working
> directory?
>
> I could _imagine_ that you'd want a tool that allows you to change the
> focus of the sparse checkout together with the working directory.
> Example: you have a sparse checkout of Documentation/ and now you want
> to have t/, too. Just changing .git/info/sparse will not be enough.
>
> The question is if the tool to change the "sparseness" [*1*] should not
> change .git/info/sparse itself; if it does not, it would be good to be
> able to discern between the "assume-unchanged" and "sparse'd away"
> files.
>
> Although it might be enough to traverse the index and check the presence
> of the assume-unchanged files in the working directory to determine
> which files are sparse, and which ones are merely assume-unchanged.
>
> Ciao,
> Dscho
>
> Footnote [*1*]: I think we need some nice and clear nomenclature here.
> Any English wizards with a good taste of naming things?
Turns out that somebody on IRC had a problem that requires to have
sparse'd out files which _do_ have working directory copies.
So just having the assume-changed bit may not be enough.
The scenario is this: the repository contains a file that users are
supposed to change, but not commit to (only the super-intelligent inventor
of this scenario is allowed to). As this repository is originally a
subversion one, there is no problem: people just do not switch branches.
But this guy uses git-svn, so he does switch branches, and to avoid
committing the file by mistake, he marked it assume-unchanged. Only that
a branch switch overwrites the local changes.
I suggested the use of the sparse feature, and mark this file (and this
file alone) as sparse'd-out.
Is this an intended usage scenario? Then we cannot reuse the
assume-changed bit [*1*].
Ciao,
Dscho
Footnote [*1*]: in this particular scenario, we could still discern
between sparse'd-out and regular assume-unchanged file, because
.git/info/sparse knows about the file. But the design is now brittle, and
it is not hard at all to come up with a situation where it breaks.
^ permalink raw reply
* Re: [PATCH 8/9] git status: not "commit --dry-run" anymore
From: Thomas Rast @ 2009-08-17 8:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1250375997-10657-9-git-send-email-gitster@pobox.com>
Junio C Hamano wrote:
> This removes tentative "git stat" and make it take over "git status".
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> * This alone fails some tests; 9/9 will be squashed in in the final round.
>
> Documentation/git-status.txt | 79 ++++++++++++++++++++++++++++++++++++-----
> builtin-commit.c | 29 ++-------------
> builtin.h | 1 -
> git.c | 1 -
> 4 files changed, 73 insertions(+), 37 deletions(-)
[...]
> - { "stat", cmd_stat, RUN_SETUP | NEED_WORK_TREE },
> { "status", cmd_status, RUN_SETUP | NEED_WORK_TREE },
This lacks a corresponding update to the Makefile:
diff --git i/Makefile w/Makefile
index f384a52..8a7509c 100644
--- i/Makefile
+++ w/Makefile
@@ -383,7 +383,6 @@ BUILT_INS += git-init$X
BUILT_INS += git-merge-subtree$X
BUILT_INS += git-peek-remote$X
BUILT_INS += git-repo-config$X
-BUILT_INS += git-stat$X
BUILT_INS += git-show$X
BUILT_INS += git-stage$X
BUILT_INS += git-status$X
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* Re: sparse support in pu
From: skillzero @ 2009-08-17 8:49 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0908170117v67e9f8b1ga56edcda14821e91@mail.gmail.com>
On Mon, Aug 17, 2009 at 1:17 AM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
> On Mon, Aug 17, 2009 at 1:09 PM, <skillzero@gmail.com> wrote:
>> 1. Have people decided whether it should be on by default if you have
>> a .git/info/sparse file? I'd definitely like it to be on by default.
>> When I first tried it, I didn't realize I had to use --sparse to git
>> checkout to get it to use the sparse rules. The same goes for a merge
>> I did that happened to have a file in the excluded area (it included
>> it because I didn't use --sparse to git merge).
>
> I tend to make it enabled by default too. I have made it stricter to
> trigger reading sparse in unpack_trees() -- only do it when
> unpack_opts.update is TRUE. This should make it safer to be enabled by
> default.
Other than it being new and not-widely-tested code, is there any
additional risk to having it enabled by default if there are no sparse
patterns defined?
It would be nice if .git/info/sparse is there by default (like
.git/info/exclude) with some commented out instructions (also like
.git/info/exclude).
>> 2. Is it not hooked up to git reset yet? I did a git checkout --sparse
>> and things look liked I expected then I did a git reset --hard
>> origin/master and it started checking out all the stuff previously
>> excluded via .git/info/sparse. I tried --sparse, but it didn't know
>> about that option.
>
> Because sparse was disabled by default, and "git reset" did not enable
> it. It'd be interesting to see what "git reset --hard" should do in
> this case: will it apply .git/info/sparse or not, which brings us back
> to the "default or not" question, hmm..
It seems like if it's going to be off by default (which it hopefully
won't be) then git reset would need to support --sparse since
otherwise, you'd never be able to git reset without undoing your
sparse options (unless you did a subsequent git checkout --sparse).
I also noticed that after I did the git reset, the sparse stuff seemed
to get into a weird state such that sparse patterns weren't working
reliably. For example, I couldn't get it to exclude a directory.
>> 3. One thing that was confusing is that I needed a trailing slash on
>> directories in .git/info/sparse to get them excluded. This seems
>> different than .gitignore, which works for me without the trailing
>> slash.
>
> Hmm.. probably because Git feeds directories to .gitignore handling
> functions. There is not much I can do, index does not have
> directories. I don't know if it's worth generating "directories" from
> index.
Maybe just add a note in the documentation? If there's a default
.git/info/sparse file then it might be good place to put a note as
well.
^ permalink raw reply
* Re: [msysGit] quick question about __stdcall at run-command.c mingw.c
From: Johannes Sixt @ 2009-08-17 8:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pat Thoyts, Frank Li, git, msysGit
In-Reply-To: <alpine.DEB.1.00.0908171018490.4991@intel-tinevez-2-302>
Johannes Schindelin schrieb:
> On Mon, 17 Aug 2009, Johannes Sixt wrote:
>> Pat Thoyts schrieb:
>>> 2009/8/17 Frank Li <lznuaa@gmail.com>:
>>>> I am tring to clear VC build patch.
>>>>
>>>> I found __stdcall position break MSVC build.
>>>>
>>>> static __stdcall unsigned run_thread(void *data)
>>>>
>>>> MSVC require __stdcall should be between return type and function
>>>> name. like static unsigned __stdcall run_thread(void *data)
>>>>
>>>> I think msys gcc should support MSVC format.
>
> I think that it does.
>
> But it is _your_ duty to check.
Cool down. Asking for "please could you check whether this works" *if* you
don't have the infrastructure to test it yourself is certainly dutyful enough.
Do you have an Irix, Solaris, HP box on your desk next to your Linux, so
that you don't have to ask others to test your patches?
-- Hannes
^ permalink raw reply
* Re: Linus' sha1 is much faster!
From: Andreas Ericsson @ 2009-08-17 8:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: John Tapsell, Bryan Donlan, Pádraig Brady, Bug-coreutils,
Git Mailing List, Brandon Casey, Junio C Hamano, Nicolas Pitre,
Paul Kocher, Paul Kocher
In-Reply-To: <alpine.LFD.2.01.0908151336530.3162@localhost.localdomain>
Linus Torvalds wrote:
>
> On Sat, 15 Aug 2009, Linus Torvalds wrote:
>> That said, I don't know if the MPL is ok for X11. I've not looked at
>> compatibility issues with MPL. For git, we could just ignore the MPL,
>> since the GPLv2 was acceptable regardless of it.
>
> If MPL isn't ok for X11, then we'd need to make sure that even the
> silliest Mozilla crud has been rewritten. There really isn't much, but
> hey, the _history_ is based on the mozilla code, and who knows - the
> 'blk_SHA_CTX' struct has things like the fields in the same order as the
> Mozilla equivalent, for all those historical reasons.
>
> (Heh. Looking at that, I probably should move the 'size' field first,
> since that would have different alignment rules, and the struct would be
> more tightly packed that way, and initialize better).
>
> Afaik, none of the actual code remains (the mozilla SHA1 thing did the
> wrong thing for performance even for just the final bytes, and did those a
> byte at a time etc, so I rewrote even the trivial SHA1_Final parts).
>
> Of course, maybe the Mozilla people would be interested in taking my
> faster version, and say that the new-BSD license is ok, and make everybody
> happy. The only listed author for the Mozilla SHA1 is Paul Kocher. I added
> him to the Cc.
>
> Paul, for your information, we're talking about a faster rewritten "mostly
> portable" SHA1 routines that you can find at
>
> http://git.kernel.org/?p=git/git.git;a=tree;f=block-sha1;hb=pu
>
> (follow the "blob" pointers to see sha1.c and sha1.h). I don't know if
> you're active with Mozilla/Firefox or whether you even care, but you seem
> to be the logical choice of person to ask.
>
I contacted Paul in february this year to get permission to use the mozilla
sha1 code for libgit2. His reply then was:
"I'm not sure which version the diffs are relative to, so I haven't reviewed them.
It's fine to distribute under BSD, GPL, or LGPL, however."
I also got explicit permission to relicense it under GPLv2 with the gcc exception.
I added the mail-address I used to contact him to CC as well. Sorry if you get
this twice, Paul.
Naturally, I'd like to use the faster version for libgit2 as well. The people
who Linus listed as contributors earlier (Brandon Casy, Linus, Junio and Nicolas
Pitre) have already consented to relicense their git contributions for libgit2
use. If anyone would like to revoke that consent for this code, speak now please,
or I'll patch it into libgit2 as well.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [msysGit] quick question about __stdcall at run-command.c mingw.c
From: Johannes Schindelin @ 2009-08-17 8:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Pat Thoyts, Frank Li, git, msysGit
In-Reply-To: <4A890C32.6010507@viscovery.net>
Hi,
On Mon, 17 Aug 2009, Johannes Sixt wrote:
> Pat Thoyts schrieb:
> > 2009/8/17 Frank Li <lznuaa@gmail.com>:
> >> I am tring to clear VC build patch.
> >>
> >> I found __stdcall position break MSVC build.
> >>
> >> static __stdcall unsigned run_thread(void *data)
> >>
> >> MSVC require __stdcall should be between return type and function
> >> name. like static unsigned __stdcall run_thread(void *data)
> >>
> >> I think msys gcc should support MSVC format.
I think that it does.
But it is _your_ duty to check.
> >> Should I directly change to MSVC format or add _MSC_VER marcro like
> >>
> >> #if defined(__MINGW32__)
> >> static __stdcall unsigned run_thread(void *data)
> >> #elif defined(_MSC_VER) /*MSVC must put __stdcall between return value
> >> and function*/
> >> static unsigned __stdcall run_thread(void *data)
> >> #endif
Noooo! NO _MSC_VER crap in mingw.c. Really. I am able to repeat that as
often as you want me, but I'd prefer not to.
> > The win32 api prototype used for thread entry functions is declared as
> > a DWORD (WINAPI *LPTHREAD_START_ROUTINE)(LPVOID) type in the mingw
> > headers and WINAPI as #define WINAPI __stdcall. This is true for the
> > MSVC headers as well. So gcc and msvc are happy using the same
> > definition for such a function and just "static unsigned long WINAPI
> > run_thread(void *)" might well be sensible.
>
> Change the code to
>
> static unsigned __stdcall run_thread(void *data)
>
> The documentation explictly says: "The routine at start_address passed to
> _beginthreadex must use the __stdcall calling convention...". So __stdcall
> it is.
I could not agree more.
Ciao,
Dscho
^ permalink raw reply
* Re: sparse support in pu
From: Nguyen Thai Ngoc Duy @ 2009-08-17 8:17 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0908162309ma6e7d41kc3bafe4575120630@mail.gmail.com>
On Mon, Aug 17, 2009 at 1:09 PM, <skillzero@gmail.com> wrote:
> 1. Have people decided whether it should be on by default if you have
> a .git/info/sparse file? I'd definitely like it to be on by default.
> When I first tried it, I didn't realize I had to use --sparse to git
> checkout to get it to use the sparse rules. The same goes for a merge
> I did that happened to have a file in the excluded area (it included
> it because I didn't use --sparse to git merge).
I tend to make it enabled by default too. I have made it stricter to
trigger reading sparse in unpack_trees() -- only do it when
unpack_opts.update is TRUE. This should make it safer to be enabled by
default.
> 2. Is it not hooked up to git reset yet? I did a git checkout --sparse
> and things look liked I expected then I did a git reset --hard
> origin/master and it started checking out all the stuff previously
> excluded via .git/info/sparse. I tried --sparse, but it didn't know
> about that option.
Because sparse was disabled by default, and "git reset" did not enable
it. It'd be interesting to see what "git reset --hard" should do in
this case: will it apply .git/info/sparse or not, which brings us back
to the "default or not" question, hmm..
> 3. One thing that was confusing is that I needed a trailing slash on
> directories in .git/info/sparse to get them excluded. This seems
> different than .gitignore, which works for me without the trailing
> slash.
Hmm.. probably because Git feeds directories to .gitignore handling
functions. There is not much I can do, index does not have
directories. I don't know if it's worth generating "directories" from
index.
--
Duy
^ permalink raw reply
* Re: [PATCH 0/6 (v2)] Suggested for PU: revision caching system to significantly speed up packing/walking
From: Johannes Schindelin @ 2009-08-17 8:16 UTC (permalink / raw)
To: Nick Edelen
Cc: Sam Vilain, Junio C Hamano, Nicolas Pitre, Michael J Gruber,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <c77435a80908161756n88eb967wbc82058fc4975c04@mail.gmail.com>
Hi,
On Mon, 17 Aug 2009, Nick Edelen wrote:
> If I'm being confusing I can just upload them to v3, but I didn't want
> to bombard everyone with duplicates.
I think by now people _are_ confused, so it's probably better to "bomb"
everyone with a clean current version of your patch series.
Although I have to admit that I am scared away by the sheer size of the
individual patches (together with bad feelings from earlier discussions
that I want to avoid).
Ciao,
Dscho
^ permalink raw reply
* Re: "make quick-install-man" broke recently
From: Junio C Hamano @ 2009-08-17 8:02 UTC (permalink / raw)
To: Johannes Sixt
Cc: Jacob Helwig, Linus Torvalds, Kjetil Barvik, Randal L. Schwartz,
git@vger.kernel.org
In-Reply-To: <4A890E09.9010507@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Junio C Hamano schrieb:
>> check_path(): allow symlinked directories to checkout-index --prefix
>
>> +test_expect_success 'checkout-index -f twice with --prefix' '
>
> Please add SYMLINKS prerequisite before you publish this test case.
>
>> + mkdir -p tar/get &&
>> + ln -s tar/get there &&
>> + echo first &&
>> + git checkout-index -a -f --prefix=there/ &&
>> + echo second &&
>> + git checkout-index -a -f --prefix=there/
>> +'
Heh, I am not sure if the fix is the best approach to begin with yet ;-)
^ permalink raw reply
* Re: "make quick-install-man" broke recently
From: Johannes Sixt @ 2009-08-17 8:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jacob Helwig, Linus Torvalds, Kjetil Barvik, Randal L. Schwartz,
git@vger.kernel.org
In-Reply-To: <7vhbw72ap3.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> check_path(): allow symlinked directories to checkout-index --prefix
> +test_expect_success 'checkout-index -f twice with --prefix' '
Please add SYMLINKS prerequisite before you publish this test case.
> + mkdir -p tar/get &&
> + ln -s tar/get there &&
> + echo first &&
> + git checkout-index -a -f --prefix=there/ &&
> + echo second &&
> + git checkout-index -a -f --prefix=there/
> +'
Thanks,
-- Hannes
^ permalink raw reply
* Re: [msysGit] quick question about __stdcall at run-command.c mingw.c
From: Johannes Sixt @ 2009-08-17 7:52 UTC (permalink / raw)
To: Pat Thoyts, Frank Li; +Cc: git, msysGit
In-Reply-To: <a5b261830908161703l2296448l698d07d01ae8a6d3@mail.gmail.com>
Pat Thoyts schrieb:
> 2009/8/17 Frank Li <lznuaa@gmail.com>:
>> I am tring to clear VC build patch.
>>
>> I found __stdcall position break MSVC build.
>>
>> static __stdcall unsigned run_thread(void *data)
>>
>> MSVC require __stdcall should be between return type and function name.
>> like
>> static unsigned __stdcall run_thread(void *data)
>>
>> I think msys gcc should support MSVC format.
>>
>> Should I directly change to MSVC format or add _MSC_VER marcro like
>>
>> #if defined(__MINGW32__)
>> static __stdcall unsigned run_thread(void *data)
>> #elif defined(_MSC_VER) /*MSVC must put __stdcall between return value
>> and function*/
>> static unsigned __stdcall run_thread(void *data)
>> #endif
>
> The win32 api prototype used for thread entry functions is declared as
> a DWORD (WINAPI *LPTHREAD_START_ROUTINE)(LPVOID) type in the mingw
> headers and WINAPI as #define WINAPI __stdcall. This is true for the
> MSVC headers as well. So gcc and msvc are happy using the same
> definition for such a function and just "static unsigned long WINAPI
> run_thread(void *)" might well be sensible.
Change the code to
static unsigned __stdcall run_thread(void *data)
The documentation explictly says: "The routine at start_address passed to
_beginthreadex must use the __stdcall calling convention...". So __stdcall
it is.
-- Hannes
^ permalink raw reply
* Re: How to stop sharing objects between repositories
From: Jeff King @ 2009-08-17 7:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Galbraith, Johannes Schindelin, Jon Jensen, git
In-Reply-To: <7v1vna3nae.fsf@alter.siamese.dyndns.org>
On Mon, Aug 17, 2009 at 12:35:53AM -0700, Junio C Hamano wrote:
> > Did you miss the part where I asked "should we include instructions to
> > the user on how to fix this"?
>
> Actually, I didn't. It is very hard to lose data once you put it in git;
> "by following recovery insn the user can redo" is often trivially correct
> thanks to it.
>
> But it is not a very good option to cause the damage and then give
> recovery insn. The user might have ran out of quota, and even if he
> didn't, he wasted needless cycles for the unwanted sort of repacking.
OK, let's forget the warning, then. Hopefully between the note under
"clone -s" and the fact that most people should be using "git gc" these
days, it won't be a big issue.
-Peff
^ permalink raw reply
* Re: How to stop sharing objects between repositories
From: Junio C Hamano @ 2009-08-17 7:35 UTC (permalink / raw)
To: Jeff King; +Cc: Mike Galbraith, Johannes Schindelin, Jon Jensen, git
In-Reply-To: <20090817072559.GA9730@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> But I can tell you that this "just warn" cannot be a good idea for a very
>> simple reason: breaking and then warning is useless---it is too late for
>> the user to do anything about it.
>
> Did you miss the part where I asked "should we include instructions to
> the user on how to fix this"?
Actually, I didn't. It is very hard to lose data once you put it in git;
"by following recovery insn the user can redo" is often trivially correct
thanks to it.
But it is not a very good option to cause the damage and then give
recovery insn. The user might have ran out of quota, and even if he
didn't, he wasted needless cycles for the unwanted sort of repacking.
^ permalink raw reply
* Re: How to stop sharing objects between repositories
From: Jeff King @ 2009-08-17 7:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Galbraith, Johannes Schindelin, Jon Jensen, git
In-Reply-To: <7v63cm3ntl.fsf@alter.siamese.dyndns.org>
On Mon, Aug 17, 2009 at 12:24:22AM -0700, Junio C Hamano wrote:
> > I'm torn on whether this is actually a good idea.
>
> I would understand if you were torn if the proposed change were to refuse
> to run without -l in a repository with alternates when --force is not
> given, or something of that nature.
>
> But I can tell you that this "just warn" cannot be a good idea for a very
> simple reason: breaking and then warning is useless---it is too late for
> the user to do anything about it.
Did you miss the part where I asked "should we include instructions to
the user on how to fix this"?
-Peff
^ permalink raw reply
* Re: How to stop sharing objects between repositories
From: Junio C Hamano @ 2009-08-17 7:24 UTC (permalink / raw)
To: Jeff King; +Cc: Mike Galbraith, Johannes Schindelin, Jon Jensen, git
In-Reply-To: <20090817064801.GA31543@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Aug 17, 2009 at 04:21:22AM +0200, Mike Galbraith wrote:
>
>> > (1) Such a user does not necessarily know a casual "git repack -a" breaks
>> > the dependency, defeating the -s option s/he deliberately used in
>> > order to save disk space in the first place. Perhaps we can reword
>> > this further to kill two penguins with a single stone?
>>
>> Perhaps a runtime warning that you're about to break it? This user may
>> not even be the one who set the thing up, no?
>
> I'm not really sure what such a setup would look like....
> ...
> That being said, I can see there being setups where such a warning might
> be useful. However, we don't really know if the user _wants_ that
> effect, or if it is an accident.
> ...
> "here is how you break the dependency" advice will also get the warning.
>
> I'm torn on whether this is actually a good idea.
I would understand if you were torn if the proposed change were to refuse
to run without -l in a repository with alternates when --force is not
given, or something of that nature.
But I can tell you that this "just warn" cannot be a good idea for a very
simple reason: breaking and then warning is useless---it is too late for
the user to do anything about it.
^ permalink raw reply
* Re: Linus' sha1 is much faster!
From: George Spelvin @ 2009-08-17 7:23 UTC (permalink / raw)
To: bdonlan, johnflux, P; +Cc: art.08.09, git, linux, nico, torvalds
If it helps anyone resolve license issues, here's a from-FIPS-180-2
implementation that's placed in the public domain. That should be
compatible with any license.
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?
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.
TODO: Check if an initial copy to w[] is faster on i386 (less register
pressure).
/*
* 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)
* - Nicilas Pitre (ARM)
*/
/* Cut here for sha1.h */
#include <stddef.h> /* For size_t */
#include <stdint.h> /* For uint32_t, uint64_t */
typedef struct SHA_context {
uint64_t len; /* May be shrunk to uint32_t */
uint32_t iv[5];
unsigned char buf[64]; /* Must be 32-bit aligned */
} SHA_CTX;
void SHA1_Init(struct SHA_context *c);
void SHA1_Update(struct SHA_context *c, void const *p, size_t n);
void SHA1_Final(unsigned char hash[20], struct SHA_context *c);
/* End of sha1.h */
#include <string.h> /* For memcpy() */
#include <arpa/inet.h> /* For ntohl() */
static void sha1_core(uint32_t iv[5], unsigned char const *p, size_t nblocks);
/* 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 */
static inline uint32_t get_be32(unsigned char const *p)
{
return ntohl(*(uint32_t const *)p);
}
static inline void put_be32(unsigned char const *p, uint32_t v)
{
*(uint32_t *)p = htonl(v);
}
#else
/* Unaligned access is not okay; do conversion as byte fetches */
static inline uint32_t get_be32(unsigned char const *p)
{
return p[0] << 24 || p[1] << 16 | p[8] << 8 | p[3];
}
static inline void put_be32(unsigned char const *p, uint32_t v)
{
p[0] = v >> 24;
p[1] = v >> 16;
p[2] = v >> 8;
p[3] = v;
}
#endif
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 */
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, 1);
n -= space;
p = (char const *)p + space;
}
/* The large middle piece */
if (n >> 6) {
sha1_core(c->iv, p, n >> 6);
p = (char const *)p + (n & -(size_t)64);
n &= 63;
}
pos = 0;
end:
/* Final partial block (may be zero size) */
memcpy(c->buf + pos, p, n);
}
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, 1);
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, 1);
/* 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 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)
/* 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 */
#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)
/* 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 source data. Not necessarily aligned.
* nblocks = Number of 64-byte blocks at p. Guaranteed non-zero.
*/
static void
sha1_core(uint32_t iv[5], unsigned char const *p, size_t nblocks)
{
uint32_t e = iv[4], d = iv[3], c = iv[2], b = iv[1], a = iv[0];
uint32_t w[16];
do {
uint32_t t;
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[4] = e += iv[4];
iv[3] = d += iv[3];
iv[2] = c += iv[2];
iv[1] = b += iv[1];
iv[0] = a += iv[0];
} while (--nblocks);
}
/* Compile with -DUNITTEST for self-tests */
#if UNITTEST
#include <stdio.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);
printf("Input: \"%.*s\"\n", len, 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 };
katest(text1, sizeof text1, hash1);
katest(text2, sizeof text2, hash2);
return 0;
}
#endif
^ 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