[copyleft-next] Redline

Kuno Woudt kuno at frob.nl
Fri Feb 8 22:25:52 UTC 2013


Hello,

On 02/08/2013 06:23 PM, Pamela Chestek wrote:
> My challenges with Github were that I could not figure out how to
> compare my last revision to anything but the most previous commit. In a
> case where all I had changed from the previous commit was an uppercase
> letter to a lowercase, that wasn't particularly helpful. In order to
> compare my latest iteration to the base document I was revising, I took
> copies and compared them in LibreOffice because I couldn't figure out
> how to do it any other way. I concede I don't know if there was a way to
> do it if I was using Git proper and knew how to use it, though.

github as far as I know does not have a way to compare arbitrary diffs, 
similarly the "github for windows" desktop application does not seem to 
have such a feature either.

On the commandline "git diff" allows you see the difference between any 
range of commits.  (Or if you have a GUI diff tool installed "git 
difftool" can give you a nicer view of the same changes).

> The other challenge was changing my mind. There was one addition I made
> in one commit, then changed my mind and took it out, which was a second
> commit.  In a LibreOffice redline it would have simply disappeared. I
> suppose you can argue that it shouldn't, and you should have insight
> into my every keystroke, but I think that's overkill when it's a
> contemplative process.

> I found the commit process apparently requires more forethought about
> when to commit that what I exercised (sorry Richard). Ideally one would
> commit at logical iterations, but I don't find it very easy to do that
> when revising a text document, where I often jump around and change my
> mind after I've read and absorbed more. Richard broke out my changes
> into logical issues after the fact, but they didn't get created so
> logically.

In general, when working on code, the projects I'm involved in prefer to 
keep the full commit history even if this includes false starts or 
invalid approaches or other chunks of code which do not end up in the 
final branch.  So, for code, we prefer to preserve the contemplative 
process.

However, other projects have different policies, and git does give you 
various tools to "squash" various commits into a single commit, 
specifically "git rebase --interactive" and "git merge --squash".

> I also find a redlined document no harder to read than a version
> comparison, it's pretty clear what's what (unless you have too many
> cooks before accepting changes). It's also easy to do, just turn it on.
>
> I appreciate that redline is incompatible with Git and so is
> inappropriate for this project. But I am a bit puzzled by what seems to
> be antipathy to redline in general, which I just see as another form of
> version control and perhaps better suited to text documents that the Git
> functionality.

As a developer, I prefer working with plain text files, as all the tools 
I use work on plain text files (or streams).  My antipathy is to word 
processor software in general, not redline in particular :)

-- kuno / warp.



More information about the copyleft-next mailing list