[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: question about git workflow

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]