hanges of libgit.
A fourth option would be to include git sources, but also include a
configure flag that could be used to link with an external libgit. This is
probably the most robust solution, but also the most complex solution (and
thus probably not the best).
--
David Roundy
http://www.darcs.n
ring contents
simultaneously with the change of the code itself. When I replace
get_pseudowavefunction with get_atomic_orbital, I also want to modify
// We call get_pseudowavefunction to get the atomic orbital...
and
printf("Error in get_pseudowavefunction!\n");
--
David Roundy
http://www.d
two parents, B1 and B2:
git:
->B/B2-
/ \
P--> A/A1 -> B/B1---> M
It's a little lame, and if user 2 doesn't do any real work, the git-using
person might be annoyed, but I think it's doable.
--
David Roundy
http://www.darcs.net
-
To unsub
e that as the parent for the root? Would there be any reason
to do so? Just a silly thought...
--
David Roundy
http://www.darcs.net
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
trol system is
more about communication than history (which is why by default, darcs
doesn't "do" history), and grouping changes together is how we express
which changes "go together". Of course, we could still have a grouping at
a higher level, so that a single "cha
oduce the author's stated
intent. Either we need to include that information in one form or another
(and in one location or another), or we've got to simply disallow replaces
(and moves?) when interacting with git.
--
David Roundy
http://www.darcs.net
-
To unsubscribe from this list: send th
SCSI merge exposed two bugs in your merge script:
1) It doesn't like a completely new directory (the misc tree contains a
new drivers/scsi/lpfc)
2) the merge testing logic is wrong. You only want to exit 1 if the
merge fails.
--
David Roundy
http://www.darcs.net
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 18, 2005 at 08:38:25AM -0700, Linus Torvalds wrote:
> On Mon, 18 Apr 2005, David Roundy wrote:
> > In particular, it would make life (that is, life interacting back
> > and forth with git) easier if we were to embed darcs patches in their
> > entirety in
in git. Instead, we could just
commute until the mergers disappear (which might be a bit scary), and then
store *that* in git. On the other hand, if this is to inefficient, and if
we store actual darcs patches in git, then we wouldn't perhaps need to
worry about mergers as a special case.
> Whether we end up with a useful implementation of Darcs/git or not,
> this will result in a more modular Darcs, and hence one that will be
> easier to optimise.
>
> What do you think?
Err, I think I've answered that one... :)
--
David Roundy
http://www.darcs.net
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Apr 16, 2005 at 03:43:02PM -0700, Linus Torvalds wrote:
> On Sat, 16 Apr 2005, David Roundy wrote:
> > 1) Would this actually be a good idea? It seems good to me, but there may
> > be other considerations that I haven't thought of.
>
> I really don't know h
f a darcs person submitted patches?
4) Would there be interest in creating a libgit? I've been imagining taking
git source files and including them directly in darcs' code, but in the
long run it would be easier if there were a standard git API we could use.
I guess that's about a
11 matches
Mail list logo
