threads / discuss / 51874

git-gui: missing some patches from git?

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

## tl;dr

13 messages between Sep 18, 2019 and Sep 24, 2019.

replies: 12people: 4as markdown or json

Birger Skogeng Pedersen· Sep 18, 2019, 07:02 UTC · lore
Hi Pratyush,

I was comparing your git-gui repo[1] with the source code of git/git-gui[2]. There seems to be a couple of things missing.

For example, I created a patch back in March 2018[3]. Junio pulled it so the changes are really there in git/git-gui/git-gui.sh (see this[4] line). This was while there was no git-gui maintainer. I guess the change never got merged to git-gui, but directly to git.

Not sure what you should to about it, I just wanted to let you know.

[1] https://github.com/prati0100/git-gui [2] https://github.com/gitster/git/tree/master/git-gui [3] https://public-inbox.org/git/20180302100148.23899-1-birgersp@gmail.com/ [4] https://github.com/gitster/git/blob/master/git-gui/git-gui.sh#L3885

Birger
Denton Liu· Sep 18, 2019, 09:27 UTC · re: Birger Skogeng Pedersen · lore

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

On Wed, Sep 18, 2019 at 09:02:37AM +0200, Birger Skogeng Pedersen wrote:
Show 20 quoted lines
> Hi Pratyush,
> 
> 
> I was comparing your git-gui repo[1] with the source code of
> git/git-gui[2]. There seems to be a couple of things missing.
> 
> For example, I created a patch back in March 2018[3]. Junio pulled it
> so the changes are really there in git/git-gui/git-gui.sh (see this[4]
> line). This was while there was no git-gui maintainer. I guess the
> change never got merged to git-gui, but directly to git.
> 
> Not sure what you should to about it, I just wanted to let you know.
> 
> [1] https://github.com/prati0100/git-gui
> [2] https://github.com/gitster/git/tree/master/git-gui
> [3] https://public-inbox.org/git/20180302100148.23899-1-birgersp@gmail.com/
> [4] https://github.com/gitster/git/blob/master/git-gui/git-gui.sh#L3885
> 
> 
> Birger

As an exercise in writing throwaway scripts, I created this monstrosity. If you're interested in merging all of the git-gui branches that came from mainline back into git-gui's master, perhaps we could do something like this:

	#!/bin/sh
	branches=
	# note that all instances of "master" refer to git.git's "master"
	# also, 5ab7227 is the latest commit in Pat's git-gui repo
	for c in $(git rev-list --children master 5ab7227 | grep ^5ab7227 | cut -d' ' -f2-)
	do 
		merge_commit=$(git rev-list $c..master --ancestry-path --merges | tail -n1)
		branch_name=$(git show -s --format=%s $merge_commit | sed -e "s/Merge branch '\\([^']*\\)' of .*/\\1/")
		#echo $branch_name: $(git rev-parse $merge_commit^2)
		git branch -f "$branch_name" $merge_commit^2
		branches="$branches $branch_name"
	done
	# this also assumes git-gui's master is checked out
	git merge $branches

This script should resurrect all of the branches that were based on 5ab7227 from mainline's master. Then (assuming you have git-gui's master checked out), it should do a big octopus merge to bring all of the changes in.

We end up with the following branches being merged:
	js/msgfmt-on-windows: 492595cfc70f97cd99d4c460db1ba01b73dab932
	tz/fsf-address-update: 63100874c1653dd6a137f74143eda322550eabc7
	jn/reproducible-build: 474642b4a47c74a1f277955d7387d1886546fa01
	ls/no-double-utf8-author-name: 331450f18a7fd298ddd6b85cc5e8ed9dba09f9da
	js/misc-git-gui-stuff: 76756d67061076c046973bff2089ad49f5dc2eb6
	bb/ssh-key-files: 6a47fa0efa342daa53c6386538fda313420351a5
	bp/bind-kp-enter: 146a6f1097f451c6b6d332916a515b7ce8c07e9a
	cb/ttk-style: f50d5055bf9bb2aa35e629d31943334afc4a9f10
	py/call-do-quit-before-exit: 5440eb0ea2651c45a0e46f2335ecbb8d1f42c584

