Re: [RFC/PATCH v2] create a skeleton for the command git rebase --status

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [RFC/PATCH v2] create a skeleton for the command git rebase --status

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:05:02

Matthieu Moy [off-list ref] writes:
Junio C Hamano [off-list ref] writes:
quoted
If this topic enhances 'git status' with the in-progress rebase
information, I'd view it as turning 'git status' from 'a more or
less useless command during rebase' to 'a useful command'.
For day-to-day operations, what we already have in status already
qualifies as 'useful command' to me:

$ git status
rebase in progress; onto 7f9a792
You are currently rebasing branch 'master' on '7f9a792'.
  (fix conflicts and then run "git rebase --continue")
  (use "git rebase --skip" to skip this patch)
  (use "git rebase --abort" to check out the original branch)
Not really.  How would you decide if 7f9a792 is worth keeping or
rebase is better be aborted without knowing where you are?
I like the output of "git status" to be concise.
Sure, as long as concise and useful, I am all for it.  The above
however does not show anything I already know in my prompt.  I would
say no thanks to "concise and useless".
OTOH, there are tons of information in .git/rebase-merge/ that
could be displayed to the user.
Surely, that is why "git status" during a rebase should show them.

Re: [RFC/PATCH v2] create a skeleton for the command git rebase --status

From: Guillaume Pages <hidden>
Date: 2016-06-15 23:05:02

After this discussion I eventually agree that it would be better
upgrading git status than creating a new command.When people use git
status, it means that they need information to continue their work, so
if you don't even know that you are in a rebase, you will very likely
need information about the current rebase.

During a classic rebase we could have output like:

rebase in progress; onto d9d448a You are currently rebasing branch
'branche1' on 'd9d448a'.  (fix conflicts and then run "git rebase
--continue") (use "git rebase --skip" to skip this patch) (use "git
rebase --abort" to check out the original branch) (5 commits applied,
3 remainings) Failed to apply:

252c273 commit message

Unmerged paths: (use "git reset HEAD <file>..." to unstage) (use "git
add <file>..." to mark resolution)

both modified: file1


And during an interactive rebase:

rebase in progress; onto 247c883 You are currently editing a commit
while rebasing branch 'b1.1' on '247c883'.  (use "git commit --amend"
to amend the current commit) (use "git rebase --continue" once you are
satisfied with your changes)

Last commands done (5 commands done) :

pick 62609785 commit message1 reword 85ae9001 new commit message2

(See more at .git/rebase-merge/done)

Next commands to do (3 remainings commands) :

squash 62609785 commit message3 pick 85ae9001 commit message4

(See more at .git/rebase-merge/git-rebase-todo)

Changes not staged for commit: (use "git add <file>..." to update what
will be committed) (use "git checkout -- <file>..." to discard changes
in working directory)

modified: file1 ...

Is it a good practice to send the user find information in the .git
directory?

Thanks

Guillaume
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help