Rebasing core-updates-next branch

Rebasing core-updates-next branch

[Manolis Ragkousis]

Hello Guix,

Core-updates-next has not been updated for some time so I think it's
time to do that.  I was planning to rebase core-updates-next on
core-updates and create a new core-updates-next.

There is a problem though. Rebasing changes the pgp signature of the
commit. The affected commits are the ones below.

a08539d gnu: guile: Use "site-ccache" for the compiled search path.
14af4d1 build: Correctly determine the system type for GNU/Hurd systems.
5b32f07 gnu: wrap-python3: Create more symlinks.
788eb97 gnu: sqlite: Update to 3.13.0.
bd46fdc utils: Fix 'modify-phases' docstring.
d35bc36 gnu: curl: Update to 7.49.1.
98e8dc6 packages: Use '--no-backup-if-mismatch' for patching.

I have cc'ed the authors of those commits.  If you are okay with it, I
will sign those commits with my key and push the new core-udpates-next.

Thank you,
Manolis

Re: Rebasing core-updates-next branch

[Leo Famulari]

On Mon, Jul 11, 2016 at 04:01:36PM +0300, Manolis Ragkousis wrote:
> d35bc36 gnu: curl: Update to 7.49.1.

You can re-sign this commit.

> I have cc'ed the authors of those commits.  If you are okay with it, I
> will sign those commits with my key and push the new core-udpates-next.

This situation is not ideal. We should think of a better way.

Re: Rebasing core-updates-next branch

[Ben Woodcroft]

On 11/07/16 23:01, Manolis Ragkousis wrote:
> Hello Guix,
>
> Core-updates-next has not been updated for some time so I think it's
> time to do that.  I was planning to rebase core-updates-next on
> core-updates and create a new core-updates-next.
>
> There is a problem though. Rebasing changes the pgp signature of the
> commit. The affected commits are the ones below.
[..]
> 788eb97 gnu: sqlite: Update to 3.13.0.

Please do.

As a general solution, can we differentiate between author and committer 
in git?
ben

Re: Rebasing core-updates-next branch

[Leo Famulari]

On Tue, Jul 12, 2016 at 02:45:30PM +1000, Ben Woodcroft wrote:
> As a general solution, can we differentiate between author and committer in
> git?

Yes. You can pass '--format=full' to `git show` or `git log` to see it.
There is surely a lower-level way to get the information too.

But, you can make the fields say anything by changing the value of
'user.name' and 'user.email' in '.git/config' or by setting
GIT_AUTHOR_NAME and GIT_COMMITTER_NAME. See the man page git-config(1).

Re: Rebasing core-updates-next branch

[Ricardo Wurmus]

Manolis Ragkousis <manolis837@gmail.com> writes:

> Hello Guix,
>
> Core-updates-next has not been updated for some time so I think it's
> time to do that.  I was planning to rebase core-updates-next on
> core-updates and create a new core-updates-next.
>
> There is a problem though. Rebasing changes the pgp signature of the
> commit. The affected commits are the ones below.

Do we need to rebase?  Is a merge not possible?

~~ Ricardo

Re: Rebasing core-updates-next branch

[Alex Kost]

Manolis Ragkousis (2016-07-11 16:01 +0300) wrote:

> Hello Guix,
>
> Core-updates-next has not been updated for some time so I think it's
> time to do that.  I was planning to rebase core-updates-next on
> core-updates and create a new core-updates-next.

Is there a reason for this?  Are you going to commit something there
that needs to be based on core-updates?  If it's just the "time to do
that", then I think it's not really needed.

> There is a problem though. Rebasing changes the pgp signature of the
> commit. The affected commits are the ones below.
>
> a08539d gnu: guile: Use "site-ccache" for the compiled search path.
> 14af4d1 build: Correctly determine the system type for GNU/Hurd systems.
> 5b32f07 gnu: wrap-python3: Create more symlinks.
> 788eb97 gnu: sqlite: Update to 3.13.0.
> bd46fdc utils: Fix 'modify-phases' docstring.
> d35bc36 gnu: curl: Update to 7.49.1.
> 98e8dc6 packages: Use '--no-backup-if-mismatch' for patching.
>
> I have cc'ed the authors of those commits.  If you are okay with it, I
> will sign those commits with my key and push the new core-udpates-next.

