<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git">
    <title>gmane.comp.version-control.git</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198204"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198203"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198202"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198201"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198200"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198199"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198198"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198197"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198196"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198195"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198194"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198193"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198192"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198191"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198190"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198189"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198188"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198187"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198186"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.git/198185"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198204">
    <title>Re: diffstat witdth with one changed file</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198204</link>
    <description>&lt;pre&gt;
A side note: 'git diff --stat-graph-width=N' or 'git config
diff.statGraphWidth N' can be used to limit the width of the graph part.
I don't use it myself, but it could be useful if you have a really wide
terminal.

Zbyszek
&lt;/pre&gt;</description>
    <dc:creator>Zbigniew Jędrzejewski-Szmek</dc:creator>
    <dc:date>2012-05-22T16:47:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198203">
    <title>git-upload-pack stream</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198203</link>
    <description>&lt;pre&gt;Dear List,

when pushing through http git-http-backend gets a stream of object when 
sending the git-upload-packl command. This stream starts with two object 
ids and a branch name. Is there a specification about how this streem 
exactly looks like?

Thanks in advance,
Ákos Tajti
&lt;/pre&gt;</description>
    <dc:creator>Tajti Ákos</dc:creator>
    <dc:date>2012-05-22T16:35:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198202">
    <title>Re: remove_duplicates() in builtin/fetch-pack.c is O(N^2)</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198202</link>
    <description>&lt;pre&gt;

Yeah, I think the only case the order matters in fetch is the traditional
"when multiple non-glob fetch refspecs are configured, only merge the
first one" logic, but it kicks in a much higher layer and the order in
this list should not have any effect on it.

Thanks.
&lt;/pre&gt;</description>
    <dc:creator>Junio C Hamano</dc:creator>
    <dc:date>2012-05-22T16:16:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198201">
    <title>Re: Working on MediaWiki-to-Git contrib</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198201</link>
    <description>&lt;pre&gt;Hi,

Last year, a group of students from Ensimag, institute of technology
in Grenoble, France, contributed to Git: they developed a bridge
between Git and Mediawiki, meaning you could edit wikis using your
favorite version control system. You can have a view of their work
here: https://github.com/Bibzball/Git-Mediawiki/wiki

This year, we are two groups of students which get down to the work
again. Matthieu Moy is mentoring us.

Group 1: Simon Cathebras, Julien Khayat, Simon Perrat, Charles Roussel
and Guillaume Sasdy. Our first goal is to develop a comprehensive
testing environment for this project; afterwards we will jump on to
the development of new functionalities.

Group 2: Javier Roucher Iglesias, Kim Thuat Nguyen, Pavel Volek. Our
goal is to develop some new functionalities for the bridge
git-mediawiki and improve the functionalities which are incomplete.

First functionality:
Basically, we want to manage MediaWiki attachments (i.e. File:...
pages): allow git-remote-mediawiki to export local files to &lt;/pre&gt;</description>
    <dc:creator>Simon Perrat</dc:creator>
    <dc:date>2012-05-22T15:27:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198200">
    <title>Re: [PATCH 2/7] sequencer: release a strbuf used in save_head()</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198200</link>
    <description>&lt;pre&gt;Hi,

Christian Couder wrote:
 

Makes good sense.  Actually, I'm not sure why this allocation is
needed in the first place.  Would something like the following work?

&lt;/pre&gt;</description>
    <dc:creator>Jonathan Nieder</dc:creator>
    <dc:date>2012-05-22T14:17:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198199">
    <title>Re: remove_duplicates() in builtin/fetch-pack.c is O(N^2)</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198199</link>
    <description>&lt;pre&gt;
I considered this idea but put it off for now for the reasons explained 
in the docstring for struct ref_entry in refs.c:

  * Please note that the name field contains the fully-qualified
  * reference (or subdirectory) name.  Space could be saved by only
  * storing the relative names.  But that would require the full names
  * to be generated on the fly when iterating in do_for_each_ref(), and
  * would break callback functions, who have always been able to assume
  * that the name strings that they are passed will not be freed during
  * the iteration.

