Fwd: my git development snapshot(s)

[Gleb Kurtsou]

On (18/09/2011 12:14), Andriy Gapon wrote:
> 
> Just decided to follow the global trends and trying to throw all of my
> local/private changes at you in hope that the "crowd-sourcing magic" might
> somehow happen :-)  This seems definitely easier than carefully producing the
> patch files and keeping them up-to-date.
> 
> So, my newly cloned gitorious repository:
> https://gitorious.org/~avg/freebsd/avgbsd
> 
> And the first branch of interest:
> https://gitorious.org/~avg/freebsd/avgbsd/commits/devel-20110915
> 
> This is a snapshot of almost all of my local changes to the FreeBSD src tree.
> Please note that the branch is not intended to be public in the git sense.  That
> is, there will be no linear history - I periodically rebase my changes on top of
> the svn head and also frequently reshuffle/merge/split commits.
> The snapshot is not tidied up, there are quite a few commits that should be
> merged into other commits, some commit messages are not accurate/pretty, etc.
> The older the commits, the more mature they are supposed to be.
> 
> Based on the above, no new commits are expected to this snapshot branch.
> I will produce new snapshot branches from time to time.
> 
> I am posting this information to this list initially, later I plan to share the
> code with the wider audience e.g. via hackers at .
> 
> P.S. This code sharing is made easier for me by git, Gitorious and "git rebase
> --onto" in particular.  Thanks to Fabien Thomas for the initial FreeBSD clone
> repository at Gitorious!

Let me share my experience as well. 

My repo: https://github.com/glk/freebsd-head/

I used rebase to keep local branches as well, but no longer do so. Such
setup worked for me at least for two years, I had local changes and
worked on a larger patchset for 7,8-STABLE and CURRENT branches
simultaneously (no longer do it either). But (imho) this approach his
serious drawbacks. The biggest one is that it's hard to check if
regression comes from your code or recently merged upstream code. The
second one: once you screw rebase (merge) you are in big trouble. Both
issues can be worked around by keeping previous master branches, but it
hardly helps: once there are conflicts with upstream or your local
changes get commited upstream it becomes only harder and harder. (I used
to have master-prev-DATE similar to devel-DATE Andriy uses.)

I like and use rebase a lot while working on the code: reorganize
commits, small fixups, etc. But try not to touch code that is more than
several days old unless really necessary. The reason is to maintain code
base in well tested state: imagine you've changed or small bit in
HEAD~20, a week later you find a bug, bisect to find that it showed up
in orig-HEAD~10 because of your small fix in orig-HEAD~20. Fixing it
would have taken less time without that rebase, or bug wouldn't appear
in the first place. Once history stabilizes (i.e. remains untouched for
3-4 days) I push it public or backup (for local projects) repository.
There is no history rewriting after this point.

Use separate branches for independent patchsets. E.g. tmpfs branch - for
tmpfs changes, misc - for smaller changes, etc. It lets me bisect and
test code easier. For example if I get strange panic I could create
temporal branch with all patchsets except pefs branch. Test it, find
faulty branch, bisect individual changes. Besides it's also possible to
bisect master branch, merge appropriate patchset revisions while
bisecting upstream, etc.

Upgrade procedure. Patchset branches are independently merged with
upstream (vendor/master in my case). And all patchset branches are
merged into master branch. In other words resolve conflicts in patchset
branches, merge everything back to master. I usually merge individual
branches only if there are conflicts or after important milestone.
Octopus merge in git may not be as good as you I'd like it to if there
are conflicts in several branches, but it's manageable.

I also find identifying my changes vs upstream easier than in rebase
scenario:

- Use 'git log --first-parent'. Limiting number of commits to show in
  gitk is also good option for large repositories.

- Use 'git merge --no-log --no-ff' to merge with upstream, it strips
  excessive logs from commit message, --no-ff is necessary only for the
  first time because fast-forward merges won't be possible. To keep
  history extremely clean: create empty git repo, make non-empty commit
  and merge with upstream.

And there is hope that keeping independent branches would make
"crowd-sourcing magic" more feasible :)  I'd prefer to be able to merge
code I'm interested in without touching unrelated bits.

Thanks,
Gleb.