Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 3/7] croosbar moved to buildroot.
Date: Mon, 1 Feb 2016 12:19:02 +0100	[thread overview]
Message-ID: <20160201121902.0c13ce7b@free-electrons.com> (raw)
In-Reply-To: <56AF1D2B.30202@mclink.it>

Mauro,

Please don't reply to me directly: keep the list in Cc so that everyone
can participate to the discussion, and the discussion benefits to
everyone. Also, please don't top-post, this is considered bad practice.

On Mon, 1 Feb 2016 09:54:03 +0100, Mauro Condarelli wrote:

> I am a bit confused.
> I tried to follow instructions in manual, but apparently I failed to fully understand them.
> I currently have a "personal" branch where I'm developing (part of a full installation where I'm developing my RootFilesystem for a real platform).
> What I sent are the diffs after a rebase and they reflect exactly what I submitted in the past days (of course).
> How should I prepare patches for the list?

The patches we want to see must be organized in a certain way (one
patch per new package, one patch for each logical change, etc.). Of
course, while you're doing your developing, you're probably going back
and forth between packages, and certainly not committing things
immediately in a way that is "clean" enough for submission.

So while all developers do for multi-patches series, they rewrite the
history of commits to produce a "clean" set of commits that is
appropriate for submission.

To do this, you need to use "interactive rebasing". You can learn about
it https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History.

> The only way I see to separate in a logical order would be:
> 
> 1) clone a buildroot (master) in a separate subdir.
> 2) hand apply changes needed for a single package.
> 3) generate patches.
> 4) checkout "origin/master" (discarding changes)
> 5) go back to (2) for next package.
> 
> Is this the right way or do You have some better advice?
> Notice that with the above schema  I will not be able to try compiling (at least some) packages
> as they are not independent (e.g.: crossbar needs  *all* those patches to compile).

See above: use the interactive rebase functionality of Git.

One hint: for your big patch that adds all the packages, what you want
to do is:

 1/ Mark the patch as "edit" in your interactive rebase session
 2/ Git will stop at this patch

 3/ Use "git reset HEAD^" to de-apply the commit and put the changes
    back into your working tree

 4/ Create new commits.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  parent reply	other threads:[~2016-02-01 11:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-01  1:25 [Buildroot] [PATCH 0/7] crossbar package and its dependencies Mauro Condarelli
2016-02-01  1:25 ` [Buildroot] [PATCH 1/7] Update for 2015.11.1 Mauro Condarelli
2016-02-01  7:22   ` Thomas Petazzoni
2016-02-01  1:25 ` [Buildroot] [PATCH 2/7] Additions necessary to compile Crossbar.io Mauro Condarelli
2016-02-01  7:22   ` Thomas Petazzoni
2016-02-01  1:25 ` [Buildroot] [PATCH 3/7] croosbar moved to buildroot Mauro Condarelli
2016-02-01  7:24   ` Thomas Petazzoni
     [not found]     ` <56AF1D2B.30202@mclink.it>
2016-02-01 11:19       ` Thomas Petazzoni [this message]
2016-02-01  1:25 ` [Buildroot] [PATCH 4/7] croosbar moved to buildroot (2) Mauro Condarelli
2016-02-01  7:25   ` Thomas Petazzoni
2016-02-01  1:25 ` [Buildroot] [PATCH 5/7] update of .hash files Mauro Condarelli
2016-02-01  7:26   ` Thomas Petazzoni
2016-02-01  1:25 ` [Buildroot] [PATCH 6/7] Dependencies added to package python-crossbar Mauro Condarelli
2016-02-01  1:25 ` [Buildroot] [PATCH 7/7] Further dependencies installed Mauro Condarelli

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=20160201121902.0c13ce7b@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /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