threads / discuss / 6765

Merge git-gui into 1.5.0 ?

Subject: Merge git-gui into 1.5.0 ?

## tl;dr

24 messages between Feb 11, 2007 and Feb 13, 2007.

replies: 23people: 6as markdown or json

Shawn O. Pearce· Feb 11, 2007, 08:40 UTC · lore

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'm wondering, should that start to occur as part of 1.5.0? Its one .sh script, like gitk. :)

Given all of the other changes going into 1.5.0, and how much news we're probably going to try to attract to this release, it may be nice to be able to say "we also have a commit creating GUI".

The main idea behind git-gui is to provide a complete enough UI that someone can work on files stored in a Git repository without needing to drop to the command line. By sticking to Tcl/Tk, git-gui is available anywhere gitk is.

It would be nice if all operations available on the command line were also available through git-gui, but I think that is a very difficult goal to reach. The command line interface is simply more powerful and much more expressive. So I'm really just aiming to make an interface that the average user can use to do collaboration through Git, without needing to fall back on git-cvsserver and a CVS client. I fully expect 'power' users to use the command line. You know who you are. ;-)

That said, operations like `git gui blame rev file` may simply be better in the GUI, even for power users, as it offers some way to visualize the annotation data and navigate through it. So I'm also trying to make those parts of git-gui easily available from the command line, when possible.

Another example is `git gui citool` (or `git citool` if git-citool is a symlink/hardlink to git-gui), which will open the UI for just one commit. Users of that-other-SCM-used-before-Git's citool subcommand may like this feature, as it offers somewhat similiar functionality, and some nice extras. ;-)

Right now git-gui is being used in production by myself and about 5 other coworkers of mine (the rest were either die-hard command line users already, or found out how useful the command line is and now refuse to give it up!). It has thus far proven to be pretty stable and easy to use. Its running stably on both Mac OS X and Windows.

It is also lacking the critical `git clone` operation.  ;-)

Thoughts?  Anyone interested can check out the repository:

  gitweb:  http://repo.or.cz/w/git-gui.git
  git:     git://repo.or.cz/git-gui.git

-- 
Shawn.

Mark Levedahl· Feb 11, 2007, 14:57 UTC · re: Shawn O. Pearce · lore

Re: Merge git-gui into 1.5.0 ?

Shawn O. Pearce wrote:

Show 8 quoted lines

> 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'm wondering, should that start to occur as part of 1.5.0?
> Its one .sh script, like gitk.  :)
>

I have recently moved a project involving multiple companies developing on Windows and Linux from cvs(nt) over to git. The availability of git-gui at the time was an important point: many folks working this project simply will not work at the command line. We are still spinning up on git, but several of the developers are relying upon git-gui now and I expect that most will use it. So, I am definitely for moving git-gui into git. It definitely fits well with the 1.5 usability theme.

Side note: with my gitk fix for Cygwin now in master, git-gui should not be deleting ~/.gitk on Cygwin anymore.

Whatever the decision: Shawn - thank you for developing this.

Mark Levedahl

Shawn O. Pearce· Feb 11, 2007, 22:49 UTC · re: Mark Levedahl · lore

Re: Merge git-gui into 1.5.0 ?

Mark Levedahl <mdl123@verizon.net> wrote:

Show 7 quoted lines

> I have recently moved a project involving multiple companies developing 
> on Windows and Linux from cvs(nt) over to git. The availability of 
> git-gui at the time was an important point: many folks working this 
> project simply will not work at the command line. We are still spinning 
> up on git, but several of the developers are relying upon git-gui now 
> and I expect that most will use it. So, I am definitely for moving 
> git-gui into git. It definitely fits well with the 1.5 usability theme.

I'm glad git-gui has helped you migrate a team away from CVS. The case you are describing is definately one of the reasons for creating git-gui.

> Side note: with my gitk fix for Cygwin now in master, git-gui should not 
> be deleting ~/.gitk on Cygwin anymore.

Gah. I forgot about that feature of git-gui.  It is now removed,
and a new version has been pushed out.  Thank you for the reminder!

> Whatever the decision: Shawn - thank you for developing this.

You are most welecome.  :)

Paul Mackerras deserves some credit too, as his prototype gitool was the original insipiration behind git-gui. And his icons are still in use within git-gui.

-- 
Shawn.

Johannes Schindelin· Feb 11, 2007, 16:39 UTC · re: Shawn O. Pearce · lore

Re: Merge git-gui into 1.5.0 ?

Hi,

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

> I'm wondering, should that start to occur as part of 1.5.0? Its one .sh 
> script, like gitk.  :)

It really does not touch a core part of git, but adds value. Given that we already include gitk, and that git-gui apparently got quite some testing, I am all for it.

Ciao, Dscho

Junio C Hamano· Feb 11, 2007, 22:27 UTC · re: Shawn O. Pearce · lore

Re: Merge git-gui into 1.5.0 ?

"Shawn O. Pearce" <spearce@spearce.org> 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.

Shawn O. Pearce· Feb 11, 2007, 22:41 UTC · re: Junio C Hamano · lore

Re: Merge git-gui into 1.5.0 ?

Junio C Hamano <junkio@cox.net> 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.

Johannes Schindelin· Feb 11, 2007, 22:53 UTC · re: Shawn O. Pearce · lore

Re: Merge git-gui into 1.5.0 ?

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

Shawn O. Pearce· Feb 11, 2007, 23:02 UTC · re: Johannes Schindelin · lore

Re: Merge git-gui into 1.5.0 ?

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 6 quoted lines

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

Johannes Schindelin· Feb 11, 2007, 23:25 UTC · re: Shawn O. Pearce · lore

Re: Merge git-gui into 1.5.0 ?

Hi,

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

Show 10 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > 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

Michael S. Tsirkin· Feb 12, 2007, 05:40 UTC · re: Shawn O. Pearce · lore

Re: Merge git-gui into 1.5.0 ?

Show 15 quoted lines

> Quoting Shawn O. Pearce <spearce@spearce.org>:
> Subject: Re: Merge git-gui into 1.5.0 ?
> 
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > 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

Junio C Hamano· Feb 12, 2007, 05:48 UTC · re: Michael S. Tsirkin · lore

Re: Merge git-gui into 1.5.0 ?

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:

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

You also would need negative -p option to deal with it as well. Think of getting "diff a/git-add.txt b/git-add.txt" and wanting to apply it to Documentation/git-add.txt.

Michael S. Tsirkin· Feb 12, 2007, 05:59 UTC · re: Junio C Hamano · lore

Re: Merge git-gui into 1.5.0 ?

Show 12 quoted lines

> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: Merge git-gui into 1.5.0 ?
> 
> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> 
> > 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.
> 
> You also would need negative -p option to deal with it as well.
> Think of getting "diff a/git-add.txt b/git-add.txt" and wanting
> to apply it to Documentation/git-add.txt.

Heh, right. With patch I just switch to another shell, cd to the correct directory, start mutt *there* and pipe the message to patch. Since this already seems to work for git-apply, maybe this can be made to work with git-am as well?

Currently: $git-am mbox fatal: Not a git repository: '.git' You need to run this command from the toplevel of the working tree.

-- 
MST

Michael S. Tsirkin· Feb 12, 2007, 06:25 UTC · re: Michael S. Tsirkin · lore

Re: Merge git-gui into 1.5.0 ?

Show 24 quoted lines

