From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21279 invoked by alias); 15 Oct 2009 12:42:41 -0000 Received: (qmail 21268 invoked by uid 22791); 15 Oct 2009 12:42:40 -0000 X-SWARE-Spam-Status: No, hits=-0.2 required=5.0 tests=AWL,BAYES_00,RCVD_NUMERIC_HELO,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Oct 2009 12:42:35 +0000 Received: from list by lo.gmane.org with local (Exim 4.50) id 1MyPf5-00077w-Vh for ecos-discuss@sources.redhat.com; Thu, 15 Oct 2009 14:42:31 +0200 Received: from 89.175.180.246 ([89.175.180.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Oct 2009 14:42:31 +0200 Received: from osv by 89.175.180.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Oct 2009 14:42:31 +0200 To: ecos-discuss@sources.redhat.com From: Sergei Organov Date: Thu, 15 Oct 2009 12:42:00 -0000 Message-ID: References: <4AD5D020.8050207@ecoscentric.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Re: Tracking eCos as a hg/git submodule X-SW-Source: 2009-10/txt/msg00098.txt.bz2 Alex Schuilenburg writes: [...] > As someone pushing for git, maybe you can give me an answer on this > since I have not yet found a git equivalent. As yet another git proponent, I'll try to answer this. > Does git allow changesets to follow copied files? I don't think it does, but neither does Mercurial, see below. > i.e. if you copy file a to file b, and then modify b, but later > someone finds a bug in a and fixes it, does git propogate the fix > automatically to b? hg does this and IMHO it is a very useful feature > since many device drivers and BSPs in ecos are clones of others. It > would cover not only bugs, but changes in APIs and suchlike which > means the risk of conflict would be small. So for example if a > template device driver or API were provided in hg, updates to the > template would be propogated automatically to copies making major API > changes a lot easier. It seems you've missed the point of "hg copy". (Caveat: I didn't use it, it's just how I understand it from documentation.) It's not a way to permanently automatically propagate changes made to a file to a (set of) other file(s). A change will propagate to the copy only on the first merge (never on commit) and then propagation will stop. Here are quotes taken from here: "First of all, remember that this propagation only happens when you merge. So if you hg copy a file, and subsequently modify the original file during the normal course of your work, nothing will happen." "Once your change history has a record that the copy and subsequent merge occurred, there's usually no further need to propagate changes from the original file to the copied file, and that's why Mercurial only propagates changes across copies at the first merge, and not afterwards." Based on the above, as soon as public repository has "the copy" and a cloned repository see it, a change won't propagate anymore even on merges. The nice thing about "hg copy" is that "hg log" will be able to show history back including the history of origin of the copy. And yes, "git log" will also learn this soon (if not already, as I've already seen a patch). However, git doesn't have "git copy" as it auto-detects the copies. Yes, it will be able to figure them out even if you just applied a raw patch to you working tree using 'patch' utility and committed the result ;-) (this is a note to the question of what system is better suited for patch-based workflows). > FAOD, I am trying to track down a genuine set of useful technical > differences between git and hg to help the maintainers make their mind > up. For example, git octopus merges have no current equivalent in hg, > though somehow I don't see that git super-power user feature will have > much, if any, use in eCos. However, changeset tracking copies of files > IMHO is very useful. [Un]fortunately, there is no such thing in Mercurial either, see above. "hg copy" seems to be useless for this purpose and is at the same category of usefulness as git octopus merges. [BTW, do you really mean you'd like a commit to be able to change a lot of files when you did modification to only one? I seriously doubt it's a good idea.] On the other hand, for example, "git blame" has an ability to automatically detect and follow copied and moved pieces of code without any additional steps taken at commit time. You see, power becomes visible in deep details. Does Hg have 'blame'? Yes, it does, but that doesn't mean it is as powerful as git's. The same is with named branches inside repository. Does Hg have them? Yes, it does, but it is rather recent addition, while git was born with this, so I suspect gits' support for such branches is superior. Such things makes comparisons of the tools even more difficult (for example, it could be the case that Hg already has copy/move detection I'm not aware of). Another thing is tagging. Both have tagging, but it's implemented very differently. Me personally likes git's idea of tags more. Yet another thing is copy/rename tracking/detection and merges propagation over them. Its deep subtle details that actually make difference in this field. > The other difference I have found is that git repos tend to grow in size > and become inefficient if left unattended for long periods and require > packing, while hg repos dont. Well, git manages Linux source trees just fine, you know. eCos is very small compared to that. But even if git repos tend to grow indeed, a cron job on public repositories should do the trick, I think. -- Sergei. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss