Debian discusses Discourse

Posted Apr 20, 2020 18:21 UTC (Mon) by mathstuf (subscriber, #69389)
In reply to: Debian discusses Discourse by marcH
Parent article: Debian discusses Discourse

The obvious extension is that every in-editor edit should end up as a new commit. There's obviously a line between that and "commit the final version". I just prefer it to be far on the side of "working sets of commits" than "what happened to be in my tree at time X" than DRH :) .

This post sums things up really well I think: https://jeremykun.com/2020/01/14/the-communicative-value-...

Debian discusses Discourse

Posted Apr 20, 2020 19:53 UTC (Mon) by marcH (subscriber, #57642) [Link]

> The obvious extension is that every in-editor edit should end up as a new commit

You've been reading my mind :-)

Nice https://jeremykun.com/2020/01/14/the-communicative-value-..., thanks!
> " Programs must be written for people to read, and only incidentally for machines to execute.” The same view guides my philosophy for working with revisions, that code changes must be written for people to read [and review] and incidentally to change codebases.

Relatively subjective discussions about code review aside, I just realized Fossil can say good bye to "git bisect":

> "what happened to be in my tree at time X"

Another casualty of this strong Fossil opinion and mistake: it forces you to collapse the history and the "history of the history" onto the same axis (https://blog.linuxplumbersconf.org/2016/ocw/proposals/384...)

Of course git doesn't take a stance and let's you do that too, in fact Github tries to push you into that exact same Fossil direction [*]. Git is the C++ of version control: it lets you do absolutely anything including of course shooting yourself in the foot.

The Code Review Tool of the Future will treat the history of the history/of the code review as a first class citizen and subsume git pile, git series, etc. Due to its severe data[base] shortcomings, email is especially bad there.

[*] https://github.com/isaacs/github/issues/959#issuecomment-...

Debian discusses Discourse

Posted May 21, 2020 12:45 UTC (Thu) by nix (subscriber, #2304) [Link] (3 responses)

The obvious extension is that every in-editor edit should end up as a new commit.

You think it's a joke, but this is what git-wip does, triggering a commit in a not-normally-visible ref on every save via editor hooks. Its only problem (other than an unavoidable complete lack of useful commit log, so you more or less have to do a log -p restricted by date to find stuff you want to recover) is that it's so transparent that I usually forget that it even exists, so I don't use its careful records of every save I did as often as I could. It's part of magit but also a separate project and I think there is a vi-hooking variant around too.

Debian discusses Discourse

Posted May 21, 2020 13:33 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (2 responses)

Using such functionality locally for backup purposes is fine, but I will judge if that branch goes for review :) .

Does it save commit history or is it a series of snapshots all sharing the same parent? Even better would be to reconstruct the history like Vim's (and probably Emacs') history tree too. If it's just a temporal snapshot history, a history viewer where you could collapse the nodes down by a time span would be nice.

Debian discusses Discourse

Posted May 21, 2020 13:45 UTC (Thu) by farnz (subscriber, #17727) [Link]

This is one of the things I like about Mercurial's Changeset Evolution feature - I can have a messy pile of commits while I'm working, and then have a clean pile for review that I've fixed up, but that maintains the links to my messy pile so that I can see how I got there.

Debian discusses Discourse

Posted Jun 2, 2020 13:10 UTC (Tue) by nix (subscriber, #2304) [Link]

It uses branches named after the complete ref of the branch being saved under, e.g. for the branch I'm working on now (named 'oracle/ctf-next'), the working tree's state is saved in a branch named 'refs/wip/wtree/refs/heads/oracle/ctf-next', and the index's state is saved as 'refs/wip/index/refs/heads/oracle/ctf-next'. The names are a bit long, but customizable, and unambiguous. The commit log comments have got more useful since I looked at them last and now say why the wip is happening and what file is being newly preserved.

Every time you commit, the corresponding wip branches are restarted: the old ones are still accessible until the reflog expires (this is clunky, but I can't really see a way around it). You end up with wip branch history like this:

193b21c09b (refs/wip/index/refs/heads/oracle/ctf-next) autosave ld/lexsup.c after stage
9848c17b26 autosave ld/lexsup.c after stage
23ccc37ffb autosave ld/ldlex.h after stage
9ece7ac0f3 autosave ld/ldlang.c after stage
4652ac99a8 autosave ld/ldlang.c after stage
c9a78b787f autosave ld/ld.texi after stage
2e0966c4e8 autosave ld/ld.h after stage
bfd20b8df2 start autosaving index
bfeee83394 fixup! libctf, ld: add --ctf-variables and omit variables from CTF by default
fbcdd02300 libctf: add ctf_link_set_variable_filter
...

(where bfeee83394 is the last commit on the real branch.)

or this, for a working tree:

436a729994 (refs/wip/wtree/refs/heads/oracle/ctf-next) autosave ld/ldlex.h before stage
662a4b4ee5 autosave ld/ldlang.c before stage
1c3b615c7d autosave ld/ld.texi before stage
1dccab233e autosave ld/ld.h before stage
5958b6cd68 autosave ld/lexsup.c after save
22bfa4bcfb autosave ld/lexsup.c after save
c744e6c41f autosave ld/lexsup.c after save
76c6a6e074 autosave ld/lexsup.c after save
caf21622cb autosave ld/lexsup.c after save
f7d813e9f5 autosave ld/lexsup.c after save
a486e6417e start autosaving worktree
bfeee83394 fixup! libctf, ld: add --ctf-variables and omit variables from CTF by default

Manual: https://magit.vc/manual/magit/Wip-Modes.html