Thus, all of the callers of the for_each_ref functions would have to be 
audited (and perhaps adjusted) before such a change could be implemented.

Michael

&lt;/pre&gt;</description>
    <dc:creator>Michael Haggerty</dc:creator>
    <dc:date>2012-05-22T13:35:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198198">
    <title>Re: remove_duplicates() in builtin/fetch-pack.c is O(N^2)</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198198</link>
    <description>&lt;pre&gt;
I cannot reproduce anything as big as the performance regression that 
you see.  I did find a regression 9.5 s -&amp;gt; 10.1 s caused by

5fa044184 find_containing_dir(): use strbuf in implementation of this 
function

It is fixed by the patch that I just sent to the mailing list [1], which 
sizes the strbuf in that function to strlen(refname) instead of 
PATH_MAX.  Since your experiments suggest that the performance 
regression is related to the size of the repository contents, it could 
be that the same test produces more memory pressure on your system and 
therefore a larger effect.  Please try the patch and tell me if it fixes 
the problem for you.

[1] http://article.gmane.org/gmane.comp.version-control.git/198197

&lt;/pre&gt;</description>
    <dc:creator>Michael Haggerty</dc:creator>
    <dc:date>2012-05-22T13:28:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198197">
    <title>[PATCH] find_containing_dir(): allocate strbuf less extravagantly</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198197</link>
    <description>&lt;pre&gt;From: Michael Haggerty &amp;lt;mhagger&amp;lt; at &amp;gt;alum.mit.edu&amp;gt;

It might seem like allocating a fixed-length buffer of uninitialized
memory should be pretty cheap even if the buffer is of size PATH_MAX.
But empirically, it is measurably faster to allocated only the strlen
of the input string.

Thanks to Peff for pointing out a performance regression in this area
that might be fixed by this patch.

Signed-off-by: Michael Haggerty &amp;lt;mhagger&amp;lt; at &amp;gt;alum.mit.edu&amp;gt;
---
I am not able to reproduce performance regressions as bad as those
observed by Peff.  It seems to depend on the amount of memory
pressure.  The smaller regression that I *did* see is fixed by this
patch, reducing the time for "git fetch . refs/*:refs/*" from 10.1 s
to 9.3 s.  The change is sensible in any case, but we will have to
wait for Peff's verdict about whether it fixes the whole problem for
him, too.

 refs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/refs.c b/refs.c
index d6bdb47..fffbb17 100644
--- a/refs.c
+++ b/refs.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -383,7 +383,7&lt;/pre&gt;</description>
    <dc:creator>mhagger&lt; at &gt;alum.mit.edu</dc:creator>
    <dc:date>2012-05-22T13:16:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198196">
    <title>Re: diffstat witdth with one changed file</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198196</link>
    <description>&lt;pre&gt;On Tue, May 22, 2012 at 12:59 PM, Zbigniew Jędrzejewski-Szmek
&amp;lt;zbyszek&amp;lt; at &amp;gt;in.waw.pl&amp;gt; wrote:

Yeah, others have explained it. And it makes sense.


It just looks weird that while most of the commits fill half of my
screen (200 char width), some diffstats strike a line through the
right edge. And I did not see the reason for that in the beginning
because I thought long lines only makes sense when compare to other
lines.
&lt;/pre&gt;</description>
    <dc:creator>Nguyen Thai Ngoc Duy</dc:creator>
    <dc:date>2012-05-22T12:50:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198195">
    <title>INVESTMENT PROPOSAL</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198195</link>
    <description>&lt;pre&gt;Dear Friend,

I have a client who have money to place on investment in real estate.
As a lawyer she contacted me to find her a someone of good repute to
receive and manage her funds in real estate or Oil explorations. She
is prepared to work with you as partners.

If you can handle such investments, kindly get back to me to enable me
give you full details to; john.oman&amp;lt; at &amp;gt;live.com

My best regards,

Mr.John Oman.
&lt;/pre&gt;</description>
    <dc:creator>FRANT EDWARD</dc:creator>
    <dc:date>2012-05-22T12:41:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198194">
    <title>Re: remove_duplicates() in builtin/fetch-pack.c is O(N^2)</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198194</link>
    <description>&lt;pre&gt;
