Am Sat, 24 May 2014 13:46:42 -0400
schrieb Igor Fedorenko :
> Second, pull-requests encourage multiple commits, when in most cases
> each pull-request corresponds to single logic change. This, too, makes
> commit history harder to comprehend for no good reason.
That is actually not a "requirement
Am Sat, 24 May 2014 19:06:24 +0200
schrieb Michael Osipov :
> Am 2014-05-24 18:57, schrieb Igor Fedorenko:
> > Please don't use Github PL merge functionality. This will create
> > merge commits... and I seriously dislike merge commits, hate them,
> > actually.
>
> Are you able to share your exper
GitHub user OhadR opened a pull request:
https://github.com/apache/maven-scm/pull/14
Update tfs.apt
working with check-in policies:
---
scm:tfs:https://tlvtfsnlbprd:8080:True:ohad:$/path/to/project
---
You can merge this pull request into a Git repository by runn
I don't know what git issues you mean, but I can explain why I dislike
github pull requests.
My problem with pull-requests is two-fold.
First, they create merge commits, which pollute commit history and make
it much harder to comprehend. I've seen projects with tens of parallel
commit "lanes" cr
Am 2014-05-24 18:57, schrieb Igor Fedorenko:
Please don't use Github PL merge functionality. This will create merge
commits... and I seriously dislike merge commits, hate them, actually.
Are you able to share your experience by improving the Git Convention on
the Maven website? Me and others w
Please don't use Github PL merge functionality. This will create merge
commits... and I seriously dislike merge commits, hate them, actually.
--
Regards,
Igor
On 2014-05-24, 12:39, Jason van Zyl wrote:
The mechanics of processing PRs from repos we have access to is all
good. But the Apache rep
I am not a Maven or other Apache committer. I just wanted to help and saw the
initial question about GitHub PRs which I have answered. I really cannot say
anything intelligent about the follow-up questions though, only one general
thing: Now you know what type of access right you need for GitHub
Am 2014-05-24 18:39, schrieb Jason van Zyl:
The mechanics of processing PRs from repos we have access to is all good. But
the Apache repos on Github I'm not sure who actually owns them, I assume ASF
infra. For any moderately sized PR I add the PR as a remote and process it
locally. But for sim
Am 2014-05-24 17:38, schrieb Alexander Kriegisch:
As for necessary permissions:
https://help.github.com/articles/what-are-the-different-access-permissions
That's good but how does one know whether he as Write Access Teams >
Repository Access' or not. Especially for mirrored repos.
--
Am 2014-05-24 17:09, schrieb Alexander Kriegisch:
Does this help?
https://help.github.com/articles/using-pull-requests
This can't help becuase the repos aren't located at github but at apache.
-
To unsubscribe, e-mail: dev-un
The mechanics of processing PRs from repos we have access to is all good. But
the Apache repos on Github I'm not sure who actually owns them, I assume ASF
infra. For any moderately sized PR I add the PR as a remote and process it
locally. But for simple patches I really would just like to hit th
As for necessary permissions:
https://help.github.com/articles/what-are-the-different-access-permissions
--
Alexander Kriegisch
> Am 24.05.2014 um 17:09 schrieb Alexander Kriegisch :
>
> Does this help?
> https://help.github.com/articles/using-pull-requests
> --
> Alexander Kriegisch
>
>
>>
Le samedi 24 mai 2014 05:15:31 Manfred Moser a écrit :
> I totally agree with William here. I also think that any standard that is
> not enforced easily is pointless.
+1
I measure it every time I take time to run the Checkstyle report and fix every
little inconsistency we made over time
> Thats w
Le samedi 24 mai 2014 11:10:04 William Ferguson a écrit :
> > parameters and local variables are not considered final: there is nothing
> > wrong
>
> with modifying their value, and nothing good to get by forcing them to be
>
> > final
>
> But there *is* value is defining them to be final.
>
>
Does this help?
https://help.github.com/articles/using-pull-requests
--
Alexander Kriegisch
> Am 24.05.2014 um 16:07 schrieb Jason van Zyl :
>
> Yes, I'm interested as well.
>
>> On May 24, 2014, at 9:33 AM, Michael Osipov wrote:
>>
>> Hi,
>>
>> does it take special permissions on Github t
Yes, I'm interested as well.
On May 24, 2014, at 9:33 AM, Michael Osipov wrote:
> Hi,
>
> does it take special permissions on Github to process pull requests?
>
> Neither am I allowed to perform the merge from the website directly, nor does
> it display the command line steps as described in
LifeCycleParticipant#afterProjectsRead is called after projects pom.xml
are read and MavenProject instances created but *before* actual build
starts. It is called for entire session and not any reactor project in
particular.
--
Regards,
Igor
On 2014-05-23, 21:03, William Ferguson wrote:
Thanks
Hi,
does it take special permissions on Github to process pull requests?
Neither am I allowed to perform the merge from the website directly, nor
does it display the command line steps as described in the GH help.
Close is not available to me too.
I simply pulled (PL 14) into my local repo a
Github user asfgit closed the pull request at:
https://github.com/apache/maven/pull/14
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enable
Argh .. I think I finally get it - thanks Igor.
On Sat, May 24, 2014 at 11:03 AM, William Ferguson <
william.fergu...@xandar.com.au> wrote:
> Thanks Igor.
>
>
>> A correct LifeCycleParticipant implementation should always scope
>> component lookups to the current project's classloader and should
20 matches
Mail list logo