* DVCS workflow and bisect
@ 2010-01-21 16:33 Teemu Likonen
2010-01-21 18:43 ` Óscar Fuentes
0 siblings, 1 reply; 3+ messages in thread
From: Teemu Likonen @ 2010-01-21 16:33 UTC (permalink / raw)
To: emacs-devel
May I voice an opinion about working with DVCS? I'm an Emacs user, not
developer, so feel free to ignore my comment. :-) Anyway, I just noticed
a problem in the DVCS history which makes diffs more difficult to read.
I'll visualize my point with "git log --graph --oneline":
* d5836ff * lisp/dired-aux.el (dired-hide-all): [...]
* a633481 * lisp/dired-aux.el (dired-hide-all): [...]
* f8314a5 Fix ccl encoding of unibyte source.
|\
| * e81c42c from trunk
| |\
| |/
|/|
* | fff9e27 Remove file that only works with CVS, [...]
* | 62b5494 (tab-always-indent): Fix custom-type.
| * 21287dd Fix ccl encoding of unibyte source.
| |\
| |/
|/|
* | 36d899a Redate and reposition log entry.
* | 02fcc7e Fix bug#5395: typing '#' in an empty C buffer [...]
(The left-most vertical line is the trunk. Asterisks [*] are commits.)
We can see that commit 21287dd [1] fixes some ccl encoding issues and at
the same time it merges stuff from the trunk. That results in a huge
diff from which is difficult to find the actual "ccl encoding" fix. See
$ bzr diff -c revid:handa@m17n.org-20100120023352-5323ovgsrok9nr72
in the Bazaar repo. The "ccl encoding" fix can be found by explicitly
asking the other parent --
$ bzr diff -r revid:acm@muc.de-20100119222724-07lwniug0azx5qu8..revid:handa@m17n.org-20100120023352-5323ovgsrok9nr72
-- but that's more difficult. Also, the version control history will be
difficult to bisect if that change introduced a bug.
My point is not to say that the author of the commit did any serious
damage or anything. I'm just suggesting that merging stuff and making
other changes should be separate commits.
---------------
1. In Bazaar: revid:handa@m17n.org-20100120023352-5323ovgsrok9nr72
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: DVCS workflow and bisect
2010-01-21 16:33 DVCS workflow and bisect Teemu Likonen
@ 2010-01-21 18:43 ` Óscar Fuentes
2010-01-22 4:26 ` Stephen J. Turnbull
0 siblings, 1 reply; 3+ messages in thread
From: Óscar Fuentes @ 2010-01-21 18:43 UTC (permalink / raw)
To: emacs-devel
Teemu Likonen <tlikonen@iki.fi> writes:
[snip]
> My point is not to say that the author of the commit did any serious
> damage or anything. I'm just suggesting that merging stuff and making
> other changes should be separate commits.
Thanks for pointing this out.
This scenario is what Stephen was trying to avoid when he wrote the
documentation for the distributed worflow.
Please, guys, don't use any undocumented workflow unless you really
*know* what you are doing.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: DVCS workflow and bisect
2010-01-21 18:43 ` Óscar Fuentes
@ 2010-01-22 4:26 ` Stephen J. Turnbull
0 siblings, 0 replies; 3+ messages in thread
From: Stephen J. Turnbull @ 2010-01-22 4:26 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
Óscar Fuentes writes:
> This scenario is what Stephen was trying to avoid when he wrote the
> documentation for the distributed worflow.
[[ Please, Karl wrote it (IIUC, that was basically adapted from docs
on bazaar.canonical.com). I contributed some changes, but mostly
simply allowed the curmudgeon in me to come out in discussion. ;-) ]]
Figuring out ways to conveniently trace parentage, either in vc or in
bzr itself, would be a real contribution, I think.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-01-22 4:26 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-21 16:33 DVCS workflow and bisect Teemu Likonen
2010-01-21 18:43 ` Óscar Fuentes
2010-01-22 4:26 ` Stephen J. Turnbull
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).