> 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? ;)
@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...
@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 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)
@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!
@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 :)
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".
@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.
@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.
@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.
@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.
@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 It seems to be nice a book - if I only had the time to read that many pages... After posting a comment, "sophisticated word repetition tool" sounds more like a tool to define abbreviations which get replaced by their long version s by the tool.
@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.
@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.
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.
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 ;-)
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