> Quoting Michael S. Tsirkin <mst@mellanox.co.il>:
> Subject: Re: Merge git-gui into 1.5.0 ?
> 
> > Quoting Junio C Hamano <junkio@cox.net>:
> > Subject: Re: Merge git-gui into 1.5.0 ?
> > 
> > "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> > 
> > > 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.
> > 
> > You also would need negative -p option to deal with it as well.
> > Think of getting "diff a/git-add.txt b/git-add.txt" and wanting
> > to apply it to Documentation/git-add.txt.
> 
> Heh, right. With patch I just switch to another shell, cd to the correct
> directory, start mutt *there* and pipe the message to patch.  Since this already
> seems to work for git-apply, maybe this can be made to work with git-am as well?
> 
> Currently:
> $git-am mbox
> fatal: Not a git repository: '.git'
> You need to run this command from the toplevel of the working tree.

Junio, the following seems to work for me. Is this correct? If yes, adding -p is trivial.

Make git-am support "negative strip-level" patches by running it in a subdirectory.

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>

---

diff --git a/git-am.sh b/git-am.sh
index 9a61234..4cea1d2 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -5,6 +5,8 @@
 USAGE='[--signoff] [--dotest=<dir>] [--utf8 | --no-utf8] [--binary] [--3way]
   [--interactive] [--whitespace=<option>] [-CNUM] <mbox>...
   or, when resuming [--skip | --resolved]'
+where=$PWD
+SUBDIRECTORY_OK=Yes
 . git-sh-setup
 set_reflog_action am
 require_work_tree
@@ -60,7 +62,7 @@ fall_back_3way () {
     mkdir "$dotest/patch-merge-tmp-dir"
 
     # First see if the patch records the index info that we can use.
-    git-apply -z --index-info "$dotest/patch" \
+    (cd $where && git-apply -z --index-info "$dotest/patch") \
 	>"$dotest/patch-merge-index-info" &&
     GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
     git-update-index -z --index-info <"$dotest/patch-merge-index-info" &&
@@ -69,8 +71,8 @@ fall_back_3way () {
     cannot_fallback "Patch does not record usable index information."
 
     echo Using index info to reconstruct a base tree...
-    if GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
-	git-apply $binary --cached <"$dotest/patch"
+    if (cd $where && GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
+	git-apply $binary --cached <"$dotest/patch")
     then
 	mv "$dotest/patch-merge-base+" "$dotest/patch-merge-base"
 	mv "$dotest/patch-merge-tmp-index" "$dotest/patch-merge-index"
@@ -398,7 +400,7 @@ do
 
 	case "$resolved" in
 	'')
-		git-apply $git_apply_opt $binary --index "$dotest/patch"
+		(cd $where && git-apply $git_apply_opt $binary --index "$dotest/patch")
 		apply_status=$?
 		;;
 	t)

-- 
MST

Johannes Schindelin· Feb 12, 2007, 11:51 UTC · re: Michael S. Tsirkin · lore

add negative -p to git-am, Re: Merge git-gui into 1.5.0 ?

Hi,

On Mon, 12 Feb 2007, Michael S. Tsirkin wrote:

> Make git-am support "negative strip-level" patches by running it in a 
> subdirectory.

I'd rather hide this behind a command line switch to git-am, since it _is_ a feature that you do not have to cd to the repo root when git-am'ing correct patches.

Ciao, Dscho

Michael S. Tsirkin· Feb 12, 2007, 11:59 UTC · re: Johannes Schindelin · lore

Re: add negative -p to git-am, Re: Merge git-gui into 1.5.0 ?

Show 13 quoted lines

> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Subject: add negative -p to git-am, Re: Merge git-gui into 1.5.0 ?
> 
> Hi,
> 
> On Mon, 12 Feb 2007, Michael S. Tsirkin wrote:
> 
> > Make git-am support "negative strip-level" patches by running it in a 
> > subdirectory.
> 
> I'd rather hide this behind a command line switch to git-am, since it _is_ 
> a feature that you do not have to cd to the repo root when git-am'ing 
> correct patches.

Maybe it *could* be a nice feature, but it does *not* currently work, so this patch is not breaking anything:

$git-am mbox fatal: Not a git repository: '.git' You need to run this command from the toplevel of the working tree.

And I think git-am is really similiar to git-apply functionally, so it should work in a similiar manner.

