corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <pmke...@apache.org>
Subject Re: [6/6] incubator-corinthia git commit: Don't store bin/lib/include dirs in repository
Date Wed, 31 Dec 2014 07:37:35 GMT
> On 31 Dec 2014, at 2:11 pm, jan i <jani@apache.org> wrote:
> 
> I am not sure I understand the difference between a normal merge and
> --squash, but if you tell me it does the job then it is fine with me.

Normal merges preserve history (links to other commits), squash doesn’t.

> I like to think of "master" having all details, and "stable" being an index
> over points where we potentially could do a release. I do agree that the
> connection is important, so maybe the commit in stable should always
> contain the GIT Id of HEAD.
> 
> Having all detail in master makes the 2 branches historical identical,
> meaning finding a historical stable point becomes complicated.
> 
> I would really prefer a "clean" stable, provided we can have a simple
> connection to "master" using e.g. GIT commit Id.
> We have unique chance to make it right, not like other projects who have a
> long version history ..... but it is important that we agree on the output
> (less the method, for me at least).

Actually I think I remember us discussing this in budapest. The idea was that every point
in stable would be truly “stable”, but would be a merge from master. So the graph would
look like this (you’ll need to view this in a monospaced font), with the top * on each branch
being the head of that branch:

Master          Stable

   *
   |
   *--------------*
   |              |
   *              |
   |              |
   *              |
   |              |
   *--------------*
   |              |
   *              |
   |              |
   *--------------*

This way, given a commit on stable, we can trace back to see the full detail of all history
which has contributed to that point, including the links back to previous stable points as
well as links to some potentially unstable points in master.

With this approach, we should make sure that the first parent of every commit on stable is
the previous commit on the stable branch. This would be achieved by doing the following:

git checkout stable
git merge master

Then if you want to get a list of *only* the truly stable points, you can do the following:

git log —first-parent stable

And for a complete history like above:

git log —graph stable

or:

git log --oneline --graph master

—
Dr Peter M. Kelly
pmkelly@apache.org

PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message