All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laxman Dewangan <ldewangan@nvidia.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Linus Walleij <linus.walleij@linaro.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [GIT PULL] GPIO bulk changes for kernel v4.6
Date: Fri, 18 Mar 2016 11:37:08 +0530	[thread overview]
Message-ID: <56EB9B0C.4050507@nvidia.com> (raw)
In-Reply-To: <CA+55aFwV4Cq=4zJc6Fw0yAGrTmci_DFAjJKxkk05pjJJf3iYbA@mail.gmail.com>


On Friday 18 March 2016 11:37 AM, Linus Torvalds wrote:
> On Thu, Mar 17, 2016 at 1:59 AM, Linus Walleij <linus.walleij@linaro.org> 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.




  reply	other threads:[~2016-03-18  6:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-17  8:59 [GIT PULL] GPIO bulk changes for kernel v4.6 Linus Walleij
2016-03-18  6:07 ` Linus Torvalds
2016-03-18  6:07   ` Laxman Dewangan [this message]
2016-03-18  7:15     ` Linus Torvalds
2016-03-18 14:32       ` Johannes Schindelin
2016-03-18 15:43         ` Junio C Hamano
2016-03-18 15:43           ` Junio C Hamano
2016-03-18 15:47         ` Linus Torvalds
2016-03-18 16:37           ` Junio C Hamano
2016-03-18 16:37             ` Junio C Hamano
2016-03-18 17:01             ` Linus Torvalds
2016-03-18 17:16               ` Junio C Hamano
2016-03-18 17:16                 ` Junio C Hamano
2016-03-18  9:01   ` Linus Walleij
2016-03-18  9:39     ` Laxman Dewangan
2016-03-18 15:56       ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56EB9B0C.4050507@nvidia.com \
    --to=ldewangan@nvidia.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.