On Tue, Apr 12, 2016 at 4:48 PM, Stefan Beller wrote:
> There are some inherent issues with shallow clones and submodules, such
> as having not having a commit available the superproject may point to
> in the submodule due to being shallow. Use the new file t5614 to document
> and test expectation
On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva wrote:
> Add commit.verbose configuration variable as a convenience for those
> who always prefer --verbose.
>
> Helped-by: Junio C Hamano
> Helped-by: Eric Sunshine
> Signed-off-by: Pranit Bauva
> ---
> diff --git a/t/t7507-commit-verbose.sh b/t/t7
On 12 Apr 2016, at 22:49, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> But my point wasn't to say "we already have everything we need", but
>> rather "we already have part of the solution, so an ideal complete
>> solution could integrate with it".
>
> Yes. That is a good direction to go
On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva wrote:
> Make the fake "editor" store output of grep in a file so that we can
> see how many diffs were contained in the message and use them in
> individual tests where ever it is required. A subsequent commit will
> introduce scenarios where it is im
On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva wrote:
> OPT_COUNTUP() merely increments the counter upon --option, and resets it
> to 0 upon --no-option, which means that there is no "unspecified" value
> with which a client can initialize the counter to determine whether or
> not --[no]-option was
From: Lars Schneider
Signed-off-by: Lars Schneider
---
Documentation/SubmittingPatches | 39 ---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 98fc4cc..79e9b33 100644
---
Junio C Hamano writes:
> Matthieu Moy writes:
>
> True, presumably the Travis integration already solves that part, so
> I suspect it is just the matter of setting up:
>
> - a fork of git.git and have Travis monitor any and all new
>branches;
>
> - a bot that scans the list traffic, applie
On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva wrote:
> Include tests to check for multiple levels of quiet and to check if the
> '--no-quiet' option sets it to 0.
>
> Signed-off-by: Pranit Bauva
> ---
> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
> @@ -476,4 +476,41 @@ test_e
On Sat, Apr 9, 2016 at 7:19 AM, Michael Rappazzo wrote:
> t1500-rev-parse has many tests which change directories and leak
> environment variables. This makes it difficult to add new tests without
> minding the environment variables and current directory.
>
> Each test is now setup, executed, and
Michael Rappazzo writes:
> t1500-rev-parse has many tests which change directories and leak
> environment variables. This makes it difficult to add new tests without
> minding the environment variables and current directory.
>
> Each test is now setup, executed, and cleaned up without leaving an
Consider this example branch:
remotes/origin/master
gitk displays this branch with different background colors for each part:
"remotes/origin" in orange and "master" in green. The idea is to make it
visually easy to read the branch name separately from the remote name.
However this fails when gi
On April 12, 2016 6:51:12 PM PDT, Duy Nguyen wrote:
>On Wed, Apr 13, 2016 at 5:38 AM, H. Peter Anvin wrote:
>> OK, I'm going to open this can of worms...
>>
>> At what point do we migrate from SHA-1?
>
>Brian Carlson has been slowly refactoring git code base, abstracting
>SHA-1 away. Once that wo
On Wed, Apr 13, 2016 at 5:38 AM, H. Peter Anvin wrote:
> OK, I'm going to open this can of worms...
>
> At what point do we migrate from SHA-1?
Brian Carlson has been slowly refactoring git code base, abstracting
SHA-1 away. Once that work is done, I think we can talk about moving
away from SHA-1
Junio C Hamano writes:
> Stefan Beller writes:
>
>> This is a resend of origin/sb/submodule-init (and it still applies on
>> top of submodule-parallel-update)
>
> Resend, or update? There was some overlap with your recent series
> that fixes "prefix" thing, IIRC.
I've queued one possible reso
On 04/12/16 18:03, Junio C Hamano wrote:
and so on. Of course trees don't have any space for this; they have a
fixed-length for the hash part of each record, which is basically:
NUL <20-byte-sha1>
So we'd probably need a "treev2" object type that gives room for an
algorithm byte (or we'd
Stefan Beller writes:
> Once I made the mistake to not remove a previous patch series I had,
> such that there was:
>
> -coverletter.patch (newly worded)
> 0001-bla-from-new-series
> 0001-foo-from-old-series
> 0002-...
> ...
>
> `git send-email 0*` then sent out a totally bogus seri
On Tue, Apr 12, 2016 at 06:03:02PM -0700, Junio C Hamano wrote:
> > So we'd probably need a "treev2" object type that gives room for an
> > algorithm byte (or we'd have to try to shove it into the mode, but since
> > old versions won't know the new algorithm anyway, I don't think it
> > solves tha
Eric Sunshine writes:
> I still have the same question[1] as last time I reviewed this patch:
> Should default be 'n', or am I misunderstanding?
Yes, you are right and no, there is no misunderstanding.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a me
Elijah Newren writes:
> There were a few cases in merge-recursive that could result in a check for
> the presence of files in the working copy while trying to create a virtual
> merge base. These were rare and innocuous, but somewhat illogical. The
> two cases were:
>
> * When there was namin
On Tue, Apr 12, 2016 at 02:15:09PM -0700, Junio C Hamano wrote:
> Nikola Forró writes:
>
> > Every yes/no question in difftool/mergetool scripts has slightly
> > different form, and none of them is consistent with the form git
> > itself uses.
> >
> > Make the form of all the questions consistent
Elijah Newren writes:
> Elijah Newren (6):
> Remove duplicate code
> Avoid checking working copy when creating a virtual merge base
> Add merge testcases for when index doesn't match HEAD
> merge-octopus: Abort if index does not match HEAD
> Add a testcase demonstrating a bug with trivi
Stefan Beller writes:
> This is a resend of origin/sb/submodule-init (and it still applies on
> top of submodule-parallel-update)
Resend, or update? There was some overlap with your recent series
that fixes "prefix" thing, IIRC.
--
To unsubscribe from this list: send the line "unsubscribe git
Jeff King writes:
> So a slightly nicer thing is to parameterize the algorithm for every
> object name reference. So commits look like:
>
> tree sha256:1234abcd...
> parent sha256:1234abcd...
>
> and so on. Of course trees don't have any space for this; they have a
> fixed-length for the hash
Soon, we'll want to automatically start index-helper, so we need
a mode that silently exits if it can't start up (either because
it's not in a git dir, or because another one is already running).
Signed-off-by: David Turner
---
index-helper.c | 29 +++--
t/t7900-
When we poke index-helper, and index-helper is using watchman, we want
to wait for a response (showing that the watchman extension shm has
been prepared). If it's not using watchman, we don't.
So add a new config, core.waitforindexhelper, with sensible defaults, to
configure this behavior.
Signe
From: Nguyễn Thái Ngọc Duy
The extension contains a bitmap, one bit for each entry in the
index. If the n-th bit is zero, the n-th entry is considered
unchanged, we can ce_mark_uptodate() it without refreshing. If the bit
is non-zero and we found out the corresponding file is clean after
refresh,
This version has been tested on OS X and Linux. It switches from
POSIX-Realtime shm to plain old mmap. Thanks to JI for this
suggestion.
This version incorporates a couple of fixes from Ramsay Jones.
There might be a couple of minor spelling/grammar fixes too.
David Turner (6):
unpack-trees:
From: Nguyễn Thái Ngọc Duy
Watchman is hidden behind index-helper. Before git tries to read the
index from shm, it notifies index-helper through the socket and waits
for index-helper to prepare a file for sharing memory (with
MAP_SHARED). index-helper then contacts watchman, updates 'WAMA'
extens
From: Nguyễn Thái Ngọc Duy
This allows signal handlers and atexit functions to realize this
situation and not clean up.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: David Turner
---
builtin/gc.c | 2 +-
cache.h | 2 +-
daemon.c | 2 +-
setup.c | 4 +++-
4 files changed, 6
Introduce a new config option, indexhelper.autorun, to automatically
run git index-helper before starting up a builtin git command. This
enables users to keep index-helper running without manual
intervention.
Signed-off-by: David Turner
---
Documentation/config.txt | 4
git.c
From: Nguyễn Thái Ngọc Duy
We detach after creating and opening the socket, because otherwise
we might return control to the shell before index-helper is ready to
accept commands. This might lead to flaky tests.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: David Turner
---
Documentatio
Add a new command (and command-line arg) to allow index-helpers to
exit cleanly.
This is mainly useful for tests.
Signed-off-by: David Turner
---
index-helper.c | 31 ++-
t/t7900-index-helper.sh | 12
2 files changed, 42 insertions(+), 1 deletio
From: Nguyễn Thái Ngọc Duy
The previous patch has the logic to clear bits in 'WAMA' bitmap. This
patch has logic to set bits as told by watchman. The missing bit,
_using_ these bits, are not here yet.
A lot of this code is written by David Turner originally, mostly from
[1]. I'm just copying and
Make git checkout (and other unpack_tree operations) preserve the
untracked cache and watchman status. This is valuable for two reasons:
1. Often, an unpack_tree operation will not touch large parts of the
working tree, and thus most of the untracked cache will continue to be
valid.
2. Even if th
Signed-off-by: David Turner
---
index-helper.c | 7 +++
t/t7900-index-helper.sh | 9 +
2 files changed, 16 insertions(+)
diff --git a/index-helper.c b/index-helper.c
index 3e0990e..dcb2041 100644
--- a/index-helper.c
+++ b/index-helper.c
@@ -480,6 +480,13 @@ int main(int arg
From: Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: David Turner
---
builtin/update-index.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 1c94ca5..7c08e1c 100644
--- a/builtin/update-index.c
+++
From: Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: David Turner
---
read-cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/read-cache.c b/read-cache.c
index d9fb78b..16cc487 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1345,7 +1345,7 @@
From: Nguyễn Thái Ngọc Duy
Later, we will introduce git index-helper to share this memory with
other git processes.
Since the memory will be shared, it will never be unmapped (although
the kernel may of course choose to page it out).
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: David Tur
From: Nguyễn Thái Ngọc Duy
There are "holes" in the index-helper approach because the shared
memory is not verified again by git. If $USER is compromised, shared
memory could be modified. But anyone who could do this could already
modify $GIT_DIR/index. A more realistic risk is some bugs in
index
From: Nguyễn Thái Ngọc Duy
Instead of reading the index from disk and worrying about disk
corruption, the index is cached in memory (memory bit-flips happen
too, but hopefully less often). The result is faster read. Read time
is reduced by 70%.
The biggest gain is not having to verify the traili
On Tue, 2016-04-12 at 11:05 -0700, Junio C Hamano wrote:
> > > - access is slow (unless cached, but we can't be sure)
> >
> > We could solve this (and the other problem) with mlock.
>
> Probably you meant madvise(2)?
>
> For something of a size comparable to the index file held by
> index-helpe
By having the `init` functionality in C, we can reference it easier
from other parts in the code.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
builtin/submodule--helper.c | 107
git-submodule.sh| 39 +---
su
Later on we want to automatically call `git submodule init` from
other commands, such that the users don't have to initialize the
submodule themselves. As these other commands are written in C
already, we'd need the init functionality in C, too. The
`resolve_relative_url` function is a large part
This is a resend of origin/sb/submodule-init (and it still applies on
top of submodule-parallel-update)
I squashed a change which Michael Haggerty proposed in one of the
large cleanup series preparing for the new refs backend. (18/21)
As that is the only fix in that series touching submodules,
pi
When creating a shallow clone of a repository with submodules, the depth
argument does not influence the submodules, i.e. the submodules are done
as non-shallow clones. It is unclear what the best default is for the
depth of submodules of a shallow clone, so we need to have the possibility
to do al
When cloning a local repository, the user may choose to use an optimization
such that the transfer uses a Git agnostic protocol. Propagate the users
choice to submodules or if they don't choose, propagate nothing.
A test will be added in a later patch.
Signed-off-by: Stefan Beller
---
builtin/cl
(This is a resend of a series from March 15th, titled
"Towards sane shallow clones with submodules", this series
applies on top of sb/submodule-parallel-update,
it replaces sb/clone-shallow-passthru)
When creating a shallow clone of a repository with submodules, the depth
argument does not influe
There are some inherent issues with shallow clones and submodules, such
as having not having a commit available the superproject may point to
in the submodule due to being shallow. Use the new file t5614 to document
and test expectations in this area.
Signed-off-by: Stefan Beller
---
t/t5614-clo
On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote:
> It would be possible, of course, to GPG-sign the entire commit's
> transitive data (rather than just the SHA1s of same). But as far as I
> know, that is not ever what is done.
There is a project called git-evtag which does this, and
On Tue, Apr 12, 2016 at 03:38:04PM -0700, H. Peter Anvin wrote:
> For existing repositories we will need to have a migration mechanism. Since
> we can't modify objects without completely invalidating the cryptographic
> properties, what I would suggest is that we leave the existing objects as
> is
gree...@obbligato.org (David A. Greene) writes:
>> I also notice that files_subtree/master4 does not appear in any of
>> the verification in the three tests that use the history being
>> prepared here, i.e. if master4 is silently dropped while master5 is
>> kept, such a bug won't be caught by them
Luke Diamand writes:
> On 28 February 2016 at 20:46, Amadeusz Żołnowski wrote:
>
>>
>> True. For now I have these cases covered by wrapper scripts. The minimum
>> I need from git-p4 is just not to fail on git submit from bare
>> repository which is covered by patch I have submitted. If I get my
On Sun, Apr 10, 2016 at 3:19 PM, Stephan Beyer wrote:
>
> @@ -123,10 +116,9 @@ static void show_list(const char *debug, int counted,
> int nr,
> const char *subject_start;
> int subject_len;
>
> - fprintf(stderr, "%c%c%c ",
> + fprintf(s
SZEDER Gábor writes:
> Hi,
>
>> > And MINGW is not happy for other reasons:
>> >
>> > builtin/rev-parse.c: In function 'cmd_rev_parse':
>> > builtin/rev-parse.c:775:12: warning: implicit declaration of function
>> > 'realpath' [-Wimplicit-function-declaration]
>> >if (!realpath(gitdir, ab
Junio C Hamano writes:
> Marios Titas writes:
>
>> Yeah, maybe informative is not the right word. What I meant is that it
>> directs the user to do the "git config user.name" thing, which is
>> likely the most appropriate course of action in this situation. In any
>> event, I think printing the
On Tue, 2016-04-12 at 16:00 -0700, Stefan Beller wrote:
> On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin
> wrote:
> > OK, I'm going to open this can of worms...
> >
> > At what point do we migrate from SHA-1? At this point the
> > cryptoanalysis of
> > SHA-1 is most likely a matter of time.
>
On Tue, Apr 12, 2016 at 04:00:18PM -0700, Stefan Beller wrote:
> On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin wrote:
> > OK, I'm going to open this can of worms...
> >
> > At what point do we migrate from SHA-1? At this point the cryptoanalysis of
> > SHA-1 is most likely a matter of time.
>
Pranit Bauva writes:
> On Wed, Apr 13, 2016 at 3:03 AM, Junio C Hamano wrote:
>> Pranit Bauva writes:
>>
>>> Current implementation of parse-options.c treats OPT__QUIET() as integer
>>> and not boolean and thus it is more appropriate to print it as integer
>>> to avoid confusion.
>>
>> There is
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The 'master' branch now has the th
On 04/12/16 16:00, Stefan Beller wrote:
On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin wrote:
OK, I'm going to open this can of worms...
At what point do we migrate from SHA-1? At this point the cryptoanalysis of
SHA-1 is most likely a matter of time.
And I thought the cryptographic proper
On Tue, Apr 12, 2016 at 3:53 PM, Junio C Hamano wrote:
> Diligent people save output from format-patch to files, proofread
> and edit them and then finally send the result out. If the
> resulting files are sent out with "git send-email 0*", this ends up
> sending backup files (e.g. 0001-X.patch.b
Make the fake "editor" store output of grep in a file so that we can
see how many diffs were contained in the message and use them in
individual tests where ever it is required. A subsequent commit will
introduce scenarios where it is important to be able to exactly
determine how many diffs were pr
Signed-off-by: Pranit Bauva
---
Changes wrt previous version (v12):
- Use '\' when interpolation isn't required
---
t/t0040-parse-options.sh | 76
1 file changed, 38 insertions(+), 38 deletions(-)
diff --git a/t/t0040-parse-options.sh b/t/t0040-
Include tests to check for multiple levels of quiet and to check if the
'--no-quiet' option sets it to 0.
Signed-off-by: Pranit Bauva
---
t/t0040-parse-options.sh | 37 +
1 file changed, 37 insertions(+)
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-o
Add commit.verbose configuration variable as a convenience for those
who always prefer --verbose.
Helped-by: Junio C Hamano
Helped-by: Eric Sunshine
Signed-off-by: Pranit Bauva
---
The previous version of the patch are:
- [v12] $gmane/288820
- [v11] $gmane/288820
- [v10] $gmane/288820
- [v
On Sun, Apr 10, 2016 at 3:19 PM, Stephan Beyer wrote:
>
> @@ -321,14 +321,13 @@ static struct commit_list *do_find_bisection(struct
> commit_list *list,
> * add one for p itself if p is to be counted,
> * otherwise inherit it from q directly.
>
OPT_COUNTUP() merely increments the counter upon --option, and resets it
to 0 upon --no-option, which means that there is no "unspecified" value
with which a client can initialize the counter to determine whether or
not --[no]-option was seen at all.
Make OPT_COUNTUP() treat any negative number as
We would want to see how multiple --quiet options affect the value of
the underlying variable (we may want "--quiet --quiet" to still be 1, or
we may want to see the value incremented to 2). Show the value as
integer to allow us to inspect it.
Signed-off-by: Pranit Bauva
---
t/t0040-parse-option
On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin wrote:
> OK, I'm going to open this can of worms...
>
> At what point do we migrate from SHA-1? At this point the cryptoanalysis of
> SHA-1 is most likely a matter of time.
And I thought the cryptographic properties of SHA1 did not matter for
Gits
On Tue, Apr 12, 2016 at 6:53 PM, Junio C Hamano wrote:
> Diligent people save output from format-patch to files, proofread
> and edit them and then finally send the result out. If the
> resulting files are sent out with "git send-email 0*", this ends up
> sending backup files (e.g. 0001-X.patch.b
Diligent people save output from format-patch to files, proofread
and edit them and then finally send the result out. If the
resulting files are sent out with "git send-email 0*", this ends up
sending backup files (e.g. 0001-X.patch.backup or 0001-X.patch~)
left by their editors next to the final
OK, I'm going to open this can of worms...
At what point do we migrate from SHA-1? At this point the
cryptoanalysis of SHA-1 is most likely a matter of time.
For existing repositories we will need to have a migration mechanism.
Since we can't modify objects without completely invalidating th
Stan Hu writes:
> The pkt-line format mandates: "a sender should include a LF, but the
> receive MUST NOT complain if it is not present." This patch
> is not absolutely necessary since receivers handle the missing the LF,
> but this patch adds it for good measure.
s/since receivers handle/since
On Wed, Apr 13, 2016 at 3:48 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Junio C Hamano writes:
>>
>>> Hmph, isn't this already in 'next', hence we cannot accept a
>>> replacement patch?
>>
>> As a one-time measure, I'll revert the previous one
>>
>> 50f0d20d (commit: add a commit.ve
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Hmph, isn't this already in 'next', hence we cannot accept a
>> replacement patch?
>
> As a one-time measure, I'll revert the previous one
>
> 50f0d20d (commit: add a commit.verbose config variable, 2016-03-14)
>
> out of 'next' and queue this
On Wed, Apr 13, 2016 at 3:03 AM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>> Current implementation of parse-options.c treats OPT__QUIET() as integer
>> and not boolean and thus it is more appropriate to print it as integer
>> to avoid confusion.
>
> There is no "confusion" factor involved,
Junio C Hamano writes:
> Hmph, isn't this already in 'next', hence we cannot accept a
> replacement patch?
As a one-time measure, I'll revert the previous one
50f0d20d (commit: add a commit.verbose config variable, 2016-03-14)
out of 'next' and queue this one instead on 'pu'.
--
To unsubscrib
Pranit Bauva writes:
> Current implementation of parse-options.c treats OPT__QUIET() as integer
> and not boolean and thus it is more appropriate to print it as integer
> to avoid confusion.
There is no "confusion" factor involved, as we do not use native
"boolean" type in our C code. IIUC, the
On Wed, Apr 13, 2016 at 2:54 AM, Junio C Hamano wrote:
> Hmph, isn't this already in 'next', hence we cannot accept a
> replacement patch?
Yes, this is already in 'next'. This was going to be merged in the
third cycle after 2.8 but on my request, you delayed it. So this is an
update on the patch.
Hmph, isn't this already in 'next', hence we cannot accept a
replacement patch?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Nikola Forró writes:
> Every yes/no question in difftool/mergetool scripts has slightly
> different form, and none of them is consistent with the form git
> itself uses.
>
> Make the form of all the questions consistent with the form used
> by git.
>
> Reviewed-by: John Keeping
> Signed-off-by:
Junio C Hamano writes:
> Karthik Nayak writes:
>
>> +branch_get_color(BRANCH_COLOR_REMOTE), maxwidth,
>> +remote_prefix,
>> branch_get_color(BRANCH_COLOR_RESET));
>> +} else {
>> +strbuf_addf(&local,
>> "%%(refname:strip=2)%s%%(if
Matthieu Moy writes:
> But my point wasn't to say "we already have everything we need", but
> rather "we already have part of the solution, so an ideal complete
> solution could integrate with it".
Yes. That is a good direction to go.
They may already have part of the solution, and their half
Karthik Nayak writes:
> + branch_get_color(BRANCH_COLOR_REMOTE), maxwidth,
> + remote_prefix,
> branch_get_color(BRANCH_COLOR_RESET));
> + } else {
> + strbuf_addf(&local,
> "%%(refname:strip=2)%s%%(if)%%(symref)%%(then) -> %%(symr
Stefan Beller writes:
> On Tue, Apr 12, 2016 at 12:23 AM, Matthieu Moy
> wrote:
>> Stefan Beller writes:
>>
>>> Hi Greg,
>>>
>>> Thanks for your talk at the Git Merge 2016!
>>> The Git community uses the same workflow as the kernel. So we may be
>>> interested in the 0 bot which could compile a
"Michael S. Tsirkin" writes:
>> As to the "use commit-tree", well, personally I am not interested in
>> a solution that can work well in my workflow ONLY if I further script
>> it. That's half-solution and unless that half is done very well,
>> I'd rather do a full solution better.
>
> Absolutel
Xiaolong Ye writes:
> +static int config_base_commit;
This variable is used as a simple boolean whose name is overly broad
(if it were named "config_base_auto" this complaint would not
apply). If you envision possible future enhancements for this
configuration variable, "int config_base_commit"
On Wed, Apr 6, 2016 at 10:47 AM, Jacob Keller wrote:
>
> I started attempting to implement this heuristic within xdiff, but I
> am at a loss as to how xdiff actually works. I suspect this would go
> in xdi_change_compact or after it, but I really don't understand how
> xdiff represents the diffs a
Xiaolong Ye writes:
> Maintainers or third party testers may want to know the exact base tree
> the patch series applies to. Teach git format-patch a '--base' option
> to record the base tree info and append it at the end of the_first_
It probably was a good idea to add stress during the discuss
On Tue, Apr 12, 2016 at 03:01:19PM +0100, John Keeping wrote:
> On Tue, Apr 12, 2016 at 03:53:12PM +0200, Nikola Fo wrote:
> > On Tue, 2016-04-12 at 14:27 +0100, John Keeping wrote:
> > > I think the case in these two is correct as-is. The "Y" is capitalised
> > > because it is the default and
David Turner writes:
>> I avoided actual files for two reasons
>>
>> - disk error rate is higher than memory one, and we might need
>> trailing SHA-1 back
>
> This only matters if we ever *read* the mmap off disk. But that will
> rarely happen -- usually, everything will stay in memory.
True,
Vasco Almeida writes:
> diff --git a/git-parse-remote.sh b/git-parse-remote.sh
> index 55fe8d5..c5e5840 100644
> --- a/git-parse-remote.sh
> +++ b/git-parse-remote.sh
> @@ -6,6 +6,9 @@
> # this would fail in that case and would issue an error message.
> GIT_DIR=$(git rev-parse -q --git-dir) ||
On Tue, 2016-04-12 at 16:40 +0700, Duy Nguyen wrote:
> On Tue, Apr 12, 2016 at 6:27 AM, David Turner <
> dtur...@twopensource.com> wrote:
> > On Fri, 2016-04-08 at 18:16 -0400, David Turner wrote:
> > > And SHM on Macs works a bit differently than on Linux in at least
> > > two
> > > irritating way
On Tue, Apr 12, 2016 at 10:12:39AM -0700, Junio C Hamano wrote:
> In any case, lest we forget...
>
> -- >8 --
> Subject: [PATCH] t3404: use write_script
Yep, looks good. Thanks.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ke
On Tue, Apr 12, 2016 at 09:58:20AM -0700, Junio C Hamano wrote:
> > Looks good and is the minimal change. I kind of wonder if the example
> > would be more clear, though, as just:
> >
> > write_script .git/hooks/pre-commit <<-\EOF &&
> > exit 1
> > EOF
> > echo whatever >file1 &&
> > ...
Junio C Hamano writes:
> Jeff King writes:
> ...
>> Looks good and is the minimal change. I kind of wonder if the example
>> would be more clear, though, as just:
>>
>> write_script .git/hooks/pre-commit <<-\EOF &&
>> exit 1
>> EOF
>> echo whatever >file1 &&
>> ...
>>
>> I don't think
Jeff King writes:
> On Sat, Apr 09, 2016 at 05:37:43PM -0700, Junio C Hamano wrote:
>
>> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
>> index b79f442..d96d0e4 100755
>> --- a/t/t3404-rebase-interactive.sh
>> +++ b/t/t3404-rebase-interactive.sh
>> @@ -555,10 +555,9 @
Jeff King writes:
> On Tue, Apr 12, 2016 at 05:33:33PM +0200, Michael J Gruber wrote:
>
>> $ git show cab2cdadfda8e8e8631026443b11d3ed6e7ba517:
>> tree cab2cdadfda8e8e8631026443b11d3ed6e7ba517:
>>
>> .gitattributes
>> .gitignore
>> .mailmap
>> ...
>
> As Junio pointed out, the colon here is not
On Tue, Apr 12, 2016 at 09:07:30AM -0700, Junio C Hamano wrote:
> Matthieu Moy writes:
>
> > "Michael S. Tsirkin" writes:
> >
> >> Interesting. An empty commit would be rather easy to create on any
> >> branch, not just the current one, using git-commit-tree.
> >
> > This "modify a branch withou
On Tue, Apr 12, 2016 at 05:33:33PM +0200, Michael J Gruber wrote:
> $ git show cab2cdadfda8e8e8631026443b11d3ed6e7ba517:
> tree cab2cdadfda8e8e8631026443b11d3ed6e7ba517:
>
> .gitattributes
> .gitignore
> .mailmap
> ...
As Junio pointed out, the colon here is not syntactic, but from the
original
1 - 100 of 130 matches
Mail list logo
