Re: [PATCH] git-completion: add stashes for gitk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you for the review.

I now understand that the commit message should have provided way more
context about my use case.

I used Bazaar almost exclusively until about a year ago. Git's ability
to put stuff in the index without committing and the power of "git
rebase" covers many of the use cases I would have used shelves
("stashes") for in Bazaar. But a stash is still, as far as I know Git,
the best solution in some cases.

A Bazaar shelve ("stash") has a stable number. (Applying a shelve from
the middle of the list won't cause a renumbering) A git stash will
change its number when a new stash is added. (On the positive side
this allows stash@{2.hours.ago}) The renumbering makes it more
difficult to keep track of what is there. I therefore have more need
of a quick way to get an overview of the stashes in git than in
bazaar. You idea of using a stash's message to refer to it would solve
this.

In Bazaar I can quickly get an overview of the shelves ("stashes") by
typing "bzr qshelve" and clicking on the "View shelved changes" tab.
Its has a list of my shelves including their number and message at the
top. Under it the diff of the currently selected shelve is displayed.
This makes it fast to get an overview of the shelves.

The objective the patch tries to achieve is to speed up getting an
overview of stashed changes in gitk. A big stash in "git stash list
-p" can force a user to read it slowly or risk skipping the next
stash. By typing "gitk stash@{<TAB>" all stashes are listed. The user
can then know if there are more stashes that haven't been viewed yet
and stop reading a stash when he knows what the current stash is. (If
I understand things right "gitk stash@{.}" would have the problem of
burying old stashed under the commits above it)

> A bigger question is why this change is made to gitk completion.  If
> this completion were useful for "gitk", wouoldn't it be equally
> useful for "git log"?
I must admit that I didn't know that "git log" could display the
content of a stashed change. After trying "git log -p -m stash@{0}" I
would say that adding stashes for "git log" would be slightly less
useful. "gitk stash@{0}" allows me to look at the stashed change and
find out what it contains. "git log -p" (note: no "-m" since the user
don't know that a stash is a merge commit) won't let me do that.
Another reason is that "git stash show -p stash@{0}" already is
autocompleted for those that wish to view their stash diff on the
command line)

> If there were a way for users to say "The one I made to stash away
> that change" from the command line (I do not mean "git stash list |
> grep 'that change'"), it would be good.
Great idea.

-- 
Helsing
Sveinung

"The Lord requires of his saints confession of sins during their whole
lives, and that without ceasing, and promises pardon. How presumptuous,
then, to exempt them from sin, or when they have stumbled, to exclude them
altogether from grace?" (sitat John Calvin)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]