Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Junio C Hamano]

Linus Torvalds  writes:

> It's literally just the fact that "git merge" does it with no extra
> flags or checks. I'd like people to have to be aware of what they are
> doing when they merge two different projects, not do it by mistake.
>
> So making it conditional on a flag like "--no-common-root" is what I'd look 
> for.

I think I said essentially the same thing in a separate message; I
am not sure "--no-common-root" is a good name, but I think it is
better to be more explicit than tying this to a strategy.

> I don't think the original "resolve" did it, for example. You can't do
> a three-way merge without a base.

Yes, and that continues to this day:

# Give up if we are given two or more remotes -- not handling octopus.
case "$remotes" in
?*' '?*)
exit 2 ;;
esac

# Give up if this is a baseless merge.
if test '' = "$bases"
then
exit 2
fi

This is a tangent but I wonder if we should say why we refuse to
the standard error before calling these two "exit"s.

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Junio C Hamano]

Linus Torvalds  writes:

> It's literally just the fact that "git merge" does it with no extra
> flags or checks. I'd like people to have to be aware of what they are
> doing when they merge two different projects, not do it by mistake.
>
> So making it conditional on a flag like "--no-common-root" is what I'd look 
> for.

I think I said essentially the same thing in a separate message; I
am not sure "--no-common-root" is a good name, but I think it is
better to be more explicit than tying this to a strategy.

> I don't think the original "resolve" did it, for example. You can't do
> a three-way merge without a base.

Yes, and that continues to this day:

# Give up if we are given two or more remotes -- not handling octopus.
case "$remotes" in
?*' '?*)
exit 2 ;;
esac

# Give up if this is a baseless merge.
if test '' = "$bases"
then
exit 2
fi

This is a tangent but I wonder if we should say why we refuse to
the standard error before calling these two "exit"s.

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Junio C Hamano]

Johannes Schindelin  writes:

> Hi Linus,
>
> On Fri, 18 Mar 2016, Linus Torvalds wrote:
>
>> I thought git didn't merge two branches that have no common base by
>> default, but it seems it will happily do so.
>
> What happened to "The coolest merge EVER!"?
>
>   http://thread.gmane.org/gmane.comp.version-control.git/5126/
>
> Ciao,
> Dscho

An obvious response to the above, "What about it?", is something you
would have already anticipated when you wrote the above, and I wish
I saw that in the message I am responding to, but I didn't, so here
is my attempt ;-)

The old article shows two interesting things.  One is that there are
cases where it makes perfect sense to bind two unrelated histories
when the two roots are totally unrelated.

I am not Linus, but I think the proposal is to make it harder to do
this unusual merge by mistake, while keeping it possible to do so
when the user really wants to.  And the "deliberately whitespace
damaged patch" in the message you are responding to was primarily to
point out where the "making it harder" logic should go by showing
how to make it impossible, leaving it to readers to adjust it to
"harder but still possible".

Now, the second thing that the old article you pointed shows is that
it is possible to create such a merge without using "git merge" even
though it is more involved and takes conscious effort by the user.
In that sense, you could argue that, with the "make it impossible"
change in Linus's message to "git merge", there is no more change
needed (I do not know if that is what you meant to imply, though).

I think it makes sense to teach "git merge" to error out like Linus
did unless the user explicitly says "I know what I am doing" with an
explicit option (e.g. --force or --merge-unrelated-histories).

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Junio C Hamano]

Johannes Schindelin  writes:

> Hi Linus,
>
> On Fri, 18 Mar 2016, Linus Torvalds wrote:
>
>> I thought git didn't merge two branches that have no common base by
>> default, but it seems it will happily do so.
>
> What happened to "The coolest merge EVER!"?
>
>   http://thread.gmane.org/gmane.comp.version-control.git/5126/
>
> Ciao,
> Dscho

