From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Michael Haggerty <mhagger@alum.mit.edu>,
Stefan Beller <sbeller@google.com>,
Jonathan Nieder <jrnieder@gmail.com>,
Ronnie Sahlberg <ronniesahlberg@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 20/23] reflog_expire(): new function in the reference API
Date: Fri, 12 Dec 2014 10:57:15 -0800 [thread overview]
Message-ID: <xmqqwq5wbss4.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20141212085022.GA11891@peff.net> (Jeff King's message of "Fri, 12 Dec 2014 03:50:22 -0500")
Jeff King <peff@peff.net> writes:
>> > enum expire_reflog_flags {
>> > EXPIRE_REFLOGS_DRY_RUN = 1 << 0,
>> > EXPIRE_REFLOGS_UPDATE_REF = 1 << 1,
>> > EXPIRE_REFLOGS_VERBOSE = 1 << 2,
>> > EXPIRE_REFLOGS_REWRITE = 1 << 3
>> > }
>> >
>> > Do we have a preference in the coding style on this one?
>
> I think vertically aligned lists look really nice. But they often wreak
> havoc with diffs, because introducing one longer line means re-aligning
> the whole thing. IMHO, it's not worth it (but if you're going to do it,
> leave lots of extra room for expansion).
>
> Just my two cents, of course. I don't recall this particular style point
> coming up before.
>
>> Both styles are used in our codebase, and I don't think the style guide
>> says anything about it. My practice in such cases is:
>>
>> * If I'm modifying existing code, preserve the existing style (to avoid
>> unnecessary churn)
>> * If most of our code uses one style, then use that style
>> * If our code uses both styles frequently, just use whatever style looks
>> better to me
>
> I think that is a very good philosophy in general.
Thanks.
About the indentation on the second and subsequent lines of a
logical line that is split into multiple lines, we explicitly say
"Both ar valid, and we use both." Following the above three-bullet
list would be a good practice for this one, too.
next prev parent reply other threads:[~2014-12-12 18:57 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-04 23:08 [PATCH 00/23] Add reflog_expire() to the references API Michael Haggerty
2014-12-04 23:08 ` [PATCH 01/23] refs.c: make ref_transaction_create a wrapper for ref_transaction_update Michael Haggerty
2014-12-04 23:08 ` [PATCH 02/23] refs.c: make ref_transaction_delete " Michael Haggerty
2014-12-04 23:08 ` [PATCH 03/23] refs.c: add a function to append a reflog entry to a fd Michael Haggerty
2014-12-04 23:08 ` [PATCH 04/23] expire_reflog(): remove unused parameter Michael Haggerty
2014-12-04 23:20 ` Jonathan Nieder
2014-12-04 23:28 ` Jonathan Nieder
2014-12-05 12:43 ` Michael Haggerty
2014-12-04 23:08 ` [PATCH 05/23] expire_reflog(): rename "ref" parameter to "refname" Michael Haggerty
2014-12-04 23:44 ` Jonathan Nieder
2014-12-04 23:08 ` [PATCH 06/23] expire_reflog(): exit early if the reference has no reflog Michael Haggerty
2014-12-04 23:48 ` Jonathan Nieder
2014-12-04 23:53 ` Jonathan Nieder
2014-12-05 15:10 ` Michael Haggerty
2014-12-04 23:08 ` [PATCH 07/23] expire_reflog(): use a lock_file for rewriting the reflog file Michael Haggerty
2014-12-05 0:23 ` Jonathan Nieder
2014-12-05 2:19 ` Stefan Beller
2014-12-08 10:07 ` Michael Haggerty
2014-12-09 18:47 ` Junio C Hamano
2014-12-09 18:54 ` Jeff King
2014-12-05 19:18 ` Stefan Beller
2014-12-05 19:32 ` Junio C Hamano
2014-12-05 19:41 ` Stefan Beller
2014-12-05 20:55 ` Junio C Hamano
2014-12-08 14:05 ` Michael Haggerty
2014-12-05 2:59 ` ronnie sahlberg
2014-12-08 10:40 ` Michael Haggerty
[not found] ` <CAN05THTTba-1n12hBszJAU-O+wsbSFd5Lt+kMk7_MU_0C=wZGQ@mail.gmail.com>
2014-12-05 17:47 ` Stefan Beller
2014-12-04 23:08 ` [PATCH 08/23] Extract function should_expire_reflog_ent() Michael Haggerty
2014-12-08 22:33 ` Stefan Beller
2014-12-04 23:08 ` [PATCH 09/23] expire_reflog(): extract two policy-related functions Michael Haggerty
2014-12-05 19:02 ` Stefan Beller
2014-12-04 23:08 ` [PATCH 10/23] expire_reflog(): add a "flags" argument Michael Haggerty
2014-12-08 22:35 ` Stefan Beller
2014-12-04 23:08 ` [PATCH 11/23] expire_reflog(): move dry_run to flags argument Michael Haggerty
2014-12-08 22:38 ` Stefan Beller
2014-12-04 23:08 ` [PATCH 12/23] expire_reflog(): move updateref " Michael Haggerty
2014-12-08 22:42 ` Stefan Beller
2014-12-04 23:08 ` [PATCH 13/23] Rename expire_reflog_cb to expire_reflog_policy_cb Michael Haggerty
2014-12-08 22:46 ` Stefan Beller
2014-12-04 23:08 ` [PATCH 14/23] struct expire_reflog_cb: a new callback data type Michael Haggerty
2014-12-08 22:49 ` Stefan Beller
2014-12-04 23:08 ` [PATCH 15/23] expire_reflog(): pass flags through to expire_reflog_ent() Michael Haggerty
2014-12-08 22:55 ` Stefan Beller
2014-12-04 23:08 ` [PATCH 16/23] expire_reflog(): move verbose to flags argument Michael Haggerty
2014-12-08 22:56 ` Stefan Beller
2014-12-04 23:08 ` [PATCH 17/23] expire_reflog(): move rewrite " Michael Haggerty
2014-12-08 22:58 ` Stefan Beller
2014-12-04 23:08 ` [PATCH 18/23] Move newlog and last_kept_sha1 to "struct expire_reflog_cb" Michael Haggerty
2014-12-08 22:59 ` Stefan Beller
2014-12-04 23:08 ` [PATCH 19/23] expire_reflog(): treat the policy callback data as opaque Michael Haggerty
2014-12-08 23:12 ` Stefan Beller
2014-12-04 23:08 ` [PATCH 20/23] reflog_expire(): new function in the reference API Michael Haggerty
2014-12-08 23:32 ` Stefan Beller
2014-12-12 8:23 ` Michael Haggerty
2014-12-12 8:50 ` Jeff King
2014-12-12 18:57 ` Junio C Hamano [this message]
2014-12-04 23:08 ` [PATCH 21/23] refs.c: remove unlock_ref/close_ref/commit_ref from the refs api Michael Haggerty
2014-12-04 23:08 ` [PATCH 22/23] lock_any_ref_for_update(): inline function Michael Haggerty
2014-12-08 23:34 ` Stefan Beller
2014-12-11 0:13 ` Michael Haggerty
2014-12-04 23:08 ` [PATCH 23/23] refs.c: don't expose the internal struct ref_lock in the header file Michael Haggerty
2014-12-04 23:47 ` [PATCH 00/23] Add reflog_expire() to the references API Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqwq5wbss4.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=peff@peff.net \
--cc=ronniesahlberg@gmail.com \
--cc=sbeller@google.com \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.