Then perhaps you could do a request-pull and development could continue on your fork?

Not sure if this is even desirable but here's the script just in case it ends up useful. I had fun writing it.

Also note that we end up missing two commits that made changes to git-gui/ under mainline git (not directly to the git-gui repo):

	* 7560f547e6 (treewide: correct several "up-to-date" to "up to date", 2017-08-23)
	* 00ddc9d13c (Fix build with core.autocrlf=true, 2017-05-09)
Hope any of this is useful to anyone,
Denton
Pratyush Yadav· Sep 18, 2019, 15:14 UTC · re: Denton Liu · lore

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

On 18/09/19 02:27AM, Denton Liu wrote:
Show 13 quoted lines
> On Wed, Sep 18, 2019 at 09:02:37AM +0200, Birger Skogeng Pedersen wrote:
> > Hi Pratyush,
> > 
> > 
> > I was comparing your git-gui repo[1] with the source code of
> > git/git-gui[2]. There seems to be a couple of things missing.
> > 
> > For example, I created a patch back in March 2018[3]. Junio pulled it
> > so the changes are really there in git/git-gui/git-gui.sh (see this[4]
> > line). This was while there was no git-gui maintainer. I guess the
> > change never got merged to git-gui, but directly to git.
> > 
> > Not sure what you should to about it, I just wanted to let you know.

This is something I've been aware of, but I have followed the strategy of ignoring the problem till someone complains. Well, that someone has now complained.

I'm not particularly comfortable with cross-tree/sub-tree merges, so I've been dreading doing this for a while. Guess now its time to get my hands dirty.

Show 13 quoted lines
> > 
> > [1] https://github.com/prati0100/git-gui
> > [2] https://github.com/gitster/git/tree/master/git-gui
> > [3] https://public-inbox.org/git/20180302100148.23899-1-birgersp@gmail.com/
> > [4] https://github.com/gitster/git/blob/master/git-gui/git-gui.sh#L3885
> > 
> > 
> > Birger
> 
> As an exercise in writing throwaway scripts, I created this monstrosity.
> If you're interested in merging all of the git-gui branches that came
> from mainline back into git-gui's master, perhaps we could do something
> like this:

Ah! Thanks a lot for this. This reduces some of the work I've been dreading.

Show 17 quoted lines
> 
> 	#!/bin/sh
> 
> 	branches=
> 	# note that all instances of "master" refer to git.git's "master"
> 	# also, 5ab7227 is the latest commit in Pat's git-gui repo
> 	for c in $(git rev-list --children master 5ab7227 | grep ^5ab7227 | cut -d' ' -f2-)
> 	do 
> 		merge_commit=$(git rev-list $c..master --ancestry-path --merges | tail -n1)
> 		branch_name=$(git show -s --format=%s $merge_commit | sed -e "s/Merge branch '\\([^']*\\)' of .*/\\1/")
> 
> 		#echo $branch_name: $(git rev-parse $merge_commit^2)
> 		git branch -f "$branch_name" $merge_commit^2
> 		branches="$branches $branch_name"
> 	done
> 	# this also assumes git-gui's master is checked out
> 	git merge $branches

Assuming I have git.git cloned in ../git (relative to git-gui.git), I ran:

  git pull -Xsubtree=git-gui ../git $branches
instead of:
  git merge $branches

because git-gui's tree doesn't have those commits and branches yet, so we can't merge straight away. This seems to have worked, but I thought I'd mention it in case it would cause some subtle problems.

Show 8 quoted lines
> This script should resurrect all of the branches that were based on
> 5ab7227 from mainline's master. Then (assuming you have git-gui's
> master checked out), it should do a big octopus merge to bring all of
> the changes in.
> 
> We end up with the following branches being merged:
> 
> 	js/msgfmt-on-windows: 492595cfc70f97cd99d4c460db1ba01b73dab932

This branch is already in git-gui (with the exception of one commit. More on that below).