An obvious response to the above, "What about it?", is something you
would have already anticipated when you wrote the above, and I wish
I saw that in the message I am responding to, but I didn't, so here
is my attempt ;-)

The old article shows two interesting things.  One is that there are
cases where it makes perfect sense to bind two unrelated histories
when the two roots are totally unrelated.

I am not Linus, but I think the proposal is to make it harder to do
this unusual merge by mistake, while keeping it possible to do so
when the user really wants to.  And the "deliberately whitespace
damaged patch" in the message you are responding to was primarily to
point out where the "making it harder" logic should go by showing
how to make it impossible, leaving it to readers to adjust it to
"harder but still possible".

Now, the second thing that the old article you pointed shows is that
it is possible to create such a merge without using "git merge" even
though it is more involved and takes conscious effort by the user.
In that sense, you could argue that, with the "make it impossible"
change in Linus's message to "git merge", there is no more change
needed (I do not know if that is what you meant to imply, though).

I think it makes sense to teach "git merge" to error out like Linus
did unless the user explicitly says "I know what I am doing" with an
explicit option (e.g. --force or --merge-unrelated-histories).

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Junio C Hamano]

Linus Torvalds  writes:

> The code in the recursive merge that allows this to happen is this:
> ...
> And I do think that's right, and I think it's clever, and it goes back to 
> 2006:
>
>   934d9a24078e merge-recur: if there is no common ancestor, fake empty one
>
> but I think there should be an option there.

Oh, I think everybody understands that and agrees by now.

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Junio C Hamano]

Linus Torvalds  writes:

> The code in the recursive merge that allows this to happen is this:
> ...
> And I do think that's right, and I think it's clever, and it goes back to 
> 2006:
>
>   934d9a24078e merge-recur: if there is no common ancestor, fake empty one
>
> but I think there should be an option there.

Oh, I think everybody understands that and agrees by now.

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Laxman Dewangan]

On Friday 18 March 2016 02:31 PM, Linus Walleij wrote:

On Fri, Mar 18, 2016 at 7:07 AM, Linus Torvalds
 wrote:

On Thu, Mar 17, 2016 at 1:59 AM, Linus Walleij  wrote:

The end result should be clean but the history is a bit messy.

Gaah. I took the tree, but I didn't realize just *how* messy it was. I
doubt you did either.

Certainly not. I wasn't even aware that things could be screwed up so
much and still look OK on the surface. I'll certainly be more cautious
about pulling branches in the future.



Apologizing for the trouble created by me. I understand from other mail 
that It seems I have misguided by the step mentioned in github document 
and so created the issue. I will not use github as mentioned by Linus T.

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Laxman Dewangan]

On Friday 18 March 2016 02:31 PM, Linus Walleij wrote:

On Fri, Mar 18, 2016 at 7:07 AM, Linus Torvalds
 wrote:

On Thu, Mar 17, 2016 at 1:59 AM, Linus Walleij  wrote:

The end result should be clean but the history is a bit messy.

Gaah. I took the tree, but I didn't realize just *how* messy it was. I
doubt you did either.

Certainly not. I wasn't even aware that things could be screwed up so
much and still look OK on the surface. I'll certainly be more cautious
about pulling branches in the future.



Apologizing for the trouble created by me. I understand from other mail 
that It seems I have misguided by the step mentioned in github document 
and so created the issue. I will not use github as mentioned by Linus T.

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Linus Walleij]

On Fri, Mar 18, 2016 at 7:07 AM, Linus Torvalds
 wrote:
> On Thu, Mar 17, 2016 at 1:59 AM, Linus Walleij  
> wrote:
>>
>> The end result should be clean but the history is a bit messy.
>
> Gaah. I took the tree, but I didn't realize just *how* messy it was. I
> doubt you did either.

Certainly not. I wasn't even aware that things could be screwed up so
much and still look OK on the surface. I'll certainly be more cautious
about pulling branches in the future.

