m/en/actions/using-workflows/reusing-workflows
Gesendet: Donnerstag, 24. März 2022 um 17:35 Uhr
Von: "Christoph Läubrich"
An: platform-dev@eclipse.org
Betreff: Re: [platform-dev] Github workflow
If you don't like to suggest to Egit to add some magic, you can suggest
to Github to add a si
to Egit to add some magic, you can suggest
> to Github to add a similar header:
>
> https://github.community/
>
> Am 24.03.22 um 17:30 schrieb Andrey Loskutov:
> >> Gesendet: Donnerstag, 24. März 2022 um 17:03 Uhr
> >> Von: "Christoph Läubrich"
> >>
rg
Betreff: Re: [platform-dev] Github workflow
Sorry for confusion then I probably don't get it. What has Egit/Eclipse
Ui to do with gerrit?
Nothing.
I use Egit to read the history.
Because I work with my code from within my IDE, not with github.
Gerrit writes url of the PR to the commit header.
Sorry for confusion then I probably don't get it. What has Egit/Eclipse
Ui to do with gerrit?
If I check with with my eclipse SDK things like "Bug " are not
linked even though they are on git-eclipse or do you mean
Reviewed-on:?
in the commit message if it was merged through gerrit?
Am 24. März 2022 16:37:20 MEZ schrieb "Christoph Läubrich"
:
>This describes all automatically discovered references by Github:
>
>https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls#issues-and-pull-requests
>
>You can
This describes all automatically discovered references by Github:
https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls#issues-and-pull-requests
You can automatically link issues with cour commit/pr:
Am 24. März 2022 14:07:12 MEZ schrieb Aleksandar Kurtakov :
>>1. All the commits should have an issue, created in the same
>>repository, number associated with them
>> 1. #
>>
>> I don't think it is necessary to have issues for each commit(more of an PR
>as it may be multiple
jects(organizations), my
>preference would be
>https://github.com/eclipse-platform/eclipse.platform
>
>
>
> Thanks
>
> Sravan
>
> *From:* platform-dev *On Behalf Of *Mickael
> Istria
> *Sent:* 24 March 2022 17:40
> *To:* Eclipse platform general developers
zations), my preference
would be https://github.com/eclipse-platform/eclipse.platform
Thanks
Sravan
From: platform-dev On Behalf Of Mickael
Istria
Sent: 24 March 2022 17:40
To: Eclipse platform general developers list.
Subject: [EXTERNAL] Re: [platform-dev] Github workflow
Hi, I'm putting a few
I like all this.
I don't like forks and used to have branches on main repo - not recommended.
>
> Indeed. The "upstream" repo shouldn't be used as a workspace for ongoing
work. Your workspace is your fork.
Also, this is free to choose from. If one wants to work with a fork (e.g.
to stash WIP),
Hi,
I'm putting a few answers here, but those could go to the document pointed
out by Sravan (which by the way could be renamed to CONTRIBUTING.md)
> I don't like forks and used to have branches on main repo - not
> recommended.
>
Indeed. The "upstream" repo shouldn't be used as a workspace
ith recommended approach
>
> Thanks
> Sravan
>
> -Original Message-
> From: platform-dev On Behalf Of Andrey
> Loskutov
> Sent: 24 March 2022 03:57
> To: Eclipse platform general developers list.
> Subject: [EXTERNAL] Re: [platform-dev] Github workflow
&g
On Behalf Of Andrey
Loskutov
Sent: 24 March 2022 03:57
To: Eclipse platform general developers list.
Subject: [EXTERNAL] Re: [platform-dev] Github workflow
Am 22. März 2022 14:11:21 MEZ schrieb Aleksandar Kurtakov :
>Please bear with us while we try to improve the contributor workf
Am 22. März 2022 14:11:21 MEZ schrieb Aleksandar Kurtakov :
>Please bear with us while we try to improve the contributor workflow with
>the limited time we have. And keep asking each step and requirement as only
>that way we will figure what is really needed and brings benefit and what
>is done
On Tue, Mar 22, 2022 at 2:52 PM Christoph Läubrich
wrote:
> > Given the plethora of repositories that comprise
> > the Eclipse SDK
>
> Even though it was considered "not important" I always has suggested to
> actually merge related stuff into one repository, this splitting across
> different
> I don't have the same experience here in general:
You are right. After the force, there is a backdoor to previous comments.
[image: image.png]
On Tue, 22 Mar 2022 at 13:45, Mickael Istria wrote:
>
>
> On Tue, Mar 22, 2022 at 1:39 PM Wim Jongman wrote:
>
>>
>>
>>> What particularly do you
> Given the plethora of repositories that comprise
> the Eclipse SDK
Even though it was considered "not important" I always has suggested to
actually merge related stuff into one repository, this splitting across
different repos is just a pain, and we should not blame the tools for
not
On Tue, Mar 22, 2022 at 1:39 PM Wim Jongman wrote:
>
>
>> What particularly do you think does not work well with it?
>>
>
> File reviews or bound to the commit id and when you force push, the review
> is gone. See the screenshot below. This makes it very hard for the reviewer
> to see if their
> What particularly do you think does not work well with it?
>
File reviews or bound to the commit id and when you force push, the review
is gone. See the screenshot below. This makes it very hard for the reviewer
to see if their suggestions have been followed.
>
>
>> I propose to just keep
On Tue, Mar 22, 2022 at 12:23 PM Wim Jongman wrote:
> Also, we need to discuss the --force parameter. It will not work well with
> the Github review system.
>
What particularly do you think does not work well with it?
> I propose to just keep committing on the branch (a bit like Gerrit change
I agree. These local branches tend to stay:
https://git.eclipse.org/c/platform/eclipse.platform.ui.git/refs/heads
On Tue, 22 Mar 2022 at 12:38, Aleksandar Kurtakov
wrote:
>
>
> On Tue, Mar 22, 2022 at 1:25 PM Lars Vogel wrote:
>
>> Sorry, if that was said before (I did not read all
On Tue, Mar 22, 2022 at 1:25 PM Lars Vogel wrote:
> Sorry, if that was said before (I did not read all discussions in
> detail) but committers can create PR for the same repository without
> the additional fork.
>
> So a possible workflow is:
> 1.) Clone repo
> 2.) Create new local branch
> 3.)
Sorry, if that was said before (I did not read all discussions in
detail) but committers can create PR for the same repository without
the additional fork.
So a possible workflow is:
1.) Clone repo
2.) Create new local branch
3.) Push local branch to new branch in origin
4.) Create PR from new
Mickael, yes your WF is very cunning, I will try that. I think the two
methods can happily co-exist.
My proposed WF is arguably a bit easier for people that aren't that Git
savvy. In my experience, it works very well to get people started.
Also, we need to discuss the --force parameter. It will
Hi,
What comes to mind is 'origin' and 'upstream' repositories. Where 'origin'
is your fork and the 'upstream' the forked repo.
Your workflow seems to fetch from 'upstream' (aka eclipse) and push to
origin (aka me), after which a PR is made from 'orgin' back to 'upstream'.
With the right settings
Hi,
On Tue, Mar 22, 2022 at 10:46 AM Wim Jongman wrote:
>
>1. Go to your fork and "Fetch upstream" [1]
>
> Why do you need to do that? Particularly if you never use master/main?
FWIW, may workflow is
$ git fetch eclipse master
$ git checkout FETCH_HEAD
[... do changes ...]
$ git commit -m
In BIRT, Windowbuilder, and Nebula we successfully use the following
workflow:
1. Fork the main repo
2. Create an issue in the main repo e.g. "My Issue" #1 (#1 being the
next ID)
3. Make changes in a branch in your fork (not in master/main)!!!
4. Commit with "My Issue #1"(include
27 matches
Mail list logo
