felipe.contreras at gmail.com
Tue Feb 8 07:37:38 EST 2011
On Tue, Feb 8, 2011 at 7:01 AM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
> On 02/07/2011 07:33 PM, Felipe Contreras wrote:
>> I wrote that svn-patch-authors file, and a simple 'git filter-branch' script
>> fixes the authors in no time:
> I thought I mentioned that it was your partial map. I apologize for not doing
> so. That said, Richard *did* correctly point that out in the next message in
> the thread.
Good. I was wondering why you didn't notice.
>> There is no advantage from hg's convert whatsoever.
> Except the avoidance of a middle-man git repo that isn't strictly necessary.
> I'm willing to trade 30 hours for the simplicity of avoiding yet another tool in
> the process. It's not like we're active enough that it's going to kill us to
> have a 48-hour freeze on commits and pushes.
The problem is that the conversion scripts are a work in progress, 64
commits so far. And most of time they are changed you have to rebuild
I'm aware of that pain, that's why I even profiled 'mtn git_export'
and fixed the bigger bottlenecks, and now it takes about 20min to do
the full conversion.
>> I wrote that file, as you can see in the hg log. We have been collaborating, if
>> you take a closer look a the pidgin-mtn-conv-files repo you would see that I
>> have contributed a lot of work.
> Yes, you've contributed some work. And I thank you for that. I will gladly
> accept contributions that make our converted history more accurate.
>> In git, there are standard tags, such as 'Signed-off-by'. Say, if you apply a
>> patch by me, the s-o-b's would be:
>> Signed-off-by: Felipe Contreras <felipe.contreras at gmail.com>
>> Signed-off-by: John Bailey <rekkanoryo at rekkanoryo.org>
> Again, as Richard pointed out, these are not "in" git. They are
> changelog-inline metadata that the Linux kernel adopted. Yes, they've caught on
> with other projects. That doesn't make them a gitism. We could use these in
> hg, bzr, darcs, mtn, and even in cvs, rcs, and SCCS. They have merit, but I'd
> rather have seen something like:
See git commit --signoff:
And git format-patch --signoff:
And git send-email --[no-]signed-off-by-cc --suppress-cc=cc,sob
It's very much part of git.
> Originated-By: Some Random Idiot <random at idiot.com>
> Approved-By: John Bailey <rekkanoryo at rekkanoryo.org>
> Approved-By: Someone Else <someone at else.org>
Sure, you can add those, but in git only Signed-off-by and Cc have
>> No, you could just use 'git filter-branch' as I do in pidgin-git-import.
> That would be perfectly acceptable to me if we were converting to git. But
> we're not converting to git. I don't want a third tool in the conversion process.
You are quite fond of providing non-arguments. You say you don't want
a third tool in the conversion process, but you don't have any valid
>> Now, one of the proposals was to provide both git and hg repos, however, it
>> would be great if you store data that can be easily exported to git.
>> 1) Provide both committer and author. Either with Signed-off-by or some other
>> method, but you have to provide both somehow.
>> 2) Always provide valid authors. In git, they are in the form "Real Name
>> <email at box.com>", and the mail part is _mandatory_. If there's no mail
>> address, <unknown> would make sense.
> I agree it would be a nice convenience to provide a git "mirror" of the hg repo.
> That said, it's not strictly necessary, as there is a way a git user can use an
> hg repo transparently with git, conveniently called git-hg. At this point I
> don't care whether someone other than me wants to maintain such an "official"
> mirror or if our official stance will be to use git-hg.
Awful. You don't want to use a "third tool" in the conversion process,
which happens rarely, but you want to force that to contributors that
prefer git. Very empathetic of you.
>> Also, remember that the idea was to start a repository from scratch, so, even
>> if the conversion tool is not finished yet, that doesn't matter as it can
>> always be fixed later on.
> It was an idea that was discussed. As I recall, I'm the only one who expressed
> interest in actually doing any of the creation and subrepo joining and whatnot.
> Unless someone else wants it also, the idea is dead. That said, I wanted the
> fresh start to happen at 3.0.0, not immediately, so things can't be left
> temporarily and fixed later. It has to be perfect at the beginning.
Awful. So the idea of having a repository for each project is dead too.
And no conversion is ever perfect. You *will* have issues that are
found after you migrate, and they would have to stay forever in the
history. Or at least until you realize that hg was not a good choice.
I for starters can think of a list of mtn commits that, like svn
commits, didn't have the right patch author, this guideline was
introduced only later, when I pointed that out.
More information about the Devel