Yours,
Linus Walleij

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Linus Walleij]

On Fri, Mar 18, 2016 at 7:07 AM, Linus Torvalds
 wrote:
> On Thu, Mar 17, 2016 at 1:59 AM, Linus Walleij  
> wrote:
>>
>> The end result should be clean but the history is a bit messy.
>
> Gaah. I took the tree, but I didn't realize just *how* messy it was. I
> doubt you did either.

Certainly not. I wasn't even aware that things could be screwed up so
much and still look OK on the surface. I'll certainly be more cautious
about pulling branches in the future.

Yours,
Linus Walleij

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Laxman Dewangan]

On Friday 18 March 2016 11:37 AM, Linus Torvalds wrote:

On Thu, Mar 17, 2016 at 1:59 AM, Linus Walleij  wrote:

NOTE: tree was a bit dirty and I realized it too late: Laxmans
devm_gpiochip_add() branch was based on my for-next branch rather
than my devel branch, making some commits appear twice and
a file named README.md "Share upstreaming patches" appear and
then get reverted out by me.

The end result should be clean but the history is a bit messy.

Gaah. I took the tree, but I didn't realize just *how* messy it was. I
doubt you did either.

Dammit, had I realized just how screwed up that branch was, I'd have
made you re-do it.

Because that branch is crap.

And the real reason is is crap isn't a "README.md" file that comes and
goes. The real reason it is crap is that it has a new root commit, and
Laxman has done something TOTALLY INSANE.

I'm not even sure what insane tool was used to do this, but there's a
new root commit at

   a101ad945113be3d7f283a181810d76897f0a0d6

that has no parenthood, and that is only used for a completely bogus
merge (merge commit e5451c8f8330e03ad3cfa16048b4daf961af434f). That's
where the README.md file comes from.

Git does support the notion of having multiple roots, and it is a
useful thing to have when you merge two different projects with
separate history. In fact, git itself has that, for 'gitk' that was
merged into the main git history.

We have that in the kernel for the initial btrfs merge too, actually.
btrfs started out outside the full kernel, and had a root of its own
with its own development history, and then it was merged into the
kernel tree under fs/btrfs.

But this is *not* that. That commit
a101ad945113be3d7f283a181810d76897f0a0d6 is just pure garbage, and the
merge that introduces it is pure shit.

Dammit, I noticed too late, so now it's out there. How the hell did
that even happen? Why did Laxman do that insane merge? Why did it get
pulled back?

You actually have to *work* at making shit like this, so I wonder what
workflow you guys had to make that bad merge. It's easy enough to do
with git manually, but it's hard to do by _mistake_. Is there some
broken tool that Laxman uses?

I'm very annoyed, because while the multi-root situation can be
useful, it can also be confusing as hell. It can cause bisection
problems, and it can just cause people to go "WTF?"

I need to know what happened and make sure it doesn't happen again. If
this is some intentional workflow by nvidia, it needs to stop *now*.
It's broken shit.




For creating the repo and branch, I just followed the instruction from wiki
https://help.github.com/articles/create-a-repo/

and for pushing changes
https://help.github.com/articles/fork-a-repo/

I jut use git (git version 2.1.4) for pushing the changes in github repo.

There is no other tools used.

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Laxman Dewangan]

On Friday 18 March 2016 11:37 AM, Linus Torvalds wrote:

On Thu, Mar 17, 2016 at 1:59 AM, Linus Walleij  wrote:

NOTE: tree was a bit dirty and I realized it too late: Laxmans
devm_gpiochip_add() branch was based on my for-next branch rather
than my devel branch, making some commits appear twice and
a file named README.md "Share upstreaming patches" appear and
then get reverted out by me.

The end result should be clean but the history is a bit messy.

Gaah. I took the tree, but I didn't realize just *how* messy it was. I
doubt you did either.

Dammit, had I realized just how screwed up that branch was, I'd have
made you re-do it.

