git cat-file -p $sha is as close as you can get to commit objects
without needing to write your own decompressing wrapper. But it gives
the same results.
Now, does the signed data also contain the parent sha?
If yes, our discussion about rebasing is moot, because a rebase will in every
case
On 2 June 2012 03:12, Andreas K. Huettel dilfri...@gentoo.org wrote:
git cat-file -p $sha is as close as you can get to commit objects
without needing to write your own decompressing wrapper. But it gives
the same results.
Now, does the signed data also contain the parent sha?
If yes, our
On Fri, Jun 1, 2012 at 11:12 AM, Andreas K. Huettel
dilfri...@gentoo.org wrote:
Now, does the signed data also contain the parent sha?
So, I was working on a lengthy email which now would be fairly
repetitive of what Kent posted.
Suffice it to say I managed to rip out a commit from the kde
On 2 June 2012 03:12, Andreas K. Huettel dilfri...@gentoo.org wrote:
git cat-file -p $sha is as close as you can get to commit objects
without needing to write your own decompressing wrapper. But it gives
the same results.
Now, does the signed data also contain the parent sha?
If
On Fri, Jun 1, 2012 at 11:36 AM, Andreas K. Huettel
dilfri...@gentoo.org wrote:
On 2 June 2012 03:12, Andreas K. Huettel dilfri...@gentoo.org wrote:
Yes. Which basically means, you *cannot* have both
a) rebase only merges
and
b) every commit must be signed
as policies.
I would say that
On Fri, Jun 1, 2012 at 5:53 PM, Rich Freeman ri...@gentoo.org wrote:
If you want the tree to be traceable to Gentoo devs, then rewriting
the signatures is probably a good thing.
I'd say that signing the merge commit is good enough. It says the
Gentoo dev who merged it has reviewed the changes
On 2 June 2012 03:53, Rich Freeman ri...@gentoo.org wrote:
git-rebase is just a shell script, that ultimately just calls
git-commit as far as I can see, which means that implementing
re-signing is just a matter of adding the appropriate parameters, or
use default configuration (assuming it
On Fri, Jun 01, 2012 at 11:53:52AM -0400, Rich Freeman wrote:
However, Kent did point out the rebase function doesn't actually apply
new signatures to the new old commits anyway, so you'd end up with
unsigned commits in the history.
Only in your local history. The push to the central repo would
Only in your local history. The push to the central repo would only send
the commits in the active chain to your branch HEAD.
Any commits that are rebased, and then replicated somewhere after that
rebase, will be stripped of their signatures by the rebase process.
--
Kent
perl -e print
On Sat, Jun 02, 2012 at 04:56:33AM +1200, Kent Fredric wrote:
Only in your local history. The push to the central repo would only send
the commits in the active chain to your branch HEAD.
Any commits that are rebased, and then replicated somewhere after that
rebase, will be stripped of their
10 matches
Mail list logo
