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+
prev parent 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 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.