Re: git-gui: missing some patches from git?

From: Denton Liu <liu.denton@gmail.com>
Date: Sep 19, 2019, 19:11 UTC
Message-ID: <20190919191105.GA85790@dentonliu-ltm.internal.salesforce.com>
In-Reply-To: <20190919190359.cuvy5g3xangrkgim@yadavpratyush.com>

On Fri, Sep 20, 2019 at 12:33:59AM +0530, Pratyush Yadav wrote:

Show 34 quoted lines

> 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@yadavpratyush.com> 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

Since those two commits have parents that are found in git.git, you'll pull the whole history of git.git if you try doing this.

> pull, and that is what happened. The repo size went up from around 6M to 
> 72M. Will cherry-picking avoid that?
>

Yes, when you cherry-pick, you're essentially replaying the patch from the old tree onto the new tree and recording a fresh commit from it. The new commit is completely separate from the one it's based on so you won't end up pulling in any ancestry information and, as a result, you won't pull the rest of git's history.

In any case, give it a try. It doesn't hurt to experiment and play around with it.

Show 16 quoted lines

> 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