Yes. You're right. It is about Git for Windows installer. Thanks for the
answer. My problem was solved by creating a variable HOME in the parameters of
the medium and refers to ssh.
19.08.2015, 16:17, "Johannes Schindelin" :
> Hi Aleksey,
>
> On 2015-08-19 09:33, Цапков Алексей wrote:
>
>> When
On Fri, Aug 21, 2015 at 1:53 AM, Eric Sunshine wrote:
> On Tue, Aug 18, 2015 at 2:37 PM, Karthik Nayak wrote:
>> Implement an `align` atom which left-, middle-, or right-aligns the
>> content between %(align:..) and %(end).
>>
>> It is followed by `:,`, where the `` is
>> either left, right or mi
This adds functionality to do work in parallel.
The whole life cycle of such a thread pool would look like
struct task_queue * tq = create_task_queue(32); // no of threads
for (...)
add_task(tq, process_one_item_function, item); // non blocking
...
int ret = finish_task_qu
`module_clone` is part of the update command, which I want to convert
to C next.
Signed-off-by: Stefan Beller
---
Replacing the latest patch in sb/submodule-helper as that contains
debug code in `cmd_submodule__helper`.
builtin/submodule--helper.c | 156
This runs a command on each submodule in parallel and should eventually
replace `git submodule foreach`.
There is a new option -j/--jobs (inspired by make) to specify the number
of parallel threads.
The jobs=1 case needs to be special cases to exactly replicate the current
default behavior of `gi
We defaulted to ignoring merge diffs because long long ago, in a
galaxy far away, we didn't have a great way to show the diffs. The
whole "--cc" option goes back to January '06 and commit d8f4790e6fe7
("diff-tree --cc: denser combined diff output for a merge commit").
And before that option - so f
The "--cc" option to "git log" is clearly a request to show some
sort of combined diff (be it --patch or --raw), but traditionally
we required the command line to explicitly ask for "git log -p --cc".
Teach the command line parser to treat a lone "--cc" as if the user
specified "-p --cc". Formats
This is a combination of two closely related topics.
- The second patch is my long-time pet peeve (it is even on the
leftover-bits list at git-blame blog). When inspecting a branch,
I often type "git log --first-parent --cc master..", and then
realize that I need to give "-p" to actuall
The revision walking API allows the callers to tweak its
configuration at the last minute, immediately after all the revision
and pathspec parameters are parsed from the command line but before
the default actions are decided based on them, by defining a "tweak"
callback function when calling setup
Quoting Junio C Hamano :
SZEDER Gábor writes:
The declaration of 'struct wt_status' requires the declararion of 'struct
pathspec'.
I think this is fine.
I am guessing that you are saying it is wrong to force wt-status.c
to include pathspec.h before including wt-status.h; I am fine with
th
When looking for the start of the trailers in the message
we are passed, we should ignore the first line of the message.
The reason is that if we are passed a patch or commit message
then the first line should be the patch title.
If we are passed only trailers we can expect that they start
with an
From: Lars Schneider
PROBLEM:
We run P4 servers on Linux and P4 clients on Windows. For an unknown
reason the file path for a number of files in P4 does not match the
directory path with respect to case sensitivity.
E.g. `p4 files` might return
//depot/path/to/file1
//depot/PATH/to/file2
If you
On Thu, Aug 20, 2015 at 12:05:34PM -0700, Junio C Hamano wrote:
> This is a tangent, but the above is different from saying that with
> a single liner test.c that has
>
> #include "wt-status.h"
>
> your compilation "cc -c test.c" should succeed. But for that goal,
> direct inclusion of to
On Tue, Aug 18, 2015 at 2:37 PM, Karthik Nayak wrote:
> Implement an `align` atom which left-, middle-, or right-aligns the
> content between %(align:..) and %(end).
>
> It is followed by `:,`, where the `` is
> either left, right or middle and `` is the size of the area
> into which the content w
Jeff King writes:
> On Thu, Aug 20, 2015 at 04:14:22PM +0200, SZEDER Gábor wrote:
>
>> Commit 578625fa91 (config: add '--name-only' option to list only
>> variable names, 2015-08-10) modified format_config() such that it
>> returned from the middle of the function when showing only keys,
>> resul
SZEDER Gábor writes:
> The declaration of 'struct wt_status' requires the declararion of 'struct
> pathspec'.
I think this is fine.
I am guessing that you are saying it is wrong to force wt-status.c
to include pathspec.h before including wt-status.h; I am fine with
that.
This is a tangent, but
On 2015-08-20 09.16, Lars Schneider wrote:
> Thanks for your feedback! See my answers below.
>> Identify path names that are different with respect to case sensitivity.
> Agreed!
>
>>
>>
>>> If there are any then run `p4 dirs` to build up a dictionary
>>> containing the "correct" cases for each pa
SZEDER Gábor writes:
> The format of the files '.git/rebase-apply/{next,last}' changed slightly
> with the recent builtin 'git am' conversion: while these files were
> newline-terminated when written by the scripted version, the ones written
> by the builtin are not.
Thanks for noticing; that sh
SZEDER Gábor writes:
> 'git describe [...] --always' should always show the unique abbreviated
> object name as a fallback when the given commit cannot be described with
> the given set of options, see da2478dbb0 (describe --always: fall back
> to showing an abbreviated object name, 2008-03-02).
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> So I think 'quote' should apply only to the top-level atoms in the
>> nested %(magic)...%(end) world.
>
> This is true in most cases, but I think there would also be use-cases
> where you would want the opposite, like:
>
> --format '
> %(if:
On Thu, Aug 20, 2015 at 1:24 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>> +sed -n '
>> + 1,/^### common groups/b
>> + /^### command list/q
>> + /^#/d; /^[ ]*$/b
>> + h;s/^[^ ][^ ]*[ ][ ]*\(.*\)/ N_("\1"),/p
>> + g;s/^\([^ ][^ ]
On Wed, Aug 19, 2015 at 6:38 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>> In addition to reviving 527ec39^:generate-cmdlist.sh and extending it, I
>> also re-indented it with tabs instead of spaces, so it's helpful to
>> ignore whitespace changes when comparing the old and new versions of
Eric Sunshine writes:
> diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
> new file mode 100755
> index 000..1ac329d
> --- /dev/null
> +++ b/generate-cmdlist.sh
> @@ -0,0 +1,50 @@
> +#!/bin/sh
> +
> +echo "/* Automatically generated by $0 */
> +struct cmdname_help {
> + char name[16
Junio C Hamano writes:
> So I think 'quote' should apply only to the top-level atoms in the
> nested %(magic)...%(end) world.
This is true in most cases, but I think there would also be use-cases
where you would want the opposite, like:
--format '
%(if:whatever)
echo %(refname)
%(en
On Thu, Aug 20, 2015 at 6:37 PM, Matthieu Moy
wrote:
> Hi,
>
> I use 'git interpret-trailers' as a commit-msg hook to add a
> Signed-off-by in a repository.
>
> When used in a one-line commit message formatted like
> 'foo: do something', the command interprets the one-line summary as a
> trailer,
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> You replaced the quote_style argument with ref_formatting_state, and I
>> think you should have kept this argument and added ref_formatting_state.
>> The other option is to add an extra indirection like
>>
>> struct ref_formatting_state {
>>
Matthieu Moy writes:
> Karthik Nayak writes:
>
>> Speaking of quote_value, The quote doesn't work well with color's
>> for e.g.
>> git for-each-ref --shell --format="%(color:green)%(refname)"
>> '''refs/heads/allow-unknown-type'''
>> Seems like an simple fix, probably after GSoC I'll do this :)
Hi,
I use 'git interpret-trailers' as a commit-msg hook to add a
Signed-off-by in a repository.
When used in a one-line commit message formatted like
'foo: do something', the command interprets the one-line summary as a
trailer, and inserts my Signed-off-by after it, without a blank line:
fo
Konstantin Hollerith writes:
> Why does git branch -d acts differently after a clone?
In the former case, that branch is the only thing that knows about
the commits near the tip of it. Immediately after you clone that
repository, you have a copy of that branch as a remote-tracking
branch for or
Lars Schneider writes:
>>> + find . | grep TWO/file1.txt &&
>>> + find . | grep TWO/File2.txt &&
>>> + find . | grep TWO/file3.txt &&
>> Not sure about the find | grep here either.
> See answers above.
These are not very good tests; they will match "OTWO/file1.txto"
On Wed, Aug 19, 2015 at 8:23 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> --- a/Documentation/git-tag.txt
>> +++ b/Documentation/git-tag.txt
>> @@ -158,6 +159,18 @@ This option is only applicable when listing tags
>> without annotation lines.
>> The object that the new tag will ref
It's unusual for a function which writes to a passed-in
strbuf to call strbuf_init; that will throw away anything
already there, leaking memory. In this case, there are
exactly two callers; one relies on this initialization and
the other passes in an already-initialized buffer.
There's no leak, as
We create a strbuf only to insert a single string, pass the
resulting buffer to a function (which does not modify the
string), and then free it. We can just pass the original
string instead.
Signed-off-by: Jeff King
---
I keep staring at this thinking I missed something, but I think this is
an eq
When formatting a config value into a strbuf, we may end
up stringifying it into a fixed-size buffer using sprintf,
and then copying that buffer into the strbuf. We can
eliminate the middle-man (and drop some calls to sprintf!)
by writing directly to the strbuf.
The reason it was written this way
On Thu, Aug 20, 2015 at 04:14:22PM +0200, SZEDER Gábor wrote:
> Commit 578625fa91 (config: add '--name-only' option to list only
> variable names, 2015-08-10) modified format_config() such that it
> returned from the middle of the function when showing only keys,
> resulting in ugly code structure
Commit 578625fa91 (config: add '--name-only' option to list only
variable names, 2015-08-10) modified format_config() such that it
returned from the middle of the function when showing only keys,
resulting in ugly code structure.
Reorganize the if statements and dealing with the key-value delimite
The declaration of 'struct wt_status' requires the declararion of 'struct
pathspec'.
Signed-off-by: SZEDER Gábor
---
wt-status.c | 1 -
wt-status.h | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index 717fd48d13..c327fe8128 100644
--- a/wt-status.c
Signed-off-by: SZEDER Gábor
---
t/t3020-ls-files-error-unmatch.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t3020-ls-files-error-unmatch.sh
b/t/t3020-ls-files-error-unmatch.sh
index ca01053bcc..124e73b8e6 100755
--- a/t/t3020-ls-files-error-unmatch.sh
+++ b/t/t3020-ls
Hi,
The format of the files '.git/rebase-apply/{next,last}' changed slightly
with the recent builtin 'git am' conversion: while these files were
newline-terminated when written by the scripted version, the ones written
by the builtin are not.
This probably makes no difference for shell scripts
On Thu, Aug 20, 2015 at 3:16 AM, Lars Schneider
wrote:
> On 20 Aug 2015, at 06:59, Torsten Bögershausen wrote:
>> On 08/19/2015 10:04 PM, larsxschnei...@gmail.com wrote:
>>> From: Lars Schneider
>>> +find . | grep two/File2.txt &&
>> Should we make sure that two/File2.txt exist?
>> T
'git describe [...] --always' should always show the unique abbreviated
object name as a fallback when the given commit cannot be described with
the given set of options, see da2478dbb0 (describe --always: fall back
to showing an abbreviated object name, 2008-03-02).
However, this is not the case
Hi,
I created a simple repository.
If i create a new branch from master and commit some changes and
then delete it with
git branch -d neuerTestBranch
I'll get a error:
error: The branch 'neuerTestBranch' is not fully merged.
I like that error, it reminds me, that i forgot to merge.
How
On Thu, Aug 20, 2015 at 12:22 AM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> You replaced the quote_style argument with ref_formatting_state, and I
>> think you should have kept this argument and added ref_formatting_state.
>> The other option is to add an extra indirection like
>>
>> stru
On Thu, Aug 20, 2015 at 12:59 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> Speaking of quote_value, The quote doesn't work well with color's
>> for e.g.
>> git for-each-ref --shell --format="%(color:green)%(refname)"
>> '''refs/heads/allow-unknown-type'''
>> Seems like an simple fix, prob
Karthik Nayak writes:
> Speaking of quote_value, The quote doesn't work well with color's
> for e.g.
> git for-each-ref --shell --format="%(color:green)%(refname)"
> '''refs/heads/allow-unknown-type'''
> Seems like an simple fix, probably after GSoC I'll do this :)
Anyway, the %(color) is really
Thanks for your feedback! See my answers below.
On 20 Aug 2015, at 06:59, Torsten Bögershausen wrote:
> Some nit-picking below:
> On 08/19/2015 10:04 PM, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>> PROBLEM:
>> We run P4 servers on Linux and P4 clients on Windows. For an unkno
46 matches
Mail list logo