Because that branch is crap.

And the real reason is is crap isn't a "README.md" file that comes and
goes. The real reason it is crap is that it has a new root commit, and
Laxman has done something TOTALLY INSANE.

I'm not even sure what insane tool was used to do this, but there's a
new root commit at

   a101ad945113be3d7f283a181810d76897f0a0d6

that has no parenthood, and that is only used for a completely bogus
merge (merge commit e5451c8f8330e03ad3cfa16048b4daf961af434f). That's
where the README.md file comes from.

Git does support the notion of having multiple roots, and it is a
useful thing to have when you merge two different projects with
separate history. In fact, git itself has that, for 'gitk' that was
merged into the main git history.

We have that in the kernel for the initial btrfs merge too, actually.
btrfs started out outside the full kernel, and had a root of its own
with its own development history, and then it was merged into the
kernel tree under fs/btrfs.

But this is *not* that. That commit
a101ad945113be3d7f283a181810d76897f0a0d6 is just pure garbage, and the
merge that introduces it is pure shit.

Dammit, I noticed too late, so now it's out there. How the hell did
that even happen? Why did Laxman do that insane merge? Why did it get
pulled back?

You actually have to *work* at making shit like this, so I wonder what
workflow you guys had to make that bad merge. It's easy enough to do
with git manually, but it's hard to do by _mistake_. Is there some
broken tool that Laxman uses?

I'm very annoyed, because while the multi-root situation can be
useful, it can also be confusing as hell. It can cause bisection
problems, and it can just cause people to go "WTF?"

I need to know what happened and make sure it doesn't happen again. If
this is some intentional workflow by nvidia, it needs to stop *now*.
It's broken shit.




For creating the repo and branch, I just followed the instruction from wiki
https://help.github.com/articles/create-a-repo/

and for pushing changes
https://help.github.com/articles/fork-a-repo/

I jut use git (git version 2.1.4) for pushing the changes in github repo.

There is no other tools used.

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Linus Torvalds]

On Fri, Mar 18, 2016 at 7:32 AM, Johannes Schindelin
 wrote:
>
> On Fri, 18 Mar 2016, Linus Torvalds wrote:
>
>> I thought git didn't merge two branches that have no common base by
>> default, but it seems it will happily do so.
>
> What happened to "The coolest merge EVER!"?
>
> http://thread.gmane.org/gmane.comp.version-control.git/5126/

I'm not complaining about multi-root capability in general - it's
still cool. In the kernel, we have aef8755711a2 ("Merge Btrfs into
fs/btrfs") that does something slightly similar.

It's literally just the fact that "git merge" does it with no extra
flags or checks. I'd like people to have to be aware of what they are
doing when they merge two different projects, not do it by mistake.

So making it conditional on a flag like "--no-common-root" is what I'd look for.

Or just make it about the merge stategy. For example, "subtree" makes
sense exactly for merging one project into a subdirectory of another.
But the default merge shouldn't do it.

I don't think the original "resolve" did it, for example. You can't do
a three-way merge without a base.

Note how that above "coolest merge" definitely wasn't done by just
"git merge gitk". I had to play around with the git internals. Now, it
shouldn't be _that_ hard, but at the same time it really shouldn't be
as easy as "I didn't know, so I merged two independent projects".

   Linus

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Linus Torvalds]

On Fri, Mar 18, 2016 at 7:32 AM, Johannes Schindelin
 wrote:
>
> On Fri, 18 Mar 2016, Linus Torvalds wrote:
>
>> I thought git didn't merge two branches that have no common base by
>> default, but it seems it will happily do so.
>
> What happened to "The coolest merge EVER!"?
>
> http://thread.gmane.org/gmane.comp.version-control.git/5126/

