Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #10900 > unrolled thread

[Debian PAPT] Question about salsa repo and packaging

Back to article view | Back to linux.debian.maint.python

Contents

  [Debian PAPT] Question about salsa repo and packaging Hilmar Preuße <hille42@web.de> - 2018-09-15 17:50 +0200
    Re: [Debian PAPT] Question about salsa repo and packaging Sergio Durigan Junior <sergiodj@debian.org> - 2018-09-16 07:40 +0200
      Re: [Debian PAPT] Question about salsa repo and packaging Elena ``of Valhalla'' <valhalla-d@trueelena.org> - 2018-09-16 09:10 +0200
        Re: [Debian PAPT] Question about salsa repo and packaging Sergio Durigan Junior <sergiodj@debian.org> - 2018-09-16 19:00 +0200
      Re: [Debian PAPT] Question about salsa repo and packaging Hilmar Preuße <hille42@web.de> - 2018-09-22 21:10 +0200

#10900 — [Debian PAPT] Question about salsa repo and packaging

Hi,

I'm maintaining the package rubber in the PAPT. I have a few question:

1. I'd like to revert some changes to the salsa repo for my package, as
these changes were never uploaded to Debian and are not superseded by
new upstream package. Is it OK to do a "git reset --hard xxxx" to make
them disappear in my repository?

2. My repo contains a stale branch called "svn". It was created during
the git -> salsa migration. AFAICT this branch contains obsolete
versions of some files. May I kill that branch?

3. Recently I imported a new upstream version. According to [1] I should
rebase my patches. Unfortunately this fails:

<snip>
hille@sid:~/devel/rubber/rubber.git $ gbp pq rebase
gbp:info: Switching to 'patch-queue/debian/master'
First, rewinding head to replay your work on top of it...
Applying: more accurate log messages when deciding whether to rebuild
some file
Using index info to reconstruct a base tree...
M	src/depend.py
Falling back to patching base and 3-way merge...
Auto-merging src/depend.py
CONFLICT (content): Merge conflict in src/depend.py
error: Failed to merge in the changes.
Patch failed at 0001 more accurate log messages when deciding whether to
rebuild some file
hint: Use 'git am --show-current-patch' to see the failed patch

Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase
--abort".

gbp:error: Couldn't run git rebase: it exited with 128
<snip>

Could anybody give me a hint, what it wrong here?

Many thanks!

Hilmar

[1] https://wiki.debian.org/Python/GitPackaging#New_upstream_release
-- 
sigfault
#206401 http://counter.li.org

[toc] | [next] | [standalone]

#10901

[Multipart message — attachments visible in raw view] — view raw

On Saturday, September 15 2018, Hilmar Preuße wrote:

> Hi,

Hey,

> I'm maintaining the package rubber in the PAPT. I have a few question:
>
> 1. I'd like to revert some changes to the salsa repo for my package, as
> these changes were never uploaded to Debian and are not superseded by
> new upstream package. Is it OK to do a "git reset --hard xxxx" to make
> them disappear in my repository?

You mean do a "git reset --hard" locally and then "git push" the
modified history?  This is not ideal, but if you're the only one using
the repository, and if there was no Debian release containing the code
you're reverting, then I'd say it's OK.

> 2. My repo contains a stale branch called "svn". It was created during
> the git -> salsa migration. AFAICT this branch contains obsolete
> versions of some files. May I kill that branch?

Sorry, I don't the answer to this one.

> 3. Recently I imported a new upstream version. According to [1] I should
> rebase my patches. Unfortunately this fails:
>
> <snip>
> hille@sid:~/devel/rubber/rubber.git $ gbp pq rebase
> gbp:info: Switching to 'patch-queue/debian/master'
> First, rewinding head to replay your work on top of it...
> Applying: more accurate log messages when deciding whether to rebuild
> some file
> Using index info to reconstruct a base tree...
> M	src/depend.py
> Falling back to patching base and 3-way merge...
> Auto-merging src/depend.py
> CONFLICT (content): Merge conflict in src/depend.py
> error: Failed to merge in the changes.
> Patch failed at 0001 more accurate log messages when deciding whether to
> rebuild some file
> hint: Use 'git am --show-current-patch' to see the failed patch
>
> Resolve all conflicts manually, mark them as resolved with
> "git add/rm <conflicted_files>", then run "git rebase --continue".
> You can instead skip this commit: run "git rebase --skip".
> To abort and get back to the state before "git rebase", run "git rebase
> --abort".
>
> gbp:error: Couldn't run git rebase: it exited with 128
> <snip>
>
> Could anybody give me a hint, what it wrong here?

