Junio C Hamano writes:
> Lucas Oshiro writes:
>
>> Improve code readability by moving tag body reading to a new function called
>> get_tag_body.
>
> Quite honestly, I think the result of this splitting is harder to
> follow than the original.
>
> For example, the value of opt->message_given and
Lucas Oshiro writes:
> struct create_tag_options {
> unsigned int message_given:1;
> unsigned int use_editor:1;
> + unsigned int force_editor:1;
> unsigned int sign;
> - if (!opt->message_given || opt->use_editor) {
> + if (opt->force_editor && !opt->message_given
Lucas Oshiro writes:
> Improve code readability by moving tag body reading to a new function called
> get_tag_body.
Quite honestly, I think the result of this splitting is harder to
follow than the original.
For example, the value of opt->message_given and the validity of
given_msg is very clos
Lucas Oshiro writes:
> +/*
> + * Returns the tag body of the given oid or NULL, in case of error. If size
> is
> + * not NULL it is assigned the body size in bytes (excluding the '\0').
> + */
> +static char *get_tag_body(const struct object_id *oid, size_t *size)
> {
> + unsigned long bu
Bonjour.
Vous souhaitez profiter pleinement de votre vie en sortant de l'impasse que vous
provoquent les banques par le rejet de vos demandes de crédits ?
Vous avez envie de ne pas vous priver et de faire totalement plaisir à
toute votre famille ?
Vous avez un nouvel emploi et vous souhaitez chang
Lucas Oshiro writes:
> This series of patches fixes the flags --edit and --no-edit. Currently,
> --no-edit has no effect.
>
> These patches implement the following behaviour:
>
> - when --edit is provided, the editor will always be opened;
>
> - when --no-edit is provided, the editor will not be
"William Baker via GitGitGadget" writes:
> This is the second iteration of changes to fix the segfault that I
> encountered while testing fsmonitor. This iteration includes the following
> updates for feedback I received on v1:
>
> * Use %u instead of %"PRIuMAX" for unsigned ints in BUG format s
Junio C Hamano wrote:
> For reference, here is the CoC the patch wants to add (there is no
> such topic yet locally, nor a single patch that can be made into
> such a topic, so there isn't exactly something people can Ack on
> yet. So here is a "preview" of what we would see once such a series
Whenever we make a struct base_data, immediately calculate its delta
children. This eliminates confusion as to when the
{ref,ofs}_{first,last} fields are initialized.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 125 +--
1 file changed, 61 insert
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 1a2600d4b3..99f6e2957f 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -614,7 +61
Instead, recompute ancestry if we ever need to reclaim memory.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 99f6e2957f..35f7f9
A subsequent commit will make the quantum of work smaller, necessitating
more locking. This commit allows resolve_delta() to be called outside
the lock.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin/index-
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index a23454da6e..1a2600d4b3 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1210,15 +1210,7 @@ static vo
Quoting myself [1]:
> index-pack does parallelize delta resolution, but
> it cannot split up trees into threads: each delta base root can go into
> its own thread, but when a delta base root is processed, all deltas on
> that root (direct or indirect) is processed in the same thread.
This is a pr
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 267 ---
1 file changed, 127 insertions(+), 140 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 3908cd3115..f6318037ca 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-
This is the second iteration of changes to fix the segfault that I
encountered while testing fsmonitor. This iteration includes the following
updates for feedback I received on v1:
* Use %u instead of %"PRIuMAX" for unsigned ints in BUG format strings
* Updated the new test's comment to be more
From: William Baker
While doing some testing with fsmonitor enabled I found
that git commands would segfault after staging and
unstaging an untracked file. Looking at the crash it
appeared that fsmonitor_ewah_callback was attempting to
adjust bits beyond the bounds of the index cache.
Digging i
On Wed, Oct 09, 2019 at 09:14:59AM +0900, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Junio, would you mind picking it up, please?
>
> I trust you enough that I won't go back to the cited messages to
> double check that these acks are real, but I'd still wait for a few
> days for p
When the %.cocci.patch target was defined in 63f0a758a0 (add coccicheck
make target, 2016-09-15), it included a mechanism to suppress the noisy
output, similar to the $(QUIET_) family of variables.
In the case where one wants to inspect the output hidden by
$(QUIET_), one could define $(V) for ver
Hi,
On Wed, 9 Oct 2019, Harish Karumuthil wrote:
> @Johannes Schindelin: In short, from your previous message I understand point.
>
> 1. shortcut codes like "" will only in Windows platform. It may
> not work in Linux / Mac.
> 2. We need do translate shortcut codes somehow ( using one-to-one map
On Tue, Oct 08, 2019 at 11:27:52AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> Inspired by the thoroughly stale https://github.com/git/git/pull/159,
> this patch fixes a couple of typos, rewraps and clarifies some comments.
>
> Signed-off-by: Johannes Sch
Hi Elijah,
sorry about the blast from the past, but I just stumbled over something
I could not even find any discussion about:
On Thu, 19 Apr 2018, Elijah Newren wrote:
> This populates a set of directory renames for us. The set of directory
> renames is not yet used, but will be in subsequent
On Wed, Oct 09, 2019 at 11:19:47AM +0900, Junio C Hamano wrote:
> > I wonder how we are supposed to use this trailer in the Git project,
> > in particular in combination with Signed-off-by. Should all
> > (co)authors sign off as well? Or will Co-authored-by imply
> > Signed-off-by?
>
> I think
On 10/8/19 5:14 PM, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> In other words, the commit message can be augmented by this:
>>
>> Acked-by: Johannes Schindelin
>> Acked-by: Derrick Stolee
>> Acked-by: Garima Singh
>> Acked-by: Jonathan Tan
>> Acked-by: Thomas Gummerer
>> Acked-
Elijah Newren writes:
> Those Acked-by's are nearly in alphabetical order (at least at first
> glance) until Brian, Derrick, and me.
Sorted in ascii order after the first "<" on the line.
On Tue, Oct 8, 2019 at 5:20 PM Junio C Hamano wrote:
>
> Johannes Schindelin writes:
>
> > In other words, the commit message can be augmented by this:
> >
> > Acked-by: Johannes Schindelin
> > Acked-by: Derrick Stolee
> > Acked-by: Garima Singh
> > Acked-by: Jonathan Tan
> > Acked-by: Thomas
On Fri, Sep 27, 2019 at 06:18:58PM -0400, Jeff King wrote:
> On Thu, Sep 26, 2019 at 11:44:48PM +0200, SZEDER Gábor wrote:
>
> > All that was over a year and a half ago, and these limitations weren't
> > a maintenance burden at all so far, and nobody needed that escape
> > hatch.
> I'm actually s
Jeff King wrote:
> If we just add a new "-z", that's less disruptive_and_ easier to use.
Agreed.
> I suspect it's not entirely sufficient for clean input, though. You're
> not feeding filenames but rather full "object names". I wouldn't be
> surprised if we mis-parse "$rev:$path" when $path has
Hi Junio
On 09/10/2019 01:14, Junio C Hamano wrote:
Johannes Schindelin writes:
In other words, the commit message can be augmented by this:
Acked-by: Johannes Schindelin
Acked-by: Derrick Stolee
Acked-by: Garima Singh
Acked-by: Jonathan Tan
Acked-by: Thomas Gummerer
Acked-by: brian m.
Hi Jonathan,
Thank you for your time. I would be for something like `git fetch
--head` or `git fetch --remote-head` as the name. It also matches `git
fetch --tags` - fetch tags from remote, in addition to whatever else.
Aside from that, there are no further comments from my side. I would
be really
> Anyway, in your first email you asked how you can merge that branch
> into 'master'. The command 'git merge origin/strings' will "merge" it
> without actually creating a merge commit, because 'strings' builds
> entirely on top of 'master'; this is what Git calls a "fast-forward
>
Hi Dscho,
On 08/10/2019 13:46, Johannes Schindelin wrote:
Hi Junio,
On Tue, 8 Oct 2019, Junio C Hamano wrote:
Johannes Schindelin writes:
I didn't quite understand this part, though.
The default creation factor is 60 (roughly speaking, it wants 60% of
the lines to match between
>>> "SG" == SZEDER Gábor writes:
> On Wed, Oct 09, 2019 at 09:13:56AM +0300, Uwe Brauer wrote:
>> Could you please try out
>> git clone https://git.code.sf.net/p/matlab-emacs/src matlab-emacs-hg
> This repository contains two branches: 'master' and 'strings'. From
> these two 'm
On Wed, Oct 09, 2019 at 09:13:56AM +0300, Uwe Brauer wrote:
> Could you please try out
> git clone https://git.code.sf.net/p/matlab-emacs/src matlab-emacs-hg
This repository contains two branches: 'master' and 'strings'. From
these two 'master' is the default branch, so that is that 'git clone'
On 10/8/2019 11:51 PM, wuzhouhui wrote:
>> -Original Messages-
>> From: "Junio C Hamano"
>> Sent Time: 2019-10-09 11:02:44 (Wednesday)
>> To: wuzhouhui
>> Cc: git@vger.kernel.org, cuif...@sugon.com
>> Subject: Re: How to find the commit that erase a change
>>
>> wuzhouhui writes:
>>
>>>
On 10/9/2019 2:13 AM, Uwe Brauer wrote:
>
>> On Tue, Sep 24, 2019 at 12:22:27PM +0200, Uwe Brauer wrote:
>
>> I hear you: I had a brief encounter with Mercurial not that long ago,
>> and there were several things that didn't work the way I expected (or
>> rather: the way I got u
Johannes Schindelin writes:
> On Wed, 9 Oct 2019, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > FWIW I actually agree with Junio about the helper, but in hindsight I
>> > could have used a better name (not one that is tied to the "index").
>> > Something like `unsigned_one_compl
Hi Junio,
On Wed, 9 Oct 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > FWIW I actually agree with Junio about the helper, but in hindsight I
> > could have used a better name (not one that is tied to the "index").
> > Something like `unsigned_one_complement()`. But of course, th
Johannes Schindelin writes:
> FWIW I actually agree with Junio about the helper, but in hindsight I
> could have used a better name (not one that is tied to the "index").
> Something like `unsigned_one_complement()`. But of course, that would
> say _what_ it does, not _why_.
I personally feel th
"brian m. carlson" writes:
> ... An option to git commit such as --trailer would
> allow folks to add whatever trailers they wish, including this one,
> without us needing to bless particular options.
Yes, that was what I was hoping to become the "core" of the idea,
with possibly syntax sugar t
On 2019-10-09 at 02:19:47, Junio C Hamano wrote:
> I think we have been happy with (1) a comment at the end of the log
> message that says X worked together with Y and Z to produce this
> patch, and (2) the trailer block that has S-o-b: from X, Y and Z,
> without any need for Co-authored-by: traile
On Wed, Oct 9, 2019 at 2:20 AM Junio C Hamano wrote:
>
> For reference, here is the CoC the patch wants to add (there is no
> such topic yet locally, nor a single patch that can be made into
> such a topic, so there isn't exactly something people can Ack on
> yet. So here is a "preview" of what we
Thanks for your comprehensive answer, Elijah!
On Di, Okt 08, 2019 at 09:14:27 -0700, Elijah Newren wrote:
> On Mon, Oct 7, 2019 at 11:52 PM Josef Wolf wrote:
> >
> > I am trying to add a file to an arbitrary branch without touching the
> > current
> > worktree with as little overhead as possible
On Tue, Oct 8, 2019 at 3:47 PM Lucas Oshiro wrote:
>
> git tag --edit and --no-edit flags are not currently fully supported.
> This patch fixes the functionality that allows the editor to be opened
> on demand.
>
> Co-authored-by: Bárbara Fernandes
> Signed-off-by: Lucas Oshiro
> Signed-off-by:
Hi Hannes,
On Wed, 9 Oct 2019, Johannes Sixt wrote:
> Am 09.10.19 um 03:19 schrieb Junio C Hamano:
> > Johannes Sixt writes:
>
> > After all, the primary purpose of
> > inventing the encoder was to catch the arith overflow, wasn't it?
>
> That was *your* motivation for the helper function. But
Hi Hannes,
On Tue, 8 Oct 2019, Johannes Sixt wrote:
> Am 08.10.19 um 08:48 schrieb Johannes Schindelin via GitGitGadget:
> > We have just introduced the helper `index_pos_to_insert_pos()` to help
> > avoiding underflows when returning `-1 - pos` for cases where we want to
> > return an insert pos
Hi Junio,
On Wed, 9 Oct 2019, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > We do not want to have it for *all* cases, where we return -1 - pos, but
> > only for those cases, where the result was actually encoded by
> > index_pos_to_insert_pos().
>
> Yup, I agree with you that decoder sho
Hi Emily,
On Tue, 8 Oct 2019, Emily Shaffer wrote:
> On Wed, Oct 09, 2019 at 09:14:59AM +0900, Junio C Hamano wrote:
> > Johannes Schindelin writes:
> >
> > > In other words, the commit message can be augmented by this:
> > >
> > > Acked-by: Johannes Schindelin
> > > Acked-by: Derrick Stolee
>
On Tue, Oct 08, 2019 at 06:38:43PM +0100, Thomas Gummerer wrote:
> In ef283b3699 ("apply: make parse_git_diff_header public", 2019-07-11)
> the 'parse_git_diff_header' function was made public and useable by
> callers outside of apply.c.
>
> However it was missed that its (then) only caller, 'find
49 matches
Mail list logo
