Subversion can put mergeinfo on any sub-directory to track cherry-picks.
Since cherry-picks are not represented explicitly in git, git-svn should
just ignore it.
Signed-off-by: Jakob Stoklund Olesen
---
perl/Git/SVN.pm | 29 +
1 file changed, 13 insertions(+), 16 dele
In a Subversion repository where many feature branches are merged into a
trunk, the svn:mergeinfo property can grow very large. This severely
slows down git-svn's make_log_entry() because it is checking all
mergeinfo entries every time the property changes.
In most cases, the additions to svn:merg
On 16/04/2014 22:58, Torsten Bögershausen wrote:
Excellent, thanks for the pointers.
Running the script below shows that
"0X00AD SOFT HYPHEN" should have zero length (and some others too).
I wonder if that is really the case, and which one of the last 2 lines
in the script is the right one.
What
2014-04-17 6:51 GMT+08:00 Brian Gesiak :
> According to po/README, the l10n coordinator is responsible
> for updating the git.pot file. Would it be possible to update it based
> on v1.9.2 and include the above comment?
>
I have pushed a polished "git.pot" to the maint branch of git-l10n/git-po.
It
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 su
2014-04-17 13:37 GMT+08:00 Jiang Xin :
> 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 --git a/po/git.pot b/po
Since we do not translate diffstat any more, remove the obsolete comments.
Signed-off-by: Jiang Xin
---
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 print_stat_summary(FILE *f
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
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
Signed-off-by: Jiang Xin
---
date.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
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: Remov
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
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
2014-04-17 6:51 GMT+08:00 Brian Gesiak :
> 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 " years" */
>
Comments for translators will be ex
On Wed, Apr 16, 2014 at 08:44:41PM -0400, Jonas Fonseca wrote:
> On Sun, Apr 13, 2014 at 5:54 PM, Kumar Appaiah
> 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 sepa
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
Hi Kumar,
On Sun, Apr 13, 2014 at 5:54 PM, Kumar Appaiah
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 the pager backend instead
On Sun, Apr 13, 2014 at 5:54 PM, Kumar Appaiah
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
> functions directly.
See m
On Apr 16, 2014, at 11:11, Junio C Hamano wrote:
Junio C Hamano writes:
"Kyle J. McKay" 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 sur
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).
>
> 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 th
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 .gitignor
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 " years" */
This is a very useful note for translators (in fact, I think
the zh_CN translation for
On Wed, Apr 16, 2014 at 3:02 PM, Junio C Hamano wrote:
> "Luis R. Rodriguez" writes:
>
>> From: "Luis R. Rodriguez"
>>
>> 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,
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 parag
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
"Luis R. Rodriguez" writes:
> From: "Luis R. Rodriguez"
>
> 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 commit is contained in v3.4,
发自我的 iPad
On 04/16/2014 09:31 PM, Junio C Hamano wrote:
> Ronnie Sahlberg 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 t
Ronnie Sahlberg 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 "I th
On Wed, Apr 16, 2014 at 12:31 PM, Junio C Hamano wrote:
> Ronnie Sahlberg 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 du
From: "Luis R. Rodriguez"
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
introduced c5905
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 g
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.
>
Ronnie Sahlberg 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 could continue u
Stepan Kasal writes:
> From: RomanBelinsky
> 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.
Interesting. What other stra
Junio C Hamano 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 you
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
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 re
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.
While
Junio C Hamano 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 info at http
Junio C Hamano 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
original "format-
Junio C Hamano 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 an
Junio C Hamano writes:
> "Kyle J. McKay" 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 better way to phrase
> i
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 htt
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
Jeff King 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 p
Christian Couder writes:
> If the input comes from stdin, then I agree that the command should be
> a filter, so its output should be on stdout. But if the input comes
> from files given as arguments, then I would say that the command
> should behave as an editor and by default it should edit its
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, em
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, em
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, em
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, em
Junio C Hamano writes:
> Erik Faye-Lund writes:
>
>> So let's manually check for these in that case, and fall back to
>> the File::Spec-helper on other platforms (e.g Win32 with native
>> Perl)
>> ...
>> +sub file_name_is_absolute {
>> +my ($path) = @_;
>> +
>> +# msys does not grok DOS
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, em
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, em
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, em
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, em
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, em
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, em
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, em
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, em
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, em
On Wed, Apr 16, 2014 at 02:54:48AM +0200, Johan Herland wrote:
> This is a work-in-progress to flesh out (and promote discussion about)
> the expected behaviors for all possible scenarios in which
> 'git submodule update' might be run.
This is lovely :).
> +# - current state of submodule:
> +#
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, em
On Tue, Apr 15, 2014 at 1:32 PM, Michael Haggerty wrote:
> On 04/15/2014 06:33 PM, Ronnie Sahlberg wrote:
>> On Mon, Apr 14, 2014 at 11:36 PM, Michael Haggerty
>> wrote:
>>> [...]
>>> I wonder, however, whether your approach of changing callers from
>>>
>>> lock = lock_ref_sha1_basic() (or v
Erik Faye-Lund writes:
> So let's manually check for these in that case, and fall back to
> the File::Spec-helper on other platforms (e.g Win32 with native
> Perl)
> ...
> +sub file_name_is_absolute {
> + my ($path) = @_;
> +
> + # msys does not grok DOS drive-prefixes
> + if ($^O eq
Brian Gesiak writes:
> Personally, I've been using the "-" shorthand with "git checkout"
> for a year or so, but only learned about "@{-1}" a few months ago.
> I think those who use "@{-1}" are familiar enough with the concept
> that they don't need to have the reference translated to a
> symboli
Am 11.04.2014 22:20, schrieb Frank Ammeter:
#!/bin/bash
# creating a git repo "repo"
rm -rf repo
mkdir repo
cd repo
git init
# committing gitattributes with text attribute set for all files
echo "* text" > .gitattributes
git add .gitattributes
git commit -m "added .gitattributes"
# add a file wit
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 place, but I do not have anythin
Frank Ammeter writes:
> Am 15.04.2014 um 23:23 schrieb Junio C Hamano :
>
>> Brandon McCaig 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 mor
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
"Kyle J. McKay" 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 func
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)
> {
>
On Wed, Apr 16, 2014 at 04:15:19PM +0200, Stepan Kasal wrote:
> From: Jean-Jacques Lafay
> 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.
>
>
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 sign
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: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 &&
From: RomanBelinsky
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
---
perl/Git/SVN.pm | 2 +-
1 file ch
From: Jean-Jacques Lafay
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 Linux, where the stack
is mor
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 die_bad
On Mon, Apr 14, 2014 at 11:41 PM, Junio C Hamano wrote:
> Christian Couder 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 this directory. It would be like
>
Am 15.04.2014 um 23:23 schrieb Junio C Hamano :
> Brandon McCaig 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 "for sharing". If you made
On 16/04/14 00:18, Duy Nguyen wrote:
> On Tue, Apr 15, 2014 at 11:45 PM, Junio C Hamano wrote:
>> Ramsay Jones 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: work around thre
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 hand-upd
On Wed, Apr 16, 2014 at 11:33 AM, Elia Pinto wrote:
> Signed-off-by: Elia Pinto
> ---
> 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
> --- a/xdiff/xprepare.c
> +++ b/xdiff/xpr
On Wed, Apr 16, 2014 at 11:33 AM, Elia Pinto wrote:
> Signed-off-by: Elia Pinto
> ---
> 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
> b
On Wed, Apr 16, 2014 at 11:33 AM, Elia Pinto wrote:
> Signed-off-by: Elia Pinto
> ---
> 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/credentia
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
Signed-off-by: Elia Pinto
---
compat/regex/regexec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/compat/regex/regexec.c b/compat/regex/regexec.c
index eb5e1d4..f86dbeb 100644
--- a/compat/regex/regexec.c
+++ b/compat/regex/regexec.c
@@ -1254,12 +1254,12 @
Signed-off-by: Elia Pinto
---
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
--- a/xdiff/xprepare.c
+++ b/xdiff/xprepare.c
@@ -161,8 +161,7 @@ static int xdl_prepare_ctx(unsigned int pa
Signed-off-by: Elia Pinto
---
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
+++ b/compat/regex/regex_interna
Signed-off-by: Elia Pinto
---
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
b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
index
Signed-off-by: Elia Pinto
---
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
+++ b/compat/regex/regcomp.c
@@ -368,7 +368,6 @@
Signed-off-by: Elia Pinto
---
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 a1d38f0..edff71c 100644
-
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 revisi
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 xyl
From: Erik Faye-Lund
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, where this helper doesn'
96 matches
Mail list logo
