Aaron Mulder on 20 Dec 2018 18:24:00 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Git: net time gain or loss?


On Thu, Dec 20, 2018 at 8:23 PM JP Vossen <jp@jpsdomain.org> wrote:
> I really, REALLY hate the digest thing!  You can't tell by looking at
> two of them which is old and which is new, and THAT leads to all kinds
> of contortions in the interface to hack-around that problem.

It doesn't seem like incrementing numeric IDs is workable for the
distributed model.  I'd have my set of numbers in my local repo, you'd
have your set of numbers in yours, and then when we both pushed to the
remote repo, it would be a conflicting mess.

It may be that they could cut the confusion a lot by putting the
date/time or UNIX timestamp in front and only relying on the digest if
the date/time conflicts: 20181220211009[DIGEST], perhaps in GMT to
avoid time zone issues, but it's still not bulletproof because what if
we have differing system clocks?  It would be more of a hint than a
definite ordering.  And would break on rebase.  And there would
potentially be a lot more to type to get to the distinguishing part
(for several commits on the same day).  I can't say it would be any
better, really.

> I can't talk about rebase, because I have to admit that's one Git aspect
> that I do not fully understand and which seems like it's nothing but
> razor blades to me.

Doesn't that also come with being distributed?  If we both have local
commits on the same branch and you push to remote first, how are we
going to get my code onto the remote?  If it just takes my push, then
we end up with a mix of code on remote that nobody's actually seen
before, which may or may not actually compile/work.  So I sort of have
to merge your changes and review before I can push mine.

But those merge commits are dang ugly, and rebase seems to be a clever
option to avoid that... granted one that can be a big headache to
understand and adjusts the history a bit and could be completely
unnecessary if not for the distributed nature of the thing.

How does Hg or Bzr handle this kind of thing (multiple developers
pushing local commits on the same branch to remote) better?

Thanks,
      Aaron

P.S. I also use Git because "everybody does" and because of GitHub,
though I was never that terribly unhappy with SVN.
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug