[Debian-eeepc-devel] rt2860 Git reporitory

Thu Oct 9 16:49:31 UTC 2008

-=| Glenn Saberton, Thu, Oct 09, 2008 at 07:48:53PM +0800 |=-
> Damyan Ivanov wrote:
> > I am very much tempted to redo the rt2860.git repository from 
> > start.
> Firstly, I disagree with this. Why can't we just clean up the existing
> repo to your liking. then at least its all in history from the start.

It is the history I want to clean up.

Of cource I could start with 

 git rm * && git ci -m 'starting with a clean repo'

and after that start the replay. Doesn't seem that nice to me.

Important note: when I am saying "starting from scratch" I don't mean 
starting with an empty repository and do the packaging all anew.  
I mean to replay (cherry-pick) *all* the commits from the current 
repository, modifying them to match the schema I find easier to work 
with.

> > Right now, each new upstream release is stored once as .tar.gz and 
> > under a directory whose name includes the version. Aside for being 
> > grossly inefficient (unless Git does some magic), this very much 
> > voids using a source management too for tracking upstream changes. 
> > Right now, commit fea49085c3b26416a96c121f848dd032603f5cb7 (New 
> > upstream version) contains an import of many new files (under 
> > rt2860-source-1.8.0.0) and no single changed file.
> I'm not sure I understand what you mean here.

I mean that importing a new upstream release should modify the current 
upstream sources (in the upstream branch), not add another directory 
in the tree.

> > If one wants to see the diff, s/he should diff manually. Even manual 
> > diff won't quite do it as the rt2860-1.7.0.0 tree also has changes to 
> > the upstream code.
> Again I am not sure I understand what you mean. the rt2860-1.7.0.0 tree
> is a pristine untarred source with the debian directory in it.

How do I see upstream differences between 1.7.0.0 and 1.8.0.0 using 
Git? OK, this can easily be done with regilar recursive diff plus 
filterdiff. Harder problem: how do I check all changes in file 
X through all upstream releases?

In order to do this, the new upstream release should be committed in 
the 'upstream' branch, then merged to 'master'. This way if I want to 
see what upstream has done, I fire up 'gitk upstream'.

This was the reason I decided to start my crusade :). The long story:

 I was lying ill at home (cought a cold, nothing serious) and suddenly 
 thought:
   "Glenn imported a new upstream release of rt2860. I should try it.  
   The last one was flacky with WPA-PSK2. If 1.8.0.0 works, I'll 
   revert my wireless AP from WPA-PSK to WPA-PSK2".
  Pulled from rt2860.git and then wanted to see the diff between 
  upstream versions.  gitk couldn't show it to me as the new upstream 
  release was imported in another directory.

> > Which brings me to the second reason for redoing the repository: 
> > upstream changes are applied directly. I am used to quilt and find it 
> > excellent for tracking upstream changes. How do you check the changes 
> > to upstream code now? Browsing the whole history is not an option. Ah, 
> > and the package already uses quilt anyway.
> I simply followed
> http://www.debian.org/doc/maint-guide/ch-update.en.html#s-newupstream-real
> and copied the debian directory over and fixed up the patch series. If
> you prefer me to do it differently, just point me in the right direction.

Oh, that guide is, err, very far from the present reality. It 
discusses version control just as some corner case and not to the 
extent it is involved in packaging today. I'd suggest the Git section 
of http://wiki.debian.org/Games/VCS

> > Another approach for tracking changes to upstream code could be 
> > a farm of branches, one for each self-contained feature. I am yet 
> > to master this so I don't feel like going this path unless others 
> > love it.  A good guide for this approach is 
> > http://www.eyrie.org/~eagle/notes/debian/git.html
> > 
> > As of keeping track of released upstream tarballs, there is that nifty 
> > tool called 'pristine-tar' which does an exellent job keeping them in 
> > a separate branch of the Git repository.
> will look into it

git-import-orig(1) has an --pristine-tar option that automates the 
import.

> > Last point, please commit when a feature is complete. Mixing two 
> > features in single commit is bad later when one wants to see why 
> > something was changed. See b187e72da2abf5066d91c80df5afcb8d95fa7c0d 
> > (initial cleanup of makefiles, on makefile branch). This commit 
> > changes two .c files, renames one Makefile, deletes another, and 
> > moddifies two. Go figure how all these changes are related. I wouldn't 
> > call them "a cleanup" in any case.
> The makefile branch is a test branch for me to try and get rt2860 to
> build with kbuild. We would like to get these modules built using l-m-e
> and as such, something needs to be fixed to do so. I am not sure why you
> even bother to mention a branch in git. Git is meant for development,
> and as such, I made the branch after discussing with you about fixing
> the makefiles. (this discussion was some weeks back on irc) You stated
> that you thought upstream should fix the makefiles, so i made that
> branch so that if we want to build modules for packaging with l-m-e,
> then the dev packaging them could simply use that branch rather than
> have the changes applied to the normal source.

I think this approach is not right. You want a feature (building 
rt2860-modules with kbuild). Create a branch from master, name it 
after the feature. Work within that branch committing after each 
logically-complete change.

You may push whenever you are satisfied with the current tree. If you 
are not satisfied, either add more commits or ammend old (but not yet 
pushed) ones. Or even push when not yet satisfied, but have to do 
something else and want to store the current state in a safe location  
just in case.
(continues below)

> The matter of the c files
> being different in that branch is because i forgot to run a debian/rules
> clean on the source before i pushed, and therefpore the patches that are
> in the master branch weren't reverted. Again I dont see why this is a
> big deal in a development branch.

Because the next step after the feature is complete is to merge the 
feature branch into master. This means also using quilt for upstream 
changes in the feature branch similarly to master.

> > After the rework I am proposing, the repository would have the 
> > following branches:
> >   * master - package is built from here
> >   * upstream - upstream releases (expanded tarballs) are tracked here
> >   * pristine-tar - a branch whhere pristine-tar keeps the service 
> >     information in order to be able to create upstream .orig.tar.gzs
> >   * makefile - same as now
> > 
> > I intent to start an empty repository named rt2860-clean.git and 
> > cherry-pich the commits from the current one one by one fixing each to 
> > follow the above layout. When done (all commits from rt2860.git 
> > migrated), I shall rename rt2860.git ti rt2860-old.git and 
> > rt2860-clean.git to rt2860-source.git. After this, you have to 
> > re-clone the repository. Your old clone can be kept so you can verify 
> > that I did not break things.
> > 
> > This would take some hours,

Most probably replace "hours" with "days"

> > so please tell me if you see something wrong in my plan.
> I personally dont see the point.

The point is having a clear history of traceable changes that is 
easier to work with.

I hope the project would trust me to do this in good faith. I intent 
to keep each commit's author for instance. Of course, I am a mortal so 
mistakes can happen. This is why I have no immediate plan for removing 
the old repository.

> But feel free to do so if you like.

Anyone else having objections?

> I am still working on getting kbuild to work, so please dont be 
> offended when I make the makefile branch again.

I have nothing against the branch per se. With a little improvement 
(using a descriptive name; moving upstreaam changes to a quilt patch) 
it would be fine to merge it to master when ready.

Particularly, I intent to do the 'improvements' I mention in the 
replayed repository. You are not required to do anything. Feel free to 
commit/push in the repository as you wish. When I am ready with the 
transition, I'll mail the list so that any local (not pushed) commits 
get pushed and migrated too.

Thanks for your patience. Lying in bed wakes up the writer in me :)

-- 
dam            JabberID: dam at jabber.minus273.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/attachments/20081009/6e2cbda2/attachment-0001.pgp 