Re: Merge git-gui into 1.5.0 ?

"Shawn O. Pearce" [off-list ref] writes:

One of my goals for git-gui is to get it merged into core Git, so
there is a GUI tool available out-of-the-box for commit creation,
(some) branch manipulation, basic merging, and pushing/fetching
changes.

I do not have objection per-se, but I have two choices on the
procedure, and I hate having choices this close to the final
release ;-).

(1) I can do the usual 'no common ancestor' merge, and treat it
    just like gitk.  I would probably place git-gui as a
    subdirectory in git.git (just like I did to gitweb/), and
    tweak the main Makefile to chdir down to git-gui, and let
    the git-gui/Makefile (the toplevel Makefile from your point
    of view) do its work.  Your current git-gui repository that
    does not have rest of git.git will _remain_ git-less.  In
    addition, git-gui repository remains to be the authoritative
    place its improvements take place.  git.git pull from there
    from time to time to get updates.

(2) After the 'no common ancestor' merge above, you fast forward
    git-gui to git.git and two repositories can cross pull from
    each other from that point on.

I have a suspicion that doing the former may turn out to be a
good demonstration that git supports subprojects already.  The
toplevel project _knows_ about subproject, but the subproject
does not have to be aware of the toplevel project.  Granted, the
toplevel project knows which specific version of the subproject
is bound to each of its commit, which is tighter integration
than what usually is desired, but still it is a form of
subproject support that may be useful.

I was actually hoping I can do so with Kay, but from his point
of view merging gitweb to git.git was so that he does not have
to worry about it anymore, so it did not work well.

Junio C Hamano [off-list ref] wrote:

I do not have objection per-se, but I have two choices on the
procedure, and I hate having choices this close to the final
release ;-).

...

I was actually hoping I can do so with Kay, but from his point
of view merging gitweb to git.git was so that he does not have
to worry about it anymore, so it did not work well.

I'm OK with either approach here.

Originally I had intended to wipe out everything except git-gui.sh,
then do an ancestor-less merge into git.git's top level directory,
and finally tweak git.git's master Makefile to add git-gui.sh to
the list of known shell scripts.  Then I was going to ask you to
pull that resulting tree.

But it may make a *lot* more sense to treat is a true subproject in
its own directory.  Unlike Kay, I'm not looking to merge git-gui
into git.git to abandon it.  I just think we should offer a GUI
out of the box, git-gui has the same dependencies as gitk, and I
happen to like git-gui.  ;-)

git-gui development is going to continue past 1.5.0's release.
There are still a lot of operations it should support that it
currently does not do, and there are certainly user interface
improvements that can still be made.

It may be saner for all involved if that development happens in
the git-gui.git repository, with drops made to git.git by way of
merging the "subproject" every so often.

It may make patching slightly more interesting though, as some
users new to git-gui development may generate a patch in git.git
(using a/git-gui/git-gui.sh as the path) which then would not apply
as-is to the master git-gui development tree.

Entirely your call Junio.

-- 
Shawn.

Hi,

On Sun, 11 Feb 2007, Shawn O. Pearce wrote:

Unlike Kay, I'm not looking to merge git-gui into git.git to abandon it.

That's great!

It may be saner for all involved if that development happens in the 
git-gui.git repository, with drops made to git.git by way of merging the 
"subproject" every so often.

Fully agree.

It may make patching slightly more interesting though, as some
users new to git-gui development may generate a patch in git.git
(using a/git-gui/git-gui.sh as the path) which then would not apply
as-is to the master git-gui development tree.

In this case, a "-p <n>" option to git-am would make sense, no?

Ciao,
Dscho

Johannes Schindelin [off-list ref] wrote:

quoted

It may make patching slightly more interesting though, as some
users new to git-gui development may generate a patch in git.git
(using a/git-gui/git-gui.sh as the path) which then would not apply
as-is to the master git-gui development tree.

In this case, a "-p <n>" option to git-am would make sense, no?

Are you saying we just suddenly found a vaild use for a flag which
nobody (except the original submitter) thought was useful?  ;-)

Yes, clearly a -p<n> on git-am would solve the problem quite nicely.

-- 
Shawn.

Hi,

On Sun, 11 Feb 2007, Shawn O. Pearce wrote:

