Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2015-09-18

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:37 mizu_no_oto joined #darcs
10:06 kowey joined #darcs
10:06 Heffalump hello from the sprint!
10:08 kowey hello!
10:09 psnively joined #darcs
10:10 psnively left #darcs
10:10 gh_ joined #darcs
10:10 gh_ hi!
10:31 gh_ it's sprint time! darcs hackers rejoice!
10:31 kowey http://darcs.net/Internals/PendingPatch <-- last updated 2012
10:44 gh_ I'm claiming http://bugs.darcs.net/issue2436 for this weekend
10:55 kowey numpy have some nice acronyms for commit messages
10:55 kowey I like MAINT, ENH, FIX, UI as prefixes
10:55 kowey http://docs.scipy.org/doc/numpy/dev​/gitwash/development_workflow.html
10:58 mizu_no_oto joined #darcs
11:07 thomie_ joined #darcs
11:23 Heffalump updated the notes on stash a bit here: http://darcs.net/Ideas/Stash
11:36 gal_bolle joined #darcs
11:46 gh_ hi gal_bolle !
11:46 thomie_ joined #darcs
11:47 gal_bolle hi
11:47 gal_bolle i think I'll be with you guys sunday
11:47 gal_bolle but it's been a long time since i last touched darcs' code
11:47 gh_ \o/
11:47 gh_ awesome
11:48 peb` joined #darcs
11:51 thomie_ joined #darcs
11:59 thomie_ joined #darcs
13:15 gh_ joined #darcs
13:28 Heffalump I've updated the notes on http://bugs.darcs.net/issue2445 to record what I've done so far
13:36 sm hello sprinters! \o/
13:50 gh_ hi sm !
13:50 gh_ https://launchpad.net/~hvr/+archive/ubuntu/ghc ← this is great
14:00 thomie_ joined #darcs
14:01 thomie_ https://ghc.haskell.org/tra​c/ghc/ticket/9943#comment:7
14:02 thomie_ https://ghc.haskell.org/trac/ghc/ticket/5273
14:07 notdan on my way to paris
14:07 notdan the wireless internet on this train is terribl tho
14:09 notdan pointfree: the feed feature sounds very cool
14:16 notdan pointfree: re: cloning an arbitrary set of patches -- that was just an idea. I think Heffalump was thinking about implemnting it in darcs directly
14:17 gh_ notdan, pointfree +1 for the feed feature. I know other people that are interested in that.
14:38 Heffalump notdan: I did implement "stash" in darcs directly, but I don't know what the high-level things around that could/should be
15:44 Heffalump kowey has pointed out that "shelf" is the right name for stash, so I will probably rename it to that quite soon
16:32 thomie_ https://ghc.haskell.org/trac/ghc/ticket/10653
16:32 kowey joined #darcs
16:42 sm shelf/shelve++
16:43 sm I guess.. is there some precendent for that ? I know jetbrains ides use it
16:43 sm I'm trying to think what is a similar operation in other VCS's
16:43 pointfree "shelve" To decide not to proceed with (a project or plan), either temporarily or permanently.
16:44 sm what about simply "hide" ?
16:44 pointfree "stow" to put away for future use.
16:47 sm "suspend" also seems not bad. Already used in darcs rebase, and seemingly for much the same kind of operation ?
16:48 sm will the new feature overlap or merge with rebase somehow ?
16:51 kowey one reason shelve/shelf may be attractive, is that other VCSes [perforce] use it for the same sort of thing
16:51 kowey http://www.perforce.com/perforce/r​15.1/manuals/cmdref/p4_shelve.html
16:51 kowey http://doc.bazaar.canonical.com/beta​/en/user-reference/shelve-help.html
16:52 kowey https://mercurial.selenic.com/wiki/ShelveExtension <-- but this sounds like a git stash-a-like
16:52 sm kowey: ah, nice
16:54 kowey not clear what bzr means by shelve though
17:13 pointfree sm, Wouldn't the new feature do the opposite of a "darcs hide REGEXP" it would show only the patches described by REGEXP or "P#hashtag" and their dependencies, hiding the rest.
17:14 sm pointfree: not sure, I might have misunderstood Heffalump's description here
17:15 Heffalump actually, in p4 shelve only applies to uncommitted changes too, so perhaps it isn't such a great name
17:16 pointfree ...same with "stow" "shelve" and "stash" they're not doing that to REGEXP or P#hashtag, they're doing it to everything else.
17:16 Heffalump (I misremembered/misinformed kowey when I said perforce did use "shelf" for this concept)
17:16 Heffalump sm: probably in the long-term. Not quite sure how yet.
17:16 Heffalump sm: (re overlapping with stash/rebase)
17:17 kowey oh, so perforce, hg, and bzr all seem to be using 'shelve' to mean the same thing as git 'stash'?
17:17 Heffalump dunno about hg, but it's looking that way..
17:17 sm perhaps having both "darcs suspend" and "darcs rebase suspend" is ok ?
17:18 Heffalump I'm somewhat hoping for a supercommand to contain this in because then things like "darcs stash pull" and "darcs stash obliterate" also might make sense
17:18 Heffalump but there's definitely a strong case against the supercommand
17:18 Heffalump and then "darcs suspend" and "darcs unsuspend" make sense
17:18 kowey supercommand might make for symmetry
17:18 sm yeah, we don't want to become git
17:18 Heffalump (other commands we might need: "darcs stash log")
17:19 kowey in that there's already a darcs rebase {pull, apply} vs darcs _ {pull, apply}
17:19 kowey establishing idea that there's analogy
17:20 Heffalump I guess the question is should there be an analogy
17:20 Heffalump there certainly is in the current implementation, but is that the right UI
17:20 sm one of the reasons to still use darcs is it's (relative) simplicity, we should try hard not to lose that
17:21 pointfree "darcs isolate P#my-feature" isolate: to set apart from others.
17:21 kowey we're giggling here because I keep saying "git" when I mean "darcs"
17:21 Heffalump but then does "darcs isolate unsuspend" sound sensible?
17:21 sm no :)
17:22 Heffalump I think the name of a supercommand has to be a noun or a verb that implies the entire suspend-blah-unsuspend workflow, not just the first part of it
17:22 Heffalump and the lack of such a name is one reason to not have a supercommand :-)
17:22 pointfree Yeah, "isolate" doesn't work as a supercommand.
17:22 kowey http://darcs.net/Using/Rebase
17:23 kowey hmm, should move more of that stuff to the the Using/ seciton
17:24 kowey so, darcs rebase has left bracket: pull, apply, suspend (any of these starts the workflow)
17:24 Heffalump btw, one strong reason for rebase to be a supercommand is that in a mythical future world where darcs does everything we'd like, rebase shouldn't actually exist
17:24 kowey and you can interleave your regular darcs business with other bits of the rebase workflow
17:25 kowey and finally N darcs rebase unsuspend to form the right bracket
17:25 sm it seems like it would be nice to have some analogy to "git checkout X" where X is a simple name of what you want, typically a tag or this repo as of a certain date
17:25 Heffalump whereas I think "stash" is something we might theoretically want forever
17:25 kowey one difficulty with the git UI is managing names of remotes vs branches
17:26 kowey an apparent inconsistency in that, something worth thinking hard about if we do branches
17:26 sm darcs checkout -t v0.1, darcs checkout --to-date yyyymmdd, ...
17:26 Heffalump sm: yes, it'd be really nice if we could have all our release tags in one repo
17:27 sm yes, you're right
17:27 Heffalump and suspended patches open up that possibility (not in practice yet)
17:27 Heffalump but it's a strong argument that "stash"ed patches aren't really special and don't belong in a supercommand
17:28 kowey also worth considering revert/unrevert maybe
17:28 Heffalump yes, we also do want a "git stash" analogue - need to manage unrecorded changes somewhere
17:29 codolio (un)revert already exists, though. Unless you're suggesting just adding the functionality to those.
17:29 codolio I could see that.
17:29 kowey interesting that git stash is good because git is bad at dealing with working dir
17:30 kowey but yeah, like rebase, it's not that darcs doesn't need it, just that the space where we would need it is vastly smaller
17:30 Heffalump codolio: unrevert has the problem that the unrevert state isn't very stable, you can lose it a bit randomly
17:30 Heffalump and I'm not sure darcs always warns you when you will lose it, even if it does so sometimes
17:31 Heffalump also you can't have multiple unrevert states
17:31 codolio Yeah, I guess it's probably not good to mix them.
17:31 sm I guess this is about decomplecting: what's recorded in the repo, what's exposed as the working copy, and unrecorded changes in the working copy
17:32 codolio I was thinking 'revert' could be like checkout. Instead of modifying the working directory to discard changes, it would modify it to an arbitrary tag/selection of patches/whatever.
17:32 codolio revert is 'update -C' in mercurial, for instance.
17:32 codolio And update is like checkout.
17:32 kowey not to make the conversation even more confusing, but this afternoon, we talked a bit about the idea that all this: rebase, stashelve, revert/unrevert, etc are variants of multiheaded darcs
17:33 kowey (and local branching too)
17:33 kowey but Heffalump wisely decided to make actual progress turning rebase into reality
17:34 kowey as opposed to us spinning around indefinitely trying to figure out the grand unified branching thing
17:40 kowey oh another reason not to use "shelve"
17:40 kowey git uses it for its two-stage commit process
17:40 sm "darcs [un]checkout PATCH" could be a bit like darcs rebase [un]suspend. It could have some options controlling how it handles patch dependencies
17:42 Heffalump checkout has too many analogies with VCSes that require you to explicitly say "I want to edit this file" for me
17:42 kowey I find git overloading to be maddening
17:42 Heffalump or with VCSes that use it for remote operations
17:42 kowey git checkout my-file.hs and git checkout my-branch shouldn't be the same command
17:42 sm that's unfortunate. I'm thinking of it in the git sense
17:42 kowey oh wait
17:43 sm I think assuming familiarity with git usage is not a bad default
17:43 kowey this overloading is why I suspect git is so superficially hostile
17:43 kowey you never know if you should do git pull upstream/blah
17:43 kowey upstream blah
17:43 kowey upstream:blah blah
17:44 kowey (although I'm confusing the discussion w/ the fact that introducing a remote vs branch concepts opens up this can of worms)
17:49 sm if not checkout, what's another word for "manifest some history in the working copy" ?
17:49 codolio hg uses update, but I don't think that's a great name, either.
17:49 kowey maybe something with apply
17:50 kowey so darcs rebase foo args means something like "do darcs foo args and along the way whatever nastiness you need to my stuff to make it fit on top of args"
17:51 Heffalump sm: if we are using top-level commands, isn't "darcs suspend" and "darcs unsuspend" ok?
17:51 sm kowey: couldn't it be a flag then ?
17:51 kowey in the case of darcs rebase {pull, apply} anyway
17:51 Heffalump yes, maybe rebase should be a flag
17:51 kowey but then the suspend, unsuspend bits of the workflow?
17:52 sm Heffalump: maybe, it's just not familiar to any other VCS user. There could be aliases
17:52 sm I think I like the idea of darcs [un]checkout TAG|DATE|PATCHES [--no-dependencies] [--rebase] or something
17:52 Riastradh joined #darcs
17:54 sm to switch your repo to a different release, "darcs unsuspend -t v0.1" seems less obvious
17:54 Heffalump I see, yes, perhaps that's a higher-level thing than suspend/unsuspend
17:55 Heffalump darcs checkout has to both suspend and unsuspend things
17:55 Heffalump or does it not?
17:55 codolio It could.
17:55 codolio Tags aren't totally ordered.
17:56 codolio Nor are arbitrary selections of patches.
17:56 sm probably darcs checkout TAG|DATE does unsuspend things by default, for simple behaviour. darcs [un]checkout PATCH.... is for fine-tuning
17:56 Heffalump that depends on if checking out a tag is supposed to leave us exactly at that tag state, or in a superset of that tag state
17:57 sm taking you to exactly that tag state should be the default, for sure
17:57 Heffalump it doesn't feel completely obvious to me, but I need to ponder more
17:58 sm have you used git much Heffalump ?
17:58 Heffalump sadly or happily no
17:58 kowey it's now 02:00 Singapore time
17:58 sm I think I have used it more. So my mind has of course been corrupted :)
17:58 Heffalump indeed :-)
17:58 Heffalump if there's a conflict between sanity and git compatibility then we have to decide
17:58 Heffalump in an ideal world we'd manage both :-)
17:59 kowey I hope to see us keep the darcs tradition of trying to have a UI that fits together nicely
18:00 kowey using git style names is by itself fine
18:00 codolio Same here.
18:00 sm I've also used svn, cvs, rcs, hg, veracity, arch, fossil. But git and darcs have pretty muched wiped out the rest for me
18:00 kowey but would be sad for us to see us sacrificing a sort of coherence for that sake
18:00 Heffalump I've used svn and cvs in the past and I use p4 actively now
18:00 kowey actively using git and have had my brain rotten by its corrupting influence
18:01 kowey it's actually not so bad
18:01 codolio For instance, git names things based on how they're implemented, as I understand.
18:01 codolio Which is why checkout is both for branches and for files.
18:01 codolio It's the same code with different options, so that's how they exposed it in the interface.
18:01 kowey I'll note that one place the "overloading" I complained about works nicely
18:02 kowey in git is when they really do refer to the same sort of thing
18:02 kowey like when you can refer to hashes and branch names
18:02 kowey in the same commands, when git merge 2880c93 does the same thing as git merge blop
18:02 sm the meaning of git's basic commands are or will be known to everyone for the next decade I expect
18:03 Heffalump kowey: that's ok cos they are the same "kind"
18:03 kowey *nod*
18:03 codolio Right. The point is to name things the same or differently based on concepts.
18:04 codolio Not on how they happen to be implemented.
18:04 kowey another thing I find awful
18:04 kowey git add means both "stage these things"
18:05 kowey and "mark these things as resolved"
18:05 codolio Also, 'start tracking these files'.
18:05 kowey yes
18:06 kowey so I think I was a bit confused when I said that git uses "shelf" for its two stage thing (I think I'm thinking of staging)
18:06 * kowey is always a bit confused
18:07 kowey ok so back to suspend/unsuspend
18:16 Heffalump if checkout needs to both suspend and unsuspend, I'm thinking of having the "primitive" commands and a higher-level command on top
18:42 sm don't let me distract, writing this out helps me think:
18:42 sm darcs checkout TAG|DATE # resets the working copy to the specified point in this repo's history.
18:42 sm darcs checkout PATCH    # applies the specified patch from history, and any other patches it depends on, to the working copy, if not already applied.
18:42 sm darcs uncheckout PATCH  # unapplies the effect of the specified patch, and any other currently checked-out patches depending on it, from the working copy.
18:42 sm
18:43 sm I see that "reset"/"apply"/"unapply" are another possibility
18:44 sm or even "revert"
18:45 sm as codolio said
18:48 Heffalump I'm reluctant to conflate the ideas of moving to a different state and adding and subtracting from the current state with each other
18:48 Heffalump darcs checkout TAG would always get you the same result
18:49 Heffalump darcs checkout PATCH would depend on your current state
18:49 Heffalump further complicated by the implementation detail in darcs that tags are actually patches
18:49 sm yes
18:50 sm maybe checkout always sets the exact state, and checkout --add/--remove modifies it
18:50 Heffalump I'm reluctant about "apply" because we already have an "apply" command that is rather so even if it's the right long-term answer it would be a difficult migration
18:50 Heffalump then I don't know what "darcs checkout PATCH" actually would do
18:50 sm or, use separate commands as in reset/apply/unapply
18:51 Heffalump "apply" command that is rather *different*
18:51 Heffalump at least I think it's rather different. Perhaps it's not. It certainly doesn't have a clear inverse at present.
18:51 sm I can imagine the apply command learning to pull patches from history as well as from a bundle file
18:51 sm it's doing much the same thing in both cases
18:51 Heffalump yeah, true
18:52 Heffalump it's the inverse that worries me more
18:52 sm "unapply... It's like obliterate but for the working copy"
18:52 sm needs more work :)
18:53 Heffalump obliterate -O is worth mentioning in this context, as it really is an inverse for the current "apply"
18:54 sm (re your earlier comment about "darcs checkout PATCH" without --add/--remove: it would check out the exact repo state as of that point in history, like get --to-patch - very familiar behaviour to git users)
18:54 Heffalump sm: that's not well-defined
18:54 sm for the current repo
18:54 Heffalump when you record a patch you don't store the exact repo state
18:54 Heffalump ok, so ordering sensitive like --to-patch is now
18:55 Heffalump I guess that's plausible
18:55 sm yeah, I don't see how to do better than taht
18:56 Heffalump and what does uncheckout PATCH do?
18:57 sm the opposite of checkout ? unapplies the effect of the specified patch, and any other currently checked-out patches depending on it, from the working copy
18:57 Heffalump but doesn't that depend on the current state?
18:57 Heffalump whereas checkout PATCH is an absolute state
18:58 sm yees
18:58 sm maybe uncheckout is not needed
18:58 sm well, except checkout is not at all intuitive for removing something
18:59 sm so how about unapply or maybe extend obliterate to handle it
18:59 Heffalump my current counter-proposal is suspend to remove something, unsuspend to add something, checkout to jump to a new state
18:59 Heffalump hmm, ok, apply/obliterate/checkout
18:59 Heffalump I don't really want to have to use a flag for the common non-destructive operation
18:59 Heffalump unappy/apply/checkout
18:59 sm yeah
19:00 Heffalump ok, so one problem is we have darcs rebase apply and darcs rebase suspend right now
19:00 sm because of how it's used in git, and because checkout will interact with unrecorded changes, I quite like "reset" too
19:01 Heffalump hmm, yes
19:01 sm it lets you know you're about to maybe lose some state
19:02 * sm reads http://git-scm.com/docs/git-reset
19:03 sm well, in git it does half a dozen things of course
19:03 Heffalump yeah, maybe there's value in avoiding git's overloaded commands
19:03 Heffalump but that rules out checkout and reset
19:04 sm I wouldn't rule them out just based on that, if there's a common usage that matches (and their english meaning conveys what we want)
19:05 sm I use "git reset --hard" all the time for "throw away the uncommitted stuff"
19:07 sm I guess all the other users of "git reset" are about manipulating the "index" (things-to-commit state), which we don't have
19:09 sm you could also choose something new like "darcs switch"
19:10 sm "checkout" just is going to be super-familiar and intuitive to all git users.
19:10 sm I'll stop bikeshedding
19:12 sm (ditto "apply")
21:04 Heffalump I think we're at least converging on them not being super-commands
21:15 thomie_ joined #darcs
21:23 kowey joined #darcs
21:23 kowey the sprint continues!
21:24 gh_ joined #darcs
21:26 Heffalump we just can't stop ourselves!
21:49 kowey http://darcs.net/Internals/PatchSelection
22:23 kowey so, runSelection is called on contexts generated by different bits of the SelectChanges module, eg. selectionContextPrim in unrevert
22:26 kowey oh wait, but the idea was for the first arg (selectChanges)
22:31 gh_ kowey, I have a small rewriting of the parts that use >=>, into using do notation, and I'll continue tomorrow with that.
22:31 gh_ implementing Heffalump's idea it's promising.. bye!
22:31 kowey :-)

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary