On Wed, Nov 17, 2010 at 09:37, demerphq <demerphq@xxxxxxxxx> wrote:
> Im hoping that if someone thinks that such a patch would be dismissed
> out of hand that they will let me know....
I don't think it should be dismissed, but it's interesting to look
forward a bit and think how clever we really want to be.
E.g. if I have a tracked file "tracked" in my repository and do:
echo Uncommited >>tracked &&
git rebase -i HEAD~3
We'll error out with:
tracked: needs update
Working tree is dirty
Although we could be smarter and scan HEAD~3..HEAD and figure out that
none of them changes "tracked" and go ahead with the rebase.
But arguably it would be more user friendly in the long term to lead
users in the direction of always having clean working trees before
they do operations like these. E.g. that users would turn your
original example into:
git status && # reports no changes / modified files
git tag before-reset-and-merge && # for ease of getting back / safe from gc
git reset --hard HEAD^ && # no untracked files with --hard
git merge some-branch # clean merge
In which case the user would be accustomed to a workflow where he's
guaranteed not to lose data, because Git is always tracking it.
But maybe we should just allow users to be more clever, and try really
hard to find out if they can be clever without screwing up their
working tree.
--
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