-- 
MST

Johannes Schindelin· Feb 12, 2007, 12:06 UTC · re: Michael S. Tsirkin · lore

Re: add negative -p to git-am, Re: Merge git-gui into 1.5.0 ?

Hi,

On Mon, 12 Feb 2007, Michael S. Tsirkin wrote:

Show 15 quoted lines

> > Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > Subject: add negative -p to git-am, Re: Merge git-gui into 1.5.0 ?
> > 
> > Hi,
> > 
> > On Mon, 12 Feb 2007, Michael S. Tsirkin wrote:
> > 
> > > Make git-am support "negative strip-level" patches by running it in a 
> > > subdirectory.
> > 
> > I'd rather hide this behind a command line switch to git-am, since it _is_ 
> > a feature that you do not have to cd to the repo root when git-am'ing 
> > correct patches.
> 
> Maybe it *could* be a nice feature, but it does *not* currently work,

yes, I read your email. My point was more to allow both use cases, and hide the more obscure one behind an option.

> And I think git-am is really similiar to git-apply functionally, so
> it should work in a similiar manner.

Except git-apply works without a repository, too.

Ciao, Dscho

Michael S. Tsirkin· Feb 12, 2007, 12:26 UTC · re: Johannes Schindelin · lore

Re: add negative -p to git-am, Re: Merge git-gui into 1.5.0 ?

Show 11 quoted lines

> > > > Make git-am support "negative strip-level" patches by running it in a 
> > > > subdirectory.
> > > 
> > > I'd rather hide this behind a command line switch to git-am, since it _is_ 
> > > a feature that you do not have to cd to the repo root when git-am'ing 
> > > correct patches.
> > 
> > Maybe it *could* be a nice feature, but it does *not* currently work,
> 
> yes, I read your email. My point was more to allow both use cases, and 
> hide the more obscure one behind an option.

I guess one person's obscure case is the other's common one.

-- 
MST

Junio C Hamano· Feb 12, 2007, 21:55 UTC · re: Shawn O. Pearce · lore

Re: Merge git-gui into 1.5.0 ?

"Shawn O. Pearce" <spearce@spearce.org> writes:

Show 8 quoted lines

> 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

Shawn O. Pearce· Feb 12, 2007, 23:34 UTC · re: Junio C Hamano · lore

Re: Merge git-gui into 1.5.0 ?

Junio C Hamano <junkio@cox.net> wrote:

Show 17 quoted lines

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > 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.

Johannes Schindelin· Feb 12, 2007, 23:38 UTC · re: Junio C Hamano · lore

Re: Merge git-gui into 1.5.0 ?

Hi,

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

Show 10 quoted lines

> 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

Shawn O. Pearce· Feb 12, 2007, 23:42 UTC · re: Johannes Schindelin · lore

Re: Merge git-gui into 1.5.0 ?

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 14 quoted lines

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

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.

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

-- 
Shawn.

Johannes Schindelin· Feb 12, 2007, 23:53 UTC · re: Shawn O. Pearce · lore

Re: Merge git-gui into 1.5.0 ?

Hi,

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

Show 19 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > 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?
> 
> 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

Jakub Narebski· Feb 13, 2007, 00:34 UTC · re: Johannes Schindelin · lore

Re: Merge git-gui into 1.5.0 ?

Johannes Schindelin wrote:

Show 23 quoted lines

> On Mon, 12 Feb 2007, Shawn O. Pearce wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>> 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?
>> 
>> 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

Shawn O. Pearce· Feb 13, 2007, 00:38 UTC · re: Jakub Narebski · lore

Re: Merge git-gui into 1.5.0 ?

Jakub Narebski <jnareb@gmail.com> wrote:

Show 13 quoted lines

> > On Mon, 12 Feb 2007, Shawn O. Pearce wrote:
> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >>> On Mon, 12 Feb 2007, Junio C Hamano wrote:
> >>>> $ 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.