Show 14 quoted lines
> 	tz/fsf-address-update: 63100874c1653dd6a137f74143eda322550eabc7
> 	jn/reproducible-build: 474642b4a47c74a1f277955d7387d1886546fa01
> 	ls/no-double-utf8-author-name: 331450f18a7fd298ddd6b85cc5e8ed9dba09f9da
> 	js/misc-git-gui-stuff: 76756d67061076c046973bff2089ad49f5dc2eb6
> 	bb/ssh-key-files: 6a47fa0efa342daa53c6386538fda313420351a5
> 	bp/bind-kp-enter: 146a6f1097f451c6b6d332916a515b7ce8c07e9a
> 	cb/ttk-style: f50d5055bf9bb2aa35e629d31943334afc4a9f10
> 	py/call-do-quit-before-exit: 5440eb0ea2651c45a0e46f2335ecbb8d1f42c584
> 
> Then perhaps you could do a request-pull and development could continue
> on your fork?
> 
> Not sure if this is even desirable but here's the script just in case it
> ends up useful. I had fun writing it.
Just to pick your brain: in what case would this not be desirable?
 
Show 5 quoted lines
> Also note that we end up missing two commits that made changes to
> git-gui/ under mainline git (not directly to the git-gui repo): 
> 
> 	* 7560f547e6 (treewide: correct several "up-to-date" to "up to date", 2017-08-23)
> 	* 00ddc9d13c (Fix build with core.autocrlf=true, 2017-05-09)
One more commit that is missing: 492595cfc7 (git-gui (MinGW): make use of MSys2's msgfmt, 2017-07-25)

This commit is comes from the merge of js/msgfmt-on-windows, which has all the commits from the merge 5ab7227 (Merge remote-tracking branch 'philoakley/dup-gui', 2017-03-18) in git-gui.

While merging js/msgfmt-on-windows should get this commit into git-gui, I'd rather have it separate,

> 
> Hope any of this is useful to anyone,
It is very useful. Thanks :)
-- 
Regards,
Pratyush Yadav
Denton Liu· Sep 18, 2019, 16:56 UTC · re: Pratyush Yadav · lore

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

On Wed, Sep 18, 2019 at 08:44:04PM +0530, Pratyush Yadav wrote:
Show 70 quoted lines
> On 18/09/19 02:27AM, Denton Liu wrote:
> > On Wed, Sep 18, 2019 at 09:02:37AM +0200, Birger Skogeng Pedersen wrote:
> > > Hi Pratyush,
> > > 
> > > 
> > > I was comparing your git-gui repo[1] with the source code of
> > > git/git-gui[2]. There seems to be a couple of things missing.
> > > 
> > > For example, I created a patch back in March 2018[3]. Junio pulled it
> > > so the changes are really there in git/git-gui/git-gui.sh (see this[4]
> > > line). This was while there was no git-gui maintainer. I guess the
> > > change never got merged to git-gui, but directly to git.
> > > 
> > > Not sure what you should to about it, I just wanted to let you know.
> 
> This is something I've been aware of, but I have followed the strategy 
> of ignoring the problem till someone complains. Well, that someone has 
> now complained.
> 
> I'm not particularly comfortable with cross-tree/sub-tree merges, so 
> I've been dreading doing this for a while. Guess now its time to get my 
> hands dirty.
> 
> > > 
> > > [1] https://github.com/prati0100/git-gui
> > > [2] https://github.com/gitster/git/tree/master/git-gui
> > > [3] https://public-inbox.org/git/20180302100148.23899-1-birgersp@gmail.com/
> > > [4] https://github.com/gitster/git/blob/master/git-gui/git-gui.sh#L3885
> > > 
> > > 
> > > Birger
> > 
> > As an exercise in writing throwaway scripts, I created this monstrosity.
> > If you're interested in merging all of the git-gui branches that came
> > from mainline back into git-gui's master, perhaps we could do something
> > like this:
> 
> Ah! Thanks a lot for this. This reduces some of the work I've been 
> dreading.
> 
> > 
> > 	#!/bin/sh
> > 
> > 	branches=
> > 	# note that all instances of "master" refer to git.git's "master"
> > 	# also, 5ab7227 is the latest commit in Pat's git-gui repo
> > 	for c in $(git rev-list --children master 5ab7227 | grep ^5ab7227 | cut -d' ' -f2-)
> > 	do 
> > 		merge_commit=$(git rev-list $c..master --ancestry-path --merges | tail -n1)
> > 		branch_name=$(git show -s --format=%s $merge_commit | sed -e "s/Merge branch '\\([^']*\\)' of .*/\\1/")
> > 
> > 		#echo $branch_name: $(git rev-parse $merge_commit^2)
> > 		git branch -f "$branch_name" $merge_commit^2
> > 		branches="$branches $branch_name"
> > 	done
> > 	# this also assumes git-gui's master is checked out
> > 	git merge $branches
> 
> Assuming I have git.git cloned in ../git (relative to git-gui.git), I 
> ran:
> 
>   git pull -Xsubtree=git-gui ../git $branches
> 
> instead of:
> 
>   git merge $branches
> 
> because git-gui's tree doesn't have those commits and branches yet, so 
> we can't merge straight away. This seems to have worked, but I thought 
> I'd mention it in case it would cause some subtle problems.

