Charlie Li on 20 Dec 2018 18:42:34 -0800


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

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


On 20/12/2018 21:23, Aaron Mulder wrote:
> On Thu, Dec 20, 2018 at 8:23 PM JP Vossen 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.
> 
Indeed not. Even in mercurial the revision hashes are definitive, while
the linear revision numbers are local to each repository and are only
there for convenience purposes.
>> 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.
> 
Mercurial does not allow history rewriting in any form by default. You
have to explicitly enable extensions (most if not all come with
mercurial itself) to do that; rebase counts as history rewriting in this
case. [And rebase in mercurial is really implemented as a series of
revision grafting (cherry-picking) and stripping, both of which are
"dangerous" history rewriting operations.]
> How does Hg or Bzr handle this kind of thing (multiple developers
> pushing local commits on the same branch to remote) better?
> 
Mercurial has the concept of multiple heads, which are just revisions
without descendants. In this case, each developer committing will have
created their own head, which all share a common parent.

Branches in mercurial are similar to subversion or CVS branches, not git
branches. The aforementioned git branch near-equivalent in mercurial are
bookmarks, which are essentially mutable tags that follow your latest
commit so long as you've activated said bookmark. Bookmarking and
multiple heads go rather hand-in-hand; you can have a head without a
bookmark, it won't get garbage collected like git does, but you may have
a hard time finding it when you haven't activated it in a while and
pushed to other heads in the meantime.

-- 
Charlie "ENOIDEA" Li

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)

Attachment: signature.asc
Description: OpenPGP digital signature

___________________________________________________________________________
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