On 01/12/2010 04:19 PM, Bill Peck wrote:
On 01/12/2010 10:16 AM, Marian Csontos wrote:
> On 01/12/2010 03:11 PM, Bill Peck wrote:
>> On 01/12/2010 04:21 AM, Marian Csontos wrote:
>>> On 01/11/2010 09:18 PM, Bill Peck wrote:
>>>> Hello Everyone,
>>>>
>>>> FYI - Just to keep things clean I've been deleting RFE and bugfix
>>>> branches after merging them into master. Obviously I won't delete
>>>> any
>>>> stable branches (we only have master right now).
>>> If anyone would like to keep branch's history, it is possible to
>>> use rebase instead of merge, just do:
>>> git pull --merge
> ^^^^^
> This should be
> git pull --rebase
> of course.
>
>>>
>> Can you explain in more detail how this would work and what the
>> differences are?
>>
>> I was told you should *NOT* use rebase if you are sharing your
>> repo. In fact, I thought rebase removed history.
> Partially correct. Before publishing changes, you can do pretty much
> anything including rewriting history.
> It is the history on the server which counts.
>
> You can run
> git pull --rebase
> [ which applies changes between origin..HEAD on top of branch ]
> and, after solving any conflicts, run
> git push
> This way, one will get rid of the branch as well as keep all the
> history.
> See
> man git-rebase
> for details.
>
> <Advertising-message>
> Sometimes it is undesirable to keep history as is, and
> git rebase -i
> allows you to split/join/reorder commits before pushing them.
> I love it.
>
I'm pretty sure this only works if you are working on a branch by
yourself! If you do this while sharing with others git doesn't have
the info needed to resolve conflicts! I think this is dangerous.
Of course it is!
And people do like dangerous things! ;-)
RULE1:
One should never do a rebase of shared branch anyone might have pulled from.
One thus always pulls from upstream to merge changes into such a branch.
But, every rule has an exception, and may be following is one:
EXCEPTION1:
In theory, a "closed" branch (or more precisley the branch to be merged
upstream and deleted), might be a good candidate for rebase.
I have done a little homework, and it might work, if we wanted to keep
more-linear history.
May be not worth all the effort, but I wanted to learn more about git,
and now I have to. :-)
Let's have a development branch DevBranch and target branch Master,
then
git checkout DevBranch
git checkout -b TempRebaseBranch
git rebase Master
will create new private branch TempRebaseBranch, containing all changes
from DevBranch, but based on Master, while DevBranch will not be affected.
-- Marian