Re: [PATCH] Introduce reset type flag to git reset
I am not sure what mixed reset (the current behaviour) is good for. If nobody comes up with a good use case it may not be a bad idea to remove it. Using the principle of minimum suprise the --mixed should be removed. --soft - undo the commit leaving all changes. --hard - undo the commit and removing all changes I'm a cogito user so not used to got options. But --soft, --hard looks rather confusing to me. Something like --force or --prune may be a bit more intuitive, and let default behaviour be the one you name --soft for now. I think it would make sense to be able to specify the topmost SHA1 (or HEAD:5 or HEAD^) from where the reset should start. Sam - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Introduce reset type flag to git reset
Sam Ravnborg [EMAIL PROTECTED] writes: But --soft, --hard looks rather confusing to me. Something like --force or --prune may be a bit more intuitive, and let default behaviour be the one you name --soft for now. I do not have objections to removing --mixed, but I do not find --force/--prune any less confusing than --soft/--hard. Its just a terminology so once people get used to it anything would do. But I agree that we need to come up with a good name for them. I do not think --force/--prune is it, though. I think it would make sense to be able to specify the topmost SHA1 (or HEAD:5 or HEAD^) from where the reset should start. git reset --hard HEAD~5 should work. Sorry, the colon : turns out to be confusing to refspec notation src:dst used in fetch/push and was replaced with a tilde ~ some time ago. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Introduce reset type flag to git reset
At Tue, 23 Aug 2005 15:08:44 -0700, Junio C Hamano wrote: Sam Ravnborg [EMAIL PROTECTED] writes: But --soft, --hard looks rather confusing to me. Something like --force or --prune may be a bit more intuitive, and let default behaviour be the one you name --soft for now. I do not have objections to removing --mixed, but I do not find --force/--prune any less confusing than --soft/--hard. Its just a terminology so once people get used to it anything would do. But I agree that we need to come up with a good name for them. I do not think --force/--prune is it, though. I think the point is what is the target?. I believe git reset is targeting at the index file and only the index file and nothing more. it's that simple. what we want instead is a command to sync/reset/revert both index and tree to know working point. so this isn't core plumbing but as a user of git, i'm sure it's very handy to have it. --soft one is simple to think, so i'm starting with this one. let's assume that, as you described in the original post, this one is intended to be used to rework on the work _you_ have before. that means that _you_ know exactly what you are doing. there might be a case, and this happned to me quite some time when I was working with quilt, which you don't want to automatically add all the files you added on the privious commit. ie. moving defines from header to .c, splitting a work to two commits. so in this case, it's ideal to just use git reset if the command lists files removed from the index. for --hard option, what you want to do is to completely revert the current state of your index file and work tree to known point. for that, how about git-revert-script? can we add --force option to that command so that even if your working tree is dirty it reverts to the specified point? -- yashi - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Introduce reset type flag to git reset
Yasushi SHOJI [EMAIL PROTECTED] writes: for --hard option, what you want to do is to completely revert the current state of your index file and work tree to known point. for that, how about git-revert-script? git revert is to create a commit that reverts a previous commit, which I think is quite different from what we have been discussing so far. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html