[Wylug-discuss] Call for talks/ideas for talks

[Will Newton]

On Mon, 2008-06-30 at 16:37 +0100, David Holden wrote:
> On Monday 30 June 2008, Roger Leigh wrote:
> > On Mon, Jun 30, 2008 at 02:43:14PM +0100, David Holden wrote:
> > > On Monday 30 June 2008, Roger Leigh wrote:
> > > > On Wed, Jun 25, 2008 at 11:23:44PM +0100, Tom Hall wrote:
> > > > > I am just nudging the list for volunteers to give talks in future
> > > > > WYLUGs, or topics that people would enjoy seeing talks on.
> > > > > The only reply last time was from Christopher Brown asking for
> > > > > something on sourcecode management; git, SVN, CVS diff, patch etc.
> > > > > Anyone doing anything cool here?
> > > >
> > > > I'm a regular user of CVS, SVN, Arch and Git.  I can give a talk on
> > > > them if there is interest in that.
> > > > If anyone had any specific VCS topics in mind, I'm sure I could cover
> > > > them.
> > >
> > > I'd be interested in one of Git. Particular how best to use it in a
> > > development cycle as a lone developer.
> >
> > That's the easiest use case for git :)
> >
> > It's also what I use most myself, though I do occasionally pull other
> > branches from people.  Normally, I use a central "official" repository
> > and pull and push just from that to my local machine, as do other
> > developers in the project.  It is, of course, possible for anyone to
> > clone that and then pull and push between me, themselves, and the
> > central repo as they feel!  git makes branching and merging so easy, you
> > do it all the time (the equivalent of "cvs/svn update", "git pull" is in
> > effect a combined fetch and branch merge).  The simplest case is just to
> > have a single standalone repo on your local machine, though that's not
> > so great for backups and letting others get a copy.
> >
> > One I work on quite frequently is schroot:
> >   http://git.debian.org/?p=buildd-tools/schroot.git;a=summary
> >   git clone git://git.debian.org/git/buildd-tools/schroot.git
> >
> > This would probably be a good simple example for how to use git.  On
> > that page you can see both tagged releases, branches (heads) and the
> > current master activity.
> >
> > Example changeset from a contributor:
> >  
> > http://git.debian.org/?p=buildd-tools/schroot.git;a=commitdiff;h=48a24ea4e5
> >a893a1f3404cad2b89d90e5d01232f
> >
> >
> > Regards,
> > Roger
> 
> At the moment, I'm trying to workout whether its worth my while understanding 
> rebasing.

Rebasing is mainly useful when you are tracking an upstream repository
and you want to maintain a patch set against that repository and
maintain it in a "pullable" state.

For example, you make some kernel changes against a release in your git
repository (say 2.6.26-rc7). You submit them, get some feedback on them
and then come to submit them again. But now the tree has moved on (rc8).
If you just git pull the upstream branch into your tree you end up with
a history something like this:

changes to rc7 --> your changes --> changes to rc8

Your changes get buried in the history and the graph of the history in
your tree is different from upstream. That makes it a bit awkward to do
a diff and understand what changed where. Instead you could do a git
rebase onto the upstream tree and end up with something like this:

changes to rc7 --> changes to rc8 --> your changes

Essentially rebase unapplies all your local changes, pulls changes and
reapplies your changes one by one on top of the new head. 

If you're just working on your own you're not likely to do much
rebasing. However, git rebase --interactive can do even more
complicated things, it allows you to drop commits, edit commit messages
and squash commits together. That can be useful if you make maybe 10
tiny changes and then decide you were over-cautious and you'd rather
redo them as maybe 3 bigger patches, rebase can help you do that.

(Having just read Roger's reply, he covers most of this better than I)

>   Dave.
> 
> 
> 
>