Skip Menu |
 

This queue is for tickets about the Dist-Zilla-Plugin-Git-Remote-Check CPAN distribution.

Report information
The Basics
Id: 85114
Status: open
Priority: 0/
Queue: Dist-Zilla-Plugin-Git-Remote-Check

People
Owner: Nobody in particular
Requestors: ether [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Wrong remote is being checked
Download (untitled) / with headers
text/plain 933b
I'm not sure if this is the same issue as #78103? When I tried to release Moose just now, where the local branch is "stable/2.08", I got: [Git::Remote::Check] Updating remote 'origin' [Git::Remote::Check] There are 3 commits visible upstream on 'origin/stable/2.08' not visible on 'master'. [Git::Remote::Check] Either merge with 'origin/stable/2.08', rebase on 'origin/stable/2.08', or anihilate upstream with 'git push -f ' [Git::Remote::Check] The 3 most recent commits are: [Git::Remote::Check] [ [Git::Remote::Check] "e913346 spelling", [Git::Remote::Check] "d87aece bump version for release", [Git::Remote::Check] "e5434b3 changelog for git move", [Git::Remote::Check] ] The config in dist.ini is: [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.

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

Subject: Re: [rt.cpan.org #85114] Wrong remote is being checked
Date: Tue, 7 May 2013 17:22:55 -0700
To: Kent Fredric via RT <bug-Dist-Zilla-Plugin-Git-Remote-Check [...] rt.cpan.org>
From: Karen Etheridge <ether [...] cpan.org>
On Tue, May 07, 2013 at 08:10:40PM -0400, Kent Fredric via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=85114 > > > To clarify: [Git::Remote::Check] does not care what "current branch" is. that > is some other module that does that.
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 (and these could be correlated with the proper "branch to release from", which is what [Git::CheckFor::CorrectBranch] does. 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. * this doesn't yet exist, but is coming soon ;) Show quoted text
> So for what you did, comparing master vs origin/stable/2.08 was completely > expected. =)
Thanks for the clarification; I will fix my configs!

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.


 



This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.