Hi,
On Fri, May 22, 2015 at 4:38 PM, Stephen Kelly wrote:
> Hello,
>
> I have an 'integration repo' which contains other git repos as submodules.
>
> One of the submodules is to be split in two to extract a library.
>
> A common way of doing that is to use git-filter-branch. A disadvantage
> of t
Le 23/05/2015 00:06, Jeff King a écrit :
> OK, this is weird. When I tried to reproduce, I couldn't. But I had
> typed in the date string myself while reading your email in another
> window. And though I was sure that I had typed it correctly, just to be
> double-plus-sure I copied and pasted your
On Sat, May 23, 2015 at 2:00 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>>> diff --git a/Documentation/git-send-email.txt
>>> b/Documentation/git-send-email.txt
>>> index 804554609def..97387fd27a8d 100644
>>> --- a/Documentation/git-send-email.txt
>>> +++ b/Documentation/git-send-email
Junio C Hamano writes:
> And I do not think an array of things that are operated on should
> not be named "ref_filter_item".
Is the double-negation intended? It seems contradictory with:
> Surely, the latter "set of operations to be applied" may currently
> be only filtering, but who says it ha
On Sat, May 23, 2015 at 2:07 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> A small thing I noticed in the test (and this patch is not adding a
>> new "breakage"---there are a few existing instances) is the use of
>> "~/"; it should be spelled "$HOME/" instead for portability (not in
>>
Per Junio's email, with core.quotepath=false, there are no differences with
sorting in either ls-files or the tree named in the GIT_TRACE_2 output:
$ git config --local core.quotepath false
$ git ls-tree --name-only -r 74332b7d653cde7ba3b999cc7b0adcfd9d924440 > ls-tree
$ LANG=C LC_ALL=C sort ls
Please Acknowledge My Proposal!!
My name is Mr. Juan Martin Domingo a lawyer resident in Spain. I am
writing to let you know I have some FUNDS I want to transfer and am
seeking if you can be a beneficiary...Do not hesitate to Contact me for
more information if interested: gva.abogad...@aim.com)
On 22/05/15 23:14, Junio C Hamano wrote:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
ry_matches(): inline function
+ is_> The fourth batch of topics have been merged to 'master'.
Junio C Hamano writes:
> A small thing I noticed in the test (and this patch is not adding a
> new "breakage"---there are a few existing instances) is the use of
> "~/"; it should be spelled "$HOME/" instead for portability (not in
> POSIX, even though bash, dash and ksh all seem to understand it
Junio C Hamano writes:
>> diff --git a/Documentation/git-send-email.txt
>> b/Documentation/git-send-email.txt
>> index 804554609def..97387fd27a8d 100644
>> --- a/Documentation/git-send-email.txt
>> +++ b/Documentation/git-send-email.txt
>> @@ -383,7 +383,42 @@ sendemail.aliasesFile::
>>
>> se
But it also contains struct ref_filter_item **items, which as I
understand it contains a list of refs (with name, sha1 & such).
That's the part I do not find natural: the same structure contains both
the list of refs and the way it should be filtered.
Re-reading the patch, I seem to understand
Allen Hubbe writes:
> Note that this only adds support for a limited subset of the sendmail
> format. The format is is as follows.
>
> : [, ...]
>
> Aliases are specified one per line, and must start on the first column of the
> line. Blank lines are ignored. If the first non whitespace
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> I think both of you are wrong ;-)
>>
>> The thing is, what you are seeing does not have much to do with
>> GIT_DIR. It is "what Git does when it finds a directory inside the
>> working tree of a project". And ".git" is the only special thing
Matthieu Moy writes:
> But I think this could be clearer in the code (and/or comment + commit
> message). Perhaps stg like:
>
> struct ref_filter_data /* Probably not the best name */ {
> struct ref_list list;
> struct ref_filter filter;
> };
>
> struct ref_list {
> int coun
"McHenry, Matt" writes:
> Yes, that does turn up some interesting stuff. It looks
> like the repository contains some paths with non-ASCII
> characters, for example this one has some en-dashes (U+2013)
> in its name:
Then the recipe in the message you are responding to s
Christian Couder writes:
>> struct ref_list {
>> int count, alloc;
>> struct ref_filter_item **items;
>> const char **name_patterns;
>> };
>
> Matthieu, I think you forgot to remove "const char **name_patterns;"
> in the above struct, as you put it in the "ref_filter" stru
Junio C Hamano writes:
> I think both of you are wrong ;-)
>
> The thing is, what you are seeing does not have much to do with
> GIT_DIR. It is "what Git does when it finds a directory inside the
> working tree of a project". And ".git" is the only special thing in
> that context.
In short, I
Mike Hommey writes:
> On Sat, May 23, 2015 at 09:22:56AM +0700, Duy Nguyen wrote:
>> On Fri, May 22, 2015 at 07:03:48PM -0700, Junio C Hamano wrote:
>> > As far as I know, GIT_DIR was prepared as a mechanism to point at
>> > another .git directory that does not live inside the working tree, not
>
On Sat, May 23, 2015 at 4:42 PM, Matthieu Moy
wrote:
> karthik nayak writes:
>
>>> At some point, I'd expect something like
>>>
>>>filtered_list_of_refs = filer(full_list_of_refs, description_of_filter);
>>>
>>> That would remove some refs from full_list_of_refs according to
>>> description_o
karthik nayak writes:
>> At some point, I'd expect something like
>>
>>filtered_list_of_refs = filer(full_list_of_refs, description_of_filter);
>>
>> That would remove some refs from full_list_of_refs according to
>> description_of_filter.
>>
>> (totally invented code, only to show the idea)
Stefan Beller writes:
> Ok, I am trying it out now, all I have left is
>
> Register your email address
> (stefanbel...@googlemail.com)
> with submitGit's Amazon SES
> account in order for it to send
> emails from you.
>
> So first of all:
> Where do I find the Amazon SES accou
Note that this only adds support for a limited subset of the sendmail
format. The format is is as follows.
: [, ...]
Aliases are specified one per line, and must start on the first column of the
line. Blank lines are ignored. If the first non whitespace character
on a line is a '#' sym
On Sat, May 23, 2015 at 11:41 AM, Thorsten von Eicken
wrote:
> On 5/22/2015 7:22 PM, Duy Nguyen wrote:
>> On Fri, May 22, 2015 at 07:03:48PM -0700, Junio C Hamano wrote:
>>> As far as I know, GIT_DIR was prepared as a mechanism to point at
>>> another .git directory that does not live inside the w
On Sat, May 23, 2015 at 12:39 PM, Mike Hommey wrote:
> On Sat, May 23, 2015 at 09:22:56AM +0700, Duy Nguyen wrote:
>> --- a/Documentation/git.txt
>> +++ b/Documentation/git.txt
>> @@ -691,6 +691,9 @@ Git so take care if using Cogito etc.
>> specifies a path to use instead of the default `.gi
On 05/23/2015 01:51 AM, Jeff King wrote:
> The stat_validity code was originally written to avoid
> re-reading the packed-refs file when it has not changed. It
> makes sure that the file continues to match S_ISREG() when
> we check it.
>
> However, we can use the same concept on a directory to see
Hi Junio,
On 2015-05-22 22:04, Junio C Hamano wrote:
> On Fri, May 22, 2015 at 12:59 PM, Johannes Schindelin
> wrote:
>>
>> On 2015-05-22 21:23, Stefan Beller wrote:
>>>
>>> So first of all:
>>> Where do I find the Amazon SES account for submitGit, to register
>>> my email with?
>>>
>>> Also can
Hi Roberto,
On 2015-05-22 23:28, Roberto Tyley wrote:
> I'm currently on a cycling holiday on an island off the west coast of
> Scotland, **without a laptop**, so updates to submitGit (based on the
> excellent feedback I've been receiving) will probably start mid-next week.
Ah, I am jealous. Enj
Hi Philip,
On 2015-05-22 23:35, Philip Oakley wrote:
> Do I read you right.. That it's necessary to create a PR on git/git
> before submitGit can be used.
Yep.
> And that if I already have a PR which goes back to an alternate fork
> (e.g. my example), then I must move or duplicate that PR onto
28 matches
Mail list logo