* Problems with format-patch UTF-8 and a missing second empty line
From: Ingo Ruhnke @ 2011-09-15 9:45 UTC (permalink / raw)
To: git
Creating a patch of a commit including UTF-8 and no empty second line,
like this:
mkdir foobar
cd foobar
git init
echo "Hello World" > file
git add file
git commit -m "ÄÖÜ
ÄÖÜ" file
git format-patch --root HEAD --stdout
Results in this:
From f4f889bad560c479a70fbf5f70a4239576001262 Mon Sep 17 00:00:00 2001
From: Ingo Ruhnke <grumbel@gmail.com>
Date: Thu, 15 Sep 2011 11:25:11 +0200
Subject: [PATCH] =?UTF-8?q?=C3=84=C3=96=C3=9C
=20=C3=84=C3=96=C3=9C?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
...
Trying to apply the patch then results in this:
$ git am /tmp/foobar/0001-.patch
Applying: =?UTF-8?q?=C3=84=C3=96=C3=9C
applying to an empty history
$ git log
commit 6f27fc51a8c52fdb595131a934d8d56c9df3b5c0
Author: Ingo Ruhnke <grumbel@gmail.com>
Date: Thu Sep 15 11:27:47 2011 +0200
=?UTF-8?q?=C3=84=C3=96=C3=9C
=20=C3=84=C3=96=C3=9C?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The UTF-8 stuff doesn't get decoded and the log message ends up broken.
The problem seems to already start with just the lack of an empty second line:
mkdir foobar
cd foobar
git init
echo "Hello World" > file
git add file
git commit -m "ABC
ABC" file
git format-patch --root HEAD --stdout
From 3abc0e59abc4c9343d22e79575e02910073d1013 Mon Sep 17 00:00:00 2001
From: Ingo Ruhnke <grumbel@gmail.com>
Date: Thu, 15 Sep 2011 11:31:03 +0200
Subject: [PATCH] ABC
ABC
$ git am /tmp/foobar/0001-ABC.patch
Applying: ABC ABC
applying to an empty history
ingo@duo:/tmp/5/bar$ git log | cat
commit eb8a9e9a1421ae6d930d99bfb8f2eab47349c387
Author: Ingo Ruhnke <grumbel@gmail.com>
Date: Thu Sep 15 11:31:03 2011 +0200
ABC ABC
Here the newline between ABC\nABC gets stripped out and replaced with
a space when transferring the commit with format-patch from one
repository to another.
Inserting an empty second line in the commit message makes both
problems go away.
Another small issue is that the filename of the patch will strip out
any UTF-8 characters, Thus a commit message of "123Äöü456" will result
in "0001-123-456.patch".
The problems happen with git version 1.7.4.1 (4b5eac7f0) on Ubuntu 11.04.
--
Blog: http://grumbel.blogspot.com/
JabberID: xmpp:grumbel@jabber.org
ICQ: 59461927
^ permalink raw reply
* Re: Anybody home?
From: Carlos Martín Nieto @ 2011-09-15 9:43 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Johannes Sixt, Git List
In-Reply-To: <CAOZxsTqGt=gYr3t7e5Ma4z6W9wt_JxrgsNSGFGVbtk2rc3LZ9w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]
On Thu, 2011-09-15 at 02:01 -0700, Joshua Stoutenburg wrote:
> > Reading your exchanges elsewhere in this thread, I think you missed that
> > you don't need a git server at all just to *use* git.
> >
> > Even when you want to exchange your commits between two or three machines,
> > all you need is ssh access. There is no *git server* necessary. git is not
> > svn. ;-)
> >
> > I thought I'd just mention this to help you streamline your search.
> >
> > -- Hannes
> >
>
> I read the first four and a half chapters from the Pro Git book pdf.
> So I think I understood that much.
>
> But in my situation, I do need a server so that other developers can
> access anytime over the internet.
If the code shouldn't be made public, then you should take a look at
gitolite[0]. Otherwise, you can just host it on gitorious.org or
github.com
[0] https://github.com/sitaramc/gitolite
cmn
>
> I should have mentioned that.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Anybody home?
From: Joshua Stoutenburg @ 2011-09-15 9:42 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Johannes Sixt, Git List
In-Reply-To: <201109150948.09040.trast@student.ethz.ch>
On Thu, Sep 15, 2011 at 12:48 AM, Thomas Rast <trast@student.ethz.ch> wrote:
> Johannes Sixt wrote:
>> Even when you want to exchange your commits between two or three machines,
>> all you need is ssh access. There is no *git server* necessary. git is not
>> svn. ;-)
>
> I'd even put this somewhat more bluntly. My two-step advice on
> switching from svn to git is:
>
> 1) forget *everything* you know from SVN
> 2) learn git as usual
>
> I don't hang out on IRC as much any more, so maybe it got better. But
> 90%[*] of SVN convert's problems seem to stem from some preconceived
> notions they carried over from SVN.
>
> Such as, "HEAD is the newest commit". Or the whole centralized
> vs. distributed you mentioned.
>
>
>
> [*] 78% of all statistics were made up on the spot
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
>
How can I "learn git as usual"?
I don't think I was on Subversion long enough to permanently damage my
brain. Only a few months (actually . . . that's probably enough). I
never used it's branching, tagging or merging features. Commit and
revert were the only that I used. Regardless, I'm happy to forget
everything I know about Subversion.
I've watched Linus Torvalds tech talk on git:
http://www.youtube.com/watch?v=4XpnKHJAok8
I also read four and a half chapters of Pro Git pdf:
http://progit.org/ebook/progit.pdf
I read and understood git for computer scientists:
http://eagain.net/articles/git-for-computer-scientists/
So I have a pretty good understanding why git is THE superior source
code management choice. And I have a basic understanding of how git
works. I know how to install a *nix server and can survive on the
CLI.
Here's where I think I'm having some troubles, and maybe you can help
me identify any others:
I got confused in Chapter 5 of the Pro Git pdf book, trying to discern
what needs to be done on the server, and what needs to be done on the
work station. The chapter seems to jump around a bit, and doesn't
follow a linear pattern. Maybe I need to read it more carefully?
Also, I'm not clear on the best way to manage large numbers of git
users (like 12-24), who also may have permissions to other services as
well (ftp, databases, email, etc). I have some hesitancy creating
each one manually on the CLI.
Finally, I'm not sure how to "learn git as usual". Point me in the
right direction, please.
^ permalink raw reply
* Re: git gc exit with out of memory, malloc failed error
From: Carlos Martín Nieto @ 2011-09-15 9:16 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Alexander Kostikov
In-Reply-To: <CA+sFfMdXLkSE_RXB28TSx0JpPVjwe1Rf+03TkiT2YJjYH7m9MQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Wed, 2011-09-14 at 21:29 -0500, Brandon Casey wrote:
> [resend since gmail's Rich formatting was enabled]
>
> On Wed, Sep 14, 2011 at 8:33 PM, Alexander Kostikov
> <alex.kostikov@gmail.com> wrote:
> >
> > I'm new to git and I'm getting the following out of memory error on git gc:
> >
> > $ git gc
> > Counting objects: 80818, done.
> > Delta compression using up to 8 threads.
> > fatal: Out of memory, malloc failed (tried to allocate 24359675 bytes)
> > error: failed to run repack
>
> Try reducing the number of threads that are used. You must have some
> pretty large objects if you have 24GB and ran out of memory. The
IIRC the 32-bit Windows builds limit each user process to 2GB. If
msysgit is built in 32-bit mode, it's possible (probable even, in order
to remain backwards-compatible) that it's hitting this limit, rather
than the physical limit of the machine. If it's using 8 threads, it
means that there are 256MB available for each thread.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Anybody home?
From: Joshua Stoutenburg @ 2011-09-15 9:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git List
In-Reply-To: <4E71A5FF.5040807@viscovery.net>
> Reading your exchanges elsewhere in this thread, I think you missed that
> you don't need a git server at all just to *use* git.
>
> Even when you want to exchange your commits between two or three machines,
> all you need is ssh access. There is no *git server* necessary. git is not
> svn. ;-)
>
> I thought I'd just mention this to help you streamline your search.
>
> -- Hannes
>
I read the first four and a half chapters from the Pro Git book pdf.
So I think I understood that much.
But in my situation, I do need a server so that other developers can
access anytime over the internet.
I should have mentioned that.
^ permalink raw reply
* Re: [PATCH 2/5] credential-cache: fix expiration calculation corner cases
From: Thomas Rast @ 2011-09-15 8:37 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Brian Gernhardt
In-Reply-To: <20110914191757.GB28267@sigill.intra.peff.net>
Jeff King wrote:
> However, there is a corner case: when we first start up, we
> have no credentials, and are waiting for a client to
> provide us with one. In this case, we ended up handing
> complete junk for the timeout argument to poll(). On some
> systems, this caused us to just wait a long time for the
> client (which usually showed up within a second or so). On
> OS X, however, the system quite reasonably complained about
> our junk value with EINVAL.
Tested, works now. Thanks!
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] t6019: avoid refname collision on case-insensitive systems
From: Thomas Rast @ 2011-09-15 8:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brad King, git
The criss-cross tests kept failing for me because of collisions of 'a'
with 'A' etc. Prefix the lowercase refnames with an extra letter to
disambiguate.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
This fixes the tests on OS X. Together with Peff's fix to the poll
issue, it now tests clean again.
t/t6019-rev-list-ancestry-path.sh | 19 +++++++++++--------
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/t/t6019-rev-list-ancestry-path.sh b/t/t6019-rev-list-ancestry-path.sh
index 738af73..39b4cb0 100755
--- a/t/t6019-rev-list-ancestry-path.sh
+++ b/t/t6019-rev-list-ancestry-path.sh
@@ -75,33 +75,36 @@ test_expect_success 'rev-list --ancestry-patch D..M -- M.t' '
# a X
# \ / \
# c---cb
+#
+# All refnames prefixed with 'x' to avoid confusion with the tags
+# generated by test_commit on case-insensitive systems.
test_expect_success 'setup criss-cross' '
mkdir criss-cross &&
(cd criss-cross &&
git init &&
test_commit A &&
- git checkout -b b master &&
+ git checkout -b xb master &&
test_commit B &&
- git checkout -b c master &&
+ git checkout -b xc master &&
test_commit C &&
- git checkout -b bc b -- &&
- git merge c &&
- git checkout -b cb c -- &&
- git merge b &&
+ git checkout -b xbc xb -- &&
+ git merge xc &&
+ git checkout -b xcb xc -- &&
+ git merge xb &&
git checkout master)
'
# no commits in bc descend from cb
test_expect_success 'criss-cross: rev-list --ancestry-path cb..bc' '
(cd criss-cross &&
- git rev-list --ancestry-path cb..bc > actual &&
+ git rev-list --ancestry-path xcb..xbc > actual &&
test -z "$(cat actual)")
'
# no commits in repository descend from cb
test_expect_success 'criss-cross: rev-list --ancestry-path --all ^cb' '
(cd criss-cross &&
- git rev-list --ancestry-path --all ^cb > actual &&
+ git rev-list --ancestry-path --all ^xcb > actual &&
test -z "$(cat actual)")
'
--
1.7.7.rc1.366.ge210a6
^ permalink raw reply related
* Re: [PATCH] for-each-ref: add split message parts to %(contents:*).
From: Michał Górny @ 2011-09-15 8:18 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Michael J Gruber
In-Reply-To: <20110907174044.GA11341@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 918 bytes --]
On Wed, 7 Sep 2011 13:40:44 -0400
Jeff King <peff@peff.net> wrote:
> On Fri, Sep 02, 2011 at 01:53:23PM -0400, Jeff King wrote:
>
> > But there may be other corner cases. I need to read through the
> > code more carefully, which I should have time to do later today.
>
> This ended up a little trickier than I expected, but I think the
> series below is what we should do. I tried to add extensive tests,
> but let me know if you can think of any other corner cases.
>
> [1/5]: t7004: factor out gpg setup
> [2/5]: t6300: add more body-parsing tests
> [3/5]: for-each-ref: refactor subject and body placeholder parsing
> [4/5]: for-each-ref: handle multiline subjects like --pretty
> [5/5]: for-each-ref: add split message parts to %(contents:*).
Thanks, it works great for me.
I tried multi-line subject + signature too and that works fine.
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: Anybody home?
From: Thomas Rast @ 2011-09-15 7:48 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Johannes Sixt, Git List
In-Reply-To: <4E71A5FF.5040807@viscovery.net>
Johannes Sixt wrote:
> Even when you want to exchange your commits between two or three machines,
> all you need is ssh access. There is no *git server* necessary. git is not
> svn. ;-)
I'd even put this somewhat more bluntly. My two-step advice on
switching from svn to git is:
1) forget *everything* you know from SVN
2) learn git as usual
I don't hang out on IRC as much any more, so maybe it got better. But
90%[*] of SVN convert's problems seem to stem from some preconceived
notions they carried over from SVN.
Such as, "HEAD is the newest commit". Or the whole centralized
vs. distributed you mentioned.
[*] 78% of all statistics were made up on the spot
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Anybody home?
From: Johannes Sixt @ 2011-09-15 7:15 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Git List
In-Reply-To: <CAOZxsTq1crC0zeMpFGMafG8HXu168gkK2-KDnpwLoamRLJshjg@mail.gmail.com>
Am 9/15/2011 6:24, schrieb Joshua Stoutenburg:
> Hey guys, I'm pretty stoked about git -- coming from subversion.
>
> I'm having a hard time understanding clearly how to set up a git
> server and configure my local machine to pull and push to it.
>
> I've been reading the git book pdf. But I think I must have missed
> something. I feel stranded.
Reading your exchanges elsewhere in this thread, I think you missed that
you don't need a git server at all just to *use* git.
Even when you want to exchange your commits between two or three machines,
all you need is ssh access. There is no *git server* necessary. git is not
svn. ;-)
I thought I'd just mention this to help you streamline your search.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/4] cleanup: use internal memory allocation wrapper functions everywhere
From: Johannes Sixt @ 2011-09-15 6:52 UTC (permalink / raw)
To: Brandon Casey; +Cc: peff, git, gitster, sunshine, bharrosh, trast, zapped
In-Reply-To: <1316051979-19671-3-git-send-email-drafnel@gmail.com>
Am 9/15/2011 3:59, schrieb Brandon Casey:
> The "x"-prefixed versions of strdup, malloc, etc. will check whether the
> allocation was successful and terminate the process otherwise.
>
> A few uses of malloc were left alone since they already implemented a
> graceful path of failure or were in a quasi external library like xdiff.
>
> Signed-off-by: Brandon Casey <drafnel@gmail.com>
> ---
> ...
> compat/mingw.c | 2 +-
> compat/qsort.c | 2 +-
> compat/win32/syslog.c | 2 +-
There is a danger that the high-level die() routine (which is used by the
x-wrappers) uses one of the low-level compat/ routines. IOW, in the case
of errors, recursion might occur. Therefore, I would prefer that the
compat/ routines do their own error reporting (preferably via return
values and errno).
-- Hannes
^ permalink raw reply
* Re: Helping on Git development
From: Andrew Ardill @ 2011-09-15 6:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Eduardo D'Avila
In-Reply-To: <20110915000851.GA6238@sigill.intra.peff.net>
On 15 September 2011 10:08, Jeff King <peff@peff.net> wrote:
> On Wed, Sep 14, 2011 at 04:34:38PM -0700, Junio C Hamano wrote:
>
>> > Is there such a thing as enough coders? :)
>>
>> Ever heard of the Mythical Man-Month ;-)?
>
> I thought git was a silver bullet. :)
>
>> I was simply saying that there already are many people who scratch his
>> own real itch, and we are short of the bandwidth to review them all.
>> It would not help the project at all to add more people who scratch
>> some random non-itches that nobody is actually interested in (e.g. an
>> entry in an unmaintained "bug tracker" that may list irrelevant and
>> stale non issues).
>
> Yeah, that may be. But I don't look at it as "we have enough
> itch-scratchers, so we don't need more". I see it as survival of the
> fittest. You may post a patch series that needs a lot of help, but
> nobody else cares, and it dies off. Or your series may be interesting
> enough that it draws attention, to the detriment of somebody else's
> series (which may take longer to get reviewed and merged). But natural
> selection only works if we have a diverse population to select from.
>
> The downside, of course, is that somebody may end up wasting time going
> down a fruitless road. But for a new contributor, hopefully they learn
> something in the process.
>
>> > 2. Read the list. People will report bugs. Try reproducing them,
>> [...]
>>
>> Yes. In the earlier steps in the above, you may find out that the
>> report was actually not a bug at all (e.g. old issue that has long
>> been fixed, pebcak, or wrong expectation), but even in such a case,
>> reporting your finding would help others.
>
> Very much agreed. I think big organizations like mozilla have people who
> do nothing but bug triage. We are not that big, but it has proven to be
> one area that is easy to break out and distribute to other people.
>
> -Peff
>
Does git even have an issue tracker? I have not seen one anywhere.
>> If you are looking to contribute to the project, a good place to start
>> is http://git-blame.blogspot.com/p/note-from-maintainer.html and in
>> Documentation/howto/maintain-git.txt
>
> I am moderately averse to hardcoding that URL that is guaranteed not to
> survive the maintainer change in our README file. The howto/maintain-git
> document mentions the periodical "A note from the maintainer" posting to
> the list that has the same text, which is a more appropriate reference.
Would a link to the wiki be more appropriate? Perhaps even a 'getting
started' page that collates information like this?
At the moment, while it is easy enough to find the information needed
to understand how the project fits together if you know where to look,
there isn't any concise summation of roles and pain points. The note
from the maintainer goes over the procedures fairly well, and the
what's cooking gives a good idea of what features are being worked on,
but it seems a little disconnected.
When kernel.org comes back online I may have a go at creating such a
page. Any thoughts?
Andrew
^ permalink raw reply
* Re: Anybody home?
From: Joshua Stoutenburg @ 2011-09-15 5:37 UTC (permalink / raw)
To: Alexander Kostikov; +Cc: Michael Witten, Git List
In-Reply-To: <CAGAhT3mo0qqU9WMgfM1vKjwMtjeb55LRG1QfEYhq7JwsBSGSEw@mail.gmail.com>
On Wed, Sep 14, 2011 at 10:19 PM, Alexander Kostikov
<alex.kostikov@gmail.com> wrote:
> If you don't mind spending $12 on documentation here is IMHO very good guide
> to git - http://peepcode.com/products/git-internals-pdf
> It contains some videos as well.
I'll definitely check it out. Not really looking for videos though.
I like things that are quiet, skim-able, and searchable.
^ permalink raw reply
* Re: Anybody home?
From: Alexander Kostikov @ 2011-09-15 5:21 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Michael Witten, Git List
In-Reply-To: <CAOZxsTr+mC9cajGa21d1sqKBEB+sUhsBOHoTuVj1D+6uTFTL6g@mail.gmail.com>
If you don't mind spending $12 on documentation here is IMHO very good
guide to git - http://peepcode.com/products/git-internals-pdf
It contains some videos as well.
On Wed, Sep 14, 2011 at 10:06 PM, Joshua Stoutenburg
<jehoshua02@gmail.com> wrote:
>
> Also, I noticed the entire kernel.org website is down. Any idea how
> long it's been like that or when/if it will come back up? What's
> Linus up to?
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-- Alexander Kostikov
^ permalink raw reply
* Re: Anybody home?
From: Joshua Stoutenburg @ 2011-09-15 5:06 UTC (permalink / raw)
To: Michael Witten; +Cc: Git List
In-Reply-To: <CAOZxsTrsi5mNdm8OgvfXyYwj1T4Vw3HfQGN-5Dsb+QnX0nz4ag@mail.gmail.com>
Also, I noticed the entire kernel.org website is down. Any idea how
long it's been like that or when/if it will come back up? What's
Linus up to?
^ permalink raw reply
* Re: Anybody home?
From: Joshua Stoutenburg @ 2011-09-15 5:04 UTC (permalink / raw)
To: Michael Witten; +Cc: Git List
In-Reply-To: <CAMOZ1BtpzsxGLzrZs2YbNP174mm3vfLCteencKSepDR329jjBQ@mail.gmail.com>
On Wed, Sep 14, 2011 at 9:48 PM, Michael Witten <mfwitten@gmail.com> wrote:
> On Thu, Sep 15, 2011 at 04:24, Joshua Stoutenburg <jehoshua02@gmail.com> wrote:
>> Hey guys, I'm pretty stoked about git -- coming from subversion.
>>
>> I'm having a hard time understanding clearly how to set up a git
>> server and configure my local machine to pull and push to it.
>>
>> I've been reading the git book pdf. But I think I must have missed
>> something. I feel stranded.
>>
>> Any help appreciated. Many thanks.
>
> Could you please ask a specific question about a specific issue of confusion?
>
There seems to be a plethora of documentation on git from various sources.
See what I mean:
http://git-scm.com/documentation
http://progit.org/book/
http://gitref.org/
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
http://www.kernel.org/pub/software/scm/git/docs/everyday.html
http://git-scm.com/course/svn.html
http://hoth.entp.com/output/git_for_designers.html
http://eagain.net/articles/git-for-computer-scientists/
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
http://www-cs-students.stanford.edu/~blynn/gitmagic/
http://help.github.com/
http://www.kernel.org/pub/software/scm/git/docs/
http://refcardz.dzone.com/refcardz/getting-started-git
Which source makes the least amount of assumptions and offers all the
juicy details for configuring git on the server, and git on the local
machine, without any fluff?
I'm looking for a solid guide. Not a novel. Not a pamphlet.
Being new to git, I can't tell which source to go with. Perhaps
someone with greater experience could point me in the right direction.
Thanks again.
--Josh
^ permalink raw reply
* Re: Anybody home?
From: Michael Witten @ 2011-09-15 4:48 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Git List
In-Reply-To: <CAOZxsTq1crC0zeMpFGMafG8HXu168gkK2-KDnpwLoamRLJshjg@mail.gmail.com>
On Thu, Sep 15, 2011 at 04:24, Joshua Stoutenburg <jehoshua02@gmail.com> wrote:
> Hey guys, I'm pretty stoked about git -- coming from subversion.
>
> I'm having a hard time understanding clearly how to set up a git
> server and configure my local machine to pull and push to it.
>
> I've been reading the git book pdf. But I think I must have missed
> something. I feel stranded.
>
> Any help appreciated. Many thanks.
Could you please ask a specific question about a specific issue of confusion?
^ permalink raw reply
* What's cooking in git.git (Sep 2011, #05; Wed, 14)
From: Junio C Hamano @ 2011-09-15 4:40 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
Here are the repositories that have my integration branches:
With maint, master, next, pu and todo:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
With only maint and master:
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
url = https://github.com/gitster/git
--------------------------------------------------
[New Topics]
* jk/maint-fetch-submodule-check-fix (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 3c73b8c)
+ fetch: avoid quadratic loop checking for updated submodules
(this branch is used by jk/argv-array.)
* bc/attr-ignore-case (2011-09-14) 5 commits
- attr: read core.attributesfile from git_default_core_config
- attr.c: respect core.ignorecase when matching attribute patterns
- builtin/mv.c: plug miniscule memory leak
- cleanup: use internal memory allocation wrapper functions everywhere
- attr.c: avoid inappropriate access to strbuf "buf" member
* jc/maint-fsck-fwrite-size-check (2011-09-11) 1 commit
- fsck: do not abort upon finding an empty blob
* jc/request-pull-show-head-2 (2011-09-13) 2 commits
- request-pull: state exact commit object name
- fetch: allow asking for an explicit commit object by name
* jk/argv-array (2011-09-14) 7 commits
- run_hook: use argv_array API
- checkout: use argv_array API
- bisect: use argv_array API
- quote: provide sq_dequote_to_argv_array
- refactor argv_array into generic code
- quote.h: fix bogus comment
- add sha1_array API docs
(this branch uses jk/maint-fetch-submodule-check-fix.)
* js/cred-macos-x-keychain-2 (2011-09-14) 1 commit
- contrib: add a pair of credential helpers for Mac OS X's keychain
(this branch uses jk/http-auth-keyring; is tangled with js/cred-macos-x-keychain.)
Welcome addition to build our confidence in the jk/http-auth-keyring topic.
--------------------------------------------------
[Stalled]
* jc/signed-push (2011-09-12) 7 commits
. push -s: support pre-receive-signature hook
. push -s: receiving end
. push -s: send signed push certificate
. push -s: skeleton
- Split GPG interface into its own helper library
- rename "match_refs()" to "match_push_refs()"
- send-pack: typofix error message
(this branch uses jc/run-receive-hook-cleanup; is tangled with jc/signed-push-3.)
This was the v2 that updated notes tree on the receiving end.
* jc/signed-push-3 (2011-09-12) 4 commits
- push -s: signed push
- Split GPG interface into its own helper library
- rename "match_refs()" to "match_push_refs()"
- send-pack: typofix error message
(this branch uses jc/run-receive-hook-cleanup; is tangled with jc/signed-push.)
This is the third edition, that moves the preparation of the notes tree to
the sending end.
* nd/maint-autofix-tag-in-head (2011-08-26) 3 commits
- Accept tags in HEAD or MERGE_HEAD
- merge: remove global variable head[]
- merge: keep stash[] a local variable
Probably needs a re-roll to aim a bit higher.
Not urgent; will not be in 1.7.7.
* jk/add-i-hunk-filter (2011-07-27) 5 commits
(merged to 'next' on 2011-08-11 at 8ff9a56)
+ add--interactive: add option to autosplit hunks
+ add--interactive: allow negatation of hunk filters
+ add--interactive: allow hunk filtering on command line
+ add--interactive: factor out regex error handling
+ add--interactive: refactor patch mode argument processing
Will be dropped.
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
* jm/mergetool-pathspec (2011-06-22) 2 commits
- mergetool: Don't assume paths are unmerged
- mergetool: Add tests for filename with whitespace
I think this is a good idea, but it probably needs a re-roll.
Cf. $gmane/176254 and 176255.
* jk/generation-numbers (2011-09-11) 8 commits
- metadata-cache.c: make two functions static
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
Perhaps 281eee4 (revision: keep track of the end-user input from the
command line, 2011-08-25) in bk/ancestry-path would help.
* po/cygwin-backslash (2011-08-05) 2 commits
- On Cygwin support both UNIX and DOS style path-names
- git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
Incomplete with respect to backslash processing in prefix_filename(), and
also loses the ability to escape glob specials. Perhaps drop?
--------------------------------------------------
[Cooking]
* rj/maint-t9159-svn-rev-notation (2011-09-13) 1 commit
- t9159-*.sh: t9159-*.sh: skip for mergeinfo test for svn <= 1.4
* tr/doc-note-rewrite (2011-09-13) 1 commit
- Documentation: basic configuration of notes.rewriteRef
Updated to a safer wording.
* jk/default-attr (2011-09-12) 1 commit
- attr: map builtin userdiff drivers to well-known extensions
Will be re-rolled after 1.7.7 final.
* ph/format-patch-no-color (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 20283e8)
+ format-patch: ignore ui.color
This fix for the recent regression probably should be in 1.7.7 final.
Will merge to "master" soonish.
* hl/iso8601-more-zone-formats (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 270f5c7)
+ date.c: Support iso8601 timezone formats
* jc/run-receive-hook-cleanup (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 68dd431)
+ refactor run_receive_hook()
(this branch is used by jc/signed-push and jc/signed-push-3.)
Just to make it easier to run a hook that reads from its standard input.
* jk/for-each-ref (2011-09-08) 5 commits
- for-each-ref: add split message parts to %(contents:*).
- for-each-ref: handle multiline subjects like --pretty
- for-each-ref: refactor subject and body placeholder parsing
- t6300: add more body-parsing tests
- t7004: factor out gpg setup
Will merge to "next".
* wh/normalize-alt-odb-path (2011-09-07) 1 commit
- sha1_file: normalize alt_odb path before comparing and storing
Will merge to "next".
* fk/use-kwset-pickaxe-grep-f (2011-09-11) 2 commits
- obstack.c: Fix some sparse warnings
- sparse: Fix an "Using plain integer as NULL pointer" warning
In general we would prefer to see these fixed at the upstream first, but
we have essentially forked from them at their last GPLv2 versions...
Will merge to "next".
* jc/make-static (2011-09-14) 4 commits
(merged to 'next' on 2011-09-14 at c5943ff)
+ exec_cmd.c: prepare_git_cmd() is sometimes used
+ environment.c: have_git_dir() has users on Cygwin
(merged to 'next' on 2011-09-11 at 2acb0af)
+ vcs-svn: remove unused functions and make some static
+ make-static: master
(this branch is tangled with jc/reflog-walk-use-only-nsha1.)
With a few fix-ups.
* rj/quietly-create-dep-dir (2011-09-11) 1 commit
(merged to 'next' on 2011-09-12 at 93d1c6b)
+ Makefile: Make dependency directory creation less noisy
* mh/check-ref-format (2011-09-11) 8 commits
- Add tools to avoid the use of unnormalized refnames.
- Do not allow ".lock" at the end of any refname component
- Add a library function normalize_refname()
- Change check_ref_format() to take a flags argument
- fixup asciidoc formatting
- git check-ref-format: add options --allow-onelevel and --refspec-pattern
- Change bad_ref_char() to return a boolean value
- t1402: add some more tests
Another reroll coming.
* mz/remote-rename (2011-09-11) 4 commits
- remote: only update remote-tracking branch if updating refspec
- remote rename: warn when refspec was not updated
- remote: "rename o foo" should not rename ref "origin/bar"
- remote: write correct fetch spec when renaming remote 'remote'
* cb/common-prefix-unification (2011-09-12) 3 commits
- rename pathspec_prefix() to common_prefix() and move to dir.[ch]
- consolidate pathspec_prefix and common_prefix
- remove prefix argument from pathspec_prefix
Will merge to "next".
* cb/send-email-help (2011-09-12) 1 commit
- send-email: add option -h
A separate set of patches to remove the hidden fully-spelled "help" from
other commands would be nice to have as companion patches as well.
Will merge to "next".
* jc/fetch-pack-fsck-objects (2011-09-04) 3 commits
(merged to 'next' on 2011-09-12 at a031347)
+ test: fetch/receive with fsckobjects
+ transfer.fsckobjects: unify fetch/receive.fsckobjects
+ fetch.fsckobjects: verify downloaded objects
We had an option to verify the sent objects before accepting a push but
lacked the corresponding option when fetching. In the light of the recent
k.org incident, a change like this would be a good addition.
* jc/fetch-verify (2011-09-01) 3 commits
(merged to 'next' on 2011-09-12 at 3f491ab)
+ fetch: verify we have everything we need before updating our ref
+ rev-list --verify-object
+ list-objects: pass callback data to show_objects()
(this branch uses jc/traverse-commit-list; is tangled with jc/receive-verify.)
During a fetch, we verify that the pack stream is self consistent,
but did not verify that the refs that are updated are consistent with
objects contained in the packstream, and this adds such a check.
* jc/receive-verify (2011-09-09) 6 commits
(merged to 'next' on 2011-09-12 at 856de78)
+ receive-pack: check connectivity before concluding "git push"
+ check_everything_connected(): libify
+ check_everything_connected(): refactor to use an iterator
+ fetch: verify we have everything we need before updating our ref
+ rev-list --verify-object
+ list-objects: pass callback data to show_objects()
(this branch uses jc/traverse-commit-list; is tangled with jc/fetch-verify.)
While accepting a push, we verify that the pack stream is self consistent,
but did not verify that the refs the push updates are consistent with
objects contained in the packstream, and this adds such a check.
* jn/maint-http-error-message (2011-09-06) 2 commits
(merged to 'next' on 2011-09-12 at a843f03)
+ http: avoid empty error messages for some curl errors
+ http: remove extra newline in error message
* bk/ancestry-path (2011-08-25) 3 commits
(merged to 'next' on 2011-09-02 at d05ba5d)
+ revision: do not include sibling history in --ancestry-path output
+ revision: keep track of the end-user input from the command line
+ rev-list: Demonstrate breakage with --ancestry-path --all
* mg/branch-list (2011-09-13) 7 commits
(merged to 'next' on 2011-09-14 at 6610a2e)
+ t3200: clean up checks for file existence
(merged to 'next' on 2011-09-11 at 20a9cdb)
+ branch: -v does not automatically imply --list
(merged to 'next' on 2011-09-02 at b818eae)
+ branch: allow pattern arguments
+ branch: introduce --list option
+ git-branch: introduce missing long forms for the options
+ git-tag: introduce long forms for the options
+ t6040: test branch -vv
* mm/rebase-i-exec-edit (2011-08-26) 2 commits
(merged to 'next' on 2011-09-02 at e75b1b9)
+ rebase -i: notice and warn if "exec $cmd" modifies the index or the working tree
+ rebase -i: clean error message for --continue after failed exec
* hv/submodule-merge-search (2011-08-26) 5 commits
- submodule: Search for merges only at end of recursive merge
- allow multiple calls to submodule merge search for the same path
- submodule: Demonstrate known breakage during recursive merge
- push: Don't push a repository with unpushed submodules
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
(this branch is tangled with fg/submodule-auto-push.)
The second from the bottom one needs to be replaced with a properly
written commit log message.
* mm/mediawiki-as-a-remote (2011-09-01) 2 commits
(merged to 'next' on 2011-09-12 at 163c6a5)
+ git-remote-mediawiki: allow push to set MediaWiki metadata
+ Add a remote helper to interact with mediawiki (fetch & push)
Fun.
* bc/unstash-clean-crufts (2011-08-27) 4 commits
(merged to 'next' on 2011-09-02 at 7bfd66f)
+ git-stash: remove untracked/ignored directories when stashed
+ t/t3905: add missing '&&' linkage
+ git-stash.sh: fix typo in error message
+ t/t3905: use the name 'actual' for test output, swap arguments to test_cmp
* da/make-auto-header-dependencies (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at e04a4af)
+ Makefile: Improve compiler header dependency check
(this branch uses fk/make-auto-header-dependencies.)
* gb/am-hg-patch (2011-08-29) 1 commit
(merged to 'next' on 2011-09-02 at 3edfe4c)
+ am: preliminary support for hg patches
* jc/diff-index-unpack (2011-08-29) 3 commits
(merged to 'next' on 2011-09-02 at 4206bd9)
+ diff-index: pass pathspec down to unpack-trees machinery
+ unpack-trees: allow pruning with pathspec
+ traverse_trees(): allow pruning with pathspec
* nm/grep-object-sha1-lock (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at 336f57d)
+ grep: Fix race condition in delta_base_cache
* tr/mergetool-valgrind (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at f5f2c61)
+ Symlink mergetools scriptlets into valgrind wrappers
* fg/submodule-auto-push (2011-09-11) 2 commits
(merged to 'next' on 2011-09-11 at 3fc86f7)
+ submodule.c: make two functions static
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
(this branch is tangled with hv/submodule-merge-search.)
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* jc/traverse-commit-list (2011-08-22) 3 commits
(merged to 'next' on 2011-08-24 at df50dd7)
+ revision.c: update show_object_with_name() without using malloc()
+ revision.c: add show_object_with_name() helper function
+ rev-list: fix finish_object() call
(this branch is used by jc/fetch-verify and jc/receive-verify.)
* fk/make-auto-header-dependencies (2011-08-18) 1 commit
(merged to 'next' on 2011-08-24 at 3da2c25)
+ Makefile: Use computed header dependencies if the compiler supports it
(this branch is used by da/make-auto-header-dependencies.)
* mh/iterate-refs (2011-09-11) 7 commits
- refs.c: make create_cached_refs() static
- Retain caches of submodule refs
- Store the submodule name in struct cached_refs
- Allocate cached_refs objects dynamically
- Change the signature of read_packed_refs()
- Access reference caches only through new function get_cached_refs()
- Extract a function clear_cached_refs()
I did not see anything fundamentally wrong with this series, but it was
unclear what the benefit of these changes are. If the series were to read
parts of the ref hierarchy (like refs/heads/) lazily, the story would
have been different, though.
* hv/submodule-update-none (2011-08-11) 2 commits
(merged to 'next' on 2011-08-24 at 5302fc1)
+ add update 'none' flag to disable update of submodule by default
+ submodule: move update configuration variable further up
* jc/lookup-object-hash (2011-08-11) 6 commits
(merged to 'next' on 2011-08-24 at 5825411)
+ object hash: replace linear probing with 4-way cuckoo hashing
+ object hash: we know the table size is a power of two
+ object hash: next_size() helper for readability
+ pack-objects --count-only
+ object.c: remove duplicated code for object hashing
+ object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload. Will keep it in 'next' at least for one cycle.
* fg/submodule-git-file-git-dir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-23 at 762194e)
+ Move git-dir for submodules
+ rev-parse: add option --resolve-git-dir <path>
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage outweighs any benefit for having this new
feature. Will keep it in 'next' at least for one cycle.
* jk/http-auth-keyring (2011-09-14) 19 commits
(merged to 'next' on 2011-09-14 at 589c7c9)
+ credential-store: use a better storage format
+ t0300: make alternate username tests more robust
+ t0300: make askpass tests a little more robust
+ credential-cache: fix expiration calculation corner cases
+ docs: minor tweaks to credentials API
(merged to 'next' on 2011-09-11 at 491ce6a)
+ credentials: make credential_fill_gently() static
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
(this branch is used by js/cred-macos-x-keychain-2; is tangled with js/cred-macos-x-keychain.)
* rr/revert-cherry-pick-continue (2011-09-11) 19 commits
(merged to 'next' on 2011-09-11 at 7d78054)
+ builtin/revert.c: make commit_list_append() static
(merged to 'next' on 2011-08-24 at 712c115)
+ revert: Propagate errors upwards from do_pick_commit
+ revert: Introduce --continue to continue the operation
+ revert: Don't implicitly stomp pending sequencer operation
+ revert: Remove sequencer state when no commits are pending
+ reset: Make reset remove the sequencer state
+ revert: Introduce --reset to remove sequencer state
+ revert: Make pick_commits functionally act on a commit list
+ revert: Save command-line options for continuing operation
+ revert: Save data for continuing after conflict resolution
+ revert: Don't create invalid replay_opts in parse_args
+ revert: Separate cmdline parsing from functional code
+ revert: Introduce struct to keep command-line options
+ revert: Eliminate global "commit" variable
+ revert: Rename no_replay to record_origin
+ revert: Don't check lone argument in get_encoding
+ revert: Simplify and inline add_message_to_msg
+ config: Introduce functions to write non-standard file
+ advice: Introduce error_resolve_conflict
--------------------------------------------------
[Discarded]
* jk/pager-with-alias (2011-08-19) 1 commit
. support pager.* for aliases
* cb/maint-quiet-push (2011-09-05) 4 commits
. t5541: avoid TAP test miscounting
. push: old receive-pack does not understand --quiet
. fix push --quiet via http
. tests for push --quiet
Dropped for rerolling after 1.7.7 cycle.
* js/cred-macos-x-keychain (2011-09-11) 15 commits
(merged to 'next' on 2011-09-12 at 8d17f94)
+ contrib: add a credential helper for Mac OS X's keychain
(merged to 'next' on 2011-09-11 at 491ce6a)
+ credentials: make credential_fill_gently() static
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
(this branch is tangled with jk/http-auth-keyring and js/cred-macos-x-keychain-2.)
Reverted out of 'next'.
* jc/reflog-walk-use-only-nsha1 (2011-09-13) 4 commits
. (baloon) teach reflog-walk to look at only new-sha1 field
+ environment.c: have_git_dir() has users on Cygwin
(merged to 'next' on 2011-09-11 at 2acb0af)
+ vcs-svn: remove unused functions and make some static
+ make-static: master
(this branch is tangled with jc/make-static.)
* jc/request-pull-show-head (2011-09-13) 2 commits
(merged to 'next' on 2011-09-13 at c82fb3a)
+ Revert "State what commit to expect in request-pull"
(merged to 'next' on 2011-09-12 at c1c7b73)
+ State what commit to expect in request-pull
Reverted out of 'next'.
^ permalink raw reply
* Anybody home?
From: Joshua Stoutenburg @ 2011-09-15 4:24 UTC (permalink / raw)
To: Git List
Hey guys, I'm pretty stoked about git -- coming from subversion.
I'm having a hard time understanding clearly how to set up a git
server and configure my local machine to pull and push to it.
I've been reading the git book pdf. But I think I must have missed
something. I feel stranded.
Any help appreciated. Many thanks.
-- Josh
^ permalink raw reply
* Re: [PATCH 1/3] make-static: master
From: Junio C Hamano @ 2011-09-15 4:29 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Ramsay Jones, GIT Mailing-list
In-Reply-To: <CALkWK0=TovazpdOvS_va7L0Fv=HcAc9x1-f+LEH_mXgKa-wCQg@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Junio C Hamano writes:
>> Many symbols that are exported to the global scope do not have to be.
>>
>> Signed-off-by: Junio C Hamano <junio@pobox.com>
>> ---
>> To be applied on top of 3793ac5 (RelNotes/1.7.7: minor fixes, 2011-09-07)
>> [...]
>
> Awesome! I've seen many similar "make-static" patches come up on the
> list, but turned down due to code churn issues. I'm happy to finally
> see it being merged.
Not so fast.
We just got a new series from Brandon Casey that adds a new caller to one
of the functions that were unused outside a file. Seeing that this happens
even inside a relative calm of pre-release feature and code freeze,
realize why we call such a change a "churn" and try to avoid it, and
imagine how much damage it would have caused if more topics were actively
being updated.
You should learn to tame your enthusiasm ;-)
^ permalink raw reply
* Re: [PATCH 4/4] attr.c: respect core.ignorecase when matching attribute patterns
From: Junio C Hamano @ 2011-09-15 4:06 UTC (permalink / raw)
To: Brandon Casey; +Cc: peff, git, sunshine, bharrosh, trast, zapped
In-Reply-To: <7vsjnyqws3.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Brandon Casey <drafnel@gmail.com> writes:
>
>> It's easy to work around this issue. I could just parse core.ignorecase
>> in git_attr_config() and set ignore_case myself like:
>>
>> if (!strcmp(var, "core.ignorecase")) {
>> ignore_case = git_config_bool(var, value);
>> return 0;
>> }
>
> I think it is immensely preferrable to do this than cascading to
> default_config like this patch does and then piling band-aid on top to fix
> the breakage caused by calling default_config.
>
> An alternative approach may be to move reading of core.attributesfile to
> default_config, and drop git_config() call from bootstrap_attr_stack(),
> getting rid of git_attr_config callback altogether.
That is, something like this on top of your patch.
attr.c | 15 ++-------------
builtin/check-attr.c | 2 ++
cache.h | 1 +
config.c | 3 +++
environment.c | 1 +
5 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/attr.c b/attr.c
index 79fb11e..76b079f 100644
--- a/attr.c
+++ b/attr.c
@@ -21,8 +21,6 @@ static const char git_attr__unknown[] = "(builtin)unknown";
#define ATTR__UNSET NULL
#define ATTR__UNKNOWN git_attr__unknown
-static const char *attributes_file;
-
/* This is a randomly chosen prime. */
#define HASHSIZE 257
@@ -495,14 +493,6 @@ static int git_attr_system(void)
return !git_env_bool("GIT_ATTR_NOSYSTEM", 0);
}
-static int git_attr_config(const char *var, const char *value, void *dummy)
-{
- if (!strcmp(var, "core.attributesfile"))
- return git_config_pathname(&attributes_file, var, value);
-
- return git_default_config(var, value, dummy);
-}
-
static void bootstrap_attr_stack(void)
{
if (!attr_stack) {
@@ -522,9 +512,8 @@ static void bootstrap_attr_stack(void)
}
}
- git_config(git_attr_config, NULL);
- if (attributes_file) {
- elem = read_attr_from_file(attributes_file, 1);
+ if (git_attributes_file) {
+ elem = read_attr_from_file(git_attributes_file, 1);
if (elem) {
elem->origin = NULL;
elem->prev = attr_stack;
diff --git a/builtin/check-attr.c b/builtin/check-attr.c
index 708988a..abb1165 100644
--- a/builtin/check-attr.c
+++ b/builtin/check-attr.c
@@ -92,6 +92,8 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix)
struct git_attr_check *check;
int cnt, i, doubledash, filei;
+ git_config(git_default_config, NULL);
+
argc = parse_options(argc, argv, prefix, check_attr_options,
check_attr_usage, PARSE_OPT_KEEP_DASHDASH);
diff --git a/cache.h b/cache.h
index 607c2ea..8d95fb2 100644
--- a/cache.h
+++ b/cache.h
@@ -589,6 +589,7 @@ extern int warn_ambiguous_refs;
extern int shared_repository;
extern const char *apply_default_whitespace;
extern const char *apply_default_ignorewhitespace;
+extern const char *git_attributes_file;
extern int zlib_compression_level;
extern int core_compression_level;
extern int core_compression_seen;
diff --git a/config.c b/config.c
index 4183f80..d3bcaa0 100644
--- a/config.c
+++ b/config.c
@@ -491,6 +491,9 @@ static int git_default_core_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.attributesfile"))
+ return git_config_pathname(&git_attributes_file, var, value);
+
if (!strcmp(var, "core.bare")) {
is_bare_repository_cfg = git_config_bool(var, value);
return 0;
diff --git a/environment.c b/environment.c
index e96edcf..d60b73f 100644
--- a/environment.c
+++ b/environment.c
@@ -29,6 +29,7 @@ const char *git_log_output_encoding;
int shared_repository = PERM_UMASK;
const char *apply_default_whitespace;
const char *apply_default_ignorewhitespace;
+const char *git_attributes_file;
int zlib_compression_level = Z_BEST_SPEED;
int core_compression_level;
int core_compression_seen;
^ permalink raw reply related
* Re: [PATCH 4/4] attr.c: respect core.ignorecase when matching attribute patterns
From: Junio C Hamano @ 2011-09-15 4:01 UTC (permalink / raw)
To: Brandon Casey; +Cc: peff, git, sunshine, bharrosh, trast, zapped
In-Reply-To: <1316051979-19671-5-git-send-email-drafnel@gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> It's easy to work around this issue. I could just parse core.ignorecase
> in git_attr_config() and set ignore_case myself like:
>
> if (!strcmp(var, "core.ignorecase")) {
> ignore_case = git_config_bool(var, value);
> return 0;
> }
I think it is immensely preferrable to do this than cascading to
default_config like this patch does and then piling band-aid on top to fix
the breakage caused by calling default_config.
An alternative approach may be to move reading of core.attributesfile to
default_config, and drop git_config() call from bootstrap_attr_stack(),
getting rid of git_attr_config callback altogether.
^ permalink raw reply
* Re: git-rebase skips automatically no more needed commits
From: Junio C Hamano @ 2011-09-15 3:41 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Francis Moreau, Michael J Gruber, git
In-Reply-To: <alpine.DEB.2.00.1109122139110.12564@debian>
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> 2. Somehow modify git-rebase--am.sh not to depend on format-patch. In
> [1], Junio mentions rewriting git-rebase--am.sh "to have
> format-patch avoid the cost of actually generating the patch text"
> and "when using "am" for rebasing we do not really care anything
> but the commit object names". If all we need is the commit name,
> why would we not use cherry-pick/sequencer instead of git-am?
What I said is "all 'am' need to use from its input while rebasing is the
commit object name"; that is very different from "we have only commit
object name so we must use cherry-pick" or "because we have commit object
name, we can afford to use cherry-pick".
Look for $rebasing in git-am.sh and notice that:
- We run get-author-ident-from-commit on $commit to keep the authorship
information in $dotest/author-script for later use, instead of letting
them read from $dotest/info prepared by "mailinfo".
- My "fixing it would be just the matter of doing this" patch in a
separate thread we had recently ("mailinfo" would obviously have
trouble telling where the message ends whilerebasing a change with
patch text in the commit log message) adds a similar logic to extract
the patch text out of $commit in the same place as above, to override
what "mailinfo" prepares in $dotest/patch.
- Even with the above two differences from the normal "separate the
metainfo and patch from the mailbox, and use them" codepath, $rebasing
codepath uses the same "git apply && git write-tree && git commit-tree"
flow.
Use of "apply && write-tree && commit-tree" is to avoid the merge overhead
of using cherry-pick, and historically, it used to matter a lot, because
starting merge-recursive was very slow (it was a Python script). Even
though we have merge-recursive rewritten in C these days, it probably
still matters, especially for large-ish projects, because merge will trash
the cached-tree information in the index, making write-tree inefficient.
^ permalink raw reply
* [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: Jay Soffian @ 2011-09-15 2:51 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Junio C Hamano, Jeff King, John Szakmeister
This credential helper adds, searches, and removes entries from
the Mac OS X keychain. The C version links against the Security
framework and is probably the best choice for daily use.
A python version is also included primarily as a more readable
example and uses the /usr/bin/security CLI to access the keychain.
Tested with 10.6.8.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Here's a C version that no longer links to git. I also kept the original
Python version as an example. I decided not to call out to
'git credential-gitpass' as it was simple enough to manage /dev/tty
and there's no portability issues since this is OS X specific.
contrib/credential-osxkeychain/Makefile | 14 +
.../git-credential-osxkeychain.c | 300 ++++++++++++++++++++
.../git-credential-osxkeychain.py | 148 ++++++++++
3 files changed, 462 insertions(+), 0 deletions(-)
create mode 100644 contrib/credential-osxkeychain/Makefile
create mode 100644 contrib/credential-osxkeychain/git-credential-osxkeychain.c
create mode 100755 contrib/credential-osxkeychain/git-credential-osxkeychain.py
diff --git a/contrib/credential-osxkeychain/Makefile b/contrib/credential-osxkeychain/Makefile
new file mode 100644
index 0000000000..a0a7074cc6
--- /dev/null
+++ b/contrib/credential-osxkeychain/Makefile
@@ -0,0 +1,14 @@
+all:: git-credential-osxkeychain
+
+CC = gcc
+RM = rm -f
+CFLAGS = -O2 -Wall
+
+git-credential-osxkeychain: git-credential-osxkeychain.o
+ $(CC) -o $@ $< -Wl,-framework -Wl,Security
+
+git-credential-osxkeychain.o: git-credential-osxkeychain.c
+ $(CC) -c $(CFLAGS) $<
+
+clean:
+ $(RM) git-credential-osxkeychain git-credential-osxkeychain.o
diff --git a/contrib/credential-osxkeychain/git-credential-osxkeychain.c b/contrib/credential-osxkeychain/git-credential-osxkeychain.c
new file mode 100644
index 0000000000..2f611f7348
--- /dev/null
+++ b/contrib/credential-osxkeychain/git-credential-osxkeychain.c
@@ -0,0 +1,300 @@
+/* Copyright 2011 Jay Soffian. All rights reserved.
+ * FreeBSD License.
+ *
+ * A git credential helper that interfaces with the Mac OS X keychain
+ * via the Security framework.
+ */
+#include <fcntl.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
+#include <termios.h>
+#include <Security/Security.h>
+
+static void die(const char *err, ...)
+{
+ char msg[4096];
+ va_list params;
+ va_start(params, err);
+ vsnprintf(msg, sizeof(msg), err, params);
+ fprintf(stderr, "%s\n", msg);
+ va_end(params);
+ exit(1);
+}
+
+void *xmalloc(size_t size)
+{
+ void *ret = malloc(size);
+ if (!ret)
+ die("Out of memory");
+ return ret;
+}
+
+void *xstrdup(const char *s1)
+{
+ void *ret = strdup(s1);
+ if (!ret)
+ die("Out of memory");
+ return ret;
+}
+
+void emit_user_pass(char *username, char *password)
+{
+ if (username)
+ printf("username=%s\n", username);
+ if (password)
+ printf("password=%s\n", password);
+}
+
+typedef enum { USERNAME, PASSWORD } prompt_type;
+
+void prompt(FILE *file, const char *what, const char *desc)
+{
+ if (desc)
+ fprintf(file, "%s for '%s': ", what, desc);
+ else
+ fprintf(file, "%s: ", what);
+}
+
+char *prompt_tty(prompt_type what, char *description)
+{
+ struct termios old;
+ struct termios new;
+ char buf[128];
+ int buf_len;
+ int fd = open("/dev/tty", O_RDWR|O_NOCTTY);
+ FILE *tty = fdopen(fd, "w+");
+ if (what == USERNAME) {
+ prompt(tty, "Username", description);
+ }
+ else {
+ prompt(tty, "Password", description);
+ tcgetattr(fd, &old);
+ memcpy(&new, &old, sizeof(struct termios));
+ new.c_lflag &= ~ECHO;
+ tcsetattr(fd, TCSADRAIN, &new);
+ }
+ if (!fgets(buf, sizeof(buf), tty)) {
+ fprintf(tty, "\n");
+ fclose(tty);
+ return NULL;
+ }
+ if (what == PASSWORD) {
+ tcsetattr(fd, TCSADRAIN, &old);
+ fprintf(tty, "\n");
+ }
+ fclose(tty);
+ buf_len = strlen(buf);
+ if (buf[buf_len-1] == '\n')
+ buf[buf_len-1] = '\0';
+ return xstrdup(buf);
+}
+
+char *username_from_keychain_item(SecKeychainItemRef item)
+{
+ OSStatus status;
+ SecKeychainAttributeList list;
+ SecKeychainAttribute attr;
+ list.count = 1;
+ list.attr = &attr;
+ attr.tag = kSecAccountItemAttr;
+ char *username;
+
+ status = SecKeychainItemCopyContent(item, NULL, &list, NULL, NULL);
+ if (status != noErr)
+ return NULL;
+ username = xmalloc(attr.length + 1);
+ strncpy(username, attr.data, attr.length);
+ username[attr.length] = '\0';
+ SecKeychainItemFreeContent(&list, NULL);
+ return username;
+}
+
+int find_internet_password(SecProtocolType protocol,
+ char *hostname,
+ char *username)
+{
+ void *password_buf;
+ UInt32 password_len;
+ OSStatus status;
+ char *password;
+ int free_username = 0;
+ SecKeychainItemRef item;
+
+ status = SecKeychainFindInternetPassword(
+ NULL,
+ strlen(hostname), hostname,
+ 0, NULL,
+ username ? strlen(username) : 0, username,
+ 0, NULL,
+ 0,
+ protocol,
+ kSecAuthenticationTypeDefault,
+ &password_len, &password_buf,
+ &item);
+ if (status != noErr)
+ return -1;
+
+ password = xmalloc(password_len + 1);
+ strncpy(password, password_buf, password_len);
+ password[password_len] = '\0';
+ SecKeychainItemFreeContent(NULL, password_buf);
+ if (!username) {
+ username = username_from_keychain_item(item);
+ free_username = 1;
+ }
+ emit_user_pass(username, password);
+ if (free_username)
+ free(username);
+ free(password);
+ return 0;
+}
+
+void delete_internet_password(SecProtocolType protocol,
+ char *hostname,
+ char *username)
+{
+ OSStatus status;
+ SecKeychainItemRef item;
+
+ status = SecKeychainFindInternetPassword(
+ NULL,
+ strlen(hostname), hostname,
+ 0, NULL,
+ username ? strlen(username) : 0, username,
+ 0, NULL,
+ 0,
+ protocol,
+ kSecAuthenticationTypeDefault,
+ 0, NULL,
+ &item);
+ if (status != noErr)
+ return;
+ SecKeychainItemDelete(item);
+}
+
+void add_internet_password(SecProtocolType protocol,
+ char *hostname,
+ char *username,
+ char *password,
+ char *comment)
+{
+ const char *label_format = "%s (%s)";
+ char *label;
+ OSStatus status;
+ SecKeychainItemRef item;
+ SecKeychainAttributeList list;
+ SecKeychainAttribute attr;
+ list.count = 1;
+ list.attr = &attr;
+ status = SecKeychainAddInternetPassword(
+ NULL,
+ strlen(hostname), hostname,
+ 0, NULL,
+ strlen(username), username,
+ 0, NULL,
+ 0,
+ protocol,
+ kSecAuthenticationTypeDefault,
+ strlen(password), password,
+ &item);
+ if (status != noErr)
+ return;
+
+ /* set the comment */
+ attr.tag = kSecCommentItemAttr;
+ attr.data = comment;
+ attr.length = strlen(comment);
+ SecKeychainItemModifyContent(item, &list, 0, NULL);
+
+ /* override the label */
+ label = xmalloc(strlen(hostname) + strlen(username) +
+ strlen(label_format));
+ sprintf(label, label_format, hostname, username);
+ attr.tag = kSecLabelItemAttr;
+ attr.data = label;
+ attr.length = strlen(label);
+ SecKeychainItemModifyContent(item, &list, 0, NULL);
+}
+
+int main(int argc, const char **argv)
+{
+ const char *usage =
+ "Usage: git credential-osxkeychain --unique=TOKEN [options]\n"
+ "Options:\n"
+ " --description=DESCRIPTION\n"
+ " --username=USERNAME\n"
+ " --reject";
+ char *description = NULL, *username = NULL, *unique = NULL;
+ char *hostname, *password;
+ int i, free_username = 0, reject = 0;
+ SecProtocolType protocol = 0;
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+ if (!strncmp(arg, "--description=", 14)) {
+ description = (char *) arg + 14;
+ }
+ else if (!strncmp(arg, "--username=", 11)) {
+ username = (char *) arg + 11;
+ }
+ else if (!strncmp(arg, "--unique=", 9)) {
+ unique = (char *) arg + 9;
+ }
+ else if (!strcmp(arg, "--reject")) {
+ reject = 1;
+ }
+ else if (!strcmp(arg, "--help")) {
+ die(usage);
+ }
+ else
+ die("Unrecognized argument `%s'; try --help", arg);
+ }
+
+ if (!unique)
+ die("Must specify --unique=TOKEN; try --help");
+
+ hostname = strchr(unique, ':');
+ if (!hostname)
+ die("Invalid token `%s'", unique);
+ *hostname++ = '\0';
+
+ /* "GitHub for Mac" compatibility */
+ if (!strcmp(hostname, "github.com"))
+ hostname = "github.com/mac";
+
+ if (!strcmp(unique, "https")) {
+ protocol = kSecProtocolTypeHTTPS;
+ } else if (!strcmp(unique, "http")) {
+ protocol = kSecProtocolTypeHTTP;
+ }
+ else
+ die("Unrecognized protocol `%s'", unique);
+
+ /* if this is a rejection delete the existing creds */
+ if (reject) {
+ delete_internet_password(protocol, hostname, username);
+ return 0;
+ }
+
+ /* otherwise look for a matching keychain item */
+ if (!find_internet_password(protocol, hostname, username))
+ return 0;
+
+ /* no keychain item found, prompt the user and store the result */
+ if (!username) {
+ if (!(username = prompt_tty(USERNAME, description)))
+ return 0;
+ free_username = 1;
+ }
+ if (!(password = prompt_tty(PASSWORD, description)))
+ return 0;
+
+ add_internet_password(protocol, hostname, username, password,
+ description ? description : "default");
+ emit_user_pass(username, password);
+ if (free_username)
+ free(username);
+ free(password);
+ return 0;
+}
diff --git a/contrib/credential-osxkeychain/git-credential-osxkeychain.py b/contrib/credential-osxkeychain/git-credential-osxkeychain.py
new file mode 100755
index 0000000000..ae5ec00d68
--- /dev/null
+++ b/contrib/credential-osxkeychain/git-credential-osxkeychain.py
@@ -0,0 +1,148 @@
+#!/usr/bin/python
+# Copyright 2011 Jay Soffian. All rights reserved.
+# FreeBSD License.
+"""
+A git credential helper that interfaces with the Mac OS X keychain via
+/usr/bin/security.
+"""
+
+import os
+import re
+import sys
+import termios
+from getpass import _raw_input
+from optparse import OptionParser
+from subprocess import Popen, PIPE
+
+USERNAME = 'USERNAME'
+PASSWORD = 'PASSWORD'
+PROMPTS = dict(USERNAME='Username', PASSWORD='Password')
+
+def prompt_tty(what, desc):
+ """Prompt on TTY for username or password with optional description"""
+ prompt = '%s%s: ' % (PROMPTS[what], " for '%s'" % desc if desc else '')
+ # Borrowed mostly from getpass.py
+ fd = os.open('/dev/tty', os.O_RDWR|os.O_NOCTTY)
+ tty = os.fdopen(fd, 'w+', 1)
+ if what == USERNAME:
+ return _raw_input(prompt, tty, tty)
+ old = termios.tcgetattr(fd) # a copy to save
+ new = old[:]
+ new[3] &= ~termios.ECHO # 3 == 'lflags'
+ try:
+ termios.tcsetattr(fd, termios.TCSADRAIN, new)
+ return _raw_input(prompt, tty, tty)
+ finally:
+ termios.tcsetattr(fd, termios.TCSADRAIN, old)
+ tty.write('\n')
+
+def emit_user_pass(username, password):
+ if username:
+ print 'username=' + username
+ if password:
+ print 'password=' + password
+
+def make_security_args(command, protocol, hostname, username):
+ args = ['/usr/bin/security', command]
+ # tlfd is 'dflt' backwards - obvious /usr/bin/security bug
+ # but allows us to ignore matching saved web forms.
+ args.extend(['-t', 'tlfd'])
+ args.extend(['-r', protocol])
+ if hostname:
+ args.extend(['-s', hostname])
+ if username:
+ args.extend(['-a', username])
+ return args
+
+def find_internet_password(protocol, hostname, username):
+ args = make_security_args('find-internet-password',
+ protocol, hostname, username)
+ args.append('-g') # asks for password on stderr
+ p = Popen(args, stdin=PIPE, stdout=PIPE, stderr=PIPE)
+ # grok stdout for username
+ out, err = p.communicate()
+ if p.returncode != 0:
+ return
+ for line in out.splitlines(): # pylint:disable-msg=E1103
+ m = re.search(r'^\s+"acct"<blob>=[^"]*"(.*)"$', line)
+ if m:
+ username = m.group(1)
+ break
+ # grok stderr for password
+ m = re.search(r'^password:[^"]*"(.*)"$', err)
+ if not m:
+ return
+ emit_user_pass(username, m.group(1))
+ return True
+
+def delete_internet_password(protocol, hostname, username):
+ args = make_security_args('delete-internet-password',
+ protocol, hostname, username)
+ p = Popen(args, stdin=PIPE, stdout=PIPE, stderr=PIPE)
+ p.communicate()
+
+def add_internet_password(protocol, hostname, username, password):
+ # We do this over a pipe so that we can provide the password more
+ # securely than as an argument which would show up in ps output.
+ # Unfortunately this is possibly less robust since the security man
+ # page does not document how to quote arguments. Emprically it seems
+ # that using the double-quote, escaping \ and " works properly.
+ username = username.replace('\\', '\\\\').replace('"', '\\"')
+ password = password.replace('\\', '\\\\').replace('"', '\\"')
+ command = ' '.join([
+ 'add-internet-password', '-U',
+ '-r', protocol,
+ '-s', hostname,
+ '-a "%s"' % username,
+ '-w "%s"' % password,
+ '-j default',
+ '-l "%s (%s)"' % (hostname, username),
+ ]) + '\n'
+ args = ['/usr/bin/security', '-i']
+ p = Popen(args, stdin=PIPE, stdout=PIPE, stderr=PIPE)
+ p.communicate(command)
+
+def main():
+ p = OptionParser()
+ p.add_option('--description')
+ p.add_option('--reject', action='store_true')
+ p.add_option('--unique', dest='token', help='REQUIRED OPTION')
+ p.add_option('--username')
+ opts, _ = p.parse_args()
+
+ if not opts.token:
+ p.error('--unique option required')
+ if not ':' in opts.token:
+ print >> sys.stderr, "Invalid token: '%s'" % opts.token
+ return 1
+ protocol, hostname = opts.token.split(':', 1)
+ if protocol not in ('http', 'https'):
+ print >> sys.stderr, "Unsupported protocol: '%s'" % protocol
+ return 1
+ if protocol == 'https':
+ protocol = 'htps'
+
+ # "GitHub for Mac" compatibility
+ if hostname == 'github.com':
+ hostname = 'github.com/mac'
+
+ # if this is a rejection delete the existing creds
+ if opts.reject:
+ delete_internet_password(protocol, hostname, opts.username)
+ return 0
+
+ # otherwise look for creds
+ if find_internet_password(protocol, hostname, opts.username):
+ return 0
+
+ # creds not found, so prompt the user then store the creds
+ username = opts.username
+ if username is None:
+ username = prompt_tty(USERNAME, opts.description)
+ password = prompt_tty(PASSWORD, opts.description)
+ add_internet_password(protocol, hostname, username, password)
+ emit_user_pass(username, password)
+ return 0
+
+if __name__ == '__main__':
+ sys.exit(main())
--
1.7.7.rc1.1.g011e1
^ permalink raw reply related
* Re: git gc exit with out of memory, malloc failed error
From: Alexander Kostikov @ 2011-09-15 2:42 UTC (permalink / raw)
To: David Michael Barr; +Cc: git
In-Reply-To: <CAFfmPPP58J90758TRB2sAj-Wr5HB=rQtaJipKovsHXyTcswuJQ@mail.gmail.com>
Thanks!
--window-memory=50m worked for my project. 256m was still throwing
error. Probably real memory consumption is close to threads number *
window memory.
On Wed, Sep 14, 2011 at 7:20 PM, David Michael Barr
<davidbarr@google.com> wrote:
> On Thu, Sep 15, 2011 at 11:33 AM, Alexander Kostikov
> <alex.kostikov@gmail.com> wrote:
>> I'm new to git and I'm getting the following out of memory error on git gc:
>>
>> $ git gc
>> Counting objects: 80818, done.
>> Delta compression using up to 8 threads.
>> fatal: Out of memory, malloc failed (tried to allocate 24359675 bytes)
>> error: failed to run repack
>>
>> The only advice I found in the internet suggested to run repack with
>> --window-memory parameter specified. But this call also fails:
>>
>> $ git repack -adf --window-memory=0
>> Counting objects: 80818, done.
>> Delta compression using up to 8 threads.
>> warning: suboptimal pack - out of memory
>> fatal: Out of memory, malloc failed (tried to allocate 24356363 bytes)
>>
>> How do I cleanup my repository?
>>
>> $ git version
>> git version 1.7.6.msysgit.0
>>
>> OS: Windows Server 2008 R2 SP1 (x64)
>> Physical memory: 24 GB
>> The commands listed were executed under x64 console process.
>>
>> --
>> Thanks,
>> Alexander Kostikov
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> Hi,
>
> My understanding is that msysgit is a 32-bit build.
> So if your existing pack is ~2GB, repack will fail.
> Also, I think that setting window-memory to 0
> means no limit, which is not what you want.
> One value I have seen suggested is 256m.
> In my experience, peak memory consumption of
> repack is proportional to the value of --window,
> so you might want to try tweaking that.
> There are quite a few config parameters that
> affect the memory consumption of repack.
>
> --
> David Barr
>
--
Your sincerely,
Alexander Kostikov
^ 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