I'm not complaining about multi-root capability in general - it's
still cool. In the kernel, we have aef8755711a2 ("Merge Btrfs into
fs/btrfs") that does something slightly similar.

It's literally just the fact that "git merge" does it with no extra
flags or checks. I'd like people to have to be aware of what they are
doing when they merge two different projects, not do it by mistake.

So making it conditional on a flag like "--no-common-root" is what I'd look for.

Or just make it about the merge stategy. For example, "subtree" makes
sense exactly for merging one project into a subdirectory of another.
But the default merge shouldn't do it.

I don't think the original "resolve" did it, for example. You can't do
a three-way merge without a base.

Note how that above "coolest merge" definitely wasn't done by just
"git merge gitk". I had to play around with the git internals. Now, it
shouldn't be _that_ hard, but at the same time it really shouldn't be
as easy as "I didn't know, so I merged two independent projects".

   Linus

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Linus Torvalds]

On Thu, Mar 17, 2016 at 11:07 PM, Laxman Dewangan  wrote:
>
> For creating the repo and branch, I just followed the instruction from wiki
> https://help.github.com/articles/create-a-repo/

So you shouldn't have created a new repo at all, you should just have
cloned an existing one (that gets you a repo, of course).

You basically ended up starting a new project.

But I guess the github connection explains why there was a crazy
README.md file there, and I can see why that documentation would make
you think it's the right thing to do.

Oh well.

Just a "git init" wouldn't have done that kind of damage, the github
documentation is just misleading in this respect.

We may have to make it really really really clear for the kernel that
people should not use github in any way except purely for hosting..

> I jut use git (git version 2.1.4) for pushing the changes in github repo.
>
> There is no other tools used.

I thought git didn't merge two branches that have no common base by
default, but it seems it will happily do so.

So once you made the mistake of starting a new project, git merge
ended up "helpfully" allowing you to merge the remote tracking branch
into that new project, and we ended up with a silly new root.

"git pull-request" will complain about not having a commit in common,
but "git merge" apparently does not even warn.

Adding Junio and the git list. This seems like much too easy a way to screw up.

Junio (and git people), the problem is that github seems to have
caused Laxman to think he should start a new project, and then git
happily merged the new root just because nobody knew better. And
sadly, I didn't notice the history screw-up until too late, so now we
in the kernel have a third root commit (the first two are
intentional): commit a101ad945113 was merged by commit e5451c8f8330.

So how about a patch something like this:

  --- a/builtin/merge.c
  +++ b/builtin/merge.c
  @@ -1398,7 +1398,7 @@ int cmd_merge(int argc, const char **argv,
const char *prefix)
 NULL, 0, UPDATE_REFS_DIE_ON_ERR);

  if (remoteheads && !common)
  -   ; /* No common ancestors found. We need a real merge. */
  +   die(_("No common ancestor - not merging"));
  else if (!remoteheads ||
   (!remoteheads->next && !common->next &&
common->item == remoteheads->item)) {

(the above is explicitly whitespace-damaged on purpose - it's not
meant as a serious patch, because we do want the *ability* to merge
different projects across different roots, and there are even git
tests for it, it's just that I think it's too easy to make this
mistake and not even realize).

So the real thing having a special option required to merge
non-related projects? Or at least a humongous warning?

You can recreate (for testing only!) this by doing this in a kernel repo:

  git checkout a101ad945113
  git merge 3cf42efc3479

and you'll see how it happily ends up creating a merge commit with no
common ancestors and no warning that anything might be wrong. It will
take a while - walking all the way up to the root to not find the
common object - but it will happily merge those two totally unrelated
branches without complaining at all.

Now I'm starting to wonder just how many github projects have lots of
separate root commits..

Linus

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Linus Torvalds]

On Thu, Mar 17, 2016 at 11:07 PM, Laxman Dewangan  wrote:
>
> For creating the repo and branch, I just followed the instruction from wiki
> https://help.github.com/articles/create-a-repo/

So you shouldn't have created a new repo at all, you should just have
cloned an existing one (that gets you a repo, of course).

