On 2017-02-28 17:37, Nick Sabalausky (Abscissa) wrote:
Maybe they should be, but with the basic git interface, or any front-end
I've seen, they're terribly convoluted. Particularly squashing. Well,
either that, or the docs are just really, REALLY bad.
There's no reason either one of those
On 02/28/2017 12:18 PM, H. S. Teoh via Digitalmars-d wrote:
Whut...? What can be easier than:
git checkout my_bug_fix
git rebase -i master
# Editor pops up, change "pick" to "squash" (or "s" for short)
# for every commit you wish to squash.
git push -f
On Tue, Feb 28, 2017 at 06:24:45PM +, Russel Winder via Digitalmars-d wrote:
> On Tue, 2017-02-28 at 09:18 -0800, H. S. Teoh via Digitalmars-d wrote:
> > […]
>
> > 30-year-old typographical infelicities like 'grep'.)
>
> Surely typing grep is far easier than get_regular_expression_print
It
On Tue, 2017-02-28 at 09:18 -0800, H. S. Teoh via Digitalmars-d wrote:
> […]
> 30-year-old typographical infelicities like 'grep'.)
Surely typing grep is far easier than get_regular_expression_print
>
[…]
> Curious to see what you come up with. AIUI, git is already providing
> the 'porcelain'
On Tue, Feb 28, 2017 at 11:37:45AM -0500, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
> On 02/28/2017 02:37 AM, Jacob Carlborg wrote:
> > On 2017-02-28 00:42, Nick Sabalausky (Abscissa) wrote:
> >
> > > Contributors shouldn't have to know as much about git as a
> > > project's
On Tuesday, 28 February 2017 at 15:49:56 UTC, Andrei Alexandrescu
wrote:
There can be any amount of discussion about this, to no
conclusive results, and any argument may be responded with "I
don't buy that". That's simply because, again, there's some
subjective factor and there is no perfect
On 02/28/2017 02:37 AM, Jacob Carlborg wrote:
On 2017-02-28 00:42, Nick Sabalausky (Abscissa) wrote:
Contributors shouldn't have to know as much about git as a project's
maintainers. So these features, if used, are AWESOME.
Squashing and rebasing is part of the basic git, in my opinion.
On 02/28/2017 11:03 AM, Seb wrote:
On Tuesday, 28 February 2017 at 14:52:36 UTC, Andrei Alexandrescu wrote:
Thanks. I'd replace "changes should be split into as many commits as
is reasonable" with "changes should be split into as many pull
requests as is reasonable", which is a natural
On Tuesday, 28 February 2017 at 14:52:36 UTC, Andrei Alexandrescu
wrote:
Thanks. I'd replace "changes should be split into as many
commits as is reasonable" with "changes should be split into as
many pull requests as is reasonable", which is a natural
consequence of "most pull requests should
On 02/28/2017 10:04 AM, Vladimir Panteleev wrote:
On Tuesday, 28 February 2017 at 14:52:36 UTC, Andrei Alexandrescu wrote:
Thanks. I'd replace "changes should be split into as many commits as
is reasonable" with "changes should be split into as many pull
requests as is reasonable", which is a
On Tuesday, 28 February 2017 at 14:52:36 UTC, Andrei Alexandrescu
wrote:
Thanks. I'd replace "changes should be split into as many
commits as is reasonable" with "changes should be split into as
many pull requests as is reasonable", which is a natural
consequence of "most pull requests should
On 02/28/2017 08:48 AM, Vladimir Panteleev wrote:
On Tuesday, 28 February 2017 at 13:10:17 UTC, Andrei Alexandrescu wrote:
This would be the overwhelmingly frequent case.
...
This indicates a problem with the PR more often than not.
It is unfortunate that these two seem to be true right now,
On Tuesday, 28 February 2017 at 13:10:17 UTC, Andrei Alexandrescu
wrote:
This would be the overwhelmingly frequent case.
...
This indicates a problem with the PR more often than not.
It is unfortunate that these two seem to be true right now, so
given that, I'll agree with you. Currently a
On 02/28/2017 01:07 AM, Vladimir Panteleev wrote:
On Sunday, 26 February 2017 at 14:38:03 UTC, Seb wrote:
1) Commit squashing
Reminder: please only do this only when it makes sense to (one commit
with significant changes followed by fixup commits that have no
significance on their own).
On 2017-02-28 00:42, Nick Sabalausky (Abscissa) wrote:
Contributors shouldn't have to know as much about git as a project's
maintainers. So these features, if used, are AWESOME.
Squashing and rebasing is part of the basic git, in my opinion.
--
/Jacob Carlborg
On Sunday, 26 February 2017 at 14:38:03 UTC, Seb wrote:
1) Commit squashing
Reminder: please only do this only when it makes sense to (one
commit with significant changes followed by fixup commits that
have no significance on their own). If the PR already has
multiple commits split into
On Sunday, 26 February 2017 at 14:38:03 UTC, Seb wrote:
As it's getting a bit exhaustive to repeat these bits on GitHub
over and over again,
I though I summarize a couple of notes that hopefully are
interesting for the DLang maintainers.
[...]
This is great, please put this somewhere (the
On 02/26/2017 09:38 AM, Seb wrote:>
Review workflow (squashed commits & write access to PRs)
Hoora for these *Please* lets make use of these.
Pretty much everything about the old way couldn't have been any better
at dissuading regular contributors if it had be DESIGNED to discourage
On Sunday, 26 February 2017 at 14:38:03 UTC, Seb wrote:
[snip]
Excellent, this info will be useful!
- All commits get squashed into one commit before the merge
- This is enabled for all DLang repos
- "auto-merge-squash" does squashing as auto-merge behavior
I especially liked this one. No
As it's getting a bit exhaustive to repeat these bits on GitHub
over and over again,
I though I summarize a couple of notes that hopefully are
interesting for the DLang maintainers.
Please take this as a friendly summary and personal advice of
most GH-related process improvements that have
20 matches
Mail list logo
