[darcs-users] some darcs comments from Johan Tibell
kowey at darcs.net
Mon Dec 28 18:29:10 UTC 2009
One question which came up: what's the different between staging commits
with an index, and staging with darcs amend-record?
On Sun, Dec 27, 2009 at 14:16:07 +0100, Johan Tibell wrote:
> This does not include changing to the new working directory. Is it
> best practice to create your topic branches inside the directory of
> the main branch as done in this case?
For small projects, I tend to have a single directory in which I dump
all my repositories:
But for larger projects, I tend to have a single directory just for that
(so cd darcs-hacking; darcs get --lazy http://darcs.net review-291)
> Also it doesn't have quite the same effect. When checking out a new
> branch in Git using "git checkout -b" untracked/uncommited files are
> still present in the working directory of the new branch, meaning that
> if you created a new file while working on e.g. the master branch and
> then realized that you want to commit them on a new branch you don't
> have to manually move them. This also means that already compiled
> files in dist/ (created by Cabal) can be more easily shared between
It sounds like a fairly convincing argument that in-repo branches are
useful because a single, shared working directory (across branches) is
Now, the wider context is that YES, there is interest in implementing
in-repo branches <http://bugs.darcs.net/issue555>, but there is some
debate about the right way to do it.
My main worry (personally) is losing the simplicity of Darcs, which I
think is a quality that we should hang to very tenaciously.
I just had a thought on one principle we could adopt that could help
us preserve this simplicity. Johan: since you're an active user of
branches, could you comment on the following idea?
Darcs should never implement 'remote' branches.
Branches should be strictly a personal affair, something a hacker would
use to work on multiple features at the same time, or a maintainer to
keep track of a bunch different patch sets; but NOT for a project that
wants to publish multiple branches (they'd have to do it the old
Perhaps this sort of simplifying principle will help. Basically the
idea is that we should consider making a point of not EVER implementing
(a) copying of branches and (b) pushing to and pulling from branches in
other repos. That branches be tied to a single directory may allow us
to make life more convenient for the most common use cases while keeping
Darcs simple to use and think about.
> > fs runs Fedora Core 3 and has two SATA disks in a software RAID 1 array.
> > I can only assume that when people complain about slow branch creation
> > - they're *really* impatient;
> > - they're using NFS on 100baseT (like me);
> This is on local disk.
Trent: any ideas on what's going on here? Is there some good
reason for this sort of discrepancy if any?
> > - they're not using --lazy for branches;
> Aside: I want all my history locally so I don't use lazy.
Even when branching an already local repo? What's there to lose?
> I remember back when that feature was announce and it didn't make any
> sense to me back then. Would severely increase the variability in
> execution times of different commands? There's lots of research
> showing that high variability is even worse than consistently slow
> operations when it comes to user perceived latency.
I recommend just trying this to see how it feels. So I think what makes
--lazy work well in practice is that in practice, one does not actually
consult the patches that are far back in history very often. If they
do, it causes some fetching but only once. So I don't think this sort
of thing really constitutes high variability:
fast fast fast fast SLOW fast fast fast
I think it would make sense to try it and see how it feels in practice,
see what life is like with some lazy repos. If you're on a plane, you
lose the ability to view the contents of a patch that you don't have,
but is that really such a huge cost compared to the one you pay more
> What about when I'm on a plane?
Well you lose the ability to consult the patches that are far back in
history... if you're on a plane.
> Why assume when you can ask? The research I've seen done at Google
> shows that humans perceive events as being instantaneous if they're
> shorter than about 250ms and that one can measure statistically
> significant difference in behavior for every 100ms slower than 250ms.
> The area of research wasn't VCSs (it was web search) but I feel
> confident that the effects translate. There are also anecdotal
> evidence from Git users describing that they use their system
> differently when certain operations are faster.
I think it's a good goal for the future. For now, we're focused on
fixing the more egregious issues like things taking many seconds or even
minutes that should be faster. If we can knock a lot of these issues
out (eg. implement filecache so that darcs annotate is usably fast,
making darcs get fast over a network, making darcs not keel over and die
if you try to record too large a patch), then we can start to worry
about instantaneous operations.
So I'm agreeing with you here, but I'm just pointing out that we are
working on lots of different ways to make Darcs faster
> >> Johan Tibell writes:
> >>> $ git diff master..integration # All changes taken together to get an
> >>> overview
> >>> $ git diff integration~2..integration~3 # Patch 3 (newest)
> > Isn't the latter equivalent to the simpler "git show integration~3"?
> I use an external diff tool.
To diff across branches in the current setup, you'd just use that
external diff tool without any darcs commands.
To diff across versions, there is now an --index=N-M flag... which
unfortunately is broken at the moment
But once that works again, I think it'd be the same feature.
> >>> Random other things I miss:
> >>> * Being able to easily refer to any patch -- typing a regex the
> >>> matches the commit messages uniquely is a pain. So is counting
> >>> backwards (i.e. --last=54.)
> > What's git's "easy" way to uniquely refer to a patch? Hashes? Darcs
> > has --match 'hash XXX'.
> The hashes in Git are used everywhere so you're likely to have the
> hash available (further up in your terminal screen) when you need it.
> The same cannot be said about Darcs' hashes.
So would a good default be for darcs changes to always print out the
patch-info hash for each patch?
Mon Dec 14 14:37:41 GMT 2009 Ganesh Sittampalam <ganesh at earth.li>
* fill out witnesses.hs
This just adds all modules to the list imported by witnesses.hs either
directly or indirectly, with some imports commented out since the modules
don't work with witnesses yet.
The idea is to make it easier to see what hasn't had witnesses added yet.
Sat Dec 26 20:24:45 GMT 2009 Joachim Breitner <mail at joachim-breitner.de>
* Also import (<>)
Thu Dec 24 11:34:44 GMT 2009 Joachim Breitner <mail at joachim-breitner.de>
* Resolve issue1362: Mention repo name in mail send body
> >>> * Not when typing "darcs help". You want the help text to stay when
> >>> you're looking for command line flags to give to a command! The
> >>> pager makes the help text disappear when you're supposed to type
> >>> the command.
> > I think this is just git setting $LESS to FSR (unless it's already set
> > to something else). The help text "disappears" because your terminal
> > emulator has been configured that way. Try ^A:altscreen off in GNU
> > Screen -- I dunno about other terminals. LESS=F should help if you use
> > less.
> I don't want to change the default behavior of less for all uses. Can
> I have it do this just for darcs?
Maybe DARCS_PAGER will help (environment variables notwithstanding, I do
agree that we need to do something about the pager defaults:
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
More information about the darcs-users