You basically ended up starting a new project.

But I guess the github connection explains why there was a crazy
README.md file there, and I can see why that documentation would make
you think it's the right thing to do.

Oh well.

Just a "git init" wouldn't have done that kind of damage, the github
documentation is just misleading in this respect.

We may have to make it really really really clear for the kernel that
people should not use github in any way except purely for hosting..

> I jut use git (git version 2.1.4) for pushing the changes in github repo.
>
> There is no other tools used.

I thought git didn't merge two branches that have no common base by
default, but it seems it will happily do so.

So once you made the mistake of starting a new project, git merge
ended up "helpfully" allowing you to merge the remote tracking branch
into that new project, and we ended up with a silly new root.

"git pull-request" will complain about not having a commit in common,
but "git merge" apparently does not even warn.

Adding Junio and the git list. This seems like much too easy a way to screw up.

Junio (and git people), the problem is that github seems to have
caused Laxman to think he should start a new project, and then git
happily merged the new root just because nobody knew better. And
sadly, I didn't notice the history screw-up until too late, so now we
in the kernel have a third root commit (the first two are
intentional): commit a101ad945113 was merged by commit e5451c8f8330.

So how about a patch something like this:

  --- a/builtin/merge.c
  +++ b/builtin/merge.c
  @@ -1398,7 +1398,7 @@ int cmd_merge(int argc, const char **argv,
const char *prefix)
 NULL, 0, UPDATE_REFS_DIE_ON_ERR);

  if (remoteheads && !common)
  -   ; /* No common ancestors found. We need a real merge. */
  +   die(_("No common ancestor - not merging"));
  else if (!remoteheads ||
   (!remoteheads->next && !common->next &&
common->item == remoteheads->item)) {

(the above is explicitly whitespace-damaged on purpose - it's not
meant as a serious patch, because we do want the *ability* to merge
different projects across different roots, and there are even git
tests for it, it's just that I think it's too easy to make this
mistake and not even realize).

So the real thing having a special option required to merge
non-related projects? Or at least a humongous warning?

You can recreate (for testing only!) this by doing this in a kernel repo:

  git checkout a101ad945113
  git merge 3cf42efc3479

and you'll see how it happily ends up creating a merge commit with no
common ancestors and no warning that anything might be wrong. It will
take a while - walking all the way up to the root to not find the
common object - but it will happily merge those two totally unrelated
branches without complaining at all.

Now I'm starting to wonder just how many github projects have lots of
separate root commits..

Linus

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Johannes Schindelin]

Hi Linus,

On Fri, 18 Mar 2016, Linus Torvalds wrote:

> I thought git didn't merge two branches that have no common base by
> default, but it seems it will happily do so.

What happened to "The coolest merge EVER!"?

http://thread.gmane.org/gmane.comp.version-control.git/5126/

Ciao,
Dscho

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Johannes Schindelin]

Hi Linus,

On Fri, 18 Mar 2016, Linus Torvalds wrote:

> I thought git didn't merge two branches that have no common base by
> default, but it seems it will happily do so.

What happened to "The coolest merge EVER!"?

http://thread.gmane.org/gmane.comp.version-control.git/5126/

Ciao,
Dscho

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Linus Torvalds]

On Fri, Mar 18, 2016 at 9:37 AM, Junio C Hamano  wrote:
>
>> I don't think the original "resolve" did it, for example. You can't do
>> a three-way merge without a base.
>
> Yes, and that continues to this day:

Yeah, "octopus" also refuses it cleanly:

common=$(git merge-base --all $SHA1 $MRC) ||
die "Unable to find common commit with $pretty_name"

The code in the recursive merge that allows this to happen is this:

if (merged_common_ancestors == NULL) {
/* if there is no common ancestor, use an empty tree */
struct tree *tree;

tree = lookup_tree(EMPTY_TREE_SHA1_BIN);
merged_common_ancestors = make_virtual_commit(tree, "ancestor");
}

