On 02.08.2019 16:47, Johannes Schindelin wrote:
> and definitely does *not* want to write a file.
In this case it can use `--paths-file -`, which means stdin.
Zilch. So I find the advice you received, let's say, interesting.
I understood that `--paths-file` is suggested to avoid possible
std
On 02.08.2019 16:48, Johannes Schindelin wrote:
How about subscribing to that PR so you get updates without requiring me
to remember to send you a manual email?
This option evaded me :) Subscribed, thanks!
Hi Alexandr,
On Fri, 2 Aug 2019, Alexandr Miloslavskiy wrote:
> On 02.08.2019 13:33, Johannes Schindelin wrote:
> > Please note that I have a patch series (currently on hold because of the
> > v2.23.0 feature freeze) to teach `git reset` an `--stdin` option:
> > https://github.com/gitgitgadget/gi
Hi Alexandr,
On Fri, 2 Aug 2019, Alexandr Miloslavskiy wrote:
> On 02.08.2019 13:33, Johannes Schindelin wrote:
> > to teach `git reset` an `--stdin` option:
>
> I think it should be changed to follow the approach decided
> here [1] - that is, use '--paths-file', and '--paths-file -'
> will mean
On 02.08.2019 13:33, Johannes Schindelin wrote:
to teach `git reset` an `--stdin` option:
I think it should be changed to follow the approach decided
here [1] - that is, use '--paths-file', and '--paths-file -'
will mean "from stdin"
[1]
https://public-inbox.org/git/a6610e94-6318-b962-5dd0-ca
On 02.08.2019 13:33, Johannes Schindelin wrote:
Please note that I have a patch series (currently on hold because of the
v2.23.0 feature freeze) to teach `git reset` an `--stdin` option:
https://github.com/gitgitgadget/git/pull/133
Perfect! Less work for me :)
Once your patch is accepted, could
@Johannes, thanks a lot for your tips!
On 02.08.2019 13:40, Johannes Schindelin wrote:
From past experience, I find that it is important to also implement the
`-z` option (which traditionally means: accept items via the command
line that are delimited by NULs).
And you might find inspiration i
Hi Alexandr,
On Thu, 1 Aug 2019, Alexandr Miloslavskiy wrote:
> On 01.08.2019 22:45, Junio C Hamano wrote:
> > That does not mean that any patch along that line will automatically
> > be accepted, of course, so the answer to "am I ready to accept"
> > question is a definite no. No, I am not read
Hi Alexandr,
On Thu, 1 Aug 2019, Alexandr Miloslavskiy wrote:
> 4) git reset
Please note that I have a patch series (currently on hold because of the
v2.23.0 feature freeze) to teach `git reset` an `--stdin` option:
https://github.com/gitgitgadget/git/pull/133
Ciao,
Johannes
On 01.08.2019 22:45, Junio C Hamano wrote:
That does not mean that any patch along that line will automatically
be accepted, of course, so the answer to "am I ready to accept"
question is a definite no. No, I am not ready---we will have to
look at the actual patches before deciding.
That's why
Alexandr Miloslavskiy writes:
> On 01.08.2019 17:56, Junio C Hamano wrote:
>> So, reading paths from a file (which could be "-" as you suggest)
>> would be a good solution for that.
>
> To summarize:
> 1) Implement --paths-file for high-level commands.
> 2) '--paths-file -' would mean reading fro
On 01.08.2019 22:26, Junio C Hamano wrote:
All true. Perhaps we need a separate tutorial for scripters to
teach them how to properly combine the plumbing commands?
@Phillip thanks for your effort!
However, I must admit that for us, this cure is worse then the problem.
We're not exactly scrip
Phillip Wood writes:
> No but it only takes paths not pathspecs, can you filter out the
> ignored paths first? From a UI point of view it would be better not to
> allow users to select ignored files if you don't want to be able to
> add them. If you want to use a pathspec then you can do 'git ls-
On 01/08/2019 14:25, Alexandr Miloslavskiy wrote:
On 31.07.2019 19:19, Jeff King wrote:
I don't have any real objection to adding stdin support for more
commands. Bu tin the specific case you're discussing, it seems like
using "git update-index" might already solve your problem. It's the
intende
On 01.08.2019 17:56, Junio C Hamano wrote:
So, reading paths from a file (which could be "-" as you suggest)
would be a good solution for that.
To summarize:
1) Implement --paths-file for high-level commands.
2) '--paths-file -' would mean reading from stdin.
Is that something you're ready to
René Scharfe writes:
> Would it make sense to have a --paths-file parameter instead that allows
> reading paths from a given file and honors the convention of reading
> from stdin with the special argument "-"? Reading from stdin would
> still only work for one parameter at a time, but paths cou
On 01.08.2019 16:26, René Scharfe wrote:
Would it make sense to have a --paths-file parameter instead
Both approaches (stdin or file) will work well for us. File sounds
easier from programming perspective. However, in previous discussion,
there was some concern about possible security problems
Am 31.07.19 um 17:45 schrieb Alexandr Miloslavskiy:
> Our suggestion is to change commands such as 'commit', 'add', etc to
> also work with --stdin-paths. If a command already supports stdin for
> any purpose, then trying to use both options will return an error.
Would it make sense to have a --pa
On 31.07.2019 19:19, Jeff King wrote:
I don't have any real objection to adding stdin support for more
commands. Bu tin the specific case you're discussing, it seems like
using "git update-index" might already solve your problem. It's the
intended plumbing for scripted index updates, and it alrea
Jeff King writes:
> ... But in the specific case you're discussing, it seems like
> using "git update-index" might already solve your problem. It's the
> intended plumbing for scripted index updates, and it already supports
> receiving paths from stdin.
Sounds good.
On Wed, Jul 31, 2019 at 05:45:12PM +0200, Alexandr Miloslavskiy wrote:
> In our git UI, we sometimes run into OS commandline length limit when
> trying to specify a list of pathspecs. For example, this happens when
> user selects a large set of files and wants to commit them. As a
> workaround, we
Alexandr Miloslavskiy writes:
> In our git UI, we sometimes run into OS commandline length limit when
> trying to specify a list of pathspecs. For example, this happens when
> user selects a large set of files and wants to commit them. As a
> workaround, we split files and issue multiple git comm
Hello,
Hello,
This is a follow-up for previous discussion [1].
In our git UI, we sometimes run into OS commandline length limit when
trying to specify a list of pathspecs. For example, this happens when
user selects a large set of files and wants to commit them. As a
workaround, we split files
23 matches
Mail list logo
