On Tue, 28/10/14, Eric Wong 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 93af4d4cc3a5e0039944dd4e340d26995b
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
0003-git-svn-reduce-check_cher
On Mon, Oct 27, 2014 at 8:10 AM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> 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
> @@ -48,6 +48,145 @@ static void r
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 peo
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 bene
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
http://git-blame.blogspot.com/p/git-publi
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
> >> comm
Signed-off-by: Rene Scharfe
---
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
--- a/Documentation/technical/ap
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() ins
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
---
builtin/merge.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
d
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 p
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
trul
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
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
Ronnie Sahlberg 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 end result you w
On Tue, Oct 28, 2014 at 12:56 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Ronnie Sahlberg 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
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
---
bundle.c | 2 +-
column.c | 2 +-
trailer.c | 2 +-
transport-helper.c
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
Junio C Hamano writes:
> Ronnie Sahlberg 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 di
On Thu, Oct 23, 2014 at 11:54 AM, Junio C Hamano wrote:
> Ronnie Sahlberg 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 flags; /* REF_NODEREF? */
>> +
Ronnie Sahlberg 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 for refs with a
On Thu, Oct 23, 2014 at 11:32 AM, Junio C Hamano wrote:
> Ronnie Sahlberg 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 with REFLOG_TRUNCATE to pe
Junio C Hamano writes:
> Ronnie Sahlberg writes:
>
>> On Thu, Oct 23, 2014 at 10:42 AM, Junio C Hamano wrote:
>>> Ronnie Sahlberg writes:
>>>
Subject: Re: [PATCH 01/15] refs.c make ref_transaction_create a
wrapper to ref_transaction_update
>>>
>>> Missing colon after "refs.c"
>>> ...
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
exerci
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 untracked_cac
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 coul
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 w
Robert de Bath 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 by each
> thre
Zoltan Klinger 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 majord...@vger.kernel.org
More m
On Mon, Oct 27, 2014 at 11:45:14AM -0700, Junio C Hamano wrote:
> David Aguilar 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
Hin-Tak Leung wrote:
> >Eric Wong 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 system).
> >
> >git-svn hit 45M and to
Hin-Tak Leung 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
> branches), there are two
32 matches
Mail list logo
