From: David Kastrup <hidden> Date: 2016-06-15 22:43:28
"Shawn O. Pearce" [off-list ref] writes:
David Kastrup [off-list ref] wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
General question: should this not be in git-gui rather than gitk? Gitk as
of now is really more a viewing tool.
Well, yes. But git-gui only works on a single branch head at a time,
and that is not enough for rebasing.
Sure. But so does git's command line tools. They tend to only
work on a single branch at time, the one called `HEAD`.
"tend", and many accept an explicit override: rebase accepts three
commit names, for example. Those that _write_ into the repository
usually _end_ up at HEAD, but most need not start there.
And git-gui does not have any operation either looking at or working
other than on the current HEAD. No diff, no file view, no rebase,
nothing.
So "single branch head at a time" is *not* why git-gui doesn't
support rebase. Its because nobody has gotten around to writing it.
I never claimed that it is not possible to put a rebase in there (the
patch does this, after all). I just said that it does not _fit_ in
there since you can't actually look at what you are rebasing on.
quoted
Could git-gui perhaps be merged with giggle at some point of time?
Unlikely. A while ago I considered "Stay in Tcl/Tk or move to
something more 'powerful/better/faster/Linus friendly'" and stayed
in Tcl/Tk. I doubt git-gui will leave Tcl/Tk. giggle is Gtk based.
My bad: git-gui has a nice polished look on my systems (Ubuntu Feisty)
while gitk has an ugly retro-blockish old-font Tk look; so not looking
at the innards, I had assumed they were implemented using different
systems.
I decided that any sort of rebase operation in git-gui must be *at
least* as easy to use/user friendly as `rebase -i` is. Anything
less is just mocking the end-user. Or something like that. Anyway,
since git-gui is restricted to a graphical interface and most such
interfaces have these pointy rodents available we can do fancy
things like dragging to express what we want to have happen, instead
of moving lines of text around.
Want to write a patch (or series of patches) for git-gui?
User interfaces are really not what I am good at, and I don't even
have enough time to deal with the things I am good at.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:28
David Kastrup [off-list ref] wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
quoted
Well, yes. But git-gui only works on a single branch head at a time,
and that is not enough for rebasing.
Sure. But so does git's command line tools. They tend to only
work on a single branch at time, the one called `HEAD`.
"tend", and many accept an explicit override: rebase accepts three
commit names, for example. Those that _write_ into the repository
usually _end_ up at HEAD, but most need not start there.
And git-gui does not have any operation either looking at or working
other than on the current HEAD. No diff, no file view, no rebase,
nothing.
Uh, "Repository->Browse Browse Branch Files..." will let you look
at files from any commit-ish, not just HEAD or an existing branch.
You can open many file browsers at once against the same commit or
different commits. Double clicking a file opens it in the blame
viewer, which itself can move around history a little bit.
"Merge->Local Merge..." will let you select any another commit to
merge with this current branch. That's two commits.
So your assertion that git-gui only works with one commit, HEAD,
is wrong.
And git-rebase taking three arguments? Its actually two; if it
is given the optional final argument of the branch to rebase it
first switches to that branch, then does the rebase. In other
words these are identical:
# this...
git checkout to-rebase &&
git rebase --onto upstreamA upstreamB
# is the same as this...
git rebase --onto upstreamA upstreamB to-rebase
quoted
quoted
Could git-gui perhaps be merged with giggle at some point of time?
Unlikely. A while ago I considered "Stay in Tcl/Tk or move to
something more 'powerful/better/faster/Linus friendly'" and stayed
in Tcl/Tk. I doubt git-gui will leave Tcl/Tk. giggle is Gtk based.
My bad: git-gui has a nice polished look on my systems (Ubuntu Feisty)
while gitk has an ugly retro-blockish old-font Tk look; so not looking
at the innards, I had assumed they were implemented using different
systems.
Nope. Myself and a few others have just spent some time making
git-gui look somewhat sane by default. It doesn't always; there are
at least a few places where it still has too much of a Tk-ish look
to it. This is especially true in a few of the dialog boxes that
git-gui might open when you are about to do something potentially
bad.
User interfaces are really not what I am good at, and I don't even
have enough time to deal with the things I am good at.
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:28
"Shawn O. Pearce" [off-list ref] wrote:
David Kastrup [off-list ref] wrote:
quoted
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.
From: David Kastrup <hidden> Date: 2016-06-15 22:43:28
"Shawn O. Pearce" [off-list ref] writes:
David Kastrup [off-list ref] wrote:
quoted
"Shawn O. Pearce" [off-list ref] writes:
quoted
quoted
Well, yes. But git-gui only works on a single branch head at a time,
and that is not enough for rebasing.
Sure. But so does git's command line tools. They tend to only
work on a single branch at time, the one called `HEAD`.
"tend", and many accept an explicit override: rebase accepts three
commit names, for example. Those that _write_ into the repository
usually _end_ up at HEAD, but most need not start there.
And git-gui does not have any operation either looking at or working
other than on the current HEAD. No diff, no file view, no rebase,
nothing.
Uh, "Repository->Browse Browse Branch Files..." will let you look at
files from any commit-ish, not just HEAD or an existing branch.
Duh. But why are the menus called "Browse master's Files" and "Browse
Branch Files" rather than "Browse heads/master" or "Browse master's
head" versus "Browse any commit" or maybe just "Browse current" and
"Browse at ..."? "Browse Branch Files" is _really_ misleading.
You can open many file browsers at once against the same commit or
different commits. Double clicking a file opens it in the blame
viewer, which itself can move around history a little bit.
I though about the blame window after my first posting (actually, I
did not yet notice one can move around in the revisions in the blame.
Nice. Now if it supported utf-8 files...). Well, yes.
"Merge->Local Merge..." will let you select any another commit to
merge with this current branch. That's two commits.
Ok, ok. Still, commits and history are much more visible as whole in
gitk: git-gui mostly lets one pick out single views (the blame window
is probably the closest one gets to moving about, but then it _is_ a
moving view which always shows a single point of time ultimately).
So your assertion that git-gui only works with one commit, HEAD,
is wrong.