Hi Francis,
I had the impression that squash merge also retains the linear history.
I am always performing these operations using the git client; is the result
different when using Github?
Best,
Stamatis
Στις Πέμ, 3 Ιαν 2019 στις 11:37 μ.μ., ο/η Francis Chuang <
francischu...@apache.org> έγραψε:
Hey Stamatis,
Squash merge on Github does preserve linear history. The commits are
squashed into a new commit and then added to master.
The problem with squash commit merge on Github is that the author of the
squashed commit is set to the person who merged the PR and the committer
is set to
What we've done in the past is to add the original author's name in
parentheses to the commit message. Not ideal, but better than losing the
attribution entirely. I think it would be good to make an effort to ask the
contributor to do the squash themselves but in some cases, the PR is ready
to merg
Thanks for the clarification Francis.
Using the git client it is possible to preserve the original author (even
in the case of a squash merge) by setting the --author parameter during the
commit.
Example: git commit --author="Stamatis Zampetakis "
I guess that's not possible with Github.
Στις Π
>I guess that's not possible with Github.
AFAIK all merge options (rebase, squash, merge) at GitHub
automatically keep PR author.
Vladimir
> On Jan 4, 2019, at 6:37 AM, Michael Mior wrote:
>
> What we've done in the past is to add the original author's name in
> parentheses to the commit message. Not ideal, but better than losing the
> attribution entirely.
Let’s not do that. The author’s name must be in the git commit’s “author
I wasn't advocating this, just explaining what has been done in the past.
If the squash merge button on GitHub keeps authorship, I would prefer to
keep that enabled.
--
Michael Mior
mm...@apache.org
Le ven. 4 janv. 2019 à 12:06, Julian Hyde a écrit :
>
>
> > On Jan 4, 2019, at 6:37 AM, Michael
Michael> If the squash merge button on GitHub keeps authorship
According to https://github.com/isaacs/github/issues/1368#issuecomment-427647139
it will set author name/email from GitHub details.
Vladimir
Hi,
I am trying to use calcite as a library/abstraction layer to front several
DB backends and route queries to the backend best suited for the query.
For example for a table in hive if a subset of columns referenced in a
query have been replicated in postgres we will reroute the query to
postgr
Would this example of query optimization using Calcite help?
https://github.com/michaelmior/calcite-notebooks/blob/master/query-optimization.ipynb
If not, sharing the code you have so far and specifically pointing out the
problem you're having would be helpful.
--
Michael Mior
mm...@apache.org
That comment makes it sound like it will be the authorship information for
whoever presses the button, which is not what we want. If that's the case,
keeping the button disabled makes sense to me.
--
Michael Mior
mm...@apache.org
Le ven. 4 janv. 2019 à 13:14, Vladimir Sitnikov
a écrit :
> Mich
I tested the "squash merge" strategy on a test repo on Github yesterday.
Unfortunately, the author of the original commit is not preserved. The
author will be set to the person who merges the commit and the committer
is set to Github.
Francis
On 5/01/2019 7:40 am, Michael Mior wrote:
That co
Hi all,
I've been investigating/experimenting with adding support for dynamic
parameters in Druid (
https://github.com/apache/incubator-druid/tree/master/sql) and I've come up
with a few questions and was also wondering if there are any
recommendations or best practices on this matter?
My first q
13 matches
Mail list logo
