Here are the fixed patches. Check this and advise me if there are any
errors.
El dom., 19 jul. 2020 a las 23:53, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> > Note: before doing rebases etc. I'd advise to push your current tree to
> > a separate branch that you can always restart
I also find it really helpful to use magit. Emacs' plugin to help me do
git things.
This video is a short introduction for it:
https://www.youtube.com/watch?v=mtliRYQd0j4
--
Joshua Branson
Sent from Emacs and Gnus
> Note: before doing rebases etc. I'd advise to push your current tree to
> a separate branch that you can always restart from, to avoid risking
> losing everything. There are ways to restore things, but it's way easier
> to just keep a branch on the side where you know your changes are safe.
At
Note: before doing rebases etc. I'd advise to push your current tree to
a separate branch that you can always restart from, to avoid risking
losing everything. There are ways to restore things, but it's way easier
to just keep a branch on the side where you know your changes are safe.
Samuel
Almudena Garcia writes:
> But I've already committed these changes in my repository. How can I
> recommit them?
You can change commits with “git rebase”. Use “git rebase -i” for
interactive rebasing, which gives you a list of commits to which you can
apply changes. If you want to change all
On 19 Jul 2020, at 20:07, Almudena Garcia 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
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?
El dom., 19 jul. 2020 a las 20:51, Almudena Garcia (<
ok. I had splitted It manually. Now I'll try again this way.
El dom., 19 jul. 2020 a las 20:49, Jessica Clarke ()
escribió:
> On 19 Jul 2020, at 19:46, Almudena Garcia
> wrote:
> >
> > > for any patch it’s best to not just show a single large diff but to
> > > split the changes into logically
On 19 Jul 2020, at 19:46, Almudena Garcia 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
> 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
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 (<
liberamenso10...@gmail.com>) escribió:
> Thanks for your explanation:
>
> > To commit only some changes and not others you can select
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
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
There are many files with different code styles. I'm confused about what is
the correct style.
El dom., 19 jul. 2020 a las 19:10, Jessica Clarke ()
escribió:
> On 19 Jul 2020, at 18:06, Almudena Garcia
> wrote:
> >
> > I fixed tabulations and comments style. Now better?
>
> Not hugely. Go read
Thanks. I'm grateful for your support of my work.
It's a difficult task, and I'm very noob yet. But I'm trying to advance
until my knowledge allows.
The Hurd devs support is very important to learn the necessary to get this
objective.
El dom., 19 jul. 2020 a las 19:01, escribió:
> Hey
On 19 Jul 2020, at 18:06, Almudena Garcia wrote:
>
> I fixed tabulations and comments style. Now better?
Not hugely. Go read files in the same directory and see if they look
like what you've written.
Jess
> El dom., 19 jul. 2020 a las 18:49, Jessica Clarke ()
> escribió:
> On 19 Jul 2020,
I fixed tabulations and comments style. Now better?
El dom., 19 jul. 2020 a las 18:49, Jessica Clarke ()
escribió:
> On 19 Jul 2020, at 17:44, Almudena Garcia
> wrote:
> >
> > Hi all:
> >
> > I attach a patch, with the code to find the cpus and enumerate them,
> reading from ACPI tables and
Hey Almudena!
I quite admire your determination to work on the Hurd SMP! I would be terrified
to try to work on something crazy cool like that. But as a friend told me
recently, "No one cares about your theories and thoughts. People care about
your actions. There were nights when I was doing a
Ok. I'll check the coding style. I'm trying to follow GNU style, but maybe
I missed It in some files.
El dom., 19 jul. 2020 a las 18:49, Jessica Clarke ()
escribió:
> On 19 Jul 2020, at 17:44, Almudena Garcia
> wrote:
> >
> > Hi all:
> >
> > I attach a patch, with the code to find the cpus and
On 19 Jul 2020, at 17:44, Almudena Garcia wrote:
>
> Hi all:
>
> I attach a patch, with the code to find the cpus and enumerate them, reading
> from ACPI tables and MADT (APIC) tables.
>
> I've tested it over Qemu, but I recommends to test It before committing,
> anyway.
>
> You can find
Hi all:
I attach a patch, with the code to find the cpus and enumerate them,
reading from ACPI tables and MADT (APIC) tables.
I've tested it over Qemu, but I recommends to test It before committing,
anyway.
You can find the rest of the work in my GitHub repository
21 matches
Mail list logo
