Re: linux-next: unnecessary merge in the v4l-dvb tree

[Mauro Carvalho Chehab]

Em Mon, 12 Feb 2018 15:42:44 -0800
Junio C Hamano  escreveu:

> Linus Torvalds  writes:
> 
> > And some maintainers end up using multiple repositories as branches
> > (the old _original_ git model). Again, you can just use "git fetch +
> > git reset", of course, but that's a bit unsafe. In contrast, doing
> > "git pull --ff-only" is a safe convenient operation that does both the
> > fetch and the update to whatever state.
> >
> > But you do need that "--ff-only" to avoid the merge.  
> 
> OK.  I guess it is legit (and semi-sensible) for downstream
> contributors to "git pull --ff-only $upstream $release_tag_X" to
> bring their long-running topic currently based on release X-1 up to
> date with respect to release X.  It probably makes more sense than
> rebasing on top of release X, even though it makes a lot less sense
> than merging their topics into release X.
> 
> As you said, pull of a tag that forbids fast-forward by default is
> rather old development (I am kind of surprised that it was so old,
> in v1.7.9), so it may be a bit difficult to transition.
> 
> There is 
> 
>   [pull]
> ff = only
> 
> but pull.ff is quite global, and not good for intermediate level
> maintainers who pull to integrate work of their downstream (for
> which they do want the current "do not ff, record the tag in a merge
> commit" behaviour) and also pull to catch up from their upstream
> (which they want "ff-when-able").  They need to control between
> ff=only and ff=when-able, depending on whom they are pulling from.

Yes, that's my pain. I don't want ff only when pulling from others,
only when pulling from upstream tree.

> 
> We may want per-remote equivalent for it, i.e. e.g.
> 
>   [pull]
>   ff=false ;# good default for collecting contributions
> 
>   [remote "torvalds"] 
>   pullFF = only ;# good default for catching up
> 
> or something like that, perhaps?


Yeah, something like that works. Please notice, however, that what I
usually do is:

$ git remote update torvalds
$ git merge 
  (or git pull . )

So, for the above to work, it should store somehow the remote from
where a tag came from.




The reason is that I keep locally a cache with several tree clones
(in bare mode) s that I bother enough to cache (linus, -stable, -next),
as pulling from BR is time consuming, and I want to do it only once
and use the same "cache" for all my git clones.

I have a few git workdirs for my upstream work, but, as a patch
developer, I also have "independent"[1] git repositories.

[1] Due to disk constraints, the clones actually use --shared. So,
the common objects are actually stored inside a single tree.

Thanks,
Mauro

Re: linux-next: unnecessary merge in the v4l-dvb tree

[Mauro Carvalho Chehab]

Em Mon, 12 Feb 2018 13:15:04 -0800
Linus Torvalds  escreveu:

> On Mon, Feb 12, 2018 at 1:00 PM, Stephen Rothwell  
> wrote:
> >
> > Linus, this happens a bit after the merge window, so I am wondering
> > about the rational of not doing a fast forward merge when merging a
> > signed tag (I forget the reasoning).  
> 
> The reasoning is to avoid losing the signature from the tag (when
> merging a signed tag, the signature gets inserted into the merge
> commit itself - use "git log --show-signature" to see them).
> 
> So when I merge a signed tag, I do *not* want to fast-forward to the
> top commit, because then I'd lose the signature from the tag. Thus the
> "merging signed tags are non-fast-forward by default" reasoning.
> 
> But, yes, that reasoning is really only valid for proper merges of new
> features, not for back-merges.
> 
> The problem, of course, is that since git is distributed, git doesn't
> know who is "upstream" and who is "downstream", so there's no
> _technical_ difference between merging a development tree, and a
> development tree doing a back-merge of the upstream tree.
> 
> Maybe it was a mistake to make signed tag merges non-fast-forward,
> since they cause these kinds of issues with people who use "pull" to
> update their otherwise unmodified trees.
> 
> I can always teach myself to just use --no-ff, since I end up doing
> things like verifying at the signatures anyway.

Hmm... at least at git version 2.14.3, git documentation doesn't
mention that signed pull requests won't do fast forward. Instead,
it says that --ff is the default behavior:


   --ff
   When the merge resolves as a fast-forward, only update the branch 
pointer, without creating a merge commit. This is the
   default behavior.

Btw, even doing:

$ git merge -ff v4.16-rc1

it will still produce a git commit for the merge.


-- 
Thanks,
Mauro

Re: get_maintainer.pl and .mailmap entries with more than 2 addresses

[Mauro Carvalho Chehab]

Em Wed, 03 Aug 2016 00:17:10 +0200
Florian Mickler <flor...@mickler.org> escreveu:

> cc'd mche...@s-opensource.com  (Mauro, is your kernel.org address up?)

Yes, my kernel.org address is up. Better to keep it as the canonical address,
as this is unlikely to change as it is not associated to an e-mail provider.

> 
>  Am Tue, 02 Aug 2016 09:36:21 -0700
> schrieb Joe Perches <j...@perches.com>:
> 
> > Hello Florian.
> > 
> > There is at least an oddity with get_maintainer handling of a
> > .mailmap entry form.
> > 
> > For instance:
> > 
> > Mauro's .mailmap entry is:
> > Mauro Carvalho Chehab <mche...@kernel.org> <mauroche...@gmail.com>
> > <mche...@infradead.org> <mche...@redhat.com> <m.che...@samsung.com>
> > <mche...@osg.samsung.com> <mche...@s-opensource.com>
> > 
> > Is this a valid form?
> > 
> > get_maintainer output for Mauro is:
> > 
> > $ ./scripts/get_maintainer.pl drivers/media/ -f
> > Mauro Carvalho Chehab <mche...@kernel.org> <mauroche...@gmail.com>
> > <mche...@infradead.org> <mche...@redhat.com> <m.che...@samsung.com>
> > <mche...@osg.samsung.com> (maintainer:MEDIA INPUT INFRASTRUCTURE
> > (V4L/DVB))
> > 
> > I believe the Mauro's and Shuah's .mailmap entries are improper and
> > should be changed, but I'm not completely aware of git .mailmap
> > handling and the documentation seems weakly specified.
> >   
> 
> Hmm.. looking at Mauros last .mailmap commit it seems like your patch is
> ok for Mauro. 
> 
> Although <mywin...@gmail.com> and <mche...@brturbo.com.br> are probably
> missing? (@Mauro) 

The mche...@brturbo.com.br is indeed an old email that I used on my
first submissions.

I don't know a mywin...@gmail.com address... that looks really weird
on my eyes...

Hmm...

$ git log --author "mywin...@gmail.com"
commit fe8b671306c78a963934cb5d6e354178390b8c87
Author: Mauro Carvalho Chehab <mywin...@gmail.com>
Date:   Thu Sep 30 14:46:47 2010 -0300

[media] saa7134: port Asus P7131 Hybrid to use the new rc-core

The rc map table were corrected thanks to Giorgio input and tests.

Reported-by: Giorgio Vazzana <mywin...@gmail.com>
Tested-by: Giorgio Vazzana <mywin...@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mche...@redhat.com>

I don't remember the dirty details about such patch anymore... too
many years ago. From the custody chain, I _suspect_ that Giorgio
proposed a patch to be applied against the saa7134 driver, but the 
remote controller map table was moved to a separate file about 7
months before such patch by those changesets:

6686fa6917ca V4L/DVB: Break Remote Controller keymaps into modules
77b7422d48cd V4L/DVB: ir-common: move IR tables from ir-keymaps.c to a separate 
file

I likely rewrote his patch against the new driver, but somehow
I mangled with the author name/email. In any case, mywin...@gmail.com
should not be associated with me.
 
> 
> $ git shortlog | grep "^Mauro C"
> Mauro Carvalho Chehab (4404):
> $ git log | grep "^Author:.*Mauro Carvalho Chehab" | sort | uniq -c
>   2 Author: Mauro Carvalho Chehab <mauroche...@gmail.com>
> 146 Author: Mauro Carvalho Chehab <mche...@brturbo.com.br>
> 645 Author: Mauro Carvalho Chehab <mche...@infradead.org>
> 794 Author: Mauro Carvalho Chehab <mche...@osg.samsung.com>
>2015 Author: Mauro Carvalho Chehab <mche...@redhat.com>
> 448 Author: Mauro Carvalho Chehab <m.che...@samsung.com>
> 353 Author: Mauro Carvalho Chehab <mche...@s-opensource.com>

All above are my e-mails. Let's point them all to mche...@kernel.org.

>   1 Author: Mauro Carvalho Chehab <mywin...@gmail.com>

This one is mangled and doesn't belong to me. So, it shouldn't be
at the .mailmap file.

> 
> 
> 
> Anyway, from a technical viewpoint your patches seem to fix
> the .mailmap entry as the author intended. (See Junio's Email for the
> documantation part) 
> But I would wait for the ack from Mauro and Shuah. 

With the above changes,

Acked-by: Mauro Carvalho Chehab <mche...@s-opensource.com>


Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html