The problem is, most cases we have no idea of the base rev1, and commit rev2
which it's leading up to. E.g. for a single patch which is between
commit rev1..rev2,
how do we find out rev1 and rev2.
On Mon, Nov 5, 2012 at 9:39 PM, Michael J Gruber
wrote:
> Eric Miao venit, vidit, dixit 05
On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber
wrote:
> Eric Miao venit, vidit, dixit 05.11.2012 15:12:
>> The problem is, most cases we have no idea of the base rev1, and commit rev2
>> which it's leading up to. E.g. for a single patch which is between
>> commit rev
On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt wrote:
> Am 11/6/2012 1:58, schrieb Eric Miao:
>> On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber
>> wrote:
>>> Eric Miao venit, vidit, dixit 05.11.2012 15:12:
>>>> The problem is, most cases we have no idea of
On Tue, Nov 6, 2012 at 3:44 PM, Johannes Sixt wrote:
> Am 11/6/2012 7:56, schrieb Eric Miao:
>> On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt wrote:
>>> Am 11/6/2012 1:58, schrieb Eric Miao:
>>>> E.g. when we merged a series of patches:
>>>>
On Fri, Nov 9, 2012 at 3:09 AM, Jeff King wrote:
> On Tue, Nov 06, 2012 at 08:58:35AM +0800, Eric Miao wrote:
>
>> > So, then the question is: What do you know/have? Is your patch the
>> > output of "git format-patch", "git diff", or just some s
Yeah, that's a very clean way I'd always want to follow, yet the
kernel upstream isn't doing so.
On Sat, Nov 10, 2012 at 4:52 PM, Enrico Weigelt wrote:
>
>
> yet another idea:
>
> you coud always put your patchsets into separate branches,
> rebase them ontop target branch before merging, and the
6 matches
Mail list logo
