I don't think the squash will prompt you for a new message -- what you could do as a workaround is use the PR tool to squash, then edit the commit message when the PR tool pauses and asks you if you want to merge to Apache. Once you edit the message, tell the PR tool to resume.
I'll have a look at updating it when I have a moment On Thu, May 26, 2016 at 11:47 AM Chris Riccomini <[email protected]> wrote: > Hey Jeremiah, > > I don't really have a specific flow in mind, so I'm OK with doing a squash > commit. I haven't tried the squash commit feature yet, since all of the PRs > I've merged have already been squashed. If I do a squash commit, can I just > set the message and that's the end of it? > > Cheers, > Chris > > On Thu, May 26, 2016 at 8:44 AM, Jeremiah Lowin <[email protected]> wrote: > >> @Chris to be clear, what workflow would you like to see? I think trying >> to do this without a squash commit (in other words editing individual >> commit messages) could get messy since it would require managing a rebase >> through the PR tool... >> >> On Thu, May 26, 2016 at 11:36 AM Jeremiah Lowin <[email protected]> >> wrote: >> >>> Yes it should be able to. Currently, if you tell the PR tool to squash >>> commits, it reattributes the author properly. So it should just be a matter >>> of adding a prompt for a new commit message. I will work on it. >>> >>> >>> On Wed, May 25, 2016 at 7:30 PM Chris Riccomini <[email protected]> >>> wrote: >>> >>>> Also, @Jeremiah, is it possible to make the airflow-pr tool allow us to >>>> change commit messages? I couldn't figure out a way to do this without >>>> affecting the git author, which removes attribution. It's kind of a >>>> pain to >>>> keep having to nag contributors to follow the guidelines. >>>> >>>> On Wed, May 25, 2016 at 3:30 PM, Chris Riccomini <[email protected] >>>> > >>>> wrote: >>>> >>>> > @Bolke, thanks for bringing this up. >>>> > >>>> > I wonder if it's possible to get a commit hook on our Apache repo to >>>> > prevent merges that don't follow at least some of the guidelines (e.g. >>>> > starts with [AIRFLOW-XXX], has a multi-line description). >>>> > >>>> > On Tue, May 24, 2016 at 8:55 AM, Maxime Beauchemin < >>>> > [email protected]> wrote: >>>> > >>>> >> There's also been some unapproved PRs that have been rush-merged. If >>>> you >>>> >> feel a sense of urgency towards a PR making it in master or in a >>>> release, >>>> >> that's a sign that you need to run your build off of a fork, where >>>> you're >>>> >> free to cherry pick any change you fancy. >>>> >> >>>> >> It's actually a positive things to have your changes running in your >>>> >> production prior to being merged as it distributes the risk (as >>>> opposed to >>>> >> havd all new code getting productionized as Airbnb) >>>> >> >>>> >> Maxime >>>> >> >>>> >> On Tue, May 24, 2016 at 12:52 AM, Bolke de Bruin <[email protected]> >>>> >> wrote: >>>> >> >>>> >> > Hi, >>>> >> > >>>> >> > I noticed that we started to slack a little in the commit messages. >>>> >> These >>>> >> > are the last commits excluding merges: >>>> >> > >>>> >> > aedb667 Make enhancements to VersionView >>>> >> > 0b3d101 [AIRFLOW-52] 1.7.1 version bump and changelog >>>> >> > 16740dd Add Kiwi.com as a user to README >>>> >> > 4b78e1a [AIRFLOW-143] setup_env.sh doesn't leverage cache for >>>> >> downloading >>>> >> > minicluster >>>> >> > 8ae8681 Increasing License Coverage >>>> >> > 7d32c17 Add a version view to display airflow version info >>>> >> > 4b25a7d [AIRFLOW-125] Add file to GCS operator >>>> >> > af43db5 [AIRFLOW-86] Wrap dict.items() in list for Py3 >>>> compatibility >>>> >> > f01854a Adding Nerdwallet to the list of Currently officially using >>>> >> > Airflow: >>>> >> > 843a22f [AIRFLOW-127] Makes filter_by_owner aware of multi-owner >>>> DAG >>>> >> > >>>> >> > Only one of those commits contains a description (4b25a7d). Only 4 >>>> out >>>> >> of >>>> >> > 10 start with an imperative and also only 4 out of 10 have a Jira >>>> >> attached >>>> >> > to them. I have no clue what “make enhancements to versionview” >>>> will do >>>> >> or >>>> >> > "setup_env.sh doesn't leverage cache for downloading minicluster”. >>>> >> > >>>> >> > If we are to collaborate in a consensus model and trust each other >>>> to >>>> >> have >>>> >> > good commits I think being able to use "git log” and actually >>>> understand >>>> >> > why (a what will be supplied by the diff) a change has been made is >>>> >> key. "A >>>> >> > project's long-term success rests (among other things) on its >>>> >> > maintainability and a maintainer has few tools more powerful than >>>> his >>>> >> > project's log.”. If you are not aware what composes good commits >>>> please >>>> >> > read http://chris.beams.io/posts/git-commit/ < >>>> >> > http://chris.beams.io/posts/git-commit/> , it is a really good >>>> article. >>>> >> > >>>> >> > Thanks! >>>> >> > Bolke >>>> >> > >>>> >> > >>>> >> > >>>> >> >>>> > >>>> > >>>> >>> >
