On Tue, Nov 1, 2016 at 2:23 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Tue, Nov 01, 2016 at 08:50:23PM -, Philip Oakley wrote:
>>
>>> > From "git help update-index":
>>> >
>>> > --[no-]assume-unchanged
>>> >When this flag is specified, the object names recorded for
>>> >
On Fri, Nov 04, 2016 at 01:03:51AM +0100, Andrea Arcangeli wrote:
> > can see why it is confused and does what it does (the whole email is
> > inside a double-quoted portion that is never closed, so it probably
> > thinks there is no hostname portion at all).
>
> I would see it too, if it actuall
On Thu, Nov 03, 2016 at 10:18:48AM -0400, Jeff King wrote:
> bogus header. The munging that postfix does makes things worse, but I
I agree it makes things worse.
> can see why it is confused and does what it does (the whole email is
> inside a double-quoted portion that is never closed, so it pro
Am 03.11.2016 um 21:44 schrieb Jeff King:
On Thu, Nov 03, 2016 at 09:40:01PM +0100, Johannes Sixt wrote:
We have to use $PWD instead of $(pwd) because on Windows...
Thanks. I have to admit I remain confused about which one to use at any
given invocation
No worries. It *is* complex, and I don
On Thu, Nov 3, 2016 at 1:47 PM, Johannes Sixt wrote:
> Am 28.10.2016 um 20:54 schrieb Stefan Beller:
>>
>> previous discussion at
>> https://public-inbox.org/git/20161022233225.8883-1-sbel...@google.com
>>
>> This implements the discarded series':
>> jc/attr
>> jc/attr-more
>> sb/pathspec-label
>>
Am 02.11.2016 um 19:18 schrieb Jeff King:
> We create a rot13.sh script in the trash directory, but need
> to call it by its full path when we have moved our cwd to
> another directory. Let's just put $TEST_ROOT in our $PATH so
> that the script is always found.
>
> This is a minor convenience for
Am 28.10.2016 um 20:54 schrieb Stefan Beller:
previous discussion at
https://public-inbox.org/git/20161022233225.8883-1-sbel...@google.com
This implements the discarded series':
jc/attr
jc/attr-more
sb/pathspec-label
sb/submodule-default-paths
This includes
* The fixes for windows
I've teste
On Thu, Nov 03, 2016 at 09:40:01PM +0100, Johannes Sixt wrote:
> > TEST_ROOT="$(pwd)"
> > +PATH=$TEST_ROOT:$PATH
>
> This causes problems on Windows. We need the following squashed in.
>
> 8<
> [PATCH] squash! t0021: put $TEST_ROOT in $PATH
>
> We have to use $PWD instead of $(pwd) b
Instead of a pipeline with sed and a useless use of cat, return the
unmodified text of wc -c from function file_size, but substitute the
result with arithmetic expansion to get rid of the leading whitespace
that some version of wc -c print.
Signed-off-by: Johannes Sixt
---
This is a pure optimiza
Some versions of uniq -c write the count left-justified, other version
write it right-justified. Be prepared for both kinds.
Signed-off-by: Johannes Sixt
---
Here it is as a proper patch.
Am 03.11.2016 um 01:41 schrieb Lars Schneider:
>> On 2 Nov 2016, at 18:03, Johannes Sixt wrote:
>> +
On 11/03, Jeff King wrote:
> On Thu, Nov 03, 2016 at 11:45:38AM -0700, Brandon Williams wrote:
>
> > On 11/03, Jeff King wrote:
> > >
> > > So this seems like a reasonable direction to me. It obviously needs
> > > documentation and tests. Arguably there should be a fallback "allow"
> > > value wh
On Thu, Nov 03, 2016 at 11:45:38AM -0700, Brandon Williams wrote:
> On 11/03, Jeff King wrote:
> >
> > So this seems like a reasonable direction to me. It obviously needs
> > documentation and tests. Arguably there should be a fallback "allow"
> > value when a protocol is not mentioned in the con
On 11/03, Jeff King wrote:
>
> So this seems like a reasonable direction to me. It obviously needs
> documentation and tests. Arguably there should be a fallback "allow"
> value when a protocol is not mentioned in the config so that you could
> convert the default from "user" to "never" if you wan
On Thu, Nov 03, 2016 at 11:19:54AM -0700, Brandon Williams wrote:
> On 11/03, Jeff King wrote:
> > +
> > + /* unknown; let them be used only directly by the user */
> > + return PROTOCOL_ALLOW_USER_ONLY;
> > +}
> > +
> > int is_transport_allowed(const char *type)
> > {
> > - const struct s
On Thu, Nov 03, 2016 at 01:53:27PM -0400, Jeff King wrote:
> I'd design the new system from scratch, and have it kick in _only_ when
> GIT_ALLOW_PROTOCOL is not set. That lets existing callers continue to
> have the safe behavior until they are ready to move to the new format.
>
> Something like
On 11/03, Jeff King wrote:
> +
> + /* unknown; let them be used only directly by the user */
> + return PROTOCOL_ALLOW_USER_ONLY;
> +}
> +
> int is_transport_allowed(const char *type)
> {
> - const struct string_list *allowed = protocol_whitelist();
> - return !allowed || string_l
On 11/03, Jeff King wrote:
> On Thu, Nov 03, 2016 at 10:51:31AM -0700, Brandon Williams wrote:
>
> > > > I don't know if I'm sold on a 'user' state just yet, perhaps that's just
> > > > because I view a whitelist or blacklist as well black and white and
> > > > having this user state adds in a gra
On Thu, Nov 03, 2016 at 10:51:31AM -0700, Brandon Williams wrote:
> > > I don't know if I'm sold on a 'user' state just yet, perhaps that's just
> > > because I view a whitelist or blacklist as well black and white and
> > > having this user state adds in a gray area.
> >
> > Well the "user" stat
On Thu, Nov 03, 2016 at 10:39:35AM -0700, Stefan Beller wrote:
> >> protocol.X.allow = always | user | never
> >
> > It sounds like there is interest for this sort of behavior, it would
> > definitely require a larger change than what I initially proposed. One
> > problem I see though is that w
On Thu, Nov 03, 2016 at 10:25:15AM -0700, Brandon Williams wrote:
> > So I think this probably needs to be a separate parallel system where
> > each protocol can be white- or black-listed in a context-specific way.
> > Like:
> >
> > protocol.X.allow = always | user | never
>
> It sounds like t
On 11/03, Stefan Beller wrote:
> >> protocol.X.allow = always | user | never
> >
> > It sounds like there is interest for this sort of behavior, it would
> > definitely require a larger change than what I initially proposed. One
> > problem I see though is that with this we have support for both
Signed-off-by: Stefan Beller
---
I discovered this, when going over this series myself once again, as
I am thinking about how this setting may affect the
"git checkout --recurse-submodules" that I am currently working on.
I'll include this in a resend, if a resend is needed (i.e. more changes
ar
>> protocol.X.allow = always | user | never
>
> It sounds like there is interest for this sort of behavior, it would
> definitely require a larger change than what I initially proposed. One
> problem I see though is that with this we have support for both a
> blacklist and a whitelist. Which wi
On 11/03, Jeff King wrote:
> On Wed, Nov 02, 2016 at 05:22:25PM -0700, Jonathan Nieder wrote:
>
> > Another difficulty with setting GIT_ALLOW_PROTOCOL globally is that it
> > requires copy/pasting the default value from upstream and then adding
> > the values I want. There's no straightforward wa
Scratch my last message, I figured out how to restore it. In the
TortoiseGit context menu I selected "Diff", and in the list the
deleted files were listed as "missing". I selected them all, right
clicked them, and selected "revert". Still don't know why the dir got
deleted in the first place though
Actually, I just tried restoring my dir with `git pull origin
clipping`, but that didn't restore it. So, besides the question "why
did it get deleted", I'd like to ask "how do I restore it?", as well.
On Thu, Nov 3, 2016 at 6:06 PM, Stefan Monov wrote:
> Hi.
>
> I just tried `git stash save` for
Hi Peff,
On Thu, 3 Nov 2016, Jeff King wrote:
> On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote:
>
> > This is missing a Content-Transfer-Encoding. I think the default is the
> > traditional 7-bit ascii encoding, but your body has characters with the
> > high-bit set (your UTF-8 bullet
This is just a test mail to test whether the bullet offends vger, still,
even with the headers indicated by Peff:
• This is a bullet point.
Fingers crossed,
Dscho
On Thu, Nov 03, 2016 at 03:59:13PM +, Chris Purcell wrote:
> >> Thanks, Jeff! If I remove the explicit configuration of remote.pushdefault
> >> = "origin", I get the same error message as you, so I suspect that's _not_
> >> the default.
> >
> > That's really bizarre, because I get the same beh
Will do, thanks! Meanwhile, I'll work around locally by changing off
'simple' in my config—if I can figure out how not to break everything
in the process...
On 3 November 2016 at 16:07, Jeff King wrote:
> On Thu, Nov 03, 2016 at 03:59:13PM +, Chris Purcell wrote:
>
>> >> Thanks, Jeff! If I re
Hi.
I just tried `git stash save` for the first time. It worked fine. Then
I tried `git stash apply` and while my uncommitted changes were
restored, another effect was that a random dir from the root of my
working copy was deleted. I don't know why it chose that exact dir,
there's lots of other di
>> Thanks, Jeff! If I remove the explicit configuration of remote.pushdefault
>> = "origin", I get the same error message as you, so I suspect that's _not_
>> the default.
>
> That's really bizarre, because I get the same behavior with or without
> it set. Not only that, but it shouldn't even come
If the contents of a file initially are:
one
three
and on branch A there is a commit, removing the blank line:
one
three
and on branch B there is a commit, adding 'two':
one
two
three
Normally, if you try to merge A into B (or B into A), git recognizes a
decision needs to be made bet
On Thu, Nov 03, 2016 at 03:48:50PM +, Chris Purcell wrote:
> Thanks, Jeff! If I remove the explicit configuration of remote.pushdefault
> = "origin", I get the same error message as you, so I suspect that's _not_
> the default.
That's really bizarre, because I get the same behavior with or wi
Resending to mailing list because Inbox is fighting with vger...
On 3 November 2016 at 15:48, Chris Purcell wrote:
> Thanks, Jeff! If I remove the explicit configuration of remote.pushdefault =
> "origin", I get the same error message as you, so I suspect that's _not_ the
> default.
>
> On Thu, 3
On Thu, Nov 03, 2016 at 11:38:45AM -0400, Jeff King wrote:
> On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote:
>
> > This is missing a Content-Transfer-Encoding. I think the default is the
> > traditional 7-bit ascii encoding, but your body has characters with the
> > high-bit set (your
On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote:
> This is missing a Content-Transfer-Encoding. I think the default is the
> traditional 7-bit ascii encoding, but your body has characters with the
> high-bit set (your UTF-8 bullet).
>
> Try adding:
>
> Content-Transfer-Encoding: 8bit
On Thu, Nov 03, 2016 at 04:15:05PM +0100, Johannes Schindelin wrote:
> When it finally sent out the mail, and I thought everything was alright,
> thinking that I could turn out for the night with a well-deserved drink, I
> got this from vger.kernel.org:
>
> -- snip --
> SMTP error from remote ser
Johannes Schindelin writes:
> thinking that I could turn out for the night with a well-deserved drink, I
> got this from vger.kernel.org:
>
> -- snip --
> SMTP error from remote server for TEXT command, host: vger.kernel.org
> (209.132.180.67) reason: 550 5.7.1 Content-Policy reject msg: Wrong M
Hi all,
On Wed, 2 Nov 2016, Johannes Schindelin wrote:
> Dear Git users,
>
> It is my pleasure to announce that Git for Windows 2.10.2 is available from:
>
> https://git-for-windows.github.io/
> [...]
I originally intended this to be sent out at the same time as the
announcement to the G
On Thu, Nov 03, 2016 at 02:53:44PM +, Chris Purcell wrote:
> I think I have discovered a bug in rev-parse's handling of @{push}:
>
> $ git push
> Everything up-to-date
> $ git rev-parse @{push}
> fatal: cannot resolve 'simple' push to a single destination
>
> The documentation for rev-parse
Hi folks,
I think I have discovered a bug in rev-parse's handling of @{push}:
$ git push
Everything up-to-date
$ git rev-parse @{push}
fatal: cannot resolve 'simple' push to a single destination
The documentation for rev-parse says that "the suffix @{push} reports
the branch 'where we would push
On Wed, Nov 02, 2016 at 05:22:25PM -0700, Jonathan Nieder wrote:
> Another difficulty with setting GIT_ALLOW_PROTOCOL globally is that it
> requires copy/pasting the default value from upstream and then adding
> the values I want. There's no straightforward way to get the current
> value and add
On Tue, Oct 25, 2016 at 12:52 PM, Duy Nguyen wrote:
> On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
> wrote:
>> Goal
>>
>>
>> We want to make it possible to use the split-index feature
>> automatically by just setting a new "core.splitIndex" configuration
>> variable to true.
>
> Thanks.
On 3 November 2016 at 15:18, Jeff King wrote:
> On Wed, Nov 02, 2016 at 11:29:01PM +0100, Andrea Arcangeli wrote:
>
>> So this must be postfix then that out of the blue decided to garble it
>> in a strange way while parsing the input... The removal of all
>> whitespaces s/what ever/whatever/ espec
> On 2 Nov 2016, at 17:43, Johannes Sixt wrote:
>
> Am 02.11.2016 um 18:04 schrieb Torsten Bögershausen:
>>> * ls/filter-process (2016-10-17) 14 commits
>>> (merged to 'next' on 2016-10-19 at ffd0de042c)
>>
>> Some (late, as I recently got a new battery for the Mac OS 10.6 test system)
>> com
On Wed, Nov 02, 2016 at 11:29:01PM +0100, Andrea Arcangeli wrote:
> So this must be postfix then that out of the blue decided to garble it
> in a strange way while parsing the input... The removal of all
> whitespaces s/what ever/whatever/ especially I've no idea how it
> decided to do so.
>
> Ca
47 matches
Mail list logo
