Hello Mauro,
On Fri, Jun 03, 2011 at 12:39:52PM -0300, Mauro Carvalho Chehab wrote:
> Em 03-06-2011 04:39, Uwe Kleine-KÃnig escreveu:
> > Hello Mauro,
> >
> > On Wed, Jun 01, 2011 at 10:34:31PM -0300, Mauro Carvalho Chehab wrote:
> >> Hi Kyungmin,
> >>
> >> Em 01-06-2011 21:50, Kyungmin Park escreveu:
> >>> Acked-by: Kyungmin Park <kyunginn.,park@xxxxxxxxxxx>
> >>
> >> As this patch is really trivial and makes sense, I've just applied it earlier
> >> today.
> > You somehow screwed up my name in the Author field more than I'm used
> > to:
> >
> > $ git cat-file commit 215c52702775556f4caf5872cc84fa8810e6fc7d | grep Uwe
> > author Uwe Kleine-KÃÆÃâÃâÃÂnig <u.kleine-koenig@xxxxxxxxxxxxxx> 1306959562 -0300
> > Signed-off-by: Uwe Kleine-KÃnig <u.kleine-koenig@xxxxxxxxxxxxxx>
> >
> > Strange enough my name in the commitlog looks fine.
>
> You should thank Python for that. We use patchwork to retrieve patches. It is written
> in Python. Python seems to have serious troubles handling anything that it is not pure
> ASCII. In the past, a non-north-american name in Patchwork would be simply discarded,
> as python used to abort patchwork. Lots of locale-fix patches later trying to address
> this issue and now, it sometimes do the right thing.
I added Jeremy Kerr to Cc:, maybe he is interested to look into that.
> > If you care to fix it, you can easily do so using git filter-branch.
> > E.g.:
> >
> > $ git filter-branch --env-filter 'test "x$GIT_COMMIT" != "x215c52702775556f4caf5872cc84fa8810e6fc7d" || { GIT_AUTHOR_NAME="Uwe Kleine-KÃnig"; export GIT_AUTHOR_NAME; }' ^215c5270277^ HEAD
> >
> > (Assuming an UTF-8 locale.)
> >
> > This converts 215c527 to a commit c6cbbfc that has my name fixed and
> > rebases all following commits on top of this. In your master branch this
> > only affects "00c4526 (Merge /home/v4l/v4l/for_upstream)"
>
> This breaks merge.
>
> $ git push
> To /home/v4l/bare_trees/v4l-dvb.git/
> ! [rejected] staging/for_v3.0 -> staging/for_v3.0 (non-fast-forward)
>
>
> Fortunately, as the patches on this branch are meant to go to v3.1,
> I just renamed the branch to staging/for_v3.1, keeping the wrong patch
> at the old branch. This way, the need of rebasing was avoided.
I don't get what you mean here. Which merge is broken? Just in case you
didn't know, git push -f should be able to overwrite the remote branch,
with all the downside that brings that with it.
Best regards and thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-KÃnig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
