Brent Goodrick <bgoodr@xxxxxxxxx> writes:
> So, here is what I think happened in my repo:
>
> 1. A while ago, I made some changes and began testing them out.
> 2. I committed the change into the first commit (see
> e802880bb89524b1f70132f1ca0716624788db3f below)
> 3. Unfortunately, I then stumbled across the coding guidelines, and
> then discovered that my if statements had too many curly braces, and
> fixed that with another commit (but I doubt that is the problem here)
> 4. I did a git pull origin and found a conflict in a file I had
> changed in the first commit above into cache.h (I had inserted a line
> right where someone else had inserted a line). I probably should have
> stopped right then and there and not gone ahead with the merge, but do
> something different (but if so, then what should I have done instead?)
> :)
Your work is about adding this new feature. Use a topic branch.
Now what is that topic branch is for? Yes, it is about adding this new
feature, and nothing else. Don't pull other people's changes made on my
tree into it. That will make your topic branch "one new feature and
everything else" and useless as a topic branch.
What would make your life easier would be:
$ git pull ;# to get up to date with me on your master branch
$ git checkout -b bg/no-progress origin/master
... work on e802880 ...
... test it ...
$ git commit ;# record that on bg/no-progress topic
$ git checkout master
$ git merge bg/no-progress
... test the result of the merge ...
$ git checkout bg/no-progress
... work on style fix ...
... test it ...
$ git commit ;# again record it on bg/no-progress topic
$ git checkout master
$ git merge bg/no-progress
... test the result of the merge ...
$ git pull ;# to get up to date with me
... resolve conflicts ...
Then after you are convinced that everything on bg/no-progress is worthy
of sending to the list [*A*], but its tip is stale because things have
progressed on my end, you can do this:
$ git checkout bg/no-progress
$ git rebase origin/master ;# and rebase to the upstream
which may conflict again (but that would be the same conflict you saw with
your "git pull" from me, and rerere may remember it).
Review and test the result and then:
$ git format-patch origin/master
There can be variants in the last few steps. For example, your commits on
bg/no-progress may be full of "Oops, this is to fix my own mistake made in
earlier commits since I forked from the upstream". You would not want to
have them in your submission (instead, you would want to pretend as if you
never made these mistakes in the first place). For that, you may want to
do, after you feel the tip of bg/no-progress is in a good shape at point
*A* above:
$ git checkout bg/no-progress
$ git rebase -i origin/master ;# and rebase to the upstream
and reorder, squash, and fix them.
Also you may feel that at point [*A*] what you have is very precious and
you would not want yourself breaking it by the final rebase (which is a
very reasonable thing to feel). In such a case, the final rewrite could
be:
$ git checkout bg/no-progress^0
$ git rebase -i origin/master ;# and rebase to the upstream
... test and review the result.
... convince yourself it is indeed better than
... what you earlier thought to be "very precious".
... and then finally
$ git branch -f bg/no-progress
$ git format-patch origin/master ;# send this
And to finish it off, you may do:
$ git checkout master
$ git merge --ours bg/no-progress
The above is a suggestion based on a design to allow you keep sticking to
your merge based workflow as much as possible, but you could instead
choose to keep rebasing. I have some observations at the end of
http://gitster.livejournal.com/24080.html
comparing the merge based workflow and the rebase based one.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
