[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
|
From incoming answers I seem to understand that everybody knows something but
there's no clear consensus of what should be done when. I could see a tendency
that Eclipse doesn't care, *how* GitHub is used, since everybody can just search
the net for how others are using it.
If, however, JDT still prefers a coordinated, somewhat uniform approach, I'd
suggest: let's first agree on *where* the results of this discussion should be
captured (I regard a mailing list as the least suitable option for this).
Should we maintain jdt.core's CONTRIBUTING.md accordingly? Should we coordinate
and push this into the next level (JDT)?
As further indication that more coordination would be desirable: concerning
rebase Läubi suggested to "Simply rebase your change and push it". Just now -
incidentally - I found that .github/workflows/rebase.yml implements exactly what
I was asking for :)
best,
Stephan
Am 09.09.22 um 09:10 schrieb Jayaprakash Arthanareeswaran:
For the last item you just mentioned, if it helps, we can issue guideline asking
Contributors to just push delta to their branch and avoid force push branch.
Regards,
Jay
-----Original Message-----
From: jdt-dev <jdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Stephan Herrmann
Sent: 08 September 2022 18:55
To: jdt-dev@xxxxxxxxxxx
Subject: [EXTERNAL] Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
One more thing:
In the gerrit era, it was always transparent what was changed from one changeset to the next. In GitHub it seems to be popular to just force-push the latest and greatest, which seems like reviewers will have to start reviewing from scratch, or is there some magic incantation that will show them differences between the current branch and one that no longer exists?
best,
Stephan
Am 08.09.22 um 15:06 schrieb Stephan Herrmann:
It feels like I asked this before, but as I can't find this info in
any canonical place I will keep asking:
How can I tell github to
- rebuild a PR unchanged
(e.g., when a failure was intermittent, when a period check is
outdated)
- when a jenkins build is still available
- after the jenkins build has been deleted
- rebase a PR on HEAD and rebuild
Please don't just answer here, but provide a link to the persistent,
canonical location where such information can be found. Hopefully,
that location can be remembered easily and will answer all related questions.
thanks,
Stephan
PS: Are there other tidbits committers should observe when working with github?
In the bugzilla era there was a lot of information we recorded in each
bug report, like Version and Target Milestone. Is JDT planning to
apply similar discipline in github? Are labels to be used in some coordinated style?
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
