Paul Jackson <[EMAIL PROTECTED]> wrote:
>> "merge" does a better job than "diff3" since it can resolve the
>
> The merge command I know of is part of Tichy's RCS tools,
> and calls diff3, and has no inherent superior abilities.
You are right, I missed some diff3 options. It looks like "diff3 -mE"
Paul Jackson [EMAIL PROTECTED] wrote:
merge does a better job than diff3 since it can resolve the
The merge command I know of is part of Tichy's RCS tools,
and calls diff3, and has no inherent superior abilities.
You are right, I missed some diff3 options. It looks like diff3 -mE
generates
> "merge" does a better job than "diff3" since it can resolve the
The merge command I know of is part of Tichy's RCS tools,
and calls diff3, and has no inherent superior abilities.
Is this the merge command you have in mind here?
--
I won't rest till it's the best ...
merge does a better job than diff3 since it can resolve the
The merge command I know of is part of Tichy's RCS tools,
and calls diff3, and has no inherent superior abilities.
Is this the merge command you have in mind here?
--
I won't rest till it's the best ...
Followup to: <[EMAIL PROTECTED]>
By author:Linus Torvalds <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Mon, 11 Apr 2005, Greg KH wrote:
> >
> > I have a feeling that the kernel.org mirror system is just going to
> > _love_ us using it to store temporary git trees :)
>
> I
Followup to: [EMAIL PROTECTED]
By author:Linus Torvalds [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
On Mon, 11 Apr 2005, Greg KH wrote:
I have a feeling that the kernel.org mirror system is just going to
_love_ us using it to store temporary git trees :)
I don't think
On Tue, 12 Apr 2005, Adam J. Richter wrote:
> On 2005-04-11, Daniel Barkalow wrote:
> >If merge took trees instead of single files, and had some way of detecting
> >renames (or it got additional information about the differences between
> >files), would that give BK-quality performance? Or does
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> So anything that got modified in just one tree obviously merges to that
> version. Any file that got modified in two trees will end up just being
> passed to the "merge" program. See "man merge" and "man diff3". The merger
> gets to fix up any
On Mon, 11 Apr 2005, Daniel Barkalow wrote:
> If merge took trees instead of single files, and had some way of detecting
> renames (or it got additional information about the differences between
> files), would that give BK-quality performance? Or does BK also support
I wrote a script to do
On Mon, 2005-04-11 at 16:31 -0500, James Bottomley wrote:
> On Mon, 2005-04-11 at 14:26 -0700, Linus Torvalds wrote:
> > I don't think kernel.org mirrors the private home directories, so it you
> > do _temporary_ trees, just make them readable in your private home
> > directory rather than in
On Mon, 2005-04-11 at 16:31 -0500, James Bottomley wrote:
On Mon, 2005-04-11 at 14:26 -0700, Linus Torvalds wrote:
I don't think kernel.org mirrors the private home directories, so it you
do _temporary_ trees, just make them readable in your private home
directory rather than in
On Mon, 11 Apr 2005, Daniel Barkalow wrote:
If merge took trees instead of single files, and had some way of detecting
renames (or it got additional information about the differences between
files), would that give BK-quality performance? Or does BK also support
I wrote a script to do merges
Linus Torvalds [EMAIL PROTECTED] wrote:
So anything that got modified in just one tree obviously merges to that
version. Any file that got modified in two trees will end up just being
passed to the merge program. See man merge and man diff3. The merger
gets to fix up any conflicts by hand.
On Tue, 12 Apr 2005, Adam J. Richter wrote:
On 2005-04-11, Daniel Barkalow wrote:
If merge took trees instead of single files, and had some way of detecting
renames (or it got additional information about the differences between
files), would that give BK-quality performance? Or does BK also
On 2005-04-11, Daniel Barkalow wrote:
>If merge took trees instead of single files, and had some way of detecting
>renames (or it got additional information about the differences between
>files), would that give BK-quality performance? Or does BK also support
>cases like:
>
>orig ---> first --->
On Sun, 10 Apr 2005, Linus Torvalds wrote:
> On Mon, 11 Apr 2005, Jeff Garzik wrote:
> >
> > > But I hope that I can get non-conflicting merges done fairly soon, and
> > > maybe I can con James or Jeff or somebody to try out GIT then...
> >
> > I don't mind being a guinea pig as long as
On Mon, 2005-04-11 at 14:26 -0700, Linus Torvalds wrote:
> I don't think kernel.org mirrors the private home directories, so it you
> do _temporary_ trees, just make them readable in your private home
> directory rather than in /pub/linux/kernel/people. For people with
> kernel.org accounts, we
On Mon, 11 Apr 2005, Greg KH wrote:
>
> I have a feeling that the kernel.org mirror system is just going to
> _love_ us using it to store temporary git trees :)
I don't think kernel.org mirrors the private home directories, so it you
do _temporary_ trees, just make them readable in your
On Sun, Apr 10, 2005 at 10:25:22PM -0500, James Bottomley wrote:
> On Sun, 2005-04-10 at 16:26 -0700, Linus Torvalds wrote:
> > On Mon, 11 Apr 2005, Benjamin Herrenschmidt wrote:
> > > If yes, then I would appreciate if you could either keep the same list,
> > > or if you want to change the list
On Monday 11 April 2005 08:51, Chris Mason wrote:
> rej -M skips the merge program, so rej -a -M will give you something like
> this:
>
> coffee:/local/linux.p # rej -a -M drivers/ide/ide.c.rej
> drivers/ide/ide.c: 1 matched, 0 conflicts remain
>
> But I would want to go over the bit that
On 2005-04-11 Linus Torvalds wrote:
>Then the bad news: the merge algorithm is going to suck. It's going to be
>just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
>understanding of renames etc. I'll try to find the best parent to base the
>merge off of, although early
On Monday 11 April 2005 03:38, Ingo Molnar wrote:
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > So anything that got modified in just one tree obviously merges to
> > that version. Any file that got modified in two trees will end up just
> > being passed to the "merge" program. See "man merge"
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Then the bad news: the merge algorithm is going to suck. It's going to
> be just plain 3-way merge, the same RCS/CVS thing you've seen before.
> With no understanding of renames etc. I'll try to find the best parent
> to base the merge off of,
On Mon, 2005-04-11 at 09:10 +1000, Benjamin Herrenschmidt wrote:
> Do you intend to continue posting "commited" patches to a mailing list
> like bk scripts did to [EMAIL PROTECTED] ? As I said a while ago, I
> find this very useful, especially with the actual patch included in the
> commit message
On Sun, 10 Apr 2005, Linus Torvalds wrote:
> Then the bad news: the merge algorithm is going to suck. It's going to be
> just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
Actually 3-way merge is not that bad. It's definitely better than ClearCase's
merge (I always fall
On Sun, Apr 10, 2005 at 11:15:20PM -0700, Linus Torvalds wrote:
> On Mon, 11 Apr 2005, Jeff Garzik wrote:
> > > But I hope that I can get non-conflicting merges done fairly soon, and
> > > maybe I can con James or Jeff or somebody to try out GIT then...
> >
> > I don't mind being a guinea pig as
On Mon, 11 Apr 2005, Jeff Garzik wrote:
>
> > But I hope that I can get non-conflicting merges done fairly soon, and
> > maybe I can con James or Jeff or somebody to try out GIT then...
>
> I don't mind being a guinea pig as long as someone else does the hard
> work of finding a new way to
On Mon, 11 Apr 2005, Jeff Garzik wrote:
But I hope that I can get non-conflicting merges done fairly soon, and
maybe I can con James or Jeff or somebody to try out GIT then...
I don't mind being a guinea pig as long as someone else does the hard
work of finding a new way to merge :)
On Sun, Apr 10, 2005 at 11:15:20PM -0700, Linus Torvalds wrote:
On Mon, 11 Apr 2005, Jeff Garzik wrote:
But I hope that I can get non-conflicting merges done fairly soon, and
maybe I can con James or Jeff or somebody to try out GIT then...
I don't mind being a guinea pig as long as
On Sun, 10 Apr 2005, Linus Torvalds wrote:
Then the bad news: the merge algorithm is going to suck. It's going to be
just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
Actually 3-way merge is not that bad. It's definitely better than ClearCase's
merge (I always fall back
On Mon, 2005-04-11 at 09:10 +1000, Benjamin Herrenschmidt wrote:
Do you intend to continue posting commited patches to a mailing list
like bk scripts did to [EMAIL PROTECTED] ? As I said a while ago, I
find this very useful, especially with the actual patch included in the
commit message
* Linus Torvalds [EMAIL PROTECTED] wrote:
Then the bad news: the merge algorithm is going to suck. It's going to
be just plain 3-way merge, the same RCS/CVS thing you've seen before.
With no understanding of renames etc. I'll try to find the best parent
to base the merge off of, although
On Monday 11 April 2005 03:38, Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
So anything that got modified in just one tree obviously merges to
that version. Any file that got modified in two trees will end up just
being passed to the merge program. See man merge and man
On 2005-04-11 Linus Torvalds wrote:
Then the bad news: the merge algorithm is going to suck. It's going to be
just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
understanding of renames etc. I'll try to find the best parent to base the
merge off of, although early testers
On Monday 11 April 2005 08:51, Chris Mason wrote:
rej -M skips the merge program, so rej -a -M will give you something like
this:
coffee:/local/linux.p # rej -a -M drivers/ide/ide.c.rej
drivers/ide/ide.c: 1 matched, 0 conflicts remain
But I would want to go over the bit that
On Sun, Apr 10, 2005 at 10:25:22PM -0500, James Bottomley wrote:
On Sun, 2005-04-10 at 16:26 -0700, Linus Torvalds wrote:
On Mon, 11 Apr 2005, Benjamin Herrenschmidt wrote:
If yes, then I would appreciate if you could either keep the same list,
or if you want to change the list name, keep
On Mon, 11 Apr 2005, Greg KH wrote:
I have a feeling that the kernel.org mirror system is just going to
_love_ us using it to store temporary git trees :)
I don't think kernel.org mirrors the private home directories, so it you
do _temporary_ trees, just make them readable in your private
On Mon, 2005-04-11 at 14:26 -0700, Linus Torvalds wrote:
I don't think kernel.org mirrors the private home directories, so it you
do _temporary_ trees, just make them readable in your private home
directory rather than in /pub/linux/kernel/people. For people with
kernel.org accounts, we can
On Sun, 10 Apr 2005, Linus Torvalds wrote:
On Mon, 11 Apr 2005, Jeff Garzik wrote:
But I hope that I can get non-conflicting merges done fairly soon, and
maybe I can con James or Jeff or somebody to try out GIT then...
I don't mind being a guinea pig as long as someone else does
On 2005-04-11, Daniel Barkalow wrote:
If merge took trees instead of single files, and had some way of detecting
renames (or it got additional information about the differences between
files), would that give BK-quality performance? Or does BK also support
cases like:
orig --- first ---
Linus Torvalds wrote:
On Mon, 11 Apr 2005, Benjamin Herrenschmidt wrote:
If yes, then I would appreciate if you could either keep the same list,
or if you want to change the list name, keep the subscriber list so
those of us who actually archive it don't miss anything ;)
I didn't even set up the
On Sun, 2005-04-10 at 16:26 -0700, Linus Torvalds wrote:
> On Mon, 11 Apr 2005, Benjamin Herrenschmidt wrote:
> > If yes, then I would appreciate if you could either keep the same list,
> > or if you want to change the list name, keep the subscriber list so
> > those of us who actually archive it
On Mon, 11 Apr 2005, Benjamin Herrenschmidt wrote:
>
> Do you intend to continue posting "commited" patches to a mailing list
> like bk scripts did to [EMAIL PROTECTED] ? As I said a while ago, I
> find this very useful, especially with the actual patch included in the
> commit message (which
On Mon, 11 Apr 2005, Benjamin Herrenschmidt wrote:
Do you intend to continue posting commited patches to a mailing list
like bk scripts did to [EMAIL PROTECTED] ? As I said a while ago, I
find this very useful, especially with the actual patch included in the
commit message (which isn't
On Sun, 2005-04-10 at 16:26 -0700, Linus Torvalds wrote:
On Mon, 11 Apr 2005, Benjamin Herrenschmidt wrote:
If yes, then I would appreciate if you could either keep the same list,
or if you want to change the list name, keep the subscriber list so
those of us who actually archive it don't
Linus Torvalds wrote:
On Mon, 11 Apr 2005, Benjamin Herrenschmidt wrote:
If yes, then I would appreciate if you could either keep the same list,
or if you want to change the list name, keep the subscriber list so
those of us who actually archive it don't miss anything ;)
I didn't even set up the
46 matches
Mail list logo
