* Re: [PATCH] gitk: Take only numeric version components when computing $git_version
From: Jonathan Nieder @ 2011-01-13 19:22 UTC (permalink / raw)
To: Mathias Lafeldt; +Cc: Anders Kaseorg, Paul Mackerras, Junio C Hamano, git
In-Reply-To: <4D2C5F3E.2020007@debugon.org>
Mathias Lafeldt wrote:
> Anders Kaseorg wrote:
>> This fixes errors running with release candidate versions of Git:
>> Error in startup script: expected version number but got "1.7.4-rc0"
[...]
> People don't seem to use gitk with the RC releases because nobody else
> complains...
GIT-VERSION-GEN contains:
DEF_VER=v1.7.4-rc1
[...]
if test -f version
then
[...]
elif test -d .git -o -f .git &&
[...]
then
VN=$(echo "$VN" | sed -e 's/-/./g');
else
VN="$DEF_VER"
fi
So after building from a tarball generated with "git archive", "git version"
produces v1.7.4-rc1, producing errors from gitk, but after building
from the git repo or a tarball generated with "make dist", the version
is v1.7.4.rc1 (which gitk accepts).
Anders's fix looks good to me for robustness reasons anyway, so
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Maybe the substitution in GIT-VERSION-GEN should say something like
VN=$(echo "$VN" | sed -e 's/-\([^r]\)/.\1/g')
meaning the result for tagged rcs would not depend on whether git is
present? Alternatively, DEF_VER could be set to v1.7.4.rc1, which
does not seem as nice to me.
^ permalink raw reply
* [PATCH] git-p4: Fixed handling of file names with spaces
From: Jerzy Kozera @ 2011-01-13 18:51 UTC (permalink / raw)
To: git; +Cc: gitster, msclrhd, Jerzy Kozera
In-Reply-To: <AANLkTi=Cp=FCuJdthr7JfML6jdNzUiDAUPjrWpTQfWGk@mail.gmail.com>
Hi,
I've noticed the same issue in reopen and rm calls - not saying these three are all occurences of this problem, but I guess fixing them is a good start.
I'm using \" instead of '' quoting for consistency with rest of the file.
Regards,
Jerzy
---
contrib/fast-import/git-p4 | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 04ce7e3..2147315 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -139,12 +139,12 @@ def setP4ExecBit(file, mode):
if p4Type[-1] == "+":
p4Type = p4Type[0:-1]
- p4_system("reopen -t %s %s" % (p4Type, file))
+ p4_system("reopen -t %s \"%s\"" % (p4Type, file))
def getP4OpenedType(file):
# Returns the perforce file type for the given file.
- result = p4_read_pipe("opened %s" % file)
+ result = p4_read_pipe("opened \"%s\"" % file)
match = re.match(".*\((.+)\)\r?$", result)
if match:
return match.group(1)
@@ -666,7 +666,7 @@ class P4Submit(Command):
for f in editedFiles:
p4_system("revert \"%s\"" % f);
for f in filesToAdd:
- system("rm %s" %f)
+ system("rm \"%s\"" % f)
return
elif response == "a":
os.system(applyPatchCmd)
--
1.7.1
^ permalink raw reply related
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Jeff King @ 2011-01-13 18:47 UTC (permalink / raw)
To: JT Olds; +Cc: git
In-Reply-To: <AANLkTimanDRHwoqSj7i9sVCZkze1L3Qp-zFYwTwHAOHX@mail.gmail.com>
On Thu, Jan 13, 2011 at 10:00:45AM -0700, JT Olds wrote:
> I don't have git-sh-setup, which seems like it should be included in
> the git-core package, but it's not. I have git-core
> 1:1.7.1-1.1ubuntu0.1 installed. Obviously this precludes
> get_author_ident_from_commit from working.
Oops, sorry about that. It ships in the /usr/lib/git-core directory
these days (it _used_ to ship in /usr/bin, so "." would find it
automatically). And when I did my test, I was using the git repository
itself, so of course it was in my current directory then. :)
But it looks like you found it.
> Author: jt@instructure.com
> Email: jt@instructure.com
> Subject: removing nondeterminism from test
> Date: Tue, 11 Jan 2011 07:42:30 -0700
>
> Should "Author" be my name? Could that be what's going on? I don't
> even know where that gets set. The ones that I failed to notice that
> they broke before I pushed them look like this:
Yep, it should be your name. So my next to suspect would be the
git-mailinfo parser, and indeed, that's the thing that has the
3-character limit that Erik mentioned.
So that's definitely the problem.
-Peff
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Erik Faye-Lund @ 2011-01-13 18:20 UTC (permalink / raw)
To: JT Olds; +Cc: Jeff King, git
In-Reply-To: <AANLkTimf2rwKqyWwQbdj7cjS8YcQwCXYGRCvQbZ5HZ19@mail.gmail.com>
In the future please don't top-post, as it makes the discussion harder
for other people to follow. I've fixed the quoting for now, though.
On Thu, Jan 13, 2011 at 6:52 PM, JT Olds <jtolds@xnet5.com> wrote:
> On Thu, Jan 13, 2011 at 10:47 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>> On Thu, Jan 13, 2011 at 6:11 PM, JT Olds <jtolds@xnet5.com> wrote:
>>> I got a copy of git-sh-setup. All of my commits (that have either
>>> worked or that I fixed) look like this:
>>>
>>> GIT_AUTHOR_NAME='JT'
>>> GIT_AUTHOR_EMAIL='jt@instructure.com'
>>> GIT_AUTHOR_DATE='1294756950 -0700'
>>> Author: jt@instructure.com
>>> Email: jt@instructure.com
>>> Subject: removing nondeterminism from test
>>> Date: Tue, 11 Jan 2011 07:42:30 -0700
>>>
>>> Should "Author" be my name? Could that be what's going on? I don't
>>> even know where that gets set. The ones that I failed to notice that
>>> they broke before I pushed them look like this:
>>>
>>
>> "git am" (which git rebase builds on) requires the author name to be
>> at least three characters long. This is a problem that has been
>> discussed before, see
>> <AANLkTinqTL7gH4CHEfy8UrhK13xcO_3UzgIyQka00MAh@mail.gmail.com>:
>>
>> http://mid.gmane.org/AANLkTinqTL7gH4CHEfy8UrhK13xcO_3UzgIyQka00MAh@mail.gmail.com
>>
>
> Oh thank you Erik, it's great to just know what the problem is. I've
> been feeling like some voodoo was happening.
>
> What are the chances of decreasing that lower bound of author name size? :)
>
It's a matter of editing the function called "get_sane_name" in
builtin/mailinfo.c.
But simply changing the bound doesn't mean you're in the clear. If any
other people you work with end up rebasing any patches you've written,
the same problem will manifest. There's a lot of people using some
really old versions of Git.
And then it's the question of why this is done in the first place. I
don't know, but I suspect Linus has his reasons. Besides, a name of
two characters aren't really sane. You'd need at least three
characters to form a first/last name pair.
I'd recommend that you use a longer name, really.
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: JT Olds @ 2011-01-13 17:52 UTC (permalink / raw)
To: kusmabite; +Cc: Jeff King, git
In-Reply-To: <AANLkTikqfX3jhSdP5xhFj=VktqW2S6AeGL_MF18g8ZA_@mail.gmail.com>
Oh thank you Erik, it's great to just know what the problem is. I've
been feeling like some voodoo was happening.
What are the chances of decreasing that lower bound of author name size? :)
-JT
On Thu, Jan 13, 2011 at 10:47 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> On Thu, Jan 13, 2011 at 6:11 PM, JT Olds <jtolds@xnet5.com> wrote:
>> I got a copy of git-sh-setup. All of my commits (that have either
>> worked or that I fixed) look like this:
>>
>> GIT_AUTHOR_NAME='JT'
>> GIT_AUTHOR_EMAIL='jt@instructure.com'
>> GIT_AUTHOR_DATE='1294756950 -0700'
>> Author: jt@instructure.com
>> Email: jt@instructure.com
>> Subject: removing nondeterminism from test
>> Date: Tue, 11 Jan 2011 07:42:30 -0700
>>
>> Should "Author" be my name? Could that be what's going on? I don't
>> even know where that gets set. The ones that I failed to notice that
>> they broke before I pushed them look like this:
>>
>
> "git am" (which git rebase builds on) requires the author name to be
> at least three characters long. This is a problem that has been
> discussed before, see
> <AANLkTinqTL7gH4CHEfy8UrhK13xcO_3UzgIyQka00MAh@mail.gmail.com>:
>
> http://mid.gmane.org/AANLkTinqTL7gH4CHEfy8UrhK13xcO_3UzgIyQka00MAh@mail.gmail.com
>
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Erik Faye-Lund @ 2011-01-13 17:47 UTC (permalink / raw)
To: JT Olds; +Cc: Jeff King, git
In-Reply-To: <AANLkTimvK3p3M8kbGzLxyhchoFONiD4=FGPWxxs=i0GA@mail.gmail.com>
On Thu, Jan 13, 2011 at 6:11 PM, JT Olds <jtolds@xnet5.com> wrote:
> I got a copy of git-sh-setup. All of my commits (that have either
> worked or that I fixed) look like this:
>
> GIT_AUTHOR_NAME='JT'
> GIT_AUTHOR_EMAIL='jt@instructure.com'
> GIT_AUTHOR_DATE='1294756950 -0700'
> Author: jt@instructure.com
> Email: jt@instructure.com
> Subject: removing nondeterminism from test
> Date: Tue, 11 Jan 2011 07:42:30 -0700
>
> Should "Author" be my name? Could that be what's going on? I don't
> even know where that gets set. The ones that I failed to notice that
> they broke before I pushed them look like this:
>
"git am" (which git rebase builds on) requires the author name to be
at least three characters long. This is a problem that has been
discussed before, see
<AANLkTinqTL7gH4CHEfy8UrhK13xcO_3UzgIyQka00MAh@mail.gmail.com>:
http://mid.gmane.org/AANLkTinqTL7gH4CHEfy8UrhK13xcO_3UzgIyQka00MAh@mail.gmail.com
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: JT Olds @ 2011-01-13 17:11 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <AANLkTimanDRHwoqSj7i9sVCZkze1L3Qp-zFYwTwHAOHX@mail.gmail.com>
I got a copy of git-sh-setup. All of my commits (that have either
worked or that I fixed) look like this:
GIT_AUTHOR_NAME='JT'
GIT_AUTHOR_EMAIL='jt@instructure.com'
GIT_AUTHOR_DATE='1294756950 -0700'
Author: jt@instructure.com
Email: jt@instructure.com
Subject: removing nondeterminism from test
Date: Tue, 11 Jan 2011 07:42:30 -0700
Should "Author" be my name? Could that be what's going on? I don't
even know where that gets set. The ones that I failed to notice that
they broke before I pushed them look like this:
GIT_AUTHOR_NAME='jt@instructure.com'
GIT_AUTHOR_EMAIL='jt@instructure.com'
GIT_AUTHOR_DATE='1294775987 -0700'
Author: jt@instructure.com
Email: jt@instructure.com
Subject: some cleanup
Date: Tue, 11 Jan 2011 12:59:47 -0700
Thanks again for the help. This has been frustrating me for months.
Still working on a duplicate-the-problem script.
-JT
On Thu, Jan 13, 2011 at 10:00 AM, JT Olds <jtolds@xnet5.com> wrote:
>> Some things off the top of my head: Does your GIT_AUTHOR_NAME or
>> GIT_AUTHOR_EMAIL contain any odd characters that might confuse a parser?
>
> Nah, from my .git/config
>
> [user]
> name = JT
> email = jt@instructure.com
>
>> Do you do anything special with setting up those environment variables
>> in your shell (e.g., in a .bashrc or .profile; those files _shouldn't_
>> be read by a non-interactive shell, but it's something to investigate)?
>
> Nope, the only place in my entire home directory where those get set
> are in my filter-branch script to fix them, which I only run after the
> problem manifests itself.
>
>> For that matter, how do you set up your identity in general (by
>> environment, or in ~/.gitconfig, or a local .git/config in each repo),
>> and what does it contain?
>
> I have a global identity in ~/.gitconfig
>
> [user]
> name = JT
> email = hello@jtolds.com
>
> and then in particular topic branches in their .git/config like before.
>
>> Can you try running this in a repo that's giving you problems:
>>
>> . git-sh-setup
>> git log --format=%H --author=your.name |
>> while read rev; do
>> get_author_ident_from_commit $rev
>> git format-patch -1 --stdout $rev |
>> git mailinfo /dev/null /dev/null
>> done | less
>
> I don't have git-sh-setup, which seems like it should be included in
> the git-core package, but it's not. I have git-core
> 1:1.7.1-1.1ubuntu0.1 installed. Obviously this precludes
> get_author_ident_from_commit from working.
>
>> If that doesn't turn up anything, I think the next thing to try would be
>> making a script that reproduces the problem for you, and see if I can
>> reproduce it here.
>
> Alright, I'll see what I can do. Thanks.
>
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: JT Olds @ 2011-01-13 17:00 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110112182150.GC31747@sigill.intra.peff.net>
> Some things off the top of my head: Does your GIT_AUTHOR_NAME or
> GIT_AUTHOR_EMAIL contain any odd characters that might confuse a parser?
Nah, from my .git/config
[user]
name = JT
email = jt@instructure.com
> Do you do anything special with setting up those environment variables
> in your shell (e.g., in a .bashrc or .profile; those files _shouldn't_
> be read by a non-interactive shell, but it's something to investigate)?
Nope, the only place in my entire home directory where those get set
are in my filter-branch script to fix them, which I only run after the
problem manifests itself.
> For that matter, how do you set up your identity in general (by
> environment, or in ~/.gitconfig, or a local .git/config in each repo),
> and what does it contain?
I have a global identity in ~/.gitconfig
[user]
name = JT
email = hello@jtolds.com
and then in particular topic branches in their .git/config like before.
> Can you try running this in a repo that's giving you problems:
>
> . git-sh-setup
> git log --format=%H --author=your.name |
> while read rev; do
> get_author_ident_from_commit $rev
> git format-patch -1 --stdout $rev |
> git mailinfo /dev/null /dev/null
> done | less
I don't have git-sh-setup, which seems like it should be included in
the git-core package, but it's not. I have git-core
1:1.7.1-1.1ubuntu0.1 installed. Obviously this precludes
get_author_ident_from_commit from working.
> If that doesn't turn up anything, I think the next thing to try would be
> making a script that reproduces the problem for you, and see if I can
> reproduce it here.
Alright, I'll see what I can do. Thanks.
^ permalink raw reply
* Re: Applying .gitattributes text/eol changes
From: Marc Strapetz @ 2011-01-13 14:57 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4D2F0E3A.8090108@drmicha.warpmail.net>
>> If a "git checkout" would (optionally) make sure that all EOLs are
>> properly set according to .gitattributes, the problem would be resolved.
>> As this might be not so easy to implement, my suggestion was to make
>> "git reset --hard" work more unobtrusive. I think we can provide a
>> corresponding patch, if it has chances to get accepted.
>
> There have been other cases where git update-index --really-refresh
> wasn't enough. You might want to check whether that is a suitable "patch
> attack vector". This might be useful not only for you but also for others.
So your suggestion is to fix "git update-index --really-refresh", so
it's a replacement for "rm .git/index"? This sounds reasonable,
especially as "rm .git/index" is something one feels not comfortable
about when performing the first time ;-)
Anyway, I'm still wondering if it will resolve the "git reset --hard"
problem of re-checking out every file, even if content is already
identical in the working tree. I think that part has to be fixed, too.
What do you think about "git checkout --fix-eols" option as an
alternative? Its uses cases are more limited, though.
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
On 13.01.2011 15:37, Michael J Gruber wrote:
> Marc Strapetz venit, vidit, dixit 13.01.2011 15:28:
>>>> case of missing .git/index, Git freshly writes all working tree files,
>>>> ignoring already existing files which already have the correct content.
>>>> Maybe this behavior is by intention and makes sense in some cases. In my
>>>> case it has adverse effects on IDEs and probably other tools which are
>>>> monitoring the file system.
>>>
>>> ...but changing gitattributes is something you don't do routinely in
>>> your workflow; so, at worst there would be an occasional unnecessary run
>>> of your build process.
>>
>> Our Git-SVN bridge does it, potentially on every pull. This is why we
>> currently need to run "rm .git/index && git reset --hard" after every
>> pull, resp. every checkout (switching to another commit may result in
>> changed .gitattributes as well).
>
> OK, now you're telling us what this is about ;)
>
>> If a "git checkout" would (optionally) make sure that all EOLs are
>> properly set according to .gitattributes, the problem would be resolved.
>> As this might be not so easy to implement, my suggestion was to make
>> "git reset --hard" work more unobtrusive. I think we can provide a
>> corresponding patch, if it has chances to get accepted.
>
> There have been other cases where git update-index --really-refresh
> wasn't enough. You might want to check whether that is a suitable "patch
> attack vector". This might be useful not only for you but also for others.
>
> Michael
>
>
^ permalink raw reply
* Re: Applying .gitattributes text/eol changes
From: Michael J Gruber @ 2011-01-13 14:37 UTC (permalink / raw)
To: Marc Strapetz; +Cc: git
In-Reply-To: <4D2F0BF3.2000808@syntevo.com>
Marc Strapetz venit, vidit, dixit 13.01.2011 15:28:
>>> case of missing .git/index, Git freshly writes all working tree files,
>>> ignoring already existing files which already have the correct content.
>>> Maybe this behavior is by intention and makes sense in some cases. In my
>>> case it has adverse effects on IDEs and probably other tools which are
>>> monitoring the file system.
>>
>> ...but changing gitattributes is something you don't do routinely in
>> your workflow; so, at worst there would be an occasional unnecessary run
>> of your build process.
>
> Our Git-SVN bridge does it, potentially on every pull. This is why we
> currently need to run "rm .git/index && git reset --hard" after every
> pull, resp. every checkout (switching to another commit may result in
> changed .gitattributes as well).
OK, now you're telling us what this is about ;)
> If a "git checkout" would (optionally) make sure that all EOLs are
> properly set according to .gitattributes, the problem would be resolved.
> As this might be not so easy to implement, my suggestion was to make
> "git reset --hard" work more unobtrusive. I think we can provide a
> corresponding patch, if it has chances to get accepted.
There have been other cases where git update-index --really-refresh
wasn't enough. You might want to check whether that is a suitable "patch
attack vector". This might be useful not only for you but also for others.
Michael
^ permalink raw reply
* Re: Applying .gitattributes text/eol changes
From: Marc Strapetz @ 2011-01-13 14:28 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4D2EFCBD.4020402@drmicha.warpmail.net>
>> case of missing .git/index, Git freshly writes all working tree files,
>> ignoring already existing files which already have the correct content.
>> Maybe this behavior is by intention and makes sense in some cases. In my
>> case it has adverse effects on IDEs and probably other tools which are
>> monitoring the file system.
>
> ...but changing gitattributes is something you don't do routinely in
> your workflow; so, at worst there would be an occasional unnecessary run
> of your build process.
Our Git-SVN bridge does it, potentially on every pull. This is why we
currently need to run "rm .git/index && git reset --hard" after every
pull, resp. every checkout (switching to another commit may result in
changed .gitattributes as well).
If a "git checkout" would (optionally) make sure that all EOLs are
properly set according to .gitattributes, the problem would be resolved.
As this might be not so easy to implement, my suggestion was to make
"git reset --hard" work more unobtrusive. I think we can provide a
corresponding patch, if it has chances to get accepted.
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
On 13.01.2011 14:23, Michael J Gruber wrote:
> Marc Strapetz venit, vidit, dixit 11.01.2011 15:02:
>> On 11.01.2011 13:11, Michael J Gruber wrote:
>>> Marc Strapetz venit, vidit, dixit 03.01.2011 18:18:
>>>> I'm looking for an unobtrusive way to apply (committed) changes for
>>>> text/eol attributes to the working tree. For instance, after having
>>>> changed "*.txt eol=crlf" to "*.txt eol=lf", all *.txt files should be
>>>> converted from CRLF to LF endings. The only advice I found so far is to
>>>> remove .git/index and do a reset --hard. The disadvantage of this
>>>> approach is that every file will be touched:
>>>>
>>>> - although the content does not change, timestamps will be changed. This
>>>
>>> The bytewise content does change.
>>
>> The content has only changed for *.txt files, but the timestamps of
>> *all* files are updated. I guess (but didn't verify from code), that in
>
> Well, sure...
>
>> case of missing .git/index, Git freshly writes all working tree files,
>> ignoring already existing files which already have the correct content.
>> Maybe this behavior is by intention and makes sense in some cases. In my
>> case it has adverse effects on IDEs and probably other tools which are
>> monitoring the file system.
>
> ...but changing gitattributes is something you don't do routinely in
> your workflow; so, at worst there would be an occasional unnecessary run
> of your build process.
>
>>
>>>> One solution I could think of which might be helpful in other situations
>>>> as well would be to have an "--unobtrusive" option for reset which would
>>>> only replace a file if the content has actually been changed.
>>>
>>> How about
>>>
>>> git ls-files \*.txt | xargs touch -a
>>> git ls-files \*.txt | git checkout
>>
>> That won't be helpful as it requires me to know what has changed.
>
> But you do know that only (at most) *.txt have changed!
>
> Michael
>
>
^ permalink raw reply
* Re: Git unpack-objects on Windows
From: Kevin Sheedy @ 2011-01-13 13:54 UTC (permalink / raw)
To: git
In-Reply-To: <4D2EF04B.20108@viscovery.net>
Ah, ok. I guess unpacking isn't what I need to do. I'm quite new to git and
don't really understand the internals yet. Anyway, cvs2git produced 2 .dat
files that I'm trying to import into a git repository using the following
commands:
git init
cat cvs2svn-tmp/git-blob.dat cvs2svn-tmp/git-dump.dat | git fast-import
I'm following the instructions from here:
http://cvs2svn.tigris.org/cvs2git.html
It looks like the objects have been added to the repository but that no
branches have been created.
Any idea how to create a branch and add the 66000 objects to it?
--
View this message in context: http://git.661346.n2.nabble.com/Git-unpack-objects-on-Windows-tp5917819p5918228.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Applying .gitattributes text/eol changes
From: Michael J Gruber @ 2011-01-13 13:23 UTC (permalink / raw)
To: Marc Strapetz; +Cc: git
In-Reply-To: <4D2C62DF.20706@syntevo.com>
Marc Strapetz venit, vidit, dixit 11.01.2011 15:02:
> On 11.01.2011 13:11, Michael J Gruber wrote:
>> Marc Strapetz venit, vidit, dixit 03.01.2011 18:18:
>>> I'm looking for an unobtrusive way to apply (committed) changes for
>>> text/eol attributes to the working tree. For instance, after having
>>> changed "*.txt eol=crlf" to "*.txt eol=lf", all *.txt files should be
>>> converted from CRLF to LF endings. The only advice I found so far is to
>>> remove .git/index and do a reset --hard. The disadvantage of this
>>> approach is that every file will be touched:
>>>
>>> - although the content does not change, timestamps will be changed. This
>>
>> The bytewise content does change.
>
> The content has only changed for *.txt files, but the timestamps of
> *all* files are updated. I guess (but didn't verify from code), that in
Well, sure...
> case of missing .git/index, Git freshly writes all working tree files,
> ignoring already existing files which already have the correct content.
> Maybe this behavior is by intention and makes sense in some cases. In my
> case it has adverse effects on IDEs and probably other tools which are
> monitoring the file system.
...but changing gitattributes is something you don't do routinely in
your workflow; so, at worst there would be an occasional unnecessary run
of your build process.
>
>>> One solution I could think of which might be helpful in other situations
>>> as well would be to have an "--unobtrusive" option for reset which would
>>> only replace a file if the content has actually been changed.
>>
>> How about
>>
>> git ls-files \*.txt | xargs touch -a
>> git ls-files \*.txt | git checkout
>
> That won't be helpful as it requires me to know what has changed.
But you do know that only (at most) *.txt have changed!
Michael
^ permalink raw reply
* Re: Git unpack-objects on Windows
From: Johannes Sixt @ 2011-01-13 12:30 UTC (permalink / raw)
To: Kevin Sheedy; +Cc: git
In-Reply-To: <1294916875939-5917819.post@n2.nabble.com>
Am 1/13/2011 12:07, schrieb Kevin Sheedy:
>
> I'm trying to import a cvs repository into git using cvs2git. After running
> cvs2git, I'm left with a git pack file. I'm now trying to unpack this file
> using:
>
> git unpack-objects < myfile.pack
>
> Or to be more exact:
>
> $ git unpack-objects <
> "C:/dev/cvsToGitWorkingRepository/.git/objects/pack/pack-479ea920f4a7389f8a52eb6062.pack"
> Unpacking objects: 100% (66409/66409), done.
>
> It looks like it worked except I'm not getting any unpacked files.
Only objects are unpacked that are not already in the object store. Since
you did not move the pack file (and its index) away from the object store,
none of its objects needed to be unpacked.
IOW, you observed expected behavior.
Why do you want to unpack some 66000 objects, I have to wonder?
-- Hannes
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again)
From: Luke Kenneth Casson Leighton @ 2011-01-13 11:39 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <AANLkTimkDYCL7+N-Rno1-0p3Gy6o0wYrnuStV_n5k4Hk@mail.gmail.com>
On Sun, Jan 9, 2011 at 5:48 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Sun, Jan 9, 2011 at 8:55 PM, Luke Kenneth Casson Leighton
> <luke.leighton@gmail.com> wrote:
>> you still have to come up with a mapping from "chains" to "pieces".
>> in the bittorrent protocol the mapping is done *entirely* implicitly
>> and algorithmically.
>
> Given a commit SHA-1, the mapping can be done algorithmically because
> the graph from the commit tip is fixed. Perhaps not mapping all at
> once, but as you have more pieces in the graph, you can map more.
you're _sure_ about this? what happens when new commits get added,
and change that graph? are you _certain_ that you can write an
algorithm which is capable of generating exactly the same mapping,
even as more commits are added to the repository being mirrored, or,
does that situation not matter?
l.
^ permalink raw reply
* [PATCH] t0000: quote TAP snippets in test code
From: Thomas Rast @ 2011-01-13 11:30 UTC (permalink / raw)
To: git; +Cc: Ævar Arnfjörð Bjarmason, Junio C Hamano
t0000 contains two snippets of actual test output. This causes
problems when passing -v to the test[*]: the test infrastructure
echoes the tests before running them, and the TAP parser then sees
this test output and concludes that two tests failed and that the TAP
output was badly formatted.
Guard against this by quoting the output in the source.
[*] either by running 'make smoke' with GIT_TEST_OPTS=-v, or with
prove ./t0000-basic.sh :: -v
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
t/t0000-basic.sh | 36 ++++++++++++++++++------------------
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 2f7002a..8deec75 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -80,11 +80,11 @@ EOF
chmod +x passing-todo.sh &&
./passing-todo.sh >out 2>err &&
! test -s err &&
-cat >expect <<EOF &&
-ok 1 - pretend we have fixed a known breakage # TODO known breakage
-# fixed 1 known breakage(s)
-# passed all 1 test(s)
-1..1
+sed -e 's/^> //' >expect <<EOF &&
+> ok 1 - pretend we have fixed a known breakage # TODO known breakage
+> # fixed 1 known breakage(s)
+> # passed all 1 test(s)
+> 1..1
EOF
test_cmp expect out)
"
@@ -164,19 +164,19 @@ EOF
test_must_fail ./failing-cleanup.sh >out 2>err &&
! test -s err &&
! test -f \"trash directory.failing-cleanup/clean-after-failure\" &&
-sed -e 's/Z$//' >expect <<\EOF &&
-not ok - 1 tests clean up even after a failure
-# Z
-# touch clean-after-failure &&
-# test_when_finished rm clean-after-failure &&
-# (exit 1)
-# Z
-not ok - 2 failure to clean up causes the test to fail
-# Z
-# test_when_finished \"(exit 2)\"
-# Z
-# failed 2 among 2 test(s)
-1..2
+sed -e 's/Z$//' -e 's/^> //' >expect <<\EOF &&
+> not ok - 1 tests clean up even after a failure
+> # Z
+> # touch clean-after-failure &&
+> # test_when_finished rm clean-after-failure &&
+> # (exit 1)
+> # Z
+> not ok - 2 failure to clean up causes the test to fail
+> # Z
+> # test_when_finished \"(exit 2)\"
+> # Z
+> # failed 2 among 2 test(s)
+> 1..2
EOF
test_cmp expect out)
"
--
1.7.4.rc1.309.g58aa0
^ permalink raw reply related
* Git unpack-objects on Windows
From: Kevin Sheedy @ 2011-01-13 11:07 UTC (permalink / raw)
To: git
I'm trying to import a cvs repository into git using cvs2git. After running
cvs2git, I'm left with a git pack file. I'm now trying to unpack this file
using:
git unpack-objects < myfile.pack
Or to be more exact:
$ git unpack-objects <
"C:/dev/cvsToGitWorkingRepository/.git/objects/pack/pack-479ea920f4a7389f8a52eb6062.pack"
Unpacking objects: 100% (66409/66409), done.
It looks like it worked except I'm not getting any unpacked files.
Has anybody gotten git unpack-objects to work on a Windows system?
--
View this message in context: http://git.661346.n2.nabble.com/Git-unpack-objects-on-Windows-tp5917819p5917819.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC/PATCH] Documentation: start to explain what git replace is for
From: Alexey Shumkin @ 2011-01-13 7:52 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20110112T232501-316@post.gmane.org>
Maaartin <grajcar1 <at> seznam.cz> writes:
> I know unicode exists already for many years, but in cygwin I get just a bunch
> of question marks instead of the name. So I'd suggest to replace "Алексей
> Шумкин" by "Alexej Shumkin" or whatever his preferred transcription is.
"Alexey Shumkin" I'd prefer ) (it can be noticed in the patche)
I use email-client for this account primarily for Russian correspondents
so the signature is in Russian
* "Maybe that's the reason to know how "The Bat!" can change letter
templates for particular recipients" he thought *
^ permalink raw reply
* [PATCH 2/2] RelNotes/1.7.4: remove helper script traces
From: Michael J Gruber @ 2011-01-13 9:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <be158c63c44562e87488d742148f54d1c71107df.1294911294.git.git@drmicha.warpmail.net>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Dunno whether you do this automatically on release.
Documentation/RelNotes/1.7.4.txt | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/Documentation/RelNotes/1.7.4.txt b/Documentation/RelNotes/1.7.4.txt
index 48dd964..21e1e3f 100644
--- a/Documentation/RelNotes/1.7.4.txt
+++ b/Documentation/RelNotes/1.7.4.txt
@@ -144,8 +144,3 @@ release, unless otherwise noted.
* "git submodule update --recursive --other-flags" passes flags down
to its subinvocations.
----
-exec >/var/tmp/1
-O=v1.7.4-rc1
-echo O=$(git describe master)
-git shortlog --no-merges ^maint ^$O master
--
1.7.4.rc1.253.gb7420
^ permalink raw reply related
* [PATCH 1/2] RelNotes/1.7.4: minor fixes
From: Michael J Gruber @ 2011-01-13 9:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/RelNotes/1.7.4.txt | 50 +++++++++++++++++++-------------------
1 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/Documentation/RelNotes/1.7.4.txt b/Documentation/RelNotes/1.7.4.txt
index 055c1ca..48dd964 100644
--- a/Documentation/RelNotes/1.7.4.txt
+++ b/Documentation/RelNotes/1.7.4.txt
@@ -15,7 +15,7 @@ Updates since v1.7.3
themselves. The name of a branch cannot begin with a dash now.
* System-wide fallback default attributes can be stored in
- /etc/gitattributes; core.attributesfile configuration variable can
+ /etc/gitattributes; the core.attributesfile configuration variable can
be used to customize the path to this file.
* The thread structure generated by "git send-email" has changed
@@ -25,39 +25,39 @@ Updates since v1.7.3
cover letter of the previous series; this has been changed to make
the patches in the new series replies to the new cover letter.
- * Bash completion script in contrib/ has been adjusted to be usable with
- Bash 4 (options with '=value' didn't complete) It has been also made
+ * The Bash completion script in contrib/ has been adjusted to be usable with
+ Bash 4 (options with '=value' didn't complete). It has been also made
usable with zsh.
* Different pagers can be chosen depending on which subcommand is
- being run under the pager, using "pager.<subcommand>" variable.
+ being run under the pager, using the "pager.<subcommand>" variable.
- * The hardcoded tab-width of 8 used in whitespace breakage checks is now
+ * The hardcoded tab-width of 8 that is used in whitespace breakage checks is now
configurable via the attributes mechanism.
* Support of case insensitive filesystems (i.e. "core.ignorecase") has
been improved. For example, the gitignore mechanism didn't pay attention
- to the case insensitivity.
+ to case insensitivity.
- * The <tree>:<path> syntax to name a blob in a tree, and :<path>
- syntax to name a blob in the index (e.g. "master:Makefile",
+ * The <tree>:<path> syntax for naming a blob in a tree, and the :<path>
+ syntax for naming a blob in the index (e.g. "master:Makefile",
":hello.c") have been extended. You can start <path> with "./" to
implicitly have the (sub)directory you are in prefixed to the
lookup. Similarly, ":../Makefile" from a subdirectory would mean
"the Makefile of the parent directory in the index".
- * "git blame" learned --show-email option to display the e-mail
+ * "git blame" learned the --show-email option to display the e-mail
addresses instead of the names of authors.
- * "git commit" learned --fixup and --squash options to help later invocation
- of the interactive rebase.
+ * "git commit" learned the --fixup and --squash options to help later invocation
+ of interactive rebase.
* Command line options to "git cvsimport" whose names are in capital
letters (-A, -M, -R and -S) can now be specified as the default in
the .git/config file by their longer names (cvsimport.authorsFile,
cvsimport.mergeRegex, cvsimport.trackRevisions, cvsimport.ignorePaths).
- * "git daemon" can be built in MinGW environment.
+ * "git daemon" can be built in the MinGW environment.
* "git daemon" can take more than one --listen option to listen to
multiple addresses.
@@ -65,13 +65,13 @@ Updates since v1.7.3
* "git describe --exact-match" was optimized not to read commit
objects unnecessarily.
- * "git diff" and "git grep" learned how functions and subroutines
+ * "git diff" and "git grep" learned what functions and subroutines
in Fortran look like.
- * "git fetch" learned "--recurse-submodules" option.
+ * "git fetch" learned the "--recurse-submodules" option.
- * "git mergetool" tells vim/gvim to show three-way diff by default
- (use vimdiff2/gvimdiff2 as the tool name for old behaviour).
+ * "git mergetool" tells vim/gvim to show a three-way diff by default
+ (use vimdiff2/gvimdiff2 as the tool name for old behavior).
* "git log -G<pattern>" limits the output to commits whose change has
added or deleted lines that match the given pattern.
@@ -91,12 +91,12 @@ Updates since v1.7.3
directory in one branch while a new file is created in place of that
directory in the other branch.
- * "git rebase --autosquash" can use SHA-1 object names to name which
- commit to fix up (e.g. "fixup! e83c5163").
+ * "git rebase --autosquash" can use SHA-1 object names to name the
+ commit which is to be fixed up (e.g. "fixup! e83c5163").
- * The default "recursive" merge strategy learned --rename-threshold
+ * The default "recursive" merge strategy learned the --rename-threshold
option to influence the rename detection, similar to the -M option
- of "git diff". From "git merge" frontend, "-X<strategy option>"
+ of "git diff". From the "git merge" frontend, the "-X<strategy option>"
interface, e.g. "git merge -Xrename-threshold=50% ...", can be used
to trigger this.
@@ -104,21 +104,21 @@ Updates since v1.7.3
changes; the most notable is -Xignore-space-at-eol.
* "git send-email" learned "--to-cmd", similar to "--cc-cmd", to read
- recipient list from a command output.
+ the recipient list from a command output.
* "git send-email" learned to read and use "To:" from its input files.
* you can extend "git shell", which is often used on boxes that allow
- git-only login over ssh as login shell, with custom set of
+ git-only login over ssh as login shell, with a custom set of
commands.
* The current branch name in "git status" output can be colored differently
- from the generic header color by setting "color.status.branch" variable.
+ from the generic header color by setting the "color.status.branch" variable.
* "git submodule sync" updates metainformation for all submodules,
not just the ones that have been checked out.
- * gitweb can use custom 'highlight' command with its configuration file.
+ * gitweb can use a custom 'highlight' command with its configuration file.
* other gitweb updates.
@@ -129,7 +129,7 @@ Also contains various documentation updates.
Fixes since v1.7.3
------------------
-All of the fixes in v1.7.3.X maintenance series are included in this
+All of the fixes in the v1.7.3.X maintenance series are included in this
release, unless otherwise noted.
* "git log --author=me --author=her" did not find commits written by
--
1.7.4.rc1.253.gb7420
^ permalink raw reply related
* Re: git-repack & big files
From: Pietro Battiston @ 2011-01-13 8:00 UTC (permalink / raw)
To: Phillip Susi; +Cc: git
In-Reply-To: <4D2CB3F5.106@cfl.rr.com>
Il giorno mar, 11/01/2011 alle 14.48 -0500, Phillip Susi ha scritto:
> On 1/11/2011 2:03 PM, Pietro Battiston wrote:
> > That's unfortunate - I think I prefer to split my mailboxes than to
> > loose many of the nice features git provides. But thanks a lot for the
> > suggestion.
>
> I'm curious what features of git you find helpful for this purpose.
Many more, I guess, that the ones I'll be able to remember now. But for
instance some features that make it better than rdiff-backup are:
1) I like to see how a given file changed at a given point in time with
a comfortable interface - not just "restore this there", or search for
the right diff gzipped somewhere
2) I like to delete some given files/folders that I forgot to
(.git)ignore from all the backups with a single command
3) I love the fact that if I move/rename a file/folder, git notices it
(and doesn't think I just deleted some files and created some others).
Since I often move/rename files/folders, when I knew git I really though
"after years of waiting, finally backups will be smart".
4) in principle - though I admit I still never tried - I like the idea
that if I have two copies of the git repo, I can backup once on each
(think of one staying home and one following me when I travel) and then
rebase one on the other
5) to backup my home the first time, rdiff-backup takes slightly less
than 5 hours and uses 32 GB , git takes around 2 hours and uses 17 GB
6) in general, just having a powerful interface I'm used to
> The
> history log doesn't seem useful at all.
I also like the fact that my commits have comments such as "before
changing PC", "after system upgrade", "before reordering mail"...
> Generally mail is only added,
> and sometimes deleted, never changed, so it also does not seem useful to
> keep multiple revisions.
I'm not sure I get what you mean - mail is added and deleted, hence the
mailbox is changed, hence I find it useful to keep multiple revisions.
> If you really want that though, rdiff-backup
> will do that and keep the old revisions delta compressed.
>
Yes, I think I will live with rdiff-backup. And miss git, but I
perfectly understand that git simply doesn't aim at solving my problem,
and that's fair.
> I use Maildir instead of mbox and do a nightly incremental backup of the
> whole system with dump, so any mail I might loose by accident I can pull
> from the backup if it is older than a day, and I never delete mail.
Yep, Maildir is nice from this point of view. But nope, it is not
practical for me to change now.
thanks to all for suggestions (and sorry for the OT)
Pietro
^ permalink raw reply
* Re: Forcing re-reading files with unchanged stats
From: Junio C Hamano @ 2011-01-13 7:26 UTC (permalink / raw)
To: Jeff King; +Cc: Tomas Carnecky, Maaartin, git
In-Reply-To: <20110113033217.GA32661@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I'm curious what this use case is, and whether it would be acceptable to
> update something like ctime on the files to make them stat-dirty to git.
Changing crlf-related attributes (or filter/smudge) after the fact,
perhaps?
^ permalink raw reply
* What's cooking in git.git (Jan 2011, #03; Wed, 12)
From: Junio C Hamano @ 2011-01-13 5:52 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
I'll start paying much less attention to any new features and enhancements
and shift the focus almost entirely on trivial fixes and regressions from
now on. Hopefully lists will do the same and we can have a fairly short
rc period this cycle. Please remind if there are patches that ought to be
in 1.7.4 but are forgotten.
--------------------------------------------------
[New Topics]
* jk/diff-driver-binary-doc (2011-01-09) 1 commit
(merged to 'next' on 2011-01-10 at 1aa4c70)
+ docs: explain diff.*.binary option
* jn/t9010-work-around-broken-svnadmin (2011-01-06) 1 commit
(merged to 'next' on 2011-01-10 at bd2f619)
+ t9010: svnadmin can fail even if available
* tr/submodule-relative-scp-url (2011-01-10) 1 commit
(merged to 'next' on 2011-01-10 at 895f887)
+ submodule: fix relative url parsing for scp-style origin
The above three should all be 1.7.4 material.
* js/test-windows (2011-01-11) 2 commits
(merged to 'next' on 2011-01-11 at c8274ed)
+ t/README: hint about using $(pwd) rather than $PWD in tests
+ Fix expected values of setup tests on Windows
* ab/p4 (2011-01-11) 1 commit
- git-p4: correct indenting and formatting
* as/userdiff-pascal (2011-01-11) 1 commit
- userdiff: match Pascal class methods
--------------------------------------------------
[Stalled]
* nd/index-doc (2010-09-06) 1 commit
- doc: technical details about the index file format
Half-written but it is a good start. I may need to give some help in
describing more recent index extensions.
* cb/ignored-paths-are-precious (2010-08-21) 1 commit
- checkout/merge: optionally fail operation when ignored files need to be overwritten
This needs tests; also we know of longstanding bugs in related area that
needs to be addressed---they do not have to be part of this series but
their reproduction recipe would belong to the test script for this topic.
It would hurt users to make the new feature on by default, especially the
ones with subdirectories that come and go.
* jk/tag-contains (2010-07-05) 4 commits
- Why is "git tag --contains" so slow?
- default core.clockskew variable to one day
- limit "contains" traversals based on commit timestamp
- tag: speed up --contains calculation
The idea of the bottom one is probably Ok, except that the use of object
flags needs to be rethought, or at least the helper needs to be moved to
builtin/tag.c to make it clear that it should not be used outside the
current usage context.
* jc/rename-degrade-cc-to-c (2011-01-06) 3 commits
- diffcore-rename: fall back to -C when -C -C busts the rename limit
- diffcore-rename: record filepair for rename src
- diffcore-rename: refactor "too many candidates" logic
* jc/rerere-remaining (2011-01-06) 1 commit
- rerere "remaining"
Just a handful of weatherballoon patches without proper tests, in response
to feature/minor fix requests.
--------------------------------------------------
[Cooking]
* rj/test-fixes (2010-12-14) 4 commits
(merged to 'next' on 2011-01-08 at 37ef456)
+ t4135-*.sh: Skip the "backslash" tests on cygwin
+ t3032-*.sh: Do not strip CR from line-endings while grepping on MinGW
+ t3032-*.sh: Pass the -b (--binary) option to sed on cygwin
+ t6038-*.sh: Pass the -b (--binary) option to sed on cygwin
Will merge to 'master' soonish.
* rj/svn-test (2010-12-30) 1 commit
(merged to 'next' on 2011-01-05 at ff38429)
+ lib-git-svn.sh: Move web-server handling code into separate function
Looked low-impact and trivial. Might merge to 'master' sometime before
1.7.4, but we are in no hurry.
* sr/gitweb-hilite-more (2010-12-30) 2 commits
(merged to 'next' on 2011-01-05 at 6b52e7e)
+ gitweb: remove unnecessary test when closing file descriptor
+ gitweb: add extensions to highlight feature map
Looked low-impact and trivial. Might merge to 'master' sometime before
1.7.4, especially highlighting itself is a new feature.
* mz/rebase (2010-12-28) 31 commits
- rebase -i: remove unnecessary state rebase-root
- rebase -i: don't read unused variable preserve_merges
- git-rebase--am: remove unnecessary --3way option
- rebase -m: don't print exit code 2 when merge fails
- rebase -m: remember allow_rerere_autoupdate option
- rebase: remember strategy and strategy options
- rebase: remember verbose option
- rebase: extract code for writing basic state
- rebase: factor out sub command handling
- rebase: make -v a tiny bit more verbose
- rebase -i: align variable names
- rebase: show consistent conflict resolution hint
- rebase: extract am code to new source file
- rebase: extract merge code to new source file
- rebase: remove $branch as synonym for $orig_head
- rebase -i: support --stat
- rebase: factor out call to pre-rebase hook
- rebase: factor out clean work tree check
- rebase: factor out reference parsing
- rebase: reorder validation steps
- rebase -i: remove now unnecessary directory checks
- rebase: factor out command line option processing
- rebase: align variable content
- rebase: align variable names
- rebase: stricter check of standalone sub command
- rebase: act on command line outside parsing loop
- rebase: improve detection of rebase in progress
- rebase: remove unused rebase state 'prev_head'
- rebase: read state outside loop
- rebase: refactor reading of state
- rebase: clearer names for directory variables
I personally haven't finished reading this one yet; Thomas said the
general direction of the series basically seemed sound (with nits here
and there), which I trust. Hopefully we will see a re-roll of this
series sometime soon, but we are not in a hurry.
* ef/alias-via-run-command (2011-01-07) 1 commit
(merged to 'next' on 2011-01-06 at 1fbd4a0)
+ alias: use run_command api to execute aliases
* uk/checkout-ambiguous-ref (2011-01-11) 1 commit
(merged to 'next' on 2011-01-11 at 2aa30de)
+ checkout: fix bug with ambiguous refs
* jn/gitweb-no-logo (2010-09-03) 1 commit
(merged to 'next' on 2011-01-04 at a5d186c)
+ gitweb: make logo optional
Seems trivial but came a bit too late for the cycle.
* cb/setup (2010-12-27) 1 commit
(merged to 'next' on 2011-01-05 at 790b288)
+ setup: translate symlinks in filename when using absolute paths
Seems trivial but came a bit too late for the cycle.
* ae/better-template-failure-report (2010-12-18) 1 commit
(merged to 'next' on 2011-01-05 at d3f9142)
+ Improve error messages when temporary file creation fails
* jc/unpack-trees (2010-12-22) 2 commits
- unpack_trees(): skip trees that are the same in all input
- unpack-trees.c: cosmetic fix
* jn/cherry-pick-strategy-option (2010-12-10) 1 commit
(merged to 'next' on 2011-01-05 at 3ccc590)
+ cherry-pick/revert: add support for -X/--strategy-option
* jn/perl-funcname (2010-12-27) 2 commits
(merged to 'next' on 2011-01-05 at 20542ed)
+ userdiff/perl: catch BEGIN/END/... and POD as headers
+ diff: funcname and word patterns for perl
Looked low-impact and trivial. Might merge to 'master' sometime before
1.7.4, but we are in no hurry.
* tr/maint-branch-no-track-head (2010-12-14) 1 commit
- branch: do not attempt to track HEAD implicitly
Probably needs a re-roll to exclude either (1) any ref outside the
hierarchies for branches (i.e. refs/{heads,remotes}/), or (2) only refs
outside refs/ hierarchies (e.g. HEAD, ORIG_HEAD, ...). The latter feels
safer and saner.
* hv/mingw-fs-funnies (2010-12-14) 5 commits
- mingw_rmdir: set errno=ENOTEMPTY when appropriate
- mingw: add fallback for rmdir in case directory is in use
- mingw: make failures to unlink or move raise a question
- mingw: work around irregular failures of unlink on windows
- mingw: move unlink wrapper to mingw.c
Will be rerolled (Heiko, 2010-12-23)
* nd/struct-pathspec (2010-12-15) 21 commits
- t7810: overlapping pathspecs and depth limit
- grep: drop pathspec_matches() in favor of tree_entry_interesting()
- grep: use writable strbuf from caller for grep_tree()
- grep: use match_pathspec_depth() for cache/worktree grepping
- grep: convert to use struct pathspec
- Convert ce_path_match() to use match_pathspec_depth()
- Convert ce_path_match() to use struct pathspec
- struct rev_info: convert prune_data to struct pathspec
- pathspec: add match_pathspec_depth()
- tree_entry_interesting(): optimize wildcard matching when base is matched
- tree_entry_interesting(): support wildcard matching
- tree_entry_interesting(): fix depth limit with overlapping pathspecs
- tree_entry_interesting(): support depth limit
- tree_entry_interesting(): refactor into separate smaller functions
- diff-tree: convert base+baselen to writable strbuf
- glossary: define pathspec
- Move tree_entry_interesting() to tree-walk.c and export it
- tree_entry_interesting(): remove dependency on struct diff_options
- Convert struct diff_options to use struct pathspec
- diff-no-index: use diff_tree_setup_paths()
- Add struct pathspec
(this branch is used by en/object-list-with-pathspec.)
On hold, perhaps in 'next', til 1.7.4 final.
* en/object-list-with-pathspec (2010-09-20) 2 commits
- Add testcases showing how pathspecs are handled with rev-list --objects
- Make rev-list --objects work together with pathspecs
(this branch uses nd/struct-pathspec.)
On hold, perhaps in 'next', til 1.7.4 final.
* tr/merge-unborn-clobber (2010-08-22) 1 commit
- Exhibit merge bug that clobbers index&WT
* ab/i18n (2010-10-07) 161 commits
- po/de.po: complete German translation
- po/sv.po: add Swedish translation
- gettextize: git-bisect bisect_next_check "You need to" message
- gettextize: git-bisect [Y/n] messages
- gettextize: git-bisect bisect_replay + $1 messages
- gettextize: git-bisect bisect_reset + $1 messages
- gettextize: git-bisect bisect_run + $@ messages
- gettextize: git-bisect die + eval_gettext messages
- gettextize: git-bisect die + gettext messages
- gettextize: git-bisect echo + eval_gettext message
- gettextize: git-bisect echo + gettext messages
- gettextize: git-bisect gettext + echo message
- gettextize: git-bisect add git-sh-i18n
- gettextize: git-stash drop_stash say/die messages
- gettextize: git-stash "unknown option" message
- gettextize: git-stash die + eval_gettext $1 messages
- gettextize: git-stash die + eval_gettext $* messages
- gettextize: git-stash die + eval_gettext messages
- gettextize: git-stash die + gettext messages
- gettextize: git-stash say + gettext messages
- gettextize: git-stash echo + gettext message
- gettextize: git-stash add git-sh-i18n
- gettextize: git-submodule "blob" and "submodule" messages
- gettextize: git-submodule "path not initialized" message
- gettextize: git-submodule "[...] path is ignored" message
- gettextize: git-submodule "Entering [...]" message
- gettextize: git-submodule $errmsg messages
- gettextize: git-submodule "Submodule change[...]" messages
- gettextize: git-submodule "cached cannot be used" message
- gettextize: git-submodule $update_module say + die messages
- gettextize: git-submodule die + eval_gettext messages
- gettextize: git-submodule say + eval_gettext messages
- gettextize: git-submodule echo + eval_gettext messages
- gettextize: git-submodule add git-sh-i18n
- gettextize: git-pull "rebase against" / "merge with" messages
- gettextize: git-pull "[...] not currently on a branch" message
- gettextize: git-pull "You asked to pull" message
- gettextize: git-pull split up "no candidate" message
- gettextize: git-pull eval_gettext + warning message
- gettextize: git-pull eval_gettext + die message
- gettextize: git-pull die messages
- gettextize: git-pull add git-sh-i18n
- gettext docs: add "Testing marked strings" section to po/README
- gettext docs: the Git::I18N Perl interface
- gettext docs: the git-sh-i18n.sh Shell interface
- gettext docs: the gettext.h C interface
- gettext docs: add "Marking strings for translation" section in po/README
- gettext docs: add a "Testing your changes" section to po/README
- po/pl.po: add Polish translation
- po/hi.po: add Hindi Translation
- po/en_GB.po: add British English translation
- po/de.po: add German translation
- Makefile: only add gettext tests on XGETTEXT_INCLUDE_TESTS=YesPlease
- gettext docs: add po/README file documenting Git's gettext
- gettextize: git-am printf(1) message to eval_gettext
- gettextize: git-am core say messages
- gettextize: git-am "Apply?" message
- gettextize: git-am clean_abort messages
- gettextize: git-am cannot_fallback messages
- gettextize: git-am die messages
- gettextize: git-am eval_gettext messages
- gettextize: git-am multi-line getttext $msg; echo
- gettextize: git-am one-line gettext $msg; echo
- gettextize: git-am add git-sh-i18n
- gettext tests: add GETTEXT_POISON tests for shell scripts
- gettext tests: add GETTEXT_POISON support for shell scripts
- Makefile: MSGFMT="msgfmt --check" under GNU_GETTEXT
- Makefile: add GNU_GETTEXT, set when we expect GNU gettext
- gettextize: git-shortlog basic messages
- gettextize: git-revert split up "could not revert/apply" message
- gettextize: git-revert literal "me" messages
- gettextize: git-revert "Your local changes" message
- gettextize: git-revert basic messages
- gettextize: git-notes "Refusing to %s notes in %s" message
- gettextize: git-notes GIT_NOTES_REWRITE_MODE error message
- gettextize: git-notes basic commands
- gettextize: git-gc "Auto packing the repository" message
- gettextize: git-gc basic messages
- gettextize: git-describe basic messages
- gettextize: git-clean clean.requireForce messages
- gettextize: git-clean basic messages
- gettextize: git-bundle basic messages
- gettextize: git-archive basic messages
- gettextize: git-status "renamed: " message
- gettextize: git-status "Initial commit" message
- gettextize: git-status "Changes to be committed" message
- gettextize: git-status shortstatus messages
- gettextize: git-status "nothing to commit" messages
- gettextize: git-status basic messages
- gettextize: git-push "prevent you from losing" message
- gettextize: git-push basic messages
- gettextize: git-tag tag_template message
- gettextize: git-tag basic messages
- gettextize: git-reset "Unstaged changes after reset" message
- gettextize: git-reset reset_type_names messages
- gettextize: git-reset basic messages
- gettextize: git-rm basic messages
- gettextize: git-mv "bad" messages
- gettextize: git-mv basic messages
- gettextize: git-merge "Wonderful" message
- gettextize: git-merge "You have not concluded your merge" messages
- gettextize: git-merge "Updating %s..%s" message
- gettextize: git-merge basic messages
- gettextize: git-log "--OPT does not make sense" messages
- gettextize: git-log basic messages
- gettextize: git-grep "--open-files-in-pager" message
- gettextize: git-grep basic messages
- gettextize: git-fetch split up "(non-fast-forward)" message
- gettextize: git-fetch update_local_ref messages
- gettextize: git-fetch formatting messages
- gettextize: git-fetch basic messages
- gettextize: git-diff basic messages
- gettextize: git-commit advice messages
- gettextize: git-commit "enter the commit message" message
- gettextize: git-commit print_summary messages
- gettextize: git-commit formatting messages
- gettextize: git-commit "middle of a merge" message
- gettextize: git-commit basic messages
- gettextize: git-checkout "Switched to a .. branch" message
- gettextize: git-checkout "HEAD is now at" message
- gettextize: git-checkout describe_detached_head messages
- gettextize: git-checkout: our/their version message
- gettextize: git-checkout basic messages
- gettextize: git-branch "(no branch)" message
- gettextize: git-branch "git branch -v" messages
- gettextize: git-branch "Deleted branch [...]" message
- gettextize: git-branch "remote branch '%s' not found" message
- gettextize: git-branch basic messages
- gettextize: git-add refresh_index message
- gettextize: git-add "remove '%s'" message
- gettextize: git-add "pathspec [...] did not match" message
- gettextize: git-add "Use -f if you really want" message
- gettextize: git-add "no files added" message
- gettextize: git-add basic messages
- gettextize: git-clone "Cloning into" message
- gettextize: git-clone basic messages
- gettext tests: test message re-encoding under C
- po/is.po: add Icelandic translation
- gettext tests: mark a test message as not needing translation
- gettext tests: test re-encoding with a UTF-8 msgid under Shell
- gettext tests: test message re-encoding under Shell
- gettext tests: add detection for is_IS.ISO-8859-1 locale
- gettext tests: test if $VERSION exists before using it
- gettextize: git-init "Initialized [...] repository" message
- gettextize: git-init basic messages
- gettext tests: skip lib-gettext.sh tests under GETTEXT_POISON
- gettext tests: add GETTEXT_POISON=YesPlease Makefile parameter
- gettext.c: use libcharset.h instead of langinfo.h when available
- gettext.c: work around us not using setlocale(LC_CTYPE, "")
- builtin.h: Include gettext.h
- Makefile: use variables and shorter lines for xgettext
- Makefile: tell xgettext(1) that our source is in UTF-8
- Makefile: provide a --msgid-bugs-address to xgettext(1)
- Makefile: A variable for options used by xgettext(1) calls
- gettext tests: locate i18n lib&data correctly under --valgrind
- gettext: setlocale(LC_CTYPE, "") breaks Git's C function assumptions
- gettext tests: rename test to work around GNU gettext bug
- gettext: add infrastructure for translating Git with gettext
- builtin: use builtin.h for all builtin commands
- tests: use test_cmp instead of piping to diff(1)
- t7004-tag.sh: re-arrange git tag comment for clarity
It is getting ridiculously painful to keep re-resolving the conflicts with
other topics in flight, even with the help with rerere.
Needs a bit more minor work to get the basic code structure right.
--------------------------------------------------
[Ejected]
* jn/svn-fe (2010-12-06) 17 commits
. vcs-svn: Allow change nodes for root of tree (/)
. vcs-svn: Implement Prop-delta handling
. vcs-svn: Sharpen parsing of property lines
. vcs-svn: Split off function for handling of individual properties
. vcs-svn: Make source easier to read on small screens
. vcs-svn: More dump format sanity checks
. vcs-svn: Reject path nodes without Node-action
. vcs-svn: Delay read of per-path properties
. vcs-svn: Combine repo_replace and repo_modify functions
. vcs-svn: Replace = Delete + Add
. vcs-svn: handle_node: Handle deletion case early
. vcs-svn: Use mark to indicate nodes with included text
. vcs-svn: Unclutter handle_node by introducing have_props var
. vcs-svn: Eliminate node_ctx.mark global
. vcs-svn: Eliminate node_ctx.srcRev global
. vcs-svn: Check for errors from open()
. vcs-svn: Allow simple v3 dumps (no deltas yet)
Some RFC patches, to give them early and wider exposure. Ejected for now.
^ permalink raw reply
* Re: [PATCH 1/2] unpack-trees: handle lstat failure for existing directory
From: Jonathan Nieder @ 2011-01-13 5:38 UTC (permalink / raw)
To: Miles Bader
Cc: git, gitster, Nguyễn Thái Ngọc Duy,
Clemens Buchacher, Alex Riesen
In-Reply-To: <buobp3ls9l1.fsf@dhlpc061.dev.necel.com>
Miles Bader wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> @@ -1382,7 +1382,9 @@ static int verify_absent_1(struct cache_entry *ce,
>> return check_ok_to_remove(ce->name, ce_namelen(ce),
>> ce_to_dtype(ce), ce, &st,
>> error_type, o);
>> -
>> + if (errno != ENOENT)
>> + return error("cannot stat '%s': %s", ce->name,
>> + strerror(errno));
>> return 0;
>
> Is errno guaranteed to be set to something relevant at this point in the
> code...?
Yes, because lstat failed. But perhaps that is a hint that the code
should be restructured as
} else if (lstat(... )) {
if (errno != ENOENT)
return error(...
return 0;
} else {
return check_ok_to_remove(...
}
^ permalink raw reply
* Re: [PATCH 1/2] unpack-trees: handle lstat failure for existing directory
From: Miles Bader @ 2011-01-13 4:37 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, gitster, Nguyễn Thái Ngọc Duy,
Clemens Buchacher, Alex Riesen
In-Reply-To: <20110113022636.GB8635@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> @@ -1382,7 +1382,9 @@ static int verify_absent_1(struct cache_entry *ce,
> return check_ok_to_remove(ce->name, ce_namelen(ce),
> ce_to_dtype(ce), ce, &st,
> error_type, o);
> -
> + if (errno != ENOENT)
> + return error("cannot stat '%s': %s", ce->name,
> + strerror(errno));
> return 0;
Is errno guaranteed to be set to something relevant at this point in the
code...?
-miels
--
Religion, n. A daughter of Hope and Fear, explaining to Ignorance the nature
of the Unknowable.
^ 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