Johannes Schindelin [off-list ref] wrote:

quoted

quoted

It may make patching slightly more interesting though, as some
users new to git-gui development may generate a patch in git.git
(using a/git-gui/git-gui.sh as the path) which then would not apply
as-is to the master git-gui development tree.

In this case, a "-p <n>" option to git-am would make sense, no?

Are you saying we just suddenly found a vaild use for a flag which
nobody (except the original submitter) thought was useful?  ;-)

That was my plan. But I was too lazy to look up the original poster...

Ciao,
Dscho

Quoting Shawn O. Pearce [off-list ref]:
Subject: Re: Merge git-gui into 1.5.0 ?

Johannes Schindelin [off-list ref] wrote:

quoted

quoted

It may make patching slightly more interesting though, as some
users new to git-gui development may generate a patch in git.git
(using a/git-gui/git-gui.sh as the path) which then would not apply
as-is to the master git-gui development tree.

In this case, a "-p <n>" option to git-am would make sense, no?

Are you saying we just suddenly found a vaild use for a flag which
nobody (except the original submitter) thought was useful?  ;-)

Yes, clearly a -p<n> on git-am would solve the problem quite nicely.

Actually, -p<n> option to git-am is also useful for piping
patches to git-am directly from mail: sometimes people would generate
a patch by hand and this results in patches incorrect -p level.
	
-- 
MST

"Shawn O. Pearce" [off-list ref] writes:

git-gui development is going to continue past 1.5.0's release.
There are still a lot of operations it should support that it
currently does not do, and there are certainly user interface
improvements that can still be made.

It may be saner for all involved if that development happens in
the git-gui.git repository, with drops made to git.git by way of
merging the "subproject" every so often.

Ok, so here is what I did last night.

$ git remote show git-gui
* remote git-gui
  URL: git://repo.or.cz/git-gui.git/
  Tracked remote branches
    master
$ git fetch git-gui
$ git read-tree --prefix=git-gui/ git-gui/master
$ git checkout git-gui
$ git rev-parse git-gui/master >.git/MERGE_HEAD
$ git commit

Junio C Hamano [off-list ref] wrote:

"Shawn O. Pearce" [off-list ref] writes:

quoted

It may be saner for all involved if that development happens in
the git-gui.git repository, with drops made to git.git by way of
merging the "subproject" every so often.

Ok, so here is what I did last night.

$ git remote show git-gui
* remote git-gui
  URL: git://repo.or.cz/git-gui.git/
  Tracked remote branches
    master
$ git fetch git-gui
$ git read-tree --prefix=git-gui/ git-gui/master
$ git checkout git-gui
$ git rev-parse git-gui/master >.git/MERGE_HEAD
$ git commit

I just sent you a patch for Makefile in git.git to build git-gui.
I've also setup things so git-gui's versions track independently of
git, yet the correct versions are embedded into the release tarball
and executable in both the standalone and embedded-in-git cases.
A true subproject!

For this to work the gitgui-* tags need to be fetched into your
repository.  I also took the assumption that the git-gui subdirectory
is never modified in git.git, but only through merging git-gui's
commit history.

To play nice I'm prefixing the git-gui tags with 'gitgui-', rather
than 'v', so that they don't conflict with git's own version numbers
within the refs/tags namespace.

I am signing gitgui tags with a GPG key. For ease of distribution
my public key was tagged under spearce-gpg-pub.  The hash for
spearce-gpg-pub is 8bb563fb25a372a9cb14f0a9b9015d409fd82c16.

I'm not sure if it makes sense to push the gitgui-* tags (or
spearce-gpg-pub) to the public git.git repository.  If these tags
aren't present then git-gui will fail to get its version number
and fallback on the hardcoded value in git-gui/GIT-VERSION-GEN.
Anyone who really cares that this is correct could just fetch
the tags on their own from repo.or.cz.

Here's the script I was working with to merge git-gui into git.git:

-->8--
#!/bin/sh

remote=git-gui
branch=master

git-fetch $remote &&
ggh=$(git-rev-parse $remote/$branch) &&
ggt=$(git-rev-parse $ggh^{tree}) &&
tree=$(git ls-tree HEAD \
	| sed "/	git-gui/s/tree .*	/tree $ggt	/" \
	| git mktree) &&
