This is a request to allow --depth=1 cloning of git repos. Some repos have a huge history (e.g. the linux kernel, mesa, etc), when some folks might want to just build the bleeding edge without having to fetch many MB of stuff that doesn't matter. This doesn't need to be the default behavior.
This should be fixed by https://git.sr.ht/~sircmpwn/aerc/commit/dd178262bb1d01f9f7d4710431547041bde52d89, but it may not be in a tagged release yet. Do you still have this issue with aerc built from git master?
This has now been implemented, but I cannot close this ticket.
What do you mean by 'unsupported' in this case? Message part(s) with no filter defined either by default and/or by the user, or something else?
Can you elaborate on what the updated UI should look like? Currently it seems that any parts can be :save'd (I haven't tried pipe).
Ah, ok that's a good idea. So the spec is:
1) -p for creating parent directories 2) if no -p and path contains directories that don't exist, show error 3) if path ends in / then create a file named after the attachment's filename, else file will be named after the last thing in the path
I think this should probably create parent directories in the given if they don't already exist (e.g. passing '~/patches/aerc/whatever' would create 'aerc' and save to file 'whatever'), but wanted to confirm that this is desirable by others before attempting to implement it.
This is a feature request to support triggering builds based on schedule. Ideally this interface would allow selecting trigger day/time, and recurrence (true/false), so that it would be possible to schedule a one-off trigger on, say, March 15th at 12:00pm GMT, or schedule builds to trigger on the first day of every month (or Sunday of every week).
One use case I had in mind is to trigger building mesa from its master branch every week to help folks (mesa developers, etc) 'dog food' it more easily. Triggering on commits to this branch would produce far too many builds to be useful.
I just noticed that if a tag contains a message, a valid link is created. If no message, then no valid link.
Some tags do not result in valid tarball links, where the tag is not part of the filename and the full filename ends up being '.tar.gz'.
For example, only one of the tags listed here has a valid tarball filename, the rest have filenames '.tar.gz' (that's the full filename, not just the extension):