On Fri, 7 Feb 2020 at 09:20, Richard Biener <richard.guent...@gmail.com> wrote: > > On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool > <seg...@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.
