Re: Bug: file named - on git commit

2013-02-04 Thread Junio C Hamano
Jonathan Nieder jrnie...@gmail.com writes:

 This was fixed by Junio around 4682d85 (diff-index.c: git diff has no
 need to read blob from the standard input, 2012-06-27), which is
 included starting with v1.7.12 and the v1.7.11.3 maint release.  Please
 upgrade.

 Should upgrade-averse folks stuck on 1.7.10.y (like Debian 7.0, which
 is currently in the release candidate stage) take this fix?  Do you
 happen to know of any other fixes such people would want?

I've been wondering if we can help automating this for backporters.

Because of the way my integration branches are managed, if you run

git log --first-parent v1.8.0..maint-1.8.0
git log --first-parent v1.8.1..maint

the output should give us a birds-eye view (because most are merges
of one or more patches on a topic) of the changes that are fixes,
excluding any feature enhancements.

You can then iterate over the single patches applied directly on top
of maint (or maint-1.8.0) and tips of the topics merged to maint (or
maint-1.8.0) and see if each of them is applicable to maint-1.7.10
codebase.  I think you can mechanically reject the ones that are on
'maint' that merge topics that were forked from v1.8.1 as too new.
That hopefully culls the topics that needs manual review and
assessment (some may be too minor to be worth backproting, for
example).

You should be able to do the same for

git log --first-parent v1.8.1..master

There will be fixes and features mixed in the output, but if you
can mechanically narrow down the ones that may be relevant to your
old maintenance track, eyeballing the rest to judge if each of them
is worth backporting will become a manageable task.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Bug: file named - on git commit

2013-02-04 Thread Jonathan Nieder
Junio C Hamano wrote:

(some may be too minor to be worth backproting, for
 example).

Yes, this is the part I was asking for help with.  Backporting is easy
but convincing the release team and upgrade-averse sysadmins to like
the result generally isn't.  Occasional nominations of the form this
change is important in my workflow could help.

Continuing to stick to fixes to very severe bugs that stand out plus a
random assortment of problems people have reported can also work fine,
though.

Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Bug: file named - on git commit

2013-01-28 Thread Matthieu Moy
Rene Moser m...@renemoser.net writes:

 Hi

 Found a little issue in git version 1.7.9.5 if a file named -, causing
 git commit to read from stdin.

Can't reproduce with Git version 1.8.1.1.440.g1d329bd, this probably has
been fixed already.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Bug: file named - on git commit

2013-01-28 Thread Duy Nguyen
On Mon, Jan 28, 2013 at 5:38 PM, Rene Moser m...@renemoser.net wrote:
 Hi

 Found a little issue in git version 1.7.9.5 if a file named -, causing
 git commit to read from stdin.

 (So you must hit ctrl-d or ctrl-c to finish the commit.)

 Everything looks ok to me after the commit. Other users reported to be
 fixed in 1.8.1.1 but haven't it tested myself.

Yes, it's fixed in 4682d85 (diff-index.c: git diff has no need to
read blob from the standard input - 2012-06-27) since v1.7.11.3.


 This does not work:

 mkdir tmp  cd tmp;
 echo foo ./-;
 git init; git add .;
 git commit -m is this a bug?

 Kind regards

 René









-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Bug: file named - on git commit

2013-01-28 Thread Thomas Rast
Rene Moser m...@renemoser.net writes:


 Found a little issue in git version 1.7.9.5 if a file named -, causing
 git commit to read from stdin.

 (So you must hit ctrl-d or ctrl-c to finish the commit.)

 Everything looks ok to me after the commit. Other users reported to be
 fixed in 1.8.1.1 but haven't it tested myself.

 This does not work:

 mkdir tmp  cd tmp;
 echo foo ./-;
 git init; git add .;
 git commit -m is this a bug?

This was fixed by Junio around 4682d85 (diff-index.c: git diff has no
need to read blob from the standard input, 2012-06-27), which is
included starting with v1.7.12 and the v1.7.11.3 maint release.  Please
upgrade.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Bug: file named - on git commit

2013-01-28 Thread Jonathan Nieder
Hi,

Thomas Rast wrote:
 Rene Moser m...@renemoser.net writes:

 Found a little issue in git version 1.7.9.5 if a file named -, causing
 git commit to read from stdin.

 (So you must hit ctrl-d or ctrl-c to finish the commit.)
[...]
 This was fixed by Junio around 4682d85 (diff-index.c: git diff has no
 need to read blob from the standard input, 2012-06-27), which is
 included starting with v1.7.12 and the v1.7.11.3 maint release.  Please
 upgrade.

Should upgrade-averse folks stuck on 1.7.10.y (like Debian 7.0, which
is currently in the release candidate stage) take this fix?  Do you
happen to know of any other fixes such people would want?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Bug: file named - on git commit

2013-01-28 Thread Junio C Hamano
Jonathan Nieder jrnie...@gmail.com writes:

 Thomas Rast wrote:
 Rene Moser m...@renemoser.net writes:

 Found a little issue in git version 1.7.9.5 if a file named -, causing
 git commit to read from stdin.

 (So you must hit ctrl-d or ctrl-c to finish the commit.)
 [...]
 This was fixed by Junio around 4682d85 (diff-index.c: git diff has no
 need to read blob from the standard input, 2012-06-27), which is
 included starting with v1.7.12 and the v1.7.11.3 maint release.  Please
 upgrade.

 Should upgrade-averse folks stuck on 1.7.10.y (like Debian 7.0, which
 is currently in the release candidate stage) take this fix?  Do you
 happen to know of any other fixes such people would want?

FYI, the fix referred to in this thread are three-patch series that
forked from 1.7.6.6, so it should be trivial to merge it even to
such an old version.

The topic-branch workflow shines ;-)

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Bug: file named - on git commit

2013-01-28 Thread Junio C Hamano
Jonathan Nieder jrnie...@gmail.com writes:

 Thomas Rast wrote:
 Rene Moser m...@renemoser.net writes:

 Found a little issue in git version 1.7.9.5 if a file named -, causing
 git commit to read from stdin.

 (So you must hit ctrl-d or ctrl-c to finish the commit.)
 [...]
 This was fixed by Junio around 4682d85 (diff-index.c: git diff has no
 need to read blob from the standard input, 2012-06-27), which is
 included starting with v1.7.12 and the v1.7.11.3 maint release.  Please
 upgrade.

 Should upgrade-averse folks stuck on 1.7.10.y (like Debian 7.0, which
 is currently in the release candidate stage) take this fix?  Do you
 happen to know of any other fixes such people would want?

There are files with four dotted decimal numbers in their names in
the Documentation/RelNotes/ directory to help distro maintainers
like you to figure it want.

This is a tangent, but even with a project like git that is managed
with a good use of topic branch workflow, we may want to have a way
to reliably identify the tip of an ancient fix like this.  People
may be able to bisect down to 4682d85, and in this particular case,
I happen to know that there wasn't any side-effect breakage
introduced by that commit, but there needs to be an easy way (it
can be expensive to compute) to make sure there is no follow-up fix
to that particular commit.

I can read git rev-list --parents | grep -C3 $(git rev-parse 4682d85)
and then figure out what the children commits of that fix are, of
course, but I suspect most people will view it as primitive ;-)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html