I'm more interested in a solution that works for everyone rather than
pointing fingers.
Given that our current docs suggest specifying origin to personal repo,
and upstream to the juju ones, is there any way we can configure the
local repo such that when we say 'git fetch' it fetches from
On 31 October 2014 15:48, Eric Snow eric.s...@canonical.com wrote:
On Fri, Oct 31, 2014 at 2:11 AM, roger peppe roger.pe...@canonical.com
wrote:
On 30 October 2014 14:34, Eric Snow eric.s...@canonical.com wrote:
On Thu, Oct 30, 2014 at 4:40 AM, roger peppe roger.pe...@canonical.com
wrote:
On 30 October 2014 14:34, Eric Snow eric.s...@canonical.com wrote:
On Thu, Oct 30, 2014 at 4:40 AM, roger peppe roger.pe...@canonical.com
wrote:
It's a pity then that if you go get a package, origin is the repo
you've branched from. There is always one of those, but you
don't necessary have
FWIW, I always branch off upstream/master. I don't have master synced to
my repo, because it just seems like an extra step. Why not go straight to
the source?
On Oct 31, 2014 11:48 AM, Eric Snow eric.s...@canonical.com wrote:
On Fri, Oct 31, 2014 at 2:11 AM, roger peppe
On 29 October 2014 21:03, Tim Penhey tim.pen...@canonical.com wrote:
On 30/10/14 01:11, roger peppe wrote:
A better solution here, which I've been meaning to do for a while,
would be to change godeps so that it can explore all possible
targets. I had a go at that this morning (just adding all
Upstream and origin are very very common in the git world. Most any how to
or stack overflow answer uses those by default. Origin is your repo and
upstream is the repo you branched from. I started out doing it your way,
Roger, since I agree that information does flow both ways, and naming my
On 30 October 2014 09:47, Nate Finch nate.fi...@canonical.com wrote:
Upstream and origin are very very common in the git world. Most any how to
or stack overflow answer uses those by default. Origin is your repo and
upstream is the repo you branched from. I started out doing it your way,
I have never used upstream as an actual remote name. I see people
commonly using the term as a wildcard to refer to the upstream branch
whatever it is. The term is also used widely in git itself with the same
meaning, including in the command line interface. For example, you set the
upstream
On Thu, Oct 30, 2014 at 10:34 PM, Eric Snow eric.s...@canonical.com wrote:
On Thu, Oct 30, 2014 at 4:40 AM, roger peppe roger.pe...@canonical.com
wrote:
It's a pity then that if you go get a package, origin is the repo
you've branched from. There is always one of those, but you
don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
+1, in fact there is already a godeps target in the Makefile, but I
never managed to get it working. It's looking for $(GOPATH)/bin/godeps
binary and I have it right there on my machine, but make still claims
File `godeps' does not exist. (when
Does your $GOPATH include more than one entry ?
The make target should probably just expect godeps to be in your $PATH.
On Wed, Oct 29, 2014 at 6:37 PM, Dimiter Naydenov
dimiter.nayde...@canonical.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
+1, in fact there is already a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29.10.2014 09:46, David Cheney wrote:
Does your $GOPATH include more than one entry ?
No, it only has a single path.
The make target should probably just expect godeps to be in your
$PATH.
That's a good point. I did some experiments adding:
We certainly should add a makefile target. I looked into it briefly
yesterday, but didn't get far, as I haven't used makefiles since college,
and didn't want to muck it up.
As for point two, yes, that's a problem. We should add GOOS=windows go get
-t -u github.com/juju/juju/... to the makefile
That would be awesome.
On Oct 29, 2014 8:11 AM, roger peppe rogpe...@gmail.com wrote:
A better solution here, which I've been meaning to do for a while,
would be to change godeps so that it can explore all possible
targets. I had a go at that this morning (just adding all tags to
On Tue, Oct 28, 2014 at 11:58 PM, John Meinel j...@arbash-meinel.com wrote:
can we please just have make dependencies.tsv do the right thing so we
don't have to remember which set of flags and env vars we need to use this
time?
I'm also not 100% sure that we'll have even downloaded all the
On 29/10/14 21:05, Dimiter Naydenov wrote:
On 29.10.2014 09:46, David Cheney wrote:
Does your $GOPATH include more than one entry ?
No, it only has a single path.
The make target should probably just expect godeps to be in your
$PATH.
That's a good point. I did some experiments adding:
We have a few windows dependencies that are not (and in some cases can not
be) imported for the linux build. Luckily, the windows dependencies are a
strict super set of the linux dependencies, so we can still use godeps to
create dependencies.tsv, just by setting GOOS first, thusly (from the root
can we please just have make dependencies.tsv do the right thing so we
don't have to remember which set of flags and env vars we need to use this
time?
I'm also not 100% sure that we'll have even downloaded all the windows
dependencies if they are a strict superset given that you are running go
18 matches
Mail list logo
