From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73549 invoked by alias); 19 Sep 2019 14:43:12 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 73540 invoked by uid 89); 19 Sep 2019 14:43:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=browser, H*c:alternative, emails X-HELO: mail-vs1-f68.google.com Received: from mail-vs1-f68.google.com (HELO mail-vs1-f68.google.com) (209.85.217.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Sep 2019 14:43:10 +0000 Received: by mail-vs1-f68.google.com with SMTP id s7so2460221vsl.2 for ; Thu, 19 Sep 2019 07:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceryinstitute.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gCwIwFkTNeFxATdhLKzQ0lM01v6WMY9sl/96l2+8OZM=; b=Tm6AaYupOdu9WvO2rGSVwXNtM1WP3/NBtJRSM//rfIWzXMpJCQjpBBVp1ZKvRVK6Wd 4MIJRwx0hgp4CQX/It8INYX3sp7RKRdJexnwblpLZq3RSGOY43fVxu71VbQNF/RRcw19 r9Tev/A483YT5SL2vGJr4/VPi/sR8A0Vn+/GFnRm+AIwfS8HWbnzzJmLl4cjq8tAc7Ly ZJ3qwZCm+RuPR49338XITMsaBUcIfsYx2MWUyHXAcTpUgX/FXmXikRaTx649Xce4R6f7 cG1xxHokyS6ugTwvf7sWdFfJ4hdDtCrIkA4HUJ9yqEwV+mJ1UTRHgNsxkb/TI3FZTllY w7Fg== MIME-Version: 1.0 References: <1685e719-738f-dd4e-c39c-c08e495b202e@arm.com> In-Reply-To: From: Damian Rouson Date: Thu, 19 Sep 2019 14:43:00 -0000 Message-ID: Subject: Re: Proposal for the transition timetable for the move to GIT To: Janne Blomqvist Cc: "Richard Earnshaw (lists)" , gcc mailing list Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00144.txt.bz2 On Thu, Sep 19, 2019 at 5:04 AM Janne Blomqvist wrote: > > One thing that's unclear to me is how should I actually make my stuff > appear in the public repo? Say I want to work on some particular > thing: > This is essentially a git workflow question. A simple and useful workflow to consider is the GitHub Flow: https://guides.github.com/introduction/flow/. Others to consider are on the GitLab Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html and on Atlassian's Git Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html. Where will the GCC git repository be hosted? > 1. git checkout -b pr1234-foo # A private branch based on latest trunk > 2. Then when I'm happy, I send out a patch for review, either manually > or with git format-patch + send-email. > Will GCC allow workflows other than emailing patches? It could make contributing more inviting to new developers. A large community of developers has grown up around the above workflows and are used to using the related tools. I realize emailing patches probably seems simple to GCC developers, but that practice is one of the main reasons I haven't contributed code to GCC even though I have supported GCC development financially and I frequently interact with GCC developers. My problems with email have been many. I have often forgotten to set my emails to plain text so my emails to GCC lists bounce and I have to resend them (often hours later if I didn't see the bounce right away). When I receive patches from GCC developers, I get frustrated with determining what -p argument to pass when applying the patch. I'm equally daunted with the process of searching through emails to find related discussions rather than having all the dialogue about a pull request (which contains the same information as a patch) in one place. And with plain-text emails as the medium, I really miss the ability to format dialogues with Markdown, including inserting hyperlinks but also to tie comments to specific lines of code in a browser interface to the pull request, etc. 3. Patch goes through a few revisions, and is approved. > 4. Now what? > 4a) Do I merge my private branch to master (err, trunk?), then commit and > push? > It's safer to first merge master into your branch and then retest with all the new commits that have hit master since you branched. If you test right after merging and find no problems (and no new commits hit master while you're testing), then the head of your branch will reflect the state master will reach when you merge into master so you know it's safe to do so. > 4b) Or do I first rebase my branch on top of the latest master, to > produce a slightly less branchy history? > A lot of people find rebasing to be overly complicated and error-prone (with the exception of interactive rebasing for the purpose of squashing commits that haven't been pushed to the remote repository). The above merging steps are easier at the expense of having merge commits in the history, which I think is good to better document the branching history. > 4c) Or do I (manually?) apply my patch on master, to create a linear > history? See above. I recommend "git merge" over manually applying patches. > 4d) Something else entirely? > A lot of the testing can be automated. For example, on GitHub, git hooks can be set up to ensure that if a branch has an open pull request against master (or other designated branches), tests run for that branch every time a new commit is pushed to it. Damian