Git repositories created and how to work with them
Andreas Pakulat
apaku at gmx.de
Wed May 12 13:46:54 UTC 2010
On 12.05.10 12:00:33, Vladimir Prus wrote:
> On Wednesday 12 May 2010 11:29:26 Andreas Pakulat wrote:
> > > Also, it's not exactly clear to me how I am supposed to arrange my working
> > > copies. Should I just clone kdevelop repository locally, or else, make
> > > gitorious clone it, and then clone gitorious clone?
> >
> > This is what I'm planning to do for myself: Have a local clone of the
> > original repo to do bugfixes in stable branch and smaller features
> > directly in master (single-commit-stuff basically). Anything bigger gets
> > a new branch branched off of master. If I then want to share this local
> > branch with others to work on it together or just have it more widely
> > tested then I'd add a remote for a clone of the repo on gitorious and
> > push the branch to that repo. Once its ready either merge it back into
> > master and push that to the original repo,
>
> Is there a reason why merge from topic branch to master is preferrable
> to rebase onto master -- which would create a more linear history?
Thats because it'll nicely group the commits belonging to the topic in
tools that visualize the history (like gitk --all, which I use a lot).
Apart from the fact that rebasing a branch you've already published will
need a forced-push and screw everybody who already uses that branch (as in
they might need to re-fetch the remote and delete all local branches that
used that rebased branch).
On the other hand merge commits make git bisect harder to do (See
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#bisect-merges),
so its your decision if the branch is one that you've only used yourself on
your own machines and didn't publish yet.
Andreas
--
You will have domestic happiness and faithful friends.
More information about the KDevelop-devel
mailing list