Re: [Debian PAPT] Question about salsa repo and packaging
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 " 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
Re: [Debian PAPT] Question about salsa repo and packaging
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 " 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/ signature.asc Description: PGP signature
Re: [Debian PAPT] Question about salsa repo and packaging
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 " 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'' signature.asc Description: PGP signature
Re: [Debian PAPT] Question about salsa repo and packaging
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 " 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: > > > 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 ", 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 > > > 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/ smime.p7s Description: S/MIME cryptographic signature
[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 " 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: 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 ", 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 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
