Re: [PATCH] Use `gnus-parameters' in `gnus-group-split-fancy'

[Daniel Dehennin <daniel.dehennin@baby-gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

Steinar Bang <sb@dod.no> writes:

[...]

> HOWTO for adding these to gnus master:
>  - Enter your git gnus clone
>     cd ~/git/gnus
>  - Add and fetch the baby-gnu gnus repo
>     git remote add baby-gnu git://git.baby-gnu.net/gnus.git
>     git fetch --tags baby-gnu
>     git fetch baby-gnu
>  - Update the gnus master branch to HEAD
>     git checkout master
>     git pull
>  - Merge in the tag, and stop for inspection (magit is nice for looking
>    at the merge results after this step, and also for fixing merge
>    conflicts): 
>     git merge --no-ff --no-commit feature/use-gnus-parameters-in-gnus-group-split-fancy
>  - After inspection and fix, either `c' to commit from inside magit, or
>    commit on the command line:
>     git commit

Hello,

When I need to make a merge for an occasional patch like this one, I'm
doing quite differently, I do not add the remote:

- I update the branch where the merge will go:
    git checkout master && git pull

- If I'm feeling paranoid, I create a dedicated branch to test the
  merge:
    git checkout -b i master

- I just merge the tag with information given in the pull request:
    git pull git://git.baby-gnu.net/gnus.git tags/feature/use-gnus-parameters-in-gnus-group-split-fancy

- In case of paranoid:
  + I edit the merge message to replace “i” by the real branch where I
    want to merge
  + I merge the “i” branch in master, If I'm not happy with the merge, I
    just trash the branch and ask for a reworked patch

- In non-paranoid case, if I'm not happy with the merge, I just reset
  it (by resetting to “upstream” state):
    git reset --hard @{u}
  
Regards.
-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x7A6FE2DF

[-- Attachment #2: Type: application/pgp-signature, Size: 229 bytes --]