Re: [fossil-users] why merge does not prompt for commit?
Would you trust a merge algorithm that you software is correct post-merge ? Even if there are no merge conflicts there is no way to know whether the result is correct :) Stanislav Paskalev On Wed, Aug 26, 2015 at 9:28 AM, Luca Ferrari fluca1...@infinito.it wrote: Hi all, this could sound trivial, but why the merge (especially with --integrate) does not prompt immediately for a commit? What is the rationale of having merge and commit as separate actions when closing branches? The only one that comes into my mind is for aborting, is that correct? Thanks, Luca ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why merge does not prompt for commit?
On Wed, Aug 26, 2015 at 8:28 AM, Luca Ferrari fluca1...@infinito.it wrote: Hi all, this could sound trivial, but why the merge (especially with --integrate) does not prompt immediately for a commit? What is the rationale of having merge and commit as separate actions when closing branches? The only one that comes into my mind is for aborting, is that correct? Committing without first checking whether the commit was _semantically_ successful is _just plain wrong_. git does it that way, but that is a huge flaw in its thinking (IMHO). A successful merge only means that the SCM was capable of merging changes without _apparent_ errors (meaning only no overlapping changes), but the developer must first compile/test the changes before committing it to ensure that the merge is semantically correct. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why merge does not prompt for commit?
On 26 August 2015 at 04:27, Luca Ferrari fluca1...@infinito.it wrote:
Correct!
Shame on me.
Not shame, at all! Some of the reasons for things are useful to think
about, and because a popular system (e.g. GIT) does it a particular way can
make us think it is the right way without thinking carefully. I didn't
know GIT did this, which makes it another strike against it, from my
perspective. For example, if you had a C (for a common example):
void foo(someRec *x) {
x.a=1;
x.b=2;
x.c=3;
}
and 2 developers realized that x.count needed to be incremented every time
foo was called, developer A adds x.count++; as the first statement and
developer B does the same thing as the *last* statement. Once merged and
committed, foo will increment count by *2*. If after the merge the
developers had run their test suite, they would detect the trivial error
and fix it.
../Dave
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why merge does not prompt for commit?
On Wed, Aug 26, 2015 at 9:00 AM, Stephan Beal sgb...@googlemail.com wrote: Committing without first checking whether the commit was _semantically_ successful is _just plain wrong_. git does it that way, but that is a huge flaw in its thinking (IMHO). A successful merge only means that the SCM was capable of merging changes without _apparent_ errors (meaning only no overlapping changes), but the developer must first compile/test the changes before committing it to ensure that the merge is semantically correct. Correct! Shame on me. Thanks. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
