Hi Developers,
Just a heads up. I rebased the inkscape-web git repository on GitLab to sort out problems with it's cherry picks.
This took 2 hours of picking through the rebasing as some of it could be automated. So I had to manually merge about two hundred of the 1600 commits to get it working.
Not sure if this will bite the inkscape git repository some time in the future. But being aware of the non-linear repository created by a migration from bzr.
Best Regards, Martin Owens
On Sat, Jan 28, 2017 at 12:04:40AM -0500, Martin Owens wrote:
Hi Developers,
Just a heads up. I rebased the inkscape-web git repository on GitLab to sort out problems with it's cherry picks.
This took 2 hours of picking through the rebasing as some of it could be automated. So I had to manually merge about two hundred of the 1600 commits to get it working.
That sounds frustrating.
Can you explain in more detail what the issue was, so we know what to avoid?
Bryce
Not sure if this will bite the inkscape git repository some time in the future. But being aware of the non-linear repository created by a migration from bzr.
Best Regards, Martin Owens
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 2017-01-27 at 21:18 -0800, Bryce Harrington wrote:
That sounds frustrating.
Can you explain in more detail what the issue was, so we know what to avoid?
It's about how the modifications are recorded as merges. Git has this option of making the history all nice and flat, i.e. a rebase. I needed to use it because Moini's commits had caused 90% of the history to be doubled, basically making the repository broken.
So as long as you never ever have to touch the history once it's made, it might be ok. But other git experts would be good.
Martin,
2017-01-28 6:31 GMT+01:00 Martin Owens <doctormo@...400...>:
On Fri, 2017-01-27 at 21:18 -0800, Bryce Harrington wrote:
That sounds frustrating.
Can you explain in more detail what the issue was, so we know what to avoid?
It's about how the modifications are recorded as merges. Git has this option of making the history all nice and flat, i.e. a rebase. I needed to use it because Moini's commits had caused 90% of the history to be doubled, basically making the repository broken.
So as long as you never ever have to touch the history once it's made, it might be ok. But other git experts would be good.
Martin,
So due to the migration from bzr to git a lot of commits in bzr turned into "a commit" + "a merge" in git? Is this what you mean with "doubled"?
Is the old repository still available somewhere and could be uploaded for comparison, before and after?
On Sat, 2017-01-28 at 09:44 +0100, Christoffer Holmstedt wrote:
2017-01-28 6:31 GMT+01:00 Martin Owens <doctormo@...400...>:
On Fri, 2017-01-27 at 21:18 -0800, Bryce Harrington wrote:
That sounds frustrating.
Can you explain in more detail what the issue was, so we know
what to
avoid?
It's about how the modifications are recorded as merges. Git has this option of making the history all nice and flat, i.e. a rebase. I needed to use it because Moini's commits had caused 90% of the history to be doubled, basically making the repository broken.
So as long as you never ever have to touch the history once it's made, it might be ok. But other git experts would be good.
Martin,
So due to the migration from bzr to git a lot of commits in bzr turned into "a commit" + "a merge" in git? Is this what you mean with "doubled"?
No, or at least, almost certain.
Is the old repository still available somewhere and could be uploaded for comparison, before and after?
Yes, Ubik made a fork before I clobbered it:
https://gitlab.com/ubik/inkscape-web
See 3,061 commits vs. 1,677
Martin,
2017-01-28 15:25 GMT+01:00 Martin Owens <doctormo@...400...>:
On Sat, 2017-01-28 at 09:44 +0100, Christoffer Holmstedt wrote:
2017-01-28 6:31 GMT+01:00 Martin Owens <doctormo@...400...>:
On Fri, 2017-01-27 at 21:18 -0800, Bryce Harrington wrote:
That sounds frustrating.
Can you explain in more detail what the issue was, so we know
what to
avoid?
It's about how the modifications are recorded as merges. Git has this option of making the history all nice and flat, i.e. a rebase. I needed to use it because Moini's commits had caused 90% of the history to be doubled, basically making the repository broken.
So as long as you never ever have to touch the history once it's made, it might be ok. But other git experts would be good.
Martin,
So due to the migration from bzr to git a lot of commits in bzr turned into "a commit" + "a merge" in git? Is this what you mean with "doubled"?
No, or at least, almost certain.
Is the old repository still available somewhere and could be uploaded for comparison, before and after?
Yes, Ubik made a fork before I clobbered it:
https://gitlab.com/ubik/inkscape-web
See 3,061 commits vs. 1,677
Martin,
Thanks for the link. I've never seen anything like that before, git commits with the same content but different hashes in different branches. Still a bit confused on what have actually happened.
Am Samstag, 28. Januar 2017, 00:31:59 CET schrieb Martin Owens:
On Fri, 2017-01-27 at 21:18 -0800, Bryce Harrington wrote:
That sounds frustrating.
Can you explain in more detail what the issue was, so we know what to avoid?
It's about how the modifications are recorded as merges. Git has this option of making the history all nice and flat, i.e. a rebase. I needed to use it because Moini's commits had caused 90% of the history to be doubled, basically making the repository broken.
So as long as you never ever have to touch the history once it's made, it might be ok. But other git experts would be good.
Just a general remark: Once git is used for real in Inkscape you should never ever rebase anything that was pushed already. Having a nice flat history isn't something to strive for with git.
Further reading: https://stackoverflow.com/questions/2715085/rebasing-and-what-does-one-mean-...
Martin,
Tobias
Am 28.01.2017 um 06:31 schrieb Martin Owens:
On Fri, 2017-01-27 at 21:18 -0800, Bryce Harrington wrote:
That sounds frustrating.
Can you explain in more detail what the issue was, so we know what to avoid?
It's about how the modifications are recorded as merges. Git has this option of making the history all nice and flat, i.e. a rebase. I needed to use it because Moini's commits had caused 90% of the history to be doubled, basically making the repository broken.
So as long as you never ever have to touch the history once it's made, it might be ok. But other git experts would be good.
Martin,
Do I understand correctly, that you re-wrote history and Maren merged her branch which was based on a former checkout with the original history? In that case it's not surprising you'll have the original history and your re-written history side-by-side.
However this could have probably been fixed by simply rebasing Maren's changes on the then latest version of the repository.
In either case this should not happen during "normal" operation, right? Rewriting history is an absolute no-go for public repositories (which is why we have append-only branches in Bazaar) and once the migration is complete I hope nobody will ever fiddle with history again.
Regards, Eduard
On Sat, 2017-01-28 at 12:53 +0100, Eduard Braun wrote:
Do I understand correctly, that you re-wrote history and Maren merged her branch which was based on a former checkout with the original history? In that case it's not surprising you'll have the original history and your re-written history side-by-side.
However this could have probably been fixed by simply rebasing Maren's changes on the then latest version of the repository.
No, the history needed to be rewritten because Maren had a bad email address that could exist on yahoo but which didn't. So it changed, but in doing so it interacted with origin and duplicated the history instead of over-writing it.
In either case this should not happen during "normal" operation, right? Rewriting history is an absolute no-go for public repositories (which is why we have append-only branches in Bazaar) and once the migration is complete I hope nobody will ever fiddle with history again.
That's right. I don't expect it to do this often (or at all). There is an option in GitLab to select rebasing or merging as the preferred method, but merging should be ok for us. Default branches in projects are protected anyway, although not against duplicate merges.
Good to know from other git users that this is super rare.
Best Regards, Martin Owens
Am Samstag, 28. Januar 2017, 09:21:02 CET schrieb Martin Owens:
[...]
No, the history needed to be rewritten because Maren had a bad email address that could exist on yahoo but which didn't. So it changed, but in doing so it interacted with origin and duplicated the history instead of over-writing it.
That poses two questions:
1) Why do you care what old email address there is in commit info?
2) Provided you care, do you know about .mailmap? https://stacktoheap.com/blog/2013/01/06/using-mailmap-to-fix-authors-list-in...
[...]
Best Regards, Martin Owens
Tobias
On Sat, Jan 28, 2017 at 04:12:29PM +0100, Tobias Ellinghaus wrote:
Am Samstag, 28. Januar 2017, 09:21:02 CET schrieb Martin Owens:
[...]
No, the history needed to be rewritten because Maren had a bad email address that could exist on yahoo but which didn't. So it changed, but in doing so it interacted with origin and duplicated the history instead of over-writing it.
That poses two questions:
Why do you care what old email address there is in commit info?
Provided you care, do you know about .mailmap?
https://stacktoheap.com/blog/2013/01/06/using-mailmap-to-fix-authors-list-in...
[...]
Yep, thanks, I was going to suggest considering .mailmap for needs like this.
Anyway, so my question is should the bzr->git be redone or is the inkscape_web on gitlab now okay? (If there are still any problems, it's going to be easier to redo things sooner rather than later I'm betting.)
Bryce
Best Regards, Martin Owens
Tobias
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEECoi7y9N/7kPOsTdimNQuWstUSOgFAliMtN0ACgkQmNQuWstU SOi7NRAAvhopRkka8UBiaSWNINqn/PKhx2XnKy3EQhk6JBB2QRG7BIti6JWNhhnd LAO41ALPqiqhW5IbqjtvyLvxluhD+MwBrV781/guYgzHqL3K1ILkcjfSNevsChEv FBZl2RBecxBx5owAZig6yB+c73tgUIt7OzaiLh5kC521PQMjXTEUVQYbP5neNbVi 81tLoAxWhmmlrmwIHd+zvpotSQn5Uvx4mYkDhxj7t+mAyY/yG/IVME9eeSTpUKpJ iF/wbqdcKKuq2UzKhCnTMN1/CmgKuXFkLmkQlETHu2eJbJeqqeG6T4SOIowUauLT uqc5INmhXEaEJJoAlE0MpMCJCBqjGGpuhnUFUKqcwQZZblppvr6xhkNRKynxOEQz GISo2cTiXQXD8ZI1hVzo+9jcR7v20F4mF6GwrUUTOJ8VQhc9tyhmodbtD2/PPSba VnLkB6jD4X5okVhfuKFfrvqHnuXPK5y8u7B/kWbTLRBHSgobEVpOR5Q1WjAqZRFa TLjAjO6jF44BwSn/u44mkwyX3jJPKx58U5FBpFPkeYE53xUvu2ADNBSE++v52CVh qX32RDbfoNMB/ulEx5Taisx2w61XFAUf6r6hbSmkIzIVGUOVllolcAAak9bdhAIQ nDGXibWlKtIRUaBes81cgRavYHo6JsBALxvJQPr87xxQv8LqAiU= =8Rv0 -----END PGP SIGNATURE-----
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2017-01-28 23:38 GMT+01:00 Bryce Harrington <bryce@...961...>:
On Sat, Jan 28, 2017 at 04:12:29PM +0100, Tobias Ellinghaus wrote:
Am Samstag, 28. Januar 2017, 09:21:02 CET schrieb Martin Owens:
[...]
No, the history needed to be rewritten because Maren had a bad email address that could exist on yahoo but which didn't. So it changed, but in doing so it interacted with origin and duplicated the history instead of over-writing it.
That poses two questions:
Why do you care what old email address there is in commit info?
Provided you care, do you know about .mailmap?
fix-authors-list-in-git/
[...]
Yep, thanks, I was going to suggest considering .mailmap for needs like this.
Anyway, so my question is should the bzr->git be redone or is the inkscape_web on gitlab now okay? (If there are still any problems, it's going to be easier to redo things sooner rather than later I'm betting.)
Bryce
Best Regards, Martin Owens
Tobias
From my point of view inkscape-web [1] looks okay, the discussion is more
of a "lessons learned" before the inkscape source code is migrated.
[1] https://gitlab.com/inkscape/inkscape-web/network/master
On Sun, Jan 29, 2017 at 02:03:36PM +0100, Christoffer Holmstedt wrote:
2017-01-28 23:38 GMT+01:00 Bryce Harrington <bryce@...961...>:
On Sat, Jan 28, 2017 at 04:12:29PM +0100, Tobias Ellinghaus wrote:
Am Samstag, 28. Januar 2017, 09:21:02 CET schrieb Martin Owens:
[...]
No, the history needed to be rewritten because Maren had a bad email address that could exist on yahoo but which didn't. So it changed, but in doing so it interacted with origin and duplicated the history instead of over-writing it.
That poses two questions:
Why do you care what old email address there is in commit info?
Provided you care, do you know about .mailmap?
fix-authors-list-in-git/
[...]
Yep, thanks, I was going to suggest considering .mailmap for needs like this.
Anyway, so my question is should the bzr->git be redone or is the inkscape_web on gitlab now okay? (If there are still any problems, it's going to be easier to redo things sooner rather than later I'm betting.)
Bryce
Best Regards, Martin Owens
Tobias
From my point of view inkscape-web [1] looks okay, the discussion is more
of a "lessons learned" before the inkscape source code is migrated.
[1] https://gitlab.com/inkscape/inkscape-web/network/master
-- Christoffer Holmstedt
Okay, great, I hadn't noticed problems on a cursory look at the history, but wasn't sure if I was missing something.
I recall you've spoken of using lp2gh; have you or do you know if anyone's recently tried a testrun of it against the Inkscape codebase itself? Would be nice to know of any potential troublespots that we could start looking into.
Thanks, Bryce
On Sun, 2017-01-29 at 09:38 -0800, Bryce Harrington wrote:
I recall you've spoken of using lp2gh; have you or do you know if anyone's recently tried a testrun of it against the Inkscape codebase itself? Would be nice to know of any potential troublespots that we could start looking into.
I've spent a couple of weeks on and off hacking into lp2gh to turn it into something we can use for gitlab. If anyone wants to see/help I'll put the code online.
Best Regards, Martin Owens
participants (5)
-
Bryce Harrington -
Christoffer Holmstedt -
Eduard Braun -
Martin Owens -
Tobias Ellinghaus