On Wed, Feb 7, 2018 at 6:43 PM, Stefan Beller wrote:
> [...]
> Error out for now instead of potentially confusing the user.
> As 5453b83bdf (send-email: --batch-size to work around some SMTP
> server limit, 2017-05-21) lays out, we rather want to not have this
> interface anyway and would rather w
Please ignore !
v3 with the nits fixed was picked by Junio
Le 07/02/2018 à 17:55, Nicolas Morey-Chaisemartin a écrit :
> Add a --edit option whichs allows modifying the messages provided by -m or -F,
> the same way git commit --edit does.
>
> Signed-off-by: Nicolas Morey-Chaisemartin
> ---
>
> F
On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote:
> > 1. You have $LESS in your environment (without "F") on one platform
> > but not the other.
>
> I think that's it. On my system LESS is defined to "-R".
>
> This opens the pager:
>
> $ echo "TEST" | less
>
> This doe
On Mon, Feb 05, 2018 at 02:56:19PM -0500, Ben Peart wrote:
> diff --git a/dir.c b/dir.c
> index 7c4b45e30e..da93374f0c 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -2297,7 +2297,8 @@ int read_directory(struct dir_struct *dir, struct
> index_state *istate,
>dir->untracke
Hi,
I have a merge conflict on a file and the git diff output looks wrong to me.
Here's how to recreate:
On branch 'dev' add/commit a file (called README.md) with the contents
( '--' used to delimit the file, not included in the content):
---
This is my default readme
---
On branc
> On 08 Feb 2018, at 09:50, Jeff King wrote:
>
> On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote:
>
>>> 1. You have $LESS in your environment (without "F") on one platform
>>>but not the other.
>>
>> I think that's it. On my system LESS is defined to "-R".
>>
>> This opens
On Thu, Feb 08, 2018 at 10:51:57AM +, Nick O'Leary wrote:
> $ git diff README.md
> diff --cc README.md
> index 61d78b2,620d806..000
> --- a/README.md
> +++ b/README.md
> @@@ -1,7 -1,1 +1,11 @@@
> -This is my default readme
> ++<<< HEAD
> +merged-history-test
> +===
>
> On 08 Feb 2018, at 12:13, Lars Schneider wrote:
>
>
>> On 08 Feb 2018, at 09:50, Jeff King wrote:
>>
>> On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote:
>>
1. You have $LESS in your environment (without "F") on one platform
but not the other.
>>>
>>> I think tha
Ah, the whitespace that was added to enable the >>> markers to be
added... that makes sense.
Which means the output is correct and some assumptions my code makes
about the format of the Combined Diff are wrong.
Thanks!
Nick
On 8 February 2018 at 11:25, Jeff King wrote:
> On Thu, Feb 08, 2018
On Thu, Feb 8, 2018 at 2:23 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> I posted a proof of concept a while back [1]. This is the full version.
>>
>> This series lets "git" binary help git-completion.bash to complete
>> -- so that when a new option is added, we don't have to up
Hi Junio,
On Wed, 7 Feb 2018, Junio C Hamano wrote:
> Øyvind Rønningstad writes:
>
> >> So no, I do not think that --recreate-merges --first-parent is a good
> > idea
> >> at all. Unless you try to do that non-interactively only, *and
> > disallow it
> >> in interactive mode*.
>
> Correct. If
On Mon, Feb 5, 2018 at 1:45 PM, Junio C Hamano wrote:
> Given that all references to this shell function seem to do
>
> sometree=$(toptree_for_commit $something)
>
> and then $sometree is used as if it were a tree object name, I can
> understand why the lack of --no-show-signature in the o
I have Linux Mint and its terminal besides usual completion (add file
name when type first letter and press tab) also can complete git
parameters. How is doing this? Bash knows git or bash has special
interface to completion and git uses it?
I want in my Linux program apply this mechanism.
On Thu, Feb 8, 2018 at 9:03 AM, Andrzej wrote:
> I have Linux Mint and its terminal besides usual completion (add file name
> when type first letter and press tab) also can complete git parameters. How
> is doing this? Bash knows git or bash has special interface to completion
> and git uses it?
>
I'll probably submit docs for this eventually, but the docs in my
--prune-tags series were already hard enough to review. Try running this
(
rm -rf /tmp/git &&
git clone https://github.com/git/git /tmp/git &&
cd /tmp/git >/dev/null &&
du -sh .git &&
git
Leo Gaspard wrote:
> That said, I just came upon [1] (esp. the description [2] and the patch
> [3]), and wondered: it looks like the patch was abandoned midway in
> favor of a hook refactoring. Would you happen to know whether the hook
> refactoring eventually took place, and/or whether this patch
On Mon, Feb 5, 2018 at 3:51 PM, Stefan Beller wrote:
> This series moves a lot of global state into the repository struct.
> It applies on top of 2512f15446149235156528dafbe75930c712b29e (2.16.0)
> It can be found at https://github.com/stefanbeller/git/tree/object-store
>
> Motivation for this ser
The second 'test_i18ngrep' invocation in the test 'curl redirects
respect whitelist' is missing its filename parameter. This has
remained unnoticed since its introduction in f4113cac0 (http: limit
redirection to protocol-whitelist, 2015-09-22), because it would only
cause the test to fail if Git w
The primary purpose of 't6022-merge-rename.sh' is to test 'git merge',
but one of the tests runs it upstream of a pipe, hiding its exit code.
Consequently, the test could continue even if 'git merge' exited with
error.
Use an intermediate file between 'git merge' and 'test_i18ngrep' to
catch a pot
Redirecting 'test_i18ngrep's standard input from a file will interfere
with the linting that will be added in a later patch.
Signed-off-by: SZEDER Gábor
---
t/t5536-fetch-conflicts.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t5536-fetch-conflicts.sh b/t/t5536-fetch-c
Some of the previous patches in this series fixed bogus
'test_i18ngrep' invocations:
- Two invocations where the tested git command's standard output is
directly piped into 'test_i18ngrep'. While convenient, this is an
antipattern, because the pipe hides the git command's exit code,
The test 'push --no-progress silences progress but not status' runs
'test_i18ngrep' without specifying a filename parameter. This has
remained unnoticed since its introduction in e304aeba2 (t5541: test
more combinations of --progress, 2012-05-01), because that
'test_i18ngrep' is supposed to check
The primary purpose of three tests in 't4001-diff-rename.sh' is to
check rename detection in 'git status', but all three do so by running
'git status' upstream of a pipe, hiding its exit code. Consequently,
the test could continue even if 'git status' exited with error.
Use an intermediate file b
This is the second version of 'sg/test-i18ngrep'.
To recap, this patch series fixes a couple of bogus 'test_i18ngrep'
invocations (patches 1-4), tries to prevent similar bugs in the future
(patch 8), teaches 'test_i18ngrep' to be more informative on failure
(patch 9), and a bit of cleanups in betw
Both 'test_i18ncmp' and 'test_i18ngrep' helper functions are supposed
to be called from our test scripts, so they should be in
'test-lib-functions.sh'.
Signed-off-by: SZEDER Gábor
---
t/test-lib-functions.sh | 26 ++
t/test-lib.sh | 26 --
When 'test_i18ngrep' can't find the expected pattern, it exits
completely silently; when its negated form does find the pattern that
shouldn't be there, it prints the matching line(s) but otherwise exits
without any error message. This leaves the developer puzzled about
what could have gone wrong.
One of the tests in 't5510-fetch.sh' checks the output of 'git fetch'
using 'test_i18ngrep', and while doing so it prefilters the output
with 'grep' before piping the result into 'test_i18ngrep'.
This prefiltering is unnecessary, with the appropriate pattern
'test_i18ngrep' can do it all by itself
Trivially refactor an assignment to make a subsequent patch
smaller. The "ref_nr" variable is initialized to 0 earlier, just as
"j" is, and "j" is only incremented in that loop, so this change isn't
a logic error.
This change makes a subsequent change which splits the incrementing of
"ref_nr" into
Stop redundantly NULL-ing the last element of the refs structure,
which was retrieved via calloc(), and is thus guaranteed to be
pre-NULL'd.
This code dates back to b888d61c83 ("Make fetch a builtin",
2007-09-10), where wasn't any reason to do this back then either, it's
just boilerplate left over
As noted in my 87h8quytmq@evledraar.gmail.com there was a bug I
noticed in v3 where it would segfault on some git-fetch invocations,
but there were not tests anywhere that caught that.
So in addition to fixing that issue, this fleshens out the testing
being set up as part of this series so we'
Access the "remote" variable passed to the fetch_one() directly rather
than through the gtransport wrapper struct constructed in this
function for other purposes.
This makes the code more readable, as it's now obvious that the remote
struct doesn't somehow get munged by the prepare_transport() fun
On Thu, Feb 08, 2018 at 12:27:07PM +0100, Lars Schneider wrote:
>
> > On 08 Feb 2018, at 12:13, Lars Schneider wrote:
> >
> >
> >> On 08 Feb 2018, at 09:50, Jeff King wrote:
> >>
> >> On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote:
> >>
> 1. You have $LESS in your enviro
In a subsequent commit this function will learn to test for tag
pruning, prepare for that by making space for more variables, and
making it clear that "expected" here refers to branches.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t5510-fetch.sh | 9 ++---
1 file changed, 6 insertions(+), 3
Add a tag to be deleted to the fetch --prune tests. The tag is always
kept for now, which is the expected behavior, but now I can add a test
for tag pruning in a later commit.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t5510-fetch.sh | 93 ---
Make the new --prune-tags option work properly when git-fetch is
invoked with a parameter instead of a
parameter.
This change is split off from the introduction of --prune-tags due to
the relative complexity of munging the incoming argv, which is easier
to review as a separate change.
Signed-of
Add a --fetch-prune option to git-fetch, along with fetch.pruneTags
config option. This allows for doing any of:
git fetch -p -P
git fetch --prune --prune-tags
git fetch -p -P origin
git fetch --prune --prune-tags origin
Or simply:
git config fetch.prune true &&
git confi
Amend the documentation for fetch.prune, fetch..prune and
--prune to link to the recently added PRUNING section.
I'd have liked to link directly to it with "<>" from
fetch-options.txt, since it's included in git-fetch.txt (git-pull.txt
also includes it, but doesn't include that option). However ma
The fetch.pruneTags configuration doesn't exist yet, but will be added
in a subsequent commit. Since testing for it requires adding new
parameters to the test_configured_prune function it's easier to review
this patch first to assert that no functional changes are introduced
yet.
Signed-off-by: Æv
When a remote URL is supplied on the command-line the internals of the
fetch are different, in particular the code in get_ref_map(). An
earlier version of the subsequent fetch.pruneTags patch hid a segfault
because the difference wasn't tested for.
Now all the tests are run as both of the variants
Add a new section to canonically explain how remote reference pruning
works, and how users should be careful about using it in conjunction
with tag refspecs in particular.
A subsequent commit will update the git-remote documentation to refer
to this section, and details the motivation for writing
Expand a compact case/esac statement for a later change that'll add
more logic to the body of the "*" case. This is a whitespace-only
change.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t5510-fetch.sh | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/t/t5510-fetch.sh b
The "git remote prune " command uses the same machinery as "git
fetch --prune", and shares all the same caveats, but its
documentation has suggested that it'll just "delete stale
remote-tracking branches under ".
This isn't true, and hasn't been true since at least v1.8.5.6 (the
oldest version I
If the $cmdline variable contains arguments with spaces they won't be
interpolated correctly, since the body of the test is single quoted,
and because test-lib.sh does its own eval().
This will be used in a subsequent commit to pass arguments that need
to be quoted to git-fetch, i.e. a file:// pat
Add a macro with the refspec string "refs/tags/*:refs/tags/*". There's
been a pre-defined struct version of this since e0aaa29ff3 ("Have a
constant extern refspec for "--tags"", 2008-04-17), but nothing that
could be passed to e.g. add_fetch_refspec().
This will be used in subsequent commits to av
Add a test for the interaction between explicitly provided refspecs
and fetch.prune.
There's no point in adding this boilerplate to every combination of
unset/false/true, it's instructive and sufficient to show that no
matter if the variable is unset, false or true the refspec on the
command-line
Re-arrange the arguments to the test_configured_prune() function used
in this test to pass the arguments to --fetch last. A subsequent
change will test for more elaborate fetch arguments, including long
refspecs. It'll be more readable to be able to wrap those on a new
line of their own.
Signed-of
On Thu, Jan 11 2018, Ævar Arnfjörð Bjarmason jotted:
> I recently disabled gc.auto=0 and my nightly aggressive repack script on
> our big monorepo across our infra, relying instead on git gc --auto in
> the background to just do its thing.
>
> I didn't want users to wait for git-gc, and I'd writt
> On 08 Feb 2018, at 17:19, Kevin Daudt wrote:
>
> On Thu, Feb 08, 2018 at 12:27:07PM +0100, Lars Schneider wrote:
>>
>>> On 08 Feb 2018, at 12:13, Lars Schneider wrote:
>>>
>>>
On 08 Feb 2018, at 09:50, Jeff King wrote:
On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneid
On Thu, Feb 08, 2018 at 04:56:55PM +0100, SZEDER Gábor wrote:
> Prevent similar mistakes in the future by validating 'test_i18ngrep's
> parameters requiring that
>
> - The last parameter names an existing file to be read, effectively
> forbiding piping into 'test_i18ngrep'.
s/forbiding/for
On Thu, Feb 08, 2018 at 04:56:47PM +0100, SZEDER Gábor wrote:
> This is the second version of 'sg/test-i18ngrep'.
>
> To recap, this patch series fixes a couple of bogus 'test_i18ngrep'
> invocations (patches 1-4), tries to prevent similar bugs in the future
> (patch 8), teaches 'test_i18ngrep' t
On 02/08/2018 04:30 PM, Joey Hess wrote:
> Leo Gaspard wrote:
>> That said, I just came upon [1] (esp. the description [2] and the patch
>> [3]), and wondered: it looks like the patch was abandoned midway in
>> favor of a hook refactoring. Would you happen to know whether the hook
>> refactoring ev
On Wed, Feb 07, 2018 at 07:41:56PM -0500, Ben Peart wrote:
[]
> diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
> index b29d749bb7..219c96594c 100755
> --- a/t/t0050-filesystem.sh
> +++ b/t/t0050-filesystem.sh
> @@ -80,7 +80,17 @@ test_expect_success 'merge (case change)' '
> git
On 2/8/2018 12:21 PM, Torsten Bögershausen wrote:
On Wed, Feb 07, 2018 at 07:41:56PM -0500, Ben Peart wrote:
[]
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index b29d749bb7..219c96594c 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -80,7 +80,17 @@ test_expect
On Thu, 8 Feb 2018 02:56:14 +
"brian m. carlson" wrote:
> Existing trailers are extracted from the input message by looking for
> -a group of one or more lines that (i) are all trailers, or (ii) contains at
> -least one Git-generated or user-configured trailer and consists of at
> +a group
Ben Peart writes:
> Correct the pointer arithmetic in adjust_dirname_case() so that it calls
> find_dir_entry() with the correct string length. Previously passing in
> "dir1/foo" would pass a length of 6 instead of the correct 4. This resulted
> in
> find_dir_entry() never finding the entry an
On Thu, Feb 8, 2018 at 12:08 AM, Eric Sunshine wrote:
> On Wed, Feb 7, 2018 at 6:43 PM, Stefan Beller wrote:
>> [...]
>> Error out for now instead of potentially confusing the user.
>> As 5453b83bdf (send-email: --batch-size to work around some SMTP
>> server limit, 2017-05-21) lays out, we rathe
On Thu, Feb 08 2018, Ævar Arnfjörð Bjarmason jotted:
> As noted in my 87h8quytmq@evledraar.gmail.com there was a bug I
> noticed in v3 where it would segfault on some git-fetch invocations,
> but there were not tests anywhere that caught that.
...and of course this whole submission this time
Torsten Bögershausen writes:
> My personal favorite would be to spell out what we expect and run a diff.
> When it fails, we can see what fails, and the function would look
> like this:
I'd rather not to have the "sort" there; output from ls-files is
meant to be stable; passing it through sort w
Hello Dear Friend,
Greetings and how are you doing?
I want to know if you are kind to be my
partner in claiming the fund of $13.6
MillionUSD left by a late client. If you're
interested please Revert for more details.
You can visit the web for more details.
http://newswww.bbc.net.uk/2/hi/uk_news/en
Included here are a couple of fixes and cleanups for
handling NULL return values from 'packet_read_line'.
Jeff King (1):
correct error messages for NULL packet_read_line()
Jon Simons (1):
always check for NULL return from packet_read_line()
builtin/archive.c | 2 +-
fetch-pack.c | 4 ++
The packet_read_line() function will die if it sees any
protocol or socket errors. But it will return NULL for a
flush packet; some callers which are not expecting this may
dereference NULL if they get an unexpected flush. This would
involve the other side breaking protocol, but we should
flag the
From: Jeff King
The packet_read_line() function dies if it gets an
unexpected EOF. It only returns NULL if we get a flush
packet (or technically, a zero-length "0004" packet, but
nobody is supposed to send those, and they are
indistinguishable from a flush in this interface).
Let's correct error
On Thu, Feb 08, 2018 at 01:47:50PM -0500, Jon Simons wrote:
> The packet_read_line() function will die if it sees any
> protocol or socket errors. But it will return NULL for a
> flush packet; some callers which are not expecting this may
> dereference NULL if they get an unexpected flush. This wo
Hello, I’m very beginner and literally a grandma. Would like Tomatoes for my
Netgear X8 R8500 router. Very misleading netgear product saying OpenVPN and had
no idea about client or I would have to do all this stuff and the netgear
security vulnerabilities are horrid. Was told to shut it down. I
Correct the pointer arithmetic in adjust_dirname_case() so that it calls
find_dir_entry() with the correct string length. Previously passing in
"dir1/foo" would pass a length of 6 instead of the correct 4. This resulted in
find_dir_entry() never finding the entry and so the subsequent memcpy that
Ævar Arnfjörð Bjarmason writes:
> On Thu, Feb 08 2018, Ævar Arnfjörð Bjarmason jotted:
>
>> As noted in my 87h8quytmq@evledraar.gmail.com there was a bug I
>> noticed in v3 where it would segfault on some git-fetch invocations,
>> but there were not tests anywhere that caught that.
>
> ...and
Add documentation explaining the functions in color.h.
While at it, mark them extern and migrate the function `color_set`
into grep.c, where the only callers are.
Signed-off-by: Stefan Beller
---
This used to be part of sb/blame-color, but I realized this is
not strictly needed for that serie
Jonathan Tan writes:
> On Thu, 8 Feb 2018 02:56:14 +
> "brian m. carlson" wrote:
>
>> Existing trailers are extracted from the input message by looking for
>> -a group of one or more lines that (i) are all trailers, or (ii) contains at
>> -least one Git-generated or user-configured trailer
Add document specifying the binary format for commit graphs. This
format allows for:
* New versions.
* New hash functions and hash lengths.
* Optional extensions.
Basic header information is followed by a binary table of contents
into "chunks" that include:
* An ordered list of commit object IDs
Teach git the 'commit-graph' builtin that will be used for writing and
reading packed graph files. The current implementation is mostly
empty, except for a '--pack-dir' option.
Signed-off-by: Derrick Stolee
---
.gitignore | 1 +
Documentation/git-commit-graph.txt | 11 ++
Thanks to everyone who gave comments on v1 and v2.
Hopefully the following points have been addressed:
* Fixed inter-commit problems where certain fixes did not arrive until
later commits.
* Converted from submode flags ("git commit-graph --write") to
subcommands ("git commit-graph write").
It is possible to have multiple commit graph files in a pack directory,
but only one is important at a time. Use a 'graph_head' file to point
to the important file. Teach git-commit-graph to write 'graph_head' upon
writing a new commit graph file.
Signed-off-by: Derrick Stolee
---
Documentation/
Teach write_commit_graph() to walk all parents from the commits
discovered in packfiles. This prevents gaps given by loose objects or
previously-missed packfiles.
Also automatically add commits from the existing graph file, if it
exists.
Signed-off-by: Derrick Stolee
---
commit-graph.c | 37 +++
Teach Git to inspect a commit graph file to supply the contents of a
struct commit when calling parse_commit_gently(). This implementation
satisfies all post-conditions on the struct commit, including loading
parents, the root tree, and the commit date. The only loosely-expected
condition is that t
Teach git-commit-graph to write graph files. Create new test script to verify
this command succeeds without failure.
Signed-off-by: Derrick Stolee
---
Documentation/git-commit-graph.txt | 39 +
builtin/commit-graph.c | 43 +++
t/t5318-commit-graph.sh
The commit graph feature is controlled by the new core.commitGraph config
setting. This defaults to 0, so the feature is opt-in.
The intention of core.commitGraph is that a user can always stop checking
for or parsing commit graph files if core.commitGraph=0.
Signed-off-by: Derrick Stolee
---
D
Teach Git to delete the current 'graph_head' file and the commit graph
it references. This is a good safety valve if somehow the file is
corrupted and needs to be recalculated. Since the commit graph is a
summary of contents already in the ODB, it can be regenerated.
Signed-off-by: Derrick Stolee
Teach Git to write a commit graph file by checking all packed objects
to see if they are commits, then store the file in the given pack
directory.
Signed-off-by: Derrick Stolee
---
Makefile | 1 +
commit-graph.c | 368 +
commit-grap
Teach git-commit-graph to read commit graph files and summarize their contents.
Use the read subcommand to verify the contents of a commit graph file in the
tests.
Signed-off-by: Derrick Stolee
---
Documentation/git-commit-graph.txt | 16
builtin/commit-graph.c | 71 +
Add Documentation/technical/commit-graph.txt with details of the planned
commit graph feature, including future plans.
Signed-off-by: Derrick Stolee
---
Documentation/technical/commit-graph.txt | 189 +++
1 file changed, 189 insertions(+)
create mode 100644 Documenta
Teach git-commit-graph to read commits from stdin when the
--stdin-commits flag is specified. Commits reachable from these
commits are added to the graph. This is a much faster way to construct
the graph than inspecting all packed objects, but is restricted to
known tips.
For the Linux repository,
Teach git-commit-graph to inspect the objects only in a certain list
of pack-indexes within the given pack directory. This allows updating
the commit graph iteratively, since we add all commits stored in a
previous commit graph.
Signed-off-by: Derrick Stolee
---
Documentation/git-commit-graph.tx
Teach git-commit-graph to delete the graph files in the pack directory
that were not referenced by 'graph_head' during this process. This cleans
up space for the user while not causing race conditions with other running
Git processes that may be referencing the previous graph file.
To delete old g
On Thu, Feb 08, 2018 at 12:15:46PM -0800, Stefan Beller wrote:
> int color_fprintf(FILE *fp, const char *color, const char *fmt, ...)
> {
> va_list args;
> diff --git a/color.h b/color.h
> index fd2b688dfb..8c7e6c41c2 100644
> --- a/color.h
> +++ b/color.h
> @@ -72,26 +72,50 @@ extern int
From: Gregory Herrero
Since commit dd6fb0053 ("rebase -p: fix quoting when calling `git
merge`"), commit message of the merge commit being rebased is passed to
the merge command using a subshell executing 'git rev-parse --sq-quote'.
Double quotes are needed around this subshell so that, newlines
On Thu, Feb 8, 2018 at 12:43 PM, Jeff King wrote:
> On Thu, Feb 08, 2018 at 12:15:46PM -0800, Stefan Beller wrote:
>
>> int color_fprintf(FILE *fp, const char *color, const char *fmt, ...)
>> {
>> va_list args;
>> diff --git a/color.h b/color.h
>> index fd2b688dfb..8c7e6c41c2 100644
>> ---
On Thu, Feb 08 2018, Leo Gaspard jotted:
> On 02/08/2018 04:30 PM, Joey Hess wrote:
>> Leo Gaspard wrote:
>>> That said, I just came upon [1] (esp. the description [2] and the patch
>>> [3]), and wondered: it looks like the patch was abandoned midway in
>>> favor of a hook refactoring. Would you
On Mon, Jan 8, 2018 at 11:34 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> +color.blame.repeatedMeta::
>> + Use the customized color for the part of git-blame output that
>> + is repeated meta information per line (such as commit id,
>> + author name, date and timezone). Defa
Derrick Stolee writes:
> Add document specifying the binary format for commit graphs. This
> format allows for:
>
> * New versions.
> * New hash functions and hash lengths.
It still is unclear, at least to me, why OID and OID length are
stored as if they can be independent. If a reader does not
Derrick Stolee writes:
> Teach git the 'commit-graph' builtin that will be used for writing and
> reading packed graph files. The current implementation is mostly
> empty, except for a '--pack-dir' option.
Why do we want to use "pack" dir, when this is specifically designed
not tied to packfile?
On 2/8/2018 4:21 PM, Junio C Hamano wrote:
Derrick Stolee writes:
Add document specifying the binary format for commit graphs. This
format allows for:
* New versions.
* New hash functions and hash lengths.
It still is unclear, at least to me, why OID and OID length are
stored as if they can
On 2/8/2018 4:27 PM, Junio C Hamano wrote:
Derrick Stolee writes:
Teach git the 'commit-graph' builtin that will be used for writing and
reading packed graph files. The current implementation is mostly
empty, except for a '--pack-dir' option.
Why do we want to use "pack" dir, when this is spe
On Thu, Feb 08, 2018 at 01:04:08PM -0800, Stefan Beller wrote:
> You may sense a pattern here: I currently have the very firm understanding
> we use the extern keyword in our codebase.
>
> And I can also attest that this was not always the case, as back in the
> day I remember writing patches wit
On Thu, Feb 8, 2018 at 1:38 PM, Jeff King wrote:
> On Thu, Feb 08, 2018 at 01:04:08PM -0800, Stefan Beller wrote:
>
>> You may sense a pattern here: I currently have the very firm understanding
>> we use the extern keyword in our codebase.
>>
>> And I can also attest that this was not always the c
On Thu, Feb 8, 2018 at 1:21 PM, Stefan Beller wrote:
> On Thu, Feb 8, 2018 at 12:08 AM, Eric Sunshine
> wrote:
>> On Wed, Feb 7, 2018 at 6:43 PM, Stefan Beller wrote:
>>> +die __("When a batch size is given, the relogin delay must be set\n")
>>> + if defined $relogin_delay and not defined
This may be intentional, but if so, it's not obvious..
Back long long ago, the original "git commit" shell script got rewritten in C.
In that rewrite, removing some temporary files seems to have been left
out. At least one: .git/COMMIT_EDITMSG.
In the original commit.sh shell script, we can find
Derrick Stolee writes:
> +char* get_commit_graph_filename_hash(const char *pack_dir,
Asterisk sticks to the identifier, not type, in our codebase.
> + struct object_id *hash)
> +{
> + size_t len;
> + struct strbuf path = STRBUF_INIT;
> + strbuf_addst
Linus Torvalds writes:
> In that rewrite, removing some temporary files seems to have been left
> out. At least one: .git/COMMIT_EDITMSG.
>
> In the original commit.sh shell script, we can find this:
>
> rm -f "$GIT_DIR/COMMIT_MSG" "$GIT_DIR/COMMIT_EDITMSG" "$GIT_DIR/SQUASH_MSG"
>
> after creat
On 02/08/2018 10:06 PM, Ævar Arnfjörð Bjarmason wrote:>> Hmm, OK, so I
guess I'll try to update the patch when I get some time to
>> delve into git's internals, as my use case (forbidding some fetches)
>> couldn't afaik be covered by a wrapper hook.
>
> Per my reading of
> https://public-inbox.org
On Thu, Feb 8, 2018 at 3:43 PM, Jeff King wrote:
> On Thu, Feb 08, 2018 at 12:15:46PM -0800, Stefan Beller wrote:
>> +/*
>> + * Resolve the constants as returned by git_config_colorbool()
>> + * (specifically "auto") to a boolean answer.
>> + */
>> +extern int want_color(int var);
>
> This explana
1 - 100 of 129 matches
Mail list logo
