All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: David Kastrup <dak@gnu.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Alexandre Bourget <alexandre.bourget@savoirfairelinux.com>,
	Git Mailing List <git@vger.kernel.org>,
	paulus@samba.org
Subject: Re: [PATCH] Mod. gitk to support REBASE (with stash support).
Date: Thu, 9 Aug 2007 03:21:47 -0400	[thread overview]
Message-ID: <20070809072147.GD24573@spearce.org> (raw)
In-Reply-To: <20070809065810.GC24573@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> David Kastrup <dak@gnu.org> wrote:
> > other than on the current HEAD.  No diff, no file view, no rebase,
> > nothing.
> 
> So your assertion that git-gui only works with one commit, HEAD,
> is wrong.

Oh, and git-gui has some features that don't even really exist in the
shell porcelain.  E.g. you can do this all from the Branch->Create
dialog in git-gui:

  b=refs/heads/branch-to-create
  git fetch origin foof:refs/remotes/origin/foof &&
  if test git show-ref $b
  then
    git push . refs/remotes/origin/foof:$b
  else
    git branch $b refs/remotes/origin/foof
  fi &&
  git checkout foof

That's actually somewhat hard to do on the command line, but as
it turns out is just insanely handy to have for some workflows.
It amounts to "Always fetch the remote tracking branch, make sure
my local branch will fast-forward to it, do so, then checkout my
local branch; but if the local branch doesn't exist create it,
then do the checkout anyway".

I used git-push above just because its handy to do the fast-forward
check and update if successful; that's not what git-gui uses
internally because its actually a really stupid abuse of the
push command.  But it was shorter to write out the shell code for
this email.  Wow, OK, I just spent more time explaining why I used
git-push than to just write the damn fast-forward test.  Whatever.

I count 1-2 commits in that operation, depending on if your local
branch exists or not.  Oh, and this nifty thing called a remote.


But you are correct to some extent, there's no diff of a prior commit
available from within git-gui.  Or rebase.  I'd like to fix both.
But its time for sleep instead.  Oh, and I'm supposed to be fixing
some "features" of fast-import this week too...

-- 
Shawn.

  reply	other threads:[~2007-08-09  7:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-08 18:33 [PATCH] Mod. gitk to support REBASE (with stash support) Alexandre Bourget
2007-08-08 19:31 ` Peter Baumann
2007-08-08 19:42 ` Johannes Schindelin
2007-08-08 20:08   ` David Kastrup
2007-08-09  3:26     ` Shawn O. Pearce
2007-08-09  5:51       ` David Kastrup
2007-08-09  6:58         ` Shawn O. Pearce
2007-08-09  7:21           ` Shawn O. Pearce [this message]
2007-08-09  7:55           ` David Kastrup
2007-08-08 19:53 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070809072147.GD24573@spearce.org \
    --to=spearce@spearce.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=alexandre.bourget@savoirfairelinux.com \
    --cc=dak@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.