Did you run the big for loop in git.git to create the branches and then the `git pull` in git-gui? That should work.

Show 29 quoted lines
> 
> > This script should resurrect all of the branches that were based on
> > 5ab7227 from mainline's master. Then (assuming you have git-gui's
> > master checked out), it should do a big octopus merge to bring all of
> > the changes in.
> > 
> > We end up with the following branches being merged:
> > 
> > 	js/msgfmt-on-windows: 492595cfc70f97cd99d4c460db1ba01b73dab932
> 
> This branch is already in git-gui (with the exception of one commit. 
> More on that below).
> 
> > 	tz/fsf-address-update: 63100874c1653dd6a137f74143eda322550eabc7
> > 	jn/reproducible-build: 474642b4a47c74a1f277955d7387d1886546fa01
> > 	ls/no-double-utf8-author-name: 331450f18a7fd298ddd6b85cc5e8ed9dba09f9da
> > 	js/misc-git-gui-stuff: 76756d67061076c046973bff2089ad49f5dc2eb6
> > 	bb/ssh-key-files: 6a47fa0efa342daa53c6386538fda313420351a5
> > 	bp/bind-kp-enter: 146a6f1097f451c6b6d332916a515b7ce8c07e9a
> > 	cb/ttk-style: f50d5055bf9bb2aa35e629d31943334afc4a9f10
> > 	py/call-do-quit-before-exit: 5440eb0ea2651c45a0e46f2335ecbb8d1f42c584
> > 
> > Then perhaps you could do a request-pull and development could continue
> > on your fork?
> > 
> > Not sure if this is even desirable but here's the script just in case it
> > ends up useful. I had fun writing it.
> 
> Just to pick your brain: in what case would this not be desirable?
I'm not 100% about the accuracy of the script. In particular,
	merge_commit=$(git rev-list $c..master --ancestry-path --merges | tail -n1)

is super hacky and makes a lot of assumptions. It'd probably be best if someone else also takes a look.

