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