pijul_org / pijul

#381 Document 'pijul tag'

Opened by raboof, on March 30, 2019
raboof commented on March 30, 2019

Let's add some documentation to 'pijul tag'

grahamc commented on March 30, 2019
13:19 <raboof> when I want to make/specify a 'release' of my project, I guess that would be a 'named collection of patches', would that also be a 'tag'?
13:20 <pemeunier> raboof: that would also be a tag, yes
13:22 <raboof> in git, a tag points to a commit hash, and in theory you can change the tag and point it to another commit hash
13:22 <pemeunier> tbh, we don't yet know how all the concepts are going to be used. We tried to implement "natural enough" concepts
13:22 <raboof> in pijul, do you have a similar 'thing the tag points to'? what would that look like?
13:22 <pemeunier> not quite
13:22 <pemeunier> or not exactly
13:23 <pemeunier> all patches have explicit dependencies (which are other patches)
13:23 <pemeunier> a tag is just a normal patch, with lots of dependencies (everything that was in the repository at the time of running `pijul tag`
13:23 <pemeunier> )
13:24 <pemeunier> transitive dependencies are removed from the set of dependencies
13:24 <pemeunier> one thing I'm not particularly happy with in Pijul, is that describing a version is not completely obvious
13:24 <raboof> right, so that set of dependencies would be the equivalent of the 'commit hash'
13:24 <pemeunier> a tag could work, but you can have multiple tags at the same time in a given state
13:25 <pemeunier> raboof: yes, sort of
13:25 <pemeunier> in Pijul, you can simulate Git's behaviour by recording all your patches with `pijul tag` instead of `pijul record`
13:25 <raboof> and since you cannot retroactively change the transitive dependencies that set uniquely identifies the release even if the tag ever changes
13:25 <pemeunier> then each patch would have one dependency: its parent
13:25 <pemeunier> raboof: it does, but you can "blend" tags
13:26 <pemeunier> you can record tag A and tag B, and then pull A and B at the same time in the same repository
13:26 <pemeunier> this amounts to computing the union of sets of patches A and B
13:26 <pemeunier> I personally find it confusing, and our choice of words is not often optimal (we're open to bikeshedding though)
13:27 <gchristensen> (this was all pretty complex stuff for me to follow at first)
13:28 <gchristensen> it may also be sensible to prohibit technically possible things (by default)
13:28 <raboof> but if you have pulled A and B and then tag C, can you still change A? and would that change affect C?
13:29 <raboof> (i'm not bikeshedding yet, just trying to understand in the first place :D )
13:29 <pemeunier> If tag C doesn't depend on A, you can unrecord A, and replace it with something else
13:29 <pemeunier> Else, i.e. if tag C depends on A, you can't
13:32 <pemeunier> raboof: patch dependencies are automatically generated, and you can add more if you want
13:32 <pemeunier> they account for very basic facts such as "you can't edit a file before creating that file"
13:32 <pemeunier> or "you can't change a paragraph that's not already there"
13:33 <pemeunier> in the future, we might have a language-aware diff algorithm that does a little more
raboof commented on March 30, 2019

I guess this belongs in the manual, https://nest.pijul.com/pijul_org/manual/discussions/11