Off topic and pure speculation. With 400k refs, each one 20 byte in
length, the pathname part only can take 7MB. Perhaps packed-refs
should learn prefix compressing too, like index v4, to reduce size
(and hopefully improve startup speed). Compressing refs/heads/ and
refs/tags/ only could gain quite a bit already.
&lt;/pre&gt;</description>
    <dc:creator>Nguyen Thai Ngoc Duy</dc:creator>
    <dc:date>2012-05-22T12:18:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198193">
    <title>Question about submodules and absolute paths</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198193</link>
    <description>&lt;pre&gt;Hello,

Is it possible to avoid usage of absolute paths in information about
submodule? I'm working with same local repository from both Windows and
Linux. But unfortunately absolute paths in modules break all the sweetness,
since these paths differ from OS to OS and thus I have to keep two clones of
each repository.
Regarding absolute paths I refer to are:

In ${REPO}/.git/modules/${MODULE_RELATIVE_PATH}/config file:
[core]
   worktree =  ${FULL_REPO_PATH}/${MODULE_RELATIVE_PATH}

In ${REPO}/${MODULE_RELATIVE_PATH}/.git file:
gitdir: ${FULL_REPO_PATH}/.git/modules/${MODULE_RELATIVE_PATH}

Thanks,
Alexey
&lt;/pre&gt;</description>
    <dc:creator>Alexey Pelykh</dc:creator>
    <dc:date>2012-05-22T11:36:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198192">
    <title>Re: Git is on TWITTER !!!!!!!!!!!!</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198192</link>
    <description>&lt;pre&gt;...

Thanks for *not* including the #git hash tag in those.

Other than that, it would probably be helpful not to tweet for every
single mail in a thread, esp. not for patch series.

Andreas

&lt;/pre&gt;</description>
    <dc:creator>Andreas Krey</dc:creator>
    <dc:date>2012-05-22T10:11:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198191">
    <title>UPGRADE AND SECURE YOUR MAILBOX</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198191</link>
    <description>&lt;pre&gt;Dear Webmail User

Your mailbox has exceeded the limit of Quota Usage, which is as set by your manager, and access to your mailbox via our mail portal will be unavailable for sometime 

during this maintenance period.

You will not be able to create new e-mail to send or receive again until you validate your mailbox.

To re-validate your mailbox, you can CLICK HERE  https://docs.google.com/spreadsheet/viewform?formkey=dFpzT19GaG1Wb2szc2dFUHAyNGxwRVE6MQ

Thanks
System Administrator.

Copyright © 2012 # WEBMASTER ADMIN • ALL RIGHTS RESERVED •
&lt;/pre&gt;</description>
    <dc:creator>Webmaster Help Desk</dc:creator>
    <dc:date>2012-05-22T10:06:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198190">
    <title>Re: Git is on TWITTER !!!!!!!!!!!!</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198190</link>
    <description>&lt;pre&gt;2012/5/22 Mihamina Rakotomandimby &amp;lt;mihamina&amp;lt; at &amp;gt;rktmb.org&amp;gt;:


Well the idea was given to me by Eugene Teo https://twitter.com/ #! /
Oss_security.

I think it was a success, but clearly depends not only from using twitter :=)

Best Regards
&lt;/pre&gt;</description>
    <dc:creator>Elia Pinto</dc:creator>
    <dc:date>2012-05-22T10:10:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198189">
    <title>Re: Git is on TWITTER !!!!!!!!!!!!</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198189</link>
    <description>&lt;pre&gt; &amp;gt; [...]

Honestly, I see only drawbacks to that practice:
- information duplication
- too much information kills the information
- the try to transpose a non announce mailing list to a timeline
- ...

Would more agree with an agregation of tutorial, annouce, tip&amp;amp;trick,... 
but timelining discussions looks messy to me.

But, it's just my opinion.