so the "no common ancestors" is just considered to be an empty merge base.

And I do think that's right, and I think it's clever, and it goes back to 2006:

  934d9a24078e merge-recur: if there is no common ancestor, fake empty one

but I think there should be an option there.

> This is a tangent but I wonder if we should say why we refuse to
> the standard error before calling these two "exit"s.

As mentioned, Octopus does.

That said, there's probably no reason to ever use the old three-way
merge, so I'm not even sure it's worth fixing the old
git-merge-resolve.

Linus

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Linus Torvalds]

On Fri, Mar 18, 2016 at 9:37 AM, Junio C Hamano  wrote:
>
>> I don't think the original "resolve" did it, for example. You can't do
>> a three-way merge without a base.
>
> Yes, and that continues to this day:

Yeah, "octopus" also refuses it cleanly:

common=$(git merge-base --all $SHA1 $MRC) ||
die "Unable to find common commit with $pretty_name"

The code in the recursive merge that allows this to happen is this:

if (merged_common_ancestors == NULL) {
/* if there is no common ancestor, use an empty tree */
struct tree *tree;

tree = lookup_tree(EMPTY_TREE_SHA1_BIN);
merged_common_ancestors = make_virtual_commit(tree, "ancestor");
}

so the "no common ancestors" is just considered to be an empty merge base.

And I do think that's right, and I think it's clever, and it goes back to 2006:

  934d9a24078e merge-recur: if there is no common ancestor, fake empty one

but I think there should be an option there.

> This is a tangent but I wonder if we should say why we refuse to
> the standard error before calling these two "exit"s.

As mentioned, Octopus does.

That said, there's probably no reason to ever use the old three-way
merge, so I'm not even sure it's worth fixing the old
git-merge-resolve.

Linus

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Linus Torvalds]

On Thu, Mar 17, 2016 at 1:59 AM, Linus Walleij  wrote:
>
> NOTE: tree was a bit dirty and I realized it too late: Laxmans
> devm_gpiochip_add() branch was based on my for-next branch rather
> than my devel branch, making some commits appear twice and
> a file named README.md "Share upstreaming patches" appear and
> then get reverted out by me.
>
> The end result should be clean but the history is a bit messy.

Gaah. I took the tree, but I didn't realize just *how* messy it was. I
doubt you did either.

Dammit, had I realized just how screwed up that branch was, I'd have
made you re-do it.

Because that branch is crap.

And the real reason is is crap isn't a "README.md" file that comes and
goes. The real reason it is crap is that it has a new root commit, and
Laxman has done something TOTALLY INSANE.

I'm not even sure what insane tool was used to do this, but there's a
new root commit at

  a101ad945113be3d7f283a181810d76897f0a0d6

that has no parenthood, and that is only used for a completely bogus
merge (merge commit e5451c8f8330e03ad3cfa16048b4daf961af434f). That's
where the README.md file comes from.

Git does support the notion of having multiple roots, and it is a
useful thing to have when you merge two different projects with
separate history. In fact, git itself has that, for 'gitk' that was
merged into the main git history.

We have that in the kernel for the initial btrfs merge too, actually.
btrfs started out outside the full kernel, and had a root of its own
with its own development history, and then it was merged into the
kernel tree under fs/btrfs.

But this is *not* that. That commit
a101ad945113be3d7f283a181810d76897f0a0d6 is just pure garbage, and the
merge that introduces it is pure shit.

Dammit, I noticed too late, so now it's out there. How the hell did
that even happen? Why did Laxman do that insane merge? Why did it get
pulled back?

You actually have to *work* at making shit like this, so I wonder what
workflow you guys had to make that bad merge. It's easy enough to do
with git manually, but it's hard to do by _mistake_. Is there some
broken tool that Laxman uses?

