We have an interface which "rolls back" commits to a previous time in
a set of data files using read-tree.
Works great ... but sometimes there are files which have
been changed in the working tree which cause read-tree to fail.
The files should have been committed but weren't.
"git read-tree -i" isn't appropriate because
we want to commit these files before the read-tree rolls
them back ... because they are changes which might be
resurrected and we don't want to lose them altogether.
So ...
git commit -a -m "something" && git read-tree ...
Doesn't work when there are no files which need committing ...
git commit -a -m "something" || git read-tree ...
Doesn't work when there are.
Is there something which can test whether a commit is needed?
I define "needed" as meaning when git commit -a would make a non-identical
commit.
Many thanks,
Geoff.
--
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