Thanks, all very helpful info. 

Pam


On Fri, Feb 8, 2013 at 5:25 PM, Kuno Woudt <kuno@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@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/copyleft-next