question about git workflow

[Florian Festi]

Christoph Höger wrote:
> Hi there dvcs users,
> 
> I am getting used to using git while working with upstream projects. So
> when I try to make a patch available upstream, I encounter the following
> problem: I want to make small commits during my work but of course send
> the result as a single patch via git format-patch. So what's best:
> 
> 1. clone upstream, create another local branch, work there, and then
> merge that branchs changes via diff?
> 
> 2. use <UNKNOWN_GIT_COMMAND> to merge those commits into a single one?
> 
> 3. do not use intermdiate local commits (bad idea)
> 
> And the final question: When I got to the point of sending one single
> patch and upstream merges it, how can I resync with upstream without
> having to clone again? 

Git is a very powerful tool (set) and there are different ways of doing 
things. Im my experience it is a good idea to keep the fingers off the 
master branch and do everything in local branches (lots of them if 
necessary). I use qgit to visualize them so it is easy to see how they look 
like. After upstream has commited your changes you can either rebase or 
delete your local branch. I try to avoid merges completely and do everything 
with rebases.

Before commiting/submitting patches upstream I typically clean them up using 
rebase -i and even spliting some of them up (git add -i). This creates a 
clean history that allows easier error detection (using git bisect) and 
understanding what the patches are about. This is IMHO one of the main 
benefits of git over most other VCS, but it requires some extra effort and a 
different understanding of what your work is.

Florian