Re: Small fix of column number in parser

[Jordi Gutiérrez Hermoso]

2011/4/28 Daniel Kraft <address@hidden>:

> Regarding testing a patch before commit (or submitting it), is there
> some "standard required way" -- i.e., running "make check" without
> errors or something else?

Yes, "make check" should be part of your testing, make sure you didn't
break something inadvertently.

>>> Do you prefer this simple patch or should I work on some
>>> "clean-up" of this situation, too -- like making skip_white_space
>>> a member of stdio_stream_reader and unifying column- and
>>> line-number tracking in one place.
>>
>> I think for a first patch, a minimal solution is fine. Leave the
>> refactoring for later.
>
> Ok. So should I now work on a refactoring?

No, I don't think this problem is worth it. Do you disagree? Find
bigger fish to fry.

> Ok about the commit message and ChangeLog change.  How can I convert
> my mq queue to a finished patch?

The "hg qfinish" will turn your patch into a commit. Before you do
that, you should edit your commit message with "hg qref -e" to do so
in an editor or "hg qref -m 'foo (bar): baz'" if it's a short
one-liner. You can read the hg docstrings for the foo command by
typing "hg help foo".

> Is it enough to just do a hg commit on the active queue before hg
> export? And if I do this, can I later get back to the patch, revise
> it and submit a changed version in case something comes up in code
> review?

If you need to move your commit back to the hg queue, you can do so
with "hg qimport -r $patch_rev", then follow whatever mq workflow
works for you.

Mercurial is a great DVCS; I really like it. I think you should get
yourself comfortable with it. There's a free book online that is quite
comprehensive. You probably would also enjoy a graphical frontend to
it like TortoiseHg which is handy for visualising your repo's DAG. If
you need help with it, you can consult the mailing lists or its
channel in Freenode; both have been very welcoming to me.

HTH,
- Jordi G. H.