<?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://blog.gmane.org/gmane.comp.version-control.git">
    <title>gmane.comp.version-control.git</title>
    <link>http://blog.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://comments.gmane.org/gmane.comp.version-control.git/198568"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198567"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198564"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198563"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198553"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198550"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198545"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198535"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198534"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198533"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198530"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198526"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198525"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198519"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198511"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198497"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198482"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198481"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198480"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.git/198478"/>
      </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://comments.gmane.org/gmane.comp.version-control.git/198568">
    <title>(unknown)</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198568</link>
    <description>&lt;pre&gt;Hello,
How are you and how is your work hope all is moving fine.i seek for honest 
partner and i meet you on was interesting and attractive then i drop by to know 
who this was, i will like to know more about you. if you wouldn't mind you can 
email me at my mail.

i will be very glad to read your mail with all pleasure. it will be nice to 
meet you and also read from you. 

i wait to hear from you soon.

kiss regards Miss
Judith.
&lt;/pre&gt;</description>
    <dc:creator>Judith Collins</dc:creator>
    <dc:date>2012-05-26T20:47:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198567">
    <title>[PATCH] t7403-*.sh: Avoid use of the nonportable '==' operator</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198567</link>
    <description>&lt;pre&gt;
Some shells, including dash, do not support using the '==' string
equality operator. This results in the failure of tests 7-12 with
'test' complaining of an "unexpected operator".

In order to suppress the errors, we replace the '==' operator with
'=', which must be supported by any POSIX shell.

Signed-off-by: Ramsay Jones &amp;lt;ramsay&amp;lt; at &amp;gt;ramsay1.demon.co.uk&amp;gt;
---

Hi Jon,

If you need to re-roll your patches from the 'js/submodule-relative'
branch (commits 3f4542e and efa4c90), could you please squash this
fix into them.

Thanks!

ATB,
Ramsay Jones

 t/t7403-submodule-sync.sh |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh
