This message was deleted.
# feature-requests
s
This message was deleted.
v
As
rebase
is not a
gt
command it is given through to
git
, so this should be supported already, shouldn't it? It will not restack the upstack, but that's why
upstack onto
should be used if you have an upstack.
r
yeah, I was imagining that it wouldn't a pure pass through, so
gt
could handle restacking. It would augment a command that people might already know.
v
I guess that would majorly confuse though if you have such hibernate commands. I personally even prefer to use
git
itself for
git
commands.
r
The docs for graphite said somewhere something like "We want you to think of gt as a complete replacement for the git cli" and that also preceded an explanation that the tool will pass through to git for some commands. I suppose since I'm already quite comfortable with the existing git cli I suppose I would feel better about thinking of
gt
as a replacement tool if I could generally do operations like
gt rebase -i
or
gt rebase --onto
the way that I'm used to except that
gt
would shim those commands to make sure that it can restack branches as needed. As it is you have a new frontend
gt
tool where you have to be cautious to consider that some commands might be direct pass throughs that let you shoot yourself in the foot and it also means that equivalent functionality needs to be placed under a completely different sub command which might not feel as intuitive as the original command. (e.g. need to remember
gt branch edit
is a replacement for
gt rebase -i
and
gt upstack onto
is a replacement for
gt rebase --onto
)
v
I totally get you. I just don't agree. 🙂 I like that
gt
does Graphite stuff and
git
does plain Git stuff where it does exaclty what I want and what I'm used to and not suddenly magic other things. I personally even don't like the push-through of Git commands. It's similar to
hub
which was also meant as
git
replacement with additional logic vs. the new and official
gh
which does not proxy
git
but is just a standalone tool for the GitHub stuff. If I would use the
git
push-through - besides being slower than just using
git
even if just slightly - then I would also always have to keep in mind which Git commands are decorated by Graphite and how and then decide on each command whether I want the plain Git behavior or the decorated one. But that is of course just my personal opinion. 🙂
s
I personally do not like the git pass through, but also had a hard time finding
upstack onto
multiple times this week. For some reason I was looking in
gt stack
instead of upstack
v
I was searching for
--onto
in
upstack restack
once 😄
r
I just don't agree
fwiw I also don't really think that it's the ideal approach either (personally I'd rather have a completely separate cli without passthrough) but it seems like
gt
should either go all in or all out here. Either it augments the standard
git
command line interface and I think it would be good in that case that it would shim standard commands like
git rebase -i
or
git rebase --onto
or else it should be completely standalone, and then it has the freedom to use subcommands that do map back to the standard command line interface in a perhaps more intuitive way.
It just doesn't seem great that the graphite cli can easily trash its own metadata because a lot of commands just pass directly through to git which is unaware of the graphite metadata
âž• 1
if it was a completely separate tool then it seems like it would be easier to create subcommands that naturally pair up with how
git
works but without needing to work exactly the same - e.g. it could have a
gt rebase
command for accessing
gt branch edit
and
gt upstack onto
functionality
v
Also debatable, I regularly type
git cc
when I really wanted to do
gt cc
😄
r
yeah I was struggling to fight my motor memory for typing
git
when playing with
gt
earlier 🙂