Re: What's in git.git

[Andreas Ericsson <ae@op5.se>]

Junio C Hamano wrote:
> 
> The problem is exactly why you need the plus sign when you fetch,
> i.e. "+pu:pu".  My "pu" rebases.
> 
> Suppose I had this:
> 
>              o--o--o
>             /      "pu"
> 	o--o
>            "master"     
> 
> You do fetch +pu:pu, branch my-pu, and build on top of it:
> 
>                      o--o--o--o--o--o--o
>                     /                  "my-pu"
>              o--o--o
>             /      "pu"
> 	o--o
>            "master"
> 
> I add some to my "master" and rebuild "pu", maybe while adding
> another commit on "pu".  You fetch +pu:pu again:
> 
>                      o--o--o--o--o--o--o
>                     /                  "my-pu"
>              o--o--o        o--o--o--o
>             /              /         "pu" 
> 	o--o--o--o--o--o--o
>                           "master"
> 

But wouldn't rebase detect the commits as being the same, unless you've 
made changes to them? If it doesn't, can we teach it to discard parent 
info and re-hash the commits if they conflict? That should solve most 
such merge-conflicts, really.


> Now, what happens when you merge "pu" into "my-pu"?  The three
> commits I had on my previous "pu" are not part of the history of
> the updated "pu" anymore, but is considered to be part of your
> development trail.  If these had an addition of a file, and if
> your development on top of the previous "pu" modified it, the
> merge would result in:
> 
>  * originally the file did not exist.
>  * "pu" adds it one way.
>  * "my-pu" adds it in another way.
> 
> This requires a hand merge.  What should be done is for me to
> instead of rebasing "pu", merge the updated master to "pu".
> 
>                      o--o--o--o--o--o--o
>                     /                  "my-pu"
>              o--o--o--------*--o
>             /              /   "pu" 
> 	o--o--o--o--o--o--o
>                           "master"
> 
> Then merge between "my-pu" and "pu" become easier.  You do not
> have to worry about the earlier three commits, because the point
> you forked from the previous "pu" becomes the merge base.
> 
> The reason I have not done it that way so far is primarily I am
> lazy and also I do not like to see too many merges in the log.
> Also "pu" tends to have really wacky stuff, so separating out
> only usable bits, excluding wacky ones is slightly easier if I
> rebuild it from scratch.
> 
> The new "next" aka "not too close to bleeding or broken edge"
> branch will be managed like the last picture above, in order to
> make working with it easier to manage.  This is only usable if I
> do not include too bleeding-edge topic branch in it.
> 
> 

Good thinking. You're a marvel at explaining things.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231