On Thu, 25 Aug 2005, Junio C Hamano wrote:
>
> "v0.99.5^0" means "look at the named object v0.99.5, dereference
> it repeatedly until you get a non-tag, and take the result,
> which had better be a commit". If a tag can contain more than
> one pointers, I do not know what it means.
Yeah, we'd
Martin Langhoff <[EMAIL PROTECTED]> writes:
> On 8/26/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> Thinking about it going from arch to git should be just a matter
>> of checking sha1 hashes, possibly back to the beginning of the
>> arch tree.
>
> Yup, though actually replaying the tree to
On 8/26/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Thinking about it going from arch to git should be just a matter
> of checking sha1 hashes, possibly back to the beginning of the
> arch tree.
Yup, though actually replaying the tree to compute the hashes is
something I just _won't_ do ;)
Martin Langhoff <[EMAIL PROTECTED]> writes:
> Hmmm. That repo is in sync, but there are no guarantees that they will
> travel together to a different repo. In fact, the push/pull
> infrastructure wants to push/pull one head at a time.
>
> And if they are not in sync, I have no way of knowing. Hmpf
On 8/26/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> > Hmmm. That repo is in sync, but there are no guarantees that they will
> > travel together to a different repo. In fact, the push/pull
> > infrastructure wants to push/pull one head at a time.
>
> Wrong as of last week ;-), and definitely w
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> I don't think this buys you anything, because then the tag needs to be
> accessible from something, which is the same problem you were trying to
> solve for the commit.
Actually not. My suggestion was a qualified one: "If all you
need is a textual in
Linus Torvalds <[EMAIL PROTECTED]> writes:
> That kind of extension shouldn't be too hard, and might make tags much
> more generally usable (ie you could say "I sign these official
> releases" or something).
Well, I admit that once I advocated changing "tag" to "bag", but
one problem is how yo
On Fri, 26 Aug 2005, Daniel Barkalow wrote:
>
> I don't think this buys you anything, because then the tag needs to be
> accessible from something, which is the same problem you were trying to
> solve for the commit.
Yes.
We had an earlier discussion somewhat along these lines, where a
"coll
On Thu, 25 Aug 2005, Junio C Hamano wrote:
> Now, among the existing object types, there are only two kinds
> of objects you can use for this. If the only thing you need to
> record is some textual information with one pointer to git
> branch head, then you can use tag that points at the git head
Martin Langhoff <[EMAIL PROTECTED]> writes:
>> In other words, if you just have a "last commit" pointer in your
>> meta-data, then git is _by_definition_ in sync. There's never anything to
>> get out of sync, because objects aren't going to change.
>
> Hmmm. That repo is in sync, but there are no
On 8/26/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > OTOH, storing the metadata in a branch will allow us to run the import
> > in alternating repositories. But as Junio points out, unless I can
> > guarantee that the metadata and the tree are in sync, I cannot
> > trivially resume the import
On Fri, 26 Aug 2005, Martin Langhoff wrote:
>
> OTOH, storing the metadata in a branch will allow us to run the import
> in alternating repositories. But as Junio points out, unless I can
> guarantee that the metadata and the tree are in sync, I cannot
> trivially resume the import cycle from a
On 8/26/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> If I am not mistaken, we have another foreign SCM import
> interface that can repeatedly slurp from the same foreign SCM to
> get updates. Doesn't cvsimport have the same issue?
Yes and no.
cvsimport uses cvsps which uses in ~/.cvsps as
Linus,
I like the solution you are suggesting, but I suspect it will create
more problems that it will solve, and while the coolness factor is
drawing me in we ain't gonna need it, as the xp people say.
More below...
On 8/26/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Git won't care, so
[ Junio, the fact that you can't script the initial commit with "git
commit" is _really_ irritating. ]
On Thu, 25 Aug 2005, Martin Langhoff wrote:
>
> Is there a convention of where/how it is safe to store additional
> (non-git) data in $GIT_DIR?
There's no convention, but I have a suggestio
15 matches
Mail list logo
