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

[Roger Leigh]

David Holden <dh at iucr.org> writes:

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

> At the moment, I'm trying to workout whether its worth my while
> understanding rebasing.

Rebasing is something of a contentious issue.

See
  http://thread.gmane.org/gmane.comp.version-control.git/75035
  http://thread.gmane.org/gmane.linux.debian.devel.general/125097

The latter "git bikeshedding" on debian-devel is a bit flamey, but
does highlight the major issues.

As I see it:

* Rebasing *changes and loses your history*.  It discards the changes
  between the original branch point and the rebase point.  It
  basically detaches the branch from the original branch point and
  reattaches it at the rebase point, with any intervening changes
  effectively re-merged against the rebase point.
* This may or may not be desirable.
* If your branch is used by others, it will cause them problems since
  the history changed.
* If the branch is a short-lived topic branch for development pending
  merging back onto a main branch, then the "history" may be dirty,
  and rebasing will clean it up for submission.
* You can avoid losing history by branching the branch, and then
  rebasing the copy; you then have both the original branch and a
  rebased branch.

I think if you are working on a single feature, and regularly commit
changes, you might find the history a bit messy.  When it comes to
merging back onto a longer-lived branch, that history is probably
irrelevant: what that branch maintainer wants is the equivalent of a
patch, or set of small patches; they don't want all the steps you took
to arrive at the final point--it will pollute the main branch history
with irrelevant details.  In this case, rebasing makes sense.  Arch
users are already used to this: they create "submission branches" with
a clean history, ready for merging back.  However, rebasing a branch
other people are actively cloning and branching from does not make any
sense at all.

When developing with CVS or SVN, branching is such a pain that it's
quite common to work on a single feature on the mainline, then commit
it only when perfect.  With GIT, you can do *all* development on
branches: you just branch the head, continually commit your changes
onto the branch as you work, and then merge the branch back when
you're done.  You can then delete the branch if you like.  With this
model, rebasing can make a lot of sense.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://list.wylug.org.uk/pipermail/wylug-discuss/attachments/20080630/fe49577b/attachment.bin