Jeff King writes:
>> +The type specifier can be either `--int` or `--bool`, to make 'git config'
>> +ensure that the variable(s) are of the given type and convert the value to
>> the
>> +canonical form (simple decimal number for int, a "true" or "false" string
>> for
>> +bool, either of for --b
On Tue, Mar 6, 2018 at 1:52 AM, Jeff King wrote:
> On Mon, Mar 05, 2018 at 06:17:26PM -0800, Taylor Blau wrote:
>> In an aim to replace:
>> $ git config --get-color slot [default] [...]
>> with:
>> $ git config --default default --color slot [...]
>> introduce `--defualt` to behave as if the g
On Mon, Mar 5, 2018 at 9:17 PM, Taylor Blau wrote:
> In an aim to replace:
>
> $ git config --get-color slot [default] [...]
>
> with:
>
> $ git config --default default --color slot [...]
>
> introduce `--defualt` to behave as if the given default were present and
s/--defualt/--default/
> a
On Mon, Mar 05, 2018 at 06:17:29PM -0800, Taylor Blau wrote:
> As of this commit, the cannonical way to retreive an ANSI-compatible
> color escape sequence from a configuration file is with the
> `--get-color` action.
>
> This is to allow Git to "fall back" on a default value for the color
> shou
On Mon, Mar 05, 2018 at 06:17:28PM -0800, Taylor Blau wrote:
> In preparation for adding `--color` to the `git-config(1)` builtin,
> let's introduce a color parsing utility, `git_config_color` in a similar
> fashion to `git_config_`.
Sounds good...
> @@ -1000,6 +1001,15 @@ int git_config_expiry_
On Mon, Mar 05, 2018 at 06:17:27PM -0800, Taylor Blau wrote:
> The documentation for the `git-config(1)` builtin has not been recently
> updated to include new types, such as `--bool-or-int`, and
> `--expiry-date`. To ensure completeness when adding a new type
> specifier, let's update the existin
On Mon, Mar 05, 2018 at 06:17:26PM -0800, Taylor Blau wrote:
> In an aim to replace:
>
> $ git config --get-color slot [default] [...]
>
> with:
>
> $ git config --default default --color slot [...]
>
> introduce `--defualt` to behave as if the given default were present and
> assigned to
On Mon, Mar 05, 2018 at 01:36:49PM -0800, Jonathan Nieder wrote:
> > I agree that would be a lot more pleasant for adding protocol features.
> > But I just worry that the stateful protocols get a lot less efficient.
> > I'm having trouble coming up with an easy reproduction, but my
> > recollectio
Dear Sir
i have this bellow funds for investment in oil and real estate money in uae
shearing 40% 60%
total funs $50,000,000 USD
Your Private Mobile No:
REPLY HERE : borisputinmarketingoiland...@gmail.com
MR MOHAMED ABDUL
Johannes,
On March 5, 2018 1:47 PM, Johannes Schindelin
wrote:
> As the credential-helper is already intended for sensitive data, and as it
> already allows to interact with a helper, I would strongly assume that it
> would make more sense to try to extend that feature (instead of the simple
>
The previous version only looked at core.excludesfile for locating the
excludesfile. So, when core.excludesfile was not defined, it did not
use the relevant default locations for the global excludes file.
The issue is in git-get-exclude-files(). Investigation shows that
git-get-exclude-files() i
Hi Johannes,
On 26/02/2018 22:29, Johannes Schindelin wrote:
>
> Once upon a time, I dreamt of an interactive rebase that would not
> flatten branch structure, but instead recreate the commit topology
> faithfully.
>
> My original attempt was --preserve-merges, but that design was so
> limited t
On Mon, Mar 05, 2018 at 06:17:25PM -0800, Taylor Blau wrote:
> Attached is a patch series to introduce `--default` and `--color` to the
> `git-config(1)` builtin with the aim of introducing a consistent interface to
> replace `--get-color`.
This series draws significant inspiration from Soukaina N
The documentation for the `git-config(1)` builtin has not been recently
updated to include new types, such as `--bool-or-int`, and
`--expiry-date`. To ensure completeness when adding a new type
specifier, let's update the existing documentation to include the new
types.
This commit also prepares f
As of this commit, the cannonical way to retreive an ANSI-compatible
color escape sequence from a configuration file is with the
`--get-color` action.
This is to allow Git to "fall back" on a default value for the color
should the given section not exist in the specified configuration(s).
With th
In an aim to replace:
$ git config --get-color slot [default] [...]
with:
$ git config --default default --color slot [...]
introduce `--defualt` to behave as if the given default were present and
assigned to slot in the case that that slot does not exist.
Values filled by `--default` beha
In preparation for adding `--color` to the `git-config(1)` builtin,
let's introduce a color parsing utility, `git_config_color` in a similar
fashion to `git_config_`.
Signed-off-by: Taylor Blau
---
config.c | 10 ++
config.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/config.
Hi,
Attached is a patch series to introduce `--default` and `--color` to the
`git-config(1)` builtin with the aim of introducing a consistent interface to
replace `--get-color`.
Thank you in advance for reviewing this series; I will be more than happy to
respond to any feedback seeing as I am sti
kalle writes:
> -In the explanation of the option --reference: shouldn't there be
> written '' instead of 'reference repository'?
"Shouldn't X be Y?" is not an effective way to communicate; it
solicits a "no, the current one is fine." without any explanation.
If you think X should be Y for som
SiddharthaMishra writes:
> Added a job to run clang static code analysis on the master and maint branch
>
> Signed-off-by: SiddharthaMishra
> ---
Why on 'master' and 'maint' and not others? Quite frankly, I find
this choice of branches rather odd, as these two branches are not
where the real d
Lars Schneider writes:
>> On 05 Mar 2018, at 22:50, Junio C Hamano wrote:
>>
>> lars.schnei...@autodesk.com writes:
>>
>>> +static int validate_encoding(const char *path, const char *enc,
>>> + const char *data, size_t len, int die_on_error)
>>> +{
>>> + if (!memcmp("UTF-", e
Paul-Sebastian Ungureanu writes:
> Usually, the usage should be shown only if the user does not know what
> options are available. If the user specifies an invalid value, the user
> is already aware of the available options. In this case, there is no
> point in displaying the usage anymore.
>
> T
On Mon, Mar 5, 2018 at 9:00 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Thu, Mar 01 2018, Nguyễn Thái Ngọc Duy jotted:
>
>> pack-objects could be a big memory hog especially on large repos,
>> everybody knows that. The suggestion to stick a .keep file on the
>> largest pack to avoid this problem is
> On 05 Mar 2018, at 22:50, Junio C Hamano wrote:
>
> lars.schnei...@autodesk.com writes:
>
>> +static int validate_encoding(const char *path, const char *enc,
>> + const char *data, size_t len, int die_on_error)
>> +{
>> +if (!memcmp("UTF-", enc, 4)) {
>
> Does the caller
Hi,
kalle wrote:
> see attachment.
Thanks for writing. A few questions:
1. Can you say a little more about the rationale for this change?
E.g. is the current formatting sending a confusing message? Is the
current formatting intending to use '' as quotes and using italics
instead?
The patches are attached.
Further some questions:
-see the explanations of the branch command, ca. line 280: wouldn't it
be better to use other words than 'references'?
-sentence "it shows all commits reachable from the parent commit": it
seems wrong to me. The last commit is also shown.
- chapter
The patches are attached.
Further some questions:
-see the explanations of the branch command, ca. line 280: wouldn't it
be better to use other words than 'references'?
-sentence "it shows all commits reachable from the parent commit": it
seems wrong to me. The last commit is also shown.
- chapter
-In the explanation of the option --reference: shouldn't there be
written '' instead of 'reference repository'?
greetings,
kalle
see attachment.
greetings,
kalle
>From ed466d29733a14acf3b2071d3d35aa829e09b1d7 Mon Sep 17 00:00:00 2001
From: kalledaballe
Date: Thu, 8 Feb 2018 18:53:54 +0100
Subject: [PATCH 1/5] I corrected some few quotation mistakes
---
Documentation/gittutorial.txt | 6 +++---
1 file changed, 3 insertions
On Mon, Mar 5, 2018 at 4:37 AM, Andreas Heiduk wrote:
> 2018-03-05 2:42 GMT+01:00 Eric Sunshine :
>> On Sun, Mar 4, 2018 at 6:22 AM, Andreas Heiduk wrote:
>>> The email address in --authors-file and --authors-prog can be empty but
>>> git-svn translated it into a syntethic email address in the fo
On Sat, Mar 03 2018, Jeff King jotted:
> The rest of this email is all logistics for attendees, so if you're not
> coming, you can stop reading. :)
I'll be arriving in BCN around 17:00 tomorrow. If someone wants to grab
pre-dinner beer or dinner, preferably in the Eixample district (just
across
On Mon, Mar 5, 2018 at 11:09 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> On Sat, Mar 03 2018, Jeff King jotted:
>>
>>> +if (@colored && @colored != @diff) {
>>
>> nit: should just be:
>>
>> if (@colored != @diff) {
>>
>> It's not possible for @arrays in scalar context
On Mon, Mar 05 2018, Jonathan Nieder jotted:
> Lars Schneider wrote:
>> - error reporting: Git is distributed and therefore lots of errors are only
>> reported locally. That makes it hard for administrators in larger
>> companies to see trouble. Would it make sense to add a config option that
Ævar Arnfjörð Bjarmason writes:
> On Sat, Mar 03 2018, Jeff King jotted:
>
>> +if (@colored && @colored != @diff) {
>
> nit: should just be:
>
> if (@colored != @diff) {
>
> It's not possible for @arrays in scalar context to be undefined.
It is true that @array can not be undef, but your
On Mon, Mar 05 2018, Lars Schneider jotted:
>> On 03 Mar 2018, at 11:39, Jeff King wrote:
>>
>> On Sat, Mar 03, 2018 at 05:30:10AM -0500, Jeff King wrote:
>>
>>> As in past years, I plan to run it like an unconference. Attendees are
>>> expected to bring topics for group discussion. Short presen
Jeff King wrote:
> On Fri, Mar 02, 2018 at 09:15:44AM -0800, Junio C Hamano wrote:
>> Jeff King writes:
>>> That's probably a reasonable sanity check, but I think we need to abort
>>> and not just have a too-small DISPLAY array. Because later code like the
>>> hunk-splitting is going to assume th
lars.schnei...@autodesk.com writes:
> +static int validate_encoding(const char *path, const char *enc,
> + const char *data, size_t len, int die_on_error)
> +{
> + if (!memcmp("UTF-", enc, 4)) {
Does the caller already know that enc is sufficiently long that
using memcmp is
Hi,
Jeff King wrote:
> I agree that would be a lot more pleasant for adding protocol features.
> But I just worry that the stateful protocols get a lot less efficient.
> I'm having trouble coming up with an easy reproduction, but my
> recollection is that http has some nasty corner cases, because
Jeff King writes:
> Yeah, I think the ref_array_item.refname flex-parameter is not valid.
> This is the same issue Ramsay mentioned in:
>
>
> https://public-inbox.org/git/58b2bdcd-d621-fd21-ab4d-6a9478319...@ramsayjones.plus.com/
>
> Junio, I think it probably makes sense to eject ot/cat-batch
On Sat, Mar 03 2018, Jeff King jotted:
> + if (@colored && @colored != @diff) {
nit: should just be:
if (@colored != @diff) {
It's not possible for @arrays in scalar context to be undefined.
Jeff King writes:
>> True. The user could tell the server operator to rename them or
>> remove them because they are not doing anything useful, but then
>> as long as everybody knows they are not doing anything, it is OK
>> to leave that sleeping dog lie, as they are not doing anything
>> harmfu
On Sat, Mar 3, 2018 at 8:12 AM, Jeff King wrote:
> On Sat, Feb 24, 2018 at 12:39:40AM +0100, SZEDER Gábor wrote:
>
>> The first patch is the most important: with a couple of well-placed file
>> descriptor redirections it ensures that the stderr of the test helper
>> functions running git commands
On Mon, Mar 05, 2018 at 12:53:07PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > It's important that the diff-filter only filter the
> > individual lines, and that there remain a one-to-one mapping
> > between the input and output lines. Otherwise, things like
> > hunk-splitting will be
Jeff King writes:
> It's important that the diff-filter only filter the
> individual lines, and that there remain a one-to-one mapping
> between the input and output lines. Otherwise, things like
> hunk-splitting will behave quite unexpectedly (e.g., you
> think you are splitting at one point, bu
On Mon, Mar 05, 2018 at 10:43:21AM -0800, Brandon Williams wrote:
> In the current protocol http has a lot of additional stuff that's had to
> be done to it to get it to work with a protocol that was designed to be
> stateful first. What I want is for the protocol to be designed
> stateless first
On Mon, Mar 05, 2018 at 10:29:14AM -0800, Jonathan Nieder wrote:
> >> It also accepts "refs/h*" to get "refs/heads" and "refs/hello". I think
> >> it's worth going for the most-restrictive thing to start with, since
> >> that enables a lot more server operations without worrying about
> >> breaki
On Mon, Mar 05, 2018 at 10:21:55AM -0800, Brandon Williams wrote:
> > Hmm, so this would accept stuff like "refs/heads/*/foo" but quietly
> > ignore the "/foo" part.
>
> Yeah that's true...this should probably not do that. Since
> "refs/heads/*/foo" violates what the spec is, really this should
Johannes Schindelin writes:
>> > "What if they say my code is not good enough?"
>>
>> Sure, though there is something implied in what is Junio is saying
>> that is useful for such people.
>>
>> It is patience. It is the message that if you miss a portability bug,
>> we won't be disappointed in
Andreas Heiduk wrote:
> 2018-03-05 2:42 GMT+01:00 Eric Sunshine :
> > Doesn't such a behavior change deserve being documented (and possibly
> > tests)?
>
> The old behaviour was neither documented nor tested - the
> change did not break any test after all.
I consider that too low of a bar to ju
Am 05.03.2018 um 20:48 schrieb Andreas Heiduk:
> Am 05.03.2018 um 18:52 schrieb Eric Wong:
>> Thanks both, I've queued 1/2 up with Eric S's edits at svn/authors-prog.
>> I'm not yet convinced 2/2 is a good change, however.
>
> I'm not sure which direction your argument points to: Do you object to
Added a job to run clang static code analysis on the master and maint branch
Signed-off-by: SiddharthaMishra
---
.travis.yml | 17 -
ci/run-static-analysis.sh | 9 -
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/.travis.yml b/.travis.yml
i
Am 05.03.2018 um 18:52 schrieb Eric Wong:
>
> Thanks both, I've queued 1/2 up with Eric S's edits at svn/authors-prog.
> I'm not yet convinced 2/2 is a good change, however.
I'm not sure which direction your argument points to: Do you object to a
$PATH search at all? Or would you like to remove
On 03/02, Johannes Schindelin wrote:
> Hi Brandon,
>
> On Wed, 28 Feb 2018, Brandon Williams wrote:
>
> > diff --git a/remote-curl.c b/remote-curl.c
> > index 66a53f74b..3f882d766 100644
> > --- a/remote-curl.c
> > +++ b/remote-curl.c
> > @@ -188,7 +188,12 @@ static struct ref *parse_git_refs(str
Nguyễn Thái Ngọc Duy writes:
> 01/44 - 05/44: nd/remove-ignore-env-field
>
> This series is moved up top. After this the patch that touch
> alternate-db in sha1_file.c looks natural because no env is involved
> anymore
Yes, I do like having this upfront and being able to merge it before
h
Ævar Arnfjörð Bjarmason writes:
> Same as v2 except rebased on master & a couple of commit message
> fixes, thanks to Eric Sunshine (thanks!). tbdiff with v2:
Noting that the series was rebased is a good thing to do, but a
statement of the fact alone without justification makes readers
wonder i
On Mon, Mar 5, 2018 at 1:26 PM, Jonathan Nieder wrote:
> Johannes Schindelin wrote:
>> The Google gang (you & Junio included) uses Linux. Peff uses Linux. From
>> what I can see Duy, Eric and Jake use Linux. That covers already the most
>> active reviewers right there.
>
> We are not as uniform as
Lars Schneider wrote:
> Thanks for starting this. I would like to propose the following topics:
Cool! Do you mind starting threads for these so people who aren't there
can provide input into the discussion, too? In other words, I'm
imagining
1. Thread starts on mailing list
2. Contributor s
Phillip Wood writes:
> From: Phillip Wood
>
> I've updated these to clean up the perl style in response to Junio's
> comments on v4.
I've considered the use of "apply --recount" in this script (eh,
rather, the existence of that option in "apply" command itself ;-))
a bug that need to be eventua
On 03/02, Jeff King wrote:
> On Fri, Feb 23, 2018 at 01:22:31PM -0800, Brandon Williams wrote:
>
> > On 02/22, Stefan Beller wrote:
> > > On Tue, Feb 6, 2018 at 5:12 PM, Brandon Williams
> > > wrote:
> > >
> > > > +static void pack_line(const char *line)
> > > > +{
> > > > + if (!strcmp(l
On Mon, Mar 5, 2018 at 1:37 PM, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>> Could you please save 'git worktree's output into an intermediate
>> file, and run 'grep' on the file's contents?
>
> Here is what I tentatively came up with, while deciding what should
> be queued based on Eric's p
On 03/02, Jeff King wrote:
> On Fri, Feb 23, 2018 at 01:45:57PM -0800, Brandon Williams wrote:
>
> > I think this is the price of extending the protocol in a backward
> > compatible way. If we don't want to be backwards compatible (allowing
> > for graceful fallback to v1) then we could design th
SZEDER Gábor writes:
> There is one more issue in these tests.
> ...
> The main purpose of this test script is to test the 'git worktree'
> command, but these pipes hide its exit code.
> Could you please save 'git worktree's output into an intermediate
> file, and run 'grep' on the file's content
> On 03 Mar 2018, at 11:39, Jeff King wrote:
>
> On Sat, Mar 03, 2018 at 05:30:10AM -0500, Jeff King wrote:
>
>> As in past years, I plan to run it like an unconference. Attendees are
>> expected to bring topics for group discussion. Short presentations are
>> also welcome. We'll put the topics
Hi,
On Mon, Mar 05, 2018 at 10:21:55AM -0800, Brandon Williams wrote:
> On 03/02, Jeff King wrote:
>> It also accepts "refs/h*" to get "refs/heads" and "refs/hello". I think
>> it's worth going for the most-restrictive thing to start with, since
>> that enables a lot more server operations witho
Hi again,
Back on topic, some quick clarifications to tie up loose ends.
Also I want to thank you for continuing to push the project to work
better (especially to work better for newcomers). We don't seem to
have a habit of saying often enough how important that goal is. Of
course we'll disagre
On 03/02, Jeff King wrote:
> On Wed, Feb 28, 2018 at 03:22:30PM -0800, Brandon Williams wrote:
>
> > +static void add_pattern(struct pattern_list *patterns, const char *pattern)
> > +{
> > + struct ref_pattern p;
> > + const char *wildcard;
> > +
> > + p.pattern = strdup(pattern);
>
> xstrd
Derrick Stolee wrote:
> Dereck Stolee wrote:
>
> nit: s/Dereck/Derrick/ Is my outgoing email name misspelled, or do you have
> a misspelled contact info for me?
A manual typo. Sorry about that.
[... a bunch snipped ...]
> I have a habit of being too loose in language around lawyer-speak. I s
Hi Dscho,
Johannes Schindelin wrote:
> On Sat, 3 Mar 2018, Jonathan Nieder wrote:
>> Hopefully the clarifications and suggestions higher in this message
>> help. If they don't, then I'm nervous about our ability to understand
>> each other.
>
> Okay, let me state what I think the goal of this do
Hi Phillip,
On Fri, 2 Mar 2018, Phillip Wood wrote:
> On 01/03/18 05:39, Sergey Organov wrote:
> >
> > Igor Djordjevic writes:
> >
> >> On 28/02/2018 06:19, Sergey Organov wrote:
> >>>
> > (3) ---X1---o---o---o---o---o---X2
> >|\ |\
> >| A1---A
Eric Sunshine wrote:
> On Sun, Mar 4, 2018 at 6:22 AM, Andreas Heiduk wrote:
> > In 36db1eddf9 ("git-svn: add --authors-prog option", 2009-05-14) the path
> > to authors-prog was made absolute because git-svn changes the current
> > directoy in some situations. This makes sense if the program is
My apologies.
Seems there was some error causing this, I see now that paths are
automatically re-selected by default. Can't reproduce the error.
Please disregard this thread.
Birger
Hi Buga,
On Sat, 3 Mar 2018, Igor Djordjevic wrote:
> By the way, is there documentation for `git merge-recursive`
> anywhere, besides the code itself...? :$
I am not aware of any. The commit message adding the command is not very
illuminating (https://github.com/git-for-windows/git/commit/720d
This makes add/add conflicts use the new handle_file_collision()
function. This leaves the handling of the index the same, but
modifies how the working tree is handled: instead of always doing
a two-way merge of the file contents and recording them at the
collision path name, we instead first esti
This makes the rename/add conflict handling make use of the new
handle_file_collision() function, which fixes several bugs and improves
things for the rename/add case significantly. Previously, rename/add
would:
* Not leave any higher order stage entries in the index, making it
appear as if
There are three conflict types that represent two (possibly entirely
unrelated) files colliding at the same location:
* add/add
* rename/add
* rename/rename(2to1)
These three conflict types already share more similarity than might be
immediately apparent from their description: (1) the handl
This makes the rename/rename(2to1) conflicts use the new
handle_file_collision() function. Since that function was based
originally on the rename/rename(2to1) handling code, the main
differences here are in what was added. In particular:
* If the two colliding files are similar, instead of bei
Adds testcases dealing with file collisions for the following types of
conflicts:
* add/add
* rename/add
* rename/rename(2to1)
These tests include expectations for proposed smarter behavior which has
not yet been implemented and thus are currently expected to fail.
Subsequent commits will cor
This series improves conflict resolutions for conflict types that involve
two (possibly entirely unrelated) files colliding at the same path. These
conflict types are:
* add/add
* rename/add
* rename/rename(2to1)
Improving these conflict types has some subtle (though significant)
performanc
On 03/03, Jeff King wrote:
> On Sat, Mar 03, 2018 at 05:30:10AM -0500, Jeff King wrote:
>
> > As in past years, I plan to run it like an unconference. Attendees are
> > expected to bring topics for group discussion. Short presentations are
> > also welcome. We'll put the topics on a whiteboard in
Hi Birger,
On Wed, 28 Feb 2018, Birger Skogeng Pedersen wrote:
> The user cannot change focus between the list of files, the diff view
> and the commit message widgets without using the mouse (clicking either of
> the four widgets ).
>
> Hotkeys CTRL/CMD+number (1-4) now focuses the first file o
Hi Jonathan,
On Sat, 3 Mar 2018, Jonathan Nieder wrote:
> Johannes Schindelin wrote:
> >> Jonathan Nieder writes:
> >>> Dereck Stolee wrote:
>
> +Test Your Changes on Linux
> +--
> +
> +It can be important to work directly on the [core Git
> code
On Mon, Mar 05, 2018 at 03:49:13PM +0100, Johannes Schindelin wrote:
> > I think that is doing the right thing for half of the problem. But
> > there's something else funny where we do not include the "upstream"
> > commits from the split history (i.e., we rebase onto nothing,
> > whereas a normal
I really appreciate the feedback on this document, Jonathan.
On 3/3/2018 1:27 PM, Jonathan Nieder wrote:
Hi Dscho,
Johannes Schindelin wrote:
Jonathan Nieder writes:
Dereck Stolee wrote:
nit: s/Dereck/Derrick/ Is my outgoing email name misspelled, or do you
have a misspelled contact info
Hi Peff,
On Wed, 28 Feb 2018, Jeff King wrote:
> On Tue, Feb 27, 2018 at 12:33:56AM +0100, Johannes Schindelin wrote:
>
> > > So something like this helps:
> > >
> > > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> > > index 81c5b42875..71e6cbb388 100644
> > > --- a/git-
On Sat, Mar 03 2018, Jeff King jotted:
> Feel free to reply to this thread if you want to make plans or discuss
> any proposed topics before the summit. Input or questions from
> non-attendees is welcome here.
1)
Last year we discussed the general topic of performance. That's of
course very gen
On 3/3/2018 5:39 AM, Jeff King wrote:
On Sat, Mar 03, 2018 at 05:30:10AM -0500, Jeff King wrote:
As in past years, I plan to run it like an unconference. Attendees are
expected to bring topics for group discussion. Short presentations are
also welcome. We'll put the topics on a whiteboard in th
Hi Larry,
On Sun, 4 Mar 2018, Larry Hunter wrote:
> There is bug using "git log --show-signature" in my installation
>
> git 2.16.2.windows.1
> gpg (GnuPG) 2.2.4
> libgcrypt 1.8.2
The gpg.exe shipped in Git for Windows should say something like this:
$ gpg --version
On Thu, Mar 01 2018, Nguyễn Thái Ngọc Duy jotted:
> pack-objects could be a big memory hog especially on large repos,
> everybody knows that. The suggestion to stick a .keep file on the
> largest pack to avoid this problem is also known for a long time.
>
> Let's do the suggestion automatically i
Hi Colin,
On Sun, 4 Mar 2018, Colin Arnott wrote:
> The http.extraHeader config parameter currently only supports storing
> constant values. There are two main use cases where this fails:
>
> 0. Sensitive payloads: frequently this config parameter is used to pass
> authentication credenti
> Recently-added "git worktree move" tests include a minor error and a few
> small issues. Specifically:
>
> * checking non-existence of wrong file ("source" instead of
> "destination")
>
> * unneeded redirect (">empty")
>
> * unused variable ("toplevel")
>
> * restoring a worktree location b
On Mon, Mar 5, 2018 at 11:59 AM, Phillip Wood wrote:
> I did wonder about putting this function in a library when I first wrote
> it but decided to wait and see if it is useful instead. As Junio points
> out it would need to be improved to act as a generic filter, so I'll
> take the easy option an
On Sat, Mar 3, 2018 at 9:21 PM, Randall S. Becker
wrote:
> On March 2, 2018 10:39 PM, Nguy?n Thái Ng?c Duy wrote:
>> This is something we could do to improve the situation when a user manually
>> moves a worktree and not follow the update process (we have had the first
>> reported case [1]). Plus
On 02/03/18 16:09, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>>> +diff_cmp () {
>>> + for x
>>> + do
>>> + sed -e '/^index/s/[0-9a-f]*[1-9a-f][0-9a-f]*\.\./1234567../' \
>>> +-e '/^index/s/\.\.[0-9a-f]*[1-9a-f][0-9a-f]*/..9abcdef/' \
>>> +-e '/^
From: Phillip Wood
Now that add -p counts patches properly it should be possible to turn
off the '--recount' option when invoking 'git apply'
Signed-off-by: Phillip Wood
---
Notes:
I can't think of a reason why this shouldn't be OK but I can't help
feeling slightly nervous about it. I'
From: Phillip Wood
Recount the number of preimage and postimage lines in a hunk after it
has been edited so any change in the number of insertions or deletions
can be used to adjust the offsets of subsequent hunks. If an edited
hunk is subsequently split then the offset correction will be lost. I
From: Phillip Wood
Since commit 8cbd431082 ("git-add--interactive: replace hunk
recounting with apply --recount", 2008-7-2) if a hunk is skipped then
we rely on the context lines to apply subsequent hunks in the right
place. While this works most of the time it is possible for hunks to
end up bei
From: Phillip Wood
When a hunk is skipped by add -i the offsets of subsequent hunks are
not adjusted to account for any missing insertions due to the skipped
hunk. Most of the time this does not matter as apply uses the context
lines to apply the subsequent hunks in the correct place, however in
From: Phillip Wood
Use a filter when comparing diffs to fix the value of non-zero hashes
in diff index lines so we're not hard coding sha1 hash values in the
expected output. This makes it easier to change the expected output if
a test is edited as we don't need to worry about the exact hash valu
From: Phillip Wood
When a file has no trailing new line at the end diff records this by
appending "\ No newline at end of file" below the last line of the
file. This line should not be counted in the hunk header. Fix the
splitting and coalescing code to count files without a trailing new line
pro
From: Phillip Wood
This code is duplicated in a couple of places so make it into a
function as we're going to add some more callers shortly.
Signed-off-by: Phillip Wood
---
git-add--interactive.perl | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/git
1 - 100 of 108 matches
Mail list logo