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$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jrnieder@gmail$(echo .)com \
--cc=mhagger@alum$(echo .)mit.edu \
--cc=peff@peff$(echo .)net \
--cc=ronniesahlberg@gmail$(echo .)com \
--cc=sbeller@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox