On Sun, Jul 26, 2015 at 11:28 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > On Sun, Jul 26, 2015 at 12:36 AM, Karthik Nayak <karthik.188@xxxxxxxxx> wrote: >> On Sun, Jul 26, 2015 at 9:38 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: >>> Also, it is helpful to reviewers if you include an interdiff at the >>> bottom of your cover letter showing the changes from one version to >>> another. You can generate an interdiff with "git diff branchname-v4 >>> branchname-v5", for instance. >> >> I've been working on the same branch, and that's why I didn't really >> provide interdiff's, and I kinda worked on the same branch again, >> so I wont be giving an interdiff for the next series either, but I'll keep this >> in mind and follow it from the forthcoming patch series. Thanks > > You can still provide an interdiff. It is quite likely that you can > find the commit corresponding to v4 in the reflog for that branch (see > git-reflog). Failing that, an easy way to recover the state at v4 is > to create a new branch (from the parent of your current working > branch) and apply the v4 patches which you sent to the mailing list. > If Junio queued v4 in his 'pu' branch, then you can also recover from > there. Once you've recovered the state of v4 using one of the methods > mentioned here (or some other), you can make an interdiff when sending > out v5. > Haha, I was just thinking about applying my patches and doing it, will definitely provide an interdiff. > Reviewers do appreciate that you provide a URL to the previous version > and take the time to explain in your cover letter what changed (and > why). Including an interdiff is one more way to ease the review > process, and is also appreciated, so it may be worthwhile to put in > the effort to recover the state of v4 so that you can include an > interdiff with v5. Doing so does require a bit of extra work for you, > but that's work you only need to do *once*, whereas if you don't do > it, then you place the burden on *each* reviewer for *each* version, > which quickly adds up to a lot more work for those reviewing your > submissions. Yes! definitely, I'll make sure that I provide the interdiff, I'll look at reflog, thanks a lot. I appreciate how reviewers take time to review code, its a wonderful process. I will be glad to put in any time to make their process easier -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html