Justin Patrin wrote:
On Sun, May 4, 2008 at 5:29 PM, William Uther
<[EMAIL PROTECTED]> wrote:
(Aside: was the recent problem OE had with suspend because suspend
itself didn't work, or rather because people were using older versions
of monotone that didn't respect suspend certs?)
The OE
On Mon, May 05, 2008 at 10:29:08AM +1000, William Uther wrote:
> / \
>/ \
> i a
> | |
> j b
> | |
> k c
>\ /
> \ /
> d
>
> With this setup, if anyone commits a child of k and then tries to
> merge, then they'll end up with the merge doing str
On Sun, May 4, 2008 at 5:29 PM, William Uther
<[EMAIL PROTECTED]> wrote:
>
> (Aside: was the recent problem OE had with suspend because suspend
> itself didn't work, or rather because people were using older versions
> of monotone that didn't respect suspend certs?)
>
The OE developers set up a
On 05/05/2008, at 10:29 AM, William Uther wrote:
On 04/05/2008, at 10:37 PM, Patrick Georgi wrote:
I feel forced in a work flow:
- git-commit --amend is missing
..
- git-rebase -i is missing
These two (at least) change history. Monotone has immutable history,
which is a feature.
(ame
On 04/05/2008, at 10:37 PM, Patrick Georgi wrote:
I feel forced in a work flow:
- git-commit --amend is missing
..
- git-rebase -i is missing
These two (at least) change history. Monotone has immutable history,
which is a feature.
(amend-commit as a shortcut to kill_rev_locally, then c
Bruce Stephens schrieb:
Thomas Keller <[EMAIL PROTECTED]> writes:
[...]
Oh, I'm sure we're all quite happy to accept your patches, detailed
bug reports and are of course willing to look over any feature
branches you may have been prepared!
AFAIK there's no reason to believe that the people c
Bruce Stephens wrote:
- git-fetch will tell me what was updated, which branches
created, mtn doesn't have this.
Again, I could write a wrapper script for that (though an inline
variant would be more efficient, avoiding the second "ls branches",
by looking at the incoming packets): ls branc
Am Sun, 04 May 2008 17:37:41 +0100
schrieb Bruce Stephens <[EMAIL PROTECTED]>:
> Patrick Georgi <[EMAIL PROTECTED]> writes:
>
> [...]
>
> >> I'd have thought note_netsync_revision_received or something would
> >> be OK for that? Maybe one wants a hook that receives all the
> >> revisions in one
Patrick Georgi <[EMAIL PROTECTED]> writes:
> Am Sun, 04 May 2008 15:22:54 +0100
> schrieb Bruce Stephens <[EMAIL PROTECTED]>:
>> [lots of good explanations about git branch names]
> so it would be "mtn-wrapper changes-since-pull server branch", and use
> a complete table of heads x server. okay..
I'm working on implementing a clean way to resolve name conflicts.
The use case is that a file with the same name is added on two
different heads (or branches), and then the heads are merged (or the
branches propagated).
There are two possible resolutions; the files should be "sutured" into
one f
Patrick Georgi <[EMAIL PROTECTED]> writes:
[...]
>> I'd have thought note_netsync_revision_received or something would be
>> OK for that? Maybe one wants a hook that receives all the revisions
>> in one go or something?
> hmm.. initialize a branch list at the beginning, then check each
> incomin
Thomas Keller <[EMAIL PROTECTED]> writes:
[...]
> Oh, I'm sure we're all quite happy to accept your patches, detailed
> bug reports and are of course willing to look over any feature
> branches you may have been prepared!
AFAIK there's no reason to believe that the people complaining have
any in
Am Sun, 04 May 2008 15:22:54 +0100
schrieb Bruce Stephens <[EMAIL PROTECTED]>:
> [lots of good explanations about git branch names]
so it would be "mtn-wrapper changes-since-pull server branch", and use
a complete table of heads x server. okay..
> I'd have thought note_netsync_revision_received or
Stephen Leake <[EMAIL PROTECTED]> writes:
>>> >> I proposed a new process for resolving non-content conflicts; see
>>> >>
>>> >> http://lists.gnu.org/archive/html/monotone-devel/2008-04/msg00084.html
>>> >>
>>> >> Would that help?
>>> >
>>> > It looks like that would help
>>>
>>> good.
Patrick Georgi <[EMAIL PROTECTED]> writes:
> Am Sun, 4 May 2008 08:18:25 + (UTC)
> schrieb Holger Freyther <[EMAIL PROTECTED]>:
>> - git-rev-list origin/qtwebkit.. (to show what I would push now)
>> is missing
> What's origin - the last server you connected, or the default one?
origin is
Christof Petig wrote:
mtn: Zertifikate | Schlüssel | Revisionen
mtn: 76.702 |74 | 25.283
mtn: Bytes rein | Bytes raus | Zertifikate rein | Revisionen rein
mtn: 1,1 M |361,4 k | 560/560 | 136/136
mtn: erfolgreicher Austausch mit localhost
On "all my per
Am Sun, 4 May 2008 08:18:25 + (UTC)
schrieb Holger Freyther <[EMAIL PROTECTED]>:
> - git-rev-list origin/qtwebkit.. (to show what I would push now)
> is missing
What's origin - the last server you connected, or the default one?
It should be possible to track a list of head revisions per s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Thomas Keller schrieb:
> Holger Freyther schrieb:
>> I'm feeling blind with monotone:
>> - git-rev-list origin/qtwebkit.. (to show what I would push now) is
>>missing
>> - gitk is almost instantly working on the OE tree
>> -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus Schiltknecht schrieb:
> Hi,
>
> Christof Petig wrote:
>> I tested Thursday's net.venge.monotone with binary ids and I don't know
>> about cached pipes. But this should be easy to speed up (especially
>> given that, according to Lapo, there is/w
Thomas Keller wrote:
Sorry, but just ranting that "something doesn't work" or "something is
missing" doesn't bring you anywhere if you're working with an Open
Source tool.
Well, don't be too harsh, it's not like we don't accept suggestions as
well, but the fact is: they are two different syst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
mtn: Zertifikate | Schlüssel | Revisionen
mtn: 76.702 |74 | 25.283
mtn: Bytes rein | Bytes raus | Zertifikate rein | Revisionen rein
mtn: 1,1 M |361,4 k | 560/560 | 136/136
mtn: erfolgreicher Austausch mit loc
Holger Freyther schrieb:
I'm feeling blind with monotone:
- git-rev-list origin/qtwebkit.. (to show what I would push now) is
missing
- gitk is almost instantly working on the OE tree
- git-fetch will tell me what was updated, which branches created,
mtn doesn't have
Markus Schiltknecht wrote:
Another thing to keep in mind: instead of trying hard to squeeze out the
last bits of performance from the decoder, it might rather be possible
to avoid en- and decoding steps completely by using a binary roster
format - thus also storing binary hashes.
That's my li
Hi,
Christof Petig wrote:
I tested Thursday's net.venge.monotone with binary ids and I don't know
about cached pipes. But this should be easy to speed up (especially
given that, according to Lapo, there is/was a specialized 40 digit hex
decoder in monotone written by Graydon.
Ah, okay, so that
"Justin Patrin" <[EMAIL PROTECTED]> writes:
> On Sat, May 3, 2008 at 12:23 PM, Stephen Leake
> <[EMAIL PROTECTED]> wrote:
>> "Justin Patrin" <[EMAIL PROTECTED]> writes:
>>
>> > On Sat, May 3, 2008 at 12:26 AM, Stephen Leake
>> > <[EMAIL PROTECTED]> wrote:
>> >> "Justin Patrin" <[EMAIL PROTECTED
Christof Petig wrote:
(especially
given that, according to Lapo, there is/was a specialized 40 digit hex
decoder in monotone written by Graydon.
It was Eric's mail pointing to that 2006 revision actually, but that
should be in mainline even now...
Lapo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus Schiltknecht schrieb:
> Hi,
>
> Christof Petig wrote:
>> just some notes for myself on the performance problems with OE:
>>
>> - - hex_decode is used extensively by roster.cc: parse_marking (and
>> expensive)
>> - - get_roster_version is taking
Justin Patrin gmail.com> writes:
> It looks like the original discussion is here:
> http://projects.linuxtogo.org/pipermail/openembedded-devel/2008-March/004642.html
> I haven't been reading my mail very carefully lately.
>
> The majority of complaints seem to be that "merge is broken". I
> hon
Koen Kooi student.utwente.nl> writes:
> Well, git has this feature:
>
> "An example from man git-push:
> --force
> Usually, the command refuses to update a remote ref that is not an
> ancestor of the local ref used to overwrite it. This flag disables the
> check. This can cause the remote repo
29 matches
Mail list logo