index 583fe21..3d85739 100755
--- a/t/t7403-submodule-sync.sh
+++ b/t/t7403-submodule-sync.sh
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -93,7 +93,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; test_expect_success '"git submodule sync" handles origin URL of the form foo' '
  git remote set-url origin foo
  git submodule sync &amp;amp;&amp;amp;
 (cd submodule &amp;amp;&amp;amp;
- test "$(git config remote.origin.url)&lt;/pre&gt;</description>
    <dc:creator>Ramsay Jones</dc:creator>
    <dc:date>2012-05-26T16:51:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198564">
    <title>[PATCH] Implement --messages-prog parameter in git-svn</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198564</link>
    <description>&lt;pre&gt;Some SVN repositories have strange policies for commit messages requiring an
empty line at the top of the commit message.  When you clone these
repositories with Git to mirror them on GitHub then no commit message
summaries are displayed at all at GitHub because they use the first line for
it (Which is empty).  You always have to open the commit message details
instead which is pretty annoying.  With the --messages-prog parameter you
can specify a program which can modify the SVN commit message before
committing it into the Git repo.  This works like the --authors-prog
parameter with the only difference that the commit message is piped into the
specified program instead of being passed to it as a command-line argument.

The same could be achieved by a "trim" feature but specifying a program
which can modify any aspect of a commit message is much more flexible.

Signed-off-by: Klaus Reimer &amp;lt;k&amp;lt; at &amp;gt;ailis.de&amp;gt;
---
 Documentation/git-svn.txt        |  5 +++++
 git-svn.perl                     | 26 ++++++++++++++++++++&lt;/pre&gt;</description>
    <dc:creator>Klaus Reimer</dc:creator>
    <dc:date>2012-05-26T15:56:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198563">
    <title>git-http-backend with hooks</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198563</link>
    <description>&lt;pre&gt;dear list,

we wrote a script that is basically a proxy before git-http-backend. All 
git requests go through this and if some criteria is true then they're 
passed to git-http-backend. We also have hooks in our repositories. The 
problem is that in some cases we don't want the hooks to run. Is it 
possible to somehow tell git-http-backend that the hooks shouldn't be run?

thanks in advance,
ákos tajti
&lt;/pre&gt;</description>
    <dc:creator>Tajti Ákos</dc:creator>
    <dc:date>2012-05-26T14:11:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198553">
    <title>[PATCH WIP 0/3] top-level gitignore considered less harmful</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198553</link>
    <description>&lt;pre&gt;While my mind is still fresh on exclude stuff, let's do something
to improve the big top-level gitignore situation [1].

The last patch is the real meat, where it assumes caller calls it on a
series of pathnames of the same dirname. It'll cache strcmp result of
the dirname part so we only pay the cost once per pattern for all
entries in the same directory.

The result is not so impressive (i'm on -O0 though). Old webkit.git,
before:

real    0m6.418s
user    0m5.561s
sys     0m0.827s

after:

real    0m5.262s
user    0m4.407s
sys     0m0.850s

We could approach the problem a different way instead: push back as
much dirname as possible back to "(struct exclude*)-&amp;gt;base", but I'm
afraid that may mess thing up with all the pushing/popping in
prep_exclude.

Also about that, we should not need to call prep_exclude() on every
pathname, at least when the caller is {fill,read}_directory().

There's another optimaztion we could do to pay even less. If users
sort the exclude patterns, if we check dirname of one pattern&lt;/pre&gt;</description>
    <dc:creator>Nguyễn Thái Ngọc Duy</dc:creator>
    <dc:date>2012-05-26T12:31:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198550">
    <title>[PATCH] pack-objects: use streaming interface for reading large loose blobs</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198550</link>
    <description>&lt;pre&gt;git usually streams large blobs directly to packs. But there are cases
where git can create large loose blobs (unpack-objects or hash-object
over pipe). Or they can come from other git implementations.
core.bigfilethreshold can also be lowered down and introduce a new
wave of large loose blobs.

Use streaming interface to read/compress/write these blobs in one
go. Fall back to normal way if somehow streaming interface cannot be
used.

Signed-off-by: Nguyễn Thái Ngọc Duy &amp;lt;pclouds&amp;lt; at &amp;gt;gmail.com&amp;gt;
---
 On top of ng/pack-objects-cleanup. Changes since the last version is
 we do not rely on close_istream(NULL); any more.

 builtin/pack-objects.c | 73 +++++++++++++++++++++++++++++++++++++++++++++-----
 t/t1050-large.sh       | 12 +++++++++
 2 files changed, 79 insertions(+), 6 deletions(-)

diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index ccfcbad..f334820 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -16,6 +16,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 #include "list-objects.h"
 #include "progress.h"
 #include &lt;/pre&gt;</description>
    <dc:creator>Nguyễn Thái Ngọc Duy</dc:creator>
    <dc:date>2012-05-26T10:28:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198545">
    <title>[PATCHv2 0/3] New test cases for branch detection</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198545</link>
    <description>&lt;pre&gt;Updates for previous patch according to feedback from Pete Wyckoff (and
some help from Junio). I also tried to find more improvement
opportunities and included an extra small patch with two small fixes.

Please review and provide feedback.

Kind regards.

Vitor Antunes (3):
  git-p4: Test changelists touching two branches
  git-p4: Verify detection of "empty" branch creation
  git-p4: Clean up branch test cases

 t/t9801-git-p4-branch.sh |  110 ++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 107 insertions(+), 3 deletions(-)

&lt;/pre&gt;</description>
    <dc:creator>Vitor Antunes</dc:creator>
    <dc:date>2012-05-26T09:56:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198535">
    <title>[PATCH 0/3] clone --local fixes</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198535</link>
    <description>&lt;pre&gt;Emeric mentioned that he was confused by the behavior of

  git clone --local file:///path/to/repo

in that the --local is silently ignored. Looking over the documentation,
it is quite unclear whether it is supposed to do anything or not. I
don't think it's an especially pressing use case, so one solution could
be to simply clarify the current behavior in the documentation.

However, I figured this should just be a two-line fix to give it more
sensible behavior, so why not just make it to do the sensible thing? And
while my initial version was two lines, it ended up growing to handle
all of the corner cases properly.  So I'm not super-excited about patch
2, but given that it is written, I think it's a reasonable thing to do
(and it is not _too_ complex).

And then while I was on the subject, I did patch 3, which is something
that has bugged me for a long time.

  [1/3]: t5701: modernize style
  [2/3]: clone: make --local handle URLs
  [3/3]: clone: allow --no-local to turn off local optimizations

-Peff
&lt;/pre&gt;</description>
    <dc:creator>Jeff King</dc:creator>
    <dc:date>2012-05-26T03:42:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198534">
    <title>[PATCH] Pass $verbosity from git pull to git rebase</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198534</link>
    <description>&lt;pre&gt;Currently "git pull -q" only takes effect in merge mode, as commit
7f87aff2 (which introduced "git pull -q") only passes it to
git-merge. This is not nice as a "git pull --rebase -q" will result in
the "Current branch master is up to date.", instead of being quiet.

The patch adds a simple unit-test that checks that the initial pull, a
pull that forwards the head, and a no-op pull are all silent.

Signed-off-by: Iustin Pop &amp;lt;iusty&amp;lt; at &amp;gt;k1024.org&amp;gt;
---
 Please keep me CC-ed, not subscribed to the list.

 git-pull.sh             |    2 +-
 t/t5521-pull-options.sh |   15 ++++++++++++++-
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 2a10047..2920c69 100755
--- a/git-pull.sh
+++ b/git-pull.sh
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -278,7 +278,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; fi
 merge_name=$(git fmt-merge-msg $log_arg &amp;lt;"$GIT_DIR/FETCH_HEAD") || exit
 case "$rebase" in
 true)
-eval="git-rebase $diffstat $strategy_args $merge_args"
+eval="git-rebase $diffstat $strategy_args $merge_args $verbosity"
 eval="$eval --onto $merge_head ${&lt;/pre&gt;</description>
    <dc:creator>Iustin Pop</dc:creator>
    <dc:date>2012-05-26T01:00:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198533">
    <title>[PATCH] Pass $verbosity from git pull to git rebase</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198533</link>
    <description>&lt;pre&gt;Currently "git pull -q" only takes effect in merge mode, as commit
7f87aff2 (which introduced "git pull -q") only passes it to
git-merge. This is not nice as a "git pull --rebase -q" will result in
the "Current branch master is up to date.", instead of being quiet.

The patch adds a simple unit-test that checks that the initial pull, a
pull that forwards the head, and a no-op pull are all silent.

Signed-off-by: Iustin Pop &amp;lt;iusty&amp;lt; at &amp;gt;k1024.org&amp;gt;
---
 Please keep me CC-ed, not subscribed to the list.

 git-pull.sh             |    2 +-
 t/t5521-pull-options.sh |   15 ++++++++++++++-
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 2a10047..2920c69 100755
--- a/git-pull.sh
+++ b/git-pull.sh
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -278,7 +278,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; fi
 merge_name=$(git fmt-merge-msg $log_arg &amp;lt;"$GIT_DIR/FETCH_HEAD") || exit
 case "$rebase" in
 true)
