On Mon, Oct 17, 2016 at 10:30:28AM -0700, Junio C Hamano wrote:
> > It looks like I _did_ look into optimizing this into a single stat()
> > call in the thread at [1]. I completely forgot about that. I did find
> > there that naively using stat_validity() on a directory is racy, though
> > I wonde
On Tue, Oct 04, 2016 at 03:54:45PM -0700, Junio C Hamano wrote:
> "git diff" and its family of commands have "--ws-error-highlight"
> option to allow whitespace breakages on old and context lines
> painted in color.diff.whitespace color, instead of the usual "we
> paint breakages only on new lines
Hi Stefan,
On Mon, 17 Oct 2016, Stefan Beller wrote:
> On Mon, Oct 17, 2016 at 3:49 PM, Junio C Hamano wrote:
> > Stefan Beller writes:
> >
> >> +static void strip_url_ending(char *url, size_t *_len)
> >> +{
> >> + int check_url_stripping = 1;
> >> + size_t len = _len ? *_len : strlen(u
Hi Junio,
On Mon, 17 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> I'll mark it as "wait for follow-up fix" in whats-cooking.txt (on
> >> 'todo' branch) to remind myself not to merge it yet.
> >
> > May I request your guidance as to your preference how to proceed? ...
>
Hi Junio,
On Mon, 17 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > +/*
> > + * Reads a file that was presumably written by a shell script, i.e.
> > + * with an end-of-line marker that needs to be stripped.
> > + *
> > + * Returns 1 if the file was read, 0 if it could not b
Hi Junio,
On Mon, 17 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > This teaches the run_git_commit() function to take an argument that will
> > allow us to implement "todo" commands that need to amend the commit
> > messages ("fixup", "squash" and "reword").
>
> Likewise
Hi Junio,
On Mon, 17 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > The sequencer is our attempt to lib-ify cherry-pick. Yet it behaves
> > like a one-shot command when it reads its configuration: memory is
> > allocated and released only when the command exits.
> >
> > Thi
Hi Junio,
On Mon, 17 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > - for (i = 1; *p; i++) {
> > + for (i = 1; *p; i++, p = next_p) {
> > char *eol = strchrnul(p, '\n');
> > - commit = parse_insn_line(p, eol, opts);
> > - if (!commit)
> >
Hi Junio,
On Mon, 17 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > I would vote for:
> >
> > 4. We keep letting Git read in the *current* version of .gitattributes
> >*before* the merge, and apply those attributes while performing the
> >merge.
>
> Even though thi
I have 3 remotes registered in my clone:
origin, fork, drive
When I do:
$ git log --oneline --decorate --graph
I only want to see branches under:
refs/heads/*
refs/remotes/origin/*
I tried the following:
$ git log --oneline --decorate --graph --simplify-by-decoration
--remote=origin topic1..
> * st/verify-tag (2016-10-10) 7 commits
> - t/t7004-tag: Add --format specifier tests
> - t/t7030-verify-tag: Add --format specifier tests
> - builtin/tag: add --format argument for tag -v
> - builtin/verify-tag: add --format to verify-tag
> - tag: add format specifier to gpg_verify_tag
> -
The superficial aspect of this change is that git-daemon now allows paths
that start with a "~". Previously, if git-daemon was run with
"--base-path=/srv/git", it was impossible to get it to serve
"/srv/git/~foo/bar.git". An odd edge-case that was broken.
But from a source-code standpoint, the c
Hello!
I have a serious problem with git, After my provider had updated to a X86_64
architecture git crashes with various memory-related errors. This is happening
remote when pushing to the repository from my local machine as well as trying
it on a shell on the server itself.
This are the err
Stefan Beller writes:
> Currently a URL for the superproject ending in
>
> (A).../path/to/dir
> (B).../path/to/dir/
> (C).../path/to/dir/.
> (D).../path/to/dir/./.
> (E).../path/to/dir/.///.//.
>
> is treated the same in (A) and (B), but (C, D, E) are different.
You may know
Santiago Torres writes:
>> * st/verify-tag (2016-10-10) 7 commits
>> - t/t7004-tag: Add --format specifier tests
>> - t/t7030-verify-tag: Add --format specifier tests
>> - builtin/tag: add --format argument for tag -v
>> - builtin/verify-tag: add --format to verify-tag
>> - tag: add format s
Johannes Schindelin writes:
> On Mon, 17 Oct 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > This teaches the run_git_commit() function to take an argument that will
>> > allow us to implement "todo" commands that need to amend the commit
>> > messages ("fixup", "squash" an
Johannes Schindelin writes:
> In the meantime, I'd be happy to just add a comment that this function is
> intended for oneliners, but that it will also read multi-line files and
> only strip off the EOL marker from the last line.
>
> Would that work for you?
That would be ideal, I would think.
Stefan Beller writes:
>> @@ -29,6 +29,12 @@ struct trailer_item {
>> struct list_head list;
>> char *token;
>> char *value;
>> +};
>> +
>> +struct arg_item {
>> + struct list_head list;
>> + char *token;
>> + char *value;
>> struct conf_info conf;
Jonathan Tan writes:
>> * rs/c-auto-resets-attributes:
>> pretty: avoid adding reset for %C(auto) if output is empty
>>
>> And neither of the two colon containing line remotely resembles how
>> a typical RFC-822 header is formatted. So that may serve as a hint
>> to how we can tighten
Am 18.10.2016 um 17:17 schrieb Raffael Reichelt:
Hello!
I have a serious problem with git, After my provider had updated to a
X86_64 architecture git crashes with various memory-related errors.
This is happening remote when pushing to the repository from my local
machine as well as trying it on
Hello Renè!
file is returning
/usr/bin/git: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=ee62e538d6fe6673d3ba49f0e66bfec784cc32bc, stripped
and ulimit is:
core file size (blocks,
Robert Dailey writes:
> I have 3 remotes registered in my clone:
>
> origin, fork, drive
>
> When I do:
>
> $ git log --oneline --decorate --graph
>
> I only want to see branches under:
>
> refs/heads/*
> refs/remotes/origin/*
>
> I tried the following:
>
> $ git log --oneline --decorate --graph
Luke Shumaker writes:
> The superficial aspect of this change is that git-daemon now allows paths
> that start with a "~". Previously, if git-daemon was run with
> "--base-path=/srv/git", it was impossible to get it to serve
> "/srv/git/~foo/bar.git".
I am not sure I understand what you are say
Junio C Hamano writes:
> Stefan Beller writes:
>
>> +static void strip_url_ending(char *url, size_t *_len)
>> +{
>> +int check_url_stripping = 1;
>> +size_t len = _len ? *_len : strlen(url);
>> +
>> +while (check_url_stripping) {
>> +check_url_stripping = 0;
>> +
On Tue, Oct 18, 2016 at 10:15 AM, Junio C Hamano wrote:
>
> I also somehow find the "check-url-stripping" variable ugly.
>
> while (URL still has something that could be stripped) {
for(;;) {
here ? (this code would not need a variable, and
for wins over while:
$ git grep "while (1)" |wc
Johannes Schindelin writes:
> To the contrary. As far as I can see, when calling `git merge`, Git
> currently *does* read .gitattributes from the file, and if that fails,
> falls back to reading that file from the index.
Hmph.
Assuming that the merge always goes in the index order, I think you
Stefan Beller writes:
> for(;;) {
>
> here ? (this code would not need a variable, and
> for wins over while:
> $ git grep "while (1)" |wc -l
> 107
> $ git grep "for (;;)" |wc -l
> 128
> )
I dunno; the numbers tells me there is no strong preference by wide
margin either way.
I am not sure if th
The remote URL for the submodule can be specified relative
to the URL of the superproject in .gitmodules. A top-level
git://site.xz/toplevel.git can specify in its .gitmodules
[submodule "sub"]
url = ../submodule.git
path = sub
to say that git://site.xz/su
On Tue, 18 Oct 2016 13:08:45 -0400,
Junio C Hamano wrote:
>
> Luke Shumaker writes:
>
> > The superficial aspect of this change is that git-daemon now allows paths
> > that start with a "~". Previously, if git-daemon was run with
> > "--base-path=/srv/git", it was impossible to get it to serve
Hello git experts,
I have in the past attempted to integrate submodules into my primary
repository using the same directory name. However, this has always
caused headache when going to and from branches that take you between
when this integration occurred and when it didn't. It's a bit hard to
exp
28a4d94044 ("object name: introduce ':/' notation",
2007-02-24) started using its own bit from object->flags to mark
commits used while parsing the ":/token" extended SHA-1 syntax to
name a commit temporarily, and this was kept even when f7bff00314
("sha1_name.c: fix parsing of ":/token" syntax", 2
Stefan Beller writes:
> Some users may rely on this by always cloning with '/.' and having
> an additional '../' in the relative path for the submodule, and this
> patch breaks them. So why introduce this patch?
>
> The fix in c12922024 (submodule: ignore trailing slash on superproject
> URL, 201
Am 17.10.2016 um 21:32 schrieb Johannes Sixt:
> I think that we could reduce the confusion by converting all $PWD to
> $(pwd) in these test cases. I don't remember why I suggested to use $PWD
> for one of the arguments of the test cases (the second must be $(pwd)),
> but the most likely reason is o
> On 17 Oct 2016, at 15:28, Junio C Hamano wrote:
> ...
>
> * ls/filter-process (2016-10-17) 14 commits
> - contrib/long-running-filter: add long running filter example
> - convert: add filter..process option
> - convert: prepare filter..process option
> - convert: make apply_filter() adhere to
Lars Schneider writes:
>> On 17 Oct 2016, at 15:28, Junio C Hamano wrote:
>> ...
>>
>> * ls/filter-process (2016-10-17) 14 commits
>> - contrib/long-running-filter: add long running filter example
>> - convert: add filter..process option
>> - convert: prepare filter..process option
>> - convert
The remote URL for the submodule can be specified relative
to the URL of the superproject in .gitmodules. A top-level
git://site.xz/toplevel.git can specify in its .gitmodules
[submodule "sub"]
url = ../submodule.git
path = sub
to say that git://site.xz/su
Stefan Beller writes:
> The remote URL for the submodule can be specified relative
> ...
> v3:
> * fixed the coding style.
Ah, thanks. I had a squash queued on top but will replace with this
one.
On Tue, Oct 18, 2016 at 12:35 PM, Robert Dailey
wrote:
> Hello git experts,
>
> I have in the past attempted to integrate submodules into my primary
> repository using the same directory name. However, this has always
> caused headache when going to and from branches that take you between
> when t
Junio C Hamano writes:
> Stefan Beller writes:
>
>> The remote URL for the submodule can be specified relative
>> ...
>> v3:
>> * fixed the coding style.
>
> Ah, thanks. I had a squash queued on top but will replace with this
> one.
Heh, I guess I shouldn't have responded before seeing what t
On Tue, Oct 18, 2016 at 2:19 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Stefan Beller writes:
>>
>>> The remote URL for the submodule can be specified relative
>>> ...
>>> v3:
>>> * fixed the coding style.
>>
>> Ah, thanks. I had a squash queued on top but will replace with this
>
On Fri, Oct 14, 2016 at 8:37 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> *1* Would we need a wrapping struct around the array of results?
>
> By the way, I do see a merit on the "check" side (tl;dr: but I do
> not think "result" needs it, hence I do not see the need for the
> "ugly" v
On Tue, Oct 18, 2016 at 4:52 PM, Stefan Beller wrote:
>
> >
> > By the way, I do see a merit on the "check" side (tl;dr: but I do
> > not think "result" needs it, hence I do not see the need for the
> > "ugly" variants).
>
> So we'd rather go with const char **result instead of our own new struct
On Tue, Oct 18, 2016 at 5:06 PM, Junio C Hamano wrote:
> On Tue, Oct 18, 2016 at 4:52 PM, Stefan Beller wrote:
>>
>> >
>> > By the way, I do see a merit on the "check" side (tl;dr: but I do
>> > not think "result" needs it, hence I do not see the need for the
>> > "ugly" variants).
>>
>> So we'd
Stefan Beller writes:
> I am not sure if I see the upside on wrapping a single value except for
> its future proofness,
I do not see anything other than future-proofing, either. If we
need to touch all the code that uses the attributes to update the
API, I'd prefer to avoid having to do that ag
Stefan Beller writes:
> The underlying issue is two fold:
>
> * in t3600 we'd need
> diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
> index d046d98..545d32f 100755
> --- a/t/t3600-rm.sh
> +++ b/t/t3600-rm.sh
> @@ -616,7 +616,7 @@ test_expect_success 'setup subsubmodule' '
> git submodule upda
On Tue, Oct 18, 2016 at 5:56 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> The underlying issue is two fold:
>>
>> * in t3600 we'd need
>> diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
>> index d046d98..545d32f 100755
>> --- a/t/t3600-rm.sh
>> +++ b/t/t3600-rm.sh
>> @@ -616,7 +616,7 @@ test
Johannes Schindelin writes:
>> > To remedy that, we now take custody of the option values in question,
>> > requiring those values to be malloc()ed or strdup()ed
>>
>> That is the approach this patch takes, so "eventually release" in
>> the title is no longer accurate, I would think.
>
> To the
Stefan Beller writes:
>> I am not sure. Certainly we would want to make sure that the normal
>> case (i.e. no funny trailing junk) to work correctly, but we do want
>> to protect the fix from future breakage as well, no?
>
> Exactly. So not intermediate "root" that we clone from, but adapting th
This is a continuation of
http://public-inbox.org/git/xmqqmvi2sj8f@gitster.mtv.corp.google.com
In a workflow where topic branches are first merged to the 'next'
integration branch to be tested before getting merged down to the
'master' integration branch to be consumed by the end users, m
The get_merge_bases_many*() family of functions first call
merge_bases_many() to find all possible merge bases between a single
commit "one" and a set of other commits "twos[]". Because this
typically involves traversing the commit graph, which uses the
object flags on the commits involved, the fu
"git merge-base" names its internal workhorse helper function
"get_merge_bases_many_0()", which takes one "can we get away without
clearing the object->flags bits because we know we are the last
caller?" parameter. Make the parameter into a flags word to make it
extensible and rename it to get_mer
The merge-base computation is performed in two steps. First,
paint_down_to_common() traverses the history to find all possible
merge bases (and more), and then remove_redundant() checks the
result and culls the ones that can be reached from another commit
in the result.
The latter received an arr
28a4d94044 ("object name: introduce ':/' notation",
2007-02-24) started using its own bit from object->flags to mark
commits used while parsing the ":/token" extended SHA-1 syntax to
name a commit temporarily, and this was kept even when f7bff00314
("sha1_name.c: fix parsing of ":/token" syntax", 2
A new option "--fp-only" limits the output to the merge bases that
are on the first-parent chain from the branches being merged.
Signed-off-by: Junio C Hamano
---
Documentation/git-merge-base.txt | 8 +++-
builtin/merge-base.c | 10 +++---
2 files changed, 14 insertions(+),
Teach "git merge" a new option "--fp-base-only" that tells it to
consider only merge bases that are on the first-parent chain.
This speeds up back-merges needed in the topic branch workflow. The
merge of 'master' back into 'next' used as an example in the RFD
article , i.e.
git checkout 4868
In a workflow where topic branches are first merged to the 'next'
integration branch to be tested before getting merged down to the
'master' integration branch to be consumed by the end users, merging
the 'master' branch back to the 'next' happens after topics graduate
to 'master' and release notes
56 matches
Mail list logo