Dave McCaldon wrote:
> > I agree with Alexander, fix up uses of the now-deprecated pubkey
> > define and this is good for a commit!
>
> I hate to open up another can of worms, but I left this alone
> because there's another, similar define
> LIBSSH2_ERROR_PUBLICKEY_UNVERIFIED. I'm not sure how this relates
> to LIBSSH2_ERROR_PUBLICKEY_UNRECOGNIZED.
I'm surprised you're not sure. It is unrelated and does not need to
be touched.
> Is it reasonable to simply supply and additional patch, or do I
> need to roll this back and create a new patch? (or maybe squish
> the two into one -- my O'Reilly Git book just arrived today!).
Please send a single patch, since it greatly helps when applying your
changes.
If anyone has questions about how to work with git to prepare patches
then please just ask them and we'll try to answer. There is also a
very helpful IRC channel #git on irc.freenode.net where you can get
help from git experts almost 24/7.
It is totally possible to change history in git, you can go back and
make changes to an old commit, and then rebase any later events onto
the new version of the old commit. Another pattern is to use branches
a lot. I'm not using branches very much, but they can be very handy.
This patch you sent was 2/2, so apparently it is not the only patch
you have against current master? Or was the first one already pushed
by Daniel? In that case you can git pull --rebase and after that
would you only be a single commit ahead? If you only need to change
the very latest commit in your repo then things are very simple, just
change files, git add them, then git commit --amend
Or do you need to change an older commit?
//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-01-21