git-read-tree -m -u --exclude-per-directory=.gitignore HEAD $tree &&
git-update-ref ORIG_HEAD HEAD &&
git-update-ref MERGE_HEAD $ggh &&
msg="Merge branch '$branch' of $(git-config remote.$remote.url)

Update to version $(git describe --abbrev=4 $ggh).
" &&
echo "$msg" >.git/MERGE_MSG &&
echo "Merge complete.  Please commit the result." ||
exit
-->8--

-- 
Shawn.

Hi,

On Mon, 12 Feb 2007, Junio C Hamano wrote:

Ok, so here is what I did last night.

$ git remote show git-gui
* remote git-gui
  URL: git://repo.or.cz/git-gui.git/
  Tracked remote branches
    master
$ git fetch git-gui
$ git read-tree --prefix=git-gui/ git-gui/master
$ git checkout git-gui

Didn't you mean "git checkout master" here?

$ git rev-parse git-gui/master >.git/MERGE_HEAD
$ git commit

Ciao,
Dscho

Johannes Schindelin [off-list ref] wrote:

On Mon, 12 Feb 2007, Junio C Hamano wrote:

quoted

Ok, so here is what I did last night.

$ git remote show git-gui
* remote git-gui
  URL: git://repo.or.cz/git-gui.git/
  Tracked remote branches
    master
$ git fetch git-gui
$ git read-tree --prefix=git-gui/ git-gui/master
$ git checkout git-gui

Didn't you mean "git checkout master" here?

I don't think so.  At this point the subdirectory git-gui is known
in the index, so Junio is trying to get checkout-index to process
those paths and create it in the working directory.
 

quoted

$ git rev-parse git-gui/master >.git/MERGE_HEAD
$ git commit

-- 
Shawn.

Hi,

On Mon, 12 Feb 2007, Shawn O. Pearce wrote:

Johannes Schindelin [off-list ref] wrote:

quoted

On Mon, 12 Feb 2007, Junio C Hamano wrote:

quoted

Ok, so here is what I did last night.

$ git remote show git-gui
* remote git-gui
  URL: git://repo.or.cz/git-gui.git/
  Tracked remote branches
    master
$ git fetch git-gui
$ git read-tree --prefix=git-gui/ git-gui/master
$ git checkout git-gui

Didn't you mean "git checkout master" here?

I don't think so.  At this point the subdirectory git-gui is known
in the index, so Junio is trying to get checkout-index to process
those paths and create it in the working directory.

Ah! Thanks,
Dscho

Johannes Schindelin wrote:

On Mon, 12 Feb 2007, Shawn O. Pearce wrote:

quoted

Johannes Schindelin [off-list ref] wrote:

quoted

On Mon, 12 Feb 2007, Junio C Hamano wrote:

quoted

Ok, so here is what I did last night.

$ git remote show git-gui
* remote git-gui
  URL: git://repo.or.cz/git-gui.git/
  Tracked remote branches
    master
$ git fetch git-gui
$ git read-tree --prefix=git-gui/ git-gui/master
$ git checkout git-gui

Didn't you mean "git checkout master" here?

I don't think so.  At this point the subdirectory git-gui is known
in the index, so Junio is trying to get checkout-index to process
those paths and create it in the working directory.

Ah! Thanks,
Dscho

So it is "git checkout -- git-gui" then?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Jakub Narebski [off-list ref] wrote:

quoted

On Mon, 12 Feb 2007, Shawn O. Pearce wrote:

quoted

Johannes Schindelin [off-list ref] wrote:

quoted

On Mon, 12 Feb 2007, Junio C Hamano wrote:

quoted

$ git read-tree --prefix=git-gui/ git-gui/master
$ git checkout git-gui

Didn't you mean "git checkout master" here?

I don't think so.  At this point the subdirectory git-gui is known
in the index, so Junio is trying to get checkout-index to process
those paths and create it in the working directory.

So it is "git checkout -- git-gui" then?

Yes.  But this trick only works once.  After that you cannot use
`read-tree --prefix` to load the index with the git-gui/master
branch, as there already is stuff under git-gui.  Instead you need
to whack the directory's files from the index, then reload it.

Or abuse mktree, as I did in the script I posted.

-- 
Shawn.