From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20593 invoked by alias); 6 Sep 2013 09:36:16 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 20582 invoked by uid 89); 6 Sep 2013 09:36:15 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Sep 2013 09:36:15 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r869aCVE009133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Sep 2013 05:36:12 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r869aAUD023331; Fri, 6 Sep 2013 05:36:11 -0400 Message-ID: <5229A20A.5060302@redhat.com> Date: Fri, 06 Sep 2013 09:36:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sourceware.org Subject: Re: [COMMIT] Re: [PATCH 0/9][gdbserver] Split server.h. References: <1378239999-15533-1-git-send-email-palves@redhat.com> <5228EDE4.7080101@redhat.com> <5229043A.1000408@redhat.com> <83wqmumrhq.fsf@gnu.org> In-Reply-To: <83wqmumrhq.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-09/txt/msg00215.txt.bz2 On 09/06/2013 06:46 AM, Eli Zaretskii wrote: >> Date: Thu, 05 Sep 2013 23:22:50 +0100 >> From: Pedro Alves >> >> Gah, and completely forgot to 'cvs add' all the new >> headers, so the gdbserver build is broken now for >> everyone. :-/ Now fixed... >> >> /me longs for 'git push'. > > Git doesn't save you from having to "git add" new files, does it? No. But when you use git for all the development work (excluding the final commit), there's no way to forget it. git shows the new files in the diff, and if you forget to add the file, it won't appear in the submitted patch, for example. This is a fault in my workflow, of course. The issue is when moving the patch from git/patch to cvs, for final commit. I always do: $ cvs diff > leftovers.diff $ less leftovers.diff before and after committing a patch. cvs diff by default doesn't show you new files - instead it says: cvs diff: dll.h is a new entry, no comparison available Even before using git/stgit for development, I was using quilt on top of cvs to manage my patches/series. I still use that, particularly when moving patches from git -> cvs. I do $ stg export -d patches in my stg/git checkout, and that puts a quilt-ready patch series in the patches directory. I then have a separate gdb cvs checkout that I only use for commits, that has src/patches symlinked to the git checkout's src/patches. So to push a series, I just go to the cvs checkout dir (I always have a terminal open for that alone), and manually do: for each patch in series; do quilt push quilt diff move ChangeLog text from patch header to ChangeLog file cvs diff cvs ci done quilt diff does show new files in the diff (diffed against /dev/null), yet another thing conspiring for me missing cvs add. For some I-can't-justify reason, I've trained my brain to not expect to see new files in the "cvs diff" step. That "is a new entry, no comparison available" warning goes to stderr, but I failed to notice in the first patch. And then as I pushed the series in sequence, I skipped that 'cvs diff' step in between committing patches, so I ended up forgetting to add all new files... The simple fix for me without learning a whole new workflow seems to be to just use cvs diff -N. My ~/.cvsrc now has: diff -upN train myself to expect to see the new files in the resulting diff, and perhaps write a little wrapper script around cvs diff that warns me if there are non-added files in the resulting diff (the ? lines), unless there's already something like that in the set of cvs commands (cvs status seems to be practically useless, I never use it). Hopefully that'll help catch this mistake going forward. (BTW, I also long for git push for being able to push a series of patches with a single command) -- Pedro Alves