This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Git ChangeLog policy for GCC Testsuite inquiry


On Fri, 7 Feb 2020 at 09:20, Richard Biener <richard.guenther@gmail.com> wrote:
>
> On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > Instead of "git am" I had "patch -p1 <", distributing the changelog parts
> > I just did in vi (as with git), then "svn ci", which pick up all modified
> > files directly (sometimes an "svn add" first).  It's pretty much the same
> > for me.
>
> I'm a believer on committing from the tree I actually tested, so it

With Git you can't really have unwanted local commits present in a
tree if you use a sensible workflow, so if you tested in a tree that
was at commit 1234abcd and you push from another machine that is at
the same commit, you know there are no unintended differences.

> was with SVN: patch, test, svn up, edit changelogs (cut&paste from the
> patch header), svn diff | less (check wha'ts abotu to be committed), svn commit
> with GIT its now: patch, test, git add/commit,

There is no good reason to delay add+commit until after testing.

Committing locally is a completely different operation from committing
to svn, because nothing is "final" until you push to gcc.gnu.org. I
commit locally, and then either test locally or push to larger
machines where I test, or test in both places at once. Even if you
only work on one machine, keeping uncommitted changes around is error
prone (it's easier to lose the work, it's easier to not realise
exactly what you're testing, it's harder to verify that what you
tested is what you eventually pushed).

Applying somebody else's patch to test it can be done in a local
branch and committed locally. You can always delete that branch later
to clear up (a naming convention like "patch-20200207-foo-bar" helps
to keep those branches clearly labelled so you can easily decide which
to remove later).

Once you've committed something it has a commit hash to identify it,
so you can easily compare the state at that revision to some other
revision, at any later time.

tl;dr make more use of branches.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]