git-gui: missing some patches from git?

git-gui: missing some patches from git?

[Birger Skogeng Pedersen]

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

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

[Denton Liu]

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.
> 
> [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

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

[Pratyush Yadav]

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.

> 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?
 
> 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

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

[Denton Liu]

On Wed, Sep 18, 2019 at 08:44:04PM +0530, Pratyush Yadav wrote:
> 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.

> 
> > 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.

>  
> > 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.

> 
> > 
> > Hope any of this is useful to anyone,
> 
> It is very useful. Thanks :)

Glad I could help!

> 
> -- 
> Regards,
> Pratyush Yadav

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

[Junio C Hamano]

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
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.

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

[Pratyush Yadav]

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

> 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.
 
> 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.

> 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

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

[Pratyush Yadav]

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.

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

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

[Denton Liu]

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.

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

> 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

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

[Pratyush Yadav]

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 
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

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

[Denton Liu]

On Fri, Sep 20, 2019 at 12:33:59AM +0530, Pratyush Yadav wrote:
> 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.

> 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

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

[Denton Liu]

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`.

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

[Pratyush Yadav]

On 19/09/19 12:11PM, Denton Liu wrote:
> 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

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

[Junio C Hamano]

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.