Bug #85114 for Dist-Zilla-Plugin-Git-Remote-Check: Wrong remote is being checked

On 2013-05-08 05:04:38, ETHER wrote:
> I'm not sure if this is the same issue as #78103?
>

> [Git::Remote::Check]
> remote_branch = stable/2.08
>
> ...so shouldn't it have been checking origin/stable/2.08? I don't see
> where it got the idea it should be comparing to the local master, as
> that wasn't my local branch.

This is due to the defaults:

'branch' defaults to 'master'   ( https://metacpan.org/module/Dist::Zilla::Plugin::Git::Remote::Check#branch1  )
and 'remote_branch' defaults to "whatever branch is". ( https://metacpan.org/module/Dist::Zilla::Plugin::Git::Remote::Check#remote_branch )

So the solution is:

 [Git::Remote::Check]
 branch   = stable/2.08
 remote_branch = stable/2.08

because it compares the state of "branch" with "remote_branch"
 

To clarify: [Git::Remote::Check] does not care what "current branch" is. that is some other module that does that.

[Git::Remote::Check]

only compares *one* specified branch with *another* specified branch.

If you specify the wrong things ( in this case caused by not specifying anything for the local branch, but specifying a remote branch to compare against ), then you'll get the wrong result.

So for what you did, comparing master vs origin/stable/2.08 was completely expected. =)

On 2013-05-08 12:23:25, ETHER wrote:
> Aha -- would it be possible/make sense to do this, though? Since one
> can
> determine what the current local branch is, and also find the remote
> tracking branch that corresponds with it, only one or the other of
> these
> needs to be configured directly

Thats not so clear to me, sure, there's a pattern where upstream/downstream match up, but I often have configs where thats not the case, and it could be very hard to determine branch tracking reliably, ie:

[remote."origin"]
   ...
   push = +refs/heads/*:refs/heads/*
   push = +refs/tags/*:refs/tags/*

is a common idiom in my .git/config

and likewise, "push=" refs  don't nessecarily correspond with "fetch=" refs.

The only slightly reliable info is these sections:

[branch "releases"]
    remote = origin
    merge = refs/heads/releases
[branch "master"]
    remote = origin
    merge = refs/heads/master

And they don't tell me anything useful, they only tell me what happens if the user does a "pull merge"

And annoying, git docs seem to suggest that this is legitimate:

[branch "master"]
    remote = origin
    merge = refs/heads/master
    merge = refs/heads/release

and will perform an octopus merge when you 'git pull'.

However, I *never* use `git pull`, and updating local branches is always explicit, either by

 `git merge --ff-only origin/$branch`

or

  `git rebase -i origin/$branch`

or

    `git merge origin/$branch`




> This is where a central [%Git] stash* would come in handy, to allow
> the user
> to just specify in one place "this is the branch(es) I permit releases
> from", and then the plugins can use git's metadata to figure out
> everything
> else.

Unless of course, you're insane and want to make sure 2 seperate branches are both ahead of upstream, then the [%Git] stash arbitrary limits your choices there.

Sure, maybe they can provide defaults, but I wouldn't want all the Git::* plugins to rely on the [%Git] stash for *all* things.

so many things are just useless that way, ie: CommitBuild for master and a seperate commitbuild for release? Sharing the same arguments across those 2 would be bad =).

>
> * this doesn't yet exist, but is coming soon ;)

Oh, and here's a more realistic case: 

 You have multiple "upstreams", users who you want all commits from, and you don't want to push a new release if any of them have new commits.

Only doable with 2x Git::Remote::Check instances.

Not doable with git configuration, unless you want to imply octopus merging with them, which I can hardly recommend, and even then, I don't think it lets you
 

[branch "master"]
    remote = origin
    remote = upstream_1
    merge = refs/heads/master
 

# No idea how that would go down, like a house on fire I'd imagine.