bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] SMP initialization: detection and enumeration


From: Jessica Clarke
Subject: Re: [PATCH] SMP initialization: detection and enumeration
Date: Sun, 19 Jul 2020 20:12:42 +0100

On 19 Jul 2020, at 20:07, Almudena Garcia <liberamenso10000@gmail.com> wrote:
> 
> But I've already committed these changes in my repository. How can I recommit 
> them? 
> Added to this, I need to generate the patch using the "master" branch (which 
> points to gnumach's upstream) to compare with the mine.
> 
> How can I solve this?

Look up git rebase.

> El dom., 19 jul. 2020 a las 20:51, Almudena Garcia 
> (<liberamenso10000@gmail.com>) escribió:
> ok. I had splitted It manually. Now I'll try again this way.
> 
> El dom., 19 jul. 2020 a las 20:49, Jessica Clarke (<jrtc27@jrtc27.com>) 
> escribió:
> On 19 Jul 2020, at 19:46, Almudena Garcia <liberamenso10000@gmail.com> wrote:
> > 
> > > for any patch it’s best to not just show a single large diff but to
> > > split the changes into logically related commits
> > I've just split the patch. I enumerated them following the dependencies 
> > order. 
> > 
> > > The commit
> > > message should describe the changes in a GNU-style ChangeLog format; you
> > > may also add additional descriptions.  
> > 
> > Where can I add this information? In the same patch or in a log file?
> 
> In the commit message. Then use git format-patch to create the patch
> files, not git diff/show. Personally I also find it easier when people
> use git send-email as then the patches are inline rather than as
> attachments, it makes it easier to reply and annotate.
> 
> Jess
> 
> > El dom., 19 jul. 2020 a las 20:23, Almudena Garcia 
> > (<liberamenso10000@gmail.com>) escribió:
> > Anyway, my patch is short. Maybe I can split It manually, taking care about 
> > dependencies between blocks. 
> > 
> > El dom., 19 jul. 2020 a las 20:17, Almudena Garcia 
> > (<liberamenso10000@gmail.com>) escribió:
> > Thanks for your explanation:
> > 
> > > To commit only some changes and not others you can select lines of
> > > interest with “git add -p” (or similar).  Once all connected changes
> > > have been staged you can commit them.  Do this repeatedly until you have
> > > a series of commits that are all small enough that a reviewer can
> > > understand them (and thus your thinking) at a glance.
> > 
> > I have already a commit list pushed in my GitHub repository. You can see It 
> > here: https://github.com/AlmuHS/GNUMach_SMP/commits/smp-new
> > But, in this case, my code is almost written from scratch, so It's complex 
> > to filter line by line.
> > The code only makes sense in a single piece. Otherway, the code doesn't 
> > compile or does nothing. 
> > 
> > > You can then turn that series of commits into a series of patches with
> > > “git format-patch”.  For example, “git format-patch -10” will generate
> > > 10 patch files from the last 10 commits.
> > 
> > Ok, I'll try this. But there are so many commits. 
> > 
> > 
> > El dom., 19 jul. 2020 a las 19:52, Ricardo Wurmus (<rekado@elephly.net>) 
> > escribió:
> > 
> > Hi,
> > 
> > for any patch it’s best to not just show a single large diff but to
> > split the changes into logically related commits.  You’re probably
> > working with Git, so the unit that we’re working with is a Git commit.
> > 
> > You should group related changes and commit them together.  The commit
> > message should describe the changes in a GNU-style ChangeLog format; you
> > may also add additional descriptions.  Here’s an example:
> > 
> > --8<---------------cut here---------------start------------->8---
> > kern: Frobnicate the jabberwocky.
> > 
> > In order to frobnicate the jabberwocky without confusion we only add the
> > core functionality here.
> > 
> > * kern/smp.c, kern/smp.h: New files.
> > * Makefrag.am (libkernel_a_SOURCES): Add them.
> > --8<---------------cut here---------------end--------------->8---
> > 
> > To commit only some changes and not others you can select lines of
> > interest with “git add -p” (or similar).  Once all connected changes
> > have been staged you can commit them.  Do this repeatedly until you have
> > a series of commits that are all small enough that a reviewer can
> > understand them (and thus your thinking) at a glance.
> > 
> > You can then turn that series of commits into a series of patches with
> > “git format-patch”.  For example, “git format-patch -10” will generate
> > 10 patch files from the last 10 commits.  You can attach these patches
> > to an email, or if you have configured “git send-email” correctly you
> > could send them directly via email to this list.  A reviewer can then
> > comment on each commit individually and apply them one by one if they
> > pass muster.
> > 
> > (This process is similar for most GNU packages.)
> > 
> > Hope this helps!
> > 
> > -- 
> > Ricardo
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]