On 24/08/15 22:30, larsxschnei...@gmail.com wrote:
From: Lars Schneider
Thanks to Luke Diamand I realized the core problem and propose here a
substiantially simpler fix to my PATCH v4.
The test cases remain and prove the problem. In particular
"8 - Clone path (ignorecase)" and
"Add a new file
Junio C Hamano writes:
> You can see that I expected that "if !state.stack->prev" check to be
> inside append_atom(), and I would imagine future readers would have
> the same expectation when reading this code. I.e.
>
> append_atom(struct atom_value *v, struct ref_f_s *state)
> {
>
On Mon, Aug 24, 2015 at 12:11:13PM -0400, Aaron Dufour wrote:
> I use git (2.2.1) on OS X (10.9.5) and recently my repo got into a bad
> state. I think this involves a mis-handling of case-insensitive file
> systems.
>
> This reproduces the problem:
>
> > git init
> Initialized empty Gi
Доброго дня,
будь ласка, просимо переглянути наш шкільний сайт,
якщо це не важко для вас,
http://154school.kiev.ua/ - будь ласка, відкрийте його для перегляду
однієї-двох сторінок,
і на будь-якій сторінці один раз натисніть на рекламний банер, який вам
найбільш цікавий,
це Ваша допомога, щоб ми
Hi All,
I have built and tested the latest version on git on multiple
distributions including Ubuntu 15.04 on the ppc64le architecture. I
have run the complete test suite and verified that there are no test
failures.
I have also written a dockerfile for this for Ubuntu 15.04 and wanted
to unders
On Sat, Aug 22, 2015 at 11:51 PM, Michael Rappazzo wrote:
> 'git worktree list' uses the for_each_worktree function to iterate,
> and outputs in the format: ' ()'
>
> Signed-off-by: Michael Rappazzo
> ---
> Documentation/git-worktree.txt | 11 +-
> builtin/worktree.c | 55 ++
Wow, yeah, that was it. Thanks for your help!
> On Aug 24, 2015, at 2:24 AM, John Keeping wrote:
>
>> On Sun, Aug 23, 2015 at 11:40:17AM -0700, Anish Athalye wrote:
>> I'm having some issues with git remote helper behavior on Windows.
>>
>> According to the protocol
>> (https://www.kernel.org
On Mon, Aug 24, 2015 at 2:05 PM, Junio C Hamano wrote:
> Michael Rappazzo writes:
>> + strbuf_strip_suffix(&head_ref, "\n");
>> +
>> + if (starts_with(head_ref.buf, ref_prefix)) {
>> + /* branch checked out */
>> + strbuf_remove(&hea
On Mon, Aug 24, 2015 at 02:30:39AM -0700, Jeff S wrote:
> XSLTPROC user-manual.html
> warning: failed to load external entity
> "http://docbook.sourceforge.net/release/xsl/current/common/l10n.xsl";
> compilation error: file
> http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl line
On Mon, Aug 24, 2015 at 01:58:04PM -0700, Junio C Hamano wrote:
> The workhorse helper function that implements "we have this (short)
> body of text; create a new file that contains it" has a "fatal"
> parameter, to which 1 was passed by almost all callers, but to
> casual readers, it was unclear
On Mon, Aug 24, 2015 at 01:58:06PM -0700, Junio C Hamano wrote:
> We forgot to terminate the payload given to write_file() with LF,
> resulting in files that end with an incomplete line. Teach the
> wrappers builtin/am uses to make sure it adds LF at the end as
> necessary.
Is it even worth doin
On Sun, Aug 23, 2015 at 01:50:53PM +0800, Paul Tan wrote:
> Did we ever explictly allow external programs to poke around the
> contents of the .git/rebase-apply directory? I think it may not be so
> good, as it means that it may not be possible to switch the storage
> format in the future (e.g. to
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Karthik Nayak writes:
>>
>>> diff --git a/Documentation/git-for-each-ref.txt
>>> b/Documentation/git-for-each-ref.txt
>>> index 1997657..06d468e 100644
>>> --- a/Documentation/git-for-each-ref.txt
>>> +++ b/Documentation/git-for-each-ref.txt
>
Junio C Hamano writes:
> Karthik Nayak writes:
>
>> On Mon, Aug 24, 2015 at 10:57 PM, Junio C Hamano wrote:
>>> Karthik Nayak writes:
>>> ...
+ performed. If used with '--quote' everything in between %(align:..)
+ and %(end) is quoted.
>> ...
>> I might have misunderstood you
Matthieu Moy writes:
> Karthik Nayak writes:
>
>> diff --git a/Documentation/git-for-each-ref.txt
>> b/Documentation/git-for-each-ref.txt
>> index 1997657..06d468e 100644
>> --- a/Documentation/git-for-each-ref.txt
>> +++ b/Documentation/git-for-each-ref.txt
>> @@ -133,7 +133,8 @@ align::
>>
Karthik Nayak writes:
> From: Karthik Nayak
>
> Add a function called 'for_each_reftype_fullpath()' to refs.{c,h}
> which iterates through each ref for the given path without trimming
> the path and also accounting for broken refs, if mentioned.
For this part, I think you would want to borrow a
Junio C Hamano writes:
> Karthik Nayak writes:
>
>> +static void end_atom_handler(struct atom_value *atomv, struct
>> ref_formatting_state *state)
>> +{
>> +struct ref_formatting_stack *current = state->stack;
>> +struct strbuf s = STRBUF_INIT;
>> +
>> +if (!current->at_end)
>> +
Karthik Nayak writes:
> +static void perform_quote_formatting(struct strbuf *s, const char *str, int
> quote_style);
> +
> +static void end_atom_handler(struct atom_value *atomv, struct
> ref_formatting_state *state)
> +{
> + struct ref_formatting_stack *current = state->stack;
> + stru
Karthik Nayak writes:
> +static void push_new_stack_element(struct ref_formatting_stack **stack)
> +{
Micronit. Perhaps s/_new//;, as you do not call the other function
pop_old_stack_element().
The remainder of this step looks pretty straight-forward and was a
pleasant read.
Thanks.
--
To uns
From: Lars Schneider
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 use P4/P
From: Lars Schneider
Thanks to Luke Diamand I realized the core problem and propose here a
substiantially simpler fix to my PATCH v4.
The test cases remain and prove the problem. In particular
"8 - Clone path (ignorecase)" and
"Add a new file and clone path with new file (ignorecase)" fail with
Stefan Beller writes:
> diff --git a/builtin/index-pack.c b/builtin/index-pack.c
> index 3f10840..159ee36 100644
> --- a/builtin/index-pack.c
> +++ b/builtin/index-pack.c
> @@ -11,6 +11,7 @@
> #include "exec_cmd.h"
> #include "streaming.h"
> #include "thread-utils.h"
> +#include "run-command.h
All existing callers to this function use it to produce a text file
or an empty file, and a new callsite that mimick them must end their
payload with a LF. If they forget to do so, the resulting file will
end with an incomplete line.
Introduce WRITE_FILE_BINARY flag bit, which no existing callers
All of the callsites covered by this change call write_file() or
write_file_gently() to create a one-liner file. Drop the caller
supplied LF and let these callees to append it as necessary.
Signed-off-by: Junio C Hamano
---
builtin/init-db.c | 2 +-
builtin/worktree.c | 10 +-
daemon.
This is just to illustrate that we _could_ do this; I think it is
better to leave these places as they are. The primary thing we
wanted to do with the automatic addition of LF to an incomplete line
was to make it easier to write a caller that creates a single-liner
file. For callers that want to
There are many calls to write_file() that repeat the same pattern in
the implementation of the builtin version of "am". They all share
the same traits, i.e they
- produce a text file with a single string in it;
- have enough information to produce the entire contents of that
file;
- gener
"git am" was recently reimplemented in C. While the implementation
was done conservatively and followed the original logic in the
scripted version fairly faithfully, the state files it left in the
$GIT_DIR/rebase-apply directory were made slightly different by
mistake---they lacked the final LF, l
All callers except three passed 1 for the "fatal" parameter to ask
this function to die upon error, but to a casual reader of the code,
it was not all obvious what that 1 meant. Instead, split the
function into two based on a common write_file_v() that takes the
flag, introduce write_file_gently()
We forgot to terminate the payload given to write_file() with LF,
resulting in files that end with an incomplete line. Teach the
wrappers builtin/am uses to make sure it adds LF at the end as
necessary.
Signed-off-by: Junio C Hamano
---
builtin/am.c | 10 --
1 file changed, 8 insertions
Jeff King writes:
> On Mon, Aug 24, 2015 at 11:15:55AM -0700, Junio C Hamano wrote:
>
>> > This all looks good to me. The topics-in-flight compatibility stuff in
>> > patches 3 and 5 is neatly done. Usually I would just cheat and change
>> > the order of arguments to make the compiler notice such
Karthik Nayak writes:
> On Mon, Aug 24, 2015 at 10:57 PM, Junio C Hamano wrote:
>> Karthik Nayak writes:
>> ...
>>> + performed. If used with '--quote' everything in between %(align:..)
>>> + and %(end) is quoted.
> ...
> I might have misunderstood you, But based on the discussion held
SZEDER Gábor writes:
>> By the way, I usually prefer a fatter 'else' clause when everything
>> else is equal, i.e.
>>
>> if (!argc)
>> argv_array_push(&args, "HEAD"); /* default to HEAD */
>> else {
>> while (*argv) {
>> ...
>>
Junio C Hamano writes:
> All callers except for two ask this function to die upon error by
> passing fatal=1; turn the parameter to a more generic "unsigned flag"
> bag of bits, introduce an explicit WRITE_FILE_GENTLY bit and change
> these two callers to pass that bit.
There is a huge iffyness
On Mon, Aug 24, 2015 at 11:15:55AM -0700, Junio C Hamano wrote:
> > This all looks good to me. The topics-in-flight compatibility stuff in
> > patches 3 and 5 is neatly done. Usually I would just cheat and change
> > the order of arguments to make the compiler notice such problems, but
> > that's
Jeff King writes:
> On Mon, Aug 24, 2015 at 10:09:41AM -0700, Junio C Hamano wrote:
>
>> So here is an solution based on the "write_file() is primarily to
>> produce text, so it should be able to correct the incomplete line
>> at the end" approach.
>
> This all looks good to me. The topics-in-fli
On Mon, Aug 24, 2015 at 11:01 PM, Junio C Hamano wrote:
> Karthik Nayak writes:
>
test_expect_success 'git branch shows badly named ref' '
cp .git/refs/heads/master .git/refs/heads/broken...ref &&
test_when_finished "rm -f .git/refs/heads/broken...ref" &&
-
On Mon, Aug 24, 2015 at 10:57 PM, Junio C Hamano wrote:
> Karthik Nayak writes:
>
>> Interdiff:
>>
>> diff --git a/Documentation/git-for-each-ref.txt
>> b/Documentation/git-for-each-ref.txt
>> index 1997657..06d468e 100644
>> --- a/Documentation/git-for-each-ref.txt
>> +++ b/Documentation/git-fo
Michael Rappazzo writes:
> +static int print_worktree_details(const char *path, const char *git_dir,
> void *cb_data)
> +{
> + struct strbuf head_file = STRBUF_INIT;
> + struct strbuf head_ref = STRBUF_INIT;
> + struct stat st;
> + struct list_opts *opts = cb_data;
> + const
On P , 2015-08-24 at 09:51 -0700, Stefan Beller wrote:
> IIUC, the second command will lookup the submodules in $(pwd), but if
> they are not there they are skipped, so all of the existing submodules
> are cloned.
> Why do you need more submodules in the tmp clone than in
> $(pwd)/projectA would be
On Mon, Aug 24, 2015 at 10:09:41AM -0700, Junio C Hamano wrote:
> So here is an solution based on the "write_file() is primarily to
> produce text, so it should be able to correct the incomplete line
> at the end" approach.
This all looks good to me. The topics-in-flight compatibility stuff in
pa
Karthik Nayak writes:
>>> test_expect_success 'git branch shows badly named ref' '
>>> cp .git/refs/heads/master .git/refs/heads/broken...ref &&
>>> test_when_finished "rm -f .git/refs/heads/broken...ref" &&
>>> - git branch >output &&
>>> + git branch 2>output &&
>>>
Karthik Nayak writes:
> Interdiff:
>
> diff --git a/Documentation/git-for-each-ref.txt
> b/Documentation/git-for-each-ref.txt
> index 1997657..06d468e 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -133,7 +133,8 @@ align::
> `` is either l
On Sv, 2015-08-23 at 17:13 -0600, Cox, Michael wrote:
> You might want to take a look at how the Boost (boost.org) project
> uses submodules. They use submodules for each library. I know they
> use relative paths in their .gitmodules file to avoid the problem
> you're referring to regarding "git
There are many calls to write_file() that repeats the same pattern
in the implementation of the builtin version of "am", and they all
share the same traits, i.e they
- produce a text file with a single string in it;
- have enough information to produce the entire contents of that
file;
- g
All callers except for two ask this function to die upon error by
passing fatal=1; turn the parameter to a more generic "unsigned flag"
bag of bits, introduce an explicit WRITE_FILE_GENTLY bit and change
these two callers to pass that bit.
This is in preparation to add one more bit to this flag wo
Because the function adds necessary LF at the end of an incomplete
line for all callers that do not pass the WRITE_FILE_BINARY option,
and no caller of the function calls with that option, stop callers
to add LF at the end of the payload they pass to the function.
Also, change the callers that pas
All existing callers to this function use it to produce a text file
or an empty file, and a new callsite that mimick them must end their
payload with a LF. If they forget to do so, the resulting file will
end with an incomplete line.
Introduce WRITE_FILE_BINARY flag bit, which no existing callers
So here is an solution based on the "write_file() is primarily to
produce text, so it should be able to correct the incomplete line
at the end" approach.
The first one is Peff's idea to consolidate callers in "am", in a
more concrete form.
The second is the fix to $gmane/276238.
The remainder is
We forgot to terminate the payload given to write_file() with LF,
resulting in files that ends with an incomplete line.
Signed-off-by: Junio C Hamano
---
builtin/am.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/am.c b/builtin/am.c
index 4d34dc5..3423aa3 100644
On Sun, Aug 23, 2015 at 7:11 AM, Jānis Rukšāns wrote:
> On Pk, 2015-08-21 at 17:07 -0700, Stefan Beller wrote:
>> On Fri, Aug 21, 2015 at 3:47 PM, Jānis Rukšāns
>> wrote:
>> >
>> > A major drawback of submodules in my opinion is the
>> > inability to make a full clone from an existing one withou
'git describe --contains' doesn't default to HEAD when no commit is
given, and it doesn't produce any output, not even an error:
~/src/git ((v2.5.0))$ ./git describe --contains
~/src/git ((v2.5.0))$ ./git describe --contains HEAD
v2.5.0^0
Unlike other 'git describe' options, the '--contains
Quoting Junio C Hamano :
@@ -443,10 +443,13 @@ int cmd_describe(int argc, const char **argv,
const char *prefix)
if (pattern)
argv_array_pushf(&args, "--refs=refs/tags/%s",
pattern);
}
- while (*argv) {
-
I use git (2.2.1) on OS X (10.9.5) and recently my repo got into a bad
state. I think this involves a mis-handling of case-insensitive file
systems.
This reproduces the problem:
> git init
Initialized empty Git repository in /Users/aarond_local/code/git-test/.git/
> git commit --allo
On Mon, Aug 24, 2015 at 8:46 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> On Mon, Aug 24, 2015 at 1:30 AM, Matthieu Moy
>> wrote:
>>> Karthik Nayak writes:
>>>
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 1997657..06d468e 100
On Mon, Aug 24, 2015 at 8:44 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> On Mon, Aug 24, 2015 at 1:26 AM, Matthieu Moy
>> wrote:
>>> Karthik Nayak writes:
>>>
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -13,7 +13,8 @@ SYNOPSIS
[ | ]
>>>
Karthik Nayak writes:
> On Mon, Aug 24, 2015 at 1:30 AM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> diff --git a/Documentation/git-for-each-ref.txt
>>> b/Documentation/git-for-each-ref.txt
>>> index 1997657..06d468e 100644
>>> --- a/Documentation/git-for-each-ref.txt
>>> +++ b/Docum
Karthik Nayak writes:
> On Mon, Aug 24, 2015 at 1:26 AM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> --- a/Documentation/git-tag.txt
>>> +++ b/Documentation/git-tag.txt
>>> @@ -13,7 +13,8 @@ SYNOPSIS
>>>[ | ]
>>> 'git tag' -d ...
>>> 'git tag' [-n[]] -l [--contains ] [--poin
On Mon, Aug 24, 2015 at 1:30 AM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> diff --git a/Documentation/git-for-each-ref.txt
>> b/Documentation/git-for-each-ref.txt
>> index 1997657..06d468e 100644
>> --- a/Documentation/git-for-each-ref.txt
>> +++ b/Documentation/git-for-each-ref.txt
>> @@
On Mon, Aug 24, 2015 at 1:26 AM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> --- a/Documentation/git-tag.txt
>> +++ b/Documentation/git-tag.txt
>> @@ -13,7 +13,8 @@ SYNOPSIS
>>[ | ]
>> 'git tag' -d ...
>> 'git tag' [-n[]] -l [--contains ] [--points-at ]
>> - [--column[=] | --no
Hi Peff,
On 2015-08-24 16:43, Jeff King wrote:
> On Mon, Aug 24, 2015 at 12:23:52PM +0200, Johannes Schindelin wrote:
>
>> You're right. I think the best approach for now is to error out when
>> `--show-notes` is passed to rev-list. Do you agree?
>
> Yes (I imagine you didn't yet read my follow-
On Mon, Aug 24, 2015 at 12:23:52PM +0200, Johannes Schindelin wrote:
> You're right. I think the best approach for now is to error out when
> `--show-notes` is passed to rev-list. Do you agree?
Yes (I imagine you didn't yet read my follow-up patch when you wrote
this). :)
-Peff
--
To unsubscribe
On 24 August 2015 at 13:43, Lars Schneider wrote:
>>
>> https://github.com/luked99/quick-git-p4-case-folding-test
> As mentioned I realized that the problem occurs only if you use client specs.
> Can you take a look at this test case / run it?
> https://github.com/larsxschneider/git/blob/d3a191cb
>
>
>
>>
>> While I was working on the examples for this email reply I realized that the
>> problem is only present for paths given in a client-spec. I added a test
>> case to prove that. That means I don’t need to request *all* paths. I
>> *think* it is sufficient to request the paths ment
On 24 August 2015 at 10:51, Lars Schneider wrote:
>>
>> I'm still trying to fully understand what's going on here - can you
>> point out where I've got it wrong below please!
> Your welcome + sure :)
>
>
> While I was working on the examples for this email reply I realized that the
> problem i
Hi,
After several merges and rebases I finally got my branches and history
to reflect valid commits and proper history. Everything is pushed to
internal bare repo and the remotes seems OK.
When I clone the updated repository, all branches reflect the correct
updated trees and blobs.
The pr
Hi Peff,
On 2015-08-23 19:43, Jeff King wrote:
> On Sat, Aug 22, 2015 at 05:14:39PM +0200, Johannes Schindelin wrote:
>
>> The `format_display_notes()` function clearly assumes that the data
>> structure holding the notes has been initialized already, i.e. that the
>> `display_notes_trees` variab
> Lars - thanks for persisting with this!
>
> I'm still trying to fully understand what's going on here - can you
> point out where I've got it wrong below please!
Your welcome + sure :)
> The server is on Linux, and is case-sensitive. For whatever reason
> (probably people committing changes o
I tried building git on a fresh install of OS X Yosemite. Unfortunately it
errors out. I've attached the error below as well as cat the xml/catalog
file. Please let me know if there is anything else needed. Thanks in
advance.
Jeff
OS X Yosemite 10.10.5
Xcode 6.4 (6E35b)
git
commit ff86faf2fa02bc
On Sun, Aug 23, 2015 at 11:40:17AM -0700, Anish Athalye wrote:
> I'm having some issues with git remote helper behavior on Windows.
>
> According to the protocol
> (https://www.kernel.org/pub/software/scm/git/docs/gitremote-helpers.html),
> when doing things like listing capabilities, git expects
On 24 Aug 2015, at 08:33, Junio C Hamano wrote:
> Lars Schneider writes:
>
>>> - Have you checked "git log" on our history and notice how nobody
>>> says "PROBLEM:" and "SOLUTION:" in capital letters? Don't try to
>>> be original in the form; your contributions are already original
>>> and
70 matches
Mail list logo
