[Digikam-devel] Re: thoughts on branches with git

[Andi Clemens]

Maybe a stupid question, but how do I check out the needed libraries for  
digiKam?
I found the digikam, kipi-plugins and the *-docs repos, but none of the  
lib repositories.

The only thing I found is a repo for libkface and libkipi.
Do I need to checkout all those libraries one-by-one now, or is there some  
kind of container repository?

Andi


On Sat, 05 Mar 2011 16:17:02 +0100, Marcel Wiesweg <marcel.wiesweg at gmx.de>  
wrote:

> Hi,
>
> now that we are using git and have merged all branches still coming from  
> SVN,
> we can now readjust habits and have a look at what workflows git allows  
> with
> branches.
>
> Compared to git, SVN never really had branches; we had code in different
> directories, and a very limited merge commoand.
> It needs some time to get used to git concepts; in doubt, I always  
> recommend
> to use gitk to get a visual feedback about local and remote branch  
> settings.
>
> git offers a lot of flexibility to do things as you want (but also to  
> break
> things, also in the remote repo). Therefore the following five workflows  
> are
> not exclusive.
>
> 1) Simple local changes
> You may have noted that "git pull --rebase" does not work as soon as you  
> have
> any local changes. The sequence it then
> git stash; git pull --rebase; git stash pop
> I always found it cumbersome, but it is a clean solution, to avoid
> intermingling your local changes with rebase conflicts.
> I still did not manage to write a bash script for this sequence (which  
> would
> not stash without local changes, and which which would not git-stash-pop  
> when
> the pull-rebase has had conflicts)
>
> 2) Local branch
> I developed the grouping feature last week using this approach. It was  
> only a
> few days of work, no need to share before it's finished, but neither  
> ready to
> commit the first parts before the rest was finished.
> Assuming you have local changes and want to continue your work in a local
> branch now:
> git checkout -b myBranch
> <commit, work, commit>
> You have finished and want to commit. Not by a merge: If you have made,  
> say,
> 10 commits, you want to add these 10 commits on top of master, and  
> discard
> your local branch.
> In the meantime, master has received new commits. Get latest master and  
> pull:
> git checkout master
> git pull
> Now, rebase your work on top of master. This rewrites your commits.
> git checkout myBranch
> git rebase master
> Then it's time to add all your commits, one by one, to master:
> git checkout master
> git rebase myBranch
> git push
> Clean up after you:
> git branch -d myBranch
> The effect on the remote repository is a linear string of commits, as if
> developed directly on master. Your local branch has never been public.
>
> 3) Public branch with rebase.
> This concept is very similar to (2): In the end, there will be a linear  
> line
> of commits on top of master, and no branch remain in the remote  
> repository.
> The main difference is that the branch lives in the remote repo, and
> development can be shared. At least when development is finished, the  
> commits
> are rebased, which rewrites history: Afterwards, the branch cannot be  
> pushed.
> Anyone who would have based his work on an intermediate commit will be  
> lost.
> The branch can be force-pushed though, if allowed on the remote side.  
> That
> means social communication is required when rebasing.
> The workflow is described here
> http://community.kde.org/20110213_GitWorkflowAgenda/StevesIdea#Use_case:_Someone_wants_to_work_on_a_feature_that_takes_longer_than_half_a_day_and_should_therefore_be_in_an_archived_branch.
> Note: I dont know if branches are already force-pushable in KDE repos; I
> assume not, and then this does not work!
>
> 4) Stable branch
> Development continues on master, and a stable branch is branched off.
> Backporting of fixed is done using git cherry-pick.
>
> 5) Development branch
> Development on master is incremental, but large, architectural changes  
> are
> done in a branch, possibly breaking everything. Development time is  
> long. The
> branch will be preserved in history for all times. Over time, changes  
> from
> master are merged intermittently. (This is what we did with the
> development/2.0 branch)
>
> Marcel
>
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/