The option has been the default for a while, and doesn't otherwise
appear in the page.
---
Documentation/git-pack-refs.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-pack-refs.txt b/Documentation/git-pack-refs.txt
index f131677..154081f 100644
---
---
Documentation/git-prune.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt
index 80d01b0..bf82410 100644
--- a/Documentation/git-prune.txt
+++ b/Documentation/git-prune.txt
@@ -59,7 +59,7 @@ borrows from your
Thomas Sabo Charms Armband http://www.schmuckskaufen.com/ ist in der
Regel für den großen mythischen neben eleganten Schmuck Thema Materialien
Inhalt zusammen mit Blogs alle den Weg durch jeden, der betroffenen ist.
Dies ist wirklich eine ausgezeichnete zuverlässige und folgenden wirklich
NIKE FREE three.0 V2 HERREN Im Jahr 2005 wurde Messi angewiesen, seinen
Vertrag mit Nike zu verbessern, aber er berichtet Nr. Möglicherweise erhält
Messi einige Vorteile oder vielleicht Versuchung von Adidas, und nike air
max 1 Damen http://www.airmaxschuhekaufen.de/ dann hat er zusätzlich
Hi,
I'm using archlinux with git version 1.8.3.3, svn version 1.8.0
(r1490375) and perl v5.18.0 (built for x86_64-linux-thread-multi)
Every git svn call that involves a fetch produces a segmentation fault
on exit (but the operation succeeds).
*** Error in `/usr/bin/perl': double free or
Eric Sunshine sunsh...@sunshineco.com writes:
This series fixes a regression in blame -L X,-N, adds blame -L tests,
and makes minor documentation adjustments. The tests, in particular,
were motivated by the desire to revisit and continue working on [1]
which extends git-blame to accept
Eric Sunshine sunsh...@sunshineco.com writes:
Standard practice in Git documentation is for each variation of an
option (such as: -p / --porcelain) to be placed on its own line in the
OPTIONS table. The -L option does not follow suit. It cuddles
-L start,end and -L :regex, separated by a
Ralf Thielow ralf.thie...@gmail.com writes:
This is a resend of v3 because at least one patch was
damaged last time for whatever reason.
Ralf Thielow (3):
l10n: de.po: switch from pure German to German+English (part 1)
l10n: de.po: switch from pure German to German+English (part 2)
Jonathan Lambrechts jonathanlambrec...@gmail.com writes:
Every git svn call that involves a fetch produces a segmentation fault
on exit (but the operation succeeds).
*** Error in `/usr/bin/perl': double free or corruption (!prev):
0x02ce1ac0 ***
=== Backtrace: =
There are only four (with some generous rounding) instances in the
current source code where we speak of subproject instead of
submodule. They are as follows:
* one error message in git-apply and two in entry.c
* the patch format for submodule changes
The latter was introduced in 0478675
The existing description reads as if it somehow applies a filter.
Change it to explain that it is merely about the ordering.
Message-proposed-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
builtin/show-branch.c | 4 ++--
1 file changed, 2 insertions(+), 2
I presume that I should apply this change to my porting of
git_mkstemps_mode() to tig. If there are no complaints about this for a
couple of days I will do so.
REF: $gmane/229961
On 07/17/2013 03:29 PM, Junio C Hamano wrote:
Thomas Rasttr...@inf.ethz.ch writes:
Thomas Rasttr...@inf.ethz.ch
After upgrade to subversion 1.8.0 on some repositories
git svn clone shows two warnings:
error closing pipe: Bad file descriptor at
/home/users/kornet/giti/libexec/git-core/git-svn line 0.
at exit. They appear because process git cat-file --batch exits before
command_close_bidi_pipe is called by
Somehow this patch breaks the main view to not open the correct commit
in diff view when enter is pressed. Back to the debugger...
On 07/18/2013 12:51 AM, Drew Northup wrote:
Since c7d67ab running tig with no options has failed with the
error tig: No revisions match the given arguments. This
On 17.07.2013 15:33, John Keeping wrote:
On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote:
I'm looking for a specification or guidelines on how a Git client should
integrate with bug tracking systems. For SVN, one can use
bugtraq-properties [1] to specify e.g. the issue tracker
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..4a6a863 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -264,6 +274,30 @@ case $merge_head in
die $(gettext Cannot rebase onto multiple branches)
fi
I am posting here first time, so please excuse me if this is not right place to
send something like this.
Please check -
http://stackoverflow.com/questions/6091306/can-i-make-git-print-x-y-z-style-tag-names-in-a-sensible-order
And also - https://github.com/gitlabhq/gitlabhq/issues/4565
IMHO
On Thu, Jul 18, 2013 at 10:27 PM, Rahul Bansal rahul.ban...@rtcamp.com wrote:
I am posting here first time, so please excuse me if this is not right place
to send something like this.
Please check -
On Thu, Jul 18, 2013 at 10:51 PM, Duy Nguyen pclo...@gmail.com wrote:
Try
git for-each-ref --sort=committerdate --format='%(refname:short)' refs/tags
And I wondered why it did not seem right. Use this one instead
git for-each-ref --sort=taggerdate --format='%(refname:short)' refs/tags
make
Hi Day,
I am aware of that command as well.
I think `git tag` current default order is string-based sorting. I
felt version-number based sorting and/or create-date based sorting
will be more appropriate.
--
Rahul Bansal | Founder CEO | rtCamp Solutions Pvt. Ltd.
Skype: rahul286 | Twitter:
Thanks again Duy. :-)
Sorry for misspelling your name in earlier email.
--
Rahul Bansal | Founder CEO | rtCamp Solutions Pvt. Ltd.
Skype: rahul286 | Twitter: @rahul286 | Web: http://rtcamp.com/
On Thu, Jul 18, 2013 at 9:26 PM, Duy Nguyen pclo...@gmail.com wrote:
On Thu, Jul 18, 2013 at 10:51
On Thu, Jul 18, 2013 at 10:57 PM, Rahul Bansal rahul.ban...@rtcamp.com wrote:
Hi Day,
I am aware of that command as well.
I think `git tag` current default order is string-based sorting. I
felt version-number based sorting and/or create-date based sorting
will be more appropriate.
ok you
Torsten Bögershausen tbo...@web.de writes:
I wasn't sure where to apply the patch, so I manually copy/paste it
on top of pu:
commit 6b1ca0f4d443ee8716857b871b0513ae85c9f112
Merge: bce90ab f351fcf
Thanks, t9001 passes on Mac OS X 10.6.
To be sure I didn't messed it up, please see the diff
The option has been the default for a while, and doesn't otherwise
appear in the page.
Signed-off-by: Jonathon Mah m...@jonathonmah.com
---
Forgot sign-off in v1. Also, I was unsure whether to rewrap the lines (and if
so, to how many columns); erred on the side of minimal changes.
Signed-off-by: Jonathon Mah m...@jonathonmah.com
---
Documentation/git-prune.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt
index 80d01b0..bf82410 100644
--- a/Documentation/git-prune.txt
+++
git-gui/lib/option.tcl |2 +-
git-gui/po/git-gui.pot | 1057
git-gui/po/ja.po | 1147 ++--
3 files changed, 1200 insertions(+), 1006 deletions(-)
--
To unsubscribe from this list: send the line
Signed-off-by: Yamada Saburo devil.tamac...@gmail.com
---
git-gui/lib/option.tcl | 2 +-
git-gui/po/git-gui.pot | 14 +-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/git-gui/lib/option.tcl b/git-gui/lib/option.tcl
index 0cf1da1..7af858c 100644
---
Signed-off-by: Yamada Saburo devil.tamac...@gmail.com
---
git-gui/po/ja.po | 153 ++-
1 file changed, 73 insertions(+), 80 deletions(-)
diff --git a/git-gui/po/ja.po b/git-gui/po/ja.po
index 0bbe504..05215b9 100644
--- a/git-gui/po/ja.po
+++
Signed-off-by: Yamada Saburo devil.tamac...@gmail.com
---
git-gui/po/git-gui.pot | 1045 ++--
1 file changed, 567 insertions(+), 478 deletions(-)
diff --git a/git-gui/po/git-gui.pot b/git-gui/po/git-gui.pot
index 0c94f9c..6ebfc94 100644
---
Junio C Hamano wrote:
Ramkumar, as you will still be the primary author of the resulting
commit, I tentatively added a line for your sign-off even though you
haven't signed off _this_ version yet, so that I would not forget.
If this version looks good, please tell us you would.
Yeah, it seems
John Keeping j...@keeping.me.uk writes:
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..4a6a863 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -264,6 +274,30 @@ case $merge_head in
die $(gettext Cannot rebase
Rahul Bansal rahul.ban...@rtcamp.com writes:
IMHO git tag is expected to show tag-list ordered by versions.
A git tag can be anything, not related to versions at all.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
Mark Levedahl mleved...@gmail.com writes:
Cygwin 1.7 is very different than the earlier, no longer supported,
and no longer available Cygwin variants in many ways, but stat is one
of them. Cygwin 1.7 uses Windows ACLs to represent file permissions,
and therefore gets the file permissions
The Show origin of this line context menu command on a line in a patch
in gitk is by far my most frequently used way of navigating back in
history. It's so much faster than git gui blame.
Now, I wish it were available right from my text editor, showing me the
origin of the line under the cursor
Thomas Rast t...@thomasrast.ch writes:
Eric Sunshine sunsh...@sunshineco.com writes:
Standard practice in Git documentation is for each variation of an
option (such as: -p / --porcelain) to be placed on its own line in the
OPTIONS table. The -L option does not follow suit. It cuddles
-L
Drew Northup n1xim.em...@gmail.com writes:
I presume that I should apply this change to my porting of
git_mkstemps_mode() to tig. If there are no complaints about this for
a couple of days I will do so.
Hmph, Thomas and I were actually asking you to give us
Signed-off-by: Drew
Junio C Hamano gits...@pobox.com writes:
Drew Northup n1xim.em...@gmail.com writes:
I presume that I should apply this change to my porting of
git_mkstemps_mode() to tig. If there are no complaints about this for
a couple of days I will do so.
Hmph, Thomas and I were actually asking you to
Andreas Schwab sch...@linux-m68k.org writes:
John Keeping j...@keeping.me.uk writes:
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..4a6a863 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -264,6 +274,30 @@ case
Jonathon Mah m...@jonathonmah.com writes:
The option has been the default for a while, and doesn't otherwise
appear in the page.
Signed-off-by: Jonathon Mah m...@jonathonmah.com
---
Forgot sign-off in v1. Also, I was unsure whether to rewrap the
lines (and if so, to how many columns);
悪魔野玉茶無 devil.tamac...@gmail.com writes:
I suspect that is not a name (and I somehow have suspicion that the
S-o-b is not real, either), but if you send patches as somebody that
does not match your sign-off, please add
From: Yamada Saburo devil.tamac...@gmail.com
followed by a blank
Kyle J. McKay mackyle at gmail.com writes:
+sub temp_is_locked {
+ my ($self, $name) = _maybe_self( at _);
+ my $temp_fd = \$TEMP_FILEMAP{$name};
+
+ defined $$temp_fd $$temp_fd-opened
$TEMP_FILES{$$temp_fd}{locked};
+}
+
=item temp_release ( NAME )
=item temp_release
悪魔野玉茶無 devil.tamac...@gmail.com writes:
@@ -124,26 +127,23 @@ msgstr コミット予定済、ファイル無し
#: git-gui.sh:2087
msgid File type changed, not staged
-msgstr ファイル型変更、コミット未予定
+msgstr ファイルタイプ変更、コミット未予定
There are good changes like this in this patch, and ...
#: git-gui.sh:3095
#, tcl-format
The options section of the git-rev-parse manual page has grown
organically so that there now does not seem to be much logic behind the
ordering of the options. It also does not make it clear that certain
options must appear first on the command line.
Address this by reorganising the options into
On Jul 18, 2013, at 11:34, David Rothenberger wrote:
Kyle J. McKay mackyle at gmail.com writes:
+sub temp_is_locked {
+ my ($self, $name) = _maybe_self( at _);
+ my $temp_fd = \$TEMP_FILEMAP{$name};
+
+ defined $$temp_fd $$temp_fd-opened $TEMP_FILES{$$temp_fd}
{locked};
+}
+
The temp_is_locked function can be used to determine whether
or not a given name previously passed to temp_acquire is
currently locked.
Signed-off-by: Kyle J. McKay mack...@gmail.com
---
perl/Git.pm | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git
When attempting to git-svn fetch files from an svn https?: url using
the serf library (the only choice starting with svn 1.8) the following
errors can occur:
Temp file with moniker 'svn_delta' already in use at Git.pm line 1250
Temp file with moniker 'git_blob' already in use at Git.pm line 1250
(cc-ing Eric Wong, who maintains git-svn and knows both it and
the libsvn perl bindings much better than I do)
Kyle J. McKay wrote:
David Rothenberger daver...@acm.org has determined the cause to
be that ra_serf does not drive the delta editor in a depth-first
manner [...]. Instead, the calls
Because it is so easy to let Git handle automatically a trivial
merge with git pull, a person who is new to Git may not realize
that the project s/he is interacting with may prefer a rebase
workflow.
Add a safety valve to fail git pull that does not explicitly
specify what branch from which
Kyle J. McKay wrote:
That change was made as a result of this feedback:
On Jul 6, 2013, at 17:11, Jonathan Nieder wrote:
Kyle McKay wrote:
The temp_is_locked function can be used to determine whether
or not a given name previously passed to temp_acquire is
currently locked.
[...]
+=item
Thomas Rast t...@thomasrast.ch writes:
Ralf Thielow ralf.thie...@gmail.com writes:
This is a resend of v3 because at least one patch was
damaged last time for whatever reason.
Ralf Thielow (3):
l10n: de.po: switch from pure German to German+English (part 1)
l10n: de.po: switch from
Jonathan Nieder wrote:
Ramsay Jones wrote:
One of the three gcc compilers that I use does not understand the
sentinel function attribute. (so, it spews 108 warning messages)
Do you know what version of gcc introduced the sentinel attribute?
Would it make sense for the ifdef in
The sentinel function attribute is not understood by versions of
the gcc compiler prior to v4.0. At present, for earlier versions
of gcc, the build issues 108 warnings related to the unknown
attribute. In order to suppress the warnings, we conditionally
define the GIT_SENTINEL macro to provide
Jonathan Nieder wrote:
Mark Levedahl wrote:
Subtests 6, 7, and 9 rely test that merge-recursive correctly
ignores whitespace when so directed. Change the particular whitespace
sequences to be ones that are not known line endings so the whitespace
is not changed when being extracted by line
Jeff King wrote:
On Tue, Jul 16, 2013 at 07:57:20AM +0200, Johannes Sixt wrote:
Am 7/15/2013 19:31, schrieb Ramsay Jones:
Sparse issues three Using plain integer as NULL pointer warnings.
Each warning relates to the use of an '{0}' initialiser expression
in the declaration of an 'struct
Mark Levedahl wrote:
On 07/15/2013 10:06 PM, Torsten Bögershausen wrote:
On 2013-07-15 21.49, Junio C Hamano wrote:
Mark Levedahl mleved...@gmail.com writes:
In order to limit the adverse effects caused by this implementation,
we provide a new fast stat interface, which allows us to use this
Mark Levedahl wrote:
Subtests 6,7, and 9 of t3032 fail on Cygwin, and I presume will fail on
msysgit for similar reasons. Looking at test 6, the expected result is a
line ending with \r\n in text.txt. This line is extracted with grep
(grep 'justice and holiness' text.txt actual), with
On Thu, Jul 18, 2013 at 09:02:12PM +0100, Ramsay Jones wrote:
The sentinel function attribute is not understood by versions of
the gcc compiler prior to v4.0. At present, for earlier versions
of gcc, the build issues 108 warnings related to the unknown
attribute. In order to suppress the
I've been looking into writing a proper test for this patch. My first
attempt tests the symptom that was seen initially, that git commit
fails if fd 0 is closed.
One problem is how to arrange for fd 0 to be closed. I could use the
bash redirection -, but I think you want to be more portable
-- Forwarded message --
From: Yamada Saburo devil.tamac...@gmail.com
Date: 2013/7/19
Subject: Re: [PATCH 4/4] Update Japanese translation (Git-gui)
To: Junio C Hamano gits...@pobox.com
Hi Hamano,
dubious ones like this (there is no change to the string, just the
way msgstr is
-- Forwarded message --
From: Yamada Saburo devil.tamac...@gmail.com
Date: 2013/7/19
Subject: Re: [PATCH 2/4] Update git-gui/po/ja.po (Git-gui Japanese)
To: Junio C Hamano gits...@pobox.com
Hi Hamano,
I suspect that is not a name
Real name.
+Language: \n
What is this
On Thu, Jul 18, 2013 at 1:32 PM, Dale R. Worley wor...@alum.mit.edu wrote:
I've been looking into writing a proper test for this patch. My first
attempt tests the symptom that was seen initially, that git commit
fails if fd 0 is closed.
One problem is how to arrange for fd 0 to be closed. I
Ramsay Jones wrote:
This was built on the next branch
All the uses of the sentinel attribute seem to come from
eccb6149 (use sentinel function attribute for variadic
lists, 2013-07-09), so this should be okay to go on top of the
jk/gcc-function-attributes branch.
--- a/git-compat-util.h
+++
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
Jonathan Nieder wrote:
Ramsay Jones wrote:
One of the three gcc compilers that I use does not understand the
sentinel function attribute. (so, it spews 108 warning messages)
Do you know what version of gcc introduced the sentinel attribute?
The variable len is set to
len = strchrnul(line, '\n') - line;
unconditionally 9 lines later, hence we can remove the call to strlen.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/apply.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/apply.c
That pointer will be assigned to new memory via
request = xmalloc(sizeof(*request));
20 lines later unconditionally anyway, so it's safe to not assign it to an
arbitrary variable.
As this patch is a micro-optimization (for readability?) it would be nice
to have as little work with this patch, so
The variable name ret sounds like the variable to be returned, but
since e6c111b4 we return error. Hence the variable name is miss leading.
As this variable is used only to extract the bits from the callback of
a tree object, I named it cb_bits for callback bits.
Also the assignment to 0 was
Hi all,
I recently started using git-subtree and ran into a small issue when
pushing to the subtree repository: newlines in the commit message seem
not to be preserved.
I was using git-subtree from [1], but can also reproduce this with the
version from the main git source-tree commit
On 07/18/2013 03:19 PM, Ramsay Jones wrote:
Jonathan Nieder wrote:
Mark Levedahl wrote:
Subtests 6, 7, and 9 rely test that merge-recursive correctly
ignores whitespace when so directed. Change the particular whitespace
sequences to be ones that are not known line endings so the whitespace
is
Define a common macro for grep needing -U to allow tests to not need
to inquire of specific platforms needing this option. Change
t3032 and t5560 to use this rather than testing explicitly for mingw.
This fixes these two tests on Cygwin.
Signed-off-by: Mark Levedahl mleved...@gmail.com
---
This
On 2013-07-18 19.50, Ramsay Jones wrote:
Mark Levedahl wrote:
On 07/15/2013 10:06 PM, Torsten Bögershausen wrote:
On 2013-07-15 21.49, Junio C Hamano wrote:
Mark Levedahl mleved...@gmail.com writes:
In order to limit the adverse effects caused by this implementation,
we provide a new fast
Never mind, this is already fixed in a5b8e28e4eb. Sorry for the noise.
Jaap
On Thu, Jul 18, 2013 at 11:22:33PM +0200, Jaap Eldering wrote:
Hi all,
I recently started using git-subtree and ran into a small issue when
pushing to the subtree repository: newlines in the commit message seem
This is an update to finish the jc/name-rev-exact-ref topic, which
fixed the command to convert an object name that points at a tag to
a refname of the tag (earlier, it did not show anything). The
codepath to handle its command line arguments, however, fed the
commit that the tag points at to the
git name-rev --stdin has been fixed to convert an object name that
points at a tag to a refname of the tag. The codepath to handle its
command line arguments, however, fed the commit that the tag points
at to the underlying naming machinery.
With this fix, you will get this:
$ git name-rev
git describe takes a commit and gives it a name based on tags in
its neighbourhood. The command does take a commit-ish but when
given a tag that points at a commit, it should dereference the tag
before computing the name for the commit.
As the whole processing is internally delegated to
On 07/18/2013 05:49 PM, Torsten Bögershausen wrote:
On 2013-07-18 19.50, Ramsay Jones wrote:
Hmm, that looks good. :-D
Torsten reported a performance boost using the win32 stat() implementation
on a linux git repo (2s - 1s, if I recall correctly) on cygwin 1.7.
Do you have a larger repo
From: Junio C Hamano gits...@pobox.com
That's just a plain-vanilla part of POSIX shell behaviour, no?
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05
Close standard input is so weird I never thought it was Posix. In
that case, we can eliminate the C
After this commit:
4c7f1819b3c142ace98269a556bc929c80e7c9fd make color.ui default to 'auto'
the patch file for 'git add -e' receives all the color codes. This is because
diffopt.use_color defaults to -1, which causes want_color to now return 'auto'.
By explicitly setting use_color to 0, we
This test confirms that a file can be ignored during git p4 sync if if is
excluded in P4 client specification.
Signed-off-by: Vitor Antunes vitor@gmail.com
---
t/t9801-git-p4-branch.sh | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git
wor...@alum.mit.edu (Dale R. Worley) writes:
From: Junio C Hamano gits...@pobox.com
That's just a plain-vanilla part of POSIX shell behaviour, no?
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05
Close standard input is so weird I never thought it was
From: Junio C Hamano gits...@pobox.com
+test_expect_success 'git_mkstemps_mode does not fail if fd 0 is not open' '
+ git init
+ echo Test. test-file
+ git add test-file
+ git commit -m Message. -
+'
+
Yup. I wonder how it would fail without the fix, though ;-)
Eh,
On Jul 18, 2013, at 12:29, Jonathan Nieder wrote:
(cc-ing Eric Wong, who maintains git-svn and knows both it and
the libsvn perl bindings much better than I do)
Kyle J. McKay wrote:
David Rothenberger daver...@acm.org has determined the cause to
be that ra_serf does not drive the delta editor
Mark Levedahl mleved...@gmail.com writes:
Unlike the results on the fast Win7 laptop, the above show
statistically significant slow down from the fast_lstat approach. I'm
just not seeing a case for the special case handling, and of course
Junio has already voted with his preference of
Kyle J. McKay mack...@gmail.com writes:
This patch allows git-svn to fetch successfully using the
serf library when given an https?: url to fetch from.
...
Versions v2-v3 of the patch introduced a bug when attempting
to change the _temp_cache function to use the new
temp_is_locked function
Jonathan Nieder jrnie...@gmail.com wrote:
(cc-ing Eric Wong, who maintains git-svn and knows both it and
the libsvn perl bindings much better than I do)
I doubt that's the case anymore. I've hardly looked at SVN in many
years, now.
Anyways, if the patches:
1) do not introduce regressions
2)
NOTE: This patch requires:
4e63dcc Git.pm: add new temp_is_locked function
which is currently in next.
Versions v2-v3 of the allow git-svn fetching to work using serf patch
introduced a bug when attempting to change the Git.pm _temp_cache function
to use the new temp_is_locked function at the
When the temp_is_locked function was introduced, there was
a desire to make _temp_cache use it. Unfortunately due to the
various tests and logic flow involved changing the _temp_cache
function to use the new temp_is_locked function is problematic
as _temp_cache needs a slightly different test
On Jul 18, 2013, at 16:34, Junio C Hamano wrote:
Kyle J. McKay mack...@gmail.com writes:
This patch allows git-svn to fetch successfully using the
serf library when given an https?: url to fetch from.
...
Versions v2-v3 of the patch introduced a bug when attempting
to change the _temp_cache
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Quite a many topics are now in 'master', and 'next' has been
shrinking in a reasonable pace, but there are some biggies remaining
(including
On Thu, Jul 18, 2013 at 3:35 PM, Junio C Hamano gits...@pobox.com wrote:
Add a safety valve to fail git pull that does not explicitly
specify what branch from which repository to integrate your history
with, when it is neither a fast-forward or already up-to-date,
until/unless the user
This was inherited from show-diff -q that was invented to tell
comparison between the index and the working tree to ignore only
removals in 2005.
These days, it is spelled as --diff-filter=d.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* And this is the endgame.
diff-lib.c | 3
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
The sentinel function attribute is not understood by versions of
the gcc compiler prior to v4.0. At present, for earlier versions
of gcc, the build issues 108 warnings related to the unknown
attribute. In order to suppress the warnings, we
Junio C Hamano wrote:
We should remove the support for -q in Git 2.0.
No. I hope you are teasing.
I don't mind seeing support for -q dropped, but I really don't think
it's worth delaying git 2.0 for that. Would s/in Git 2.0/in some
future release/ be ok?
The patch text itself looks
Junio C Hamano wrote:
It seems to apply well on the tip of jk/gcc-function-attributes.
- This macro is not about git at all, so I'll edit the patch to
call it GCC_ATTR_SENTINEL before applying.
Would naming it something like LAST_ARG_MUST_BE_NULL instead make
sense? That way, if some
On Thu, Jul 18, 2013 at 9:30 AM, Drew Northup n1xim.em...@gmail.com wrote:
Somehow this patch breaks the main view to not open the correct commit in
diff view when enter is pressed. Back to the debugger...
Does this (possibly white-space damaged) patch work for you?
diff --git a/tig.c
Greetings from George Daniels
I am George Daniels, a Banker and credit system programmer (HSBC bank).
I saw your email address while browsing through the bank D.T.C Screen in
my office
yesterday so I decided to use this very chance to know you. I believe
we should use every opportunity to know
95 matches
Mail list logo