This is a project work for the class I am taking (Advanced Topics in Software Engineering).
legit is a complimentary Command-Line-Interface tool for git that adds some commands which proposes to simplify git interface. See Purposes, Concepts, Misfits, and a Redesign of Git.
git stash is a powerful git command for stashing changes in a dirty working directory.
This is very useful for when you are working on something, but have to stop for a while to do something else.
Stashing changes work akin to comitting them on a secondary branch and merging them back later to your working directories. It works similarly, even suffering from conflict issues.
There is, though, a common issue: while it is easy to master the command, it is not dead simple to learn it on a need-to-know basis. Therefore, many people never use it. Or use it seldom and/or only for immediate basic pop/stack operations, never adding messages to explain what the changes are about and so on.
This feature request for gitless should include a few commands (to be surveyed yet) that simplifies this process for git novice users.
legit stash: alias to the command belowlegit stash save <hash/id>: saves current staging area to stash, similar togit stashlegit stash list: list all stashes, similar togit stash listlegit stash apply <hash/id>: applies stash by hash or id, but requires hash/id argumentlegit stash pop: applies stash by hash or id or on the top of the stack (not shown on legit help stash)legit stash rm <hash/id>: removes stash by hash or id, similar togit stash drop, but requires hash/id argumentlegit stash show <hash/id>: show contents of stasing area, similar togit stash show
--message (string)--id (string)
- Prompt user for stash id always, if not given by --id
- Prompt user for stash messages always, if not given by --message
- Make these settings globally configurable
I like none of these ideas, but others might like it.
It might be useful for users to use a custom ID for their stashes, instead of using the sha1 git generates.
We are going to implement a local DB on the current user .git directory with a map from user-friendly ID to git native hash on a file. This file has to be garbage collected to clear old values from time to time, because the user might still use git itself to drop/pop stashes.
The only risk I see are users stashing changes for complex work that are already good enough for committing, instead of adding them on 'under work' branches.
Another possibility is for the ID code to always be the first line of the message (and strip it when printing with gitless). This way, a local index is not needed.