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

[David Holden]

On Tuesday 01 July 2008, Will Newton wrote:
> 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=48a24e
> > >a4e5 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.

Ah, I understand.


>
> 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)
>

I don't seem to have got rogers reply did it go to the list?



So as a lone developer with say a "master" and a branch "d1"  I could make 
changes to d1,  then say master needs an emergency change I can make it, 
continue with "d1" then if I'm happy with "d1", I can checkout "master" and 
do git rebase "d1", this will unapply master changes and apply "d1" changes 
then re-apply master changes?

  Dave.



-- 
Dr. David Holden.

See: <http://www.gnu.org/philosophy/no-word-attachments.html>
regarding Word or PowerPoint. GPG key available on request.
-------------------------------------------------------------