Setting evaluateOnCommit to any branch will only result in the commit-id instead of the branch name

[TheSnoozer]

Describe the bug

As discussed in
#395 (comment)
the property <evaluateOnCommit>HEAD</evaluateOnCommit> should allow everything like HEAD, HEAD^1 or a specific branch name (e.g. branch). However when setting it to a specific branch name the git.branch will always be the full commit-id (which is the right fall back when the branch can not be determined -- e.g. detached HEAD).

Steps to Reproduce

  @Test
  @Parameters(method = "useNativeGit")
  public void verifyEvalOnDifferentCommitWithCommitHash(boolean useNativeGit) throws Exception {
    // given
    mavenSandbox.withParentProject("my-jar-project", "jar")
                .withNoChildProject()
                .withGitRepoInParent(AvailableGitTestRepo.WITH_TAG_ON_DIFFERENT_BRANCH)
                .create();
    MavenProject targetProject = mavenSandbox.getParentProject();
    setProjectToExecuteMojoIn(targetProject);

    GitDescribeConfig gitDescribe = createGitDescribeConfig(true, 9);
    gitDescribe.setDirty(null);

    mojo.gitDescribe = gitDescribe;
    mojo.useNativeGit = useNativeGit;
    mojo.evaluateOnCommit = "test";

    // when
    mojo.execute();

    // then
    assertPropertyPresentAndEqual(targetProject.getProperties(), "git.commit.id.abbrev", "9cb810e");

    assertPropertyPresentAndEqual(targetProject.getProperties(), "git.commit.id.describe", "test_tag-0-g9cb810e57");

    assertPropertyPresentAndEqual(targetProject.getProperties(), "git.branch", "test");

    assertPropertyPresentAndEqual(targetProject.getProperties(), "git.tags", "test_tag");

    assertPropertyPresentAndEqual(targetProject.getProperties(), "git.dirty", "true");

    assertPropertyPresentAndEqual(targetProject.getProperties(), "git.total.commit.count", "2");
  }

Expected behavior

• Tests should pass

Additional context

For reproducibility please provide the following:

[TheSnoozer]

I briefly looked into this and used the git repo that is referenced in the ticket for some more testing.
The repo looks like this:

* 9cb810e - Fri, 29 Nov 2013 10:39:31 +0100 (5 years ago) (tag: test_tag, test)
|           Change in tag - Karol Lassak
| * 2343428 - Fri, 29 Nov 2013 10:38:34 +0100 (5 years ago) (HEAD -> master)
|/            Moved master - Karol Lassak
* e3d159d - Fri, 29 Nov 2013 10:38:02 +0100 (5 years ago)
            Added readme - Karol Lassak

The referenced git name-rev in the comments of the linked ticket seems to prefer a tag if present (e.g. trying to get the branch-name for test with git name-rev --name-only test would yield tags/test_tag^0). For getting a branch name it is certainly undesirable to suddenly get a tag name and thus I think would not work.

What currently seems to be a good approach solution (almost) would seems to be using git branch --contains which is also being used in tools like git-what-branch.

The output looks like the following:

$ git branch --contains test
  test
$ git branch --contains HEAD
* master
$ git branch --contains master
* master
$ git branch --contains 9cb810e
  test
$ git branch --contains 2343428
* master
$ git branch --contains test_tag
  test
$ git branch --contains HEAD^1
* master
  test

For almost all cases (besides the HEAD^1) it yields one result with the actual branch name.

Replacing the --contains with --points-at somewhat fixes HEAD^1 but does not yield a branch for the test_tag and HEAD^1:

$ git branch --points-at test
  test
o$ git branch --points-at HEAD
* master
$ git branch --points-at master
* master
$ git branch --points-at 9cb810e
  test
$ git branch --points-at 2343428
* master
$ git branch --points-at test_tag
# no output
$ git branch --points-at HEAD^1
# no output

For our use-cases I also believe using git branch --points-at would be the right(er) thing to use, since HEAD^1 is not a branch and test_tag is questionable if it should be considered a branch or a tag.

