On Mon, Oct 27, 2014 at 6:32 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
If that is the only casualty, I think it is probably a net-win. We may
want better tooling around viewing the merge later, but that can wait
until somebody steps up with a real use case
Hin-Tak Leung ht...@users.sourceforge.net wrote:
To compare the old clone with the new, I did:
git branch -r | sort | xargs -n 1 git log --decorate=full -n 1
It turned out other than the empty vs 3 word commit messages
about two years ago on trunk (which are inherited in all the newer
Hin-Tak Leung ht...@users.sourceforge.net wrote:
Eric Wong normalper...@yhbt.net wrote:
Which SVN version are you using? I'm cloning (currently on r373xx)
https://svn.r-project.org/R using --stdlayout and
unable to see memory growth of the git-svn Perl process beyond 40M
(on a 32-bit
On Mon, Oct 27, 2014 at 11:45:14AM -0700, Junio C Hamano wrote:
David Aguilar dav...@gmail.com writes:
+write_script .git/fail-right-file \EOF
+echo $2
+exit 1
+EOF
This should be inside the next one, no?
+test_expect_success PERL 'difftool stops on error with --trust-exit-code'
Zoltan Klinger zoltan.klin...@gmail.com writes:
I like René's approach, too. It's more flexible, supports the old
behaviour and it scratches my itch as well.
OK, then let's go with that one.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Robert de Bath rob...@tvisiontech.co.uk writes:
... text unnecessarily opaque ...
Yes, that's quite likely.
However, I think you should continue to have a similar form to the
previous 'pack.window' and
'pack.depth' descriptions... perhaps:
The maximum size of memory that is consumed
On 2014-10-27 13.10, Nguyễn Thái Ngọc Duy wrote:
[]
Nice serious, I can imagine to test benchmark it (so I assume there is a
branch
on github or so ?)
Another thing:
Can we switch the feature off?
It could be nice to benchmark with and without the cache on the command line,
and besides that
On 2014-10-27 13.10, Nguyễn Thái Ngọc Duy wrote:
[]
+static void xmkdir(const char *path)
+{
+ if (mkdir(path, 0700))
+ die_errno(_(failed to create directory %s), path);
+}
Does it makes sense to ignore EINTR and do a retry ?
Another question is if the function could be
On 2014-10-27 13.10, Nguyễn Thái Ngọc Duy wrote:
dir.c | 150
--
dir.h | 60 +++
2 files changed, 189 insertions(+), 21 deletions(-)
[]
+struct untracked_cache_dir {
+ struct
Am 28.10.2014 um 00:32 schrieb Zoltan Klinger:
I like René's approach, too. It's more flexible, supports the old
behaviour and it scratches my itch as well.
Don't mind if you dropped my patch and used René's instead.
Good. :) And here's the t/ part of your patch, slightly changed to
exercise
Junio C Hamano gits...@pobox.com writes:
Ronnie Sahlberg sahlb...@google.com writes:
On Thu, Oct 23, 2014 at 10:42 AM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
Subject: Re: [PATCH 01/15] refs.c make ref_transaction_create a
wrapper to
On Thu, Oct 23, 2014 at 11:32 AM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
commit 020ed65a12838bdead64bc3c5de249d3c8f5cfd8 upstream.
When performing a reflog transaction update, only write to the reflog iff
msg is non-NULL. This can then be combined
Ronnie Sahlberg sahlb...@google.com writes:
commit 0295e9cebc41020ee84da275549b164a8770ffba upstream.
Change refs.c to use a single transaction to copy/rename both the refs and
its reflog. Since we are no longer using rename() to move the reflog file
we no longer need to disallow rename_ref
On Thu, Oct 23, 2014 at 11:54 AM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
@@ -3531,7 +3537,7 @@ struct ref_update {
enum transaction_update_type update_type;
unsigned char new_sha1[20];
unsigned char old_sha1[20];
- int
Junio C Hamano gits...@pobox.com writes:
Ronnie Sahlberg sahlb...@google.com writes:
commit 0295e9cebc41020ee84da275549b164a8770ffba upstream.
Change refs.c to use a single transaction to copy/rename both the refs and
its reflog. Since we are no longer using rename() to move the reflog file
If the asynchronous start of copy_to_sideband() fails, then any
env_array entries added to struct child_process proc by
prepare_push_cert_sha1() are leaked. Call the latter function only
after start_async() succeeded so that the allocated entries are
cleaned up automatically by start_command() or
Call child_process_init() instead of zeroing the memory of variables of
type struct child_process by hand before use because the former is both
clearer and shorter.
Signed-off-by: Rene Scharfe l@web.de
---
bundle.c | 2 +-
column.c | 2 +-
trailer.c | 2 +-
On Tue, Oct 28, 2014 at 12:56 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Ronnie Sahlberg sahlb...@google.com writes:
commit 0295e9cebc41020ee84da275549b164a8770ffba upstream.
Change refs.c to use a single transaction to copy/rename both the refs and
Ronnie Sahlberg sahlb...@google.com writes:
I timed a git branch -m for a branch with ~2400 log entries and it
takes neglible time :
real 0m0.008s
user 0m0.000s
sys 0m0.007s
I really hate this line of reasoning. Small things tend to add up.
More importantly, when you know that the
Two identical loops in suggest_conflicts() in merge, and
do_recursive_merge() in sequencer, can use a single helper function
extracted from the latter that prepares the Conflicts: hint that
is meant to remind the user the paths for which merge conflicts had
to be resolved to write a better commit
Extract a helper function from prepare_to_commit() to determine
where to place a new Signed-off-by: line, which is essentially the
true end of the log message, ignoring the trailing Conflicts:
line and everything below it.
The detection _should_ make sure the Conflicts: line it finds is
truly the
Just like other hints such as Changes to be committed we show in
the editor to remind the committer what paths were involved in the
resulting commit to help improving their log message, this section
is merely a reminder.
Traditionally, it was not made into comments primarily because it
has to be
So here is a reroll to hopefully bring this topic closer to
perfection.
The first two patches haven't changed, except that they are now part
of a numbered series.
The third patch is a refactoring that helps clarify what happens in
the last step, which is new.
The endgame is similar to what was
Since the very beginning when we added the renormalizing parameter
to this function with 7610fa57 (merge-recursive --renormalize,
2010-08-05), nobody seems to have ever referenced it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/merge.c | 4 ++--
1 file changed, 2 insertions(+), 2
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: René Scharfe
Sent: Tuesday, October 28, 2014 16:59
To: Git Mailing List
Cc: Junio C Hamano
Subject: [PATCH] use child_process_init() to initialize struct child_process
variables
Call child_process_init()
Signed-off-by: Rene Scharfe l@web.de
---
Documentation/technical/api-run-command.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/technical/api-run-command.txt
b/Documentation/technical/api-run-command.txt
index 3f12fcd..a9fdb45 100644
---
On Mon, Oct 27, 2014 at 10:42:21AM -0700, Junio C Hamano wrote:
I believe I can work around the error with an export _C89_CCMODE=1,
but I thought I'd send the patch since this is the only occurrence of
the problem, and the argument order is inconsistent with other linker
commands in the
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
On Mon, Oct 27, 2014 at 01:59:18PM -0700, Junio C Hamano wrote:
I do not think it is too hard to teach strbuf_commented_addf() about
the leading HT, but that would be a separate topic; if squashing the
SP-HT to HT is worth doing for this codepath, doing it at that helper
would benefit all
On Mon, Oct 27, 2014 at 02:14:42PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
For the most part, combined-diff (and --cc) will show the interesting
cases anyway. But if you take a whole file from one side of the merge,
then there is nothing interesting for diff to show. Do people
On Mon, Oct 27, 2014 at 8:10 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
diff --git a/builtin/update-index.c b/builtin/update-index.c
index e57e2d7..471c0b4 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@
Hi, I patched my system git with the recent git-svn improvements, and just use
it for general use; so theses are the patches, against 2.1.0.
0001-git-svn-only-look-at-the-new-parts-of-svn-mergeinfo.patch
0002-git-svn-only-look-at-the-root-path-for-svn-mergeinfo.patch
On Tue, 28/10/14, Eric Wong normalper...@yhbt.net wrote:
So both merges
are correct, but we lose one, and gain one?
I'll try to check more closely tomorrow.
Can you point out
the exact revisions in the
R repo? Thanks.
The missing merge on branch R-2-14-branch is:
commit
33 matches
Mail list logo
