Re: Requesting `git stash --cached` or something similar

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

 



On Mon, Apr 13, 2015 at 10:05:02PM -0400, Brandon McCaig wrote:
> Trevor:
> 
> On Mon, Apr 13, 2015 at 9:44 PM, Trevor Saunders <tbsaunde@xxxxxxxxxxxx> wrote:
> > I would expect the answers to be it sets the working directories state
> > to the state in HEAD, and leaves untracked files alone.  If that's what
> > you want you can do git commit -m <message>; git reset --hard; git reset
> > --soft; git stash save to get the effect you want I believe. That said
> > it seems like a kind of odd thing to want to do, what are you actually
> > trying to do?
> 
> That looks like a bad solution. git reset --hard is going to throw
> away any remaining changes to the working tree. The previous commit

 git reset --hard is there to do *exactly* that, which I'm assuming is
 the desired thing for a hypothetical git stash save --cached to do
 because its consistant with what git stash save does.

> would have committed the staged changes, albeit, you should connect
> the commands with && instead of ; to account for errors. After a `git

it should be clear this is not actual code to run exactly as written.

> reset --hard' there's no point in doing a `git reset --soft' because
> hard does *everything*. --soft would try to reset the HEAD without
> touching the index or working tree, but both have already been reset
> with --hard.

yes, that was supposed to be git reset --soft HEAD~ in which case it
does do something, and it is there exactly to just reset HEAD so that
git stash can then pick up the changes from the temporary commit.

> The motivation is most likely stashing a few changes away so that you
> can commit others that are ready to be committed while keeping others
> around to continue working on them. This too is a good observation. It

yes, it could be they are looking for something like git stash --patch,
but maybe not we don't know.

> could mean that the OP is inexperienced with a commit-often workflow.
> You can use git -add -i or -p to commit the good stuff and keep the
> bad stuff out to work on it more. The great thing about Git is that
> the history is very malleable. You can also commit the bad and fix it
> after, rebase the history to clean it up, and end up with perfect
> history while still keeping your changes safely in history.

git stash also stores changes in the git database.  However if you
really like the stack / queue type workflow you might want to consider
stgit or stacked git or something (I personally really dislike that work
flow so I'm not really familiar with those tools).

> The OP should experiment with workflows because Git is already very
> good at this. Stash isn't really needed. That said, I had forgotten
> that --patch was added to stash some time ago so if that is what you
> want then it already exists. It's not quite as easy as --cached, but
> it still gives you some control. It's still not nearly as good as
> using the full power of Git with a regular commit on a branch though.

good is subjective and depends on what you need to do.  There are
certainly times where the stash is a good way to solve problems, and if
people have ideas for things they think it can do better that's great.

Trev

> 
> Regards,
> 
> -- 
> Brandon McCaig <bamccaig@xxxxxxxxx> <bamccaig@xxxxxxxxxxxxxxxx>
> Castopulence Software <https://www.castopulence.org/>
> Blog <http://www.bambams.ca/>
> perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
> q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
> tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
> --
> 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
--
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]