I'm very annoyed, because while the multi-root situation can be
useful, it can also be confusing as hell. It can cause bisection
problems, and it can just cause people to go "WTF?"

I need to know what happened and make sure it doesn't happen again. If
this is some intentional workflow by nvidia, it needs to stop *now*.
It's broken shit.

   Linus

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Linus Torvalds]

On Thu, Mar 17, 2016 at 1:59 AM, Linus Walleij  wrote:
>
> NOTE: tree was a bit dirty and I realized it too late: Laxmans
> devm_gpiochip_add() branch was based on my for-next branch rather
> than my devel branch, making some commits appear twice and
> a file named README.md "Share upstreaming patches" appear and
> then get reverted out by me.
>
> The end result should be clean but the history is a bit messy.

Gaah. I took the tree, but I didn't realize just *how* messy it was. I
doubt you did either.

Dammit, had I realized just how screwed up that branch was, I'd have
made you re-do it.

Because that branch is crap.

And the real reason is is crap isn't a "README.md" file that comes and
goes. The real reason it is crap is that it has a new root commit, and
Laxman has done something TOTALLY INSANE.

I'm not even sure what insane tool was used to do this, but there's a
new root commit at

  a101ad945113be3d7f283a181810d76897f0a0d6

that has no parenthood, and that is only used for a completely bogus
merge (merge commit e5451c8f8330e03ad3cfa16048b4daf961af434f). That's
where the README.md file comes from.

Git does support the notion of having multiple roots, and it is a
useful thing to have when you merge two different projects with
separate history. In fact, git itself has that, for 'gitk' that was
merged into the main git history.

We have that in the kernel for the initial btrfs merge too, actually.
btrfs started out outside the full kernel, and had a root of its own
with its own development history, and then it was merged into the
kernel tree under fs/btrfs.

But this is *not* that. That commit
a101ad945113be3d7f283a181810d76897f0a0d6 is just pure garbage, and the
merge that introduces it is pure shit.

Dammit, I noticed too late, so now it's out there. How the hell did
that even happen? Why did Laxman do that insane merge? Why did it get
pulled back?

You actually have to *work* at making shit like this, so I wonder what
workflow you guys had to make that bad merge. It's easy enough to do
with git manually, but it's hard to do by _mistake_. Is there some
broken tool that Laxman uses?

I'm very annoyed, because while the multi-root situation can be
useful, it can also be confusing as hell. It can cause bisection
problems, and it can just cause people to go "WTF?"

I need to know what happened and make sure it doesn't happen again. If
this is some intentional workflow by nvidia, it needs to stop *now*.
It's broken shit.

   Linus

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Linus Torvalds]

On Fri, Mar 18, 2016 at 2:39 AM, Laxman Dewangan  wrote:
>
> Apologizing for the trouble created by me.

Don't worry about it, we'll just have to make sure it doesn't happen again.

I thought you must have had done something special to do this, and
that made me upset.

But the fact that it was just a trivial and explainable mistake makes
it slightly sad, but "mistakes happen".

I'll push to get it harder to make this mistake in git, and that will
be part of the "let's make sure it doesn't happen again".

We have other ugly history issues. I don't like it, and I wish I had
caught this earlier (or better yet, somebody else had), but it's water
under the bridge.

 Linus

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

[Linus Torvalds]

On Fri, Mar 18, 2016 at 2:39 AM, Laxman Dewangan  wrote:
>
> Apologizing for the trouble created by me.

Don't worry about it, we'll just have to make sure it doesn't happen again.

I thought you must have had done something special to do this, and
that made me upset.

But the fact that it was just a trivial and explainable mistake makes
it slightly sad, but "mistakes happen".

I'll push to get it harder to make this mistake in git, and that will
be part of the "let's make sure it doesn't happen again".

We have other ugly history issues. I don't like it, and I wish I had
caught this earlier (or better yet, somebody else had), but it's water
under the bridge.

 Linus