On Tue, May 09, 2017 at 11:48:17AM +0900, Junio C Hamano wrote:
> > I guess what I was asking was: do you still think it was unclear, or do
> > you think you were just being dense?
> >
> > I don't feel like I gave any information in the follow-on explanation
> > that wasn't in the commit message,
Jeff King writes:
> On Tue, May 09, 2017 at 11:48:17AM +0900, Junio C Hamano wrote:
>
>> > I guess what I was asking was: do you still think it was unclear, or do
>> > you think you were just being dense?
>> >
>> > I don't feel like I gave any information in the follow-on
Jonathan Tan writes:
> Teach receive-pack, in the case that push options are provided for a
> signed push, to verify that the push options both within the cert and
> outside the cert are consistent.
Thanks. The idea was that the certificate should record how the
push
On Mon, May 01, 2017 at 12:34:38PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I don't know if we would want to be extra paranoid about patch-ids.
> > There is no helping:
> >
> > git rev-list HEAD | git diff-tree --stdin -p | git patch-id --stable
> >
> > because diff-tree doesn't know that it's
On Mon, May 08, 2017 at 10:54:10AM -0400, Marc Branchaud wrote:
> On 2017-05-08 03:48 AM, Junio C Hamano wrote:
> >
> > * mb/diff-default-to-indent-heuristics (2017-05-02) 4 commits
> > (merged to 'next' on 2017-05-08 at 158f401a92)
>
> I think there's a general open question about this,
On Mon, May 08, 2017 at 12:03:37PM -0400, Marc Branchaud wrote:
> This matches how the diff Porcelain works. It makes the plumbing commands
> respect diff's configuration options, such as indentHeuristic, because
> init_revisions() calls diff_setup() which fills in the diff_options struct.
I
On Mon, May 08, 2017 at 10:13:41AM -0700, Stefan Beller wrote:
> > -test_expect_success 'diff: nice spaces with diff.indentHeuristic' '
> > +test_expect_success 'diff: nice spaces with diff.indentHeuristic=true' '
>
> Adding the '=true' seems weird to me (I'd think the true is implied,
> similar
On Mon, May 08, 2017 at 12:03:39PM -0400, Marc Branchaud wrote:
> @@ -730,9 +729,6 @@ sub parse_diff {
> if (defined $diff_algorithm) {
> splice @diff_cmd, 1, 0, "--diff-algorithm=${diff_algorithm}";
> }
> - if ($diff_indent_heuristic) {
> - splice
On Mon, May 08, 2017 at 12:03:35PM -0400, Marc Branchaud wrote:
> The only change from v3 is in 3/4, to expand t4061 to test various
> combinations of --(no-)indent-heuristic and diff.indentHeuristic.
>
> I kindof went all-in and tried to cover every possible combination for
> all four affected
Jonathan Tan writes:
> + # Tweak the push output to make the push option outside the cert
> + # different, then replay it on a fresh dst, checking that ff is not
> + # deleted.
> + sed -i "s/\\([^ ]\\)bar/\\1baz/" push &&
This is not portable. Didn't
On Sat, May 06, 2017 at 07:13:52PM +0200, René Scharfe wrote:
> If resolve_refdup() fails it returns NULL and possibly leaves its hash
> output parameter untouched. Make sure to use it only if the function
> succeeded, in order to avoid accessing uninitialized memory.
>
> Found with
On Sat, May 06, 2017 at 07:13:56PM +0200, René Scharfe wrote:
> If resolve_refdup() fails it returns NULL and possibly leaves its hash
> output parameter untouched. Make sure to use it only if the function
> succeeded, in order to avoid accessing uninitialized memory.
>
> Signed-off-by: Rene
Jeff King writes:
> I do feel a bit sad about breaking this case (or at the very least
> forcing you to set an option to retain cross-version compatibility). But
> my gut says that we don't want to lock ourselves into never changing the
> diff algorithm (and I'm sure we've done it
On Mon, May 08, 2017 at 09:49:34AM -0700, Stefan Beller wrote:
> On Sat, May 6, 2017 at 1:40 AM, Jordi Mas wrote:
> > Hello,
> >
> > When translating git (https://github.com/git/git/tree/master/po)
> >
> > The following strings cannot be translated:
> >
> > remote: Counting
On Sat, May 06, 2017 at 12:23:32PM +0200, Lars Schneider wrote:
> I am about to write a bash/sh script that helps me to rebase a bunch of
> branches (e.g. select branches based on prefix, conflict resolution/
> rerere support, ...).
>
> I wonder if anyone has such a script already and is
On 09/05/17 03:29, Junio C Hamano wrote:
Johannes Schindelin writes:
Recent "stress" tests show that t0025 if flaky, reported by Lars Schneider,
larsxschnei...@gmail.com
All tests from t0025 are covered in t0027 already, so that t0025 can be
retiered:
Jeff King writes:
> I don't think the diffstat summary is marked for translation at all,
> plumbing or not. There's some history there:
>
>
> http://public-inbox.org/git/1345922816-20616-1-git-send-email-pclo...@gmail.com/t/#u
Wow, that's a long thread.
> There was an
Jiang Xin writes:
> Git v2.13.0-rc2 introduced 4 new messages, let's start round 2 for Git
> 2.13.0 l10n.
>
> You can get it from the usual place:
>
> https://github.com/git-l10n/git-po/
>
> As how to update your XX.po and help to translate Git, please see
>
David Turner writes:
> Can you actually keep the email address as my Twopensource one? I want to
> make sure that Twitter, my employer at the time, gets credit for this work
> (just as I want to make sure that my current employer, Two Sigma, gets credit
> for my
Christian Couder writes:
> On Fri, Apr 14, 2017 at 10:32 PM, wrote:
>> diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
>> index 33a51c9..677e15a 100755
>> --- a/t/t1450-fsck.sh
>> +++ b/t/t1450-fsck.sh
>> @@ -689,4 +689,17 @@
Junio C Hamano writes:
> Thanks for spotting.
>
> I do not think you have to worry about any bug in Git-the-program
> with this merge. If you try to reproduce the merge yourself (which
> by the way is easy to do, with "M=4af9a7d344 && git checkout $M^ &&
> git merge $M^2"),
"Randall S. Becker" writes:
> I have to admit that I just assumed it would have to work that way
> this would not be particularly useful. However, in thinking about
> it, we might want to limit the depth of how far -b takes
> effect. If the super module brings in
Jeff King writes:
> Actually, it's not too bad, because we can pick up things like
> option_origin from the globals. Here it is for reference. The nice thing
> about it (IMHO) is that it makes the lifetimes of the helper variables
> much more shorter and more clear.
>
> But I'm OK
Jeff King writes:
> On Tue, May 09, 2017 at 11:14:18AM +0900, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> >> Ah, OK, and now I understand why you called this a "bug" (which is
>> >> older and do not need to be addressed as part of 2.13) in the
>> >>
On Mon, May 08, 2017 at 10:54:12PM -0400, Jeff King wrote:
> Contents are the same. I decided to leave the "; do" as it
> matches the rest of the script. If we're going to fix it, we
> should do them all.
Like this, perhaps.
I didn't go on a crusade against "; do" in the other scripts, but
On Mon, May 08, 2017 at 10:10:28PM -0400, Jeff King wrote:
> On Tue, May 09, 2017 at 10:33:39AM +0900, Junio C Hamano wrote:
>
> > >> My patch deals with 'remote..refspec', i.e. 'remote->fetch'.
> > >> Apparently some extra care is necessary for 'remote..tagOpt' and
> > >> 'remote->fetch_tags',
On Tue, May 09, 2017 at 11:14:18AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> >> Ah, OK, and now I understand why you called this a "bug" (which is
> >> older and do not need to be addressed as part of 2.13) in the
> >> original message. The new tests check requests
On Tue, May 09, 2017 at 10:49:19AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > The specific helpers have less visibility, which is good. The public
> > functions a() and b() were already public, so no change. But now the
> > common helper is public, too, even though
On Mon, May 08, 2017 at 08:30:49AM +0200, Дилян Палаузов wrote:
> why do these work:
>
> git clone --bare -b 3.5 https://github.com/python/cpython A
> git clone -b 3.6 A B
>From the description of --bare in "git help clone":
[...]the branch heads at the remote are copied directly to
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.
You can find the changes
Yubin Ruan writes:
> That would be helpful. But, frankly, if a user would be aware of that
> `advice.*'
> variable, he would have enough knowledge of Git to be aware of that situation.
> So, I think that 'M lala.txt' in transitions from branch to branch would be
>
Hello,
why do these work:
git clone --bare -b 3.5 https://github.com/python/cpython A
git clone -b 3.6 A B
git clone -b 3.5 https://github.com/python/cpython C
but these not:
git clone -b 3.6 C D
git clone --no-local -b 3.6 C D
with git version 2.12.2.89.g49800c940?
Regards
Дилян
On Thu, May 4, 2017 at 1:32 PM, Johannes Schindelin
wrote:
> Hi Ævar,
>
> On Thu, 4 May 2017, Ævar Arnfjörð Bjarmason wrote:
>
>> So I think if your criteria for working on integrating v2 is users
>> noticing it elsewhere and asking you for it you'll likely never
Ævar Arnfjörð Bjarmason writes:
> This won't be in my next PCRE submission, but I have a path locally to
> simply import PCRE into git.git as compat/pcre2, so it can be compiled
> with NO_PCRE=Y similar to how NO_REGEX=Y works.
>
> This will hopefully address your concerns
On Mon, May 8, 2017 at 3:49 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Christian Couder writes:
>>
>>> This patch series contains 2 patches that have already been sent to
>>> the list but have felt through the
Ævar Arnfjörð Bjarmason writes:
> It's just to bring us in line with upstream which as noted in that
> commit has fixed the issues we locally patched (and more), and for us
> to stop maintaining a fork of an old version of part of Gawk.
>
> There's no known issue with the
From: David Turner
Make git checkout (and other unpack_tree operations) preserve the
untracked cache. 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
I recently sent out a request for assistance, after noticing that the
untracked cache is simply thrown away after operations such as
`git checkout` or `git reset --hard`:
http://public-inbox.org/git/alpine.DEB.2.20.1705031202470.3480@virtualbox/
Duy responded with some high-level reasoning that
On Fri, Apr 14, 2017 at 10:32 PM, wrote:
> diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
> index 33a51c9..677e15a 100755
> --- a/t/t1450-fsck.sh
> +++ b/t/t1450-fsck.sh
> @@ -689,4 +689,17 @@ test_expect_success 'bogus head does not fallback to all
> heads' '
>
On Mon, May 08, 2017 at 03:07:02PM +0900, Junio C Hamano wrote:
> Yubin Ruan writes:
>
> > That would be helpful. But, frankly, if a user would be aware of that
> > `advice.*'
> > variable, he would have enough knowledge of Git to be aware of that
> > situation.
> > So,
Samuel Lijin writes:
> We now expect `status --ignored` to list ignored files even if they are
> in an untracked directory.
>
> Signed-off-by: Samuel Lijin
> ---
> t/t7061-wtstatus-ignore.sh | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
>
On Mon, May 8, 2017 at 2:55 AM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> See the first patch for motivation & why.
>
> I do not think it quite explains the motivation, though. "Doing
> this way, we can keep in sync with the upstream more
On Mon, May 08, 2017 at 01:56:27PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > If certain options like --honor-pack-keep, --local, or
> > --incremental are used with pack-objects, then we need to
> > feed each potential object to want_object_in_pack() to see
> > if it
Hi Ævar,
On Sat, 6 May 2017, Ævar Arnfjörð Bjarmason wrote:
> I have one [script] to git am a patch from a msgid, thought I should
> write something to handle a series in some DWIM fashion (e.g. apply the
> latest continuous sequence of patches matching --author) but figured
> that someone's
Hi Dilyan,
On Sun, 7 May 2017, Дилян Палаузов wrote:
> I compiled git/master
... which advances from time to time, so you definitely want to include a
more informative data point here, e.g. 4fa66c85f11 (Git 2.13-rc2,
2017-05-04) ...
> using the clang 4.0 static analyzer with
>
> scan-build
(Adding Dave in Cc as it looks like he is involved.)
On Mon, May 8, 2017 at 11:41 AM, Johannes Schindelin
wrote:
> I recently sent out a request for assistance, after noticing that the
> untracked cache is simply thrown away after operations such as
> `git checkout`
Hi Junio,
On Sun, 7 May 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Let me repeat myself:
>
> Don't.
I had to. You did not understand me.
> Instead, read through what you are responding to the end before start
> typing a byte. In case you
Hi,
On Mon, 8 May 2017, Prathamesh Chavan wrote:
> I am Prathamesh Chavan, an undergraduate student from the department
> of Computer Science and Engineering, at Indian Institue of Technology,
> Kharagpur. I applied for Google Summer of Code 2017 and my project
> "Incremental rewrite of
> 在 2017年5月8日,12:11,Junio C Hamano 写道:
>
> Two suggestions.
>
> (1) I do not think $smtp is always valid when we come here; it is
> unsafe to unconditionally say $smtp->quit like this patch does.
>
>$smtp->quit if defined $smtp;
>
> may help codepaths like
Hi,
On Sat, 6 May 2017, Ævar Arnfjörð Bjarmason wrote:
> On Sat, May 6, 2017 at 12:30 AM, Johannes Schindelin
> wrote:
> > Hi Daniel,
> >
> >
> > On Fri, 5 May 2017, Daniel Ferreira wrote:
> >> +static void print_modified(void)
> >> +{
> >> + int i;
> >> +
Hi Daniel,
On Fri, 5 May 2017, Daniel Ferreira (theiostream) wrote:
> On Fri, May 5, 2017 at 7:30 PM, Johannes Schindelin
> wrote:
> >> +static int git_add_interactive_config(const char *var,
> >
> > Not git_add_interactive__helper_config()? ;-)
>
> I don't get if
Hi Daniel,
On Fri, 5 May 2017, Daniel Ferreira (theiostream) wrote:
> On Fri, May 5, 2017 at 7:38 PM, Johannes Schindelin
> wrote:
>
> > But maybe you want to keep the naming a little more consistent with
> > the Perl script, e.g. instead of calling the function
> >
On 5/8/2017 1:12 PM, Brandon Williams wrote:
On 05/06, Junio C Hamano wrote:
Brandon Williams writes:
One of the things brought up on the list in the past few days has been
migrating away from using the index compatibility macros. One of the issues
brought up in that
Re-indent lines, as they were off by one.
When a line was not indented (as you would expect from function defintions)
we had a stray whitespace preceding the line.
Indented lines have a stray white space after the indentation by tabs,
before the actual text, i.e.
if (...)
...
It looks like all
> On 08 May 2017, at 12:12, Johannes Schindelin
> wrote:
>
> Hi Dilyan,
>
>
> On Sun, 7 May 2017, Дилян Палаузов wrote:
>
>> ...
>
> Also: to make it *really* useful for other developers, it would be a good
> idea for you to try your hand at patching the
On 5/8/2017 5:45 AM, Christian Couder wrote:
On Fri, Apr 14, 2017 at 10:32 PM, wrote:
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index 33a51c9..677e15a 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -689,4 +689,17 @@ test_expect_success 'bogus head does
On Mon, May 8, 2017 at 9:03 AM, Marc Branchaud wrote:
> The only change from v3 is in 3/4, to expand t4061 to test various
> combinations of --(no-)indent-heuristic and diff.indentHeuristic.
>
> I kindof went all-in and tried to cover every possible combination for
> all
Hello,
I'm a Sr. Software Quality Assurance Engineer at Epocal Inc. in Ottawa, Ontario,
Canada. We are a medical device manufacturer that is required to comply with
the Food & Drug Administration's (FDA) regulations.
I'm in charge of what is known as Non-Product Software, essentially any piece
Git version: 2.11.0
THE CASE:
I have 15 commit to be squashed (the hashes are real, but the commit
messages were changed for privacy). When it's rebase interactively
squashing all the 15 commits, the numbering goes from 1 to 10 and
after it starts again from 1 to 5.
- The first line says "This
On Mon, May 8, 2017 at 10:14 AM, Robertson, Todd
wrote:
> Hello,
>
> I'm a Sr. Software Quality Assurance Engineer at Epocal Inc. in Ottawa,
> Ontario,
> Canada. We are a medical device manufacturer that is required to comply with
> the Food & Drug Administration's
Hello Johannes,
I compiled git/master
... which advances from time to time, so you definitely want to include a
more informative data point here, e.g. 4fa66c85f11 (Git 2.13-rc2,
2017-05-04) ...
The 4fa66c85f11 you mentioned is part of the URL I sent.
Please note, that the information is
This matches how the diff Porcelain works. It makes the plumbing commands
respect diff's configuration options, such as indentHeuristic, because
init_revisions() calls diff_setup() which fills in the diff_options struct.
Signed-off-by: Marc Branchaud
---
The only change from v3 is in 3/4, to expand t4061 to test various
combinations of --(no-)indent-heuristic and diff.indentHeuristic.
I kindof went all-in and tried to cover every possible combination for
all four affected commands.
An inter-diff is below.
M.
Jeff King (1):
From: Jeff King
Now that diff.indentHeuristic is handled automatically by the plumbing
commands, there's no need to propagate it manually.
Signed-off-by: Jeff King
Signed-off-by: Marc Branchaud
---
git-add--interactive.perl | 4
1 file
From: Stefan Beller
The feature was included in v2.11 (released 2016-11-29) and we got no
negative feedback. Quite the opposite, all feedback we got was positive.
Turn it on by default. Users who dislike the feature can turn it off
by setting diff.indentHeuristic (which also
This heuristic was originally introduced as an experimental feature,
and therefore part of the UI configuration.
But the user often sees diffs generated by plumbing commands like
diff-tree. Moving the indent heuristic into diff's basic configuration
prepares the way for diff plumbing commands to
On 05/08, Stefan Beller wrote:
> On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker
> wrote:
> > On May 6, 2017 4:38 AM Ciro Santilli wrote:
> >> This is a must if you are working with submodules, otherwise every
> >> git checkout requires a git submodule update, and you
On 05/07, Eric Wong wrote:
> Samuel Lijin wrote:
> > > Samuel Lijin wrote:
> > >> Yep, I see these on public-inbox.org/git/ but not in my gmail inbox:
> > >
> > > Hi Samuel, check your Spam box (and move it to a normal inbox so
> > > they can train it).
On May 8, 2017 12:55 PM, Stefan Beller wrote:
>On Mon, May 8, 2017 at 9:46 AM, Randall S. Becker
>wrote:
>> On May 8, 2017 12:25 PM, Stefan Beller wrote:
>>>On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker
>>>wrote:
On May 6, 2017 4:38 AM
On 05/06, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > One of the things brought up on the list in the past few days has been
> > migrating away from using the index compatibility macros. One of the issues
> > brought up in that thread was how simply doing that
Can you actually keep the email address as my Twopensource one? I want to make
sure that Twitter, my employer at the time, gets credit for this work (just as
I want to make sure that my current employer, Two Sigma, gets credit for my
current work).
Please feel free to add Signed-off-by: David
On May 8, 2017 12:25 PM, Stefan Beller wrote:
>On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker
>wrote:
>> On May 6, 2017 4:38 AM Ciro Santilli wrote:
>>> This is a must if you are working with submodules, otherwise every
>>> git checkout requires a git submodule
On Mon, May 8, 2017 at 10:08 AM, Brandon Williams wrote:
>>
>> >[submodule "gnulib"]
>> >path=./gnulib
>> >external = true # implies no branch for checkout -b --recurse-submodules
>>
>> >I think there are a couple more situations where such "external" submodules
>>
On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker
wrote:
> On May 6, 2017 4:38 AM Ciro Santilli wrote:
>> This is a must if you are working with submodules, otherwise every git
>> checkout requires a git submodule update,
>> and you forget it, and things break, and you
On Sat, May 6, 2017 at 1:40 AM, Jordi Mas wrote:
> Hello,
>
> When translating git (https://github.com/git/git/tree/master/po)
>
> The following strings cannot be translated:
>
> remote: Counting objects: 331, done.
> remote: Compressing objects: 100% (213/213), done.
>
On 05/08, Randall S. Becker wrote:
> On May 8, 2017 12:55 PM, Stefan Beller wrote:
> >On Mon, May 8, 2017 at 9:46 AM, Randall S. Becker
> >wrote:
> >> On May 8, 2017 12:25 PM, Stefan Beller wrote:
> >>>On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker
On Mon, May 8, 2017 at 9:46 AM, Randall S. Becker
wrote:
> On May 8, 2017 12:25 PM, Stefan Beller wrote:
>>On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker
>>wrote:
>>> On May 6, 2017 4:38 AM Ciro Santilli wrote:
This is a must if you are
On 05/08, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Sat, 6 May 2017, Ævar Arnfjörð Bjarmason wrote:
>
> > I have one [script] to git am a patch from a msgid, thought I should
> > write something to handle a series in some DWIM fashion (e.g. apply the
> > latest continuous sequence of patches
On 2017-05-08 03:48 AM, Junio C Hamano wrote:
* mb/diff-default-to-indent-heuristics (2017-05-02) 4 commits
(merged to 'next' on 2017-05-08 at 158f401a92)
I think there's a general open question about this, which is whether or
not we should just drop the diff.indentHeuristic configuration
On Mon, May 08, 2017 at 09:26:11PM +0200, Дилян Палаузов wrote:
> Click on https://mail.aegee.org/dpa/scan-build-git-4fa66c85f11/ and
> then on "fast-import.c: line 2057 -> View Report" and you will see
> pointless assignment.
>
> I cannot organize the report much better, as filtering out the
On 5/8/2017 4:03 PM, Christian Couder wrote:
On Mon, May 8, 2017 at 6:50 PM, Jeff Hostetler wrote:
On 5/8/2017 5:45 AM, Christian Couder wrote:
This test does not pass when the GIT_TEST_SPLIT_INDEX env variable is
set on my Linux machine.
Also it looks like you
Commit dddbad728c ("timestamp_t: a new data type for timestamps",
26-04-2017) introduced a new typedef 'timestamp_t', as a synonym for an
unsigned long, which was used at the time to represent timestamps in
git. A later commit 28f4aee3fb ("use uintmax_t for timestamps",
26-04-2017) changed the
If git is built with the FREAD_READS_DIRECTORIES build variable set, this
would cause sparse to issue a 'not declared, should it be static?' warning
on Linux. This is a result of the method employed by 'compat/fopen.c' to
suppress the (possible) redefinition of the (system) fopen macro, which
In commit f6a4e61 ("push: accept push options", 2016-07-14), send-pack
was taught to include push options both within the signed cert (if the
push is a signed push) and outside the signed cert; however,
receive-pack ignores push options within the cert, only handling push
options outside the cert.
In commit c714e45 ("receive-pack: implement advertising and receiving
push options", 2016-07-14), receive-pack was taught to (among other
things) advertise that it understood push options, depending on
configuration. It was documented that it advertised such ability by
default; however, it
Changes from v1:
- merged last 2 patches
- patch 1:
- updated advertisePushOptions doc to say "False by default"
- patch 2 (formerly 2-3):
- reject mismatching push options (similar to how a pre-receive hook
can reject a push) instead of merely reporting it
- added test to check
On Mon, May 08, 2017 at 10:02:58AM +0900, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > I guess it is ok for now and in this series, but we may want
> > to split up diff.[ch] in the future into multiple finer grained files.
>
> For what end? Such a split would
On Mon, May 8, 2017 at 2:55 PM, Jeff King wrote:
> On Mon, May 08, 2017 at 10:02:58AM +0900, Junio C Hamano wrote:
>
>> Stefan Beller writes:
>>
>> > I guess it is ok for now and in this series, but we may want
>> > to split up diff.[ch] in the future into
On Mon, May 8, 2017 at 6:50 PM, Jeff Hostetler wrote:
>
>
> On 5/8/2017 5:45 AM, Christian Couder wrote:
>>
>> This test does not pass when the GIT_TEST_SPLIT_INDEX env variable is
>> set on my Linux machine.
>>
>> Also it looks like you sent a v8 of this patch series with
On Mon, May 08, 2017 at 04:13:51PM -0300, Luciano Moreira wrote:
> Git version: 2.11.0
>
> THE CASE:
> I have 15 commit to be squashed (the hashes are real, but the commit
> messages were changed for privacy). When it's rebase interactively
> squashing all the 15 commits, the numbering goes from
On Sun, May 7, 2017 at 2:12 PM, Torsten Bögershausen wrote:
> On 2017-05-05 12:46, Samuel Lijin wrote:
>> If git sees a directory which contains only untracked and ignored
>> files, clean -d should not remove that directory. It was recently
>> discovered that this is *not* true of
Hi,
On Mon, 2017-05-08 at 09:27 +0900, Junio C Hamano wrote:
> Liam Beguin writes:
>
> > Sorry for the delay, I don't mind switching to C but it would probably
> > be easier to see if the scripted version gets approved first.
> > If it does, I could then get started on the
On 05/05/2017 05:26 PM, Jonathan Nieder wrote:
-This list is followed by a flush-pkt. Then the push options are transmitted
-one per packet followed by another flush-pkt. After that the packfile that
-should contain all the objects that the server will need to complete the new
-references will
On Sun, May 7, 2017 at 11:26 PM, Junio C Hamano wrote:
> Samuel Lijin writes:
>
>> Addresses the issues raised by Stefan and Junio (thanks for your
>> feedback) about not using C99-style comments and keeping tests
>> working on every commit to prevent
On 05/06/2017 03:09 PM, brian m. carlson wrote:
This is the eighth series of patches to convert unsigned char [20] to
struct object_id. This series converts lookup_commit, lookup_blob,
lookup_tree, lookup_tag, and finally parse_object to struct object_id.
I patched v2 (which I have reviewed)
Samuel Lijin writes:
> What happens right now is that because (1) directories containing only
> untracked and ignored files are considered "untracked" and (2)
> read_directory_recursive() skips over untracked directories, even with
> DIR_SHOW_IGNORED_TOO set. As a result,
On Tue, May 09, 2017 at 02:00:18AM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Tue, May 9, 2017 at 1:32 AM, brian m. carlson
> wrote:
> > PCRE and PCRE2 also tend to have a lot of security updates, so I would
> > prefer if we didn't import them into the tree. It is
On Tue, May 09, 2017 at 09:44:50AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Mon, May 08, 2017 at 01:56:27PM +0900, Junio C Hamano wrote:
> >
> >> Surely, even if we need to exclude some objects from an existing
> >> packfile due to these selection options, we
Hello dear,
I am Miss Makena Jelani. hope you remember me? is been a long time,
where have you been. well, contact me so we can talk
Makena.
Stefan Beller writes:
> It looks like all these lines were introduced by one of the conflict chunks
> in 4af9a7d344 (Merge branch 'bc/object-id', 2016-09-19). Viewing that
> commit in gitk, the indentation seems fine, i.e. there is just one
> whitespace in front of the lines,
1 - 100 of 110 matches
Mail list logo