Catalin, Daniel,
thank you both for your input.
I'll try your recommendations (when time is available ;-) and see how it
goes.
Best regards,
Jan
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kern
Jan Veldeman <[EMAIL PROTECTED]> wrote:
> The parents which should be visible to the outside, will always be versions
> of my development tree, which I have previously pushed out. My way of
> working would become:
> * make changes, all over the place, using stgit
> * still make changes (none of the
Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> On Tue, 23 Aug 2005, Jan Veldeman wrote:
>> The parents which should be visible to the outside, will always be versions
>> of my development tree, which I have previously pushed out. My way of
>> working would become:
>> * make changes, all over the plac
On Tue, 30 Aug 2005 15:25:22 -0700 Junio C Hamano wrote:
> Christian Meder <[EMAIL PROTECTED]> writes:
>
> > Is alternates unthinkable with URLs (e.g. remote alternates).
>
> In order to read an object data, the low level core GIT layer
> does open()/mmap() of a file on the locally mounted files
Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> I got mostly done with this before Linus mentioned the possibility of
> having multiple index entries in the same stage for a single path. I
> finished it anyway, but I'm not sure that we won't want to know which of
> the common ancestors contributed whi
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
read-tree.c | 522 ++-
1 files changed, 297 insertions(+), 225 deletions(-)
d0f45ad81db2e133c49c23bd09c5615da344bb5c
diff --git a/read-tree.c b/read-tree.c
--- a/read-tree.c
+++ b/rea
On Tue, 30 Aug 2005, Junio C Hamano wrote:
> Dan, I really really *REALLY* wanted to try this out in "pu"
> branch and even was about to rig some torture chamber for
> testing before applying the patch, but you got the shiny blue
> bat X-<.
I'll send a replacement with the settings correct.
> A
Adds object_list_append() and a function to get the struct tree from an ent.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
object.c | 11 +++
object.h |3 +++
tree.c | 19 +++
tree.h |3 +++
4 files changed, 36 insertions(+), 0 deletions(-)
49d3
On Wed, 31 Aug 2005, Catalin Marinas wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> > I got mostly done with this before Linus mentioned the possibility of
> > having multiple index entries in the same stage for a single path. I
> > finished it anyway, but I'm not sure that we won't want to
On Tue, 30 Aug 2005, Catalin Marinas wrote:
> Back from holiday. Thanks to all who replied to this thread.
>
> On Tue, 2005-08-23 at 14:05 -0400, Daniel Barkalow wrote:
> > Having a useful diff isn't really a requirement for a parent; the diff in
> > the case of a merge is going to be the total o
Sergey Vlasov <[EMAIL PROTECTED]> writes:
> All this means that currently there is no clean way to publish a partial
> GIT repository, unless you place it at the same server where the base
> repository is located (and even in that case needing to use something
> like "echo /pub/scm/linux/kernel/gi
Jon Loeliger <[EMAIL PROTECTED]> writes:
> (*) -- I knew I didn't need to bother the list with this
> question. And that as soon as I asked for external help,
> the answer would become clear. Sorry to have bothered you.
That's OK. As I stated before, the primary motivation that got
me i
Stephen Rothwell <[EMAIL PROTECTED]> writes:
> The commit c594adad5653491813959277fb87a2fef54c4e05 is shown as
> "connected" (in Linus' tree, not one of my patches) by gitk, so I am happy
> that git prune did not get rid of it, but why does fsck-cache report it as
> dangling?
Hmph. You ran fsck-
I've been doing some clean-ups, mostly in the documentation
area. The tutorial reachable from the main gitweb page should
look a lot nicer and use glossary words more consistently then
before. I think its 'Packing your repository' section should be
replaced with more general 'Feeding and caring f
On Wed, 31 Aug 2005 13:13:56 -0700 Junio C Hamano <[EMAIL PROTECTED]> wrote:
>
> Stephen Rothwell <[EMAIL PROTECTED]> writes:
>
> > The commit c594adad5653491813959277fb87a2fef54c4e05 is shown as
> > "connected" (in Linus' tree, not one of my patches) by gitk, so I am happy
> > that git prune did
Stephen Rothwell <[EMAIL PROTECTED]> writes:
>> Stephen Rothwell <[EMAIL PROTECTED]> writes:
>>
>> > The commit c594adad5653491813959277fb87a2fef54c4e05 is shown as
>> > "connected" (in Linus' tree, not one of my patches) by gitk, so I am happy
>> > that git prune did not get rid of it, but why d
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> Is there any current use for read-tree with multiple trees without -m or
> equivalent?
I did not know it even allowed multiple trees without -m, but
you are right. It does not seem to complain.
I have never thought about using multiple trees withou
Junio C Hamano <[EMAIL PROTECTED]> writes:
>> Why does --emu23 use I+H for stage 2, rather than just I? Wouldn't this
>> just reintroduce removed files?
>
> They are not "removed files", at least in the original context.
>
> The original intention was...
Gmane turns out to be better remembering
On Wed, 31 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > Is there any current use for read-tree with multiple trees without -m or
> > equivalent?
>
> I did not know it even allowed multiple trees without -m, but
> you are right. It does not seem to complai
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> (The thread you mention seems to say that we accept entries being missing
> from the index as if they were unchanged, but I don't see a good reason
> for this; you'd be dealing with the full set in the index for the merge,
> even if you don't have a
20 matches
Mail list logo
