@Izzy For a moment I thought that someone stole my question :P (BTW, BY-SA also requires you to link to the user's page, but never mind in this case.)

@ComFreek BY = mention original author (I did)

SA = Share Alike (same license: I did)

? = Link to original (I did :)

But yeah, you've triggered that. When working on my books, I always miss that functionality. When working at SE, I always forget to ask for it :)

So thanks for the reminder – even if not intentional :)

Ah, I see: SE's interpretation has that "link to the authors page".

Let's check what the Original terms say...

> If supplied, you must provide the name of the creator and attribution parties, a copyright notice, a license notice, a disclaimer notice, and a link to the material. CC licenses prior to Version 4.0 also require you to provide the title of the material if supplied, and may have other slight differences.

But yeah, nevermind: Main thing is I've made clear where I've copied from, right? ;)

Yeah, it's totally fine. I don't think that code golf add-ons would be very maintainble :D

@ComFreek No idea. But if I get that right, I wouldn't expect more than one release: the initial one. No updates ever, probably – everything else is a real exception. Updates are no challenges :)

... if not explicitly declared such, maybe? (LTS challenge, LOL)

You might want to checkout AuthorSupportTool for OpenOffice (esp. feature Check for anglicism and sophisticated word repetition tool). Its support for OO 4 is quite disputed, however.

Popularity contest with the winning criteria "who has the cleanest code" would also be an option :)

@ComFreek Checking... While I'm looking behind the link: Does "support for OO 4 is quite disputed" mean it works fine with versions <4? If so, it might be very good you've raised that today – as I was just about updating my 3.5.7 (which came with Ubuntu 12.04 LTS and never got updated) to 4.3.*...

Ah, that one it is. Yeah, had checked it a while ago for "Management of bibliographic sources and reference styles". But seeing how well-supported it is (last release 4/2011), I've decided against it. With 3.4 being the latest supported LO version, even my current 3.5.7 is too new...

> better support of collaborative work with subversion

I bet they have fun programming that. That sounds like a use case for DVCS if I ever heard one.

@Izzy (Sorry for the delay, didn't get any notification.) There is a poll on the right side of the website.

Some weeks ago, I used git + MS Word and it worked like a charm - at least in my case. The diff exactly showed me the words I added.

@ComFreek Did you use a smuge/clean type filter with git-diff?

@Caleb I don't even exactly know what these are, so I don't think that I've used them (unless Git has some automatic magic). I only used "git init, add, commit".

@ComFreek Saying 50:50 chance, yeah. Feel free to make it an answer, so the idea doesn't get lost. I might give it a try in a few days, and upvote your answer, and might even accept it if the addon still does its job with 4.3 :)

@ComFreek cat .git/config and look for any of 'textconv', 'smudge', or 'clean' keys.

@Caleb I cannot see any keys you mentioned in that file.

@Izzy Ok, I'll do it later.

@ComFreek I've just started using Git with my ODT files as well (document consists of multiple parts plus "Master Document"). But I doubt diff would do any good here, as the documents are ZIP containers.

(using Git for "versioned auto-backup", after having had the issue of a "broken document" a couple of times due to elements used by the publisher in the original word doc, where LO seems to have conversion issues with)

@Izzy You can setup diff filters (using the textconv filter and an ODT » text filter) so that it works quite effectively.

@Caleb True: now that you mention it, I remember. That's even possible for JPegs (e.g. diffing the Exif data). When time permits (or the next "crashed document" forces me), I'll check into that. Thanks for the pointer!

@Izzy AFAIK, docx files (which I used) are also only ZIP containers and Git correctly diffed them even when writing in a table cell.

@Izzy You can do more that EXIF data, you could throw an image diff viewer in there too ;-)

@ComFreek I'm wondering if your distro doesn't have some default textconv filters setup. I don't think plain-jane git out of the box will do that.

Distro?

Windows :)

@ComFreek Distro-95, Vista, 7/8... #D

Or eXPerimental...

You forgot the good old '98 :)

(I'm using 8.1 of course.)

I can't understand people who still use XP (on private PCs)

@ComFreek I'm not a Windows GUI. Debian here, and on two computers (unfortunately) still Ubuntu ;)

@ComFreek I can't understand why they still use Windows at all. The last MS-Win I've been using was 3.11 for playgroups ;)

Windows GUI :P Lubuntu is quite nice for old computers

@ComFreek Oh. Will check that this weekend for ODT :)

@Caleb I guess one can do a lot of things with that. As I've already pointed out a few weeks ago, I'm very thankful to you having pushed me into Git :)

You might be interested in ODiff: www-verimag.imag.fr/~moy/opendocument

What did you use before, Izzy?

SVN, and before that CVS (with the latter being quite a while ago). Still using SVN for a couple of reasons with several of my projects.

SVN and CVS are probably still better than my technique years ago: create a folder for each version of a software project :D

What I love about SVN (and what basically keeps me from switching to Git for all of my projects) is the "serial rev": You can easily see that "revision 325" must have newer code than "revision 173".

@ComFreek Uh-oh...

@Izzy It takes a bit to get your head around but git svn is ingenious if you don't have a choice but to interact with an SVN team. Once you get the hang of what to do when, you get a LOT of the git benefits while playing perfectly nice with an SVN repo/team.

Does anyone have experience with hub (GitHub's CLI build upon Git CLI)?

@Izzy I think extracting a number (as in git log entry number) should be possible ... somehow, but it's probably not worth the effort.

@Izzy bzr does DVCS with a serial revition numbering system, but personally I think it makes it harder not easier to grok. DVCS isn't necessarily linear, that's half the point.

@ComFreek Wow! Wonderful! Marked it right away, for sure will give it a closer look! I'm already using odt2text for quickly checking things in ODT files.

In git you can user relative references though, they just count back from the tip of whatever branch you are on instead of forward from 0.

@Caleb Thought about that, but again it's the overhead keeping me away from it. Those projects I'm speaking of only have a few changes every now and then.

@Izzy Do they have branches/tags or just a straight sequence?

@ComFreek That topic is directly addressed in that Open-Source Git book (as soon as I remember the name, I'll throw it in – or simply check my public domain library for "Git", in the German branch). And they concluded you can only do that using timestamps.

@Caleb Nah, I don't want another VCS, please :)

@Caleb That's a different thing. I'm rather refering to a line like $Id$ in source code.

@Caleb Few have branches, but AFAIR those branches are rather historical and could even be dropped.

You mean ProGit @Izzy? ebooks.qumran.org/opds/…

@Izzy You can actually do that with git. We were just talking about smudge/clean filters...that's were you do it. I've seen it done with linear numbers to because you can generate your own counter that runs at commit time and edits the files appropriately.

I've made branches when "switching topology", so to say – i.e. completely re-structuring the code, and keep the "old branch" for compatibility – back-porting bugfixes for a year or so, than declaring them "unsupported".

@ComFreek Exactly, yes! That book is available in many languages. And actively maintained.

@Caleb That sounds interesting! I don't mind "gaps" if they happen from time to time, but a '"counter" is a "serial", and would do for this case!

@Izzy git rev-list --count HEAD

A common way to generate a version number for devel builds is something like:

printf "0_%s_%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"

...where 0 is the last release version number, which you should be able to fetch from tags.

@ComFreek Umpf. Than better refrain from putting that as an answer, wouldn't match. I might take a look at it nevertheless: if it works, and it's not just a macro-expander (but really what we're looking for), I'll let you know and you can put the answer then.

For example this is a favorite of mine and often used in packaging HEAD versions of software:

git describe --long --tags | sed 's/^//;s/-/_/g'

That will generate you a version number for the current commit that has the name of the last tag + the number of commits since that version was tagged + the actual hash of the release.

That way you can see at a glance how many commits you're dealing with since the tagged release, do numerical sorts on the version including builds of each commit, plus you have the hash if you need to reference it directly.

Fore example on SE-AUR that might show something like v1.3.3.3_3_g05fd27a.

v1.3.3.3 is the last tag, I've made three commits in this branch since that tag, and the short-sha of my current commit is g05fd27a.

Stick that in sed command as a smudge filter or a pre-commit hook and you can keep a version number up to date in the repo.

That sounds great for a command-line check on how far I am. But I'd need Git to put that into a placeholder within the commited files – not on commit, but on checkout. And then it must not put the "number of total commits" in there, but the "number of coimmits when the checked-out version was committed".

@Caleb Oh, you were faster.

Hm, that might do as well. Would cause an additional "diff line", but that's ignorable.

Thanks a lot for the explanation! Just "bookmarked" it to copy-paste it to my Todo list later.

@ComFreek that previous comment is a candidat for our addon: too many to-s to count to two :)

@Izzy On checkout would be a smudge/clean filter. git rev-list --count HEAD would supply a value, you'd just need to write the sed expression to insert/remove it yourself (although there are several out there already of course.

@Caleb but wouldn't rev-list give the total number of commits in the repo?

Say I have 10 commits, and checkout #5.

git rev-list --count HEAD would result in a "10" then, while I want the "5".

And specifying something other than HEAD would not count from 0 to 5, but from X to 10.

Maybe I'll simply try my Google-Fu on this problem. For sure you just proved there should be some kind of solution to it.

@Izzy No, that would count down the tree from whatever branch you are on now following parents back to the start of the repo. If you branched at 100 and made 10 commits in both branches they would each show 110. If you then rebased one of them on the other, the rebased one would start showing 120 because the 10 commits from the other one got inserted into the current branch.

Still, matching things back requires a little effort again: if I want "commit #5" I had to use git --rev-list HEAD |head -n 5|tail -n 1 or something like that :)

@Caleb In which case #101 from the rebased branch suddenly became #111, losing consistency.

@Izzy That's why git doesn't use sequential revision numbers. There is no guarantee that they are sequential.

@Izzy Indeed :)

In subversion you'd have r100, r101 in branch x, r102 in branch y, r103 in branch x, .... and then you try to merge and you end up with 10 more commits r121-r130 (or worse, just r121 with everything squashed and no meta data about where the commits came from and blame goes out the window.

To be honest: a rebase is something one rarely should use. I know it can be useful, and I know what for – but as I'm the repo owner, I sit on the "receiving end", and wouldn't be dealing with the consequences :)

I'm leaving now before I get depressed. I remember managing merges between long-running devel branches in subversion and it's the stuff nightmares are made of.

@Caleb No need for getting depressed!

I'm talking about "mini projects" I'm working with.

@Izzy If you're rarely using rebase you haven't discovered what it's for!

Not to be compared with things like Linux kernel ;)

@Caleb You might be right about that. I only know it in theory. And while I could definitely see some advantages, I didn't see where I personally with my own stuff would need it.

You don't rebase anything you've made public, sure. But it's indispensable to set you free to hack on things without worrying about loosing things or introducing accidental mistakes.

@Izzy You're own stuff is generally the only place you want to use it regularly ;-)

@Caleb Put that way, yes :)

And if I fork from another repo, make some fix, and want to send that upstream, that's definitely something where rebase comes in – especially when the "master" has moved forward as well.

hey guys, anyone have a recommendation for a program that makes windows 8 look like windows 7? trying to find that question in the search but I'm only seeing one that asks for the opposite, to make 7 look like 8

i really don't see that question, so maybe I will just post it up