onsdag 01 november 2006 21:49 skrev Junio C Hamano: > Andy Parkins <andyparkins@xxxxxxxxx> writes: > > On Wednesday 2006, November 01 18:28, Junio C Hamano wrote: > >> So from that point of view, the above commandline perfectly > >> makes sense. However, giving anything but HEAD with path makes > >> us go "Huh?" It is unclear what this should mean: > >> > >> git-reset [--hard | --mixed] HEAD^ oops/file1 > > > > I don't understand. Why wouldn't that mean reset oops/file1 to the state > > it had in HEAD^? > > Path limiters everywhere in git means "do this only for paths > that match this pattern, and empty path means the pattern match > every path -- the command's behaviour is not different in any > other aspect between the case you gave no limiter and the case > you gave _all_ paths as limiters". So the other paths remain as > they were (both index and working tree), and HEAD needs to be > updated to HEAD^ in the above example. > > While that perfect makes sense from mechanical point of view, I > am not sure what it _means_ to keep some paths from now > abandoned future while having some other paths reset to the > rewound commit, from the point of view of end-user operation. > > In other words, I do not have a good explanation on what "git > reset [--hard|--mixed] <commit> <path>..." does that I can write > in the documentation. You could refer to git-checkout although checkout doesn't have something corresponding to --mixed. The --hard option would correspond to the -f flag in checkout. It is like "cherrypicking" content (not changes) from a particular commit. Where did the soft option go? Since checkout already does the work.. Is there any need for extending git-reset, other than that's where people look for this feature. The man page could be extended instead. -- robin - 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