[plt-dev] One e-mail per commit?

On May 17, Michael Sperber wrote:
> Eli Barzilay <eli at barzilay.org> writes:
> 
> > On May 17, Michael Sperber wrote:
> >> Eli Barzilay <eli at barzilay.org> writes:
> >> 
> >> > On May 17, Michael Sperber wrote:
> >> >> Eli Barzilay <eli at barzilay.org> writes:
> >> >> 
> >> >> > You mean that Sam will have his own repository with a different
> >> >> > history where my five commits are squashed into one, and his
> >> >> > own commits are present in more detail (which involve him doing
> >> >> > the 86 commits as usual, then writing a new total commit log
> >> >> > message that would be present in the public repository but not
> >> >> > in his oen)?
> >> >> 
> >> >> Essentially: However, it won't be different in git's identity
> >> >> sense of the word - it will have additional stuff in it, namely
> >> >> the 86 individual commits that the rest of us shouldn't be
> >> >> looking it.  And that new total commit message would actually
> >> >> worthwhile, because we'd see the big picture instead of the
> >> >> itty-bitty details that matter only to Sam.
> >> >> 
> >> >> > If so, then I think that you have some misunderstanding of how
> >> >> > git works.
> >> >> 
> >> >> This is not a question of how git works, it's a question of
> >> >> organizing your workflow.  git is perfectly able to handle this
> >> >> workflow.
> >> >
> >> > I have no idea what you're talking about here.  For the history to
> >> > be the same in git's identity's sense, it must be exactly the same
> >> > history on both repositories -- either all of them present in
> >> > both, or the overall single one in both.
> >> 
> >> Let me re-phrase: The revision graph in the central repository will
> >> be a subgraph of the revision graph in Sam's repository.  All the
> >> patches of the central repository will be in Sam's repository, and
> >> they will have the identity (i.e. same hash) there.
> >
> > Git doesn't keep a history of sha1-ed patches -- it's a history of
> > commits, each pointing to a tree and a parent commit(s).  If we both
> > have the same <sha1>, then `git log <sha1>' in both of our repository
> > is guaranteed to be exactly the same graph, same author, dates, and
> > log messages -- they're all part of the resulting hash.
> 
> Right.  So?  Sam's repository has more <sha1>s than the central
> repository.  This situation comes up not only in the workflow I
> described, but every time Sam pulls from the central repository when he
> still has unpushed changes in his own repository.  (Sorry, Sam, to be on
> your case all the time ...)

He *cannot* have more commits and somehow end up with the same commit
sha1 at the top.  This is why when he has unpushed changes he needs to
rebase (creating new commit objects for the same changes) or merge
(creating one new commit with two parents).  But this is not getting
anywhere at this point, so I'll stop.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!