On 19/09/19 11:47AM, Denton Liu wrote: > On Fri, Sep 20, 2019 at 12:02:58AM +0530, Pratyush Yadav wrote: > > Hi Junio, > > > > On 18/09/19 10:49AM, Junio C Hamano wrote: > > > Pratyush Yadav <me@xxxxxxxxxxxxxxxxx> writes: > > > You should be able to merge this (and all other git-gui topics > > > already in my tree Denton pointed out) to your 'master'. If you > > > then make a trial merge of the result back into my tree with "git > > > merge -Xsubtree=git-gui", it should result in "already up to date", > > > i.e. a noop merge. > > > > I pulled all the changes into git-gui. I had to manually backport two > > commits: > > > > * 7560f547e6 (treewide: correct several "up-to-date" to "up to date", * 2017-08-23) > > * 00ddc9d13c (Fix build with core.autocrlf=true, 2017-05-09) > > > > because they touched other parts of git, that were not in git-gui. > > > > For the record, you could do a > > git cherry-pick -Xsubtree=git-gui 00ddc9d13c 7560f547e6 > > to bring them over instead of manually recreating the changes yourself. > Personally, I'd prefer the cherry-picked commits as it'd preserve > authorship information but I'm not sure how Junio feels. I'm not sure how this will work internally, but won't this also pull all the ancestors of those commits into git-gui? That is bloat I'd rather avoid. I tried creating branches for those two commits and then did a subtree pull, and that is what happened. The repo size went up from around 6M to 72M. Will cherry-picking avoid that? And if it won't, how about munging a patch created by format-patch to get the authorship information without having to pull all the ancestors? > From a correctness perspective, however, I compared my results after > doing that with yours and it's identical. > > If it looks all good, I'll put all this on my 'master' and re-send > > the pull request. > > I took a look as well and the end result looks good to me too. Thanks. -- Regards, Pratyush Yadav
