As I mentioned here and there (including on IRC), I am in favor of monthly release of pijul, until we hit pijul-1.0, with regular release candidates (ideally one per week) and call to test the angry bird.
Also, I am committed to write better ChangeLog. So, here is the pending ChangeLog for pijul-0.11.0.
pijul-0.11.0 (unreleased)
Enhancement
Mimic the behaviour of darcs show dependencies by splitting the patch name
into several names and by using a left-to-right layout with dot (was
top-to-bottom before) (rc1, @lthms).
Give to pijul rollback a proper CLI, very similar to what pijul record and pijul tag already allow (rc1, @lthms).
There is now an help notice for patches selection, using ? (rc1, @FlorentBecker, @lthms)
Improve the patch summary presentation (rc1, @lthms)
You can now override the global pijul configuration directory, which is ~/.pijulconfig by default (rc1, @yory)
pijul status prints the current branch in addition to pending changes and
conflicts (rc1, @laumann)
pijul fork gets a new option --tag to create a new branch with the minimal set
of dependencies for a given tag (rc2, @lthms)
<C-k> when writing a patch name will now erase what is after the cursor
(rc2, @pmeunier)
It is now possible to jump from one word to another with <C-←> and <C-→>
(rc2, @pmeunier)
pijul dist removes the archive in case of failure (rc2, @lthms)
pijul dist now offers a new --stdout option to print the resulting archive
to the standard output (rc2, @lthms)
Pijul now supports partial clones, meaning you can select a path within your
repository, and only the patches required to output the content of this path
will be pulled (rc2, @pmeunier)
Bugfixes
pijul was using a pager, even if the NOPAGER environment variable was set
(rc1, @lthms)
pijul was not using a pager for the log command (rc1, @lthms)
While selecting changes to record, the d option (done, that is skipping the
remaining changes) was behaved incorrectly with -n option (rc2, @pmeunier)
pijul checkout could fail sometimes because of Sanakirja specificity (rc2, @lthms)
pijul pull and push were failing when used to target another branch than
the current one, both locally and remotely (rc2, @lthms)
Okay, so I have tagged a 0.11-rc1 version which won’t be published to crates.io due to a bug in cargo. I have created a new branch called testing, so you can just use it since forking from a patch is not yet completely ready.
This means there is now three branches in pijul upstream:
master, which contains the accepted changes
latest which reflects the latest published version on crates.io
testing which will be updated once a week with a release candidate version to test.
Beware that, it is not because a patch finds its way to master that it will be added to testing at the end of the week. The main idea is that latest and testing should not have too big issues, whereas master may be broken from time to time (but of course, we want to avoid that also).
Happy testing, and thanks by advance for your time and reports (if any). Released notes have been updated accordingly :).
I gave it a test, seems all good, just a small issue: when using ? in the record dialog, it repeats the commit message. I think there’s no need for that, actually it’s kinda confusing.
added file new_file.txt
Shall I record this change? (1/6) [ynkadi?] ?
added file new_file.txt
Available options:
Also: there’s a typo in d: skip all rema I ning changes.
And a bug: say that I add 3 files. When recording, on the first file I type d. I expect it to stop. Instead it continues with the other files, as if I typed n.
Also, for the sake of exposure, I repost here a comment I made on one discussion of the Nest:
I had to merge my changes with your partial checkout patch. I have pushed everything to the branch master, so don’t forget to pull them before pushing again, in order to prevent conflicts on pijul upstream.
I think I will tag pijul-0.11-rc2 with “forking from a patch” this week-end, then a pijul-0.11-rc3 with “partial checkout” the week after (or whenever it’s ready, really).
After this third RC, and once stabilized, I think we will have everything we need to release pijul-0.11.0!
I have updated the first post with a preview of what pijul-0.11-rc2 will probably be. I plan to tag it and push it to testing as soon as line-0.1.5 is officially released on crates.io.
Ok, thanks for the clarifications. I have ideas to fix the space problem in Sanakirja, by allocating the file in chunks. The default size of a chunk is non-trivial to set.
The main blocker now is, I don’t know how OSX and Windows behave when mmap’ing a larger size than the file.
They work fine between repositories that support them, which is not the case of the Nest. The repository format changed a little bit, but just opening a mutable transaction is enough to convert old repositories to the new format.
I cannot make it works locally, with a pijul freshly built with your patches.
mkdir test
cd test
pijul init
mkdir a b
echo test > a/test
echo foo > b/foo
pijul record -n -a -m "patch"
cd ..
pijul clone test test-partial --path a/
ls test-partial
Output is a b rather than test, which I was expected.
The expected here is just a: a partial clone will have the same hierarchy, but it will neither:
apply the patches that relate exclusively to other parts of the repository.
nor output these other parts (if they are created from a patch that touches both a and other parts).
There is a test case in the repository, called partial.bats, which passed last time I checked. Could you try to create a new test from that one, and modify it to make it fail?
Sometimes, the smaller patches have the biggest impacts :D.
Edit: I have been able to make it works! But I need to clone the project once first, then reclone the new project with --path.
Congrats! This is an awesome new features! I wish we will be able to have a word about partial clones in practice, now that the theory is correctly implemented.
I will tag a rc2 today, with the complete changes inside master, for folks to test.
There is one known bug to be fixed before the release, plus something related to Windows and OpenSSH I haven’t had the time to dive into. That is without counting on all the bugs testers will found :D.
Will update the ChangeLog notes of this post, too.
Ok, latest stable pijul, from fresh clone of master:
~/.cargo/bin/pijul pull https://nest.pijul.com/pijul_org/pijul --from-branch testing --to-branch=testing
Pulling patches: 100% (111/111), done.
Hash: 9tNKV1UL5cYbw3gpDScSfoZSRthQ3a6KHHKMQTjA1CyCumqrVcXey6t37qJMHURpZQwZt1UsKoj3bhNPfevwdhTK
Authors: ["Pierre-Étienne Meunier <pe@pijul.org>"]
Timestamp: 2018-02-27 14:44:24.130178136 UTC
Init
Shall I pull this patch? [ynkad] a
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /build/rust/src/rustc-1.25.0-src/src/liballoc/vec.rs:1551:10
note: Run with `RUST_BACKTRACE=1` for a backtrace.
export RUST_BACKTRACE=1 && ~/.cargo/bin/pijul pull https://nest.pijul.com/pijul_org/pijul --from-branch testing --to-branch=testing
Pulling patches: 100% (111/111), done.
Hash: 9tNKV1UL5cYbw3gpDScSfoZSRthQ3a6KHHKMQTjA1CyCumqrVcXey6t37qJMHURpZQwZt1UsKoj3bhNPfevwdhTK
Authors: ["Pierre-Étienne Meunier <pe@pijul.org>"]
Timestamp: 2018-02-27 14:44:24.130178136 UTC
Init
Shall I pull this patch? [ynkad] a
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /build/rust/src/rustc-1.25.0-src/src/liballoc/vec.rs:1551:10
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::_print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::begin_panic
6: std::panicking::begin_panic_fmt
7: rust_begin_unwind
8: core::panicking::panic_fmt
9: core::panicking::panic_bounds_check
10: libpijul::optimal_diff::add::<impl libpijul::backend::GenericTxn<A, R>>::add_lines
11: libpijul::optimal_diff::<impl libpijul::backend::GenericTxn<A, R>>::diff
12: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::diff_with_binary
13: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_inode
14: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_children
15: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, T>>::record
16: libpijul::apply::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, T>>::apply_patches
17: libpijul::apply_resize
18: pijul::commands::remote::Session::pull
19: pijul::commands::pull::run
20: pijul::main
21: std::rt::lang_start::{{closure}}
22: std::panicking::try::do_call
23: __rust_maybe_catch_panic
24: std::rt::lang_start_internal
25: main
26: __libc_start_main
27: _start