finding if a commit is needed

finding if a commit is needed

[Geoff Russell]

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.

Re: finding if a commit is needed

[Jonathan Nieder]

Geoff Russell wrote:

> 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.

Maybe "git diff --exit-code HEAD"?

Regards,
Jonathan

Re: finding if a commit is needed

[Geoff Russell]

On Thu, Jul 29, 2010 at 9:36 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Geoff Russell wrote:
>
>> 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.
>
> Maybe "git diff --exit-code HEAD"?

Thanks ... "git diff --quiet || echo differences"

Cheers,
Geoff.

>
> Regards,
> Jonathan
>



-- 
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069
http://perfidy.com.au