* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-12 10:42 UTC (permalink / raw)
To: Sean; +Cc: David Woodhouse, git
In-Reply-To: <3203.10.10.10.24.1115893120.squirrel@linux1>
On Thu, 2005-05-12 at 06:18 -0400, Sean wrote:
> Does BK use a repo ID ?
Yes.
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: David Woodhouse @ 2005-05-12 10:43 UTC (permalink / raw)
To: Sean; +Cc: tglx, git
In-Reply-To: <3203.10.10.10.24.1115893120.squirrel@linux1>
On Thu, 2005-05-12 at 06:18 -0400, Sean wrote:
> Does BK use a repo ID ? If not, can you not apply the same process to
> git? Seems the fast forward heads might complicate things
> slightly....
BK doesn't fast-forward in quite the same way as git does. But we're not
really supposed to be paying too much attention to how BK works.
Your claim is that you can do this with existing git tools. I await that
demonstration.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-12 10:58 UTC (permalink / raw)
To: David Woodhouse; +Cc: tglx, git
In-Reply-To: <1115894589.16187.570.camel@hades.cambridge.redhat.com>
On Thu, May 12, 2005 6:43 am, David Woodhouse said:
> On Thu, 2005-05-12 at 06:18 -0400, Sean wrote:
>> Does BK use a repo ID ? If not, can you not apply the same process to
>> git? Seems the fast forward heads might complicate things
>> slightly....
>
> BK doesn't fast-forward in quite the same way as git does. But we're not
> really supposed to be paying too much attention to how BK works.
lol, i just asked because you brought it up.
> Your claim is that you can do this with existing git tools. I await that
> demonstration.
Well i'm not going to write the code for you, but simply descend the
history ordered by local commit time as given by the file object and
you're done.
Sean.
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-12 11:18 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <3656.10.10.10.24.1115891188.squirrel@linux1>
On Thu, 2005-05-12 at 05:46 -0400, Sean wrote:
> On Thu, May 12, 2005 5:39 am, Thomas Gleixner said:
>
> > Please do the complete test. Sync test2 with test1 and show me the
> > picture there. It will be the same as you see in test1, which is wrong
>
> It will get the fast forward head from test1, and so it _should_ show the
> exact same thing! The repositories are in sync, they should display the
> exact same way. What is the problem?
What you see is a clone and not a sync / merge.
tglx
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-12 11:24 UTC (permalink / raw)
To: tglx; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <1115896713.22180.314.camel@tglx>
On Thu, May 12, 2005 7:18 am, Thomas Gleixner said:
> On Thu, 2005-05-12 at 05:46 -0400, Sean wrote:
>> On Thu, May 12, 2005 5:39 am, Thomas Gleixner said:
>>
>> > Please do the complete test. Sync test2 with test1 and show me the
>> > picture there. It will be the same as you see in test1, which is wrong
>>
>> It will get the fast forward head from test1, and so it _should_ show
>> the
>> exact same thing! The repositories are in sync, they should display the
>> exact same way. What is the problem?
>
> What you see is a clone and not a sync / merge.
>
Right, that's what a fast forward head is. It replaces a sync / merge and
the trees become exactly syncronized via a shared head. I have mixed
feelings about fast forward heads, but they don't hide _too_ much
information. Is there any _useful_ question you can ask where the answer
is lost for all time because of this.
Sean
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-12 11:43 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <3745.10.10.10.24.1115897090.squirrel@linux1>
On Thu, 2005-05-12 at 07:24 -0400, Sean wrote:
> Right, that's what a fast forward head is. It replaces a sync / merge and
> the trees become exactly syncronized via a shared head. I have mixed
> feelings about fast forward heads, but they don't hide _too_ much
> information.
The question is how hard it is to do a reconstruction. In the current
state automatic reconstruction is simply not possible.
> Is there any _useful_ question you can ask where the answer
> is lost for all time because of this.
I want to see the history of _any_ repository in the order of changes
in the specific repository. The fast forward heads without additional
information simply do not allow this.
I want to see the history of a file in the correct order. The current
solution ends up with useless file version diffs or annotates where
changes are shown in random order and therefor worthless.
tglx
^ permalink raw reply
* How to add new tree?
From: Alexey Nezhdanov @ 2005-05-12 11:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Hello.
Probably a lame question but I can figure out how to add new directory to repo
neither with cogito nor with git.
a simple example:
=========
$mkdir newdir
$cg-add newdir
cg-add: newdir does not exist
$
==========
How can this be resolved?
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-12 11:48 UTC (permalink / raw)
To: tglx; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <1115898230.11872.8.camel@tglx>
On Thu, May 12, 2005 7:43 am, Thomas Gleixner said:
> On Thu, 2005-05-12 at 07:24 -0400, Sean wrote:
>> Right, that's what a fast forward head is. It replaces a sync / merge
>> and
>> the trees become exactly syncronized via a shared head. I have mixed
>> feelings about fast forward heads, but they don't hide _too_ much
>> information.
>
> The question is how hard it is to do a reconstruction. In the current
> state automatic reconstruction is simply not possible.
You keep evading the question. What are you reconstructing, and why?
What questions can you then answer with your reconstruction that you can't
answer with what we already have today. You HAVE to explain what the
VALUE of the end result is beyond what we already have today.
>> Is there any _useful_ question you can ask where the answer
>> is lost for all time because of this.
>
> I want to see the history of _any_ repository in the order of changes
> in the specific repository. The fast forward heads without additional
> information simply do not allow this.
Then just download their repository with the -t switch of rsync or its
equal and preserve the timestamps on the files as they exist in the remote
repository.
> I want to see the history of a file in the correct order. The current
> solution ends up with useless file version diffs or annotates where
> changes are shown in random order and therefor worthless.
>
What is this correct order you're talking about? The order is _given_
explicitly in the parent child relationships. There is no other order of
any value, at least none you've been able to put forth.
Sean
^ permalink raw reply
* Re: How to add new tree?
From: David Greaves @ 2005-05-12 12:03 UTC (permalink / raw)
To: Alexey Nezhdanov; +Cc: git
In-Reply-To: <200505121544.23902.snake@penza-gsm.ru>
Alexey Nezhdanov wrote:
>Hello.
>Probably a lame question but I can figure out how to add new directory to repo
>neither with cogito nor with git.
>
>a simple example:
>=========
>$mkdir newdir
>$cg-add newdir
>cg-add: newdir does not exist
>$
>==========
>How can this be resolved?
>
>
>
git (and so cogito) manage content.
Directories have no content
Add a file within it
cg-add newdir/file
and it will create a tree as needed.
David
--
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-12 12:16 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <2247.10.10.10.24.1115898521.squirrel@linux1>
On Thu, 2005-05-12 at 07:48 -0400, Sean wrote:
> Then just download their repository with the -t switch of rsync or its
> equal and preserve the timestamps on the files as they exist in the remote
> repository.
Thats really the brightest idea since the invention of sliced bread.
tglx
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-12 12:16 UTC (permalink / raw)
To: tglx; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <1115900168.11872.13.camel@tglx>
On Thu, May 12, 2005 8:16 am, Thomas Gleixner said:
> On Thu, 2005-05-12 at 07:48 -0400, Sean wrote:
>
>> Then just download their repository with the -t switch of rsync or its
>> equal and preserve the timestamps on the files as they exist in the
>> remote
>> repository.
>
> Thats really the brightest idea since the invention of sliced bread.
>
That's pretty smug for someone who can't even formulate a problem statement.
Sean
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-12 12:17 UTC (permalink / raw)
To: tglx; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <1115900168.11872.13.camel@tglx>
On Thu, May 12, 2005 8:16 am, Thomas Gleixner said:
> On Thu, 2005-05-12 at 07:48 -0400, Sean wrote:
>
>> Then just download their repository with the -t switch of rsync or its
>> equal and preserve the timestamps on the files as they exist in the
>> remote
>> repository.
>
> Thats really the brightest idea since the invention of sliced bread.
>
By the way, you have to download the object ANYWAY
Sean
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: David Woodhouse @ 2005-05-12 12:29 UTC (permalink / raw)
To: Sean; +Cc: tglx, Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <2247.10.10.10.24.1115898521.squirrel@linux1>
On Thu, 2005-05-12 at 07:48 -0400, Sean wrote:
> What is this correct order you're talking about? The order is _given_
> explicitly in the parent child relationships. There is no other order of
> any value, at least none you've been able to put forth.
Now you're just being silly. You _replied_ to a message in which it was
stated perfectly coherently. Even you appeared to understand the
explanation at that point.
*plonk*
--
dwmw2
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-12 12:32 UTC (permalink / raw)
To: David Woodhouse; +Cc: tglx, Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <1115900963.16187.575.camel@hades.cambridge.redhat.com>
On Thu, May 12, 2005 8:29 am, David Woodhouse said:
> On Thu, 2005-05-12 at 07:48 -0400, Sean wrote:
>> What is this correct order you're talking about? The order is _given_
>> explicitly in the parent child relationships. There is no other order
>> of
>> any value, at least none you've been able to put forth.
>
> Now you're just being silly. You _replied_ to a message in which it was
> stated perfectly coherently. Even you appeared to understand the
> explanation at that point.
>
David,
I gave you a solution to your problem, what is the issue that remains?
Sean
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-12 12:34 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <4754.10.10.10.24.1115900216.squirrel@linux1>
On Thu, 2005-05-12 at 08:16 -0400, Sean wrote:
> On Thu, May 12, 2005 8:16 am, Thomas Gleixner said:
> > On Thu, 2005-05-12 at 07:48 -0400, Sean wrote:
> >
> >> Then just download their repository with the -t switch of rsync or its
> >> equal and preserve the timestamps on the files as they exist in the
> >> remote
> >> repository.
> >
> > Thats really the brightest idea since the invention of sliced bread.
> >
>
> That's pretty smug for someone who can't even formulate a problem statement.
I explained it several times and you refuse to understand it.
I accept and understand your POV that it does not matter for you. But
thats not a really good reason to refuse others information which can be
added easily and without harming you.
tglx
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-12 12:35 UTC (permalink / raw)
To: tglx; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <1115901291.11872.21.camel@tglx>
On Thu, May 12, 2005 8:34 am, Thomas Gleixner said:
> I explained it several times and you refuse to understand it.
>
> I accept and understand your POV that it does not matter for you. But
> thats not a really good reason to refuse others information which can be
> added easily and without harming you.
And you have a perfectly workable solution handed to you that doesn't
require any change whatsoever.
Sean
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Jan Harkes @ 2005-05-12 13:29 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Sean, Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <1115898230.11872.8.camel@tglx>
On Thu, May 12, 2005 at 01:43:50PM +0200, Thomas Gleixner wrote:
> > Is there any _useful_ question you can ask where the answer
> > is lost for all time because of this.
>
> I want to see the history of _any_ repository in the order of changes
> in the specific repository. The fast forward heads without additional
> information simply do not allow this.
But you can't add additional information to the fast-forward head. That
would defeat the whole point of the fast-forward.
> I want to see the history of a file in the correct order. The current
> solution ends up with useless file version diffs or annotates where
> changes are shown in random order and therefor worthless.
Not random order, those changes were performed in parallel, so there is
no order between them until they are merged, at which point the parent
linkage defines the order. If you want to add a total ordering to them,
write out a file with 'commit-id parent-id' pairs and run it through
'tsort'.
Your examples break if you consider additional merges where M syncs up a
couple of times (f.i. at Rn-2) before M is merged back into R.
What you seem to want won't be fixed by adding a repoid, you need to
keep a list of all the commits you have already seen and append any new
ones whenever you look at the history. If you look whenever you pull or
merge the list will be in the total ordering that you seem to expect for
your repository. But that is a porcelain thing.
Jan
^ permalink raw reply
* Adapting scripts to work in current (not top) directory
From: Alexey Nezhdanov @ 2005-05-12 13:58 UTC (permalink / raw)
To: GIT Mailing List
All git and cogito scripts wants .git subdirectory. If I'm in a subdirectory
that have no .git direcory in it I'm out of luck.
I have wrote an example script that determines the lowest possible .git
directory position and changes to it to satisfy user request.
Problems with script:
1) May be I misunderstood the git ideology and it needs not this at all.
if point (1) is false then there are couple of other problems:
2) Script is extremelly ugly. I'm a week bash programmer so please criticize.
3) This logic shold be somehow embedded to all git- and cg- scripts. I can not
figure how to do it non-intruisively.
4) files and patch with spaces not supported. Probably fixable but first I
want to resolve points (1), (2) and (3)
===========================
#!/bin/bash
#
# Add new file to a GIT repository.
# Copyright (c) Petr Baudis, 2005
#
# Takes a list of file names at the command line, and schedules them
# for addition to the GIT repository at the next commit.
. ${COGITO_LIB:-/home/snake/lib/cogito/}cg-Xlib
[ "$1" ] || die "usage: cg-add FILE..."
gitpath=
subpath=
curpath=`pwd`
for ((i=2;i<9999;i=i+1)) ; do {
path1=`echo $curpath | cut -d / -f 0-$i`
path2=`echo $curpath | cut -d / -f $((i+1))-`
[ -d "$path1"/.git ] && gitpath=$path1 && subpath=$path2
[ "$path1" == "$curpath" ] && break
}; done
for file in "$@"; do
if [ -f "$file" ]; then
echo "Adding file $file"
else
die "$file does not exist"
fi
done
cd "$gitpath"
files=
for file in "$@"; do
files="$files $subpath/$file"
done
git-update-cache --add -- $files
===========================
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: [PATCH] improved delta support for git
From: Chris Mason @ 2005-05-12 14:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7voebhkql5.fsf@assigned-by-dhcp.cox.net>
On Thursday 12 May 2005 00:36, Junio C Hamano wrote:
> It appears to me that changes to the make_sure_we_have_it()
> routine along the following lines (completely untested) would
> suffice. Instead of just returning success, we first fetch the
> named object from the remote side, read it to see if it is
> really the object we have asked, or just a delta, and if it is a
> delta call itself again on the underlying object that delta
> object depends upon.
If we fetch the named object and it is a delta, the delta will either depend
on an object we already have or an object that we don't have. If we don't
have it, the pull should find it while pulling other commits we don't have.
-chris
^ permalink raw reply
* Re: [PATCH] improved delta support for git
From: Jon Seymour @ 2005-05-12 14:47 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <2cfc403205051207467755cdf@mail.gmail.com>
On 5/13/05, Chris Mason <mason@suse.com> wrote:
> On Thursday 12 May 2005 00:36, Junio C Hamano wrote:
> > It appears to me that changes to the make_sure_we_have_it() ...
>
> If we fetch the named object and it is a delta, the delta will either depend
> on an object we already have or an object that we don't have. If we don't
> have it, the pull should find it while pulling other commits we don't have.
>
Chris,
Doesn't that assume that the object referenced by the delta is
reachable from the commit being pulled. While that may be true in
practice, I don't think it is a logical certainty.
jon.
^ permalink raw reply
* Re: [PATCH] improved delta support for git
From: Nicolas Pitre @ 2005-05-12 15:18 UTC (permalink / raw)
To: jon; +Cc: Git Mailing List
In-Reply-To: <2cfc403205051207471f6957e0@mail.gmail.com>
On Fri, 13 May 2005, Jon Seymour wrote:
> On 5/13/05, Chris Mason <mason@suse.com> wrote:
> > On Thursday 12 May 2005 00:36, Junio C Hamano wrote:
> > > It appears to me that changes to the make_sure_we_have_it() ...
> >
> > If we fetch the named object and it is a delta, the delta will either depend
> > on an object we already have or an object that we don't have. If we don't
> > have it, the pull should find it while pulling other commits we don't have.
> >
>
> Chris,
>
> Doesn't that assume that the object referenced by the delta is
> reachable from the commit being pulled. While that may be true in
> practice, I don't think it is a logical certainty.
1) If you happen to already have the referenced object in your local
repository then you're done.
2) If not you pull the referenced object from the remote repository,
repeat with #1 if it happens to be another delta object.
3) If the remote repository doesn't contain the object referenced by any
pulled delta object then that repository is inconsistent just like if
a blob object referenced by a tree object was missing. This
therefore should not happen. git-fsck-cache will flag broken delta
links soon.
Nicolas
^ permalink raw reply
* How-to create a new repository using cogito
From: Wink Saville @ 2005-05-12 15:37 UTC (permalink / raw)
To: git
Hello,
I've successfully followed the instructions in the cogito README and
gotten both cogito repositories and linux. I then tried to create a
local repository for a directory of my own. But was unsuccessful.
<Attempted to do the following>
wink@tuxws git-linux $ mkdir test
wink@tuxws git-linux $ cd test
wink@tuxws test $ echo "some data" > src.c
wink@tuxws test $ cat src.c
some data
wink@tuxws test $ cg-clone -s .
defaulting to local storage area
`/home/wink/git-linux/test/./.git/refs/heads/master' ->
`.git/refs/heads/origin'
cg-pull: objects pull failed
cg-init: pull failed
<forged ahead despite the error's>
wink@tuxws test $ cg-add src.c
Adding file src.c
wink@tuxws test $ cg-commit
usage: git-diff-cache [-p] [-r] [-z] [-m] [--cached] <tree sha1>
cg-commit: Nothing to commit
<using "cg-commit ." did prompt me for log info>
wink@tuxws test $ cg-commit .
Ignoring path .
usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
error: mmap failed
fatal: cache corrupted
cg-commit: update-cache failed
wink@tuxws test $ cg-log
cat: .git/refs/tags/: Is a directory
cat: .git/refs/heads/: Is a directory
Invalid id:
<contents of .git>
wink@tuxws test $ find .git -type f
.git/refs/heads/master
.git/refs/heads/origin
.git/index
.git/branches/origin
.git/objects/42/6863280eedd08aa600ac034e6a9933ba372944
So something happened but I'm obviously missing something. Also why does
this fail?
wink@tuxws test $ cd .git/objects/42/
wink@tuxws test $ git-cat-file 6863280eedd08aa600ac034e6a9933ba372944
usage: git-cat-file [-t | tagname] <sha1>
Thanks,
Wink
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 5/10/2005
^ permalink raw reply
* Re: How-to create a new repository using cogito
From: Zack Brown @ 2005-05-12 15:27 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <42837827.8020404@saville.com>
On Thu, May 12, 2005 at 08:37:11AM -0700, Wink Saville wrote:
> Hello,
>
> I've successfully followed the instructions in the cogito README and
> gotten both cogito repositories and linux. I then tried to create a
> local repository for a directory of my own. But was unsuccessful.
You didn't read far enough down in the README.
Look for cg-init
>
> <Attempted to do the following>
>
> wink@tuxws git-linux $ mkdir test
> wink@tuxws git-linux $ cd test
> wink@tuxws test $ echo "some data" > src.c
> wink@tuxws test $ cat src.c
> some data
> wink@tuxws test $ cg-clone -s .
> defaulting to local storage area
> `/home/wink/git-linux/test/./.git/refs/heads/master' ->
> `.git/refs/heads/origin'
> cg-pull: objects pull failed
> cg-init: pull failed
>
> <forged ahead despite the error's>
>
> wink@tuxws test $ cg-add src.c
> Adding file src.c
> wink@tuxws test $ cg-commit
> usage: git-diff-cache [-p] [-r] [-z] [-m] [--cached] <tree sha1>
> cg-commit: Nothing to commit
>
> <using "cg-commit ." did prompt me for log info>
>
> wink@tuxws test $ cg-commit .
> Ignoring path .
> usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
> error: mmap failed
> fatal: cache corrupted
> cg-commit: update-cache failed
> wink@tuxws test $ cg-log
> cat: .git/refs/tags/: Is a directory
> cat: .git/refs/heads/: Is a directory
> Invalid id:
>
> <contents of .git>
>
> wink@tuxws test $ find .git -type f
> .git/refs/heads/master
> .git/refs/heads/origin
> .git/index
> .git/branches/origin
> .git/objects/42/6863280eedd08aa600ac034e6a9933ba372944
>
> So something happened but I'm obviously missing something. Also why does
> this fail?
>
> wink@tuxws test $ cd .git/objects/42/
> wink@tuxws test $ git-cat-file 6863280eedd08aa600ac034e6a9933ba372944
> usage: git-cat-file [-t | tagname] <sha1>
>
> Thanks,
>
> Wink
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 5/10/2005
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Jon Seymour @ 2005-05-12 15:44 UTC (permalink / raw)
To: Thomas Gleixner, Sean, Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <20050512132922.GB20785@delft.aura.cs.cmu.edu>
On 5/12/05, Jan Harkes <jaharkes@cs.cmu.edu> wrote:
> On Thu, May 12, 2005 at 01:43:50PM +0200, Thomas Gleixner wrote:
> ....
> Your examples break if you consider additional merges where M syncs up a
> couple of times (f.i. at Rn-2) before M is merged back into R.
>
> What you seem to want won't be fixed by adding a repoid, you need to
> keep a list of all the commits you have already seen and append any new
> ones whenever you look at the history. If you look whenever you pull or
> merge the list will be in the total ordering that you seem to expect for
> your repository. But that is a porcelain thing.
>
> Jan
If committers always follow the convention that their previous local
commit is nominated as the first (local) parent in the commit and
commits from foreign repositories are listed after the first parent,
can the chain of "local" parents be an effective proxy for repoid?
Consider first a graph where there are no more than 2 parents in a merge
Ln
| \
Ln-1 Fn
| |
Ln-2 Fn-1
| /
Ln-3
Thomas would like to sort this as:
Ln
Fn
Fn-1
Ln-1
Ln-2
Ln-3
So, use this algorithm:
1. Merge result comes first.
2. For each foreign parent:
- sort the graph between the foreign parent and the merge base
according to his algorithm using the foreign parent as the starting
point of the algorithm. Append the result into the list.
3. Append the merge base to the list.
Admittedly the order for foreign parent for N-way merges is somewhat
arbitrary but a committer could probably make a choice that "works" in
most cases by specifying the foreign parents in a "sensible" order.
Of course, this relies on a committer always nominating the local
parent first, but that wouldn't be hard to enforce in the porcelain
layer.
jon.
1. the merging commit comes first
2. the graph of commits between each foreign parent and the
"merge-base" is sorted
3.
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Jon Seymour @ 2005-05-12 15:48 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <2cfc4032050512084426ea3d4d@mail.gmail.com>
| small clarification to algorithm, removed editing work area
On 5/12/05, Jan Harkes <jaharkes@cs.cmu.edu> wrote:
> On Thu, May 12, 2005 at 01:43:50PM +0200, Thomas Gleixner wrote:
> ....
> Your examples break if you consider additional merges where M syncs up a
> couple of times (f.i. at Rn-2) before M is merged back into R.
>
> What you seem to want won't be fixed by adding a repoid, you need to
> keep a list of all the commits you have already seen and append any new
> ones whenever you look at the history. If you look whenever you pull or
> merge the list will be in the total ordering that you seem to expect for
> your repository. But that is a porcelain thing.
>
> Jan
If committers always follow the convention that their previous local
commit is nominated as the first (local) parent in the commit and
commits from foreign repositories are listed after the first parent,
can the chain of "local" parents be an effective proxy for repoid?
Consider first a graph where there are no more than 2 parents in a merge
Ln
| \
Ln-1 Fn
| |
Ln-2 Fn-1
| /
Ln-3
Thomas would like to sort this as:
Ln
Fn
Fn-1
Ln-1
Ln-2
Ln-3
So, use this algorithm:
1. Merge result comes first.
2. For each foreign parent:
- sort the graph between the foreign parent and the merge base
(not including merge base) according to his algorithm using the
foreign parent as the starting
point of the algorithm. Append the result into the list.
3. Append the merge base to the list.
Admittedly the order for foreign parent for N-way merges is somewhat
arbitrary but a committer could probably make a choice that "works" in
most cases by specifying the foreign parents in a "sensible" order.
Of course, this relies on a committer always nominating the local
parent first, but that wouldn't be hard to enforce in the porcelain
layer.
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox