* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Jan Harkes @ 2005-05-12 16:20 UTC (permalink / raw)
To: jon; +Cc: Git Mailing List
In-Reply-To: <2cfc403205051208506249c9aa@mail.gmail.com>
On Fri, May 13, 2005 at 01:50:50AM +1000, Jon Seymour wrote:
> 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.
...
> 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
It breaks when Fn was a pull from Ln-1, and Ln was a fast-forward to Fn.
Now the first parent is going to be Fn-1 and the history of the local
repository after the fast forward warps to
Fn (== Ln)
Ln-1
Ln-2
Fn-1
Ln-3
And adding repoids doesn't help a bit. However if the local repo kept a
history of what the user has seen previously, it can be linearized
consistently. The history file would contain Ln-3...Ln-1 before the
fast-forward and would add Fn-1,Fn. We would end up with a history that
looks like,
Fn (== Ln)
Fn-1
Ln-1
Ln-2
Ln-3
Which I believe is exactly what Thomas wants to see in this case. I
don't see how repoid's can be useful for this. It is a porcelain thing
where you need to track what you have seen before. Anything else doesn't
matter because most permutations of the history are perfectly valid
since the Fn and Ln changes in reality occured in parallel and as a
result can be arbitrarily interleaved.
In fact anyone else who branched at Ln-3 and merges again at Ln doesn't
really care in what order changes in the F and L branches occurred, only
that all modifications are included.
Jan
^ permalink raw reply
* [PATCH] cg-init should only process files
From: David Greaves @ 2005-05-12 16:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing Lists
cg-init tries to add directories
Signed-off-by: David Greaves <david@dgreaves.com>
---
commit c6ecba40932efa0b28cd15d00fdab3b2607ec069
tree 39f7bebbadf6ebae67367b629d8cec298f7dcc90
parent f7d4b2adfc6a29036e2a8abe5b742e57b64e50d7
author David Greaves <david@dgreaves.com> Thu, 12 May 2005 13:05:03 +0100
committer David Greaves <david@ash.(none)> Thu, 12 May 2005 13:05:03 +0100
cg-init | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: cg-init
===================================================================
--- 85d8d081e2012da8dd1af35b62ae82f79f89ebd0/cg-init (mode:100755)
+++ 39f7bebbadf6ebae67367b629d8cec298f7dcc90/cg-init (mode:100755)
@@ -31,7 +31,7 @@
echo "Cloned (origin $uri available as branch \"origin\")"
else
git-read-tree # Seed the dircache
- find * | xargs cg-add
+ find * -type f | xargs cg-add
cg-commit -C -m"Initial commit" -e
fi
exit 0
^ permalink raw reply
* Overwriting files in Makefile
From: Horst von Brand @ 2005-05-12 15:56 UTC (permalink / raw)
To: git
The current setup disturbs me. The Makefile copies the scripts into the
destination, and then edits them in place. Why not just generate them from
.in files before installing, i.e. by a rule something like
%: %.in
sed -e 's;@LIBDIR@;$(sedlibdir);g' $^ > $@
with '@LIBDIR@' in the .in file whereever the substitution should take
place. This way you also avoid the possible loss of the permission bits
when fooling around (any SUID/SGID would get lost; not that it matters
here).
In any case, the '\/'s (LTS, "Leaning Toothpick Syndrome") when futzing
around with file paths can be avoided by using something else than '/' as
delimiter for sed(1)'s substitute command, like ';' here.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Jon Seymour @ 2005-05-12 15:50 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <2cfc403205051208483132921@mail.gmail.com>
|| oops - fix to algorithm, sorry guys
| 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 this algorithm . Append the
result into the list.
3. Sort the graph between the local parent and the merge base
(including merge base) according to this algorithm. Append the result
into 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
* 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
* 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: 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
* 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: [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
* 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: 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
* 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] [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
* 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: 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: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: 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: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: 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: 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: 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: 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
* 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: 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
* 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
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