unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Brice Waegeneire <brice@waegenei.re>
To: zimoun <zimon.toutoune@gmail.com>
Cc: Guix Devel <guix-devel@gnu.org>,
	Guix-devel <guix-devel-bounces+brice+lists=waegenei.re@gnu.org>
Subject: Re: best practise between git-fetch vs url-fetch?
Date: Wed, 13 May 2020 08:24:15 +0000	[thread overview]
Message-ID: <f6b5f65941bea2feaf99498127b3a92d@waegenei.re> (raw)
In-Reply-To: <CAJ3okZ0v3VvmT=eWAVeAQoFqZh4L3H4tUkEJn1-5EXcJgRB_tQ@mail.gmail.com>

Hello,

On 2020-05-13 01:08, zimoun wrote:
> Based on these 2 messages [1,2], what is the consensus between
> git-fetch and url-fetch?

I was hoping that some one bring this up, thanks.

> Pushing to SWH when linting appears to me winning the pros/cons.  Even
> if SWH should eventually fetch http://guix.gnu.org/sources.json soon.
> And the other big pros from my point of view is the content-addressed
> Git references.

Git references being content-addressed is important because it
make it more difficult for a lazy upstream developer to replace a
tarball in place -because it was somehow broken and they didn't
wanted to bump the version number- and broke a package.  Instead
with git, to broke a package in similar way (with a hash mismatch)
that developer would have to do “git push --force” which is much
more frowned upon since it will affect all the users of that git repo.

An other argument in recommending the 'git-fetch' method is that it
facilitate the use of “guix build --with-commit”:
1. You don't need to find out the git-url of the package,
2. Nor finding which dependencies are missing compared to a tarball
    build (often it's autoconf, libtool, & co.),
3. You don't need to manually tweak phases relating to autoconf and
    the like.
All in all recommending 'git-fetch' make “--with-commit” really more
useful.  This feature is one of my favorite from Guix since it make
testing a patch from an upstream developer really easy, eg.:
“guix build picom --with-commit=picom=vNext”.

> Well, does it make sense to state on a recommended method?

It does, it avoid having to discuss it with each new contributor
and avoid noise in patches about changing the source's method based
on each developer preference (I'm personally guilty of that).

> [1] https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00091.html
> On Fri, 6 Mar 2020 at 18:41, Marius Bakke <mbakke@fastmail.com> wrote:
> 
>> url-fetch requires less bandwidth, and does not depend on 'git'.
>> 
>> Though the most important distinction is that uploaded releases
>> sometimes contain pre-processed sources (e.g. documentation) that need
>> additional dependencies or scripts when building from the raw 
>> repository
>> (this is why you often need to add autoconf, libtool & friends as 
>> inputs
>> when building Autotools projects from git).
>> 
>> I don't know whether there is a difference between the uploaded fmt
>> zipball and the git repository.
> 
> 
> [2] https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00189.html
> On Wed, 11 Mar 2020 at 15:39, Ludovic Courtès <ludo@gnu.org> wrote:
> 
>> Other considerations:
>> 
>>   - Bandwidth requirement for source code downloads has never been a
>>     criterion so far.
>> 
>>   - Git references are nice because they’re (roughly) 
>> content-addressed.
>> 
>>   - ‘guix lint -c archival’ archives Git references on Software
>>     Heritage; it does not archive tarballs (though SWH will do it
>>     for us eventually.)

Cheers,
- Brice


  reply	other threads:[~2020-05-13  8:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200306091524.5044.11103@vcs0.savannah.gnu.org>
     [not found] ` <20200306091525.E8A1621163@vcs0.savannah.gnu.org>
2020-03-06 14:37   ` 01/02: gnu: fmt: Use HTTPS and git-fetch Marius Bakke
2020-03-06 15:07     ` Pierre Neidhardt
2020-03-06 17:40       ` Marius Bakke
2020-03-07  7:46         ` Pierre Neidhardt
2020-03-07 11:37           ` Pierre Neidhardt
2020-03-11 14:39         ` Ludovic Courtès
2020-03-11 14:54           ` Pierre Neidhardt
2020-05-13  1:08             ` best practise between git-fetch vs url-fetch? zimoun
2020-05-13  8:24               ` Brice Waegeneire [this message]
2020-05-13 18:07                 ` Tobias Geerinckx-Rice
2020-05-14 16:16                   ` Jack Hill
2020-05-24 20:04                     ` Josh Marshall
2020-05-24 20:30                     ` Ludovic Courtès
2020-05-25  4:54                       ` Jack Hill
2020-05-25 21:17                         ` Ludovic Courtès
2020-05-26  2:05                           ` Jack Hill
2020-05-13 17:13               ` Leo Famulari
2020-05-24 20:34                 ` Ludovic Courtès
2020-05-26 11:41               ` zimoun

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=f6b5f65941bea2feaf99498127b3a92d@waegenei.re \
    --to=brice@waegenei.re \
    --cc=guix-devel-bounces+brice+lists=waegenei.re@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=zimon.toutoune@gmail.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.
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).