I'm absolutely OK with it, do whatever seems appropriate to you.

-- 
Alex

Re: Rebasing core-updates-next branch

[Manolis Ragkousis]

Hello,

On 07/12/16 10:29, Alex Kost wrote:
> Is there a reason for this?  Are you going to commit something there
> that needs to be based on core-updates?  If it's just the "time to do
> that", then I think it's not really needed.

Yes my work is based on commits from core-updates and in order to push
Hurd related patches to core-updates-next I need to update it.

On 07/12/16 09:04, Ricardo Wurmus wrote:
> Do we need to rebase?  Is a merge not possible?
>

It's definitely possible but I agree with Ludo on this. It's better to
avoid unnecessary merge commits.

Btw I just noticed that commit bd46fdc is not signed by anyone. How
should I handle this one?

Thank you,
Manolis

Re: Rebasing core-updates-next branch

[Leo Famulari]

On Tue, Jul 12, 2016 at 03:57:34PM +0300, Manolis Ragkousis wrote:
> On 07/12/16 09:04, Ricardo Wurmus wrote:
> > Do we need to rebase?  Is a merge not possible?
> 
> It's definitely possible but I agree with Ludo on this. It's better to
> avoid unnecessary merge commits.

Merges *are* ugly but, in general, I think they are better than
discarding the signatures.

Re: Rebasing core-updates-next branch

[Ludovic Courtès]

Hi!

Manolis Ragkousis <manolis837@gmail.com> skribis:

> Core-updates-next has not been updated for some time so I think it's
> time to do that.  I was planning to rebase core-updates-next on
> core-updates and create a new core-updates-next.
>
> There is a problem though. Rebasing changes the pgp signature of the
> commit. The affected commits are the ones below.
>
> a08539d gnu: guile: Use "site-ccache" for the compiled search path.
> 14af4d1 build: Correctly determine the system type for GNU/Hurd systems.
> 5b32f07 gnu: wrap-python3: Create more symlinks.
> 788eb97 gnu: sqlite: Update to 3.13.0.
> bd46fdc utils: Fix 'modify-phases' docstring.
> d35bc36 gnu: curl: Update to 7.49.1.
> 98e8dc6 packages: Use '--no-backup-if-mismatch' for patching.
>
> I have cc'ed the authors of those commits.  If you are okay with it, I
> will sign those commits with my key and push the new core-udpates-next.

Fine with me!

Ricardo Wurmus <rekado@elephly.net> skribis:

> Do we need to rebase?  Is a merge not possible?

I like to avoid unnecessary merge commits, but I could go either way in
this case.  I guess you’d prefer merging?

Thanks,
Ludo’.

Re: Rebasing core-updates-next branch

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi!
>
> Manolis Ragkousis <manolis837@gmail.com> skribis:
>
>> Core-updates-next has not been updated for some time so I think it's
>> time to do that.  I was planning to rebase core-updates-next on
>> core-updates and create a new core-updates-next.
>>
>> There is a problem though. Rebasing changes the pgp signature of the
>> commit. The affected commits are the ones below.
>>
>> a08539d gnu: guile: Use "site-ccache" for the compiled search path.
>> 14af4d1 build: Correctly determine the system type for GNU/Hurd systems.
>> 5b32f07 gnu: wrap-python3: Create more symlinks.
>> 788eb97 gnu: sqlite: Update to 3.13.0.
>> bd46fdc utils: Fix 'modify-phases' docstring.
>> d35bc36 gnu: curl: Update to 7.49.1.
>> 98e8dc6 packages: Use '--no-backup-if-mismatch' for patching.
>>
>> I have cc'ed the authors of those commits.  If you are okay with it, I
>> will sign those commits with my key and push the new core-udpates-next.
>
> Fine with me!
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Do we need to rebase?  Is a merge not possible?
>
> I like to avoid unnecessary merge commits, but I could go either way in
> this case.  I guess you’d prefer merging?

Either way is fine by me (and my commits are not affected here).  I just
think that it’s a bit unfortunate to throw away signatures.

~~ Ricardo