Merge git-gui into 1.5.0 ?

Merge git-gui into 1.5.0 ?

[Shawn O. Pearce]

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.

Re: Merge git-gui into 1.5.0 ?

[Mark Levedahl]

Shawn O. Pearce wrote:
> 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

Re: Merge git-gui into 1.5.0 ?

[Shawn O. Pearce]

Mark Levedahl <mdl123@verizon.net> wrote:
> 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.

Re: Merge git-gui into 1.5.0 ?

[Johannes Schindelin]

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

Re: Merge git-gui into 1.5.0 ?

[Junio C Hamano]

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

Re: Merge git-gui into 1.5.0 ?

[Shawn O. Pearce]

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.

Re: Merge git-gui into 1.5.0 ?

[Johannes Schindelin]

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

Re: Merge git-gui into 1.5.0 ?

[Shawn O. Pearce]

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.

-- 
Shawn.

Re: Merge git-gui into 1.5.0 ?

[Johannes Schindelin]

Hi,

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

> 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

Re: Merge git-gui into 1.5.0 ?

[Michael S. Tsirkin]

> 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

Re: Merge git-gui into 1.5.0 ?

[Junio C Hamano]

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

 

Re: Merge git-gui into 1.5.0 ?

[Michael S. Tsirkin]

> 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

Re: Merge git-gui into 1.5.0 ?

[Michael S. Tsirkin]

> 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

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

[Johannes Schindelin]

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

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

[Michael S. Tsirkin]

> 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

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

[Johannes Schindelin]

Hi,

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

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

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

[Michael S. Tsirkin]

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

Re: Merge git-gui into 1.5.0 ?

[Junio C Hamano]

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

Re: Merge git-gui into 1.5.0 ?

[Shawn O. Pearce]

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

Re: Merge git-gui into 1.5.0 ?

[Johannes Schindelin]

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

Re: Merge git-gui into 1.5.0 ?

[Shawn O. Pearce]

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.
 
> > $ git rev-parse git-gui/master >.git/MERGE_HEAD
> > $ git commit

-- 
Shawn.

Re: Merge git-gui into 1.5.0 ?

[Johannes Schindelin]

Hi,

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

Re: Merge git-gui into 1.5.0 ?

[Jakub Narebski]

Johannes Schindelin wrote:
> 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

Re: Merge git-gui into 1.5.0 ?

[Shawn O. Pearce]

Jakub Narebski <jnareb@gmail.com> wrote:
> > 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.