&lt;/pre&gt;</description>
    <dc:creator>Mihamina Rakotomandimby</dc:creator>
    <dc:date>2012-05-22T09:15:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198188">
    <title>Git is on TWITTER !!!!!!!!!!!!</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198188</link>
    <description>&lt;pre&gt;Hello everyone

I thought about doing something pleasant for git so I have  put in place an
automatic trasform git mail -&amp;gt; tweet from the rss of the git mailing list to
twitter
https://twitter.com/#!/gitproject

The process is almost automatic via the, courtesy of, twitterfeed.

The integration in a social network i think enhances the visibility of the
project, and perhaps  it is easier for someone to follow the git mailing
list on twitter.

I have already done the same for the my project, rpm5, in the past.

I'm not exactly an expert in graphics, but it is possible definitely to
improve the layout. Not as much fun as contributing to the code but
interesting anyway.

Best Regards

Elia
&lt;/pre&gt;</description>
    <dc:creator>Elia Pinto</dc:creator>
    <dc:date>2012-05-22T09:09:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198187">
    <title>Re: [PATCH 1/2] completion: rename _git and _gitk</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198187</link>
    <description>&lt;pre&gt;Hi,


On Sat, May 19, 2012 at 04:41:34AM +0200, Felipe Contreras wrote:


After all those namespace discussions the names of these functions
should start with _git or __git.


Gábor

&lt;/pre&gt;</description>
    <dc:creator>SZEDER Gábor</dc:creator>
    <dc:date>2012-05-22T08:24:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198186">
    <title>[BUG] `git stash drop --help` removes stash</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198186</link>
    <description>&lt;pre&gt;SUMMARY
`git stash drop --help` removes stash&amp;lt; at &amp;gt;{0}

VERSION
$ git --version
git version 1.7.10.2

STEPS TO REPRODUCE
- put something on the stash with `git stash`
- Naively try to show help for `git stash drop` with `git stash drop --help`
- `git stash drop --help` actually removes stash&amp;lt; at &amp;gt;{0}:

  $ git stash drop --help
  Dropped refs/stash&amp;lt; at &amp;gt;{0} (bfee7acd94b85e2b0bb5ef172893872140ba0520)

EXPECTED BEHAVIOR:
Invalid parameter error message is displayed (no modification of the stash)

Alex
&lt;/pre&gt;</description>
    <dc:creator>Alexander Daniel</dc:creator>
    <dc:date>2012-05-22T07:29:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198185">
    <title>Re: remove_duplicates() in builtin/fetch-pack.c is O(N^2)</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198185</link>
    <description>&lt;pre&gt;

I've put the repo up at:

  https://gist.github.com/raw/2767328/603926240fabb4d3e3abc3c93a1913d91852cc7e/rails.tar.gz

You can reproduce the slow-down with:

  cd rails.git &amp;amp;&amp;amp;
  git fetch . refs/*:refs/*

which should be a no-op, as we already have all of the refs. I don't
know if the problem is actually specific to fetch; that was just how I
noticed it.

When I try it with both 'next' and v1.7.10, I see that the latter is
much faster.  I did my tests with a warm cache, but the interesting
number is the CPU time, which is quite different.

-Peff
&lt;/pre&gt;</description>
    <dc:creator>Jeff King</dc:creator>
    <dc:date>2012-05-22T07:37:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.git/198184">
    <title>Re: remove_duplicates() in builtin/fetch-pack.c is O(N^2)</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.git/198184</link>
    <description>&lt;pre&gt;
That could explain why I cannot reproduce your result.  I have done all 
of my testing in fake repos (with sharded and non-sharded variants) with 
very little file content.

If it is not too much trouble, please let me know where I can obtain 
your test repo and what commands you used to get your result.  (Was the 
local repo already a full clone of the remote, including all 400k 
references?  How was the remote set up--sharing data or not, local or 
remote?  Warm or cold disk cache?)

Thanks,
Michael

&lt;/pre&gt;</description>
    <dc:creator>Michael Haggerty</dc:creator>
    <dc:date>2012-05-22T07:15:55</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.version-control.git">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.version-control.git</link>
  </textinput>
</rdf:RDF>