Overall the git branch output appears to be lead by two characters (either two spaces, or a star and one space) so I think this is almost good and could be parsed fairly easy (is it the same for other OSses?).

=======================================================

Note 1

Previously we had been using git symbolic-ref -q and this only seems to work when we are not in detached HEAD and asking for the symbolic-ref of HEAD:

$ git lg2
* 9cb810e - Fri, 29 Nov 2013 10:39:31 +0100 (5 years ago) (tag: test_tag, tag: foo, test)
|           Change in tag - Karol Lassak
| * 2343428 - Fri, 29 Nov 2013 10:38:34 +0100 (5 years ago) (HEAD, master, another_branch)
|/            Moved master - Karol Lassak
* e3d159d - Fri, 29 Nov 2013 10:38:02 +0100 (5 years ago)
            Added readme - Karol Lassak
$ git status
HEAD detached at 2343428
nothing to commit, working tree clean
$ git symbolic-ref HEAD
fatal: ref HEAD is not a symbolic ref

$ git checkout master
$ git status
On branch master
nothing to commit, working tree clean
$ git symbolic-ref HEAD
refs/heads/master
$ git symbolic-ref master
fatal: ref master is not a symbolic ref

$ git checkout another_branch
$ git status
On branch another_branch
nothing to commit, working tree clean
$ git symbolic-ref -q HEAD
refs/heads/another_branch

However this always returns a single (and the right branch).

Side effect 1 of git branch --points-at

If two branches point to the same commit the execution of git branch --points-at might rightfully return multiple branches.

Example:

$ git lg
* 9cb810e - (5 years ago) Change in tag - Karol Lassak (tag: test_tag, test)
| * 2343428 - (5 years ago) Moved master - Karol Lassak (HEAD -> another_branch, master)
|/  
* e3d159d - (5 years ago) Added readme - Karol Lassak

$ git branch --points-at 2343428
* another_branch
  master

Side effect 2 of git branch --points-at

Detached HEAD is also returned a branch:

$ git lg
* 9cb810e - (5 years ago) Change in tag - Karol Lassak (tag: test_tag, tag: foo, test)
| * 2343428 - (5 years ago) Moved master - Karol Lassak (HEAD, master, another_branch)
|/  
* e3d159d - (5 years ago) Added readme - Karol Lassak

$ git status
HEAD detached at 2343428
nothing to commit, working tree clean

$ git branch --points-at 2343428
* (HEAD detached at 2343428)
  another_branch
  master

Final Conclusion

I believe the best and right answer would be using git symbolic-ref -q HEAD if a user runs evaluateOnCommit with HEAD (the default). However as soon as someone asks for a different thing like HEAD^1 or a specific branch name (e.g. branch) we should use git branch --points-at. In the case that we can not determine a branch name we should use the commit hash as fallback (for both cases).

[TheSnoozer]

Fixed with #414

[BRLOKESH]

$ git commit -m "Initial Code Commit"
On branch feature/milestone_edu
nothing to commit, working tree clean

$ git push --set-upstream origin feature/milestone_edu
To https://bitbucket.org/.../flutter_project.git
! [rejected] feature/milestone_edu -> feature/milestone_edu (non-fast-forward)
error: failed to push some refs to 'https://...@bitbucket.org/.../flutter_project.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Not commit my source code to this branch : feature/milestone_edu

[TheSnoozer]

Hi,
thanks for reporting your reporting your problem here.

What you posted does not seem to be related with this plugin.

Essentially what seems to happened here is that your local commit-history does not match with whatever is known to the server. Or in other words git does not know a strategy to push your local feature branch with your local commits to the remote repository without losing commits. As a result git rejects your git push to prevent this from happening.

I'd suggest to search on a search engine for git push rejected non-fast-forward for further advice.
What to do here depends on your commits you want to preserve (either merge with the remote and then push again, or force-update the remote). Please read carefully what the difference between the two potential options mean and how to resolve your situation correctly. Furthermore search online to see if there are alternative strategies to resolve for your situation.

TLDR: Search online, I can not help you - this is not meant as advice what strategy is the "best" to resolve your issue.