Subject: Re: [sup-devel] Need help applying patches

From: William Morgan <[email-masked]>
Date: Sun, 20 Feb 2011 21:58:13 +0000

Reformatted excerpts from Hamish's message of 2011-02-20:
> But I can't see why it could not find it. The code quoted above has
> moved down by 31 lines, but is otherwise unchanged, but I thought git
> could cope with that :/

Git apply is a pretty low-level command and I believe it acts basically like
the patch command, i.e. fails fast if things aren't perfectly in tune.

To pull in the git merge logic on patch files, use `git am -3`.

> $ git am -s ../patches2merge/
> Nothing to do.

I think it's trying to interpret that directory as a maildir. Give it the
individual files.
-- 
William <[email-masked]>
_______________________________________________
Sup-devel mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-devel

---

From: Hamish <[email-masked]>
Date: Sun, 20 Feb 2011 19:19:17 +0000

Gaudenz has submitted a few useful patches which I want to commit to the
gpgme branch, but git apply seems to fail. I've forwarded the message
text below, and attached the patches. When I apply it gpgme, I get:

$ git apply --check --verbose ../patches2merge/0001-Unify-formatting-of-GPGME-error-messages.patch
Checking patch lib/sup/crypto.rb...
error: while searching for:
    begin
      sig = GPGME.detach_sign(format_payload(payload), gpg_opts)
    rescue GPGME::Error => exc
      info "Error while running gpg: #{exc.message}"
      raise Error, "GPG command failed. See log for details."
    end

    envelope = RMail::Message.new

error: patch failed: lib/sup/crypto.rb:75
error: lib/sup/crypto.rb: patch does not apply

I tried hand-editing the patch to change the line numbers, but I still
get the same error. Am I missing a trick? I've checked the file formats
and both have unix-style line endings.

I have tried and I can apply these patches by hand, but then they will
appear as committed by me, rather than giving Gaudenz his due.

Do others have the same problem? You could try by checking out the gpgme
branch and trying git apply.

I've also tried git am on a directory with these 3 attachments in:

Not very helpful. Any help appreciated.

Hamish Downer

PS I am using git 1.7.1 on Ubuntu 10.10 x86_64 

--- Begin forwarded message from Gaudenz Steinlin ---
From: Gaudenz Steinlin <[email-masked]>
To: sup-devel <[email-masked]>
Date: Thu, 17 Feb 2011 14:49:01 +0000
Subject: [sup-devel] GPGME fixes

Hi

While reimporting all my messages I encountered a few problemes with
the GPGME code. Please consider the attached fixes.

The second patch depends on the first (error message unification). But
if you don't like the first I can easily produce a standalone version.

Gaudenz

---

From: Hamish <[email-masked]>
Date: Sun, 20 Feb 2011 19:55:33 +0000

> text below, and attached the patches. When I apply it gpgme, I get:

Of course, having just written an email describing my problem, I do a
little more playing about and manage to find a way through. To record
what I did:

$ cat ../patches2merge/0001-Unify-formatting-of-GPGME-error-messages.patch | git am -s -3
$ vim lib/sup/crypto.rb
$ git add lib/sup/crypto.rb
$ git am -3 --resolved

Rinse and repeat for the other 2 patches. And now the log looks like I
expect it to. 

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).

If there is some better way to do this in future, please tell me.

Hamish

---

From: Michael Hamann <[email-masked]>
Date: Sun, 20 Feb 2011 21:12:50 +0100

Hi,

Excerpts from Hamish's message of 2011-02-20 20:19:17 +0100:
[...]
> appear as committed by me, rather than giving Gaudenz his due.

You can use git commit --author="Name <[email-masked]>", then you
are recorded as committer and the author you supply is recorded as
author of the change.

Michael Hamann

---

From: Gaudenz Steinlin <[email-masked]>
Date: Tue, 22 Feb 2011 14:14:38 +0100

Hi

> preserved the commit messages from Gaudenz (although a couple of mine

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 ~
_______________________________________________
Sup-devel mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-devel