On Wed, Jul 25 2018, Junio C Hamano wrote:
> * js/range-diff (2018-07-25) 21 commits
> [...]
>
> "git tbdiff" that lets us compare individual patches in two
> iterations of a topic has been rewritten and made into a built-in
> command.
>
> Undecided.
>
> Many "The feature is useful"
s.com/
Helped-by: Jonathan Nieder
Helped-by: Junio C Hamano
Signed-off-by: Ævar Arnfjörð Bjarmason
---
On Wed, Jul 25 2018, Junio C Hamano wrote:
> Jonathan Nieder writes:
> [...]
> All interesting ideas and good suggestions. I'll leave 2/2 in the
> mail archive and take only 1/2 for
On Wed, Jul 25 2018, Daniel Baumann wrote:
> the attached patch removes a superfluous tab indentation in the
> interactive git-rebase messages.
>
> It would be nice to get rid of this to avoid visual disturbance with
> whitespace highlighting editors.
The code you're modifying doesn't exist in
On Wed, Jul 25 2018, Luke Diamand wrote:
> On 23 July 2018 at 12:27, Chen Bin wrote:
>> Hook pre-p4-submit is executed before git-p4 actually submits code.
>> If the hook exits with non-zero value, submit process will abort.
>
>
> Looks good to me - could you add some documentation please
>
have been worthy
of including in this changelog (but weren't). Instead of amending it
to include these, just note that future changes will be noted in the
log.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/technical/hash-function-transition.txt | 6 ++
1 file changed, 6 insertion
b18...@genre.crustytoothpaste.net/
2.
https://public-inbox.org/git/ca+55afwse9bf8e0hlk9pp3fvd5lavy5grdsv3fbntgzekja...@mail.gmail.com/
3. https://public-inbox.org/git/xmqqzhygwd5o....@gitster-ct.c.googlers.com/
Signed-off-by: Ævar Arnfjörð Bjarmason
---
.../technical/hash-function-transition.txt| 186 +-
1 file
t; to choose", but if we picked SHA-256 now, that would not be a choice
> that Brian has to later justify for choosing against everybody
> else's wishes, which makes it the best choice ;-)
Looks like it's settled then. I thought I'd do the grunt work of
updating the relevant documentatio
On Fri, Jul 20 2018, brian m. carlson wrote:
> On Mon, Jun 11, 2018 at 12:29:42PM -0700, Jonathan Nieder wrote:
>> My understanding of the discussion so far:
>>
>> Keccak team encourages us[1] to consider a variant like K12 instead of
>> SHA3.
>>
>> AGL explains[2] that the algorithms
On Sat, Jul 21 2018, Beat Bolli wrote:
> In the interest of code hygiene, make it easier to compile Git with the
> flag -pedantic.
>
> Pure pedantic compilation results in one warning per use of the
> translation macro `N_`, therefore also disable the parenthesising of
> i18n strings with
On Thu, Jul 19 2018, Jeff King wrote:
> Since this use of strncpy was verified by manual inspection
> and since it doesn't trigger the automated ban-list, we're
> better off leaving it to keep our divergence from glibc
> minimal.
FWIW it's s/glibc/gawk/. It's originally from glibc, but gawk
On Thu, Jul 19 2018, Basin Ilya wrote:
> Hi.
>
> I have two github accounts, one is for my organization and I want git to
> automatically choose the correct ssh `IdentityFile` based on the clone URL:
>
> g...@github.com:other/publicrepo.git
>~/.ssh/id_rsa
>
On Thu, Jul 19 2018, Timothy Rice wrote:
>> How did you come up with this "./" syntax?
>
> It is a Unix thing: "./" or just "." refers to the current directory.
>
> When calling scripts or programs in the current directory from a Unix
> command line, it is required to refer to them as, say,
On Tue, Jul 17 2018, Jeff King wrote:
> On Tue, Jul 17, 2018 at 10:59:50AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> That doesn't make sense to me. Just because git itself is happily
>> ignoring the exit code I don't think that should mean there shouldn't be
>> a m
On Tue, Jul 17 2018, Jonathan Nieder wrote:
> Hi Ævar,
>
> Ævar Arnfjörð Bjarmason wrote:
>> On Tue, Jul 17 2018, Jonathan Nieder wrote:
>
>>> That suggests a possible improvement. If all callers should be
>>> ignoring the exit code, can we
On Tue, Jul 17 2018, J. Paul Reed wrote:
> Hey Git Devs,
>
> I have a bit of an odd question: do git clone/checkout operations have a
> deterministic ordering?
>
> That is: are files guaranteed to be laid down onto disk in any specific
> (and deterministic) order as a clone and/or checkout
On Tue, Jul 17 2018, Jonathan Nieder wrote:
> Hi,
>
> Jeff King wrote:
>> On Mon, Jul 16, 2018 at 03:56:39PM -0700, Jonathan Nieder wrote:
>
>>> The calling command in the motivating example is Android's "repo" tool:
>>>
>>> bare_git.gc('--auto')
>>>
>>> from
On Sat, Jul 07 2018, Linus Torvalds wrote:
I really like where this is going in general. Having a "human" format
would be great.
> For really recent dates (same day), use the relative date stamp, while
> for old dates (year doesn't match), don't bother with time and timezone.
> [...]
> Once
kely case is that we have an
> unborn HEAD, in which case the empty tree comparison is
> the right thing)
>
> - this matches how other code, like "git diff", behaves
>
> While we're thinking about it, let's add an assertion to
> run_diff_index(). It should al
This segfaults, but should print an error instead, have a repo with a
corrupt HEAD:
(
rm -rf /tmp/git &&
git clone --single-branch --branch todo g...@github.com:git/git.git
/tmp/git &&
echo
>/tmp/git/.git/refs/heads/todo &&
On Tue, Jul 3, 2018 at 3:36 PM, Jeff King wrote:
> On Mon, Jul 02, 2018 at 01:15:19PM -0700, Jeremy Huddleston Sequoia wrote:
>
>> > I hope that maybe they're also interested in reducing the overall
>> > diff between upstream Git and what ships with XCode. Last time I
>> > looked (which was
On Tue, Jul 10, 2018 at 1:16 PM, 周应天 wrote:
> Hi,
> I’m using following command to do some search work:
> git log --all -G 'some regexp' -p — path/to/my/file.
> But the output could miss some commit. (For example, I grep a little piece of
> code from a commit diff
On Fri, Jun 29 2018, Mike Hommey wrote:
> On Sat, Jun 30, 2018 at 12:10:24AM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, Jun 29 2018, Mike Hommey wrote:
>>
>> > I noticed some slowness when fast-importing data from the Firefox mercurial
>> > re
On Fri, Jun 29 2018, Mike Hommey wrote:
> I noticed some slowness when fast-importing data from the Firefox mercurial
> repository, where fast-import spends more than 5 minutes importing ~2000
> revisions of one particular file. I reduced a testcase while still
> using real data. One could
On Thu, Jun 28 2018, Junio C Hamano wrote:
> The tip of 'next' has been rewound and it currently has only 4
> topics. Quite a many topics are cooking in 'pu' and need to be
> sifted into good bins (for 'next') and the remainder. Help is
> appreciated in that area ;-)
Per my
On Tue, Jun 26, 2018 at 12:47 AM, Junio C Hamano wrote:
Happy 2.18.0 everyone!
> * ab/fetch-tags-noclobber (2018-05-16) 9 commits
> - fixup! push tests: assert re-pushing annotated tags
> - fetch: stop clobbering existing tags without --force
> - fetch tests: add a test clobbering tag
On Thu, Jun 14 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> On Wed, Jun 13 2018, Junio C Hamano wrote:
>>
>>> Ævar Arnfjörð Bjarmason writes:
>>>
>>>> E.g. here's a breakdown of my dotfiles repo:
>>>>
>
On Wed, Jun 13 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> E.g. here's a breakdown of my dotfiles repo:
>>
>> $ git -c core.abbrev=4 log --pretty=format:%h|perl -nE 'chomp;say
>> length'|sort|uniq -c|sort -nr
>> 784
On Tue, Jun 12 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Change the core.abbrev config variable and the corresponding --abbrev
>> command-line option to support relative values such as +1 or -1.
>>
>> Before Linus's e6c587c733 (
;87efhfvxzu@evledraar.gmail.com>
(https://public-inbox.org/git/87efhfvxzu@evledraar.gmail.com/)
2.
(https://public-inbox.org/git/cahqjxre8okskcck1aphahcclzhox+tzi8nnu2ra74rerx8s...@mail.gmail.com/)
Signed-off-by: Ævar Arnfjörð Bjarmason
---
contrib/credential/netrc/git-credenti
On Mon, Jun 11 2018, Linus Torvalds wrote:
> On Mon, Jun 11, 2018 at 12:29 PM Jonathan Nieder wrote:
>>
>> Yves Orton and Linus Torvalds prefer[5] SHA3 over SHA2 because of how
>> it is constructed.
>
> Yeah, I really think that it's a mistake to switch to something that
> has the same problem
es of write and
> executable permissions are performed.
>
> The in-place checkout is therefore optional. It could be enabled by Git
> installers on Windows, where umask is irrelevant.
>
> Signed-off-by: Clemens Buchacher
> Reviewed-by: Orgad Shaneh
> Reviewed-by: "brian m. carlson&qu
On Sat, Jun 09 2018, brian m. carlson wrote:
[Expanding the CC list to what we had in the last "what hash" thread[1]
last year].
> == Discussion of Candidates
>
> I've implemented and tested the following algorithms, all of which are
> 256-bit (in alphabetical order):
>
> * BLAKE2b (libb2)
> *
On Sun, Jun 10 2018, Clemens Buchacher wrote:
> When replacing files with new content during checkout, we do not write
> to them in-place. Instead we unlink and re-create the files in order to
> let the system figure out ownership and permissions for the new file,
> taking umask into account.
>
On Sun, Jun 10, 2018 at 2:04 AM, 陶青云 wrote:
> Sorry to intrude, but I can't send a patch to the maillist using
> qq.com and 163.com SMTP server.
Do you have a git with this patch: http://github.com/git/git/commit/5453b83bdf ?
It worked for 赵小强 on 163.com, maybe it'll work for you too.
On Sun, Jun 10 2018, Todd Zullinger wrote:
>> I added 'use autodie;' without realizing it had external dependencies.
>> According to the documentation
>> http://perldoc.perl.org/autodie.html
>> it's a pragma since perl 5.10.1
>> Removing 'use autodie;' should be fine: it's not critical.
>
> I
On Sat, Jun 09 2018, brian m. carlson wrote:
> Since there's been a lot of questions recently about the state of the
> NewHash work, I thought I'd send out a summary.
Thanks for all your work on this.
> I know that we have long tried to avoid discussing the specific
> algorithm to use, in
On Sat, Jun 09 2018, Elijah Newren wrote:
> On Sat, Jun 9, 2018 at 12:01 PM, Christoph Böhmwalder
> wrote:
>> Hi,
>>
>> Since this is a use case that actually comes up quite often in
>> day-to-day use, especially among git beginners, I was wondering: is
>> there a specific reason why a command
On Sat, Jun 09 2018, Martin Ågren wrote:
> On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote:
>> The "log" family of commands does its own parsing for --abbrev in
>> revision.c, so having dedicated tests for it makes sense.
>
>> +for i in $(test_seq 4
On Sat, Jun 09 2018, Duy Nguyen wrote:
> On Sat, Jun 9, 2018 at 12:22 AM Ævar Arnfjörð Bjarmason
> wrote:
>>
>>
>> On Fri, Jun 08 2018, Johannes Sixt wrote:
>>
>> > Am 08.06.2018 um 18:00 schrieb Thomas Braun:
>> >> I for my part would much r
On Fri, Jun 08 2018, Jonathan Nieder wrote:
> Separate from that legal context, though, I think it's an interesting
> feature request. I don't think it goes far enough: I would like a way
> to erase arbitrary information from the history in a repository. For
> example, if I accidentally check
On Fri, Jun 08 2018, Peter Backes wrote:
> On Fri, Jun 08, 2018 at 10:13:20AM +0200, Ævar Arnfjörð Bjarmason wrote:
>> Can you walk us through how anyone would be expected to fork (as create
>> a new project, not the github-ism) existing projects under such a
>> regiment?
Add tests showing how "git-blame" behaves. As noted in an earlier
change there's a behavior difference between core.abbrev=40 and
--abbrev=40.
Let's also assert that neither way of changing the abbreviation length
modifies the porcelain output.
Signed-off-by: Ævar Arnfjörð Bjarmas
-inbox.org/git/87lgbsz61p@evledraar.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/config.txt| 43 ++
cache.h | 1 +
config.c| 7 +
environment.c | 1
In ac53fe8601 ("sha1_name: convert uses of 40 to GIT_SHA1_HEXSZ",
2017-07-13) the code this is validating user input for in
find_unique_abbrev_r() was converted to GIT_SHA1_HEXSZ, but the
corresponding validation codepath wasn't change. Let's do that.
Signed-off-by: Ævar Arnfjörð
The "log" family of commands does its own parsing for --abbrev in
revision.c, so having dedicated tests for it makes sense.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t0014-abbrev.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t0014-abbrev.sh b/t/t0014-abbre
w the format has changed
over time will help those users avoid nasty surprises.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/git-blame.txt | 8 +++-
builtin/blame.c | 2 ++
t/t0014-abbrev.sh | 7 ++-
3 files changed, 15 insertions(+), 2 deletions(-)
diff -
Adjust this code that'll be modified in a subsequent change to have
more than one line per branch to use braces per the CodingGuidelines,
this makes the later change easier to understand.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
diff.c | 5 +++--
revision.c | 5 +++--
2 files changed, 6
In a later change I mean to make values like -1 and +1 mean something
different, but right now they're implicitly parsed. Let's test for the
current behavior before changing it.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t0014-abbrev.sh | 131 --
1
The only thing out of the ordinary with git-describe is the --abbrev=0
special-case.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t0014-abbrev.sh | 25 +
1 file changed, 25 insertions(+)
diff --git a/t/t0014-abbrev.sh b/t/t0014-abbrev.sh
index d8b060d922..645bcca1d1
carefully,
but let's make this clearer by explicitly stating this limitation of
--abbrev as it relates to git-blame, it is not shared by any other
command that supports core.abbrev or --abbrev.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/git-blame.txt | 5 +
1 file changed, 5 insertion
The "git-{ls-files,ls-tree,show-ref}" commands all have in common that
the core.abbrev variable is ignored, and only --abbrev works. This is
intentional since these are all plumbing.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t0014-abbrev.sh | 32 ++
Adjust this code that'll be modified in a subsequent change to have
more than one line per branch to use braces per the CodingGuidelines,
this makes the later change easier to understand.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
parse-options-cb.c | 5 +++--
1 file changed, 3 insertions(+), 2
The "diff" family of commands does its own parsing for --abbrev in
diff.c, so having dedicated tests for it makes sense.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t0014-abbrev.sh | 31 +++
1 file changed, 31 insertions(+)
diff --git a/t/t0014-abbrev.sh
Adjust this code that'll be modified in a subsequent change to have
more than one line per branch to use braces per the CodingGuidelines,
this makes the later change easier to understand.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Signed-off-by: Ævar Arnfjörð Bjarmason
---
diff.c| 5 -
revision.c| 5 -
t/t0014-abbrev.sh | 10 +-
3 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/diff.c b/diff.c
index 136d44b455..75935322f1 100644
--- a/diff.c
+++ b/diff.c
@@ -4801,7 +4801
For no good reason the --abbrev= command-line option was less strict
than the core.abbrev config option, which came down to the latter
using git_config_int() which rejects an empty string, but the rest of
the parsing using strtoul() which will convert it to 0.
Signed-off-by: Ævar Arnfjörð
llow users to
consistently opt-in for either a higher or lower probability of
collision, without needing to hardcode a given numeric value like
"10", which would be overkill on some repositories, and far to small
on others.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/co
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t0014-abbrev.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t0014-abbrev.sh b/t/t0014-abbrev.sh
index 934c54a96b..d8b060d922 100755
--- a/t/t0014-abbrev.sh
+++ b/t/t0014-abbrev.sh
@@ -168,4 +168,14 @@ do
"
done
+
in later patches when adding more tests.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/README | 4
t/t6006-rev-list-format.sh | 6 ++
t/test-lib-functions.sh| 23 +++
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/t/README b/t/RE
mands have their own parsing for it in diff.c and
revision.c, respectively. Those were added earlier in
47dd0d595d ("diff: --abbrev option", 2005-12-13) and 508d9e372e ("Fix
"--abbrev=xyz" for revision listing", 2006-05-27), although note that
sometimes diff goes via
stop somewhere to make this
digestible).
1. https://public-inbox.org/git/20180108102029.ga21...@sigill.intra.peff.net/
2. https://public-inbox.org/git/20180606102719.27145-1-ava...@gmail.com/
Ævar Arnfjörð Bjarmason (20):
t/README: clarify the description of test_line_count
test library:
Referring to the "length" of a file is ambiguous. We mean the number
of lines, so let's say that.
Changes the description added in fb3340a6a7 ("test-lib: introduce
test_line_count to measure files", 2010-10-31).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/README | 2 +
On Fri, Jun 08 2018, Johannes Sixt wrote:
> Am 08.06.2018 um 18:00 schrieb Thomas Braun:
>> I for my part would much rather prefer that to be a compile time
>> option so that I don't need to check on every git update on windows
>> if this is now enabled or not.
>
> This exactly my concern,
On Thu, Jun 07 2018, g...@jeffhostetler.com wrote:
> From: Jeff Hostetler
>
> Create design documentation to describe the telemetry feature.
>
> Signed-off-by: Jeff Hostetler
> ---
> Documentation/technical/telemetry.txt | 475
> ++
> 1 file changed, 475
On Thu, Jun 07 2018, Johannes Sixt wrote:
> Am 07.06.2018 um 16:53 schrieb g...@jeffhostetler.com:
>> From: Jeff Hostetler
>>
>> I've been working to add code to Git to optionally collect telemetry data.
>> The goal is to be able to collect performance data from Git commands and
>> allow it to
On Fri, Jun 08 2018, Peter Backes wrote:
> On Thu, Jun 07, 2018 at 10:53:13PM -0400, Theodore Y. Ts'o wrote:
>> The problem is you've left undefined who is "you"? With an open
>> source project, anyone who has contributed to open source project has
>> a copyright interest. That hobbyist in
On Thu, Jun 07 2018, Matthew Wilcox wrote:
> On Thu, Jun 07, 2018 at 09:09:25PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> On Thu, Jun 07 2018, Matthew Wilcox wrote:
>> > If the first atom of a regex is a bracket expression with an inverted
>> > range,
>> >
On Thu, Jun 07 2018, Matthew Wilcox wrote:
> If the first atom of a regex is a bracket expression with an inverted range,
> git grep is very slow.
>
> $ time git grep 'struct_size' >/dev/null
>
> real 0m0.368s
> user 0m0.563s
> sys 0m0.453s
>
> $ time git grep '[^t]truct_size' >/dev/null
>
On Thu, Jun 07 2018, Derrick Stolee wrote:
> To test the performance in this situation, I created a
> script that organizes the Linux repository in a similar
> fashion. I split the commit history into 50 parts by
> creating branches on every 10,000 commits of the first-
> parent history. Then,
On Wed, Jun 06 2018, Timothy Rice wrote:
>> It does seem like something which could be noted in the git
>> rm docs. Perhaps you'd care to take a stab at a patch to
>> add a note to Documentation/git-rm.txt Thomas? Maybe a note
>> at the end of the DISCUSSION section?
>
> That same
On Wed, Jun 06 2018, Thomas Fischer wrote:
> I agree that the entire chain of empty directories should not be
> tracked, as git tracks content, not files.
>
> However, when I run 'rm path/to/some/file', I expect path/to/some/ to
> still exist.
>
> Similarly, when I run 'git rm
On Wed, Jun 06 2018, Brandon Williams wrote:
> On 06/05, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Tue, Jun 05 2018, Brandon Williams wrote:
>>
>> > +uploadpack.allowRefInWant::
>> > + If this option is set, `upload-pack` will support the `ref-in-want`
&g
On Wed, Jun 06 2018, Derrick Stolee wrote:
> On 6/6/2018 8:11 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Wed, Jun 06 2018, Derrick Stolee wrote:
>>
>>> Signed-off-by: Derrick Stolee
>>> ---
>>> builtin/commit-graph.c | 39 +-
On Wed, Jun 06 2018, Derrick Stolee wrote:
> diff --git a/t/t5318-commit-graph.sh b/t/t5318-commit-graph.sh
> index c0c1ff09b9..846396665e 100755
> --- a/t/t5318-commit-graph.sh
> +++ b/t/t5318-commit-graph.sh
> @@ -249,6 +249,15 @@ test_expect_success 'git commit-graph verify' '
>
>
On Wed, Jun 06 2018, Derrick Stolee wrote:
> Signed-off-by: Derrick Stolee
> ---
> builtin/commit-graph.c | 39 +--
> commit-graph.c | 15 +++
> commit-graph.h | 7 +++
> 3 files changed, 23 insertions(+), 38 deletions(-)
>
On Mon, Jun 04 2018, Derrick Stolee wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 11f027194e..d2eb3c8e9b 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -900,7 +900,8 @@ the `GIT_NOTES_REF` environment variable. See
>
On Mon, Jun 04 2018, Derrick Stolee wrote:
> + prepare_alt_odb();
> + for (alt = alt_odb_list; alt; alt = alt->next) {
> + verify_argv[2] = "--object-dir";
> + verify_argv[3] = alt->path;
> + if
On Wed, Jun 06 2018, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Jan 08 2018, Derrick Stolee wrote:
>
>> On 1/7/2018 5:42 PM, Ævar Arnfjörð Bjarmason wrote:
>>>
>>> On Sun, Jan 07 2018, Derrick Stolee jotted:
>>>
>>>> git log --oneline --raw
or picking a trade-off between performance, and the odds that
future or remote (or current and local) short SHA-1 will be ambiguous.
1. https://public-inbox.org/git/20180107181459.222909-1-dsto...@microsoft.com/
2. https://public-inbox.org/git/87lgbsz61p@evledraar.gmail.com/
Signed-off-by: Æva
Adjust this code that'll be modified in a subsequent change per the
CodingGuidelines.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index fbbf0f8e9f..12f762ad92 100644
--- a/config.c
+++ b/config.c
On Mon, Jan 08 2018, Derrick Stolee wrote:
> On 1/7/2018 5:42 PM, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Sun, Jan 07 2018, Derrick Stolee jotted:
>>
>>> git log --oneline --raw --parents
>>>
>>> Num Pa
On Tue, Jun 05 2018, Brandon Williams wrote:
> Add a link to gitsubmodules(7) under the `submodule.active` entry in
> git-config(1).
Did you mean to change either the subject or content of this patch? Your
subject says gitsubmodules(7), but you link to git-submodule(1).
On Tue, Jun 05 2018, Brandon Williams wrote:
> +uploadpack.allowRefInWant::
> + If this option is set, `upload-pack` will support the `ref-in-want`
> + feature of the protocol version 2 `fetch` command.
> +
I think it makes sense to elaborate a bit on what this is for. Having
read this
e provoked by calling
`valid_fetch_refspec(":*")`.
Zero the struct, as is done in other users of `struct refspec_item` by
using the refspec_item_init() initialization function.
Signed-off-by: Martin Ågren
Signed-off-by: Ævar Arnfjörð Bjarmason
---
refspec.c | 2 +-
1 file changed, 1 inse
sign-off, but otherwise it's the same.
Martin Ågren (1):
refspec: initalize `refspec_item` in `valid_fetch_refspec()`
Ævar Arnfjörð Bjarmason (2):
refspec: s/refspec_item_init/&_or_die/g
refspec: add back a refspec_item_init() function
builtin/clone.c | 2 +-
builtin/pull.c | 2 +-
refspec.
ing future use of it, let's make it
available to other users.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
refspec.c | 10 +++---
refspec.h | 2 ++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/refspec.c b/refspec.c
index 0fd392e96b..a35493e35e 100644
--- a/refspec.c
+++ b
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/clone.c | 2 +-
builtin/pull.c | 2 +-
refspec.c | 5 +++--
refspec.h | 3 ++-
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 99e73dae85..74a804f2e8 100644
--- a/builtin/clone.c
+++
On Mon, Jun 4, 2018 at 6:52 PM, Derrick Stolee wrote:
> Thanks for the feedback on v3. There were several small cleanups, but
> perhaps the biggest change is the addition of "commit-graph: use
> string-list API for input" which makes "commit-graph: add '--reachable'
> option" much simpler.
Do
t;checkout", failed or otherwise.
Then if we ever run into this sort of regression, either in the
existing code or with a new feature, we'll know.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t2024-checkout-dwim.sh | 29 +
1 file changed, 29 insertions(+)
diff -
Add an *_INIT macro for the tracking_name_data similar to what exists
elsewhere in the codebase, e.g. OID_ARRAY_INIT in sha1-array.h. This
will make it more idiomatic in later changes to add more fields to the
struct & its initialization macro.
Signed-off-by: Ævar Arnfjörð Bjarm
Pass the previously added "num_matches" struct value up to the callers
of unique_tracking_name(). This will allow callers to optionally print
better error messages in a later change.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/checkout.c | 10 +++---
builtin/workt
"", 2009-10-18) which introduced this DWIM feature
to begin with, and 4e85333197 ("worktree: make add
dwim", 2017-11-26) which added it to git-worktree.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/config.txt | 21 -
Documentation/git-check
There is no point in doing this right now, but in later change the
"ret" variable will be inspected. This change makes that meaningful
change smaller.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/checkout.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
The line was too long already, and will be longer still when a later
change adds another argument.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
checkout.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/checkout.h b/checkout.h
index 9980711179..4cd4cd1c23 100644
etermining whether that's the
case could easily change due to future changes in the checkout logic.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/config.txt | 7 +++
advice.c | 2 ++
advice.h | 1 +
builtin/checkout.c | 13 +
t/t2024
Internally track how many matches we find in the check_tracking_name()
callback. Nothing uses this now, but it will be made use of in a later
change.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
checkout.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/checkout.c b
: introduce an *_INIT macro
4: 72ddaeddd3 ! 4: 34f3b67f9b checkout.c: change "unique" member to
"num_matches"
@@ -1,6 +1,6 @@
Author: Ævar Arnfjörð Bjarmason
-checkout.c]: change "unique" member to "num_matches"
+checkout.c
On Tue, Jun 05 2018, Tim Friske wrote:
> Hi Everyone,
>
> ten days ago I asked on https://unix.stackexchange.com/ why Git is not
> creating a merge commit when merging a signed/annotated tag. Does someone has
> an answer to my question
>
On Mon, Jun 04 2018, Martin Ågren wrote:
> We allocate a `struct refspec_item` on the stack without initializing
> it. In particular, its `dst` and `src` members will contain some random
> data from the stack. When we later call `refspec_item_clear()`, it will
> call `free()` on those pointers.
On Sun, Jun 03 2018, Peter Backes wrote:
> On Sun, Jun 03, 2018 at 02:59:26PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> I'm not trying to be selfish, I'm just trying to counter your literal
>> reading of the law with a comment of "it'll depend".
>>
>> J
701 - 800 of 2740 matches
Mail list logo
