From: Arun Isaac <arunisaac@systemreboot.net>
To: Tobias Geerinckx-Rice <me@tobias.gr>
Cc: 28020-done@debbugs.gnu.org
Subject: [bug#28020] [PATCH] gnu: Add emacs-gitpatch.
Date: Fri, 11 Aug 2017 12:18:39 +0530 [thread overview]
Message-ID: <adb92ed8.AEQAOWvIHGIAAAAAAAAAAAPejtMAAAACwQwAAAAAAAW9WABZjVNP@mailjet.com> (raw)
In-Reply-To: <b5dd4d41-060a-8a05-1812-67eb356bcaba@tobias.gr>
Tobias Geerinckx-Rice writes:
>> Also, having a staging branch to which all commits are made would help
>> keep the master branch clean, and free of these mishaps. But, I guess
>> this issue has been raised before, and the creation of such a staging
>> branch has been postponed.
>
> Interesting. Do you have a link? We do have a ‘staging’ branch, but it
> serves a different purpose (basically, ‘core-updates’, lite).
I was referring to this thread discussing the stability of master. It's
not about any staging branch like I proposed, but there are some
similarities.
https://lists.gnu.org/archive/html/guix-devel/2017-07/msg00021.html
> Since the commit message is already reviewed on the mailing list, such a
> branch would only catch the — one hopes — very rare last-minute foul-up
> by the committer themselves.
>
> ‘Someone’ would have to keep track of, review, and merge it. ‘People’
> would then start following that branch instead of master (Why let a typo
> keep me from the shiny?), making rebasing just as painful.
Agreed.
> I'm less opposed to an optional hook, but fear that it will discourage
> committers from making a habit of checking all their commits before that
> last and final push. Which they should definitely be doing.
Despite these concerns, I think it is still worth automating some commit
checks. Given long enough time, even the most careful person is likely
to mess up somewhere.
> (That's not a dig at you or anyone personally — you're talking to the
> reason for the /current/ pre-push hook, after all :-)
No issues! :-)
next prev parent reply other threads:[~2017-08-11 6:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-08 18:02 [bug#28020] [PATCH] gnu: Add emacs-gitpatch Oleg Pykhalov
2017-08-10 9:12 ` bug#28020: " Arun Isaac
2017-08-10 12:06 ` [bug#28020] " ng0
2017-08-10 16:26 ` Arun Isaac
2017-08-10 16:35 ` Tobias Geerinckx-Rice
2017-08-10 16:39 ` Arun Isaac
[not found] ` <a0b9df8d.AEEAOmPO1j4AAAAAAAAAAAPU2QkAAAACwQwAAAAAAAW9WABZjIlJ@mailjet.com>
2017-08-10 16:55 ` ng0
2017-08-10 17:31 ` Arun Isaac
[not found] ` <9b857f17.AEQAOV3jPRoAAAAAAAAAAAPU5Q8AAAACwQwAAAAAAAW9WABZjJhx@mailjet.com>
2017-08-11 0:25 ` Tobias Geerinckx-Rice
2017-08-11 6:48 ` Arun Isaac [this message]
[not found] ` <4c62b87d.AEQAOV3jPRsAAAAAAAAAAAPU2QkAAAACwQwAAAAAAAW9WABZjJhx@mailjet.com>
2017-08-11 6:56 ` ng0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=adb92ed8.AEQAOWvIHGIAAAAAAAAAAAPejtMAAAACwQwAAAAAAAW9WABZjVNP@mailjet.com \
--to=arunisaac@systemreboot.net \
--cc=28020-done@debbugs.gnu.org \
--cc=me@tobias.gr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).