281–286 of 286 posts
Earlier quoted context omitted.
Only the workspace can be built and tested, so the workspace is what should be committed. We should be stashing anything we don't want to test and commit yet.
I'm trying to keep out of this fight, but how are you planning on just stashing one hunk without staging?
Those articles from mid-1990s are great to read; they are both funny and informative. Even as many of the points they make are still valid today, even more valuable is the ability to look at succeesses or failures with 20+ years of hindsight. I feel the pain of the user in this particular case. But I also understand the frustration of the people who wanted to write their own smaller programs with less restrictions th…
A similar argument has also been made about JavaScript. When it comes to market share I guess most users don't care how elegant the solution is under the hood.
Earlier quoted context omitted.
Only the workspace can be built and tested, so the workspace is what should be committed. We should be stashing anything we don't want to test and commit yet.
I'm trying to keep out of this fight, but how are you planning on just stashing one hunk without staging?
However, if the staging area is relaced by a CHEAD commit ("commit head") whose parent is HEAD, then the problem of "stashing the index" completely goes away. You don't stash staged changes because they are already committed into the staging commit CHEAD.
That said, the stash feature could work with this CHEAD. Stashing the staged changes sitting in CHEAD could propagate them into the stash somehow (such as by a reference to that commmit). Then CHEAD is reset to point to HEAD, and the changes are gone. A single stash item consisting of work tree changes and staged changes could simply be an object that references two commits: a commit of working changes committed just for the stash, and a reference to the CHEAD which existed at that time. It could be that one is the parent of the other. So that is to say, a commit is made of the working copy changes, parented at the CHEAD. The stash then points to the SHA of that commit.
Intuitively, I know this would work, because in the existing Git, I could easily implement this workflow instead of using the stash. Given a tree of local changes, I could "stage" some of them by creating a commit with "git commit --patch". Then "stash" rest of them into another commit "git commit -a". Then, create a branch or tag for that two-commit combo, and finally get rid of it with "git reset --hard HEAD^^". Later, I could easily recover the changes from that branch, either by cherry picking, or doing a hard reset to them or whatever.
Speaking of which, an example of how stashes are limiting because they aren't commits, think of how you can't do:
git reset --hard stash@{0} # wipe it all away and make it like this stash
The requirement of reproducing working changes and staged ones from a stash represented as a two-commit combo is very simple. You cherry pick one normally and make it the CHEAD (the aforementioned special head for pointing to a commit being staged). Then the other one is cherry-picked with -n, so it is applied as local changes.
I remain amazed that the #1 shipper of Unix systems today is .. Apple. I grew up on Unix in the 80's, cut my teeth on MIPS RISC/os and then Irix and SunOS and all the joys of the very first days of Linux, oh my .. and I was fully prepared to be an SGI fanboy for the rest of my life - and then, they abandoned Irix and shipped NT. sadface So when the tiBook came out, and it was promised to have a Unix on it, I jumped o…
Were you amazed back in the days when one of the most popular Unix flavours was produced by Microsoft? Yes, Xenix.
Earlier quoted context omitted.
> Maybe for Windows transplants. In general, not at all. care to elaborate In my experience, Powershell is so much nicer than bash that even on my work mac I tend to use it when doing stuff for me (not going to force it on my team)
Powershell originated on Windows and garnered a fan base on the platform. It's not much appreciated outside that niche and most people who like it are people who use or used it on Windows.
I find it odd that you consider Windows and PowerShell a niche, when it seems to have been enthusiastically embraced by the community
Earlier quoted context omitted.
It's the command that does "Reset working directory/Discard changes/Revert to last commit"! You'd think that's what "git reset" would to, but of course not.
> You'd think that's what "git reset" would to, but of course not. Ahem, the command for "Reset working directory/Discard changes/Revert to last commit" is "git reset --hard". That's the one I use. "git checkout -f" does the same thing, but only because their different functionality coincides when there are no other arguments. When given a non-HEAD commit-id or branch-id they do different things.