* Re: [PATCH v2 2/2] read-cache: make sure file handles are not inherited by child processes
From: Junio C Hamano @ 2016-10-24 19:53 UTC (permalink / raw)
To: Eric Wong; +Cc: larsxschneider, git, Johannes.Schindelin, jnareb
In-Reply-To: <20161024183900.GA12769@starla>
Eric Wong <e@80x24.org> writes:
> larsxschneider@gmail.com wrote:
>> +++ b/read-cache.c
>> @@ -156,7 +156,11 @@ void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
>> static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
>> {
>> int match = -1;
>> - int fd = open(ce->name, O_RDONLY);
>> + int fd = open(ce->name, O_RDONLY | O_CLOEXEC);
>> +
>> + if (O_CLOEXEC && fd < 0 && errno == EINVAL)
>> + /* Try again w/o O_CLOEXEC: the kernel might not support it */
>> + fd = open(ce->name, O_RDONLY);
>
> In the case of O_CLOEXEC != 0 and repeated EINVALs,
> it'd be good to use something like sha1_file_open_flag as in 1/2
> so we don't repeatedly hit EINVAL. Thanks.
Sounds sane.
It's just only once, so perhaps we do not mind a recursion like
this?
read-cache.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index b594865d89..a6978b9321 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -156,11 +156,14 @@ void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
{
int match = -1;
- int fd = open(ce->name, O_RDONLY | O_CLOEXEC);
+ static int cloexec = O_CLOEXEC;
+ int fd = open(ce->name, O_RDONLY | cloexec);
- if (O_CLOEXEC && fd < 0 && errno == EINVAL)
+ if ((cloexec & O_CLOEXEC) && fd < 0 && errno == EINVAL) {
/* Try again w/o O_CLOEXEC: the kernel might not support it */
- fd = open(ce->name, O_RDONLY);
+ cloexec &= ~O_CLOEXEC;
+ return ce_compare_data(ce, st);
+ }
if (fd >= 0) {
unsigned char sha1[20];
^ permalink raw reply related
* Re: [PATCH v2 2/2] read-cache: make sure file handles are not inherited by child processes
From: Lars Schneider @ 2016-10-24 19:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Johannes.Schindelin, e, jnareb, gitster
In-Reply-To: <10135d1c-d9a7-d4ec-438a-bb0a8f6762fe@kdbg.org>
> On 24 Oct 2016, at 21:22, Johannes Sixt <j6t@kdbg.org> wrote:
>
> Am 24.10.2016 um 20:03 schrieb larsxschneider@gmail.com:
>> From: Lars Schneider <larsxschneider@gmail.com>
>>
>> This fixes "convert: add filter.<driver>.process option" (edcc8581) on
>> Windows.
>
> Today's next falls flat on its face on Windows in t0021.15 "required process filter should filter data"; might it be the failure meant here? (I haven't dug deeper, yet.)
Yes, this is the failure meant here :-)
Cheers,
Lars
^ permalink raw reply
* Re: [PATCH v5 00/27] Prepare the sequencer for the upcoming rebase -i patches
From: Junio C Hamano @ 2016-10-24 20:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Jakub Narębski, Johannes Sixt, Ramsay Jones
In-Reply-To: <alpine.DEB.2.20.1610231135270.3264@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I still do not understand (note that I am not saying "I do not
>> accept"--acceptance or rejection happens after an understandable
>> explanation is given, and "do not understand" means no such
>> explanation has been given yet) your justification behind adding a
>> technical debt to reimplement the author-script parser and not
>> sharing it with "git am" in 13/27.
>
> At this point, I am most of all reluctant to introduce such a huge change,
> which surely would introduce a regression.
That is a perfectly sensible and honest answer that I can
understand, accept and even support.
You've been working on the series for several months, running with
these dozen or so lines of code, and replacing it with another dozen
or so lines of code would require you to make sure the result is
actually doing the same thing for the remainder of your series. And
I agree that is an unnecessary risk in order to ship a working code.
The code being battle tested counts.
I cared on this point mostly because I wanted to make sure that
people later can find out why there are two functions that ought to
be doing the same thing.
If there were a technical reason why these two must stay to be
different implementations that are potentially doing different
things, I want to see that reason described, so that those who come
later and want to refactor the helper functions into one later will
know why they are separate in the first place.
If on the other hand there isn't any technical reason why they must
stay to be different, and they are different mostly because you
happened to have written a different one in 13/27 and have been
running with it, that is also a good thing for them to know.
^ permalink raw reply
* Re: [PATCH v5 00/27] Prepare the sequencer for the upcoming rebase -i patches
From: Junio C Hamano @ 2016-10-24 20:03 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Stefan Beller, Jeff King, Jakub Narębski, Johannes Sixt,
Ramsay Jones
In-Reply-To: <alpine.DEB.2.20.1610231151140.3264@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I prefer to cook it in 'next' sufficiently long to ensure that we hear
>> feedbacks from non-Windows users if there is any unexpected breakage.
>
> FWIW I am using the same patches not only on Windows but also in my Linux
> VM.
Thanks for a datapoint, but when I said "non-Windows users", I was
not referring you as "the" Windows user. I am expecting that you
would hear from Windows users who got exposure to your series by its
inclusion in Git for Windows. They are the ones that I had in mind
as "Windows users"---and not hearing breakage reported by them would
be a good sign.
The primary reason why we want to cook a new topic in 'next' is to
expose it to people with different workflows using it on different
things, and that is especially more important for a change that
affects features that are flexible and can be used in different
ways---the set of options and commands used by the original author
of the series are often different from other people's.
Any change, when it hits 'next', is expected to be sufficiently
tested by the original author [*1*], but that is only true in the
context of the original author's daily use. Both reviews and
author's tests are not sufficient to find bugs [*2*].
Topics that touch parts of the system that are more important to
users' daily Git life deserve extra time to find any unexpected
breakage in them. Windows users are participating in that test by
inclusion of the topic in the released version of Git for Windows.
I want to see the the test for the rest of the world done by early
adopters who run 'next' (as 'pu' is too scary for daily use).
[Footnote]
*1* And me, as topics geting ready to be in 'next' are first merged
to my private edition branch that is slightly ahead of 'next' to
be used in my everyday use, but just like the original author is
merely one user, I am also merely one user with a specific set
of workflows that is different from others'.
*2* Bug finding is not the primary purpose of the review in the
first place. It is to find design mistakes both at the external
and internal level, and bug finding "here you have off-by-one"
is merely a side effect. End user tests may expose the former
(e.g. the design based on a wrong assumption may not accomodate
certain workflow the original author and the reviewers failed to
consider while writing and reviewing), but no amount of test
will uncover the latter (e.g. internal API that is misdesigned
will make future enhancement unnecessarily harder).
I think it was one of the achievements of the review cycle of
this particular series that we got rid of the _entrust() thing,
for example. That had no visible external effect that would
have been caught by cooking on 'next' or releasing it to the
public, but was the kind of thing the code review was expected
to find and fix.
^ permalink raw reply
* Re: [PATCH v5 00/27] Prepare the sequencer for the upcoming rebase -i patches
From: Junio C Hamano @ 2016-10-24 20:16 UTC (permalink / raw)
To: Stefan Beller
Cc: Johannes Schindelin, git@vger.kernel.org, Jeff King,
Jakub Narębski, Johannes Sixt, Ramsay Jones
In-Reply-To: <CAGZ79kaq85c1Gk1aRSrdQGp1Nm9p6tN0jXbFvTN0v+9ehooxYg@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
>> Speaking of what to and not to include in the upcoming release, we
>> do want to include Stefan's off-by-one fix to the submodule-helper,
>> but that is blocked on Windows end due to the test.
>
> I'd be happy either way, i.e. we could revert that fix and make a release?
> AFAICT, Windows only has broken tests, not broken functionality with that
> submodule bug fix.
If you are referring the "trailing /. should not make difference
when resolving ../relative/path" change with "rever that fix", I
think that may be a reasonable way to proceed. Even though that
change is a bugfix (at least from the point of view by me and j6t in
the recent discussion), it is a behaviour change that we would want
to see feedback from existing submodule users and deserves a longer
gestation period. And that part is not yet in 'next' yet ;-)
> If we want a longer gestation period, we'd ideally merge it to master
> just after a release, such that we "cook" it in master without having
> it in any release (we had a similar discussion for the diff heuristics IIRC).
Yes.
It would mean that we would need a separate patch that adds the
!MINGW prerequisite to some tests to what is on 'next', as the early
patches on sb/submodule-ignore-trailing-slash~ that fixes off-by-one
is the right thing to do either way. It of course needs help from
Windows folks to validate the results.
^ permalink raw reply
* Re: [PATCH 28/36] attr: keep attr stack for each check
From: Junio C Hamano @ 2016-10-24 20:29 UTC (permalink / raw)
To: Stefan Beller; +Cc: git@vger.kernel.org, Brandon Williams, Duy Nguyen
In-Reply-To: <CAGZ79kZ_7eG4uCXwyg0F=-hjmuT1dCAATSRnY293qkNC6siM5Q@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
> I looked for a platform independent way to get a thread id as a natural
> number, i.e. I want to get 1,2,3,... such that I could have just added
> list/array of attr stacks to each check, which would be the
> <check, thread> tuple you envision.
>
> However I think we do not really need it to be per check. If we had
> an easy portable way of getting such a thread id, I would have implemented
> a list of stacks per thread first. (Because each thread only looks at one
> check at a time.)
It seems that by "list of stacks per thread", you mean "there is a
list of stacks, each thread uses one and only element of that list",
but I do not think it would be desirable.
"Each thread only looks at one check at a time" is false. For
example, "write_archive_entry()" would use one check that is
specific to "git archive" to learn about "export-ignore" and
"export-subst" attributes, while letting convert_to_write_tree()
called via sha1_file_to_archive() called via write_entry() method
(i.e. write_tar_entry() or write_zip_entry()) to use a separate
check that is specific to the convert.c API.
>> With manipulation of attr stack protected with a single Big
>> Attributes Lock, this should be safe. It may not perform very well
>> when used by multiple threads, though ;-)
>
> I agree. So maybe it is not really a good fit for general consumption yet.
I would still think it is a good first step. It may already be
thread-safe, but may not be thread-ready from performance point of
view. IOW, this would not yet help an attempt to make the callers
faster by making them multi-threaded.
^ permalink raw reply
* Re: [PATCH 17/36] attr: expose validity check for attribute names
From: Stefan Beller @ 2016-10-24 21:07 UTC (permalink / raw)
To: Ramsay Jones
Cc: Junio C Hamano, git@vger.kernel.org, Brandon Williams, Duy Nguyen
In-Reply-To: <0425fea3-3419-c265-b964-f5a309b867fa@ramsayjones.plus.com>
On Sun, Oct 23, 2016 at 8:07 AM, Ramsay Jones
<ramsay@ramsayjones.plus.com> wrote:
>
>
> On 23/10/16 00:32, Stefan Beller wrote:
>> From: Junio C Hamano <gitster@pobox.com>
>>
>> Export attr_name_valid() function, and a helper function that
>> returns the message to be given when a given <name, len> pair
>> is not a good name for an attribute.
>>
>> We could later update the message to exactly spell out what the
>> rules for a good attribute name are, etc.
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> Signed-off-by: Stefan Beller <sbeller@google.com>
>> ---
>
> [snip]
>
>> +extern int attr_name_valid(const char *name, size_t namelen);
>> +extern void invalid_attr_name_message(struct strbuf *, const char *, int);
>> +
>
> The symbol 'attr_name_valid()' is not used outside of attr.c, even
> by the end of this series. Do you expect this function to be used
> in any future series? (The export is deliberate and it certainly
> seems like it should be part of the public interface, but ...)
>
> In contrast, the 'invalid_attr_name_message()' function is called
> from code in pathspec.c, which relies on 'git_attr_counted()' to
> call 'attr_name_valid()' internally to check for validity. :-D
Yeah, I am taking over Junios patches and do not quite implement
what Junio thought I would. ;) So I guess it is a communication mismatch.
git_attr_counted is a wrapper around attr_name_valid in the way that
it either returns NULL when the attr name is invalid or it does extra work
and returns a pointer to an attr.
So I think for API completeness we'd want to keep attr_name_valid around,
as otherwise the API looks strange. But that doesn't seem like a compelling
reason, so I'll drop it from the header file and make it static.
Thanks,
Stefan
^ permalink raw reply
* Re: Reporting Bug in Git Version Control System
From: Junio C Hamano @ 2016-10-24 21:14 UTC (permalink / raw)
To: Stefan Beller; +Cc: Yash Jain, git@vger.kernel.org
In-Reply-To: <xmqqzilt61jo.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Stefan Beller <sbeller@google.com> writes:
>
>> On Mon, Oct 24, 2016 at 7:28 AM, Yash Jain <yashjain.lnm@gmail.com> wrote:
>>> Hello,
>>> I have two accounts on github("yj291197" and "yaki29").
>>> Both the accounts have different gmail IDs("yj291197@gmail.com" and
>>> "yashjain.lnm@gmail.com" respectively) but same passwords.
>>> I used to use git for "yj291197" account and a few days earlier I made
>>> this new account and used git commit to commit on "yaki29" but it
>>> appeared as "yj291197" committed on "yaki29's" repo.
>>> Then I pulled a request of that commit then it appeared "yaki29"
>>> pulled a request with a commit of "yj291197".
>>>
>>> And during this whole session I was signed in as "yaki29" on github.com .
>>>
>>
>> This is a Github issue, so ask Github support.
>>
>> Or read up on .mailmap files.
>
> I am (obviously) not a GitHub support, but I think the confusion is
> coming from not understanding who the committer and the author of a
> commit are and where they are coming from. They are both recorded
> locally, taken from user.name and user.email configuration variables
> when the commits are made. "git push" to propagate them to GitHub
> will NOT change these values of a commit, once a commit is created.
>
> The story described looks quite consistent if the user has
> yj291197@gmail.com configured as user.email and kept making commits
> in the local repository, and pushed them to either yj291197 or yaki29
> accounts at GitHub, without ever changing the local configuration to
> use the other e-mail address. All commits would record the user and
> e-mail address yj291197, and the only one that may be attributed to
> the new one yaki29 would be the automerge created at GitHub when a
> pull request is responded on-site without first fetching and making
> a merge locally.
IOW, this sounds like Pebkac to me. There is no a thing that needs
fixing in Git, and I do not immediately see there is anything GitHub
needs to fix, either. The user may need fixing, though ;-).
^ permalink raw reply
* Re: revisiting zstd timings
From: Junio C Hamano @ 2016-10-24 21:36 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20161023080552.lma2v6zxmyaiiqz5@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> If we were designing git today, it seems like a no-brainer to use zstd
> over zlib. But given backwards-compatibility issues, I'm not sure.
> 10-20% speedup on reading is awfully nice, but I don't think there's a
> good way to gracefully transition, because zlib is part of the
> on-the-wire format for serving objects. We could re-compress on the fly,
> but that gets expensive (in existing cases, we can quite often serve the
> zlib content straight from disk, but this would require an extra
> inflate/deflate. At least we wouldn't have to reconstitute objects from
> deltas, though).
>
> A transition would probably look something like:
>
> 0. The patch below, or something like it, to teach git to read both
> zlib and zstd, and optionally write zstd. We'd probably want to
> make this an unconditional requirement like zlib, because the point
> is for it to be available everywhere (I assume the zstd code is
> pretty portable, but I haven't put it to the test).
>
> 1. Another patch to add a "zstd" capability to the protocol. This
> would require teaching pack-objects an option to convert zstd back
> to zlib on the fly.
>
> Servers which handle a limited number of updated clients can switch
> to zstd immediately to get the benefit, and their clients can
> handle it directly. Likewise, clients of older servers may wish to
> repack locally using zstd to get the benefit. They'll have to
> recompress on the fly during push, but pushes are rare than other
> operations (and often limited by bandwidth anyway).
>
> 2. After a while, eventually flip the default to zstd=5.
>
> 3. If "a while" is long enough, perhaps add a patch to let servers
> tell clients "go upgrade" rather than recompressing on the fly.
>
> I don't have immediate plans for any of that, but maybe something to
> think about.
Thanks for a write-up. This is quite interesting.
Thanks to d98b46f8d, this does not have to impact the object naming
;-)
^ permalink raw reply
* An anomaly, not a bug
From: m. @ 2016-10-24 21:46 UTC (permalink / raw)
To: git
Concerning ".gitignore", experienced using git 2.10.0
Starting code using one or more spaces or tabs from the left
margin will have git reading .gitignore and ignoring(or
un-ignoring) the command-instruction.
Example: Starting .gitignore
/*
# above line is duly read. Then un-ignoring
# something but starting the command further to the
# right will have git not reading that line
!/nottobeignored.file
End .gitignore
Note: the comments can be started away from the left margin,
as normal in all unix-linux configuration files we know of.
Git follows this behaviour fine.
The lines containing commands, on the contrary of regular
convention cannot be indented by spaces or tabs. Quite
unusual, confusing, not in the sense of conventional and
easily adverted in coding git.
Could be we are missing out on something,
Git command line tool is a functional tool now in our setup
for two years, first noticed this alien behaviour in this
version of git, on osx, the fink(osx package mananger)
binary.
^ permalink raw reply
* [PATCH] doc: fix the 'revert a faulty merge' ASCII art tab spacing
From: Philip Oakley @ 2016-10-24 21:54 UTC (permalink / raw)
To: gitster; +Cc: Johannes.Schindelin, git, peff, philipoakley
In-Reply-To: <xmqq1sz9b9ex.fsf@gitster.mtv.corp.google.com>
The asciidoctor doc-tool stack does not always respect the 'tab = 8 spaces' rule
expectation, particularly for the Git-for-Windows generated html pages. This
follows on from the 'doc: fix merge-base ASCII art tab spacing' fix.
Use just spaces within the block of the ascii art.
All other *.txt ascii art containing three dashes has been checked.
Asciidoctor correctly formats the other art blocks that do contain tabs.
Signed-off-by: Philip Oakley <philipoakley@iee.org
---
The git-scm doc pages https://git-scm.com/docs/ does not convert this
how-to document to html, rather it links to the Github text pages, which
does respect the 8 space tab rule.
---
Documentation/howto/revert-a-faulty-merge.txt | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt
index 462255e..19f59cc 100644
--- a/Documentation/howto/revert-a-faulty-merge.txt
+++ b/Documentation/howto/revert-a-faulty-merge.txt
@@ -30,7 +30,7 @@ The history immediately after the "revert of the merge" would look like
this:
---o---o---o---M---x---x---W
- /
+ /
---A---B
where A and B are on the side development that was not so good, M is the
@@ -47,7 +47,7 @@ After the developers of the side branch fix their mistakes, the history
may look like this:
---o---o---o---M---x---x---W---x
- /
+ /
---A---B-------------------C---D
where C and D are to fix what was broken in A and B, and you may already
@@ -81,7 +81,7 @@ In such a situation, you would want to first revert the previous revert,
which would make the history look like this:
---o---o---o---M---x---x---W---x---Y
- /
+ /
---A---B-------------------C---D
where Y is the revert of W. Such a "revert of the revert" can be done
@@ -93,14 +93,14 @@ This history would (ignoring possible conflicts between what W and W..Y
changed) be equivalent to not having W or Y at all in the history:
---o---o---o---M---x---x-------x----
- /
+ /
---A---B-------------------C---D
and merging the side branch again will not have conflict arising from an
earlier revert and revert of the revert.
---o---o---o---M---x---x-------x-------*
- / /
+ / /
---A---B-------------------C---D
Of course the changes made in C and D still can conflict with what was
@@ -111,13 +111,13 @@ faulty A and B, and redone the changes on top of the updated mainline
after the revert, the history would have looked like this:
---o---o---o---M---x---x---W---x---x
- / \
+ / \
---A---B A'--B'--C'
If you reverted the revert in such a case as in the previous example:
---o---o---o---M---x---x---W---x---x---Y---*
- / \ /
+ / \ /
---A---B A'--B'--C'
where Y is the revert of W, A' and B' are rerolled A and B, and there may
@@ -129,7 +129,7 @@ lot of overlapping changes that result in conflicts. So do not do "revert
of revert" blindly without thinking..
---o---o---o---M---x---x---W---x---x
- / \
+ / \
---A---B A'--B'--C'
In the history with rebased side branch, W (and M) are behind the merge
--
2.9.0.windows.1.323.g0305acf
^ permalink raw reply related
* Re: An anomaly, not a bug
From: Alexei Lozovsky @ 2016-10-24 22:20 UTC (permalink / raw)
To: m.; +Cc: git
In-Reply-To: <20161024214601.GA11699@hostname_variable_in_muttrc>
> Note: the comments can be started away from the left margin,
> as normal in all unix-linux configuration files we know of.
> Git follows this behaviour fine.
Actually, git reads
# comment
as 'ignore files with name " " (4 spaces)', and then a comment.
It does not ignore the leading whitespace.
^ permalink raw reply
* Re: [PATCH] hex: use unsigned index for ring buffer
From: René Scharfe @ 2016-10-24 22:33 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: Git List
In-Reply-To: <xmqqshrl7j42.fsf@gitster.mtv.corp.google.com>
Am 24.10.2016 um 19:27 schrieb Junio C Hamano:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>> I think it would be preferable to just fix it inline in each place.
>>
>> Yeah, probably.
>>
>> My initial reaction to this was
>>
>> char *sha1_to_hex(const unsigned char *sha1)
>> {
>> - static int bufno;
>> + static unsigned int bufno;
>> static char hexbuffer[4][GIT_SHA1_HEXSZ + 1];
>> return sha1_to_hex_r(hexbuffer[3 & ++bufno], sha1);
>>
>> "ah, we do not even need bufno as uint; it could be ushort or even
>> uchar". If this were a 256 element ring buffer and the index were
>> uchar, we wouldn't even be having this discussion, and "3 &" is a
>> way to get a fake type that is a 2-bit unsigned integer that wraps
>> around when incremented.
>>
>> But being explicit, especially when we know that we can rely on the
>> fact that the compilers are usually intelligent enough, is a good
>> idea, I would think.
>>
>> Isn't size_t often wider than uint, by the way? It somehow makes me
>> feel dirty to use it when we know we only care about the bottom two
>> bit, especially with the explicit "bufno %= ARRAY_SIZE(hexbuffer)",
>> but I may be simply superstitious in this case. I dunno.
>
> If we are doing the wrap-around ourselves, I suspect that the index
> should stay "int" (not even unsigned), as that is supposed to be the
> most natural and performant type on the architecture. Would it
> still result in better code to use size_t instead?
Right.
Gcc emits an extra cltq instruction for x86-64 (Convert Long To Quad,
i.e. 32-bit to 64-bit) if we wrap explicitly and still use an int in
sha1_to_hex(). It doesn't if we use an unsigned int or size_t. It
also doesn't for get_pathname(). I guess updating the index variable
only after use makes the difference there.
But I think we can ignore that; it's just an extra cycle. I only
even noticed it when verifying that "% 4" is turned into "& 3"..
Clang and icc don't add the cltq, by the way.
So how about this? It gets rid of magic number 3 and works for array
size that's not a power of two. And as a nice side effect it can't
trigger a signed overflow anymore.
Just adding "unsigned" looks more attractive to me for some reason.
Perhaps I stared enough at the code to get used to the magic values
there..
René
---
hex.c | 3 ++-
path.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/hex.c b/hex.c
index ab2610e..845b01a 100644
--- a/hex.c
+++ b/hex.c
@@ -78,7 +78,8 @@ char *sha1_to_hex(const unsigned char *sha1)
{
static int bufno;
static char hexbuffer[4][GIT_SHA1_HEXSZ + 1];
- return sha1_to_hex_r(hexbuffer[3 & ++bufno], sha1);
+ bufno = (bufno + 1) % ARRAY_SIZE(hexbuffer);
+ return sha1_to_hex_r(hexbuffer[bufno], sha1);
}
char *oid_to_hex(const struct object_id *oid)
diff --git a/path.c b/path.c
index a8e7295..52d889c 100644
--- a/path.c
+++ b/path.c
@@ -25,7 +25,8 @@ static struct strbuf *get_pathname(void)
STRBUF_INIT, STRBUF_INIT, STRBUF_INIT, STRBUF_INIT
};
static int index;
- struct strbuf *sb = &pathname_array[3 & ++index];
+ struct strbuf *sb = &pathname_array[index];
+ index = (index + 1) % ARRAY_SIZE(pathname_array);
strbuf_reset(sb);
return sb;
}
--
2.10.1
^ permalink raw reply related
* Re: An anomaly, not a bug
From: Alexei Lozovsky @ 2016-10-24 22:47 UTC (permalink / raw)
To: m.; +Cc: git
In-Reply-To: <CALhvvbYnTf9qqsCFWjgfnynRy9LDEQf=Y++2tQioTKHbaYGHDA@mail.gmail.com>
> Actually, git reads
>
> # comment
>
> as 'ignore files with name " " (4 spaces)', and then a comment.
> It does not ignore the leading whitespace.
Even not as a comment, it treats it as literally a filename with
a hash and that comment in it. However, one (usually) does not
name their files like that, so for all purposes this can be thought
of as a sort of comment.
^ permalink raw reply
* [PATCH] reset: --unmerge
From: Junio C Hamano @ 2016-10-24 23:10 UTC (permalink / raw)
To: git
The procedure to resolve a merge conflict typically goes like this:
- first open the file in the editor, and with the help of conflict
markers come up with a resolution.
- save the file.
- look at the output from "git diff" to see the combined diff to
double check if the resolution makes sense.
- perform other tests, like trying to build the result with "make".
- finally "git add file" to mark that you are done.
and repeating the above until you are done with all the conflicted
paths. If you, for whatever reason, accidentally "git add file" by
mistake until you are convinced that you resolved it correctly (e.g.
doing "git add file" immediately after saving, without a chance to
peruse the output from "git diff"), there is no good way to recover.
There is "git checkout -m file" but that overwrites the working tree
file to reproduce the conflicted state, which is not exactly what
you want. You only want to reproduce the conflicted state in the
index, so that you can inspect the (proposed) merge resolution you
already have in your working tree.
Add "git reset --unmerge <paths>" command that does just that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Not thought through thoroughly yet about details, such as "should
it always require at least one pathspec?".
builtin/reset.c | 8 +++++++-
t/t7107-reset-unmerged.sh | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 9020ec66c8..3aa9e0b34a 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -21,6 +21,7 @@
#include "parse-options.h"
#include "unpack-trees.h"
#include "cache-tree.h"
+#include "resolve-undo.h"
static const char * const git_reset_usage[] = {
N_("git reset [--mixed | --soft | --hard | --merge | --keep] [-q] [<commit>]"),
@@ -272,6 +273,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
struct object_id oid;
struct pathspec pathspec;
int intent_to_add = 0;
+ int unmerge = 0;
const struct option options[] = {
OPT__QUIET(&quiet, N_("be quiet, only report errors")),
OPT_SET_INT(0, "mixed", &reset_type,
@@ -286,6 +288,8 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
OPT_BOOL('p', "patch", &patch_mode, N_("select hunks interactively")),
OPT_BOOL('N', "intent-to-add", &intent_to_add,
N_("record only the fact that removed paths will be added later")),
+ OPT_BOOL(0, "unmerge", &unmerge,
+ N_("recover conflicted stages from an earlier 'git add'")),
OPT_END()
};
@@ -357,7 +361,9 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
hold_locked_index(lock, 1);
if (reset_type == MIXED) {
int flags = quiet ? REFRESH_QUIET : REFRESH_IN_PORCELAIN;
- if (read_from_tree(&pathspec, oid.hash, intent_to_add))
+ if (unmerge)
+ unmerge_cache(&pathspec);
+ else if (read_from_tree(&pathspec, oid.hash, intent_to_add))
return 1;
if (get_git_work_tree())
refresh_index(&the_index, flags, NULL, NULL,
diff --git a/t/t7107-reset-unmerged.sh b/t/t7107-reset-unmerged.sh
new file mode 100755
index 0000000000..57b2e27150
--- /dev/null
+++ b/t/t7107-reset-unmerged.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+
+test_description='git reset with paths'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo one >file &&
+ git add file &&
+ git commit -m "one" &&
+ git tag initial &&
+
+ echo two >file &&
+ git commit -a -m "two" &&
+
+ git checkout -b side initial &&
+ echo three >file &&
+ git commit -a -m "three"
+'
+
+test_expect_success "cause conflict, resolve, and unresolve" '
+ git reset --hard &&
+ git checkout master &&
+ test_must_fail git merge side &&
+
+ git ls-files -u >expect &&
+
+ echo four >file &&
+ git add file &&
+
+ git reset --unmerge -- file &&
+ git ls-files -u >actual &&
+ test_cmp expect actual
+'
+
+test_done
^ permalink raw reply related
* [PATCH] Allow stashes to be referenced by index only
From: Aaron M Watson @ 2016-10-24 23:40 UTC (permalink / raw)
To: git
Cc: Aaron M Watson, Jon Seymour, David Caldwell, Øystein Walle,
Jeff King, Ævar Arnfjörð Bjarmason, David Aguilar,
Alex Henrie
In-Reply-To: <1473378397-22453-1-git-send-email-watsona4@gmail.com>
Instead of referencing "stash@{n}" explicitly, it can simply be
referenced as "n". Most users only reference stashes by their position
in the stash stask (what I refer to as the "index"). The syntax for the
typical stash (stash@{n}) is slightly annoying and easy to forget, and
sometimes difficult to escape properly in a script. Because of this the
capability to do things with the stash by simply referencing the index
is desirable.
This patch includes the superior implementation provided by Øsse Walle
(thanks for that), with a slight change to fix a broken test in the test
suite. I also merged the test scripts as suggested by Jeff King, and
un-wrapped the documentation as suggested by Junio Hamano.
Signed-off-by: Aaron M Watson <watsona4@gmail.com>
---
Documentation/git-stash.txt | 3 ++-
git-stash.sh | 15 +++++++++++++--
t/t3903-stash.sh | 35 +++++++++++++++++++++++++++++++++++
3 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 92df596..2e9cef0 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -39,7 +39,8 @@ The latest stash you created is stored in `refs/stash`; older
stashes are found in the reflog of this reference and can be named using
the usual reflog syntax (e.g. `stash@{0}` is the most recently
created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}`
-is also possible).
+is also possible). Stashes may also be referenced by specifying just the
+stash index (e.g. the integer `n` is equivalent to `stash@{n}`).
OPTIONS
-------
diff --git a/git-stash.sh b/git-stash.sh
index 826af18..d7072c8 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -384,9 +384,8 @@ parse_flags_and_rev()
i_tree=
u_tree=
- REV=$(git rev-parse --no-flags --symbolic --sq "$@") || exit 1
-
FLAGS=
+ REV=
for opt
do
case "$opt" in
@@ -404,6 +403,9 @@ parse_flags_and_rev()
die "$(eval_gettext "unknown option: \$opt")"
FLAGS="${FLAGS}${FLAGS:+ }$opt"
;;
+ *)
+ REV="${REV}${REV:+ }'$opt'"
+ ;;
esac
done
@@ -422,6 +424,15 @@ parse_flags_and_rev()
;;
esac
+ case "$1" in
+ *[!0-9]*)
+ :
+ ;;
+ *)
+ set -- "${ref_stash}@{$1}"
+ ;;
+ esac
+
REV=$(git rev-parse --symbolic --verify --quiet "$1") || {
reference="$1"
die "$(eval_gettext "\$reference is not a valid reference")"
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 2142c1f..f82a8c4 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -131,6 +131,26 @@ test_expect_success 'drop middle stash' '
test 1 = $(git show HEAD:file)
'
+test_expect_success 'drop middle stash by index' '
+ git reset --hard &&
+ echo 8 >file &&
+ git stash &&
+ echo 9 >file &&
+ git stash &&
+ git stash drop 1 &&
+ test 2 = $(git stash list | wc -l) &&
+ git stash apply &&
+ test 9 = $(cat file) &&
+ test 1 = $(git show :file) &&
+ test 1 = $(git show HEAD:file) &&
+ git reset --hard &&
+ git stash drop &&
+ git stash apply &&
+ test 3 = $(cat file) &&
+ test 1 = $(git show :file) &&
+ test 1 = $(git show HEAD:file)
+'
+
test_expect_success 'stash pop' '
git reset --hard &&
git stash pop &&
@@ -604,7 +624,21 @@ test_expect_success 'invalid ref of the form stash@{n}, n >= N' '
git stash drop
'
+test_expect_success 'invalid ref of the form "n", n >= N' '
+ git stash clear &&
+ test_must_fail git stash drop 0 &&
+ echo bar5 >file &&
+ echo bar6 >file2 &&
+ git add file2 &&
+ git stash &&
+ test_must_fail git stash drop 1 &&
+ test_must_fail git stash pop 1 &&
+ test_must_fail git stash apply 1 &&
+ test_must_fail git stash show 1 &&
+ test_must_fail git stash branch tmp 1 &&
+ git stash drop
+'
+
test_expect_success 'stash branch should not drop the stash if the branch exists' '
git stash clear &&
echo foo >file &&
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] hex: use unsigned index for ring buffer
From: Junio C Hamano @ 2016-10-24 23:53 UTC (permalink / raw)
To: René Scharfe; +Cc: Jeff King, Git List
In-Reply-To: <b1f9054e-fadb-c2d3-bf95-00e88e1fb85b@web.de>
René Scharfe <l.s.r@web.de> writes:
> Am 24.10.2016 um 19:27 schrieb Junio C Hamano:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>>> I think it would be preferable to just fix it inline in each place.
>>>
>>> Yeah, probably.
>>>
>>> My initial reaction to this was
>>>
>>> char *sha1_to_hex(const unsigned char *sha1)
>>> {
>>> - static int bufno;
>>> + static unsigned int bufno;
>>> static char hexbuffer[4][GIT_SHA1_HEXSZ + 1];
>>> return sha1_to_hex_r(hexbuffer[3 & ++bufno], sha1);
>>>
>>> "ah, we do not even need bufno as uint; it could be ushort or even
>>> uchar". If this were a 256 element ring buffer and the index were
>>> uchar, we wouldn't even be having this discussion, and "3 &" is a
>>> way to get a fake type that is a 2-bit unsigned integer that wraps
>>> around when incremented.
>>>
>>> But being explicit, especially when we know that we can rely on the
>>> fact that the compilers are usually intelligent enough, is a good
>>> idea, I would think.
>>>
>>> Isn't size_t often wider than uint, by the way? It somehow makes me
>>> feel dirty to use it when we know we only care about the bottom two
>>> bit, especially with the explicit "bufno %= ARRAY_SIZE(hexbuffer)",
>>> but I may be simply superstitious in this case. I dunno.
>>
>> If we are doing the wrap-around ourselves, I suspect that the index
>> should stay "int" (not even unsigned), as that is supposed to be the
>> most natural and performant type on the architecture. Would it
>> still result in better code to use size_t instead?
>
> Right.
>
> Gcc emits an extra cltq instruction for x86-64 (Convert Long To Quad,
> i.e. 32-bit to 64-bit) if we wrap explicitly and still use an int in
> sha1_to_hex(). It doesn't if we use an unsigned int or size_t. It
> also doesn't for get_pathname(). I guess updating the index variable
> only after use makes the difference there.
>
> But I think we can ignore that; it's just an extra cycle. I only
> even noticed it when verifying that "% 4" is turned into "& 3"..
> Clang and icc don't add the cltq, by the way.
>
> So how about this? It gets rid of magic number 3 and works for array
> size that's not a power of two. And as a nice side effect it can't
> trigger a signed overflow anymore.
Looks good to me. Peff?
> Just adding "unsigned" looks more attractive to me for some reason.
> Perhaps I stared enough at the code to get used to the magic values
> there..
I somehow share that feeling, too.
^ permalink raw reply
* Re: [PATCH] hex: use unsigned index for ring buffer
From: Jeff King @ 2016-10-25 0:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Git List
In-Reply-To: <xmqq60ohtib5.fsf@gitster.mtv.corp.google.com>
On Mon, Oct 24, 2016 at 04:53:50PM -0700, Junio C Hamano wrote:
> > So how about this? It gets rid of magic number 3 and works for array
> > size that's not a power of two. And as a nice side effect it can't
> > trigger a signed overflow anymore.
>
> Looks good to me. Peff?
Any of the variants discussed in this thread is fine by me.
-Peff
^ permalink raw reply
* What's cooking in git.git (Oct 2016, #06; Mon, 24)
From: Junio C Hamano @ 2016-10-25 1:09 UTC (permalink / raw)
To: git
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.
Originally I planed to start concluding this cycle today, but
waiting for the conclusion of a few test breakages on Windows, I
didn't tag -rc0 today.
Here are my current thinking on the notable topics.
- the "off-by-one fix" part of sb/submodule-ignore-trailing-slash
needs to be in the upcoming release but the "trailing /. in base
should not affect the resolution of ../relative/path" part that
is still under discussion can wait. Which means we'd need a few
more !MINGW prerequisites in the tests by -rc0.
- js/prepare-sequencer topic is not yet in 'next' but it would be a
nice-to-have in the upcoming release if we can. It does not yet
touch "rebase -i", but does touch the sequencer code that is used
in cherry-pick and revert, so I'd prefer to cook it for at least
a week and half in 'next' before merging.
- ls/filter-process topic has been in 'next' with one known test
breakage on Windows, whose resolution ls/git-open-cloexec is
close to its final shape. Perhaps we can cook them for at least
a week and half in 'next' and have it in the upcoming release.
- ex/deprecate-empty-pathspec-as-match-all topic that makes it
illegal to say 'git add ""' when you mean 'git add .' has been in
'next' for more than a cycle. I am inclined to merge it in the
upcoming release.
- jc/merge-drop-old-syntax is relatively new in 'next' after all
known in-tree dependents have been updated. I am planning to
keep it cooking in 'next' but add a backward incompatibility
notice to the release notes to the upcoming release.
- lt/abbrev-auto and its follow-up jk/abbrev-auto are about auto
scaling the default abbreviation length when Git produces a short
object name to adjust to the modern times. Peff noticed one
fallout from it recently and its fix jc/abbrev-auto is not yet in
'next'. I would not be surprised if there are other uncovered
fallouts remaining in the code, but at the same time, I expect
they are all cosmetic kind that do not affect correctness, so I
am inclined to include all of them in the upcoming release.
I plan to merge other smallish topics that have been in 'next' to
'master' soonish, and relabel the remainder that have been labeled
as "Will merge to 'master'" to "Will hold" and keep cooking them in
'next'. For this reason, please do not take the "Will merge to
'master'" label too literally in this issue of "What's cooking"
report. It is always true that the label only means "the topic will
be in 'master' eventually", not "the topic will be in the upcoming
release", but in this issue that is even more true than usual.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* jk/tap-verbose-fix (2016-10-24) 4 commits
(merged to 'next' on 2016-10-24 at 5073a4de2d)
+ test-lib: bail out when "-v" used under "prove"
(merged to 'next' on 2016-10-21 at 592679411c)
+ travis: use --verbose-log test option
+ test-lib: add --verbose-log option
+ test-lib: handle TEST_OUTPUT_DIRECTORY with spaces
The Travis CI configuration we ship ran the tests with --verbose
option but this risks non-TAP output that happens to be "ok" to be
misinterpreted as TAP signalling a test that passed. This resulted
in unnecessary failure. This has been corrected by introducing a
new mode to run our tests in the test harness to send the verbose
output separately to the log file.
Will merge to 'master'.
* po/fix-doc-merge-base-illustration (2016-10-21) 1 commit
(merged to 'next' on 2016-10-21 at ac6f04a6c5)
+ doc: fix merge-base ASCII art tab spacing
Some AsciiDoc formatter mishandles a displayed illustration with
tabs in it. Adjust a few of them in merge-base documentation to
work around them.
Will merge to 'master'.
* jc/abbrev-auto (2016-10-22) 4 commits
- transport: compute summary-width dynamically
- transport: allow summary-width to be computed dynamically
- fetch: pass summary_width down the callchain
- transport: pass summary_width down the callchain
(this branch uses jk/abbrev-auto and lt/abbrev-auto.)
"git push" and "git fetch" reports from what old object to what new
object each ref was updated, using abbreviated refnames, and they
attempt to align the columns for this and other pieces of
information. The way these codepaths compute how many display
columns to allocate for the object names portion of this output has
been updated to match the recent "auto scale the default
abbreviation length" change.
Will merge to 'next'.
* jc/reset-unmerge (2016-10-24) 1 commit
- reset: --unmerge
After "git add" is run prematurely during a conflict resolution,
"git diff" can no longer be used as a way to sanity check by
looking at the combined diff. "git reset" learned a new
"--unmerge" option to recover from this situation.
* jk/daemon-path-ok-check-truncation (2016-10-24) 1 commit
- daemon: detect and reject too-long paths
"git daemon" used fixed-length buffers to turn URL to the
repository the client asked for into the server side directory
path, using snprintf() to avoid overflowing these buffers, but
allowed possibly truncated paths to the directory. This has been
tightened to reject such a request that causes overlong path to be
required to serve.
Will merge to 'next'.
* ls/git-open-cloexec (2016-10-24) 3 commits
- SQUASH???
- read-cache: make sure file handles are not inherited by child processes
- sha1_file: open window into packfiles with CLOEXEC
Git generally does not explicitly close file descriptors that were
open in the parent process when spawning a child process, but most
of the time the child does not want to access them. As Windows does
not allow removing or renaming a file that has a file descriptor
open, a slow-to-exit child can even break the parent process by
holding onto them. Use O_CLOEXEC flag to open files in various
codepaths.
Under discussion.
cf. <20161024183900.GA12769@starla>
This needs to be merged before ls/filter-process so that it won't
break Windows.
* rs/ring-buffer-wraparound (2016-10-24) 1 commit
- hex: make wraparound of the index into ring-buffer explicit
The code that we have used for the past 10+ years to cycle
4-element ring buffers turns out to be not quite portable in
theoretical world.
Under discussion.
cf. <b1f9054e-fadb-c2d3-bf95-00e88e1fb85b@web.de>
--------------------------------------------------
[Stalled]
* jc/bundle (2016-03-03) 6 commits
- index-pack: --clone-bundle option
- Merge branch 'jc/index-pack' into jc/bundle
- bundle v3: the beginning
- bundle: keep a copy of bundle file name in the in-core bundle header
- bundle: plug resource leak
- bundle doc: 'verify' is not about verifying the bundle
The beginning of "split bundle", which could be one of the
ingredients to allow "git clone" traffic off of the core server
network to CDN.
While I think it would make it easier for people to experiment and
build on if the topic is merged to 'next', I am at the same time a
bit reluctant to merge an unproven new topic that introduces a new
file format, which we may end up having to support til the end of
time. It is likely that to support a "prime clone from CDN", it
would need a lot more than just "these are the heads and the pack
data is over there", so this may not be sufficient.
Will discard.
* mh/connect (2016-06-06) 10 commits
- connect: [host:port] is legacy for ssh
- connect: move ssh command line preparation to a separate function
- connect: actively reject git:// urls with a user part
- connect: change the --diag-url output to separate user and host
- connect: make parse_connect_url() return the user part of the url as a separate value
- connect: group CONNECT_DIAG_URL handling code
- connect: make parse_connect_url() return separated host and port
- connect: re-derive a host:port string from the separate host and port variables
- connect: call get_host_and_port() earlier
- connect: document why we sometimes call get_port after get_host_and_port
Rewrite Git-URL parsing routine (hopefully) without changing any
behaviour.
It has been two months without any support. We may want to discard
this.
* kn/ref-filter-branch-list (2016-05-17) 17 commits
- branch: implement '--format' option
- branch: use ref-filter printing APIs
- branch, tag: use porcelain output
- ref-filter: allow porcelain to translate messages in the output
- ref-filter: add `:dir` and `:base` options for ref printing atoms
- ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
- ref-filter: introduce symref_atom_parser() and refname_atom_parser()
- ref-filter: introduce refname_atom_parser_internal()
- ref-filter: make "%(symref)" atom work with the ':short' modifier
- ref-filter: add support for %(upstream:track,nobracket)
- ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
- ref-filter: introduce format_ref_array_item()
- ref-filter: move get_head_description() from branch.c
- ref-filter: modify "%(objectname:short)" to take length
- ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
- ref-filter: include reference to 'used_atom' within 'atom_value'
- ref-filter: implement %(if), %(then), and %(else) atoms
The code to list branches in "git branch" has been consolidated
with the more generic ref-filter API.
Rerolled.
Needs review.
* ec/annotate-deleted (2015-11-20) 1 commit
- annotate: skip checking working tree if a revision is provided
Usability fix for annotate-specific "<file> <rev>" syntax with deleted
files.
Has been waiting for a review for too long without seeing anything.
Will discard.
* dk/gc-more-wo-pack (2016-01-13) 4 commits
- gc: clean garbage .bitmap files from pack dir
- t5304: ensure non-garbage files are not deleted
- t5304: test .bitmap garbage files
- prepare_packed_git(): find more garbage
Follow-on to dk/gc-idx-wo-pack topic, to clean up stale
.bitmap and .keep files.
Has been waiting for a reroll for too long.
cf. <xmqq60ypbeng.fsf@gitster.mtv.corp.google.com>
Will discard.
* jc/diff-b-m (2015-02-23) 5 commits
. WIPWIP
. WIP: diff-b-m
- diffcore-rename: allow easier debugging
- diffcore-rename.c: add locate_rename_src()
- diffcore-break: allow debugging
"git diff -B -M" produced incorrect patch when the postimage of a
completely rewritten file is similar to the preimage of a removed
file; such a resulting file must not be expressed as a rename from
other place.
The fix in this patch is broken, unfortunately.
Will discard.
--------------------------------------------------
[Cooking]
* jc/merge-base-fp-only (2016-10-19) 8 commits
. merge-base: fp experiment
- merge: allow to use only the fp-only merge bases
- merge-base: limit the output to bases that are on first-parent chain
- merge-base: mark bases that are on first-parent chain
- merge-base: expose get_merge_bases_many_0() a bit more
- merge-base: stop moving commits around in remove_redundant()
- sha1_name: remove ONELINE_SEEN bit
- commit: simplify fastpath of merge-base
An experiment of merge-base that ignores common ancestors that are
not on the first parent chain.
* bw/submodule-branch-dot-doc (2016-10-19) 1 commit
(merged to 'next' on 2016-10-21 at 18aad25ba8)
+ submodules doc: update documentation for "." used for submodule branches
Recent git allows submodule.<name>.branch to use a special token
"." instead of the branch name; the documentation has been updated
to describe it.
Will merge to 'master'.
* tg/add-chmod+x-fix (2016-10-20) 1 commit
(merged to 'next' on 2016-10-21 at 1585ac7139)
+ t3700: fix broken test under !SANITY
A hot-fix for a test added by a recent topic that went to both
'master' and 'maint' already.
Will merge to 'master'.
* jk/diff-submodule-diff-inline (2016-10-20) 1 commit
(merged to 'next' on 2016-10-21 at 13f300805e)
+ rev-list: use hdr_termination instead of a always using a newline
A recently graduated topic regressed "git rev-list --header"
output, breaking "gitweb". This has been fixed.
Will merge to 'master'.
* jk/no-looking-at-dotgit-outside-repo (2016-10-20) 8 commits
- setup_git_env: avoid blind fall-back to ".git"
- diff: handle sha1 abbreviations outside of repository
- diff_aligned_abbrev: use "struct oid"
- diff_unique_abbrev: rename to diff_aligned_abbrev
- find_unique_abbrev: use 4-buffer ring
- test-*-cache-tree: setup git dir
- read info/{attributes,exclude} only when in repository
- Merge branch 'jc/diff-unique-abbrev-comments' into jk/no-looking-at-dotgit-outside-repo
(this branch uses jc/diff-unique-abbrev-comments.)
Update "git diff --no-index" codepath not to try to peek into .git/
directory that happens to be under the current directory, when we
know we are operating outside any repository.
Will wait until 'jc/diff-unique-abbrev-comments' graduates, rebase
onto 'master' and then cook in 'next'.
* pt/gitgui-updates (2016-10-20) 35 commits
(merged to 'next' on 2016-10-21 at 4c8214095a)
+ Merge tag 'gitgui-0.21.0' of git://repo.or.cz/git-gui
+ git-gui: set version 0.21
+ Merge branch 'as/bulgarian' into pu
+ git-gui: Mark 'All' in remote.tcl for translation
+ git-gui i18n: Updated Bulgarian translation (565,0f,0u)
+ Merge branch 'os/preserve-author' into pu
+ git-gui: avoid persisting modified author identity
+ git-gui: Do not reset author details on amend
+ Merge branch 'kb/unicode' into pu
+ git-gui: handle the encoding of Git's output correctly
+ git-gui: unicode file name support on windows
+ Merge branch 'dr/ru' into pu
+ git-gui: Update Russian translation
+ git-gui: maintain backwards compatibility for merge syntax
+ Merge branch 'va/i18n_2' into pu
+ git-gui i18n: mark string in lib/error.tcl for translation
+ git-gui: fix incorrect use of Tcl append command
+ git-gui i18n: mark "usage:" strings for translation
+ git-gui i18n: internationalize use of colon punctuation
+ Merge branch 'pt/non-mouse-usage' into pu
+ Amend tab ordering and text widget border and highlighting.
+ Allow keyboard control to work in the staging widgets.
+ Merge branch 'pt/git4win-mods' into pu
+ git-gui (Windows): use git-gui.exe in `Create Desktop Shortcut`
+ git-gui: fix detection of Cygwin
+ Merge branch 'patches' into pu
+ git-gui: ensure the file in the diff pane is in the list of selected files
+ git-gui: support for $FILENAMES in tool definitions
+ git-gui: fix initial git gui message encoding
+ git-gui/po/glossary/txt-to-pot.sh: use the $( ... ) construct for command substitution
+ Merge branch 'va/i18n' into pu
+ Merge branch 'rs/use-modern-git-merge-syntax' into pu
+ Merge branch 'js/commit-gpgsign' into pu
+ Merge branch 'sy/i18n' into pu
+ git-gui: sort entries in tclIndex
A new version of git-gui, now at its 0.21.0 tag.
Will merge to 'master'.
* yk/git-tag-remove-mention-of-old-layout-in-doc (2016-10-20) 1 commit
(merged to 'next' on 2016-10-21 at 8d9e23b023)
+ doc: remove reference to the traditional layout in git-tag.txt
Shorten description of auto-following in "git tag" by removing a
mention of historical remotes layout which is not relevant to the
main topic.
Will merge to 'master'.
* dk/worktree-dup-checkout-with-bare-is-ok (2016-10-14) 1 commit
(merged to 'next' on 2016-10-17 at 24594d3e56)
+ worktree: allow the main brach of a bare repository to be checked out
In a worktree connected to a repository elsewhere, created via "git
worktree", "git checkout" attempts to protect users from confusion
by refusing to check out a branch that is already checked out in
another worktree. However, this also prevented checking out a
branch, which is designated as the primary branch of a bare
reopsitory, in a worktree that is connected to the bare
repository. The check has been corrected to allow it.
Will merge to 'master'.
* jc/cocci-xstrdup-or-null (2016-10-12) 1 commit
(merged to 'next' on 2016-10-17 at 55ceaa465a)
+ cocci: refactor common patterns to use xstrdup_or_null()
Code cleanup.
Will merge to 'master'.
* tb/convert-stream-check (2016-10-12) 2 commits
- convert.c: stream and fast search for binary
- read-cache: factor out get_sha1_from_index() helper
End-of-line conversion sometimes needs to see if the current blob
in the index has NULs and CRs to base its decision. We used to
always get a full statistics over the blob, but in many cases we
can return early when we have seen "enough" (e.g. if we see a
single NUL, the blob will be handled as binary). The codepaths
have been optimized by using streaming interface.
Waiting for review.
* jk/ambiguous-short-object-names (2016-10-12) 1 commit
(merged to 'next' on 2016-10-19 at e7c55a9da5)
+ t1512: become resilient to GETTEXT_POISON build
A test fixup to recently graduated topic.
Will merge to 'master'.
* jk/merge-base-fork-point-without-reflog (2016-10-12) 1 commit
(merged to 'next' on 2016-10-19 at 00a6797f62)
+ merge-base: handle --fork-point without reflog
"git rebase" immediately after "git clone" failed to find the fork
point from the upstream.
Will merge to 'master'.
* jk/upload-pack-use-prio-queue (2016-10-11) 1 commit
(merged to 'next' on 2016-10-19 at 1d6efb07ac)
+ upload-pack: use priority queue in reachable() check
Code clean-up and performance improvement to reduce use of
timestamp-ordered commit-list by replacing it with a priority
queue.
Will merge to 'master'.
* jk/fetch-quick-tag-following (2016-10-14) 1 commit
(merged to 'next' on 2016-10-19 at d7718dcdf5)
+ fetch: use "quick" has_sha1_file for tag following
When fetching from a remote that has many tags that are irrelevant
to branches we are following, we used to waste way too many cycles
when checking if the object pointed at by a tag (that we are not
going to fetch!) exists in our repository too carefully.
Will merge to 'master'.
* jt/trailer-with-cruft (2016-10-21) 8 commits
- trailer: support values folded to multiple lines
- trailer: forbid leading whitespace in trailers
- trailer: allow non-trailers in trailer block
- trailer: clarify failure modes in parse_trailer
- trailer: make args have their own struct
- trailer: streamline trailer item create and add
- trailer: use list.h for doubly-linked list
- trailer: improve const correctness
Update "interpret-trailers" machinery and teaches it that people in
real world write all sorts of crufts in the "trailer" that was
originally designed to have the neat-o "Mail-Header: like thing"
and nothing else.
Waiting for review.
* mm/send-email-cc-cruft-after-address (2016-10-21) 3 commits
(merged to 'next' on 2016-10-21 at c7ec2b5025)
+ Git.pm: add comment pointing to t9000
+ t9000-addresses: update expected results after fix
(merged to 'next' on 2016-10-19 at 41e3f876cd)
+ parse_mailboxes: accept extra text after <...> address
"git send-email" attempts to pick up valid e-mails from the
trailers, but people in real world write non-addresses there, like
"Cc: Stable <add@re.ss> # 4.8+", which broke the output depending
on the availability and vintage of Mail::Address perl module.
Will merge to 'master'.
* va/i18n (2016-10-17) 7 commits
(merged to 'next' on 2016-10-19 at b7d733698b)
+ i18n: diff: mark warnings for translation
+ i18n: credential-cache--daemon: mark advice for translation
+ i18n: convert mark error messages for translation
+ i18n: apply: mark error message for translation
+ i18n: apply: mark error messages for translation
+ i18n: apply: mark info messages for translation
+ i18n: apply: mark plural string for translation
More i18n.
Will merge to 'master'.
* jk/tighten-alloc (2016-10-17) 2 commits
(merged to 'next' on 2016-10-19 at 548522a520)
+ inline xalloc_flex() into FLEXPTR_ALLOC_MEM
+ avoid pointer arithmetic involving NULL in FLEX_ALLOC_MEM
Protect our code from over-eager compilers.
Will merge to 'master'.
* pb/test-parse-options-expect (2016-10-17) 1 commit
(merged to 'next' on 2016-10-19 at d3517d592f)
+ t0040: convert all possible tests to use `test-parse-options --expect`
Test clean-up.
Will merge to 'master'.
* pb/bisect (2016-10-18) 27 commits
- bisect--helper: remove the dequote in bisect_start()
- bisect--helper: retire `--bisect-auto-next` subcommand
- bisect--helper: retire `--bisect-autostart` subcommand
- bisect--helper: retire `--bisect-write` subcommand
- bisect--helper: `bisect_replay` shell function in C
- bisect--helper: `bisect_log` shell function in C
- bisect--helper: retire `--write-terms` subcommand
- bisect--helper: retire `--check-expected-revs` subcommand
- bisect--helper: `bisect_state` & `bisect_head` shell function in C
- bisect--helper: `bisect_autostart` shell function in C
- bisect--helper: retire `--next-all` subcommand
- bisect--helper: retire `--bisect-clean-state` subcommand
- bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
- t6030: no cleanup with bad merge base
- bisect--helper: `bisect_start` shell function partially in C
- bisect--helper: `get_terms` & `bisect_terms` shell function in C
- bisect--helper: `bisect_next_check` & bisect_voc shell function in C
- bisect--helper: `check_and_set_terms` shell function in C
- bisect--helper: `bisect_write` shell function in C
- bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
- bisect--helper: `bisect_reset` shell function in C
- wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
- t6030: explicitly test for bisection cleanup
- bisect--helper: `bisect_clean_state` shell function in C
- bisect--helper: `write_terms` shell function in C
- bisect: rewrite `check_term_format` shell function in C
- bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
Move more parts of "git bisect" to C.
Waiting for review.
* ab/gitweb-abbrev-links (2016-10-14) 3 commits
(merged to 'next' on 2016-10-17 at 4868def05e)
+ gitweb: link to "git describe"'d commits in log messages
+ gitweb: link to 7-char+ SHA-1s, not only 8-char+
+ gitweb: fix a typo in a comment
In addition to purely abbreviated commit object names, "gitweb"
learned to turn "git describe" output (e.g. v2.9.3-599-g2376d31787)
into clickable links in its output.
Will merge to 'master'.
* js/prepare-sequencer (2016-10-21) 27 commits
- sequencer: mark all error messages for translation
- sequencer: start error messages consistently with lower case
- sequencer: quote filenames in error messages
- sequencer: mark action_name() for translation
- sequencer: remove overzealous assumption in rebase -i mode
- sequencer: teach write_message() to append an optional LF
- sequencer: refactor write_message() to take a pointer/length
- sequencer: roll back lock file if write_message() failed
- sequencer: stop releasing the strbuf in write_message()
- sequencer: left-trim lines read from the script
- sequencer: support cleaning up commit messages
- sequencer: support amending commits
- sequencer: allow editing the commit message on a case-by-case basis
- sequencer: introduce a helper to read files written by scripts
- sequencer: prepare for rebase -i's commit functionality
- sequencer: remember the onelines when parsing the todo file
- sequencer: get rid of the subcommand field
- sequencer: avoid completely different messages for different actions
- sequencer: strip CR from the todo script
- sequencer: completely revamp the "todo" script parsing
- sequencer: refactor the code to obtain a short commit name
- sequencer: future-proof read_populate_todo()
- sequencer: plug memory leaks for the option values
- sequencer: future-proof remove_sequencer_state()
- sequencer: avoid unnecessary indirection
- sequencer: use memoized sequencer directory path
- sequencer: use static initializers for replay_opts
Update of the sequencer codebase to make it reusable to reimplement
"rebase -i" continues.
Will merge to 'next'.
* sb/submodule-ignore-trailing-slash (2016-10-18) 3 commits
. submodule--helper: normalize funny urls
(merged to 'next' on 2016-10-11 at e37425ed17)
+ submodule: ignore trailing slash in relative url
+ submodule: ignore trailing slash on superproject URL
A minor regression fix for "git submodule".
It seems that POSIX emulation layer of Windows is not cooperating;
this may have to wait (or tentatively reverted in Windows port) for
the resolution of the issue.
cf. <alpine.DEB.2.20.1610131255001.197091@virtualbox>
cf. <CAGZ79kYrKGLEOO72aWuX5OOM-AecdFZFXRqBkRzhdAM-VbPFxA@mail.gmail.com>
What's the current state of this topic?
* st/verify-tag (2016-10-10) 7 commits
- t/t7004-tag: Add --format specifier tests
- t/t7030-verify-tag: Add --format specifier tests
- builtin/tag: add --format argument for tag -v
- builtin/verify-tag: add --format to verify-tag
- tag: add format specifier to gpg_verify_tag
- ref-filter: add function to print single ref_array_item
- gpg-interface, tag: add GPG_VERIFY_QUIET flag
"git tag" and "git verify-tag" learned to put GPG verification
status in their "--format=<placeholders>" output format.
Waiting for review.
cf. <20161007210721.20437-1-santiago@nyu.edu>
* mm/credential-libsecret (2016-10-11) 1 commit
(merged to 'next' on 2016-10-17 at 1b4af03ba4)
+ contrib: add credential helper for libsecret
A new credential helper that talks via "libsecret" with
implementations of XDG Secret Service API has been added to
contrib/credential/.
Will merge to 'master'.
* sb/attr (2016-10-24) 36 commits
- completion: clone can initialize specific submodules
- clone: add --init-submodule=<pathspec> switch
- submodule update: add `--init-default-path` switch
- pathspec: allow escaped query values
- pathspec: allow querying for attributes
- pathspec: move prefix check out of the inner loop
- pathspec: move long magic parsing out of prefix_pathspec
- Documentation: fix a typo
- attr: keep attr stack for each check
- attr: convert to new threadsafe API
- attr: make git_check_attr_counted static
- attr.c: outline the future plans by heavily commenting
- attr.c: always pass check[] to collect_some_attrs()
- attr.c: introduce empty_attr_check_elems()
- attr.c: correct ugly hack for git_all_attrs()
- attr.c: rename a local variable check
- attr.c: pass struct git_attr_check down the callchain
- attr.c: add push_stack() helper
- attr: support quoting pathname patterns in C style
- attr: expose validity check for attribute names
- attr: add counted string version of git_attr()
- attr: add counted string version of git_check_attr()
- attr: retire git_check_attrs() API
- attr: convert git_check_attrs() callers to use the new API
- attr: convert git_all_attrs() to use "struct git_attr_check"
- attr: (re)introduce git_check_attr() and struct git_attr_check
- attr: rename function and struct related to checking attributes
- attr.c: plug small leak in parse_attr_line()
- attr.c: tighten constness around "git_attr" structure
- attr.c: simplify macroexpand_one()
- attr.c: mark where #if DEBUG ends more clearly
- attr.c: complete a sentence in a comment
- attr.c: explain the lack of attr-name syntax check in parse_attr()
- attr.c: update a stale comment on "struct match_attr"
- attr.c: use strchrnul() to scan for one line
- commit.c: use strchrnul() to scan for one line
The attributes API has been updated so that it can later be
optimized using the knowledge of which attributes are queried.
Building on top of the updated API, the pathspec machinery learned
to select only paths with given attributes set.
* jc/ws-error-highlight (2016-10-04) 4 commits
(merged to 'next' on 2016-10-17 at ecbdc57d77)
+ diff: introduce diff.wsErrorHighlight option
+ diff.c: move ws-error-highlight parsing helpers up
+ diff.c: refactor parse_ws_error_highlight()
+ t4015: split out the "setup" part of ws-error-highlight test
"git diff/log --ws-error-highlight=<kind>" lacked the corresponding
configuration variable to set it by default.
Will merge to 'master'.
* jk/abbrev-auto (2016-10-03) 1 commit
(merged to 'next' on 2016-10-21 at 8aa3d760d8)
+ find_unique_abbrev: move logic out of get_short_sha1()
(this branch is used by jc/abbrev-auto; uses lt/abbrev-auto.)
Updates the way approximate count of total objects is computed
while attempting to come up with a unique abbreviated object name,
which in turn needs to estimate how many hexdigits are necessary to
ensure uniqueness.
Undecided.
* nd/ita-empty-commit (2016-10-24) 4 commits
- commit: don't be fooled by ita entries when creating initial commit
- commit: fix empty commit creation when there's no changes but ita entries
- diff: add --ita-[in]visible-in-index
- diff-lib: allow ita entries treated as "not yet exist in index"
When new paths were added by "git add -N" to the index, it was
enough to circumvent the check by "git commit" to refrain from
making an empty commit without "--allow-empty". The same logic
prevented "git status" to show such a path as "new file" in the
"Changes not staged for commit" section.
Will merge to 'next'.
* lt/abbrev-auto (2016-10-03) 3 commits
(merged to 'next' on 2016-10-03 at bb188d00f7)
+ abbrev: auto size the default abbreviation
+ abbrev: prepare for new world order
+ abbrev: add FALLBACK_DEFAULT_ABBREV to prepare for auto sizing
(this branch is used by jc/abbrev-auto and jk/abbrev-auto.)
Allow the default abbreviation length, which has historically been
7, to scale as the repository grows. The logic suggests to use 12
hexdigits for the Linux kernel, and 9 to 10 for Git itself.
Will hold to see if people scream.
* jc/diff-unique-abbrev-comments (2016-09-30) 1 commit
(merged to 'next' on 2016-10-17 at c7fb286102)
+ diff_unique_abbrev(): document its assumption and limitation
(this branch is used by jk/no-looking-at-dotgit-outside-repo.)
A bit more comments in a tricky code.
Will merge to 'master'.
* va/i18n-perl-scripts (2016-10-20) 14 commits
- i18n: difftool: mark warnings for translation
- i18n: send-email: mark string with interpolation for translation
- i18n: send-email: mark warnings and errors for translation
- i18n: send-email: mark strings for translation
- i18n: add--interactive: mark status words for translation
- i18n: add--interactive: remove %patch_modes entries
- i18n: add--interactive: mark edit_hunk_manually message for translation
- i18n: add--interactive: i18n of help_patch_cmd
- i18n: add--interactive: mark patch prompt for translation
- i18n: add--interactive: mark plural strings
- i18n: clean.c: match string with git-add--interactive.perl
- i18n: add--interactive: mark strings with interpolation for translation
- i18n: add--interactive: mark simple here-documents for translation
- i18n: add--interactive: mark strings for translation
Porcelain scripts written in Perl are getting internationalized.
Waiting for review.
cf. <20161010125449.7929-1-vascomalmeida@sapo.pt>
* jc/latin-1 (2016-09-26) 2 commits
(merged to 'next' on 2016-09-28 at c8673e03c2)
+ utf8: accept "latin-1" as ISO-8859-1
+ utf8: refactor code to decide fallback encoding
Some platforms no longer understand "latin-1" that is still seen in
the wild in e-mail headers; replace them with "iso-8859-1" that is
more widely known when conversion fails from/to it.
Will hold to see if people scream.
* mg/gpg-richer-status (2016-10-12) 1 commit
(merged to 'next' on 2016-10-17 at 8843a6a8be)
+ gpg-interface: use more status letters
The GPG verification status shown in "%G?" pretty format specifier
was not rich enough to differentiate a signature made by an expired
key, a signature made by a revoked key, etc. New output letters
have been assigned to express them.
Will merge to 'master'.
* js/libify-require-clean-work-tree (2016-10-07) 6 commits
(merged to 'next' on 2016-10-17 at f5c20df38b)
+ wt-status: begin error messages with lower-case
+ wt-status: teach has_{unstaged,uncommitted}_changes() about submodules
+ wt-status: export also the has_un{staged,committed}_changes() functions
+ wt-status: make the require_clean_work_tree() function reusable
+ pull: make code more similar to the shell script again
+ pull: drop confusing prefix parameter of die_on_unclean_work_tree()
The require_clean_work_tree() helper was recreated in C when "git
pull" was rewritten from shell; the helper is now made available to
other callers in preparation for upcoming "rebase -i" work.
Will merge to 'master'.
* bw/ls-files-recurse-submodules (2016-10-10) 4 commits
(merged to 'next' on 2016-10-17 at f0e398946a)
+ ls-files: add pathspec matching for submodules
+ ls-files: pass through safe options for --recurse-submodules
+ ls-files: optionally recurse into submodules
+ git: make super-prefix option
"git ls-files" learned "--recurse-submodules" option that can be
used to get a listing of tracked files across submodules (i.e. this
only works with "--cached" option, not for listing untracked or
ignored files). This would be a useful tool to sit on the upstream
side of a pipe that is read with xargs to work on all working tree
files from the top-level superproject.
Will merge to 'master'.
* ls/filter-process (2016-10-17) 14 commits
(merged to 'next' on 2016-10-19 at ffd0de042c)
+ contrib/long-running-filter: add long running filter example
+ convert: add filter.<driver>.process option
+ convert: prepare filter.<driver>.process option
+ convert: make apply_filter() adhere to standard Git error handling
+ pkt-line: add functions to read/write flush terminated packet streams
+ pkt-line: add packet_write_gently()
+ pkt-line: add packet_flush_gently()
+ pkt-line: add packet_write_fmt_gently()
+ pkt-line: extract set_packet_header()
+ pkt-line: rename packet_write() to packet_write_fmt()
+ run-command: add clean_on_exit_handler
+ run-command: move check_pipe() from write_or_die to run_command
+ convert: modernize tests
+ convert: quote filter names in error messages
The smudge/clean filter API expect an external process is spawned
to filter the contents for each path that has a filter defined. A
new type of "process" filter API has been added to allow the first
request to run the filter for a path to spawn a single process, and
all filtering need is served by this single process for multiple
paths, reducing the process creation overhead.
Will wait for ls/git-open-cloexec.
* hv/submodule-not-yet-pushed-fix (2016-10-10) 3 commits
- batch check whether submodule needs pushing into one call
- serialize collection of refs that contain submodule changes
- serialize collection of changed submodules
The code in "git push" to compute if any commit being pushed in the
superproject binds a commit in a submodule that hasn't been pushed
out was overly inefficient, making it unusable even for a small
project that does not have any submodule but have a reasonable
number of refs.
Waiting for review.
cf. <cover.1475851621.git.hvoigt@hvoigt.net>
* sg/fix-versioncmp-with-common-suffix (2016-09-08) 5 commits
- versioncmp: cope with common leading parts in versionsort.prereleaseSuffix
- versioncmp: pass full tagnames to swap_prereleases()
- t7004-tag: add version sort tests to show prerelease reordering issues
- t7004-tag: use test_config helper
- t7004-tag: delete unnecessary tags with test_when_finished
The prereleaseSuffix feature of version comparison that is used in
"git tag -l" did not correctly when two or more prereleases for the
same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2
are there and the code needs to compare 2.0-beta1 and 2.0-beta2).
Waiting for a reroll.
cf. <20160908223727.Horde.jVOOJ278ssZ3qkyjkmyqZD-@webmail.informatik.kit.edu>
* sb/push-make-submodule-check-the-default (2016-10-10) 2 commits
- push: change submodule default to check when submodules exist
- submodule add: extend force flag to add existing repos
Turn the default of "push.recurseSubmodules" to "check" when
submodules seem to be in use.
Will hold to wait for hv/submodule-not-yet-pushed-fix
* jc/pull-rebase-ff (2016-07-28) 1 commit
- pull: fast-forward "pull --rebase=true"
"git pull --rebase", when there is no new commits on our side since
we forked from the upstream, should be able to fast-forward without
invoking "git rebase", but it didn't.
Needs a real log message and a few tests.
* ex/deprecate-empty-pathspec-as-match-all (2016-06-22) 1 commit
(merged to 'next' on 2016-09-21 at e19148ea63)
+ pathspec: warn on empty strings as pathspec
Originally merged to 'next' on 2016-07-13
An empty string used as a pathspec element has always meant
'everything matches', but it is too easy to write a script that
finds a path to remove in $path and run 'git rm "$paht"', which
ends up removing everything. Start warning about this use of an
empty string used for 'everything matches' and ask users to use a
more explicit '.' for that instead.
The hope is that existing users will not mind this change, and
eventually the warning can be turned into a hard error, upgrading
the deprecation into removal of this (mis)feature.
Will hold to see if people scream.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
(merged to 'next' on 2016-10-11 at 8928c8b9b3)
+ merge: drop 'git merge <message> HEAD <commit>' syntax
Stop supporting "git merge <message> HEAD <commit>" syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.
It has been reported that git-gui still uses the deprecated syntax,
which needs to be fixed before this final step can proceed.
cf. <5671DB28.8020901@kdbg.org>
Will merge to 'master'.
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2016, #06; Mon, 24)
From: Stefan Beller @ 2016-10-25 2:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <xmqq1sz5tetv.fsf@gitster.mtv.corp.google.com>
On Mon, Oct 24, 2016 at 6:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> * sb/submodule-ignore-trailing-slash (2016-10-18) 3 commits
> . submodule--helper: normalize funny urls
> (merged to 'next' on 2016-10-11 at e37425ed17)
> + submodule: ignore trailing slash in relative url
> + submodule: ignore trailing slash on superproject URL
>
> A minor regression fix for "git submodule".
>
> It seems that POSIX emulation layer of Windows is not cooperating;
> this may have to wait (or tentatively reverted in Windows port) for
> the resolution of the issue.
>
> cf. <alpine.DEB.2.20.1610131255001.197091@virtualbox>
> cf. <CAGZ79kYrKGLEOO72aWuX5OOM-AecdFZFXRqBkRzhdAM-VbPFxA@mail.gmail.com>
>
> What's the current state of this topic?
The first 2 patches actually fix a bug users run into, and I these are
fine for general consumption IMHO.
The third patch only breaks tests as our test suite is holding it wrong.
I was bike shedding on the list and yak shaving here to come up with
the correct fix for the test suite.
One of the initial ways to work around the bugfix was to
git clone . root # <- add in this step and it works again.
git clone root super
but instead I will do the preparation for the 'super' project not
in '.' but in 'root', just called differently ("super_remote" ?)
An additional new test for cloning from '.' will be introduced, too.
I plan on working on that with highest priority for git after finishing
some attr stuff that I currently have open. So expect a patch (or two)
this week.
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH] Allow stashes to be referenced by index only
From: Jeff King @ 2016-10-25 8:11 UTC (permalink / raw)
To: Aaron M Watson
Cc: git, Jon Seymour, David Caldwell, Øystein Walle,
Ævar Arnfjörð Bjarmason, David Aguilar,
Alex Henrie
In-Reply-To: <1477352413-4628-1-git-send-email-watsona4@gmail.com>
On Mon, Oct 24, 2016 at 07:40:13PM -0400, Aaron M Watson wrote:
> Instead of referencing "stash@{n}" explicitly, it can simply be
> referenced as "n". Most users only reference stashes by their position
> in the stash stask (what I refer to as the "index"). The syntax for the
> typical stash (stash@{n}) is slightly annoying and easy to forget, and
> sometimes difficult to escape properly in a script. Because of this the
> capability to do things with the stash by simply referencing the index
> is desirable.
>
> This patch includes the superior implementation provided by Øsse Walle
> (thanks for that), with a slight change to fix a broken test in the test
> suite. I also merged the test scripts as suggested by Jeff King, and
> un-wrapped the documentation as suggested by Junio Hamano.
>
> Signed-off-by: Aaron M Watson <watsona4@gmail.com>
> ---
Thanks, this version looks good to me.
Oddly, it does not seem to apply. I get:
$ git am -3 ~/patch
Applying: Allow stashes to be referenced by index only
Using index info to reconstruct a base tree...
M git-stash.sh
error: patch failed: t/t3903-stash.sh:604
error: t/t3903-stash.sh: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Patch failed at 0001 Allow stashes to be referenced by index only
The culprit seems to be the final hunk header:
> @@ -604,7 +624,21 @@ test_expect_success 'invalid ref of the form stash@{n}, n >= N' '
This should be "604,6", as there are 6 context lines, and your patch
does not remove any lines.
I suspect the maintainer can fix it up while applying, but for my
curiosity: did you hand-edit it, or is there a potential bug in git's
diff code?
-Peff
^ permalink raw reply
* Re: [PATCH] Allow stashes to be referenced by index only
From: Aaron and Ashley Watson @ 2016-10-25 8:20 UTC (permalink / raw)
To: Jeff King
Cc: git, Jon Seymour, David Caldwell, Øystein Walle,
Ævar Arnfjörð Bjarmason, David Aguilar,
Alex Henrie
In-Reply-To: <20161025081149.x5l5zcupva546ssf@sigill.intra.peff.net>
On Tue, Oct 25, 2016 at 4:11 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 24, 2016 at 07:40:13PM -0400, Aaron M Watson wrote:
>
>> Instead of referencing "stash@{n}" explicitly, it can simply be
>> referenced as "n". Most users only reference stashes by their position
>> in the stash stask (what I refer to as the "index"). The syntax for the
>> typical stash (stash@{n}) is slightly annoying and easy to forget, and
>> sometimes difficult to escape properly in a script. Because of this the
>> capability to do things with the stash by simply referencing the index
>> is desirable.
>>
>> This patch includes the superior implementation provided by Øsse Walle
>> (thanks for that), with a slight change to fix a broken test in the test
>> suite. I also merged the test scripts as suggested by Jeff King, and
>> un-wrapped the documentation as suggested by Junio Hamano.
>>
>> Signed-off-by: Aaron M Watson <watsona4@gmail.com>
>> ---
>
> Thanks, this version looks good to me.
>
> Oddly, it does not seem to apply. I get:
>
> $ git am -3 ~/patch
> Applying: Allow stashes to be referenced by index only
> Using index info to reconstruct a base tree...
> M git-stash.sh
> error: patch failed: t/t3903-stash.sh:604
> error: t/t3903-stash.sh: patch does not apply
> error: Did you hand edit your patch?
> It does not apply to blobs recorded in its index.
> Patch failed at 0001 Allow stashes to be referenced by index only
>
> The culprit seems to be the final hunk header:
>
>> @@ -604,7 +624,21 @@ test_expect_success 'invalid ref of the form stash@{n}, n >= N' '
>
> This should be "604,6", as there are 6 context lines, and your patch
> does not remove any lines.
>
> I suspect the maintainer can fix it up while applying, but for my
> curiosity: did you hand-edit it, or is there a potential bug in git's
> diff code?
I did indeed edit the patch by hand (I forgot to remove the spaces
after the > in the test file), but
the bug appears to be in emacs's diff-mode, not in git.
>
> -Peff
--
Aaron and Ashley Watson
^ permalink raw reply
* Re: Reporting Bug in Git Version Control System
From: Pranit Bauva @ 2016-10-25 8:51 UTC (permalink / raw)
To: Yash Jain; +Cc: Git List
In-Reply-To: <CAN8fUZe4iWJCZYqBBDbNyPq1Dz7f4xvTNRVEZgg5AYN2NrKCbg@mail.gmail.com>
Hey Yash,
Junio has explained the problem very well. Since you seem to be a
beginner (guessing purely by your email) I will tell you how to fix
it.
Remember when you would have first installed git, you would have done
something like `git config --global user.name <what ever name>` and
`git config --global user.email <what ever email>`, it gets
permanently stored in the git configuration file (~/.gitconfig). Now
all the commits in git are made with this name and email. If you want
to change this, again run the above commands with your new name and
email. After that commits will be done with a different name and
email. Hope this helps! :)
Regards,
Pranit Bauva
^ permalink raw reply
* Re: [PATCH v1 00/19] Add configuration options for split-index
From: Duy Nguyen @ 2016-10-25 9:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, Git Mailing List,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <xmqq8ttd7h8g.fsf@gitster.mtv.corp.google.com>
On Tue, Oct 25, 2016 at 1:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> - splitIndex.sharedIndexExpire
>>
>> To make sure that old sharedindex files are eventually removed
>> when a new one has been created, we "touch" the shared index file
>> every time it is used by a new split index file. Then we can
>> delete shared indexes with an mtime older than one week (by
>> default), when we create a new shared index file. The new
>> "splitIndex.sharedIndexExpire" config option lets people tweak
>> this grace period.
>
> I do not quite understand this justification. Doesn't each of the
> "this hold only changes since the base index file" files have a
> backpointer that names the base index file it is a delta against?
Yes, but the shared file does not have pointers to all the files that
need it, which could be more than one. We know one of them,
$GIT_DIR/index, and possibly $GIT_DIR/index.lock too. But those files
people generate manually and refer to them with $GIT_INDEX_FILE, we
can't know where they are.
> Is it safe to remove a base index file when there is still a split
> index file that points at it?
>
> IOW, I do not see why it can be safe for the expiration decision to
> be based on timestamp (I would understand it if it were based on a
> refcnt, though).
Problem is we can't maintain these ref counts cheap and simple. We
don't want to update sharedindex file every time somebody references
to it (or stops referencing to it) because that defeats the purpose of
splitting it out and not touching it any more. Adding a separate file
for ref count could work, but it gets complex, especially when we
think about race condition at update time.
Timestamps allow us to say, ok this base index file has not been read
by anybody for N+ hours (or better, days), it's most likely not
referenced by any temporary index files (including
$GIT_DIR/index.lock) anymore because those files, by the definition of
"temporary", must be gone by now. We should definitely check and make
sure the file $GIT_DIR/index points to still exist. I'm going to read
the series now, so I don't know if the previous sentence is true.
It will probably be harder to handle race condition at updating
$GIT_DIR/index, which could be avoided by a sufficiently long grace
period with timestamps.
--
Duy
^ permalink raw reply
* Re: [PATCH 0/4] nd/ita-empty-commit update
From: Duy Nguyen @ 2016-10-25 9:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <xmqqeg357hou.fsf@gitster.mtv.corp.google.com>
On Tue, Oct 25, 2016 at 12:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> The name ita-invisible-in-index is not perfect but I could not think
>> of any better. Another name could be diff-cached-ignores-ita, but
>> that's just half of what it does. The other half is diff-files-includes-ita...
>
> I can't either, and it is one of the reasons why I am reluctant.
> Not being able to be named with a short-and-sweet name often is a
> sign that the thing to be named is conceptually not well thought
> out.
It's implementation detail leak, and probably why naming it for
"normal" people is so hard. Whatever the name is must somehow imply
"so these i-t-a markers actually live in the index and considered real
index entries, associated to empty blob, most of the time..."
> But as we need to give it some name to the flat to ease
> experimenting, let's take that name as-is.
--
Duy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox