headers
Rich Freeman | 1 Jun 2012 04:49
Picon
Favicon
Gravatar

Re: Re: Portage Git migration - clean cut or git-cvsserver

On Thu, May 31, 2012 at 5:52 PM, Kent Fredric <kentfredric <at> gmail.com> wrote:
> Just I haven't worked out what happens when the SHA1 of the 'parent'
> header changes, which *will* change if the rebase is anything other
> than a fast-forward.
>
> If that SHA1 changes, the gpg signature will surely fail?

Rebasing doesn't modify past commits - it creates new ones and the
past ones are no longer in the history of the current head.  So, it
doesn't break the old signatures so much as discard them.  You would
need to create new signatures in their place, presumably from whoever
performed the rebase.

I'm trying to glean what I can from the little info out there about
how the new commit signatures work, but I don't think that you can use
signatures to convey authorship if later authors are going to rebase
the branch.  The situation is not unlike what we have now with
manifests.

As far as I can tell if you want to do work outside of master, and
then get those commits into master but preserve all the past
signatures in the history of master, then you'd need to do a merge
commit, so that all the deltas to do the merge are in a separate
commit which is then signed by the person doing the merge.

Rich
Permalink | Reply | 18 comments |
headers
Michał Górny | 1 Jun 2012 05:59
Picon
Favicon
Gravatar

Re: Re: Portage Git migration - clean cut or git-cvsserver

On Thu, 31 May 2012 17:04:30 -0500
William Hubbs <williamh <at> gentoo.org> wrote:

> On Thu, May 31, 2012 at 08:23:31PM +0100, Ciaran McCreesh wrote:
> > On Thu, 31 May 2012 14:18:04 -0500
> > William Hubbs <williamh <at> gentoo.org> wrote:
> > > > Not sure I'm following, but I will be the first to admit that
> > > > I'm a git novice.  Would this be aided by a convention, like
> > > > only committing to master on the gentoo official repository,
> > > > and any on-the-side work on places like github/etc stays in
> > > > branches? Those repositories would just keep getting fed
> > > > commits on master from the official repository.
> > > 
> > >  Iagree with this; I think we should ban merge commits on master.
> > > That would force everyone to rebase their work on current master
> > > before they commit to master which would make the history clean.
> > 
> > So what's the point of switching to git if you want to ban the main
> > reason git exists?
> 
> To clarify: we should only allow fast-forward merges on master.
> 
> My big complaint about merge commits is if you do a git show <hash> on
> a merge commit, you get nothing, so there is no way to see what
> actually changed in that commit.

Or you use a graphical tool which shows the whole merge history and you
see the exact changes happening rather than some blob with 'do foo, do
bar, and some baz too'.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michał Górny | 1 Jun 2012 06:05
Picon
Favicon
Gravatar

Re: Re: Portage Git migration - clean cut or git-cvsserver

On Thu, 31 May 2012 16:27:48 -0400
Michael Orlitzky <michael <at> orlitzky.com> wrote:

> On 05/31/12 16:09, Michał Górny wrote:
> > On Thu, 31 May 2012 15:58:43 -0400
> > Rich Freeman <rich0 <at> gentoo.org> wrote:
> > 
> >> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <mgorny <at> gentoo.org>
> >> wrote:
> >>> What would git signing work with rebased commits? Would all of
> >>> them have to be signed once again?
> >>>
> >>
> >> The whole point of rebasing is to throw away history (which is
> >> either good or bad based on your perspective).
> >>
> >> So, if 14 devs spend 3 years and 2000 commits working on something
> >> in a branch, and I commit it to master using a rebase, then all
> >> you'll see in the master history is that rich0 committed 20k lines
> >> of code to master on May 31st, and that would be signed by me.
> >>
> >> I think that rebasing before merging is a pretty typical workflow
> >> anyway - when you submit a patch to Linus, he doesn't really care
> >> that you spent six months tweaking it - he just is getting a big
> >> blob of code that either works or doesn't.  Does all that
> >> sub-history really matter?  You could always push the branch to
> >> the repository if you wanted to keep it on the side.
> > 
> > That sounds like a pretty poor workflow to me. If I tweak something
> > for 3 years, I'm likely to have a larger set of logically organized
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kent Fredric | 1 Jun 2012 06:55
Picon
Gravatar

Re: Re: Portage Git migration - clean cut or git-cvsserver

On 1 June 2012 14:49, Rich Freeman <rich0 <at> gentoo.org> wrote:
> On Thu, May 31, 2012 at 5:52 PM, Kent Fredric <kentfredric <at> gmail.com> wrote:
>> Just I haven't worked out what happens when the SHA1 of the 'parent'
>> header changes, which *will* change if the rebase is anything other
>> than a fast-forward.
>>
>> If that SHA1 changes, the gpg signature will surely fail?
>
> Rebasing doesn't modify past commits - it creates new ones and the
> past ones are no longer in the history of the current head.  So, it
> doesn't break the old signatures so much as discard them.  You would
> need to create new signatures in their place, presumably from whoever
> performed the rebase.

Hmm, thats annoying. Almost makes me wish it was the trees that were
signed, not the commits.

Although, I probably could brew up a prototype resigning tool ( based
on Git::PurePerl ,... when they accept and publish my changes ) , just
would be problematic because simply the act of signing a past commit
means the SHA1 of the commit itself is different, so all successive
commits after a re-signed commit will change and also need to be
rebased and re-signed.

--

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\ <at> tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
(Continue reading)

Permalink | Reply | 17 comments |
headers
Dirkjan Ochtman | 1 Jun 2012 10:16
Picon
Favicon

