[copyleft-next] Redline

Pamela Chestek pchestek at gmail.com
Sat Feb 9 01:55:24 UTC 2013


Thanks, all very helpful info.

Pam


On Fri, Feb 8, 2013 at 5:25 PM, Kuno Woudt <kuno at frob.nl> wrote:

> 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.
>
>
> ______________________________**_________________
> copyleft-next mailing list
> copyleft-next at lists.**fedorahosted.org<copyleft-next at lists.fedorahosted.org>
> https://lists.fedorahosted.**org/mailman/listinfo/copyleft-**next<https://lists.fedorahosted.org/mailman/listinfo/copyleft-next>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/copyleft-next/attachments/20130208/bdd75630/attachment.html>


More information about the copyleft-next mailing list