unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: Eric Brown <ecbrown@ericcbrown.com>, 40764-done@debbugs.gnu.org
Subject: [bug#40764] New package: r-restrserve
Date: Thu, 10 Dec 2020 15:25:30 +0100	[thread overview]
Message-ID: <86sg8dhh5x.fsf@gmail.com> (raw)
In-Reply-To: <87pn3hlrz0.fsf@elephly.net>

Hi Ricardo,

On Thu, 10 Dec 2020 at 14:18, Ricardo Wurmus <rekado@elephly.net> wrote:
>> On Wed, 09 Dec 2020 at 19:36, Christopher Baines <mail@cbaines.net> wrote:
>>
>>> In the future, I'd strongly recommend not adding packages to the bottom
>>> of modules, unless you really want the package definition to be
>>> there. If every new definition gets added at the bottom, merge conflicts
>>> become very likely. Related to this, I also moved the package definition
>>> up off the bottom of the module.
>>
>> What do you mean?  From my understanding, we always add new R packages
>> at the botton of the files cran.scm or bioconductor.scm; mainly.
>
> The problem is 100% with tooling.  Git needs some context to apply
> patches.  When you add package definitions to the bottom and that bottom
> context keeps changing you will always need to tell Git how to apply that
> patch.

[...]

> It would be *great* if we could find another way to appease git and do
> the right thing for the most common case of simply adding a package
> definition to the bottom of the file, no matter what context there might
> be right above.

The option “format-patch --base” reduces the burden and I proposed this
patch:

   <http://issues.guix.gnu.org/issue/43946>

Adding directly in the patch the (base) commit where the patch is known
to apply fixes most of the issues.  IMO.


All the best,
simon





  parent reply	other threads:[~2020-12-10 14:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22 11:12 [bug#40764] New package: r-restrserve Eric Brown
2020-05-30 17:56 ` Marius Bakke
2020-12-09 19:36 ` bug#40764: " Christopher Baines
2020-12-10 12:36   ` [bug#40764] " zimoun
2020-12-10 13:18     ` Ricardo Wurmus
2020-12-10 14:22       ` Efraim Flashner
2020-12-10 14:25       ` zimoun [this message]
2020-12-14  9:54         ` Oleg Pykhalov
2020-12-15 14:35           ` zimoun
2021-05-26 22:33 ` [bug#48690] " Eric Brown

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=86sg8dhh5x.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=40764-done@debbugs.gnu.org \
    --cc=ecbrown@ericcbrown.com \
    --cc=rekado@elephly.net \
    /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).