On Wed, Oct 09, 2019 at 07:25:51PM +0200, SZEDER Gábor wrote:
> > Probably they'd be easy enough to fix (and they're out of tree anyway),
> > so I'm not really arguing against the escape hatch exactly. Mostly I'm
> > just surprised that if I introduced 3 cases (out of probably a dozen
> > scripts)
On Wed, Oct 09, 2019 at 11:28:51AM -0400, Joey Hess wrote:
> > 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 "@{}" or similar
> > in it.
>
> N
On Tue, Oct 08, 2019 at 11:37:39AM -0700, Jonathan Tan wrote:
> When building the packfile to be sent, send_pack() is given a list of
> remote refs to be used as exclusions. For each ref, it first checks if
> the ref exists locally, and if it does, passes it with a "^" prefix to
> pack-objects. Ho
On Fri, Oct 04, 2019 at 05:13:08PM -0700, Denton Liu wrote:
> The synopsis section in git-rev-list.txt has grown to be a huge list
> that probably needs its own synopsis. Since the list is huge, users may
> be given the false impression that the list is complete, however it is
> not. It is missing
Jakob Jarmar writes:
> git stash push does not recursively stash submodules, but if
> submodule.recurse is set, it may recursively reset --hard them. Having
> only the destructive action recurse is likely to be surprising
> behaviour, and unlikely to be desirable, so the easiest fix should be to
On Fri, Oct 11, 2019 at 01:39:28PM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > ... but I'd still wait for a few
> > days for people who expressed their Acks but your scan missed, or
> > those who wanted to give their Acks but forgot to do so, to raise
> > their hands on this thre
Denton Liu writes:
> In previous patches, extern was mechanically removed from function
> declarations without care to formatting, causing parameter lists to be
> misaligned. Manually format changed sections such that the parameter
> lists are realigned.
>
> Viewing this patch with 'git diff -w'
Johannes Schindelin writes:
> On Thu, 10 Oct 2019, Maxim Belsky via GitGitGadget wrote:
>
>> From: Maxim Belsky
>>
>> Signed-off-by: Maxim Belsky
>
> I totally agree with the patch, but only because I read a couple of
> reports that users were struggling with this. Maybe add a couple of
> refer
On Thu, Oct 10, 2019 at 12:18:53AM +, Eric Wong wrote:
> > The project leadership team can be contacted by email as a whole at
> > g...@sfconservancy.org, or individually:
> >
> > - Ævar Arnfjörð Bjarmason
> > - Christian Couder
> > - Jeff King
> > - Junio C Hamano
>
> All folks
Emily Shaffer writes:
> @@ -77,6 +77,7 @@ API_DOCS = $(patsubst %.txt,%,$(filter-out
> technical/api-index-skel.txt technica
> SP_ARTICLES += $(API_DOCS)
>
> TECH_DOCS += MyFirstContribution
> +TECH_DOCS += MyFirstRevWalk
s/Rev/Object/ probably (if so I can locally amend).
> diff --git a/D
Johannes Schindelin writes:
> I should note that I looked through all of the hits of `git grep -w
> except -- t/` and did not find any other typo.
Thanks.
Thomas Gummerer writes:
> On 10/10, Johannes Schindelin via GitGitGadget wrote:
>> From: Johannes Schindelin
>>
>> The original phrasing of this paragraph made at least one person stumble
>> over the word "from" (thinking that it was a typo and "from" was
>> intended), and other readers chimed
On Fri, Oct 11, 2019 at 10:42:20AM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > static int calculate_width(const struct strbuf *row)
> > {
> > int in_termcode = 0;
> > int width = 0;
> > int i;
> >
> > for (i = 0; i < row.len; i++
On 11/10/19 3:36 pm, Andrew Donnellan wrote:
It would be nice if Mailman could adopt X-Original-Sender too. As it is,
(which I have gone ahead and reported as
https://gitlab.com/mailman/mailman/issues/641)
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com I
Junio C Hamano writes:
> ... but I'd still wait for a few
> days for people who expressed their Acks but your scan missed, or
> those who wanted to give their Acks but forgot to do so, to raise
> their hands on this thread.
Now, two days and four hours have passed, so I'll merge the result
to 'n
On 11/10/19 3:29 pm, Junio C Hamano wrote:
Jeff King writes:
This might provide an alternate solution (or vice versa). I kind of like
this one better in that it doesn't require the sender to do anything
differently (but it may be less robust, as it assumes the receiver
reliably de-mangling).
Jeff King writes:
> This might provide an alternate solution (or vice versa). I kind of like
> this one better in that it doesn't require the sender to do anything
> differently (but it may be less robust, as it assumes the receiver
> reliably de-mangling).
I share the assessment. I also feel t
Johannes Schindelin writes:
>> diff --git a/builtin/commit.c b/builtin/commit.c
>> index d898a57f5d..adb8c89c60 100644
>> --- a/builtin/commit.c
>> +++ b/builtin/commit.c
>> @@ -1653,7 +1653,7 @@ int cmd_commit(int argc, const char **argv, const char
>> *prefix)
>>
>> repo_rerere(the_reposi
Johannes Schindelin writes:
>> builtin/commit.c | 22 --
>> commit.h | 3 ---
>> sequencer.c | 45 ++---
>> sequencer.h | 2 ++
>> 4 files changed, 36 insertions(+), 36 deletions(-)
>
> Hmm. I would have thought that
"Johannes Schindelin via GitGitGadget"
writes:
> To answer Jonathan's question, at long last, yes, it is useful. A hook is
> not only an opportunity to run code at given points in Git's life cycle, but
> also an opportunity to stop Git in its tracks.
In general that is correct, and especially so
Jonathan Tan writes:
>> -if ((opt & PICKAXE_BLAME_COPY_HARDEST)
>> -|| ((opt & PICKAXE_BLAME_COPY_HARDER)
>> +if ((opt & BLAME_COPY_HARDEST)
>> +|| ((opt & BLAME_COPY_HARDER)
>
> Any reason why the names are renamed to omit "PICKAXE_"? In particular,
> these names are stil
Jeff King writes:
> Yes, I agree that ordering and de-duplication rules are useful, too.
> Some of that can be expressed already in trailer.* config, but I don't
> know if it would be capable enough to do everything you want (though
> again, it would be really nice to _make_ it capable enough so
Denton Liu writes:
> static int calculate_width(const struct strbuf *row)
> {
> int in_termcode = 0;
> int width = 0;
> int i;
>
> for (i = 0; i < row.len; i++) {
> if (row.buf[i] == '\033')
>
Johannes Schindelin writes:
> This is a big heavy-handed: adding a `width` field to `struct strbuf`
> and maintaining it _just_ for the purpose of `graph.c` puts an
> unnecssary load on every other `strbuf` user (of which there are a
> _lot_).
>
> So my obvious question is: what makes `width` dif
On 10/10/2019 7:05 PM, Denton Liu wrote:
> Hi Dscho,
>
> On Thu, Oct 10, 2019 at 11:07:35PM +0200, Johannes Schindelin wrote:
>> Hi James,
>>
>> On Thu, 10 Oct 2019, James Coglan via GitGitGadget wrote:
>>
>>> From: James Coglan
>>>
>>> All the output functions in `graph.c` currently keep trac
git stash push does not recursively stash submodules, but if
submodule.recurse is set, it may recursively reset --hard them. Having
only the destructive action recurse is likely to be surprising
behaviour, and unlikely to be desirable, so the easiest fix should be to
ensure that the call to git res
I'm going to start with pack-bitmap.h, then builtin/pack-objects.c.
> int reuse_partial_packfile_from_bitmap(struct bitmap_index *,
> struct packed_git **packfile,
> -uint32_t *entries, off_t *up_to);
> +
> As we now allocate 2 more words than necessary for each
> bitmap to serve as marks telling us that we can stop
> iterating over the words, we don't need to rely on
> bitmap_git->reuse_objects to stop iterating over the words.
As Peff states [1], this justification is probably incorrect as well.
> From: Jeff King
>
> In a following patch we will allocate a variable number
> of words in some bitmaps. When iterating over the words we
> will need a mark to tell us when to stop iterating. Let's
> always allocate 2 more words, that will always contain 0,
> as that mark.
[snip]
> if (b
On Fri, 11 Oct 2019 10:16:40 +1100 Daniel Axtens wrote:
>
> Andrew Donnellan writes:
>
> > On 11/10/19 6:41 am, Jonathan Nieder wrote:
> >> Interesting! I'm cc-ing the Git mailing list in case "git am" might
> >> wnat to learn the same support.
> > Argh, that reminds me... this patch only r
git stash push does not recursively stash submodules, but if
submodule.recurse is set, it may recursively reset --hard them. Having
only the destructive action recurse is likely to be surprising
behaviour, and unlikely to be desirable, so the easiest fix should be to
ensure that the call to git res
Andrew Donnellan writes:
> On 11/10/19 6:41 am, Jonathan Nieder wrote:
>> Interesting! I'm cc-ing the Git mailing list in case "git am" might
>> wnat to learn the same support.
> Argh, that reminds me... this patch only rewrites the name and email
> that is recorded as the Patchwork submitter,
On 2019-10-10 at 08:49:23, Toon Claes wrote:
> Jeff King writes:
>
> > Yeah, I'd agree that we should start first with a generic trailer line.
>
> IIUC you are suggesting something like this?
>
> git commit --trailer="Co-authored-by: "
>
> I really want to consider this, but I do not understa
On Fri, Oct 11, 2019 at 10:01:23AM +1100, Andrew Donnellan wrote:
> > This might provide an alternate solution (or vice versa). I kind of like
> > this one better in that it doesn't require the sender to do anything
> > differently (but it may be less robust, as it assumes the receiver
> > reliabl
Hi Dscho,
On Thu, Oct 10, 2019 at 11:07:35PM +0200, Johannes Schindelin wrote:
> Hi James,
>
> On Thu, 10 Oct 2019, James Coglan via GitGitGadget wrote:
>
> > From: James Coglan
> >
> > All the output functions in `graph.c` currently keep track of how many
> > printable chars they've written to
On 11/10/19 9:54 am, Jeff King wrote:
Neat. There was discussion on a similar issue recently in:
https://public-inbox.org/git/305577c2-709a-b632-4056-658277117...@redhat.com/
where a possible solution was to get senders to use in-body From
headers even when sending their own patches.
I thi
On Thu, Oct 10, 2019 at 12:41:32PM -0700, Jonathan Nieder wrote:
> > Add support for using the X-Original-Sender or Reply-To headers, as used by
> > Google Groups and Mailman respectively, to unmangle the From header when
> > necessary.
> [...]
> Interesting! I'm cc-ing the Git mailing list in ca
Hi Phillip,
On Thu, 10 Oct 2019, Phillip Wood via GitGitGadget wrote:
> From: Phillip Wood
>
> Prior to commit 356ee4659b ("sequencer: try to commit without forking
> 'git commit'", 2017-11-24) the sequencer would always run the
> post-commit hook after each pick or revert as it forked `git comm
Hi Phillip,
On Thu, 10 Oct 2019, Phillip Wood via GitGitGadget wrote:
> From: Phillip Wood
>
> This simplifies the implementation of run_prepare_commit_msg_hook() and
> will be used in the next commit.
>
> Signed-off-by: Phillip Wood
> ---
> builtin/commit.c | 22 --
> comm
On 11/10/19 6:41 am, Jonathan Nieder wrote:
Interesting! I'm cc-ing the Git mailing list in case "git am" might
wnat to learn the same support.
Argh, that reminds me... this patch only rewrites the name and email
that is recorded as the Patchwork submitter, it doesn't actually rewrite
the From
Hi Maxim,
On Thu, 10 Oct 2019, Maxim Belsky via GitGitGadget wrote:
> From: Maxim Belsky
>
> Signed-off-by: Maxim Belsky
I totally agree with the patch, but only because I read a couple of
reports that users were struggling with this. Maybe add a couple of
reference points to the commit messa
Hi James,
On Thu, 10 Oct 2019, James Coglan via GitGitGadget wrote:
> From: James Coglan
>
> All the output functions in `graph.c` currently keep track of how many
> printable chars they've written to the buffer, before calling
> `graph_pad_horizontally()` to pad the line with spaces. Some funct
Team,
On Thu, 10 Oct 2019, Tanay Abhra via GitGitGadget wrote:
> diff --git a/t/t1308-config-set.sh b/t/t1308-config-set.sh
> index d0a2727b85..7b4e1a63eb 100755
> --- a/t/t1308-config-set.sh
> +++ b/t/t1308-config-set.sh
> @@ -166,14 +166,14 @@ test_expect_success 'find value with highest priori
Jonathan Nieder wrote:
> Eric Wong wrote:
> > Konstantin Ryabitsev wrote:
>
> >> This is actually really fast if you already have a local copy of the
> >> repository with most objects. Try this yourself if you have
> >> torvalds/linux.git locally:
> >>
> >> git clone --bare -s torvalds/linux.git
Eric Wong wrote:
> Konstantin Ryabitsev wrote:
>> This is actually really fast if you already have a local copy of the
>> repository with most objects. Try this yourself if you have
>> torvalds/linux.git locally:
>>
>> git clone --bare -s torvalds/linux.git test
>
> Yep, -s (--shared) makes cloni
(+cc: git)
Hi,
Konstantin Ryabitsev wrote[1]:
> How I envision this would work:
>
> - user creates an account (which requires a mail confirmation)
> - they choose a "submit patch" option from the menu
> - the patch submission screen has a succession of screens:
Interesting! This reminds me a bi
Hi,
Andrew Donnellan wrote:
> To avoid triggering spam filters due to failed signature validation, many
> mailing lists mangle the From header to change the From address to be the
> address of the list, typically where the sender's domain has a strict DMARC
> policy enabled.
>
> In this case, we
In previous patches, extern was mechanically removed from function
declarations without care to formatting, causing parameter lists to be
misaligned. Manually format changed sections such that the parameter
lists are realigned.
Viewing this patch with 'git diff -w' should produce no output.
Signe
> On 10/9/2019 7:44 PM, Jonathan Tan wrote:
> > Instead, recompute ancestry if we ever need to reclaim memory.
>
> I find this message lacking in important details:
>
> 1. Where do we recompute ancestry?
> 2. What are the performance implications of this change?
> 3. Why is it important that you
> Hello Jonathan!
> My name is Wambui and I'm one of the applicants in the current round of
> Outreachy applications. I wanted to write an initial email to introduce
> myself since I'm interested in working on your mentored projects!
>
> I have been going through the mailing list threads about Out
> Convert pickaxe_blame preprocessor constants in blame.h to an enum.
> Also replace previous instances of the constants with the new enum values.
First of all, thanks for your initiative in finding a microproject and
making a patch for it!
About your commit message title, I know that 50 characte
From: Phillip Wood
Prior to commit 356ee4659b ("sequencer: try to commit without forking
'git commit'", 2017-11-24) the sequencer would always run the
post-commit hook after each pick or revert as it forked `git commit` to
create the commit. The conversion to committing without forking `git
commi
From: Phillip Wood
Commit 65850686cf ("rebase -i: rewrite write_basic_state() in C",
2018-08-28) accidentially added new function declarations after
the #endif at the end of the include guard.
Signed-off-by: Phillip Wood
---
sequencer.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
From: Phillip Wood
This simplifies the implementation of run_prepare_commit_msg_hook() and
will be used in the next commit.
Signed-off-by: Phillip Wood
---
builtin/commit.c | 22 --
commit.h | 3 ---
sequencer.c | 45 ++-
When I converted the sequencer to avoid forking git commit i forgot about
the post-commit hook. These patches are based on
pw/rebase-i-show-HEAD-to-reword, otherwise the new test fails as that branch
changes the number of commits we make.
Phillip Wood (3):
sequencer.h fix placement of #endif
s
On Thu, Oct 10, 2019 at 11:16:24AM -0700, Denton Liu wrote:
> You can see the results of this by doing:
>
> $ git fetch https://github.com/Denton-L/git.git testing/graph-output
> $ git diff FETCH_HEAD^2 t/t4214-log-graph-octopus.sh
>
> and the resulting diff is very pleasing imo.
I g
Hi James,
Nicely done! This issue was bugging me for a while!
On Thu, Oct 10, 2019 at 09:13:52AM -0700, James Coglan via GitGitGadget wrote:
[...]
> diff --git a/t/t4214-log-graph-octopus.sh b/t/t4214-log-graph-octopus.sh
> index 9ada687628..fbd485d83a 100755
> --- a/t/t4214-log-graph-octopus.s
On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote:
> This series of patches are designed to improve the output of the log --graph
> command; their effect can be summed up in the following diagram:
>
> BeforeAfter
> ---
>
> *
>
On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote:
> From: James Coglan
>
> Following the introduction of "left-skewed" merges, which are merges
> whose first parent fuses with another edge to its left, we have some
> more edge cases to deal with in the display of commit and post-merge
On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote:
> From: James Coglan
>
> Currently, when we display a merge whose first parent is already present
> in a column to the left of the merge commit, we display the first parent
> as a veritcal pipe `|` in the GRAPH_POST_MERGE line and then
On Thu, Oct 10, 2019 at 01:49:03PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 9 Oct 2019, Jeff King wrote:
>
> > 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 combi
Hey,
Today I've spent a few hours to understand why git-completion doesn't work
in my zsh shell. It was because I thought ~/.zsh/_git should be a dictionary
with git-completion.zsh file.
I think this change may save some hours for someone else.
Maxim Belsky (1):
doc: Change zsh git completion
From: Maxim Belsky
Signed-off-by: Maxim Belsky
---
contrib/completion/git-completion.zsh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index 886bf95d1f..c0eca3ff25 100644
--- a/contrib/comp
On Thu, Oct 10, 2019 at 10:49:23AM +0200, Toon Claes wrote:
> > Yeah, I'd agree that we should start first with a generic trailer line.
>
> IIUC you are suggesting something like this?
>
> git commit --trailer="Co-authored-by: "
>
> I really want to consider this, but I do not understand how t
From: James Coglan
Following the introduction of "left-skewed" merges, which are merges
whose first parent fuses with another edge to its left, we have some
more edge cases to deal with in the display of commit and post-merge
lines.
The current graph code handles the following cases for edges ap
From: James Coglan
Currently, when we display a merge whose first parent is already present
in a column to the left of the merge commit, we display the first parent
as a veritcal pipe `|` in the GRAPH_POST_MERGE line and then immediately
enter the GRAPH_COLLAPSING state. The first-parent line tra
From: James Coglan
When a merge commit is printed and its final parent is the same commit
that occupies the column to the right of the merge, this results in a
kink in the displayed edges:
* |
|\ \
| |/
| *
Graphs containing these shapes can be hard to read, as t
From: James Coglan
The change I'm about to make requires being able to inspect the mapping
array that was used to render the last GRAPH_COLLAPSING line while
rendering a GRAPH_COMMIT line. The `new_mapping` array currently exists
as a pre-allocated space for computing the next `mapping` array dur
From: James Coglan
In 04005834ed ("log: fix coloring of certain octopus merge shapes",
2018-09-01) there is a fix for the coloring of dashes following an
octopus merge. It makes a distinction between the case where all parents
introduce a new column, versus the case where the first parent collaps
From: James Coglan
When a graph contains edges that are in the process of collapsing to the
left, but those edges cross a commit line, the effect is that the edges
have a jagged appearance:
*
|\
| *
| \
*-. \
|\ \ \
| | * |
| * | |
From: James Coglan
There's a duplication of logic between `graph_insert_into_new_columns()`
and `graph_update_width()`. `graph_insert_into_new_columns()` is called
repeatedly by `graph_update_columns()` with an `int *` that tracks the
offset into the `mapping` array where we should write the next
From: James Coglan
This computation is repeated in a couple of places and I need to add
another condition to it to implement a further improvement to the graph
rendering, so I'm extracting this into a function.
Signed-off-by: James Coglan
---
graph.c | 12
1 file changed, 8 insert
From: James Coglan
I will shortly be making some changes to this function and so am trying
to simplify it. It currently contains some duplicated logic; both
branches the function can take assign the commit's column index into
the `mapping` array and increment `mapping_index`.
Here I change the f
From: James Coglan
I will shortly be making some changes to
`graph_insert_into_new_columns()` and so am trying to simplify it. One
possible simplification is that we can extract the loop for finding the
element in `new_columns` containing the given commit.
`find_new_column_by_commit()` contains
From: James Coglan
All the output functions in `graph.c` currently keep track of how many
printable chars they've written to the buffer, before calling
`graph_pad_horizontally()` to pad the line with spaces. Some functions
do this by incrementing a counter whenever they write to the buffer, and
o
This series of patches are designed to improve the output of the log --graph
command; their effect can be summed up in the following diagram:
BeforeAfter
---
*
|\
| * *
| |\ |\
|
Hi,
I ran into an issue where git stash seems to be losing modified content
from submodules without warning, if submodule.recurse is true. See
below for an example:
1. enable submodule.recurse:
~ $ git config --global submodule.recurse true
2. create the repo to be used as a submodule:
~ $ git
The target audience is a Git contributor who is just getting started
with the concept of object walking. The goal is to prepare this
contributor to be able to understand and modify existing commands which
perform revision walks more easily, although it will also prepare
contributors to create new c
On 10/9/2019 7:44 PM, Jonathan Tan wrote:
> Instead, recompute ancestry if we ever need to reclaim memory.
I find this message lacking in important details:
1. Where do we recompute ancestry?
2. What are the performance implications of this change?
3. Why is it important that you construct a stac
From: Tanay Abhra
Change test 'find value_list for a key from a configset' to redirect the
result to 'expect' instead of 'except' which was a typo.
With this change, the test case actually fails because it uses
`configset_get_value`. Clearly, this was intended to be
`configset_get_value_multi` s
I am currently trying to whittle down the number of open PRs at
https://github.com/git/git, and this is one of the patches I deem valuable
enough (and complete enough) to put through to the Git mailing list even
when the original contributor has gone silent.
Tanay Abhra (1):
t1308-config-set: f
My name is lucifer lie,im am id hacked,have now 3,7nok million in debt,and
github brand shows upp on my 2 iphones,ipad,smart tv,mac aor,asus rod strix,mt
tv provider boks,these hackers are treathning me and stealing and using my id
overseas,i have talked too
www.okokrim.no,www.finanstilsynet.no
Hi Junio,
On Thu, 10 Oct 2019, Junio C Hamano wrote:
> "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:
> >
>
This is my attempt to revive an old discussion
[https://public-inbox.org/git/20180314003816.ge147...@aiede.svl.corp.google.com/]
(related to this StackOverflow thread
[https://stackoverflow.com/questions/25561485/git-rebase-i-with-squash-cannot-detach-head]
).
> [...] is this the right behavior
From: Johannes Schindelin
Currently, the exit code of the `post-checkout` hook becomes the exit
code of the `git restore` (or the equivalent `git checkout`) command,
_iff_ no error occurred during the `restore` operation.
That allows versatile scripting where the `post-checkout` failure modes
ca
Hi Denton,
On Wed, 9 Oct 2019, Denton Liu wrote:
> 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 t
Hi Peff,
On Wed, 9 Oct 2019, Jeff King wrote:
> 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 a
Convert pickaxe_blame preprocessor constants in blame.h to an enum.
Also replace previous instances of the constants with the new enum values.
Signed-off-by: Wambui Karuga
---
blame.c | 8
blame.h | 12 +++-
builtin/blame.c | 17 -
3 files change
Hi,
On Wed, 9 Oct 2019, Jeff King wrote:
> 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 C
Hello Jonathan!
My name is Wambui and I'm one of the applicants in the current round of
Outreachy applications. I wanted to write an initial email to introduce
myself since I'm interested in working on your mentored projects!
I have been going through the mailing list threads about Outreachy and
I
On Thu, Oct 10, 2019 at 01:07:32PM +0200, SZEDER Gábor wrote:
> On Wed, Oct 09, 2019 at 02:00:12PM -0700, William Baker via GitGitGadget
> wrote:
> > diff --git a/t/t7519-status-fsmonitor.sh b/t/t7519-status-fsmonitor.sh
> > index 81a375fa0f..87042470ab 100755
> > --- a/t/t7519-status-fsmonitor.sh
On Wed, Oct 09, 2019 at 02:00:12PM -0700, William Baker via GitGitGadget wrote:
> diff --git a/t/t7519-status-fsmonitor.sh b/t/t7519-status-fsmonitor.sh
> index 81a375fa0f..87042470ab 100755
> --- a/t/t7519-status-fsmonitor.sh
> +++ b/t/t7519-status-fsmonitor.sh
> @@ -354,4 +354,17 @@ test_expect_s
On 10/10, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> The original phrasing of this paragraph made at least one person stumble
> over the word "from" (thinking that it was a typo and "from" was
> intended), and other readers chimed in, agreeing that it was confusin
Hi Dscho,
On 10/10/2019 10:03, Johannes Schindelin wrote:
So a better interpretation would have been:
The default creation factor is 60 (roughly speaking, it wants at
most 60% of the diffs' lines to differ, otherwise it considers
them not to be a match.
This is still inaccurate, but at le
From: Johannes Schindelin
The original phrasing of this paragraph made at least one person stumble
over the word "from" (thinking that it was a typo and "from" was
intended), and other readers chimed in, agreeing that it was confusing:
https://public-inbox.org/git/0102016b8d597569-c1f6cfdc-cb45-4
This is an attempt to revive the discussion started in
https://public-inbox.org/git/0102016b8d597569-c1f6cfdc-cb45-4428-8737-cb1bc30655d8-000...@eu-west-1.amazonses.com/#t
Johannes Schindelin (1):
doc(stash): clarify the description of `save`
Documentation/git-stash.txt | 5 +++--
1 file chan
Hi Philip,
On Wed, 9 Oct 2019, Philip Oakley wrote:
> 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 de
Jeff King writes:
Yeah, I'd agree that we should start first with a generic
trailer line.
IIUC you are suggesting something like this?
git commit --trailer="Co-authored-by: "
I really want to consider this, but I do not understand how that
improves the user experience compared to adding t
98 matches
Mail list logo
