even though the SHA1 commit ID can be looked at, a changing commit ID
doesn't mean changed code. What if you hat two commits since the last
build, one that adds a change and another that reverts it? You are seeing
the same code, yet you rebuild it.
If you don't have a decent build system that can do incremental builds, you
may want to stick with git diff. You already have the previous build's
commit ID, so you can do git diff old-id HEAD. If anything changed, do a
build. If you pass --stat to git diff, you will get the list of changed
files, so you can make a decision if you really need to build (e.g. no
build if only the README file changed.). This technique may be actually
applied to other VCSes.
On Feb 11, 2016 12:37 AM, "Suu" <suu.q...@oracle.com> wrote:
> Before I build/compile a git branch, I would like to know whether it has
> changed since the last time I built it.
> If no change, I won't bother to build.
> in Subversion, it's a "revision number" that identifies the whole set of
> source code at the time. If you commit another set of changes to the
> branch, you get a new "revision number"
> What is its equivalent in GIT? (commit SHA-1 number?)
> How do I get that value? (git log -p 1?)
> You received this message because you are subscribed to the Google Groups
> "Git for human beings" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.