| Message ID | 20200706083755.11778-1-ludo@gnu.org |
|---|---|
| Headers | show |
Hi Ludo, On Mon, 06 Jul 2020 at 10:37, Ludovic Courtès <ludo@gnu.org> wrote: > I put the “Invoking” node under “Development”, not sure if that’s > the best place. Also, I considered doing a ‘guix git’ command, > of which ‘authenticate’ would be one sub-command and maybe ‘clone’ > another one. But for ‘clone’ I thought that ‘guix download’ would > be a better fit. So I concluded that ‘guix git-authenticate’ was > a good choice in the end. On the topic of other subcommands, I have in mind log and tag. Currently, I have --8<---------------cut here---------------start------------->8--- export CKT=~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq export SRC=~/src/guix --8<---------------cut here---------------end--------------->8--- and I run "git -C $CKT" or "git -C $SRC", for example: git -C $SRC log | grep Update And I would like to be able to simply run; guix git log | grep Update And the same for tagging commits. Which implies also improve what "guix pull" and "guix time-machine" accept. All the best, simon
On Mon, 6 Jul 2020 at 14:46, Ludovic Courtès <ludo@gnu.org> wrote: > > git -C $SRC log | grep Update > > > > And I would like to be able to simply run; > > > > guix git log | grep Update > > Good point. Though hopefully this particular use case (finding new > package updates) is well served by ‘guix pull --news’, no? It is not for new package updates, but the contrary. :-) I use it for searching versions back in time. Which commit introduces which version. To be honest, I am almost never use "guix pull --news" because I am pulling once every full moon, and even when I do, I run an ugly script like: --8<---------------cut here---------------start------------->8--- #!/bin/bash # url-cache-directory from guix/git.scm # pjmkgl... = hash("https://git.savannah.gnu.org/git/guix.git") CACHE=~/.cache/guix/checkouts CHECKOUT=${CACHE}/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq printf "Updating local checkout:\n'$CHECKOUT'..." git -C $CHECKOUT pull -q echo " done." guix pull --commit=$(git -C $CHECKOUT \ log \ --before=$(date --date='2 weeks ago' +%Y-%m-%d) \ --format="%h" | head -n1) \ $@ --8<---------------cut here---------------end--------------->8--- because I do want the substitutes available. Well, for example, I run: "guix pull --news" and I get 15 new packages and 367 packages upgraded. > It’s not entirely clear to me what a ‘guix git log’ command would do in > fact: show the log for the ‘guix’ channel? For all channels (how?)? > For the specified channel? For what commit range? This is maybe out of the current bug report. I do not know if it is good to discuss here. Well, quickly we could imagine: guix git log # for guix channel guix git log --channel=name Then for the commit range, it could be the same UI as "git log". Since the commit messages are well-formatted, it is pretty easy to grep in. Moreover, "git worktree" could be added too. Well, the idea behind is to avoid clone+guix-environment+./pre-env-inst. > > And the same for tagging commits. Which implies also improve what "guix > > pull" and "guix time-machine" accept. > > Tagging commits is tricky because users only have a *cached* checkout. > So if we want persistent tags, we’ll have to develop a separate > mechanism. Could be useful, though perhaps redundant with the > (unimplemented) idea of tagging generation? Well, I do not want persistent tags. I am fine with local tags. I mean it is easy to tag my local repo with something meaningful for me and then lookup couple of weeks later. I do with "git -C $SRC" but I would like nicer to be able to run: guix git log | grep bazinga guix git tag foo guix time-machine --commit=foo -- > In the short term, we don’t need to solve all these problems: we can > also go for ‘git-authenticate’ and rename it once we have these other > commands. I have learnt that renaming will not work. :-) Because backward compatibilities and break the workflow of someone. So I would take the other route, go for "guix git authenticate" and hoping that other commands would come soon. Well, I do not know. It is just a suggestion reading your message. :-) Cheers, simon
Hi, zimoun <zimon.toutoune@gmail.com> skribis: > On Mon, 6 Jul 2020 at 14:46, Ludovic Courtès <ludo@gnu.org> wrote: > >> > git -C $SRC log | grep Update >> > >> > And I would like to be able to simply run; >> > >> > guix git log | grep Update >> >> Good point. Though hopefully this particular use case (finding new >> package updates) is well served by ‘guix pull --news’, no? > > It is not for new package updates, but the contrary. :-) > I use it for searching versions back in time. Which commit introduces > which version. > > To be honest, I am almost never use "guix pull --news" because I am > pulling once every full moon, and even when I do, I run an ugly script > like: > > #!/bin/bash > > # url-cache-directory from guix/git.scm > # pjmkgl... = hash("https://git.savannah.gnu.org/git/guix.git") > CACHE=~/.cache/guix/checkouts > CHECKOUT=${CACHE}/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq > > printf "Updating local checkout:\n'$CHECKOUT'..." > git -C $CHECKOUT pull -q > echo " done." > > guix pull --commit=$(git -C $CHECKOUT \ > log \ > --before=$(date --date='2 weeks ago' +%Y-%m-%d) \ > --format="%h" | head -n1) \ > $@ > > because I do want the substitutes available. Well, for example, I > run: "guix pull --news" and I get 15 new packages and 367 packages > upgraded. We’re drifting off-topic, but this is interesting. I just hope few people do that, but at least it’s a reminder of the sad situation wrt. substitute availability. I don’t understand why you wouldn’t run ‘guix pull --news’ though. It provides useful info beyond packages, doesn’t it? [...] >> In the short term, we don’t need to solve all these problems: we can >> also go for ‘git-authenticate’ and rename it once we have these other >> commands. > > I have learnt that renaming will not work. :-) > Because backward compatibilities and break the workflow of someone. > So I would take the other route, go for "guix git authenticate" and > hoping that other commands would come soon. Well, this particular renaming would be easy: it’s really just renaming, with a known name, a situation very different from that of ‘guix environment’ if that’s what you were alluding to. Thanks, Ludo’.
Hi, On Mon, 06 Jul 2020 at 21:48, Ludovic Courtès <ludo@gnu.org> wrote: > We’re drifting off-topic, but this is interesting. I just hope few > people do that, but at least it’s a reminder of the sad situation > wrt. substitute availability. I have started to do so during lockdown. I was in South of France (Millau \o/) only with my laptop which is not so much powerful. Well, on one hand it is the availability of package substitutes; but except some corner case and bad luck, in general* it is fine for me. On the other hand, I am really annoyed by building the derivations. But the new Guile compiler for derivation and other such optimizations could really improve the situation. :-) *general: well, it should not be possible to pull packages that do not build. It is rare but it happens and it is really frustrating: burn CPU and finally end with "build error". Anyway! Off-topic. > I don’t understand why you wouldn’t run ‘guix pull --news’ though. It > provides useful info beyond packages, doesn’t it? The command "guix pull --news" is useful. It provides useful information about packages, features, etc. But I read "--news" directly on guix-patches. :-) However, "guix pull --news" is not useful for what I want: find the commit backward in order to feed "guix time-machine --commit=". From my point of view, "--news" is useful forward. Other said, I delete the old generations I pulled e.g. 1 year ago so "--news" cannot work in this case. Anyway! Another off-topic. >>> In the short term, we don’t need to solve all these problems: we can >>> also go for ‘git-authenticate’ and rename it once we have these other >>> commands. >> >> I have learnt that renaming will not work. :-) >> Because backward compatibilities and break the workflow of someone. >> So I would take the other route, go for "guix git authenticate" and >> hoping that other commands would come soon. > > Well, this particular renaming would be easy: it’s really just renaming, > with a known name, a situation very different from that of ‘guix > environment’ if that’s what you were alluding to. Well, I do not think that particular renaming would be easy; as any other renaming: changing established things is hard. It is easy to add, not to remove. And from my point of view "guix git-authenticate" is not special enough to deserve a subcommand. But we all enjoy different taste of wine. :-) Anyway. Because we are drifting too much, let open another discussion and move forward this one. So, it was my bikeshedding feedback. :-) Cheers, simon
Hi Ludo, On Sat, 11 Jul 2020 at 13:01, Ludovic Courtès <ludo@gnu.org> wrote: > I pushed this after renaming the command to ‘guix git authenticate’ > after all: Cool! And this new subcommand opens room of new other subsubcommands. :-) Cheers, simon