-eval="git-rebase $diffstat $strategy_args $merge_args"
+eval="git-rebase $diffstat $strategy_args $merge_args $verbosity"
 eval="$eval --onto $merge_head ${&lt;/pre&gt;</description>
    <dc:creator>Iustin Pop</dc:creator>
    <dc:date>2012-05-26T01:00:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198530">
    <title>investment proposal</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198530</link>
    <description>&lt;pre&gt;Can you stand as an Investor to received Tenure Investment Proceeds? If 
interested please reply Email:mrs.edilyn789&amp;lt; at &amp;gt;zhot.net
Mrs Edilyn M Padilla.
&lt;/pre&gt;</description>
    <dc:creator>agfund9&lt; at &gt;libero.it</dc:creator>
    <dc:date>2012-05-25T21:44:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198526">
    <title>LOAN OFFER!!</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198526</link>
    <description>&lt;pre&gt;We offer loans at 2% interest rate (Between 1,000 USD to 100,000:00 USD). Get back if interested: 
We will furnish you with further instructions.

Regards,
DR. FLORA CLARK
CHIEF EXECUTIVE OFFICER     
Contact email:aoanloan94&amp;lt; at &amp;gt;mail.com
&lt;/pre&gt;</description>
    <dc:creator>DANNY XIONG</dc:creator>
    <dc:date>2012-05-25T21:14:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198525">
    <title>[ANNOUNCE] Git 1.7.10.3</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198525</link>
    <description>&lt;pre&gt;The latest maintenance release Git 1.7.10.3 is now available at
the usual places.

The release tarballs are found at:

    http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

172c6ad5a55276213c5e40b83a4c270f6f931b3e  git-1.7.10.3.tar.gz
c75f9dd4e5157b0c0cb53d67a599b1b038b9c708  git-htmldocs-1.7.10.3.tar.gz
4ae4f9f0f0dc42ad5cb2de309049c953841bc413  git-manpages-1.7.10.3.tar.gz

Also the following public repositories all have a copy of the v1.7.10.3
tag and the maint branch that the tag points at:

  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git


Git v1.7.10.3 Release Notes
===========================

