From: Erik Faye-Lund kusmab...@googlemail.com
On Windows, absolute paths might start with a DOS drive prefix,
which these two checks failed to recognize.
Unfortunately, we cannot simply use the file_name_is_absolute
helper in File::Spec::Functions, because Git for Windows has an
MSYS-based Perl,
Thank you for the feedback!
Imagine the case where there are more than one branches
whose tip points at the commit you came from.
name-rev will not be able to pick correctly which one to report.
I see. Yes, you're exactly right; the following demonstrates
the problem:
$ git checkout -b
The output from a successful invocation of the shorthand command
git rebase - is something like Fast-forwarded HEAD to @{-1},
which includes a relative reference to a revision. Other commands
that use the shorthand -, such as git checkout -, typically
display the symbolic name of the revision.
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
contrib/credential/osxkeychain/git-credential-osxkeychain.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
compat/regex/regex_internal.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/compat/regex/regex_internal.c b/compat/regex/regex_internal.c
index d4121f2..a7a71ec 100644
--- a/compat/regex/regex_internal.c
+++
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
compat/regex/regcomp.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c
index 06f3088..c7da378 100644
--- a/compat/regex/regcomp.c
+++
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
contrib/credential/wincred/git-credential-wincred.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/contrib/credential/wincred/git-credential-wincred.c
b/contrib/credential/wincred/git-credential-wincred.c
index
Helló
a nevem Nora kedvem, hogy Önnel a kapcsolatot, miután megy keresztül a profil
ezen az oldalon, miközben keresi a kapcsolatot. Én nagyon örülök, hogy a
barátod, kérjük, ha nem bánja, azt fogom szeretni, hogy írjon nekem vissza az e-
mail címemet. (
johnson.nora31 @ yahoo.com)
úgy, hogy én
On Wed, Apr 16, 2014 at 11:33 AM, Elia Pinto gitter.spi...@gmail.com wrote:
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
contrib/credential/wincred/git-credential-wincred.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
On Wed, Apr 16, 2014 at 11:33 AM, Elia Pinto gitter.spi...@gmail.com wrote:
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
xdiff/xprepare.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xdiff/xprepare.c b/xdiff/xprepare.c
index 63a22c6..e0b6987 100644
On 16/04/2014 07:48, Torsten Bögershausen wrote:
On 15.04.14 21:10, Peter Krefting wrote:
Torsten Bögershausen:
diff --git a/utf8.c b/utf8.c
index a831d50..77c28d4 100644
--- a/utf8.c
+++ b/utf8.c
Is there a script that generates this code from the Unicode database files, or
did you
On 16/04/14 00:18, Duy Nguyen wrote:
On Tue, Apr 15, 2014 at 11:45 PM, Junio C Hamano gits...@pobox.com wrote:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
On 11/04/14 23:22, Junio C Hamano wrote:
[...]
[New Topics]
* nd/index-pack-one-fd-per-thread (2014-04-09) 1 commit
- index-pack:
Am 15.04.2014 um 23:23 schrieb Junio C Hamano gits...@pobox.com:
Brandon McCaig bamcc...@gmail.com writes:
That is for your benefit, and for easily sharing that configuration
with collaborators. Git only cares that the file exists in your
working tree at run-time.
It is a lot more than
On Mon, Apr 14, 2014 at 11:41 PM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder chrisc...@tuxfamily.org writes:
Yeah, except that we could add for example a '-o' option that would
take a directory as argument and that would mean that the command
should operate on all the files in
Date: Thu, 10 Apr 2014 16:37:15 +0200
This change fixes a gcc warning when building msysGit.
---
config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index 314d8ee..0b7e4f8 100644
--- a/config.c
+++ b/config.c
@@ -572,7 +572,7 @@ static void
From: Jean-Jacques Lafay jeanjacques.la...@gmail.com
Date: Sat, 10 Nov 2012 18:36:10 +0100
In large repos, the recursion implementation of contains(commit,
commit_list) may result in a stack overflow. Replace the recursion with
a loop to fix it.
This problem is more apparent on Windows than on
From: RomanBelinsky belinsky.ro...@gmail.com
Date: Tue, 11 Feb 2014 18:23:02 +0200
fix parsing error for dates like:
2014-01-07T5:58:36.048176Z
previous regex can parse only:
2014-01-07T05:58:36.048176Z
reproduced in my svn repository during conversion.
Signed-off-by: Stepan Kasal ka...@ucw.cz
On 04/15/2014 08:49 AM, Johannes Sixt wrote:
Am 4/14/2014 15:54, schrieb Michael Haggerty:
diff --git a/lockfile.c b/lockfile.c
index 664b0c3..1453a7a 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -292,6 +292,9 @@ int commit_lock_file(struct lock_file *lk)
if (lk-fd = 0
On Wed, Apr 16, 2014 at 04:13:53PM +0200, Stepan Kasal wrote:
Date: Thu, 10 Apr 2014 16:37:15 +0200
This change fixes a gcc warning when building msysGit.
What warning? I'm assuming -Wuninitialized?
diff --git a/config.c b/config.c
index 314d8ee..0b7e4f8 100644
--- a/config.c
+++
On 04/15/2014 08:55 AM, Johannes Sixt wrote:
Am 4/14/2014 15:54, schrieb Michael Haggerty:
The function remove_lock_file_on_signal() is used as a signal handler.
It is not realistic to make the signal handler conform strictly to the
C standard, which is very restrictive about what a signal
On Wed, Apr 16, 2014 at 04:15:19PM +0200, Stepan Kasal wrote:
From: Jean-Jacques Lafay jeanjacques.la...@gmail.com
Date: Sat, 10 Nov 2012 18:36:10 +0100
In large repos, the recursion implementation of contains(commit,
commit_list) may result in a stack overflow. Replace the recursion with
On 2014-04-16 17.29, Jeff King wrote:
On Wed, Apr 16, 2014 at 04:13:53PM +0200, Stepan Kasal wrote:
Date: Thu, 10 Apr 2014 16:37:15 +0200
This change fixes a gcc warning when building msysGit.
[]
+NORETURN
static void die_bad_number(const char *name, const char *value)
{
const
Kyle J. McKay mack...@gmail.com writes:
On Apr 14, 2014, at 15:51, Junio C Hamano wrote:
I think we would want to see the actual change formatted this way
(without needing to pass -w to git show), as it will make it
clear that this artificial extra level of define the whole thing
inside a
Hi,
Elia Pinto wrote:
[Subject: compat/regex/regcomp.c: reduce scope of variables]
gnulib regex is still maintained upstream and available under the
LGPL 2.1+. Shouldn't we make the change there and reimport to
make it easier to pull in later changes?
Thanks,
Jonathan
--
To unsubscribe from
Frank Ammeter g...@ammeter.ch writes:
Am 15.04.2014 um 23:23 schrieb Junio C Hamano gits...@pobox.com:
Brandon McCaig bamcc...@gmail.com writes:
That is for your benefit, and for easily sharing that configuration
with collaborators. Git only cares that the file exists in your
working tree
On Tue, Apr 15, 2014 at 1:32 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 04/15/2014 06:33 PM, Ronnie Sahlberg wrote:
On Mon, Apr 14, 2014 at 11:36 PM, Michael Haggerty mhag...@alum.mit.edu
wrote:
[...]
I wonder, however, whether your approach of changing callers from
lock =
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
Jeff King p...@peff.net writes:
On Wed, Apr 16, 2014 at 06:38:19PM +0200, Torsten Bögershausen wrote:
Does that also silence the warning?
This works under gcc 4.2.1 Mac OS: the warning is away.
Thanks. I couldn't test myself, as I could not get gcc to generate the
warning in the first
a...@bellandwhistle.net writes:
Any clarification on the differences much appreciated:
http://stackoverflow.com/questions/23097368/git-ignore-vs-exclude-vs-assume-unchanged/23097509
Please don't force people to refer to external site.
The .gitignore and .git/info/exclude are the two UIs to
Any clarification on the differences much appreciated:
http://stackoverflow.com/questions/23097368/git-ignore-vs-exclude-vs-assume-unchanged/23097509
--
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
Junio C Hamano gits...@pobox.com writes:
Kyle J. McKay mack...@gmail.com writes:
If I'm the only one getting a wrong meaning from the comments, then no
reason to change them.
I agree that the description does not read well with the work-around
already there. I am not sure what would be a
Junio C Hamano gits...@pobox.com writes:
By the way, you have this in your log message:
... the git-rebase--*.sh scripts have used a return to return
from the dot command that runs them. While this is allowed by
POSIX,...
Is it this is allowed, or is it this should be the way
Junio C Hamano gits...@pobox.com writes:
... I am looking at this
more from the angle of obtaining a useful building block, while you
seem to be thinking of this as a specialized tool for a narrow set
of specifkc tasks.
By the way, I am speaking with a bitter experience of designing the
Junio C Hamano gits...@pobox.com writes:
... I am being
cautious here because I do not see us making the same mistake.
s/do not/ want to/
Sorry for the noise.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
Move the check for the lock failure to happen immediately after
lock_any_ref_for_update().
Previously the lock and the check-if-lock-failed was separated by a handful
of string manipulation statements.
Moving the check to occur immediately after the failed lock makes the
code slightly easier to
Callers outside of refs.c use either lock_ref_sha1() or
lock_any_ref_for_update() to lock a ref during an update.
Two of these places we do not immediately check the lock for failure
making reading the code harder.
One place we do some unrelated string manipulation fucntions before we
check for
Change fast_forward_to() to check if locking the ref failed, print a nice
error message and bail out early.
The old code did not check if ref_lock was NULL and relied on the fact
that the write_ref_sha1() would safely detect this condition and set the
return variable ret to indicate an error.
Junio C Hamano gits...@pobox.com writes:
Furthermore, were we to translate @{-1}, does that mean we
should also translate @{-2} or prior?
Surely, why not. If a user is so forgetful to need help remembering
where s/he was immediately before, wouldn't it be more helpful to
give here is where
Stepan Kasal ka...@ucw.cz writes:
From: RomanBelinsky belinsky.ro...@gmail.com
Date: Tue, 11 Feb 2014 18:23:02 +0200
fix parsing error for dates like:
2014-01-07T5:58:36.048176Z
previous regex can parse only:
2014-01-07T05:58:36.048176Z
reproduced in my svn repository during conversion.
Ronnie Sahlberg sahlb...@google.com writes:
Currently any locking of refs in a transaction only happens during the commit
phase. I think it would be useful to have a mechanism where you could
optionally take out locks for the involved refs early during the transaction.
So that simple callers
On 04/15/2014 08:40 PM, Torsten Bögershausen wrote:
refs.c:
int close_ref(struct ref_lock *lock)
{
if (close_lock_file(lock-lk))
return -1;
lock-lock_fd = -1;
return 0;
}
When the close() fails, fd is still = 0, even if the file is closed.
Could it be
On 2014-04-16 12.51, Kevin Bracey wrote:
On 16/04/2014 07:48, Torsten Bögershausen wrote:
On 15.04.14 21:10, Peter Krefting wrote:
Torsten Bögershausen:
diff --git a/utf8.c b/utf8.c
index a831d50..77c28d4 100644
--- a/utf8.c
+++ b/utf8.c
Is there a script that generates this code from the
From: Luis R. Rodriguez mcg...@suse.com
Upstream Linux kernel commit c5905afb was introduced on v3.4 but
git describe --contains yields v3.5 while if we use git to look
for the first parent with git describe --first-parent yields
v3.3. The reason for this seems to be that the merge commit that
On Wed, Apr 16, 2014 at 12:31 PM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
Currently any locking of refs in a transaction only happens during the commit
phase. I think it would be useful to have a mechanism where you could
optionally take out locks
Ronnie Sahlberg sahlb...@google.com writes:
I am not sure if that is the right way to go, or instead change all
create/update/delete to take locks without adding a new primitive.
ack.
Hmph. When I say I am not sure, I dunno, etc., I do mean it.
Did you mean by Ack I do not know, either, or
On 04/16/2014 09:31 PM, Junio C Hamano wrote:
Ronnie Sahlberg sahlb...@google.com writes:
Currently any locking of refs in a transaction only happens during the commit
phase. I think it would be useful to have a mechanism where you could
optionally take out locks for the involved refs early
发自我的 iPad
Luis R. Rodriguez mcg...@do-not-panic.com writes:
From: Luis R. Rodriguez mcg...@suse.com
Upstream Linux kernel commit c5905afb was introduced on v3.4 but
git describe --contains yields v3.5
Actually, describe --contains should yield v3.5-rc1~120^3~76^2,
not v3.5.
And you are right that the
On 04/16/2014 08:56 PM, Ronnie Sahlberg wrote:
Change fast_forward_to() to check if locking the ref failed, print a nice
error message and bail out early.
The old code did not check if ref_lock was NULL and relied on the fact
that the write_ref_sha1() would safely detect this condition and set
On 04/16/2014 08:56 PM, Ronnie Sahlberg wrote:
Move the check for the lock failure to happen immediately after
lock_any_ref_for_update().
Previously the lock and the check-if-lock-failed was separated by a handful
of string manipulation statements.
Please flow sentences together into
On Wed, Apr 16, 2014 at 3:02 PM, Junio C Hamano gits...@pobox.com wrote:
Luis R. Rodriguez mcg...@do-not-panic.com writes:
From: Luis R. Rodriguez mcg...@suse.com
Upstream Linux kernel commit c5905afb was introduced on v3.4 but
git describe --contains yields v3.5
Actually, describe
A note for translators in date.c is not included in git.pot.
Namely, the following note from date.c:147 is not included
(https://github.com/git/git/blob/v1.9.2/date.c#L147):
/* TRANSLATORS: %s is n years */
This is a very useful note for translators (in fact, I think
the zh_CN translation for
On 2014-04-16 10:51, Junio C Hamano wrote:
a...@bellandwhistle.net writes:
Any clarification on the differences much appreciated:
http://stackoverflow.com/questions/23097368/git-ignore-vs-exclude-vs-assume-unchanged/23097509
Please don't force people to refer to external site.
The
The concept of n-th prior checkout (aka @{-n}) and immediately
previous checkout (aka -) are equivalent, even though the former
may be more generic.
You seem to be saying that those who understand the former are with
superiour mental capacity in general than those who only know the
latter,
Hi,
a...@bellandwhistle.net wrote:
In particular, 'exclude' is spottily documented.
Where did you expect to read about it? I see some mention of
.git/info/exclude in the gitignore(5) page, but I wouldn't be
surprised if there's room for improvement there (improvements
welcome).
On Apr 16, 2014, at 11:11, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Kyle J. McKay mack...@gmail.com writes:
If I'm the only one getting a wrong meaning from the comments,
then no
reason to change them.
I agree that the description does not read well with the
On Sun, Apr 13, 2014 at 5:54 PM, Kumar Appaiah
a.ku...@alumni.iitm.ac.in wrote:
This commit adds custom log_read and log_draw functions that utilize
the diff stat drawing functions from the diff module. The absence of
the triple hyphen separator prevents direct usage of the diff drawing
Hi Kumar,
On Sun, Apr 13, 2014 at 5:54 PM, Kumar Appaiah
a.ku...@alumni.iitm.ac.in wrote:
These patches add colourization to the log view. They reuse the diff
stat drawing functions from the diff module directly.
This is a great idea. I wonder though if it would make sense to put
this into
Dear valued customer,
Do you need an urgent loan to pay of your bills, invest more on your business,
if yes PREMIUM CAPITAL LOAN offer loan at 3% interest rate. We are fast and
reliable when it comes to loan lending contact email:
premiumcapitall...@hotmail.co.uk for more information.
Contact
On Wed, Apr 16, 2014 at 08:44:41PM -0400, Jonas Fonseca wrote:
On Sun, Apr 13, 2014 at 5:54 PM, Kumar Appaiah
a.ku...@alumni.iitm.ac.in wrote:
This commit adds custom log_read and log_draw functions that utilize
the diff stat drawing functions from the diff module. The absence of
the
2014-04-17 6:51 GMT+08:00 Brian Gesiak modoca...@gmail.com:
A note for translators in date.c is not included in git.pot.
Namely, the following note from date.c:147 is not included
(https://github.com/git/git/blob/v1.9.2/date.c#L147):
/* TRANSLATORS: %s is n years */
Comments for translators
On Wed, Apr 16, 2014 at 10:19:54AM -0700, Junio C Hamano wrote:
Ahh, OK, if you did so, you won't have any place to hook the only
on msys do this trick into.
It somehow feels somewhat confusing that we define a sub with the
same name as the system one, while not overriding it entirely but
Hello,
On Wed, Apr 16, 2014 at 12:13:21PM -0700, Junio C Hamano wrote:
Interesting. What other strange forms can they record in their
repositories, I have to wonder. Can they do
2014-01-07T5:8:6.048176Z
for example?
Roman Belinsky, the author of this fix, witnessed after large scale
When generate git.pot, many irrelevant comments are extracted as references
for translators, but one useful comment is lost. This series patches will
fix this issue.
Jiang Xin (3):
i18n: Fixes uncatchable comments for translators
i18n: Only extract comments marked by special tag
i18n:
Comment for l10n translators can not be extracted by xgettext if it is
not right above the l10n tag. Moving the comment right before the l10n
tag will fix this issue.
Reported-by: Brian Gesiak modoca...@gmail.com
Signed-off-by: Jiang Xin worldhello@gmail.com
---
date.c | 2 +-
1 file
Since we do not translate diffstat any more, remove the obsolete comments.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
diff.c | 8
1 file changed, 8 deletions(-)
diff --git a/diff.c b/diff.c
index 539997f..54d5308 100644
--- a/diff.c
+++ b/diff.c
@@ -1461,20 +1461,12 @@ int
When extract l10n messages, we use --add-comments option to keep
comments right above the l10n messages for references. But sometimes
irrelevant comments are also extracted. For example in the following
code block, the comment in line 2 will be extracted as comment for the
l10n message in line
2014-04-17 13:37 GMT+08:00 Jiang Xin worldhello@gmail.com:
When generate git.pot, many irrelevant comments are extracted as references
for translators, but one useful comment is lost. This series patches will
fix this issue.
Brief changes of po/git.pot after applied these patches:
diff
This patch serves as a heads up about a feature I'm working on. I hope
that by posting it early, people could double check if I have made
some fundamental mistakes that completely ruin the idea. It's about
speeding up git status by caching untracked file info in the index
_if_ your file system
79 matches
Mail list logo
