gitconfig is not loaded by git for security unless you explicitly tell it to.
i.e. a user still has to run
git config --local include.path ../.gitconfig
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.laun
After having messed up my first emailed patch due to missing this
email, would it not be better to add a .gitconfig to the project tree
which includes this helper script by default?
On Fri, Aug 12, 2016 at 9:36 PM, Maciej Sumiński
wrote:
> On 08/11/2016 08:28 PM, Wayne Stambaugh wrote:
> [snip]
>
I think the mirror should be working again now, we will see when
something is pushed to lp.
2016-08-25 7:40 GMT+02:00 Nick Østergaard :
> I will try to make the mirror be synced from launchpad, at latest on friday.
>
> 2016-08-24 5:39 GMT+02:00 kinichiro inoguchi :
>> Hi,
>>
>> I hope mirror on Gi
I will try to make the mirror be synced from launchpad, at latest on friday.
2016-08-24 5:39 GMT+02:00 kinichiro inoguchi :
> Hi,
>
> I hope mirror on GitHub keeps refreshing from new git repo on Launchpad.
> https://github.com/KiCad/kicad-source-mirror
>
> For GUI translators task,
> we need to d
Having discussed this a bit more on IRC I must take back this
suggestion. Presumably 5.0 will be based on master rather than on 4.0,
so things will get messy if we do that...
On Wed, Aug 24, 2016 at 08:03:24PM -0400, Chris Pavlina wrote:
> I really think the branch should just be named 'stable', t
I really think the branch should just be named 'stable', things like
"4.0" should be tags inside it.
However I have pushed an additional 4.0 branch to avoid breaking things
that may have been depending on that name, if there are any.
On Wed, Aug 24, 2016 at 07:56:05PM -0400, Wayne Stambaugh wrote
Nick,
Is this what you were looking for or are you also expecting the branch
to be named 4.0 instead of stable-4?
On 8/24/2016 7:31 PM, Chris Pavlina wrote:
> Should be good now.
>
> On Wed, Aug 24, 2016 at 07:24:45PM -0400, Wayne Stambaugh wrote:
>> Thanks.
>>
>> On 8/24/2016 7:16 PM, Chris Pav
A note to everyone, you may have to run "git fetch --tags" in order for
your tags to be updated locally.
On Wed, Aug 24, 2016 at 07:24:45PM -0400, Wayne Stambaugh wrote:
> Thanks.
>
> On 8/24/2016 7:16 PM, Chris Pavlina wrote:
> > I'll fix it.
> >
> > On Wed, Aug 24, 2016 at 07:11:42PM -0400, Wa
Should be good now.
On Wed, Aug 24, 2016 at 07:24:45PM -0400, Wayne Stambaugh wrote:
> Thanks.
>
> On 8/24/2016 7:16 PM, Chris Pavlina wrote:
> > I'll fix it.
> >
> > On Wed, Aug 24, 2016 at 07:11:42PM -0400, Wayne Stambaugh wrote:
> >> Are saying that Niki's branch is different? When I was ask
Thanks.
On 8/24/2016 7:16 PM, Chris Pavlina wrote:
> I'll fix it.
>
> On Wed, Aug 24, 2016 at 07:11:42PM -0400, Wayne Stambaugh wrote:
>> Are saying that Niki's branch is different? When I was asking about a
>> git version of the stable branch, why didn't you say something? I
>> didn't even see
I'll fix it.
On Wed, Aug 24, 2016 at 07:11:42PM -0400, Wayne Stambaugh wrote:
> Are saying that Niki's branch is different? When I was asking about a
> git version of the stable branch, why didn't you say something? I
> didn't even see that there was another branch in the mirror on github.
> I a
Are saying that Niki's branch is different? When I was asking about a
git version of the stable branch, why didn't you say something? I
didn't even see that there was another branch in the mirror on github.
I agree that it should match the mirror assuming the mirror is up to
date with the bzr sta
Hi Wayne.
I have had a little chat with Nick about github 4.0 and my 4.0.x
branch, and now that 4.0 has been updated to the latest, I would
suggest using the 4.0 branch from the KiCAD github mirror instead, as
my branch branches of from master at an much earlier point than 4.0, so
4.0 shares more
I don't like that your "stable-4" branch don't match the 4.0 branch in
the kicad-source mirror.
See:
https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev/commit/?h=stable-4&id=7ced0635031e2dcf7ec34db598726f0887da2cc5
https://github.com/KiCad/kicad-source-mirror/commit/bcdcaa724d1097bffd365422
Form like now:
lp:id
not supported with the terminal. It will be usefull to use form like
"LP: #id".
В Среда, 24 авг. 2016 в 8:08 , Eldar Khayrullin
написал:
Launchpad supports link messages to bugs like this:
LP: #id
P.S. and in the terminal in Ubuntu this msg is the link too.
В Пятница, 1
Hi,
I hope mirror on GitHub keeps refreshing from new git repo on Launchpad.
https://github.com/KiCad/kicad-source-mirror
For GUI translators task,
we need to download source code tarball to obtain strings in the GUI.
On GitHub, we could download every committed rev as tarball by one click.
On L
Thanks everyone for taking a look at this. I just pushed the stable-4
branch to lp:kicad so we should be synced up. I'll tag the bzr stable 4
repo as obsolete when I get a chance.
On 8/23/2016 1:13 PM, kinichiro inoguchi wrote:
>> Can someone please take a look at it you get a chance and make su
> Can someone please take a look at it you get a chance and make sure I
> didn't make a mess of things before I push this to the main repo.
Hi,
I compared the new git stable-4 repository and old bzr lp:kicad/4.0.
https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
https://code.launchpa
Looks good to me.
On Tue, Aug 23, 2016 at 11:15:39AM -0400, Wayne Stambaugh wrote:
> OK. That was easy. I pushed the changes to my personal repo on lp at
>
> https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
>
> Can someone please take a look at it you get a chance and make sure I
> d
OK. That was easy. I pushed the changes to my personal repo on lp at
https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
Can someone please take a look at it you get a chance and make sure I
didn't make a mess of things before I push this to the main repo.
Thanks everyone for the help.
I don't think tracking you 4.0.x branch is what we want. We want the
main repo to be the source not someone's personal repo or am I not
understanding how git works?
On 8/23/2016 10:14 AM, Niki Guldbrand wrote:
> Hi Wayne.
>
> Just do run the following:
>
> git remote remove nikis-github-repo
>
It was the kicad github mirror I used, and I'm regularely pulling from
it, and rebasing against it. And when I added the launchpad remote
about 30 min ago, git didn't fetch anything new.
The 4.0.x branch was made with the git-remote-bzr addon, which found an
common anchestor in the git tree and cr
After you have create your local copy, you just push it to launchpad,
and then delete your local copy of my branch, then people will pull 4.0
from launchpad, then, i'm basically out of the picture, and I'll use
lauchpad as the source for stable as everybody else.
On tir, 2016-08-23 at 10:34 -0400,
Hi Wayne.
Just do run the following:
git remote remove nikis-github-repo
git remote add --fetch --tags nikis-github-repo
https://github.com/nikgul/kicad-source-mirror.git
git checkout -b stable-4 nikis-github-repo/4.0.x
And now you have a local branch named stable-4 that tracks my remote
4.0.x
What was your original clone source? I cloned the mirror on github to
create the new repo so if you cloned from that, there should be no
difference unless you have manually updating them.
On 8/23/2016 10:23 AM, Niki Guldbrand wrote:
> Hi Wayne.
>
> My git repo contains all the tags from bzr all
Hi Wayne.
My git repo contains all the tags from bzr all ready.
On tir, 2016-08-23 at 10:16 -0400, Wayne Stambaugh wrote:
> It should. Anyone on the kicad-product-committers team has write
> access
> to lp:kicad. Since I need to figure out how to do this, I'll give it
> one more try before I th
It should. Anyone on the kicad-product-committers team has write access
to lp:kicad. Since I need to figure out how to do this, I'll give it
one more try before I throw in the towel. I just ran `git tag` and
there are no tags in our git repo. I thought the bzr tags got
translated to git tags by
How about I just do this? I think it'll let me push new branches...
On Aug 23, 2016 09:58, "Shane Burrell" wrote:
> If you really trust the branch and aren't concerned about history (prolly
> messy anyways), just create a stable branch in your repo, and checkout a
> clean from the remote to over
If you really trust the branch and aren't concerned about history (prolly
messy anyways), just create a stable branch in your repo, and checkout a
clean from the remote to overlay your stable branch and push that. More of
a replace than a merge. That's likely the cleanest way to do it. It would
I forgot to add, if you trust the divergent branch (because I imagine
its cherry-picked commits etc from master).
Then just do a git checkout and specify niki's branch from the remote
and a local branch name in the command line. Then push that branch.
This will combine the two.
__
Niki's branch is out of sync from the launchpad git tree and
kicad-source-mirror .
The hashes are different, thus the history is different and so a
pull (which does a merge) won't end well.
___
Mailing list: https://launchpad.net/~kicad-developers
Post
Thanks Niki and Chris. Now my ignorance of git will become obvious. I
just ran the following commands:
git remote add nikis-github-repo
https://github.com/nikgul/kicad-source-mirror.git
git checkout -b stable-4
git pull nikis-github-repo 4.0.x
and I'm getting conflicts on dozens files. This
Looks good to me. Wayne, I'd probably just pull from this if I were you.
On Mon, Aug 22, 2016 at 11:26:31PM +0200, Niki Guldbrand wrote:
> Hi Wayne.
>
> I have pushed an updated 4.0.x branch to github, please have a look and
> see if you can use it as is, or ... ?
>
>
> On man, 2016-08-22 at 16
Hi Wayne.
I have pushed an updated 4.0.x branch to github, please have a look and
see if you can use it as is, or ... ?
On man, 2016-08-22 at 16:39 -0400, Wayne Stambaugh wrote:
> I only need a snapshot of the current 4 stable branch r6308 tag
> 4.0.4.
> I'm the only one with commit access so I
I only need a snapshot of the current 4 stable branch r6308 tag 4.0.4.
I'm the only one with commit access so I can guarantee it wont change.
If you update your stable 4 branch, I'll pull this into my repo and then
push it to the kicad repo as the stable 4 branch and then make the bzr
stable 4 repo
On Mon, Aug 22, 2016 at 01:06:37PM -0400, Wayne Stambaugh wrote:
> I fine with keeping the github mirror. Someone will have to change the
> url from the obsolete bzr repo to the new git repo.
Many many thanks to all of you.
I am not (really) a dev but I think that this transition and all other
s
Hi Again.
Forgot to provide a link to a description of the model, so here it is:
http://nvie.com/posts/a-successful-git-branching-model/
On man, 2016-08-22 at 20:12 +0200, Niki Guldbrand wrote:
> Hi All.
>
> I Have a copy of 4.0.x in my git repo at github [1], although I
> havent
> updated it
Hi All.
I Have a copy of 4.0.x in my git repo at github [1], although I havent
updated it in som time, but the setup is still there, I just need to
install the git bzr plugin again, and I can keep it updated for some
time if you wish ?
I also have an suggestion, that you might want to adopt the g
I fine with keeping the github mirror. Someone will have to change the
url from the obsolete bzr repo to the new git repo.
On 8/22/2016 11:59 AM, Mark Roszko wrote:
> The github mirror is useful to keep because its usually far faster
> than launchpad and easier to deal with for personal developme
And need update the Wiki
https://github.com/KiCad/kicad-source-mirror/wiki
В Понедельник, 22 авг. 2016 в 7:16 , Eldar Khayrullin
написал:
But need to close posibilities to create ISSUE or PR.
В Понедельник, 22 авг. 2016 в 6:59 , Mark Roszko
написал:
The github mirror is useful to keep bec
But need to close posibilities to create ISSUE or PR.
В Понедельник, 22 авг. 2016 в 6:59 , Mark Roszko
написал:
The github mirror is useful to keep because its usually far faster
than launchpad and easier to deal with for personal development.
The benefit is that after someone does all their
The github mirror is useful to keep because its usually far faster
than launchpad and easier to deal with for personal development.
The benefit is that after someone does all their work on github, one
can simply push it back to launchpad with zero issues by just adding
another remote.
Bzr on the
In launchpad git bug tagged in commit message like :
bug #id
Launchpad give a link to.
В Понедельник, 22 авг. 2016 в 6:38 , Wayne Stambaugh
написал:
I just tagged 4.0.4 so technically you can start creating packages
against it. I'm not sure of the status of the doc, lib, and
translation
repo
Feel free to procrastinate the announcement.
Since it seems we will reuse the 4.0.3 doc, lib and i18n but I they have
not been retagged yet, it is ok to delay it half a day. Alternately you
could make the announcement a draft and I can publish it when ready.
Den 22/08/2016 17.46 skrev "Wayne Sta
I just tagged 4.0.4 so technically you can start creating packages
against it. I'm not sure of the status of the doc, lib, and translation
repos. I will try to make the announcement before I go out of town for
the weekend but I cannot promise that it will happen.
On 8/22/2016 10:50 AM, Adam Wolf
Hello.
I think need to rename .bzrignore to .gitignore and to remove
.gitconfig.
P.S. I don't know but I have issue with this one when I use
~/.gitignore_global.
В Понедельник, 22 авг. 2016 в 5:36 , Wayne Stambaugh
написал:
Let me tag 4.0.4 first since I'm hoping to roll out another stable
FYI the guy syncing bzr to the kicad-source-mirror managed to make it work.
Although it seems like he only pushed the 4.0 branch once. There is a 4.0
branch in that. (Sorry I don't remember his name exactly now)
Den 22/08/2016 16.34 skrev "Chris Pavlina" :
> I'm used to git repo surgery enough to
This package dev is fine with you waiting a few days for 4.0.4, but let's
not stretch out much more than that.
On Mon, Aug 22, 2016 at 9:21 AM, Chris Pavlina
wrote:
> On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> > On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > > Hi, Wayne!
Let me tag 4.0.4 first since I'm hoping to roll out another stable
release soonish. I'll do this right now. I can push this release back
a few days until we get the 4 stable branch merged into the main kicad
git repo. Thanks for the help. Anyone else object to this? I'm
thinking about my packa
I'm used to git repo surgery enough to make the branch - if nobody else
does it before I get out of work tonight, I'll do it then.
As Shane says it should be very easy though, assuming there's nothing
funny going on.
On Mon, Aug 22, 2016 at 10:26:46AM -0400, Shane Burrell wrote:
> It should be re
On 8/22/2016 10:13 AM, Chris Pavlina wrote:
> On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
>> On 8/22/2016 9:53 AM, Clemens Koller wrote:
>>> Hi, Wayne!
>>>
>>> On 2016-08-22 14:09, Wayne Stambaugh wrote:
I wasn't planning on migrating the stable 4 branch to git. I'm hopin
It should be really easy. Create a branch and overlay stable 4 branch via
manual or checkout the hash mark you need and commit to branch. I
typically do a develop branch (bleeding edge) and branch of stable without
any issues and created stable in same fashion the first time.
On Mon, Aug 22, 201
On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > Hi, Wayne!
> >
> > On 2016-08-22 14:09, Wayne Stambaugh wrote:
> >> I wasn't planning on migrating the stable 4 branch to git. I'm hoping
> >> there wont be too many more 4 stable re
What Chris said is exactly what I'd ask for!
Adam Wolf
On Mon, Aug 22, 2016 at 9:13 AM, Chris Pavlina
wrote:
> On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> > On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > > Hi, Wayne!
> > >
> > > On 2016-08-22 14:09, Wayne Stambaugh wrote
On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > Hi, Wayne!
> >
> > On 2016-08-22 14:09, Wayne Stambaugh wrote:
> >> I wasn't planning on migrating the stable 4 branch to git. I'm hoping
> >> there wont be too many more 4 stable re
On 8/22/2016 9:53 AM, Clemens Koller wrote:
> Hi, Wayne!
>
> On 2016-08-22 14:09, Wayne Stambaugh wrote:
>> I wasn't planning on migrating the stable 4 branch to git. I'm hoping
>> there wont be too many more 4 stable releases so I'm not sure it's worth
>> the effort.
>
> Ok, I was wondering...
Hi, Wayne!
On 2016-08-22 14:09, Wayne Stambaugh wrote:
> I wasn't planning on migrating the stable 4 branch to git. I'm hoping
> there wont be too many more 4 stable releases so I'm not sure it's worth
> the effort.
Ok, I was wondering...
I was missing the stable branch, too - as well as all the
There is one issue. I cannot associate series or milestone to a git
repo. This means the nifty timeline on the summary page doesn't work.
If you click on the product-git series, you will find there is no repo
association like there was with the bzr product repo. I don't know if
this something th
I wasn't planning on migrating the stable 4 branch to git. I'm hoping
there wont be too many more 4 stable releases so I'm not sure it's worth
the effort.
On 8/21/2016 11:45 PM, kinichiro inoguchi wrote:
> Hi,
> Thanks for transitioning to git !
>
> Do you plan to move stable 4.0 blanch, too ?
This is really excellent news! Thank you Wayne!
The webhook is already set, let's fix a few bugs to see if it works.
Just to remind you, there is a git config file that should ease marking
commits as bug fixes [1].
Cheers,
Orson
1. https://lists.launchpad.net/kicad-developers/msg25728.html
On 0
Hi,
Thanks for transitioning to git !
Do you plan to move stable 4.0 blanch, too ?
Mainly for GUI translation work, I would like to check stable 4.0.
If it remains in bzr, I will check the bzr stable 4.0 blanch.
Thanks a lot.
___
Mailing list: https:/
Thanks to everyone who worked on this issue. I can't wait to be
able to bury bzr. I was holding off on proposing a merge of OCE
related bits because I really needed git rebase and bzr just couldn't
deliver anything remotely useful.
- Cirilo
On Mon, Aug 22, 2016 at 9:34 AM, Wayne Stambaugh
wrot
Christmas in August has arrived! I think. I've switch the KiCad
project over to Git and the product branch (renamed product-git to avoid
conflict with the bzr product branch) seems to be up to date and ready
to go. As with the product branch the product-git branch is owned by
the kicad-product-c
2016-08-21 20:26 GMT+02:00 Chris Pavlina :
> On Sun, Aug 21, 2016 at 11:30:11AM -0400, Wayne Stambaugh wrote:
>> > [snip]
>>
>> To all my developers with commit access, please do not commit any
>> changes to the product branch until further notice. I am going to
>> attempt to switch the project ov
On Sun, Aug 21, 2016 at 02:26:04PM -0400, Chris Pavlina wrote:
> It's like Christmas!! :O
Well *I* personally suck with both bzr and git since I am an svn user...
However bzr gave me a lot of problem (and still doesn't properly support
a proxy!) and in general I had less issues with projects usi
On Sun, Aug 21, 2016 at 11:30:11AM -0400, Wayne Stambaugh wrote:
> > [snip]
>
> To all my developers with commit access, please do not commit any
> changes to the product branch until further notice. I am going to
> attempt to switch the project over to use git as the default vcs
> sometime later
On 08/21/2016 05:30 PM, Wayne Stambaugh wrote:
[snip]
> To all my developers with commit access, please do not commit any
> changes to the product branch until further notice. I am going to
> attempt to switch the project over to use git as the default vcs
> sometime later today and I don't want t
On 8/12/2016 3:44 PM, Wayne Stambaugh wrote:
> On 8/12/2016 5:36 AM, Maciej Sumiński wrote:
>> On 08/11/2016 08:28 PM, Wayne Stambaugh wrote:
>> [snip]
>>> I'll see if I can figure out how to do this and if it works we can use
>>> it instead of adding the bug report url to the commit message. I wo
I think git-SUM is something like that:
$ git log --oneline | wc -l
В Пятница, 12 авг. 2016 в 11:26 , Nick Østergaard
написал:
What do you mean with git-SUM, is that the bzrlike revno or is that
the short git sha1?
I personally like the way we have it now with the build date, the
bzrlike revn
On Fri, Aug 12, 2016 at 04:31:52PM -0400, Wayne Stambaugh wrote:
> [snip] I just want to do things because that's what all the
> cool kids are doing. If it makes sense, then we should adopt it. If
> not we should do what is appropriate for us. In this case is seems to
> make sense.
We're only t
On 8/12/2016 4:30 PM, Chris Pavlina wrote:
> On Fri, Aug 12, 2016 at 03:34:35PM -0400, Wayne Stambaugh wrote:
>> On 8/11/2016 11:28 AM, Chris Pavlina wrote:
>>> I stand by my recommendation to use a "Fixes: lp:n" on a line by
>>> itself. This is _established convention_ in git commit messages.
On Fri, Aug 12, 2016 at 03:34:35PM -0400, Wayne Stambaugh wrote:
> On 8/11/2016 11:28 AM, Chris Pavlina wrote:
> > I stand by my recommendation to use a "Fixes: lp:n" on a line by
> > itself. This is _established convention_ in git commit messages. A quick
> > example from the Linux kernel tree
What do you mean with git-SUM, is that the bzrlike revno or is that
the short git sha1?
I personally like the way we have it now with the build date, the
bzrlike revno serial and the git sha1.
Or are you suggesting to do like (2016-08-03 2383bcf-6299)-product
instead of (2016-08-03 BZR 6299, Git
On 8/12/2016 5:36 AM, Maciej Sumiński wrote:
> On 08/11/2016 08:28 PM, Wayne Stambaugh wrote:
> [snip]
>> I'll see if I can figure out how to do this and if it works we can use
>> it instead of adding the bug report url to the commit message. I wonder
>> if we can link a commit to a bug report? T
I'm OK with git-SUM rather than the obnoxiously long git rev numbers.
Anyone object to this?
On 8/12/2016 1:25 AM, Simon Wells wrote:
> In regards to this, Currently bzr revs are just the number and the git
> revs are the bzr number and the git sum. Is it worthwhile (esspeically
> in the title bar
On 8/11/2016 11:28 AM, Chris Pavlina wrote:
> I stand by my recommendation to use a "Fixes: lp:n" on a line by
> itself. This is _established convention_ in git commit messages. A quick
> example from the Linux kernel tree has Reported-by, Requested-by, Cc,
> Signed-off-by all formatted in this
On 08/11/2016 08:28 PM, Wayne Stambaugh wrote:
[snip]
> I'll see if I can figure out how to do this and if it works we can use
> it instead of adding the bug report url to the commit message. I wonder
> if we can link a commit to a bug report? That could be an issue if we
> cannot. I don't want
In regards to this, Currently bzr revs are just the number and the git
revs are the bzr number and the git sum. Is it worthwhile (esspeically
in the title bar just changing this to git-BZRREV or just git-SUM
since git will be the primary vcs?
On Fri, Aug 12, 2016 at 7:55 AM, Adam Wolf
wrote:
> So
Sounds good! I think that timeline is fine.
Adam Wolf
On Thu, Aug 11, 2016, 2:54 PM Wayne Stambaugh wrote:
> You have a couple of options.
>
> You could just clone directly from the source mirror on github for
> testing then update the url when we go live with git on launchpad.
>
> You could c
You have a couple of options.
You could just clone directly from the source mirror on github for
testing then update the url when we go live with git on launchpad.
You could create your own clone of the github source mirror and add a
remote link to your own personal git branch on launchpad and us
It should. Can we somehow push a copy of what it is now so I have
something to build against?
On Thu, Aug 11, 2016, 1:52 PM Wayne Stambaugh wrote:
> If we go live with git on 8/21, will that give you enough time to get
> things squared away on your end?
>
> On 8/11/2016 2:41 PM, Adam Wolf wrote
If we go live with git on 8/21, will that give you enough time to get
things squared away on your end?
On 8/11/2016 2:41 PM, Adam Wolf wrote:
> The Git part will take maybe 1 week for OS X. I am in favor of this
> transition.
>
> Adam Wolf
>
>
> On Aug 11, 2016 1:31 PM, "Wayne Stambaugh"
The Git part will take maybe 1 week for OS X. I am in favor of this
transition.
Adam Wolf
On Aug 11, 2016 1:31 PM, "Wayne Stambaugh" wrote:
> On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> >>>
On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
>> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
>>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
The last time I looked, notifications of repo commits still were not
implemented. This is a sho
I stand by my recommendation to use a "Fixes: lp:n" on a line by
itself. This is _established convention_ in git commit messages. A quick
example from the Linux kernel tree has Reported-by, Requested-by, Cc,
Signed-off-by all formatted in this way.
Come on... it's established convention alread
Den 11/08/2016 11.18 skrev "Maciej Sumiński" :
>
> On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> > On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> >> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> >>> The last time I looked, notifications of repo commits still were not
> >>> implemented. This
On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
>>> The last time I looked, notifications of repo commits still were not
>>> implemented. This is a show stopper for me. I don't want to have to
>>> cons
On 08/10/2016 04:49 PM, Chris Pavlina wrote:
[snip]
> Any particular reason for having (fixes lp:) in the first
> line? Typically the first line of the commit message is kept very
> short and limited to things one might need when quickly browsing a
> log. The usual convention in git is to w
On Wed, Aug 10, 2016 at 9:34 AM, Wayne Stambaugh wrote:
>
> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> > On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> >> The last time I looked, notifications of repo commits still were not
> >> implemented. This is a show stopper for me. I don't want to h
On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
>> The last time I looked, notifications of repo commits still were not
>> implemented. This is a show stopper for me. I don't want to have to
>> constantly grep the git commit log to see what changed.
On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> The last time I looked, notifications of repo commits still were not
> implemented. This is a show stopper for me. I don't want to have to
> constantly grep the git commit log to see what changed. If change
> notifications are working correctly, t
I understand that many people will be using the Bzr UI tools, but Git is
very good at enabling digging in the history using the command line.
I have a handy Git alias which shows me a condensed version of the history
(it's actually coloured in my terminal, so it's really clear what's going on):
*
I was really confused for a minute when someone verbosely said git log
master..origin/master
Here's my current aliases. Aliases really make git awesome. Pay
particular attention to `git hist` and `git ll` and `git d`
[alias]
co = checkout
ci = commit
st = status
br = branc
Well, I can't help with getting email notifications, but I don't
understand why logs are being grepped either. Getting a summary of
changes since the last update should be as simple as 'git fetch'
followed by something like 'git log master..origin/master', and you'll
get it in a nice summary form :
On 8/8/2016 12:23 PM, Chris Pavlina wrote:
> Well, we're not looking at Github anymore, right? Just Git on Launchpad?
> So the pull request thing doesn't matter.
>
> We use Stash (Bitbucket) at work, it seems to give much better control.
> GitLab is also popular. I really, really want to see us sw
Well, we're not looking at Github anymore, right? Just Git on Launchpad?
So the pull request thing doesn't matter.
We use Stash (Bitbucket) at work, it seems to give much better control.
GitLab is also popular. I really, really want to see us switch to git,
as do many others, but I don't really ca
The last time I looked, notifications of repo commits still were not
implemented. This is a show stopper for me. I don't want to have to
constantly grep the git commit log to see what changed. If change
notifications are working correctly, then I'm OK with moving forward on
this if you can get t
Hi Maciej,
It would be a net benefit for the OS X builder for us to switch to git.
The Jenkins bzr plugin is not very good. Usually when the OS X nightlies
stop for a few days, it is because the plugin got stuck updating and never
times out. I tried to fix it upstream but there were issues.
It
Apparently we have not discussed git transition for a long time now, so
I felt it is the right time to raise the subject again to keep our routine.
Launchpad now supports merge proposals [1] and it looks like they are
still improving git integration. The only missing feature are links
between bug
99 matches
Mail list logo