public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Piotr Hosowicz <piotr@hosowicz.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: GIT again
Date: Fri, 07 Jan 2011 17:07:36 +0100	[thread overview]
Message-ID: <4D273A48.4020302@example.com> (raw)
In-Reply-To: <20110107154302.GF1891@tiehlicka.suse.cz>

On 07.01.2011 16:43, Michal Hocko wrote:
> On Fri 07-01-11 16:13:00, Piotr Hosowicz wrote:
>> Hello,
>>
>> Sorry for bothering again. I think I fimanaged to build the kernel
>> as I wanted to. Lets simplify the problem. There is Linus tree and a
>> separate tree, which was announed here as:
>>
>> git://git.kernel.org/some.git for-linus
>>
>> The objective is to build the kernel with Linus sources with
>> some.git changes incorporatwed in it. I think I managed to achieve
>> the objective doing:
>>
>> # let me remind myself ;-)
>> git clone<Linus URL here>
>> git remote add some git://git.kernel.org/some.git
>> git pull some for-linus
>
> Yes, this will merge some/for-linus branch into the current branch which
> is master (from the above sequence of commands).

Thanks.

>> I've done it this way and I am convinced I've achieved the
>> objective. But not sure.
>
> git pull is essentially the same thing as git fetch and git merge. The
> first command fetches all commits from the remote and the second one
> will merge your current tree with the given branch (it doesn't care much
> about the fact those commits come from a remote repository as those
> objects are available locally after fetch)

Thanks.

>> For sure the last command modified the
>> source, what is what I wanted, I had to finally correct ot by hand
>> and do git commit -a.
>
> This is because you could end up with some conflicts after merge.
> Anyway, git commit -a is not the best way to do this in general. I would
> encourage you to use git status to get an overview of what has changed
> (what is the conflict etc...) and selectively git add only those changes
> that are relevant and then git commit after you are done.

I thought so. Thanks.

> Btw. the way you did this is not very much optimal. You have merged
> something into your _master_ branch which means that when-ever you want
> to pull again from linus you will have to merge again. In general I tend
> to keep the _master_ branch without any modifications and do all my
> changes (merges with other external sources etc.) in dedicated branches
> so that I can keep following linus master without any modifications.

That is a future stage to some. Now I am happy and proud I have what I 
wanted.

Thanks, regards,

Piotr Hosowicz

-- 
<Nub> Może mi ktoś wytłumaczyć, jak dzielą sie komórki?
<Tolek> o
<Tolek> O
<Tolek> 8
<Tolek> o o
NP: Peter Green Splinter Group - Burglar
NB: 2.6.37-20110107-1437-pztidm+

      reply	other threads:[~2011-01-07 16:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-07 15:13 GIT again Piotr Hosowicz
2011-01-07 15:43 ` Michal Hocko
2011-01-07 16:07   ` Piotr Hosowicz [this message]

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=4D273A48.4020302@example.com \
    --to=piotr@hosowicz.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox