Fred's firmware development diary

[Fred]

Right, I've got to a state where I'm unsure of what I have locally committed and am therefore not sure whether I want to push up or not.

OK, its easy, get the sha1 commit from githubs public site and do this :

git log 1d21ce090621ac4236c5..HEAD

this gets all commits between that sha1 (you only need the first unique part of it, 8 chars is usually enough apparently) and the current last commit of your local current branch.

There is probably a way to get the latest head from the server with a url too rather than explicitly, but not sure what it is yet.

------------------------------------------------------------------

I think what I need to do is :

Code: Select all

git stash

to store my current uncommitted changes safely out of the way.

Code: Select all

git branch public

to get a copy of the repo i have locally again.

Code: Select all

git checkout public

to make public my current working branch

Code: Select all

git reset --hard HEAD

to reduce my local branch to what is on the server

EDIT: this one ^ was wrong. What I needed to do was reset to the server head, so provide a reference to the github servers copy/head.

Code: Select all

git diff master public

or similar to find out what is going on.

when I'm done looking...

Code: Select all

git checkout master

to go back to my master branch

and finally...

Code: Select all

git stash apply

to put my changes back in place on the master branch.

----------------------------------------------------------------------

unfortunately stash isn't available on 1.4.4, only 1.5.0+

Solution : backports.org

http://packages.debian.org/etch-backports/git-core

----------------------------------------------------------------------

OK, so there you have it, how to complicate a simple task!

Thanks to Aaron who I just rang 10 mins before midnight on new years eve who was most helpful in explaining that a branch isn't a specific entity on it's own, rather just a shallow copy/ reference that you can independently manipulate.

Fred.

[Fred]

OK, just a little something to note :

When you do a git diff rev2..rev1

order affects the output. IE, even if rev1 was before rev2 you will get the way the changes need to be made to move between them in the order specified.

Fred.

[Fred]

I just pushed a few small changes up. I've got to get clean and get food now, but later I'll be committing and pushing much more stuff :-)

Fred.

[Fred]

for the record :

git log
git shortlog
git diff

all work with revhash..revhash

so you can find see what is going on. I'd like there to be a shortlog + files touched method, and there probably is as to me a commit message means little without a file reference...

git stash works most excellently also.

My current plan of attack is to keep the following branches :

master = my development branch (this is non standard, but linus may do something like this?)
public = last pushed branch
seank = seans last pushed branch
otherContributorX = their last pushed branch

the aim of the game is for peoples last pushes to be clean to merge into my public branch and push back up. IE, the changes are of suitable quality and they have already brought their stuff up to date so the merge is trivial for me.

Then it is simply a matter of ensuring we work on different files or at least different bits of files.

Fred.

[Fred]

I've been working hard on the doxy stuff and playing wtih git in earnest.

About git :

I LOVE git:
Simultaneously I have seans work, the public repo, my latest stuff and the last release as it was in ONE directory :-) I can switch between them almost instantaneously and if bugs come up I can release fixes without releasing new features! mint.

On the other hand, setting up multiple remote repositories without Aaron to hold my hand is slightly complex and tricky.

I've now got Sean's stuff locally though, but I haven't done anything with it yet as it still needs some work and to be brought up to date.

I still need to configure the github repo as the default for my public branch to ease tracking it.

I also still need to figure out how to create a public release branch to live next to the master development one. This will be useful when we start having people using the system and reporting bugs. Bug fixes will definitely be released promptly (priority much higher than new features) and independently of any new features currently under development. IE, the fixes will be alone and released as minor version increments over the release version.

Then I need to tell my release branch to track the public release branch.

Lots of fun stuff to get on with :-)

The next release will most likely be a purely documentation update over the last, though I may add in some extra serial stuff too if anyone ever responds meaningfully to the thread I started. I was hoping more of the key members would, like me, have no life and be on the board over this time. Hopefully some of them pipe up over the next week or so.

A documentation and code tidy up/reorganise won't hurt at all though, it's about time I gave it another "hows your father" :-)

Fred.

[Fred]

This message timed at 00:36 1/1/09 :-)

What better way to start the year than committing all of my doxy work so far and pushing it up to the public repo!

Bed time,

Fred.

[Fred]

Right, I just pushed my latest stuff.

You can use this link to download it as a zip or tar.gz :

http://github.com/fredcooke/freeems-van ... 3f039bfba0#

The trick to that download link is to wait for a few seconds after the popup comes before choosing which type. It seems to me that it is during that time that it is generating the files. I could be wrong though.

Jared, if you want you can do a preliminary doxy of that commit state and post it as 0.0.19-prerelease on the sourceforge site? I'm interested in having people look it over in html format and provide feedback on what needs changing etc.

I'll carry on working so make sure you get that commit :-)

Fred.

[Fred]

Code: Select all

/home/user/workspaces/home/freeems-vanilla> git diff --shortstat public 0.0.18-JackTheRipper
 95 files changed, 1450 insertions(+), 2671 deletions(-)

Now you will actually get to see how much work I do on this bloody thing! Look at that!!

That's about 10 days work, except that I was away on holiday sight seeing for 1/3 of it and at work for another third.

The high delete count is because I removed some files here and there including 3 header files.

Note, I've started using tags :-)

I could actually retrospectively go back and generate all those stats for all previous version jumps using git-svn which I've been playing with tonight. I'm trying to figure out how to get my git commits into my svn repo when they don't share a parent.

I may generate those stats if I get bored.

Fred.

[Fred]

Code: Select all

/home/user/workspaces/home/freeems-vanilla> git diff --shortstat public 0.0.18-JackTheRipper
 95 files changed, 1450 insertions(+), 2671 deletions(-)

<snip>

The high delete count is because I removed some files here and there including 3 header files.

Code: Select all

/home/user/workspaces/home/freeems-vanilla/src/doxy> git diff --shortstat 0.0.18-JackTheRipper public
 95 files changed, 2671 insertions(+), 1450 deletions(-)

It pays if you get the arguments around the right way... :-)

Fred.

[Fred]

I've been playing with branches and git-svn and so forth. The main thing I will say is that git-svn is dead easy. The other thing I'll say is that the network view on github doesn't show a second line for a second branch unless there is a difference between them at all points in time? Not quite sure on the logic behind it. I knew it didn't show say Jared's branch as he's not committed anything to it yet, but it also won't show one of my own if there are no differences. Note, no diffs, not no different commits. Add two diff files, one to each branch and there it is, remove the one from the forked branch (release in my case) and it's invisible again! Curious.

So, right now it's visible as I added a further commit to the master branch just to test (and to get something done).

See it here :

http://github.com/fredcooke/freeems-vanilla/network

The three red dots are my test commits, they are fairly meaningless. Scroll to the left to see Sean's commits.

Fred.