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
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
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
"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
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
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",
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,
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
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
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
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
>> +++
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' '
>
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
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
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
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
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.
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
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
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.
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
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
>> -
> 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
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
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
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",
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
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
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
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.
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
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
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) {
>> +
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
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
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,
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
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
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;
>>
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
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
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
>>
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
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
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
> * 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
> -
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
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
> >
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);
> >
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
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"
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
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
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;
> >> +
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
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
Good Day,
Financing shouldn't be a mystery for you, contact us for help today. Easy
Funding Service is here to help you solve out all your outstanding debts and be
free for good..We have come to conclusion that its high time a person can buy
his own house, good cars, established good business,
57 matches
Mail list logo