When merging upstream work related to other projects into your own
project repository, you probably don't want to check for (and try to
update) the status on every change-set in the merge. So add a list of
references (branches, tags, commits, etc.) whose commits should be
ignored in the patch updat
On Wed, 2014-06-11 at 17:18 +1000, Jeremy Kerr wrote:
> Hi Thomas,
>
> > Another thing that is missing IMO is a way of sorting the patches by
> > the number of A/R/T tags. Probably not needed to be able to sort them
> > for each individual value, but being able to sort them by the sum of
> > A+R+T
Trying again after signing up to the mailing list (patch is slightly
modified from my first submission, which may either be in moderation
or may have gotten lost somehow):
On Wed, Jun 11, 2014 at 04:09:16PM +0530, Siddhesh Poyarekar wrote:
> Hi,
>
> We recently encountered a case in our glibc pat
Dear Jeremy Kerr,
On Wed, 11 Jun 2014 17:18:19 +1000, Jeremy Kerr wrote:
> > Another thing that is missing IMO is a way of sorting the patches by
> > the number of A/R/T tags. Probably not needed to be able to sort them
> > for each individual value, but being able to sort them by the sum of
> >
Hi Thomas,
> Another thing that is missing IMO is a way of sorting the patches by
> the number of A/R/T tags. Probably not needed to be able to sort them
> for each individual value, but being able to sort them by the sum of
> A+R+T would be useful so that maintainers can spot immediately which
>
Dear Jeremy Kerr,
On Wed, 11 Jun 2014 10:00:54 +1000, Jeremy Kerr wrote:
> They should be parsed when the original patch is received, and when any
> follow-ups are appended to the patch. However:
>
> > I noticed that (in the Buildroot patchwork [0]) some tags were not
> > accounted for:
> >
