public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-portage-dev] Handling merge issues (on the case of prefix)
@ 2010-03-26  5:23 Sebastian Pipping
  2010-03-26  5:53 ` Zac Medico
  2010-03-26 17:03 ` Sebastian Pipping
  0 siblings, 2 replies; 3+ messages in thread
From: Sebastian Pipping @ 2010-03-26  5:23 UTC (permalink / raw
  To: gentoo-portage-dev

Hello!


As the prefix branch is not the last case where people may run into
problems with merging due to the conversion from SVN to Git I feel like
writing about it here.


In this mail
============
- The problem
  - Merges in SVN
  - Merges in Git
  - Consequences

- Dealing with it
  - The concept
  - Realization


The problem
===========

Merges in SVN
-------------
In SVN people select what commits are merged from where to where
manually: SVN, merge commits 3 to 10 to branch "prefix" please.  What
has been merge is tracked in the mind of the person merging and in log
messages.


Merges in Git
-------------
In Git there's another place where merges are saved: in the DAG of commits:

  - A commit with several children/successors is a branch point
  - A commit with several parents is a merge point

When merging one branch into another Git runs the DAG up (into the past)
from both commits until it finds a shared merge or branch point: that's
the point up to where both branches were synced last time.  History
after that point is then merged over, nothing before.


Consequences
------------
So Git relies on the existence of merge commits to detect what has been
merged already.  Creating all these merge commits is a tough job for a
conversion tool (like svn2git) as it would have to distinguish between
cases where just a few commist have been cherry-picked over and cases
where all previous commits have made it over.

So the portage Git history does not have merge commits at these points
but plain single-parent commits.


Dealing with it
===============

The concept
-----------
So to not get diffs way bigger than needed when merging what we can do
is we can manually (and permanently) teach Git what we know more about
portage's history.
Let's look the case of the prefix branch.

The current head on prefix has this log message:

  [head on prefix]
  "Merged from trunk -r15842:15843"

Looking a few commits back (using gitg or git log) on branch master I
find this commit:

  [commit f52e83b0982c9c18d96757ab55109d43a9873b3f on master]
  install_qa_check: make sure init.d and conf.d files do not have
    syntax errors in them #310805
  svn path=/main/trunk/; revision=15843

So that's the commit where grobian merged trunk into prefix last time:
perfect.


Realization
-----------
How do we teach Git that all that stuff has been merged already?
By creating a merge commit with two parents:

  1) f52e83b0982c9c18d96757ab55109d43a9873b3f
  2) head on prefix

This is how to do it on the shell

  # Checkout prefix locally
  git checkout -b prefix overlays-gentoo-org/prefix

  # Create merge commit manually (_NOT_ something to do usually)
  MERGE_COMMIT=$(echo \
    'Teach Git that trunk@15843 has been merged into prefix' \
    | git commit-tree 'prefix^{tree}' -p prefix -p
    f52e83b0982c9c18d96757ab55109d43a9873b3f)

  # Inspect result
  echo ${MERGE_COMMIT}

  # Move prefix head forward to include that commit
  git merge ${MERGE_COMMIT}

  # Inspect what we have done visually
  gitg

That's where we leave the land of dirty hacks and Git's so-called
plumbings. We can can continue merging the few remaining commits from
here as usual.

  # Get a feeling for what would be merged
  # Should list ~10 commits (instead of ~8000 without the hack before)
  git cherry -v prefix overlays-gentoo-org/master

  # Merge master into prefix
  git merge overlays-gentoo-org/master  # Fails with conflicts, fine
  git status
  git mergetool
  git commit
  git push overlays-gentoo-org prefix

I hope this mail was helpful to you.



Sebastian




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [gentoo-portage-dev] Handling merge issues (on the case of prefix)
  2010-03-26  5:23 [gentoo-portage-dev] Handling merge issues (on the case of prefix) Sebastian Pipping
@ 2010-03-26  5:53 ` Zac Medico
  2010-03-26 17:03 ` Sebastian Pipping
  1 sibling, 0 replies; 3+ messages in thread
From: Zac Medico @ 2010-03-26  5:53 UTC (permalink / raw
  To: gentoo-portage-dev

Thanks, I've used your procedure to do that to the 2.1.7 branch and
it seems to have worked well (git cherry now gives the expected result):


http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=797fb70107834d0346e5201b7a9aaa5d36978c81
-- 
Thanks,
Zac



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [gentoo-portage-dev] Handling merge issues (on the case of prefix)
  2010-03-26  5:23 [gentoo-portage-dev] Handling merge issues (on the case of prefix) Sebastian Pipping
  2010-03-26  5:53 ` Zac Medico
@ 2010-03-26 17:03 ` Sebastian Pipping
  1 sibling, 0 replies; 3+ messages in thread
From: Sebastian Pipping @ 2010-03-26 17:03 UTC (permalink / raw
  To: gentoo-portage-dev

On 03/26/10 06:23, Sebastian Pipping wrote:
> Consequences
> ------------
> So Git relies on the existence of merge commits to detect what has been
> merged already.  Creating all these merge commits is a tough job for a
> conversion tool (like svn2git) as it would have to distinguish between
> cases where just a few commist have been cherry-picked over and cases
> where all previous commits have made it over.
> 
> So the portage Git history does not have merge commits at these points
> but plain single-parent commits.

I was wondering if this could be something that git-svn can do better
than svn2git: after all what does git-svn do in these 100 minutes taking
longer than svn2git?

So I ran a git-svn conversion again but it seems it does no better:

  # git cherry -v prefix master | wc -l
  7988

So that looks like about the same.



Sebastian



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-03-26 17:04 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-26  5:23 [gentoo-portage-dev] Handling merge issues (on the case of prefix) Sebastian Pipping
2010-03-26  5:53 ` Zac Medico
2010-03-26 17:03 ` Sebastian Pipping

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox