clean / dirty / untracked

[clembo590]

thanks for this plugin. it is awesome.
However I feel a little something is missing:

When the plugin run we have an information about

"git.dirty" which tells us that the build is being performed on a dirty branch.

However if there is a new file that is "untracked" then this boolean is still false and there is not way to really know if the state of the current branch is "clean".

Could you add a "git.untracked" that would be true if some files are untracked in the current branch.
Or you could add a "git.clean" that would be the opposite of dirty
(except that when there is an untracked file then "git.clean" would be false and "git.dirty" would be false)

usage example:
if "git.clean" is false then I would prevent developers from building the project except it project version ends with "SNAPSHOT"

[TheSnoozer]

Hello,
thank you for creating this issue and sharing your idea. I like it! For me git.untracked feels the best description of the state you'd like to describe. A git.clean would IMHO raise the question what is clean - there is IMHO no git terminology that would fully describe the 'clean' state. However for untracked there is such already existing git terminology that gives the user/consumer somewhat of an idea what this property wants to indicate.

[Reissner]

I like the idea also: practically, dirty should mean sth untracked but not ignored,
or tracked and modified, staged or not.
There shall be a label for that, and if clean, no label.
That way, clean builds are normal and dirty ones are recognized.

In fact git provides sth like that, namely the command describe.
But dirty is defined in the same way as for this plugin and it is a good idea for the plugin to be conform with git.

So the problem goes deeper: the suggestion shall be made to the git team.

I think, to keep backward compatibility, it is ok to have both labels or one of them, depending on the state.
so a version shall be 1.2.3-44-dirty+untracked or only dirty or only untracked.
Only clean versions like 1.2.3.44 are known to be reproducible.

By the way: THANK YOU A LOT FOR THAT PLUGIN... it is GREAT!!!!

[almson]

Ran into this as well.

I don't see a problem with diverging from git describe behavior and adding -dirty in case there are untracked files.

The goal of this plugin is to create version tags which describe the exact state of what is being built, not to be compatible with git.

[Reissner]

It is not just the aim of that plugin to describe the state of the workspace related to repo,
but it is the goal of git describe command.
So the problem is with git not really with the plugin.
I do think, it is confusing, if the plugin deviates from git.
The aim of the plugin shall be to make the properties of git available in maven context.

[almson]

@Reissner The description of the plugin is:

git-commit-id-plugin is a plugin quite similar to Build Number Maven Plugin for example but as the Build Number plugin at the time when I started this plugin only supported CVS and SVN, something had to be done. I had to quickly develop a Git version of such a plugin. For those who don't know the plugin, it basically helps you with the following tasks and answers related questions

Which version had the bug? Is that deployed already?
Make your distributed deployment aware of versions
Validate if properties are set as expected

Where does it say that the aim of the plugin is to expose git properties or use git describe?

[TheSnoozer]

Perhaps to chime in here (and thanks to the previous commenters).
Indeed I also feel that the plugin is here to expose git properties to the maven world and not work like a specific command (e.g. git describe). Certainly providing the information of a git describe version number is also a git properties and thus is also exposed with the plugin. Just adding -dirty in case there are untracked files sounds somewhat like a (dirty) hack.
What about if users don't like that? Then there should be yet another switch added to the billion of switches the plugin already has.

Perhaps can someone who wants that feature also elaborate further on the use case? In my personal view it feels like that untracked files (not commited, only files that exists locally) can only occur locally. Why does the version number matter here? Whatever is produced should not be made public, since the untracked uncommited file is essentially resulting in a build that is not reproducible by others. So just to understand this right: We could also call the generated property ǹon-reproducible to end up with 1.2.3-44-dirty+untracked or 1.2.3-44-dirty+ǹon-reproducible. What extra information does the untracked really give here in that context? The dirty already indicates that the specific version was modified and essentially is a ǹon-reproducible build.

[almson]

@TheSnoozer I think the intent of your second paragraph is unclear. Are you asking that the person(s) who want 1.2.3-44-dirty+untracked explain their reasoning? Your reasoning seems to align with mine. Any non-reproducible[1] build should just be labeled -dirty, and because it's non-reproducible it really doesn't matter whether it's because of untracked files or uncommitted changes or what git describe would call it.

[1] Actually, it's more than non-reproducible. Builds which use -SNAPSHOT dependencies are non-reproducible, but builds which use uncommitted changes are mystery meat.

[clembo590]

@TheSnoozer
I agree with last message of @almson and it is one of the option that I suggested:

if you have untracked files then "git.dirty" could be set to true. (and currently it s not)

If you do not agree with that then it would be great to add a "git.untracked".

I reformulate an example to show how I would use this "new" property:
if ("git.untracked"=true OR "git.dirty"=true) then I would prevent developers from building the project except if project version ends with "SNAPSHOT"

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-antrun-plugin</artifactId>
    <executions>
      <execution>
        <id>checkNoReleaseBuildWithDirtyRepo</id>
        <goals>
          <goal>run</goal>
        </goals>
        <phase>initialize</phase>
        <configuration>
          <target>
            <echo>Displaying properties values from maven ant run</echo>
            <echo>[isSnapshot]: ${isSnapshot}</echo>

            <echo>Displaying value of 'isDirty' property</echo>
            <echo>[isDirty]: ${git.dirty}</echo>

            <fail message="DIRTY REPOSITORY!!!! NO RELEASE BUILD ALLOWED IN A DIRTY REPO!">
              <condition>
                <and>
                  <equals arg1="${isDirty}" arg2="true"></equals>
                  <equals arg1="${isSnapshot}" arg2="false"></equals>
                </and>
              </condition>
            </fail>

          </target>
        </configuration>
      </execution>
    </executions>
  </plugin>