Fixes since v1.7.10.2
---------------------

 * The message file for German translation has been updated a bit.

 * Running "git checkout" on an unborn branch used to corrupt HEAD.

 * &lt;/pre&gt;</description>
    <dc:creator>Junio C Hamano</dc:creator>
    <dc:date>2012-05-25T20:54:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198519">
    <title>[PATCH 1/2] Add possibility to store configuration in ~/.config/git/config file</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198519</link>
    <description>&lt;pre&gt;git will store its configuration in ~/.config/git/config file if this file
exists and ~/.gitconfig file doesn't, otherwise git store its configuration
in ~/.gitconfig as usual
---
 builtin/config.c |   31 ++++++++++++++++++++++++++++---
 config.c         |   15 ++++++++++++++-
 2 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/builtin/config.c b/builtin/config.c
index 33c8820..dc890d5 100644
--- a/builtin/config.c
+++ b/builtin/config.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -171,8 +171,20 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int get_value(const char *key_, const char *regex_)
 if (!local) {
 const char *home = getenv("HOME");
 local = repo_config = git_pathdup("config");
-if (home)
-global = xstrdup(mkpath("%s/.gitconfig", home));
+if (home) {
+char gitconfig_path[PATH_MAX], config_path[PATH_MAX];
+FILE *gitconfig_file, *config_file;
+
+sprintf(gitconfig_path, "%s/.gitconfig", home);
+sprintf(config_path, "%s/.config/git/config", home);
+gitconfig_file = fopen(gitconfig_path, "r");
+config_file = fopen(config_path, "r");
+
+&lt;/pre&gt;</description>
    <dc:creator>NGUYEN Huynh Khoi Nguyen</dc:creator>
    <dc:date>2012-05-25T19:47:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198511">
    <title>how to share files between machines?</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198511</link>
    <description>&lt;pre&gt;We have a shared git repository (origin).  Everyone on the team clones 
the repo, does some work, commits locally then pushes to the shared 
repository.

I have a box where I have cloned the repo.  I have another box (test 
box) where I have also cloned the same repo.  I change/commit/push code 
on either box to the shared repo depending on the task at hand.

Now I want to do something different.  I want to create new files on my 
local box in various directories that are part of my local git rep, and 
share them only between just the two boxes.  So I need the ability to 
commit/push to another repo such that others on the repo mentioned in 
the first sentence will not be affected.

There will be various files in various sub directories, so when I pull 
on the second box, I want all the files to come down and be put in the 
same directory that they existed on my box 1 where I committed them.

Is this at all possible? Maybe by creating a bare repository on my box 1?



J.V.
&lt;/pre&gt;</description>
    <dc:creator>J.V.</dc:creator>
    <dc:date>2012-05-25T19:28:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198497">
    <title>N/A</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198497</link>
    <description>&lt;pre&gt;Good day

My name is Paul Underwood. I work with Reliance bank Limited here in the
London and I have a business proposal for you. Please go through the attached
letter and get more details about this deal. Your urgent response is highly
anticipated and will be highly appreciated. Get back to me
through my email below or you can call the number below for further clarification.

Please, don't respond to this email if you are NOT INTERESTED or LESS
INTERESTED in the deal because I need someone that will give the deal 100%
attention to enable us succeed as I have put in much in planning on how we
will succeed. So I do not want anybody that will come and waste my time and
mess up the deal and put me in big trouble that might land me in prison or or
make me lose my job.

Like I said before, if you are interested and can be able to handle such huge
deal after reading the attached proposal then contact me but if you are not
interested or cannot be able to handle such deal involving such huge amount of
money then do &lt;/pre&gt;</description>
    <dc:creator>RELIANCE BANK®</dc:creator>
    <dc:date>2012-05-25T17:54:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198482">
    <title>[RFC] Possibility to choose ~/.config/git/config instead of ~/.gitconfig</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198482</link>
    <description>&lt;pre&gt;Hello,

As you know, git stores its configuration in ~/.gitconfig file and in  
other hidden files at the root of the user's directory.

We would like to have a configuration directory instead of all these  
configuration files by following the XDG specification because:
- not a lot of hidden files at the root, so better view
- one directory per software in ~/.config

We would like to give to users the possibility to store configuration  
in ~/.config/git/config file.

git would store its configuration in ~/.config/git/config file if:
- this file exists,
- and ~/.gitconfig file doesn't.
Otherwise git would store its configuration in ~/.gitconfig as usual.

If you don't create ~/.config/git/config, there is no change.

What do you think about it ?

I will send you a patch today.

Thanks,

Lucien KONG,
Valentin DUPERRAY,
Huynh Khoi Nguyen NGUYEN,
Thomas NGUY,
Franck JONAS

Grenoble INP ENSIMAG


&lt;/pre&gt;</description>
    <dc:creator>nguyenhu&lt; at &gt;minatec.inpg.fr</dc:creator>
    <dc:date>2012-05-25T16:15:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198481">
    <title>behaviour of .gitignore</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198481</link>
    <description>&lt;pre&gt;On my local machine, I create a /bin/ directory added some bash scripts, 
comitted and then pushed them to the repository.

Now today I do a git pull and they are gone but cannot see that anyone 
deleted them in the git log / history, but there is a /bin/ entry in the 
.gitignore file.

Does this mean, the files are still in the shared repository (orgin) 
that I could get them back?

I tried removing /bin/ from the git ignore and doing a pull but my /bin/ 
directory is still not there.

Is there anyway to do a pull now and have it look at my local gitignore 
and pull the directory back?

thanks


J.V.
&lt;/pre&gt;</description>
    <dc:creator>J.V.</dc:creator>
    <dc:date>2012-05-25T16:32:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198480">
    <title>fmt-merge-message: add empty line between tag and signature verification</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198480</link>
    <description>&lt;pre&gt;
When adding the information from a tag, put an empty line between the 
message of the tag and the commented-out signature verification 
information.

At least for the kernel workflow, I often end up re-formatting the message 
that people send me in the tag data. In that situation, putting the tag 
message and the tag signature verification back-to-back then means that 
normal editor "reflow parapgraph" command will get confused and think that 
the signature is a continuation of the last message paragraph.

So I always end up having to first add an empty line, and then go back and 
reflow the last paragraph. Let's just do it in git directly.

The extra vertical space also makes the verification visually stand out 
more from the user-supplied message, so it looks a bit more readable to me 
too, but that may be just an odd personal preference.

Signed-off-by: Linus Torvalds &amp;lt;torvalds&amp;lt; at &amp;gt;linux-foundation.org&amp;gt;
---
This is a throw-away patch - apply or not as you prefer. I thought I'd 
send it out and see what peopl&lt;/pre&gt;</description>
    <dc:creator>Linus Torvalds</dc:creator>
    <dc:date>2012-05-25T16:02:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198478">
    <title>Hello Dearst One</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198478</link>
    <description>&lt;pre&gt;Hello Dearst One
My name is Mabel a pretty girl Living I Feel Empty without 
Can I Trust You , Am approaching you for a genuine 
friendship and a partnership ,I saw your contact today 
,and i am interested in you, Please i would like to know 
more about you,remember age or distance does not matter 
but what matters is true love,for further communication 
contact me . to enable me to explain myself well to you 
and as well to know whom you are very well i know that my 
coming to you will create a great happiness in my living 
,so i felt we could start from friendship. Who knows, 
something greater may come up in time to come if you don't 
mind, for more of my introduction and to let you know more 
about my self.Tell me about yourself as you reply to this 
mail.
Thanks Yours
Mabel
---
Professional hosting for everyone - http://www.host.ru
&lt;/pre&gt;</description>
    <dc:creator>baby mabel</dc:creator>
    <dc:date>2012-05-25T14:48:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.git/198475">
    <title>[PATCH] Teach ignore machinery about pattern "/"</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.git/198475</link>
    <description>&lt;pre&gt;Pattern "/" is ambiguous because the slash can mean "anchor the
pattern to this location" (e.g. /path), but it can also mean
"match directories only" (e.g. path/). Currently git interprets it as
the latter except that 'path' is an empty string, which makes this
pattern totally useless.

On the other hand, it's intuitive to read '/' as "match root
directory", or equivalent to "/*". (The other way to see it is "match
all directories", which leads to the same result).

One may wonder why bother an "ignore all" pattern. The pattern is
useful when you want to keep just a small portion of the working
directory. But that's still a rare case.

A more popular case would be sparse checkout, where ignore rules are
used to _include_. The thus now "include all" pattern is used to say
"make a sparse checkout that includes everything except this and
this".

Recognize this special pattern and turn it the working equivalence
pattern "/*"

Signed-off-by: Nguyễn Thái Ngọc Duy &amp;lt;pclouds&amp;lt; at &amp;gt;gmail.com&amp;gt;
---
 dir.c                &lt;/pre&gt;</description>
    <dc:creator>Nguyễn Thái Ngọc Duy</dc:creator>
    <dc:date>2012-05-25T12:47:36</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>