Re: Re: Portage Git migration - clean cut or git-cvsserver

On Thu, May 31, 2012 at 6:49 PM, Robin H. Johnson <robbat2 <at> gentoo.org> wrote:
> Discussion on merge policy. Originally I thought we would disallow merge
> commits, so that we would get a cleaner history. However, it turns out that if
> the repo ends up being pushed to different places with slightly different
> histories, merges are absolutely going to be required to prevent somebody from
> having to rebase at least one of their sets of commits that are already pushed.

Can you elaborate on why the cleaner history a no-merge policy
enforces is a good thing? I actually think that seeing merge commits
might clarify the history; it can be valuable to see that some mistake
was made in a merge instead, but you can only see that if there's an
explicit merge commit.

I should note that I come at this from the Mercurial side, where the
immutability of (public) history has historically carried more value
than on the git side (and related to that, rebase-like tools were less
integrated until relatively recently).

Cheers,

Dirkjan
Permalink | Reply | 1 comment |
headers
Kent Fredric | 1 Jun 2012 10:40
Picon
Gravatar

Re: Re: Portage Git migration - clean cut or git-cvsserver

On 1 June 2012 20:16, Dirkjan Ochtman <djc <at> gentoo.org> wrote:
> Can you elaborate on why the cleaner history a no-merge policy
> enforces is a good thing? I actually think that seeing merge commits
> might clarify the history; it can be valuable to see that some mistake
> was made in a merge instead, but you can only see that if there's an
> explicit merge commit.
>
> I should note that I come at this from the Mercurial side, where the
> immutability of (public) history has historically carried more value
> than on the git side (and related to that, rebase-like tools were less
> integrated until relatively recently).
>
> Cheers,
>
> Dirkjan
>

One of the perk of fast-forward only histories is merge problems don't happen.

If a commit sequence isn't fast-fowardable, then the submitter has to
rebase it, and a rebased history is a guaranteed clean merge.

It also puts the onus on making the patch sequence mergable on the
contributor of that patch sequence, by forcing them to resolve
conflicts before they can submit their branch for inclusion, and this
is good, because they understand their own changes best, and are the
best person to decide how to deal with conflicts.

The best example of this is 2 people contribute behaviourally
identical code, with different syntax .
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samuli Suominen | 1 Jun 2012 12:02
Picon
Favicon

lastrite x11-terms/cxterm

# Samuli Suominen <ssuominen <at> gentoo.org> (01 Jun 2012)
# Fails to run with font issues wrt bug 418259
# Last release was back in 2003
# Removal in 30 days
x11-terms/cxterm
Permalink | Reply | 0 comments |
headers
Rich Freeman | 1 Jun 2012 12:49
Picon
Favicon
Gravatar

Re: Re: Portage Git migration - clean cut or git-cvsserver

On Fri, Jun 1, 2012 at 12:05 AM, Michał Górny <mgorny <at> gentoo.org> wrote:
> Yes, it isn't but such kind of work flow was presented in the message I
> replied to.

Yup, I wasn't aware that when rebasing you have the option to squash
commits or not.  They all get rewritten as if they were applied to the
current head in the first place, but apparently unless you squash them
you still get all the individual commits.

Rich
Permalink | Reply | 0 comments |
headers
Rich Freeman | 1 Jun 2012 12:54
Picon
Favicon
Gravatar

Re: Re: Portage Git migration - clean cut or git-cvsserver

On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric <kentfredric <at> gmail.com> wrote:
>
> Hmm, thats annoying. Almost makes me wish it was the trees that were
> signed, not the commits.

I think it is the tree that is signed, but that changes too.

Rebasing re-applies the same diff to the new head to give you a new
set of commits.  When you apply the same diff to a different parent
you end up with a different tree, so the tree signature won't be the
same either.

Keep in mind that git does not store a long train of diffs.  It stores
a long chain of complete trees, and the diffs get calculated if you
ask for them.  Since it is COW you only re-store files that actually
change, and incorporate others by reference.  However, if you have a
1MB file that you change 1 line on 100x, you'll end up with 100MB of
files.  Of course, when they get packed I'd hope that they'd compress
well.

Rich
Permalink | Reply | 16 comments |
headers
Kent Fredric | 1 Jun 2012 13:23
Picon
Gravatar

Re: Re: Portage Git migration - clean cut or git-cvsserver

On 1 June 2012 22:54, Rich Freeman <rich0 <at> gentoo.org> wrote:
> On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric <kentfredric <at> gmail.com> wrote:
>>
>> Hmm, thats annoying. Almost makes me wish it was the trees that were
>> signed, not the commits.
>
> I think it is the tree that is signed, but that changes too.

Nope, at least not as far as I can tell, and I just implemented commit
signature verification >_>

> Rebasing re-applies the same diff to the new head to give you a new
> set of commits.  When you apply the same diff to a different parent
> you end up with a different tree, so the tree signature won't be the
> same either.

Not nessecarily. Given that :

 a file with a given content has a fixed SHA
A tree is just a list of these SHA's , and that in turn is referenced
by SHA, so if 2 commits have identical file content, their 'tree' sha
will be the same ( in theory ).

So that means, if you perform a rebase, assuming the filesystem looks
the same as it did before the rebase, it will have the same SHA1 for
the tree, regardless of the process of how it got to be that way.

The only SHA that has to change is the 'parent',

( Demonstration here: https://gist.github.com/2851330 , note I have 2
(Continue reading)

Permalink | Reply | 15 comments |

Gmane