Re: Patch to tutorial.txt

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

 



On 11/20/06, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
On Mon, 20 Nov 2006, Paolo Ciarrocchi wrote:
> On 11/19/06, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
>> Paolo Ciarrocchi wrote:

>>> From: Paolo Ciarrocchi <paolo.ciarrocchi@xxxxxxxxx>
>>> Date: Sun, 19 Nov 2006 23:41:31 +0100
>>> Subject: [PATCH] One of the comment was not really clear, rephrased to
>>> make it easier to be understood by the reader
>>
>> Wordwrap. Perhaps it would be better to split description into short line,
>> and two-line description.

See http://git.or.cz/gitwiki/CommitMessageConventions

Thanks! I was not aware of that.

In short, it is better to split description into short one-line
description, for example
  "Documentation: Make comment about merging in tutorial.txt more clear"
followed by empty line, then longer description of changes (if any), for
example

  One of the comment was not really clear, rephrased to make it easier
  to be understood by the reader

followed by empty line, then signoff line, for example

  Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@xxxxxxxxx>

Ok, but the Signed/off-by part should handled  by the -s option in
git-format-patch.

> This is not clear to me, when I do a "git commit -a" I can add a text using vi,
> should I manually split the text in multiple lines?
> Only the first line will be part of the Subject?

Yes. The rest will be in the email body.

>> [...]
>>>  ------------------------------------------------
>>>
>>>  at this point the two branches have diverged, with different changes
>>> -made in each.  To merge the changes made in the two branches, run
>>> +made in each.  To merge the changes made in experimental into master run
>>
>> I would rather say:
>>   To merge the changes made in the two branches into master, run
>
> Why Jakub? There are only two branches, master and experimental.
> While sitting in master and doing git pull . experimental I would
> expect to merge I did in experimental into master. Changes did in
> master are alreay merged in master. Am I wrong?

For me, "merge" in "to merge the changes" phrase is merge in common-sense
meaning of the world, not the SCM jargon. Merge the changes == join the
changes, so you have to give both sides, both changes you join.

Merge the changes == take changes in branch 'experimental' since forking,
take changes in branch 'master' since forking, join those changes
together (merge), and put the result of this joining (this merge) into
branch 'master'.

On the contrary, in "merge branch 'experimenta' into 'master'" phrase
"merge" is in the SCM meaning of this word.


Just my 2 eurocoents of not native English speaker...

I'm not a native English speaker as well, furthemore I'm still not
confident with git so your comments are more then appreciated!

Ciao,
--
Paolo
http://docs.google.com/View?docid=dhbdhs7d_4hsxqc8
http://www.linkedin.com/pub/0/132/9a3
Non credo nelle otto del mattino. Però esistono. Le otto del mattino
sono l'incontrovertibile prova della presenza del male nel mondo.
Gli ultimi giorni, Andrew Masterson
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]