Show 15 quoted lines
>  
> > Also note that we end up missing two commits that made changes to
> > git-gui/ under mainline git (not directly to the git-gui repo): 
> > 
> > 	* 7560f547e6 (treewide: correct several "up-to-date" to "up to date", 2017-08-23)
> > 	* 00ddc9d13c (Fix build with core.autocrlf=true, 2017-05-09)
> 
> One more commit that is missing: 492595cfc7 (git-gui (MinGW): make use of MSys2's msgfmt, 2017-07-25)
> 
> This commit is comes from the merge of js/msgfmt-on-windows, which has 
> all the commits from the merge 5ab7227 (Merge remote-tracking branch 'philoakley/dup-gui', 2017-03-18)
> in git-gui.
> 
> While merging js/msgfmt-on-windows should get this commit into git-gui, 
> I'd rather have it separate,
Any reason why you'd want to keep it separate?

I'm assuming you're referring to the commit that merges js/msgfmt-on-windows in:

	commit 90dbf226ba3fae0d932ae4e42d8d3122a47766bc
	Merge: 5800c63717 492595cfc7
	Author: Junio C Hamano <gitster@pobox.com>
	Date:   Jul 25 2017
		Merge branch 'js/msgfmt-on-windows' of ../git-gui into js/git-gui-msgfmt-on-windows
		
		* 'js/msgfmt-on-windows' of ../git-gui:
		  git-gui (MinGW): make use of MSys2's msgfmt
		  git gui: allow for a long recentrepo list
		  git gui: de-dup selected repo from recentrepo history
		  git gui: cope with duplicates in _get_recentrepo
		  git-gui: remove duplicate entries from .gitconfig's gui.recentrepo

Since js/msgfmt-on-windows is based on 5ab7227 (Merge remote-tracking branch 'philoakley/dup-gui', 2017-03-18), when it was merged into git.git's master, the merge brought in those other four commits by Philip Oakley since they weren't merged into git.git yet.

However, you're not going to be merging in the same list of commits if you merge into git-gui. You'll only end up merging in one commit: the missing 492595cfc7 (git-gui (MinGW): make use of MSys2's msgfmt, 2017-07-25). This is because Philip's commits are already in the git-gui repo.

Show 5 quoted lines
> 
> > 
> > Hope any of this is useful to anyone,
> 
> It is very useful. Thanks :)
Glad I could help!
> 
> -- 
> Regards,
> Pratyush Yadav
Junio C Hamano· Sep 18, 2019, 17:49 UTC · re: Pratyush Yadav · lore

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

Pratyush Yadav <me@yadavpratyush.com> writes:
Show 12 quoted lines
> Assuming I have git.git cloned in ../git (relative to git-gui.git), I 
> ran:
>
>   git pull -Xsubtree=git-gui ../git $branches
>
> instead of:
>
>   git merge $branches
>
> because git-gui's tree doesn't have those commits and branches yet, so 
> we can't merge straight away. This seems to have worked, but I thought 
> I'd mention it in case it would cause some subtle problems.

I am not sure what your $branches above are referring to, but if you run "git log" in the resulting git-gui repository and see any of the commits that are about git and not git-gui, then it is not a subtle but a grave problem. The reason why git-gui and gitk are separate projects is because they do not want to contaminate their history with stuff that are not related to them (e.g. changes to "git fast-export").

Taking one of the commits Denton found as an example:
>> 	js/misc-git-gui-stuff: 76756d67061076c046973bff2089ad49f5dc2eb6
(by the way, this can also be found by running
	git log --first-parent --min-parents=2 master -- git-gui

in git itself; 02a5f25d956be187bc0 merged it in as its second parent. The second parents of these merges you would find are candidates---you may already have some, and you may need to merge others to your tree; there may be some that are direct updates to git-gui/ part of my tree (which shouldn't have been done but mistakes happen).

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.

Thanks.
Pratyush Yadav· Sep 18, 2019, 19:22 UTC · re: Junio C Hamano · lore

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

On 18/09/19 10:49AM, Junio C Hamano wrote:
Show 16 quoted lines
> Pratyush Yadav <me@yadavpratyush.com> writes:
> 
> > Assuming I have git.git cloned in ../git (relative to git-gui.git), I 
> > ran:
> >
> >   git pull -Xsubtree=git-gui ../git $branches
> >
> > instead of:
> >
> >   git merge $branches
> >
> > because git-gui's tree doesn't have those commits and branches yet, so 
> > we can't merge straight away. This seems to have worked, but I thought 
> > I'd mention it in case it would cause some subtle problems.
> 
> I am not sure what your $branches above are referring to, but if you

The $branches is from Denton's script (its in his email that I replied to) that lists all the branches merged into git/git-gui that are not in git-gui. So it should essentially be all the branches not in my tree that should be.

Show 6 quoted lines
> run "git log" in the resulting git-gui repository and see any of the
> commits that are about git and not git-gui, then it is not a subtle
> but a grave problem.  The reason why git-gui and gitk are separate
> projects is because they do not want to contaminate their history
> with stuff that are not related to them (e.g. changes to "git
> fast-export").
No, I was only pulling in merges related to git-gui into my tree. I do 
not intend to pull in any other changes.
 
Show 7 quoted lines
> Taking one of the commits Denton found as an example:
> 
> >> 	js/misc-git-gui-stuff: 76756d67061076c046973bff2089ad49f5dc2eb6
> 
> (by the way, this can also be found by running
> 
> 	git log --first-parent --min-parents=2 master -- git-gui

Yes, that is what I was doing. Denton's script just made the tedious task of finding all those out easier.

Show 12 quoted lines
> in git itself; 02a5f25d956be187bc0 merged it in as its second
> parent.  The second parents of these merges you would find are
> candidates---you may already have some, and you may need to merge
> others to your tree; there may be some that are direct updates to
> git-gui/ part of my tree (which shouldn't have been done but
> mistakes happen).
>
> 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.

Well, technically it won't be a noop merge because my master has some changes that haven't been pulled by you yet, but I get the point. Thanks. I'll test this out.

-- 
Regards,
Pratyush Yadav
Pratyush Yadav· Sep 19, 2019, 18:32 UTC · re: Junio C Hamano · lore

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

Hi Junio,
On 18/09/19 10:49AM, Junio C Hamano wrote:
Show 6 quoted lines
> 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.

I then did a trial merge into your 'master', and running a diff, git.git's version of git-gui is identical to mine. So everything seems to be correct.

Instead of doing this on my master, I did it on a separate branch just to be sure I don't mess something up. You can find it on https://github.com/prati0100/git-gui.git on the branch 'trial_merge'.

These are the new commits introduced:
  7435f916d3 git-gui: fix build with core.autocrlf=true
  834e3ec31e git-gui: correct "up-to-date" to "up to date"
  fecfccf9ff Merge branches 'js/msgfmt-on-windows', 'tz/fsf-address-update', 'jn/reproducible-build', 'ls/no-double-utf8-author-name', 'js/misc-git-gui-stuff', 'bb/ssh-key-files', 'bp/bind-kp-enter', 'cb/ttk-style' and 'py/call-do-quit-before-exit' of ../git into trial_merge
  f7a8834ba4 Merge branch 'bp/amend-toggle-bind'
  ec7424e1a6 git-gui: add hotkey to toggle "Amend Last Commit"
  6c8ec8c30a Merge branch 'bw/commit-scrollbuffer'
  acfa495519 Merge branch 'bw/amend-checkbutton'
  da08d559b7 git-gui: add horizontal scrollbar to commit buffer
  ba41b5b335 git-gui: convert new/amend commit radiobutton to checkbutton
  c77abf0460 Merge branch 'py/revert-hunks-lines'
  5a2bb62180 Merge branch 'bp/widget-focus-hotkeys'
  e07446ed5f git-gui: add hotkeys to set widget focus
  a4fa2f0a4c git-gui: allow undoing last revert
  2ccdfb1c78 git-gui: return early when patch fails to apply
  62bd99934b git-gui: allow reverting selected hunk
  5f0a516de9 git-gui: allow reverting selected lines

The top 3 commits are of note. The top 2 are the manual backports. The third is the octopus merge of all the topics not in git-gui yet. The rest are just other topics that were introduced in my fork recently.

If it looks all good, I'll put all this on my 'master' and re-send the pull request.

-- 
Regards,
Pratyush Yadav
Denton Liu· Sep 19, 2019, 18:47 UTC · re: Pratyush Yadav · lore

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

On Fri, Sep 20, 2019 at 12:02:58AM +0530, Pratyush Yadav wrote:
Show 18 quoted lines
> 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.

From a correctness perspective, however, I compared my results after doing that with yours and it's identical.

Show 33 quoted lines
> I then did a trial merge into your 'master', and running a diff, 
> git.git's version of git-gui is identical to mine. So everything seems 
> to be correct.
> 
> Instead of doing this on my master, I did it on a separate branch just 
> to be sure I don't mess something up. You can find it on 
> https://github.com/prati0100/git-gui.git on the branch 'trial_merge'.
> 
> These are the new commits introduced:
> 
>   7435f916d3 git-gui: fix build with core.autocrlf=true
>   834e3ec31e git-gui: correct "up-to-date" to "up to date"
>   fecfccf9ff Merge branches 'js/msgfmt-on-windows', 'tz/fsf-address-update', 'jn/reproducible-build', 'ls/no-double-utf8-author-name', 'js/misc-git-gui-stuff', 'bb/ssh-key-files', 'bp/bind-kp-enter', 'cb/ttk-style' and 'py/call-do-quit-before-exit' of ../git into trial_merge
>   f7a8834ba4 Merge branch 'bp/amend-toggle-bind'
>   ec7424e1a6 git-gui: add hotkey to toggle "Amend Last Commit"
>   6c8ec8c30a Merge branch 'bw/commit-scrollbuffer'
>   acfa495519 Merge branch 'bw/amend-checkbutton'
>   da08d559b7 git-gui: add horizontal scrollbar to commit buffer
>   ba41b5b335 git-gui: convert new/amend commit radiobutton to checkbutton
>   c77abf0460 Merge branch 'py/revert-hunks-lines'
>   5a2bb62180 Merge branch 'bp/widget-focus-hotkeys'
>   e07446ed5f git-gui: add hotkeys to set widget focus
>   a4fa2f0a4c git-gui: allow undoing last revert
>   2ccdfb1c78 git-gui: return early when patch fails to apply
>   62bd99934b git-gui: allow reverting selected hunk
>   5f0a516de9 git-gui: allow reverting selected lines
> 
> The top 3 commits are of note. The top 2 are the manual backports. The 
> third is the octopus merge of all the topics not in git-gui yet. The 
> rest are just other topics that were introduced in my fork recently.
> 
> 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.
> 
> -- 
> Regards,
> Pratyush Yadav
Pratyush Yadav· Sep 19, 2019, 19:03 UTC · re: Denton Liu · lore

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

On 19/09/19 11:47AM, Denton Liu wrote:
Show 27 quoted lines
> 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 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
Denton Liu· Sep 19, 2019, 19:11 UTC · re: Pratyush Yadav · lore

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

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
Denton Liu· Sep 19, 2019, 19:33 UTC · re: Denton Liu · lore

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

On Thu, Sep 19, 2019 at 12:11:05PM -0700, Denton Liu wrote:
> > > For the record, you could do a
> > > 
> > > 	git cherry-pick -Xsubtree=git-gui 00ddc9d13c 7560f547e6

I forgot one more thing, if you end up doing this, you should probably sign-off on your cherry-picks by doing `-s`.

Pratyush Yadav· Sep 24, 2019, 14:06 UTC · re: Denton Liu · lore

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

On 19/09/19 12:11PM, Denton Liu wrote:
Show 31 quoted lines
> On Fri, Sep 20, 2019 at 12:33:59AM +0530, Pratyush Yadav wrote:
> > On 19/09/19 11:47AM, Denton Liu wrote:
> > > 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.
It works. Thanks.
-- 
Regards,
Pratyush Yadav
Junio C Hamano· Sep 18, 2019, 17:31 UTC · re: Birger Skogeng Pedersen · lore

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

Birger Skogeng Pedersen <birger.sp@gmail.com> writes:
> For example, I created a patch back in March 2018[3]. Junio pulled it
> so the changes are really there in git/git-gui/git-gui.sh (see this[4]
> line). This was while there was no git-gui maintainer. I guess the
> change never got merged to git-gui, but directly to git.
Thanks for noticing.  

I do recall forking Pat's tree, applying a few patches and pulling the result to git itself while asking Pat to pull from me to get these patches. Perhaps these were not merged back before Pratyush inherited the tree.

← back to recent threads