<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-08-25 16:12 GMT+03:00 Pino Toscano <<a href="mailto:ptoscano@redhat.com" target="_blank">ptoscano@redhat.com</a>>: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thursday, 25 August 2016 16:05:47 CEST NoxDaFox wrote: > 2016-08-25 14:09 GMT+03:00 Pino Toscano <<a href="mailto:ptoscano@redhat.com">ptoscano@redhat.com</a>>: > > > On Wednesday, 24 August 2016 23:59:53 CEST Matteo Cafasso wrote: > > > The find_inode API allows the User to search all the entries referring > > > to a given inode and returns a tsk_dirent structure for each of them. > > > > > > As I didn't want to change unrelated code, there is a little bit > > > of code duplication at the moment. Plan is to refactor the logic > > > in a dedicated set of patches. > > > > The general idea looks ok, but I'd rather see the duplication dealt > > with sooner than later. > > > In the previous submissions, non related changes were rejected therefore I > thought that was the custom. I don't see how the two cases are the same: what was "rejected" was a single patch contaning both additions documented in the commit message, and unrelated changes such as formatting fixes. I remember to have said that it's a no-go as *single* patch, but they can be sent (and integrated) as different commits. </blockquote><div>Then I totally misunderstood. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> In this case, refactoring and de-duplication of code should be done in different commits as well. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > Moreover I'll add another API find_block (block_number --> tsk_dirents > referring to it) and I think is easier to refactor the code once all the > use cases are in place as the picture gets more clear. More reasons to refactor *before*: since you already planned more APIs, it's easier to just refactor one in advance with all the common code needed, and use it later. Also, it eases a lot the review of the patches, since it will be less code added. </blockquote><div>Seems reasonable, I'll proceed and re-submit then. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> -- Pino Toscano _______________________________________________ Libguestfs mailing list <a href="mailto:Libguestfs@redhat.com">Libguestfs@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/libguestfs" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/libguestfs</a> </blockquote></div> </div></div>