* asciidoc, was Re: Chicken/egg problem building from a 'git clone'
From: Johannes Schindelin @ 2009-03-06 12:02 UTC (permalink / raw)
To: John Tapsell; +Cc: Jakub Narebski, Jeff King, Matthieu Moy, Git Mailing List
In-Reply-To: <43d8ce650903060327l64e76f2al7ec3c2ee76be14eb@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2548 bytes --]
Hi,
On Fri, 6 Mar 2009, John Tapsell wrote:
> 2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Fri, 6 Mar 2009, Jakub Narebski wrote:
> >
> >> Jeff King <peff@peff.net> writes:
> >> > On Thu, Mar 05, 2009 at 01:38:27PM +0100, Matthieu Moy wrote:
> >> >
> >> >>>> * we have lots other files in git.git that are autogenerated (the
> >> >>>> documentation files, for example)
> >> >>>
> >> >>> I'm not aware of any auto-generated files that are checked in. Can you
> >> >>> give an example?
> >> >>
> >> >> man pages and html docs are commited, but in a separate branch. IOW,
> >> >> Junio abuses Git as a distribution mechanism, but keeps it totally
> >> >> separate from the actual sources.
> >> >
> >> > OK, true; but that is a totally different mechanism, unless the proposal
> >> > is to autobuild a "this would be the release tarball" branch similar to
> >> > html and man branches.
> >>
> >> I thnk the proposal was to have 'configure' branch with configure
> >> script built, similar to how 'html' and 'man' branches have built
> >> documentation in HTML and manpages format.
> >>
> >> However while toolchain needed to produce documentation (asciidoc +
> >> xmlto) isn't, I think, something very common, in my opinion autoconf is
> >> something that is present on systems containing other build tools
> >> required to build git from sources. So 'configure' branch is not, I
> >> think, as necessary as 'html' and 'man' branches; additionally 'html'
> >> branch (or the repository used to build documentation, or the byproduct
> >> of building documentation) is used to generate on-line docs for git.
> >
> > Plus, keep in mind that autoconf support is only an afterthought in Git;
> > Just running "make" is supposed to work. If it does not, patches are
> > certainly welcome, I think.
>
> Well now that you mention it.. :-)
>
> It doesn't check for the existance of asciidoc, but blindly assumes it
> exists. And even if you do have asciidoc, there's a good chance that
> you have the wrong version. The INSTALL file says that asciidoc
> requires 8.2.7 but most distros (debian, ubuntu. probably other) have
> 8.2.6.
> If you compile the docs with the wrong asciidoc version, there is no
> warning or error at all. It just builds incorrect man pages.
Frankly, I was talking about "make". I never needed asciidoc there.
Besides, if it is really an itch of yours, maybe you can come up with a
patch checking for a correct asciidoc version? Only if asciidoc would be
needed at all, of course.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Finn Arne Gangstad @ 2009-03-06 11:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Sverre Rabbelier, markus.heidelberg, git,
John Tapsell, Andreas Ericsson
In-Reply-To: <7v4oy7szze.fsf@gitster.siamese.dyndns.org>
On Fri, Mar 06, 2009 at 02:32:53AM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
> >
> >> On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
> >> <markus.heidelberg@web.de> wrote:
> >> > Oh, I confused "config option" with "command line argument"...
> >>
> >> Right, I'd like to be able to do:
> >> $ git config push.iamnotretarded true
> >> $ git push
> >
> > LOL! Sverre, you have a way to crack me up...
>
> I found it amusing, too.
>
> It may have some correlation with how well organized your work habit is,
> but I do not think it has much correlation with being retarded. It is
> more about "'matching refs' is the perfect default for _my_ use pattern,
> don't mess with it, please".
So here is my current WIP suggestion for a new "push.default"
variable, I am not sure if a single entry can express all useful
choices, or if it is a good idea to introduce more default choices
other than "nothing" (with the goal of making it the default in a
later release).
I think all the values here make sense as a --option to git push
though (except --nothing...)
Suggested new entry in config.txt:
push.default::
Defines the action git push should take if no refspec is given
on the command line, no refspec is configured in the branch, and
no refspec is implied by any of the options given on the command
line.
+
The term `current remote` means the remote configured for the current
branch, or `origin` if no remote is set. `origin` is also used if
you are not on a branch at all.
+
* `nothing` do not push anything
* `matching` push all matching branches to the current remote.
All branches having the same name in both ends are considered to be
matching. This is the default value.
* `same-remote` push all matching branches that are configured to use
the current remote. Branches with no remote configuration are not pushed.
* `tracked` push all branches that are tracking a branch on the current
remote to their counterpart.
- Finn Arne
^ permalink raw reply
* Re: Chicken/egg problem building from a 'git clone'
From: Matthieu Moy @ 2009-03-06 10:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <m3eixbszkt.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> However while toolchain needed to produce documentation (asciidoc +
> xmlto) isn't, I think, something very common, in my opinion autoconf
> is something that is present on systems containing other build tools
> required to build git from sources.
Plus:
* an old ./configure script (taken from a previous tarball release)
has good chance to work on a new Git. Since Makefile is designed to
be useable without scripting, Junnio takes great care not to break
existing setups.
* ./configure script is not mandatory to build Git from sources.
--
Matthieu
^ permalink raw reply
* Re: Chicken/egg problem building from a 'git clone'
From: John Tapsell @ 2009-03-06 11:27 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, Jeff King, Matthieu Moy, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0903061203270.10279@pacific.mpi-cbg.de>
2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Fri, 6 Mar 2009, Jakub Narebski wrote:
>
>> Jeff King <peff@peff.net> writes:
>> > On Thu, Mar 05, 2009 at 01:38:27PM +0100, Matthieu Moy wrote:
>> >
>> >>>> * we have lots other files in git.git that are autogenerated (the
>> >>>> documentation files, for example)
>> >>>
>> >>> I'm not aware of any auto-generated files that are checked in. Can you
>> >>> give an example?
>> >>
>> >> man pages and html docs are commited, but in a separate branch. IOW,
>> >> Junio abuses Git as a distribution mechanism, but keeps it totally
>> >> separate from the actual sources.
>> >
>> > OK, true; but that is a totally different mechanism, unless the proposal
>> > is to autobuild a "this would be the release tarball" branch similar to
>> > html and man branches.
>>
>> I thnk the proposal was to have 'configure' branch with configure
>> script built, similar to how 'html' and 'man' branches have built
>> documentation in HTML and manpages format.
>>
>> However while toolchain needed to produce documentation (asciidoc +
>> xmlto) isn't, I think, something very common, in my opinion autoconf is
>> something that is present on systems containing other build tools
>> required to build git from sources. So 'configure' branch is not, I
>> think, as necessary as 'html' and 'man' branches; additionally 'html'
>> branch (or the repository used to build documentation, or the byproduct
>> of building documentation) is used to generate on-line docs for git.
>
> Plus, keep in mind that autoconf support is only an afterthought in Git;
> Just running "make" is supposed to work. If it does not, patches are
> certainly welcome, I think.
Well now that you mention it.. :-)
It doesn't check for the existance of asciidoc, but blindly assumes it
exists. And even if you do have asciidoc, there's a good chance that
you have the wrong version. The INSTALL file says that asciidoc
requires 8.2.7 but most distros (debian, ubuntu. probably other) have
8.2.6.
If you compile the docs with the wrong asciidoc version, there is no
warning or error at all. It just builds incorrect man pages.
John
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Sverre Rabbelier @ 2009-03-06 11:17 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin
Cc: markus.heidelberg, Finn Arne Gangstad, git, John Tapsell,
Andreas Ericsson
In-Reply-To: <7v4oy7szze.fsf@gitster.siamese.dyndns.org>
Heya,
On Fri, Mar 6, 2009 at 11:32, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
>>> Right, I'd like to be able to do:
>>> $ git config push.iamnotretarded true
>>> $ git push
>>
>> LOL! Sverre, you have a way to crack me up...
Hehe, good, never hurts to add some humor to this list every now and then ;).
> I found it amusing, too.
I think that humor at times is an effective way to convey your point
while and at the same time keeping the tone light :).
> It may have some correlation with how well organized your work habit is,
> but I do not think it has much correlation with being retarded. It is
> more about "'matching refs' is the perfect default for _my_ use pattern,
> don't mess with it, please".
For me the reason 'git push' works well for me is that origin is
repo.or.cz and I use the repo there just to synch my changes between
my laptop and my pc (and to keep a backup). I reckon there are other
workflows for which it makes sense to use 'git push' directly :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: setting up tracking on push
From: Miles Bader @ 2009-03-06 11:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0903061144480.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > I vaguely feel like I should be able to do:
>> >
>> > git push --track origin grognul
>
> http://search.gmane.org/?query=push+track&group=gmane.comp.version-control.git
>
> Summary for the lazy: it needs a lot of work to be implemented properly.
Alternatively, maybe a "git track [REMOTE [BRANCH]]" command that simply
adds makes adding the appropriate config magic more convenient ?
I dunno what the arg syntax would look like in the general case;
I almost always want to use the current branch, and track an identically
named branch in the origin remote though...
-Miles
--
Custard, n. A vile concoction produced by a malevolent conspiracy of the hen,
the cow, and the cook.
^ permalink raw reply
* Re: Chicken/egg problem building from a 'git clone'
From: Johannes Schindelin @ 2009-03-06 11:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jeff King, Matthieu Moy, John Tapsell, Git Mailing List
In-Reply-To: <m3eixbszkt.fsf@localhost.localdomain>
Hi,
On Fri, 6 Mar 2009, Jakub Narebski wrote:
> Jeff King <peff@peff.net> writes:
> > On Thu, Mar 05, 2009 at 01:38:27PM +0100, Matthieu Moy wrote:
> >
> >>>> * we have lots other files in git.git that are autogenerated (the
> >>>> documentation files, for example)
> >>>
> >>> I'm not aware of any auto-generated files that are checked in. Can you
> >>> give an example?
> >>
> >> man pages and html docs are commited, but in a separate branch. IOW,
> >> Junio abuses Git as a distribution mechanism, but keeps it totally
> >> separate from the actual sources.
> >
> > OK, true; but that is a totally different mechanism, unless the proposal
> > is to autobuild a "this would be the release tarball" branch similar to
> > html and man branches.
>
> I thnk the proposal was to have 'configure' branch with configure
> script built, similar to how 'html' and 'man' branches have built
> documentation in HTML and manpages format.
>
> However while toolchain needed to produce documentation (asciidoc +
> xmlto) isn't, I think, something very common, in my opinion autoconf is
> something that is present on systems containing other build tools
> required to build git from sources. So 'configure' branch is not, I
> think, as necessary as 'html' and 'man' branches; additionally 'html'
> branch (or the repository used to build documentation, or the byproduct
> of building documentation) is used to generate on-line docs for git.
Plus, keep in mind that autoconf support is only an afterthought in Git;
Just running "make" is supposed to work. If it does not, patches are
certainly welcome, I think.
Ciao,
Dscho
^ permalink raw reply
* Re: Using Git with windows
From: Johannes Schindelin @ 2009-03-06 10:59 UTC (permalink / raw)
To: John Chapman; +Cc: Tariq Hassanen, git
In-Reply-To: <1236327385.4010.5.camel@localhost>
Hi,
On Fri, 6 Mar 2009, John Chapman wrote:
> Just be sure to be aware of autocrlf, and that on windows with msysgit,
> it is enabled by default.
>
> [...]
>
> Unless you think your repository will become larger than 2GB (Not
> likely), then msysgit will do just fine.
Both issues will be addressed in the next Git for Windows installer.
Ciao,
Dscho
^ permalink raw reply
* Fwd: how to have --no-ff be the default for all branch
From: jean-luc malet @ 2009-03-06 10:45 UTC (permalink / raw)
To: git
In-Reply-To: <1de9d39c0903060244t2d39e9c8kd5791d097c84bbeb@mail.gmail.com>
---------- Forwarded message ----------
From: jean-luc malet <jeanluc.malet@gmail.com>
Date: Fri, Mar 6, 2009 at 11:44 AM
Subject: how to have --no-ff be the default for all branch
To: git@vger.kernel.org
Hi all!
I'm using git for a time now and the thing that annoyed me the most is
that git "loose" branch information, ie if I have branch1 and master
that I do dev on branch1 (let say 3 commit) and that I want to deliver
on master, if there has not been any commit on master, when I do
git checkout master
git merge branch1
git branch -d branch1
then git resolve as fast forward and then make branch1 "disapear" (ie
on gitk I can't notice just by looking at the tree that there was a
branch there)
the solution is to use
git merge --no-ff branch1
I would like that it is the default for all branch and that I use --ff
when I want to do fast forward merge
I know that I can set it up for one branch
git config add branch.master.mergeoption --no-ff
but I want it to be the default no just for one branch but for all branch
git config add branch.*.mergeoption --no-ff
don't work....
how can I do that?
thanks
JLM
--
KISS! (Keep It Simple, Stupid!)
(garde le simple, imbécile!)
"mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses
simples et qui marchent, espèce d'imbécile!"
-----------------------------
"Si vous pensez que vous êtes trop petit pour changer quoique ce soit,
essayez donc de dormir avec un moustique dans votre chambre." Betty
Reese
http://www.grainesdechangement.com/citations.htm
--
KISS! (Keep It Simple, Stupid!)
(garde le simple, imbécile!)
"mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses
simples et qui marchent, espèce d'imbécile!"
-----------------------------
"Si vous pensez que vous êtes trop petit pour changer quoique ce soit,
essayez donc de dormir avec un moustique dans votre chambre." Betty
Reese
http://www.grainesdechangement.com/citations.htm
^ permalink raw reply
* Re: setting up tracking on push
From: Johannes Schindelin @ 2009-03-06 10:45 UTC (permalink / raw)
To: Jay Soffian; +Cc: Miles Bader, git
In-Reply-To: <76718490903052049k217e9c12gb7881f8904fdd9d@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 457 bytes --]
Hi,
On Thu, 5 Mar 2009, Jay Soffian wrote:
> On Thu, Mar 5, 2009 at 10:07 PM, Miles Bader <miles@gnu.org> wrote:
> > I vaguely feel like I should be able to do:
> >
> > git push --track origin grognul
>
> Hmm, I vaguely remember seeing a patch come across the list to do this.
Indeed.
http://search.gmane.org/?query=push+track&group=gmane.comp.version-control.git
Summary for the lazy: it needs a lot of work to be implemented properly.
Hth,
Dscho
^ permalink raw reply
* Re: Chicken/egg problem building from a 'git clone'
From: Jakub Narebski @ 2009-03-06 10:39 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, John Tapsell, Git Mailing List
In-Reply-To: <20090305124512.GA2723@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Mar 05, 2009 at 01:38:27PM +0100, Matthieu Moy wrote:
>
>>>> * we have lots other files in git.git that are autogenerated (the
>>>> documentation files, for example)
>>>
>>> I'm not aware of any auto-generated files that are checked in. Can you
>>> give an example?
>>
>> man pages and html docs are commited, but in a separate branch. IOW,
>> Junio abuses Git as a distribution mechanism, but keeps it totally
>> separate from the actual sources.
>
> OK, true; but that is a totally different mechanism, unless the proposal
> is to autobuild a "this would be the release tarball" branch similar to
> html and man branches.
I thnk the proposal was to have 'configure' branch with configure
script built, similar to how 'html' and 'man' branches have built
documentation in HTML and manpages format.
However while toolchain needed to produce documentation (asciidoc +
xmlto) isn't, I think, something very common, in my opinion autoconf
is something that is present on systems containing other build tools
required to build git from sources. So 'configure' branch is not, I
think, as necessary as 'html' and 'man' branches; additionally 'html'
branch (or the repository used to build documentation, or the
byproduct of building documentation) is used to generate on-line docs
for git.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Johannes Schindelin @ 2009-03-06 10:37 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git, John Tapsell, Andreas Ericsson
In-Reply-To: <20090305221529.GA25871@pvv.org>
Hi,
Disclaimer: if you are offended by constructive criticism, or likely to
answer with insults to the comments I offer, please stop reading this mail
now (and please do not answer my mail, either). :-)
Still with me? Good. Nice to meet you.
Just for the record: responding to a patch is my strongest way of saying
that I appreciate your work.
On Thu, 5 Mar 2009, Finn Arne Gangstad wrote:
> Previously, git push [remote] with no arguments would behave like
> "git push <remote> :" if no push refspecs were configured for the remote.
> It may be too easy for novice users to write "git push" or
> "git push origin" by accident, so git will now push nothing, and give an
> error message in such cases.
>
> Teach git push a new option "--matching" that keeps the old behavior of
> pushing all matching branches when none are configured.
As others have commented, you cannot just go and fsck existing users over.
That is just not flying well.
IMHO you should always consider the downsides of your patch in addition to
the upsides, and not only for yourself, but also for others.
> @@ -63,10 +63,11 @@ the remote repository.
> The special refspec `:` (or `{plus}:` to allow non-fast forward updates)
> directs git to push "matching" branches: for every branch that exists on
> the local side, the remote side is updated if a branch of the same name
> -already exists on the remote side. This is the default operation mode
> +already exists on the remote side. Nothing will be pushed
The two spaces after the full stop were not actually a typo.
> if no explicit refspec is found (that is neither on the command line
> nor in any Push line of the corresponding remotes file---see below).
>
> +
> --all::
Please do not change the style of the surrounding text. We do not have
double empty lines there.
> diff --git a/builtin-push.c b/builtin-push.c
> index 122fdcf..ffc648d 100644
> --- a/builtin-push.c
> +++ b/builtin-push.c
> @@ -48,6 +48,12 @@ static void set_refspecs(const char **refs, int nr)
> }
> }
>
> +
> +static int has_multiple_bits(unsigned int x)
> +{
> + return (x & (x - 1)) != 0;
> +}
> +
> static int do_push(const char *repo, int flags)
To spare you searching: HAS_MULTI_BITS(x) (it is defined in
git-compat-util.h).
And by removing your function, you also remove another double empty line.
> @@ -71,17 +77,24 @@ static int do_push(const char *repo, int flags)
> return error("--mirror can't be combined with refspecs");
> }
>
> - if ((flags & (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) ==
> - (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) {
> - return error("--all and --mirror are incompatible");
> + if (has_multiple_bits(flags & (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR | TRANSPORT_PUSH_MATCHING))) {
> + return error("--all, --mirror and --matching are incompatible");
These are awfully long lines. Not so good.
> }
>
> - if (!refspec
> - && !(flags & TRANSPORT_PUSH_ALL)
> - && remote->push_refspec_nr) {
> - refspec = remote->push_refspec;
> - refspec_nr = remote->push_refspec_nr;
> + if ((flags & TRANSPORT_PUSH_MATCHING) && refspec) {
> + return error("--matching cannot be combined with refspecs");
> }
> +
> +
Yet another double empty line.
> + if (!refspec && !(flags & TRANSPORT_PUSH_ALL)) {
> + if (remote->push_refspec_nr) {
> + refspec = remote->push_refspec;
> + refspec_nr = remote->push_refspec_nr;
> + } else if (!(flags & TRANSPORT_PUSH_MATCHING)) {
> + return error("No refspecs given and none configured for %s, nothing to push.", remote->name);
> + }
Long line and surplus curly brackets.
Just to make it clear, because many people misunderstand my comments: I
would not have spent my precious time writing this email if I did not
think that --matching is something we want to have.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Junio C Hamano @ 2009-03-06 10:32 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sverre Rabbelier, markus.heidelberg, Finn Arne Gangstad, git,
John Tapsell, Andreas Ericsson
In-Reply-To: <alpine.DEB.1.00.0903061124000.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
>
>> On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
>> <markus.heidelberg@web.de> wrote:
>> > Oh, I confused "config option" with "command line argument"...
>>
>> Right, I'd like to be able to do:
>> $ git config push.iamnotretarded true
>> $ git push
>
> LOL! Sverre, you have a way to crack me up...
I found it amusing, too.
It may have some correlation with how well organized your work habit is,
but I do not think it has much correlation with being retarded. It is
more about "'matching refs' is the perfect default for _my_ use pattern,
don't mess with it, please".
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Johannes Schindelin @ 2009-03-06 10:24 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: markus.heidelberg, Finn Arne Gangstad, git, John Tapsell,
Andreas Ericsson
In-Reply-To: <fabb9a1e0903051426p1222f151s8f466abf319706da@mail.gmail.com>
Hi,
On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
> On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
> <markus.heidelberg@web.de> wrote:
> > Oh, I confused "config option" with "command line argument"...
>
> Right, I'd like to be able to do:
> $ git config push.iamnotretarded true
> $ git push
LOL! Sverre, you have a way to crack me up...
Snickering,
Dscho
^ permalink raw reply
* [PATCH v4] git-p4: improve performance with large files
From: Sam Hocevar @ 2009-03-06 10:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vfxhrt2by.fsf@gitster.siamese.dyndns.org>
On Fri, Mar 06, 2009, Junio C Hamano wrote:
> Sorry, but that's not a commit log message, so signing it off does not add
> much value to the patch.
I'm sorry, for some reason git format-patch is eating my commit
messages (other commits appear just fine). As I'm doing this from a
Windows machine, I smell CR/LF issues in msysgit. Here is a clean
version:
git-p4: improve performance when importing huge files by reducing
the number of string concatenations while constraining memory usage.
Signed-off-by: Sam Hocevar <sam@zoy.org>
---
contrib/fast-import/git-p4 | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3832f60..db0ea0a 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -984,11 +984,22 @@ class P4Sync(Command):
while j < len(filedata):
stat = filedata[j]
j += 1
+ data = []
text = ''
+ # Append data every 8192 chunks to 1) ensure decent performance
+ # by not making too many string concatenations and 2) avoid
+ # excessive memory usage by purging "data" often enough. p4
+ # sends 4k chunks, so we should not use more than 32 MiB of
+ # additional memory while rebuilding the file data.
while j < len(filedata) and filedata[j]['code'] in ('text', 'unicod
e', 'binary'):
- text += filedata[j]['data']
+ data.append(filedata[j]['data'])
del filedata[j]['data']
+ if len(data) > 8192:
+ text += ''.join(data)
+ data = []
j += 1
+ text += ''.join(data)
+ data = None
if not stat.has_key('depotFile'):
sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
--
Sam.
^ permalink raw reply related
* [PATCH v2 2/2] MinGW: 64-bit file offsets
From: Johannes Schindelin @ 2009-03-06 9:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Johannes Sixt
In-Reply-To: <alpine.DEB.1.00.0903061048220.10279@pacific.mpi-cbg.de>
The type 'off_t' should be used everywhere so that the bit-depth of that
type can be adjusted in the standard C library, and you just need to
recompile your program to benefit from the extended precision.
Only that it was not done that way in the MS runtime library.
This patch reroutes off_t to off64_t and provides the other necessary
changes so that finally, clones larger than 2 gigabyte work on Windows
(provided you are on a file system that allows files larger than 2gb).
Initial patch by Sickboy <sb@dev-heaven.net>.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Johannes Sixt <j6t@kdbg.org>
---
Unchanged since v1 (therefore I dared adding Hannes' ACK).
compat/mingw.c | 8 +++++---
compat/mingw.h | 5 ++++-
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 3dbe6a7..27bcf3f 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -46,7 +46,8 @@ static int do_lstat(const char *file_name, struct stat *buf)
buf->st_uid = 0;
buf->st_nlink = 1;
buf->st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);
- buf->st_size = fdata.nFileSizeLow; /* Can't use nFileSizeHigh, since it's not a stat64 */
+ buf->st_size = fdata.nFileSizeLow |
+ (((off_t)fdata.nFileSizeHigh)<<32);
buf->st_dev = buf->st_rdev = 0; /* not used by Git */
buf->st_atime = filetime_to_time_t(&(fdata.ftLastAccessTime));
buf->st_mtime = filetime_to_time_t(&(fdata.ftLastWriteTime));
@@ -101,7 +102,7 @@ int mingw_fstat(int fd, struct stat *buf)
}
/* direct non-file handles to MS's fstat() */
if (GetFileType(fh) != FILE_TYPE_DISK)
- return fstat(fd, buf);
+ return _fstati64(fd, buf);
if (GetFileInformationByHandle(fh, &fdata)) {
buf->st_ino = 0;
@@ -109,7 +110,8 @@ int mingw_fstat(int fd, struct stat *buf)
buf->st_uid = 0;
buf->st_nlink = 1;
buf->st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);
- buf->st_size = fdata.nFileSizeLow; /* Can't use nFileSizeHigh, since it's not a stat64 */
+ buf->st_size = fdata.nFileSizeLow |
+ (((off_t)fdata.nFileSizeHigh)<<32);
buf->st_dev = buf->st_rdev = 0; /* not used by Git */
buf->st_atime = filetime_to_time_t(&(fdata.ftLastAccessTime));
buf->st_mtime = filetime_to_time_t(&(fdata.ftLastWriteTime));
diff --git a/compat/mingw.h b/compat/mingw.h
index a255898..cb9c4d4 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -163,11 +163,14 @@ int mingw_rename(const char*, const char*);
/* Use mingw_lstat() instead of lstat()/stat() and
* mingw_fstat() instead of fstat() on Windows.
*/
+#define off_t off64_t
+#define stat _stati64
+#define lseek _lseeki64
int mingw_lstat(const char *file_name, struct stat *buf);
int mingw_fstat(int fd, struct stat *buf);
#define fstat mingw_fstat
#define lstat mingw_lstat
-#define stat(x,y) mingw_lstat(x,y)
+#define stat64(x,y) mingw_lstat(x,y)
int mingw_utime(const char *file_name, const struct utimbuf *times);
#define utime mingw_utime
--
1.6.2.240.g23c7
^ permalink raw reply related
* [PATCH v2 1/2] Add an (optional, since expensive) test for >2gb clones
From: Johannes Schindelin @ 2009-03-06 9:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Johannes Sixt
In-Reply-To: <7vfxhry3da.fsf@gitster.siamese.dyndns.org>
Define GIT_TEST_CLONE_2GB=t if you want the test not to be skipped.
The test works by constructing a repository larger than 2gb, and then
cloning it.
The repository is forced larger than 2gb by setting compression and
delta depth to zero, and then adding just enough unique objects of
a given size.
The objects consist of a running decimal number in ASCII, padded by
spaces. Should that break in the future, e.g. when pack v4 becomes
default, there is a commented-out call to test-genrandom which can be
substituted, but that uses more cycles than the current method.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Changes since v1: fixed && chain, better commit message.
t/t5705-clone-2gb.sh | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
create mode 100755 t/t5705-clone-2gb.sh
diff --git a/t/t5705-clone-2gb.sh b/t/t5705-clone-2gb.sh
new file mode 100755
index 0000000..9f52154
--- /dev/null
+++ b/t/t5705-clone-2gb.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+test_description='Test cloning a repository larger than 2 gigabyte'
+. ./test-lib.sh
+
+test -z "$GIT_TEST_CLONE_2GB" &&
+say "Skipping expensive 2GB clone test; enable it with GIT_TEST_CLONE_2GB=t" &&
+test_done &&
+exit
+
+test_expect_success 'setup' '
+
+ git config pack.compression 0 &&
+ git config pack.depth 0 &&
+ blobsize=$((20*1024*1024)) &&
+ blobcount=$((2*1024*1024*1024/$blobsize+1)) &&
+ i=1 &&
+ (while test $i -le $blobcount
+ do
+ printf "Generating blob $i/$blobcount\r" >&2 &&
+ printf "blob\nmark :$i\ndata $blobsize\n" &&
+ #test-genrandom $i $blobsize &&
+ printf "%-${blobsize}s" $i &&
+ echo "M 100644 :$i $i" >> commit
+ i=$(($i+1)) ||
+ echo $? > exit-status
+ done &&
+ echo "commit refs/heads/master" &&
+ echo "author A U Thor <author@email.com> 123456789 +0000" &&
+ echo "committer C O Mitter <committer@email.com> 123456789 +0000" &&
+ echo "data 5" &&
+ echo ">2gb" &&
+ cat commit) |
+ git fast-import &&
+ test ! -f exit-status
+
+'
+
+test_expect_success 'clone' '
+
+ git clone --bare --no-hardlinks . clone
+
+'
+
+test_done
--
1.6.2.240.g23c7
^ permalink raw reply related
* Re: What's in git.git (Mar 2009, #03; Fri, 06)
From: Junio C Hamano @ 2009-03-06 9:44 UTC (permalink / raw)
To: git
In-Reply-To: <7vocwft5tx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Quite a many topics that have been scheduled for 'master' for some time
> have all graduated. With this pace we may be able to have a very short
> cycle for a change before 1.6.3 final ;-).
People who have been following the 'next' branch during 1.6.2 rc period
may already know these, but here is how the tip of 'master' looks like as
of tonight (an excerpt from the draft release notes to 1.6.3).
Updates since v1.6.2 so far
---------------------------
(usability, bells and whistles)
* "--pretty=<style>" option to the log family of commands can now be
spelled as "--format=<style>". In addition, --format=%formatstring
is a short-hand for --pretty=tformat:%formatstring.
* "--oneline" is a synonym for "--pretty=oneline --abbrev=commit".
* If you realize that you botched the patch when you are editing hunks
with the 'edit' action in git-add -i/-p, you can abort the editor to
tell git not to apply it.
* git-archive learned --output=<file> option.
* git-bisect shows not just the number of remaining commits whose goodness
is unknown, but also shows the estimated number of remaining rounds.
* git-branch -r shows HEAD symref that points at a remote branch in
interest of each tracked remote repository.
* git-config learned -e option to open an editor to edit the config file
directly.
* git-format-patch can be told to use attachment with a new configuration,
format.attach.
* git-imap-send learned to work around Thunderbird's inability to easily
disable format=flowed with a new configuration, imap.preformattedHTML.
* git-rebase can be told to rebase the series even if your branch is a
descendant of the commit you are rebasing onto with --force-rebase
option.
* git-send-email learned --confirm option to review the Cc: list before
sending the messages out.
(developers)
* Test scripts can be run under valgrind.
Fixes since v1.6.2 so far
-------------------------
All of the fixes in v1.6.2.X maintenance series are included in this
release, unless otherwise noted.
Here are fixes that this release has, but have not been backported to
v1.6.2.X series.
* .gitignore learned to handle backslash as a quoting mechanism for
comment introduction character "#" (backport by merging dd482ee if
needed).
* timestamp output in --date=relative mode used to display timestamps that
are long time ago in the default mode; it now uses "N years M months
ago", and "N years ago" (backport by picking 10edf37 if needed).
* git-add -i/-p now works with non-ASCII pathnames (backport by picking
8851f48 if needed).
* "git hash-object -w" did not read from the configuration file from the
correct .git directory (backport by merging 272459a if needed).
* git-send-email learned to correctly handle multiple Cc: addresses
(backport by merging afe756c if needed).
^ permalink raw reply
* Re: [PATCH] git-p4: improve performance with large files
From: Junio C Hamano @ 2009-03-06 9:42 UTC (permalink / raw)
To: git
In-Reply-To: <20090306085357.GA12880@zoy.org>
Sam Hocevar <sam@zoy.org> writes:
> On Thu, Mar 05, 2009, Han-Wen Nienhuys wrote:
>
>> i'd say
>>
>> data = []
>>
>> add a comment that you're trying to save memory. There is no reason to
>> remove data from the namespace.
>
> Okay. Here is an improved version.
>
> Signed-off-by: Sam Hocevar <sam@zoy.org>
Sorry, but that's not a commit log message, so signing it off does not add
much value to the patch.
^ permalink raw reply
* [PATCH] Documentation: More examples for git bisect
From: John Tapsell @ 2009-03-06 9:37 UTC (permalink / raw)
To: git; +Cc: John Tapsell
Including passing parameters to the programs, and running more
complicated checks without requiring a seperate shell script.
Signed-off-by: John Tapsell <johnflux@gmail.com>
---
Documentation/git-bisect.txt | 27 ++++++++++++++++++++++++++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 147ea38..7b8cfdd 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -212,7 +212,7 @@ If you have a script that can tell if the current source code is good
or bad, you can automatically bisect using:
------------
-$ git bisect run my_script
+$ git bisect run my_script arguments
------------
Note that the "run" script (`my_script` in the above example) should
@@ -251,6 +251,22 @@ EXAMPLES
$ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good
$ git bisect run make # "make" builds the app
------------
++
+This looks for the first revision that fails to build between HEAD and
+the tag 'v1.2'.
+
+* Automatically bisect a test failure between origin and HEAD:
++
+------------
+$ git bisect start HEAD origin -- # HEAD is bad, origin is good
+$ git bisect run make test # "make test" builds and tests
+------------
++
+This looks for the first revision that 'make test' fails for, assuming that
+you have such a Makefile rule, and that 'make test' also builds the source code.
+Note however that if the source fails to build, this will be treated as a bad
+commit. This may not be what you intend, so the following examples instead
+treat build failures as commits to skip.
* Automatically bisect a broken test suite:
+
@@ -291,6 +307,15 @@ It's safer if both "test.sh" and "check_test_case.sh" scripts are
outside the repo to prevent interactions between the bisect, make and
test processes and the scripts.
+* Automatically bisect a broken test suite, simplified version:
++
+------------
+$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
+$ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
+------------
++
+Does the same as the previous example, but on a single line.
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
--
1.6.2.97.g034f.dirty
^ permalink raw reply related
* Re: orthogonal cases of log --date option
From: Junio C Hamano @ 2009-03-06 8:58 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, Miles Bader, git
In-Reply-To: <76718490903060031u2bbc5c08k6a635dcdb1c8bc32@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Yeah, that part is easy. I wasn't sure the best way to handle places
> where a constant date_mode is used e.g.:
>
> pp_user_info(NULL, CMIT_FMT_EMAIL, &sb, committer, DATE_RFC2822,
> encoding);
One approach that will be hated by libgit2 effort would be to keep the
date_mode an enum as before (sans DATE_LOCAL) and make the "tz_offset"
thing as a setting global to the process, defined in environ.c
^ permalink raw reply
* Re: [PATCH] git-p4: improve performance with large files
From: Sam Hocevar @ 2009-03-06 8:53 UTC (permalink / raw)
To: git
In-Reply-To: <1d48f7010903051725v510f99f0h2a05b9381ff75ac1@mail.gmail.com>
On Thu, Mar 05, 2009, Han-Wen Nienhuys wrote:
> i'd say
>
> data = []
>
> add a comment that you're trying to save memory. There is no reason to
> remove data from the namespace.
Okay. Here is an improved version.
Signed-off-by: Sam Hocevar <sam@zoy.org>
---
contrib/fast-import/git-p4 | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3832f60..db0ea0a 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -984,11 +984,22 @@ class P4Sync(Command):
while j < len(filedata):
stat = filedata[j]
j += 1
+ data = []
text = ''
+ # Append data every 8192 chunks to 1) ensure decent performance
+ # by not making too many string concatenations and 2) avoid
+ # excessive memory usage by purging "data" often enough. p4
+ # sends 4k chunks, so we should not use more than 32 MiB of
+ # additional memory while rebuilding the file data.
while j < len(filedata) and filedata[j]['code'] in ('text', 'unicod
e', 'binary'):
- text += filedata[j]['data']
+ data.append(filedata[j]['data'])
del filedata[j]['data']
+ if len(data) > 8192:
+ text += ''.join(data)
+ data = []
j += 1
+ text += ''.join(data)
+ data = None
if not stat.has_key('depotFile'):
sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
--
Sam.
^ permalink raw reply related
* Re: orthogonal cases of log --date option
From: Jay Soffian @ 2009-03-06 8:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Miles Bader, git
In-Reply-To: <7v1vtbw03h.fsf@gitster.siamese.dyndns.org>
On Fri, Mar 6, 2009 at 3:02 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Is it? Isn't it just the matter of doing something like this?
>
> struct date_mode {
> enum {
> DATE_NORMAL = 0,
> DATE_RELATIVE,
> ...
> DATE_RAW
> } format;
> enum {
> DATE_ORIGINAL = 0,
> DATE_LOCAL
> /* perhaps ",DATE_GMT" later... */
> } tz_offset;
> };
>
> /* In revision.c::handle_revision_opt() */
> ...
> } else if (!strcmp(arg, "--date=local")) {
> revs->date_mode.format = DATE_NORMAL;
> revs->date_mode.tz_offset = DATE_LOCAL;
> } else if (!prefixcmp(arg, "--date=")) {
> revs->date_mode.format = parse_date_format(arg + 7);
> } else if (!strcmp(arg, "--tz=local")) {
> revs->date_mode.tz_offset = DATE_LOCAL;
> }
> ...
>
> /* In date.c::show_date() */
> ...
> const char *show_date(unsigned long time, int tz, struct date_mode *mode_)
> {
> int mode = mode_->format;
>
> if (mode_->tz_offset == DATE_LOCAL)
> tz = local_tzoffset(time);
>
> ...
> /* and remove the existing
> if (mode == DATE_LOCAL)
> tz = local_tzoffset(time);
> that appears later in the code
> */
> ...
Yeah, that part is easy. I wasn't sure the best way to handle places
where a constant date_mode is used e.g.:
pp_user_info(NULL, CMIT_FMT_EMAIL, &sb, committer, DATE_RFC2822,
encoding);
I had started on:
static const struct date_mode date_rfc2822 = {DATE_RFC2822, DATE_ORIGINAL};
...
pp_user_info(NULL, CMIT_FMT_EMAIL, &sb, committer, &date_rfc2822,
encoding);
But I imagine there's maybe a better way to do that.
j.
^ permalink raw reply
* Re: Using Git with windows
From: John Chapman @ 2009-03-06 8:16 UTC (permalink / raw)
To: Tariq Hassanen; +Cc: git
In-Reply-To: <e878dbad0903052323m56f3d63fi69862e9dae278c00@mail.gmail.com>
(Hmm, don't know why evolution didn't quote the message...)
Tariq, while git is heaps nicer and better on Linux, it works quite well
on windows as well, and is reasonably mature.
Just be sure to be aware of autocrlf, and that on windows with msysgit,
it is enabled by default.
- Also, if you use the cygwin version instead, be aware that applying
patches, etc, can get /funky/ when cygwin is using unix line endings,
but your development environment doesn't. Again, be very aware of line
endings.
Unless you think your repository will become larger than 2GB (Not
likely), then msysgit will do just fine.
Running git under linux in vmware will be faster, but not worth the
bother, in my opinion.
^ permalink raw reply
* What's in git.git (Mar 2009, #03; Fri, 06)
From: Junio C Hamano @ 2009-03-06 8:26 UTC (permalink / raw)
To: git
Quite a many topics that have been scheduled for 'master' for some time
have all graduated. With this pace we may be able to have a very short
cycle for a change before 1.6.3 final ;-).
* The 'master' branch has these since the last announcement.
Arjen Laarhoven (2):
Clean up use of ANSI color sequences
builtin-branch.c: Rename branch category color names
Deskin Miller (1):
add -i: revisit hunk on editor failure
Elijah Newren (1):
Ensure proper setup of git_dir for git-hash-object
Felipe Contreras (3):
config: Add new option to open an editor.
git config: codestyle cleanups
Add tests for git log --pretty, --format and --oneline.
Finn Arne Gangstad (1):
Support "\" in non-wildcard exclusion entries
Jay Soffian (6):
builtin-branch: improve output when displaying remote branches
send-email: allow send-email to run outside a repo
send-email: handle multiple Cc addresses when reading mbox message
send-email: --suppress-cc improvements
send-email: don't create temporary compose file until it is needed
send-email: add --confirm option and configuration setting
Jeff King (4):
valgrind: ignore ldso and more libz errors
branch: clean up repeated strlen
add basic branch display tests
never fallback relative times to absolute
Jeremy White (2):
Enable setting attach as the default in .gitconfig for git-format-patch.
imap.preformattedHTML to tell Thunderbird to send non-flowed text
Johannes Schindelin (11):
Add valgrind support in test scripts
Valgrind support: check for more than just programming errors
test-lib.sh: optionally output to test-results/$TEST.out, too
t/Makefile: provide a 'valgrind' target
Add a script to coalesce the valgrind outputs
Tests: let --valgrind imply --verbose and --tee
test-lib: avoid assuming that templates/ are in the GIT_EXEC_PATH
valgrind: do not require valgrind 3.4.0 or newer
Avoid segfault with 'git branch' when the HEAD is detached
git config: trivial cleanup for editor action
MinGW: 64-bit file offsets
John Tapsell (1):
Documentation - More examples for git bisect
Junio C Hamano (4):
git-blame: refactor code to emit "porcelain format" output
blame: show "previous" information in --porcelain/--incremental format
git-add -i/-p: learn to unwrap C-quoted paths
Draft release notes: Carry forward the warning for behaviour changes
Marius Storm-Olsen (2):
Add bare repository indicator for __git_ps1
Fixup: Add bare repository indicator for __git_ps1
Nanako Shiraishi (3):
Add --format that is a synonym to --pretty
Give short-hands to --pretty=tformat:%formatstring
Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit"
SZEDER Gábor (1):
rerere: remove duplicated functions
Sverre Rabbelier (1):
Teach rebase to rebase even if upstream is up to date
Ted Pavlic (4):
completion: For consistency, change "git rev-parse" to __gitdir calls
completion: Use consistent if [...] convention, not "test"
completion: Better __git_ps1 support when not in working directory
completion: More fixes to prevent unbound variable errors
Teemu Likonen (1):
bash completion: add --format= and --oneline options for "git log"
^ 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