[10:50] <anonym> hi
[10:53] <anonym> hello all
[11:07] <jelmer> hi anonym
[15:04] <serg> I'd like to discuss a patch/fix for https://bugs.launchpad.net/bzr-git/+bug/351317
[15:05] <serg> it shows no activity since 2010, so I'd rather ask here
[15:05] <serg> anyone?
[15:13] <jelmer> serg: hi
[15:13] <serg> hi
[15:14] <jelmer> serg: I can offer some opinions on that bug :-)
[15:14] <serg> so, at the moment I'm mainly interested to know the problems that my suggested solutions might have
[15:14] <serg> thanks
[15:15]  * jelmer looks at the patch
[15:15] <jelmer> serg: it looks like you're basically adding the revision id that the path was introduced in?
[15:15] <serg> yes
[15:15] <serg> exactly
[15:16] <serg> it makes file ids unique
[15:16] <serg> and stable
[15:16] <serg> in the sence that one can fork, merge, uncommit/pull, etc
[15:16] <serg> and file ids won't change
[15:16] <serg> probably even roundtripping will work
[15:16] <serg> but I personally don't need it
[15:17] <serg> one can also rename files in the bzr repo (branched from git)
[15:17] <serg> that will work too
[15:17] <jelmer> serg: this breaks renames
[15:17] <jelmer> serg: so, for the basic case this approach works well I think
[15:17] <jelmer> there a couple of issues that I can see:
[15:17] <jelmer> - it breaks all existing bzr-git imports
[15:18] <serg> sure, I understand that
[15:18] <jelmer> - it's quite common in git to have multiple additions of the same file done independently ("parallel imports"). This makes it impossible to merge those with bzr (since they'll have different file ids)
[15:19] <serg> what does "multiple additions of the same file done independently" mean?
[15:19] <jelmer> - this breaks renames (though no worse than before) - once you push the renamed file into git it'll get a new file id when you pull it back into bzr
[15:20] <jelmer> serg: if I work on a branch that's based on a release tarball, the files in that branch will have a different file id than the upstream branch.
[15:21] <serg> was that a feature? that users can create a branch from a release tarball? it never worked in bzr, I didn't expect people to do that in any vcs
[15:22] <serg> but okay
[15:22] <jelmer> serg: it doesn't work in bzr because of file ids, but it works particularly well in git
[15:22] <serg> this can never work with any stable bzr-like file ids, for this feature to work one must track files by names
[15:23] <jelmer> serg: right, this was one of the reasons we were looking at path tokens (an alternative to file ids)
[15:25] <serg> okay. so if my approach kind of works for my usage pattern (I understand, you agreed with it), I can keep a private branch of bzr git. But because of migration issues and this "tarball" git feature, this my patch can never be the only bzr-git behavior. now, the last question
[15:25] <jelmer> serg: I posted some thoughts here: https://lists.ubuntu.com/archives/bazaar/2011q2/072368.html
[15:26] <serg> jelmer: if you'd like I can polish it a bit and add as an option, so that one can enable it, say, per-branch
[15:26] <serg> fixing what can be fixed, and keeping fundamental issues up to the user's decision
[15:27] <jelmer> serg: note that it breaks the testsuite at the moment
[15:27] <jelmer> serg: I think it would be reasonable to have it as an optional thing
[15:27] <serg> sure, if you'll want to make it generally usable, I'll fix the test suite
[15:27] <jelmer> serg: there is actually already a config variable you can use to set the bzr-git mapping method for a branch
[15:28] <serg> I must've missed it, I did look. sorry :)
[15:28] <jelmer> serg: I think it would be reasonable to have as a patch; nobody is maintaining bzr-git at the moment though
[15:29] <serg> my use case is to pull various mysql/mariadb extensions into mariadb tree. not pushing back though
[15:29] <serg> okay, thanks. I'll try to fix the patch, then
[15:29] <jelmer> serg: that's from git into bzr or the other way around?
[15:30] <serg> mariadb is in bzr
[15:30] <serg> extensions - in bzr or git
[15:30] <serg> from git into bzr. from many trees into one
[15:31] <jelmer> ah, I see
[15:33] <jelmer> serg: I don't actually see the option for overriding the mapping anymore; it might have been removed at some point.
[15:33] <serg> no problem, now that you've mentioned it, I can dig it up in the history, and hopefully the comment will explain why it was removed
[15:40] <jelmer> serg: are you already using this workflow?
[15:41] <serg> I was pulling from another bzr tree. but only now I'm starting to pull from 3 git repos
[15:42] <serg> and they have COPYING, README.md, and - particlarly annoying src/ and include/
[15:42]  * serg could live with COPYING and README being clashed into one file
[15:44] <jelmer> serg: if you need reviews/help landing stuff, feel free to ping me here
[15:45] <serg> thanks! I'll need to fix the patch first (add an option, fix tests, etc)
[15:46] <serg> one problem is that once we start using this approach, it'll be difficult to change it, so I wanted to be more confident that it works. Thanks for your help
[15:49] <jelmer> serg: do you have control over the git repositories?
[15:49] <serg> no
[15:50] <jelmer> serg: there are some open issues in bzr-git that might affect you
[15:50] <jelmer> if one of the repositories uses submodules or signed tags, that will break bzr-git
[15:51] <serg> I see. So far it worked, if it'll break, I'll need to figure something out, may be add a fix to bzr-git
[15:52] <jelmer> see pad.lv/963525, pad.lv/1084403
[15:54] <serg> what was the story with the second bug going to "fixed" and back few times?
[15:56] <jelmer> serg: see the comments - somebody who is not involved with bzr-git marked them as fixed
[15:57] <serg> ah, "not involved", ok. (I thought it's one of your developers, who might've had a different opinion, or something)
[16:06] <jelmer> serg: he spammed launchpad by changing the status of a large number of bugs
[16:07] <jelmer> also, s/developers/developer/ :-)