While rebasing the patch-queue, there was a conflict with one of the
files.  A conflict happens when you have two distinct versions of the
same file containing modifications that are not trivial to be
automatically merged by git.  The conflict is marked above as:

  CONFLICT (content): Merge conflict in src/depend.py

You now have to resolve this conflict before proceeding.  Basically,
open the file and look for the conflict markers, which look like:

  <<<<<<< HEAD
  some content
  =======
  some other content
  >>>>>>> some-branch

You will then have to decide how to resolve this, either by deleting one
of the changes, or by adapting them, etc.  Once you resolve all of the
conflicts, you will be able to perform a "git rebase --continue".  Note
that you may encounter many conflicts while rebasing.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

[toc] | [prev] | [next] | [standalone]

#10902

[Multipart message — attachments visible in raw view] — view raw

On 2018-09-16 at 01:32:05 -0400, Sergio Durigan Junior wrote:
> > 1. I'd like to revert some changes to the salsa repo for my package, as
> > these changes were never uploaded to Debian and are not superseded by
> > new upstream package. Is it OK to do a "git reset --hard xxxx" to make
> > them disappear in my repository?
> 
> You mean do a "git reset --hard" locally and then "git push" the
> modified history?  This is not ideal, but if you're the only one using
> the repository, and if there was no Debian release containing the code
> you're reverting, then I'd say it's OK.

can one be sure that nobody else is using the repository? maybe nobody
in debian, but what about our derivatives? or even our users

if there is a strong need to remove those changes (e.g. for copyright
reasons) I agree that a reset --hard is a reasonable option, but if it's
just to keep the repo clean my personal preference would be for a ``git
revert`` that doesn't break the repo for other users.

-- 
Elena ``of Valhalla''

[toc] | [prev] | [next] | [standalone]

#10904

[Multipart message — attachments visible in raw view] — view raw

On Sunday, September 16 2018, Elena wrote:

> On 2018-09-16 at 01:32:05 -0400, Sergio Durigan Junior wrote:
>> > 1. I'd like to revert some changes to the salsa repo for my package, as
>> > these changes were never uploaded to Debian and are not superseded by
>> > new upstream package. Is it OK to do a "git reset --hard xxxx" to make
>> > them disappear in my repository?
>> 
>> You mean do a "git reset --hard" locally and then "git push" the
>> modified history?  This is not ideal, but if you're the only one using
>> the repository, and if there was no Debian release containing the code
>> you're reverting, then I'd say it's OK.
>
> can one be sure that nobody else is using the repository? maybe nobody
> in debian, but what about our derivatives? or even our users
>
> if there is a strong need to remove those changes (e.g. for copyright
> reasons) I agree that a reset --hard is a reasonable option, but if it's
> just to keep the repo clean my personal preference would be for a ``git
> revert`` that doesn't break the repo for other users.

I understand and agree with your comment, but it seems like his commits
are pretty recent.  As I said, overwitting history is never ideal, but
under specific circumstances I think it's "ok-ish".

But sure, if you're comfortable with using "git revert", then by all
means, go ahead.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

[toc] | [prev] | [next] | [standalone]

#10929

On 16.09.2018 07:32, Sergio Durigan Junior wrote:
> On Saturday, September 15 2018, Hilmar Preuße wrote:

Hi,

>> I'm maintaining the package rubber in the PAPT. I have a few question:
>>
>> 1. I'd like to revert some changes to the salsa repo for my package, as
>> these changes were never uploaded to Debian and are not superseded by
>> new upstream package. Is it OK to do a "git reset --hard xxxx" to make
>> them disappear in my repository?
> 
> You mean do a "git reset --hard" locally and then "git push" the
> modified history?  This is not ideal, but if you're the only one using
> the repository, and if there was no Debian release containing the code
> you're reverting, then I'd say it's OK.
> 
I now deciced to use revert and it is OK for me. Thanks for the hint!

>> 3. Recently I imported a new upstream version. According to [1] I should
>> rebase my patches. Unfortunately this fails:
>>
>> Could anybody give me a hint, what it wrong here?
> 
> While rebasing the patch-queue, there was a conflict with one of the
> files.  A conflict happens when you have two distinct versions of the
> same file containing modifications that are not trivial to be
> automatically merged by git.  The conflict is marked above as:
> 
>   CONFLICT (content): Merge conflict in src/depend.py
> 
> You now have to resolve this conflict before proceeding.  Basically,
> open the file and look for the conflict markers, which look like:
> 
For any reason the phenomenon is gone now. One of my patches was
updated, during rebase.

Hilmar
-- 
sigfault
#206401 http://counter.li.org

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web