From: Gaudenz Steinlin <gaudenz@soziologie.ch>
To: sup-devel <sup-devel@rubyforge.org>
Subject: Re: [sup-devel] Need help applying patches
Date: Tue, 22 Feb 2011 14:14:38 +0100 [thread overview]
Message-ID: <1298379918-sup-5032@meteor.durcheinandertal.local> (raw)
In-Reply-To: <1298230750-sup-6418@whisper>
[-- Attachment #1.1: Type: text/plain, Size: 1875 bytes --]
Hi
Excerpts from Hamish's message of 2011-02-20 20:55:33 +0100:
> Excerpts from Hamish's message of Sun Feb 20 19:19:17 +0000 2011:
> I ran into some more issues merging this into next - my usual
> cherry-pick method led to the same problems as originally, and led to me
> being listed as the committer, but I managed to do a git merge which
> preserved the commit messages from Gaudenz (although a couple of mine
> appear to be repeated).
Cherrypicking has basically the same disadvantages as rebasing as it
changes the commit ID. So don't cherry pick commits from one branch
(e.g. next) into another branch (e.g. gpgme) if you want to merge that
branch back into the branch from which you cherry-picked (e.g. you
want to merge gpgme back into next).
Also don't rebase a branch as soon as you published it somwhere for
other to pull from.
>
> If there is some better way to do this in future, please tell me.
I think the correct thing to do is to rebase your development branches
against the branch they will eventually be merged into as long as you
did not publish them. Rebasing has the nice effect of not complicating
the history to much.
If you can't rebase then merge, either merge your feature branch into
the target branch and then you are free recreate your feature branch
and rebase while you are doing development.
Or if your changes are not ready yet for merging, you can also merge
the target branch into your feature branch to get the latest changes
into your feature branch.
For testing and day to day usage I usually create a sepeparate branch
based of next and merge all my development branches into this branch.
This branch is then never published and frequently recreated if
something fails...
Gaudenz
--
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Sup-devel mailing list
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel
next prev parent reply other threads:[~2011-02-22 13:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-20 19:19 Hamish
2011-02-20 19:55 ` Hamish
2011-02-22 13:14 ` Gaudenz Steinlin [this message]
2011-02-20 20:12 ` Michael Hamann
2011-02-20 21:58 ` William Morgan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1298379918-sup-5032@meteor.durcheinandertal.local \
--to=gaudenz@soziologie.ch \
--cc=sup-devel@rubyforge.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox