On Mon, 6 Jul 2015, Junio C Hamano wrote:
> Jacob Keller writes:
>
> > I've been looking at the refspecs for git fetch, and noticed that
> > globs are partially supported. I wanted to use something like:
> >
> > refs/tags/some-prefix-*:refs/tags/some-prefix-*
> >
> > as a refspec, so that I can
On Wed, 31 Oct 2012, Felipe Contreras wrote:
> Hi,
>
> On Wed, Oct 31, 2012 at 7:59 PM, Jonathan Nieder wrote:
> > Felipe Contreras wrote:
> >> On Wed, Oct 31, 2012 at 7:20 PM, Johannes Schindelin
> >> wrote:
> >
> >>> I just tested this with junio/next and it seems this issue is still
> >>> un
On Fri, 6 Jul 2012, Alex Riesen wrote:
> Hi list,
>
> when git-clone was built in, its treatment of umask has changed: the shell
> version respected umask for newly created directories by using plain mkdir(1),
> and the builtin version just uses mkdir(work_tree, 0755).
>
> Is it intentional?
I h
On Fri, 9 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > In case #16, I'm not sure what I should produce. I think the best thing
> > might be to not leave anything in stage 1. The desired end effect is that
> > the user
On Fri, 9 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > It tries to make sure that there is room to put stuff for resolving a
> > conflict without messing with modified files in the directory.
>
> I agree it can be used that w
2) call 'git-merge'
> from 'git-pull'. What I have in the proposed updates branch has
> been fixed since my earlier message to the list and has a new
> merge strategy script, in addition to 'resolve' and 'octopus',
> called 'git-merge-multibase
On Thu, 8 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > I assume that what you want is something to include everything from two
> > commits, which would give conflicts if a name is reused?
>
> My understanding is that Darrin w
On Thu, 8 Sep 2005, Darrin Thompson wrote:
> On Mon, 2005-09-05 at 01:41 -0400, Daniel Barkalow wrote:
> > I've got a version of read-tree which accepts multiple ancestors and does
> > a merge using information from all of them.
>
> Do the multiple ancestors have to s
On Thu, 8 Sep 2005, Fredrik Kuivinen wrote:
> The first one agrees with what was actually committed. For the second
> one the difference between the tree produced by the algorithm and what
> was committed is:
>
> diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h
> --- a/include/net/i
On Thu, 8 Sep 2005, Fredrik Kuivinen wrote:
> On Wed, Sep 07, 2005 at 02:33:42PM -0400, Daniel Barkalow wrote:
> > On Wed, 7 Sep 2005, Fredrik Kuivinen wrote:
> >
> > > Of the 500 merge commits that currently exists in the kernel
> > > repository 19 produce
On Wed, 7 Sep 2005, Fredrik Kuivinen wrote:
> Of the 500 merge commits that currently exists in the kernel
> repository 19 produces non-clean merges with git-merge-script. The
> four merge cases listed in
> <[EMAIL PROTECTED]> are cleanly merged by
> git-merge-script. Every merge commit which is c
On Tue, 6 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > Good. (Although that patch doesn't seem to be directly on top of my
> > version; I can tell what it's doing anyway)
>
> That one was against the proposed u
On Tue, 6 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > Do you know if there's anything like case #16 in there? I'd be interested
> > to know if there's anything that gets handled automatically in different
> >
On Mon, 5 Sep 2005, Linus Torvalds wrote:
> On Mon, 5 Sep 2005, Fredrik Kuivinen wrote:
> >
> > After a quick look through the diff source I didn't find anything
> > else. It's quite possible that I haved missed something though. Most
> > of the translated messages are related to error reporting,
On Mon, 5 Sep 2005, Linus Torvalds wrote:
> On Mon, 5 Sep 2005, Wayne Scott wrote:
> >
> > A recent commit in linux-2.6 looks like this:
>
> It hopefully shouldn't happen any more with the improved and fixed
> git-merge-base.
Couldn't it also happen if there's stale data in MERGE_HEAD when you
On Mon, 5 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > I've got a version of read-tree which accepts multiple ancestors and does
> > a merge using information from all of them.
>
> After disabling the debugging print
Signed-off-by: Daniel Barkalow
---
Documentation/technical/trivial-merge.txt | 92 +
1 files changed, 92 insertions(+), 0 deletions(-)
create mode 100644 Documentation/technical/trivial-merge.txt
7544be0a8eda7b796150729a7795c2639278da62
diff --git a/Documentation
Adds support for multiple ancestors, removes --emu23, much simplification.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
read-tree.c | 811 +++--
t/t1005-read-tree-m-2way-emu23.sh | 422 ---
2 files change
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
object.c | 11 +++
object.h |3 +++
2 files changed, 14 insertions(+), 0 deletions(-)
88cf2db55848e7a2cf655171c7e9fd74c70a0281
diff --git a/object.c b/object.c
--- a/object.c
+++ b/object.c
@@ -184,6 +184,17 @@
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
tree.c | 21 +
tree.h |3 +++
2 files changed, 24 insertions(+), 0 deletions(-)
3bfcc20b6aeff3e1fbcce97a426383c9770a2105
diff --git a/tree.c b/tree.c
--- a/tree.c
+++ b/tree.c
@@ -1,5 +1,7 @@
#include &
Various messages have already described this series. There's still a
memory leak that should get resolved, but otherwise it should work. I'm
not entirely sure that all directory-file conflict cases are handled
properly, and some undefined cases behave differently. Also, I was a bit
careless wit
I've got a version of read-tree which accepts multiple ancestors and does
a merge using information from all of them.
The basic features are that it looks for an ancestor which would permit a
trivial merge, and uses that. However, if it finds ancestors which permit
different trivial merges, it
On Sun, 4 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > 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
On Sun, 4 Sep 2005, Junio C Hamano wrote:
> Sam Ravnborg <[EMAIL PROTECTED]> writes:
>
> > If the problem is not fully understood it can be difficult to come up
> > with the proper solution. And with the example above the problem should
> > be really easy to understand.
> > Then we have the tree
On Sat, 3 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > I think "fetch" is more applicable to what they do.
>
> OK. then they are git-http-fetch and friends. How about
> git-ssh-push? The counterpart of fetch-pack/c
On Fri, 2 Sep 2005, Junio C Hamano wrote:
> I said:
>
> > I'll draw up a strawman tonight unless somebody else
> > does it first.
>
> 1. Say 'index' when you are tempted to say 'cache'.
>
> git-checkout-cache git-checkout-index
> git-convert-cache git-convert-
On Thu, 1 Sep 2005, Junio C Hamano wrote:
> Tim Ottinger <[EMAIL PROTECTED]> writes:
>
> > git-update-cache for instance?
> > I am not sure which 'cache' commands need to be 'index' now.
>
> Logically you are right, but I suspect that may not fly well in
> practice. Too many of us have already
A few things to improve testing. I'll clean up the series as a whole once
it's tested.
This removes the emu23 tests; I think that the only DF conflict tests were
in that set, however, so these should be fished out and added to something
else.
Signed-off-by: Daniel Barkalow <[EM
On Thu, 1 Sep 2005, Junio C Hamano wrote:
> Daniel, I do not know what your current status is, but I think
> you need something like this.
Yup, I forgot to actually test that functionality.
> ---
> diff --git a/tree.c b/tree.c
> --- a/tree.c
> +++ b/tree.c
> @@ -224,10 +224,12 @@ struct tree *pa
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
> yo
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 merg
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&#x
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 del
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
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
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 del
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 which, and, if some of them don't have a
path, we woul
On Sat, 27 Aug 2005, Linus Torvalds wrote:
> On Sat, 27 Aug 2005, Daniel Barkalow wrote:
> >
> > What I missed was that the effect of causes_df_conflict is to give "no
> > merge" for the entry, rather than giving an error overall. So I do need an
> > equival
On Sat, 27 Aug 2005, Daniel Barkalow wrote:
> Okay, so it looks to me like the only cases that care about the contents
> of the index, other than in stage 0 (which is effectively another tree,
> but already in index-form rather than tree-form), are 2 and 3, and these
> only care becau
On Sat, 27 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > Part of threeway_merge, however, wants to search the rest of the cache for
> > interfering entries in some cases, which would have to happen differently,
> > because I w
On Sat, 27 Aug 2005, Martin Langhoff wrote:
> On 8/27/05, Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> > The problem with both of these (and doing it in the build system) is that,
> > when a project includes another project, you generally don't want whatever
> >
I've gotten to the point of having all of the entries for a given path
ready to put into the cache at the same, and now I want to convert the
merge functions to take their data directly, rather than in the cache, so
that they can take extra entries for extra ancestors.
Part of threeway_merge, howe
On Fri, 26 Aug 2005, Fredrik Kuivinen wrote:
> On Fri, Aug 26, 2005 at 04:48:32PM -0400, Daniel Barkalow wrote:
> > On Fri, 26 Aug 2005, Fredrik Kuivinen wrote:
> >
> > > I will try to describe how the algorithm works. The problem with the
> > > usual 3-way merge
On Fri, 26 Aug 2005, Fredrik Kuivinen wrote:
> I will try to describe how the algorithm works. The problem with the
> usual 3-way merge algorithm is that we sometimes do not have a unique
> common ancestor. In [1] B and C seems to be equally good. What this
> algorithm does is to _merge_ the commo
On Fri, 26 Aug 2005, Martin Langhoff wrote:
> On 8/26/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> > their core GIT tools come from. But how would _I_ pull from
> > that "My Project", if I did not want to pull unrelated stuff in?
>
> and then...
>
> > What I think _might_ deserve a bit more su
On Fri, 26 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > I've started this, and have gotten as far as having read-tree accept > 3
> > trees and ignore everything but the last 3. Am I correct in assuming that
> > if I brea
On Wed, 24 Aug 2005, Daniel Barkalow wrote:
> Of course, this is going to take a bit of work, because read-tree
> currently puts all of its arguments into the cache and then works on
> merging, and taking multiple ancestors requires putting them somewhere
> else, because they won&
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
On Thu, 25 Aug 2005, Junio C Hamano wrote:
> One thing that makes me reluctant to recommend this "merging
> unrelated projects" business is that I suspect that it makes
> things _much_ harder for the upstream project that is being
> merged, and should not be done without prior arrangement; Linus
>
On Thu, 25 Aug 2005, Jan Veldeman wrote:
> Daniel Barkalow wrote:
>
> > I'm not sure how applicable to this situation stgit really is; I see stgit
> > as optimized for the case of a patch set which is basically done, where
> > you want to keep it applicable to
On Wed, 24 Aug 2005, A Large Angry SCM wrote:
> Daniel Barkalow wrote:
> > I'm starting to work on letting the merging process see multiple
> > ancestors, and I think it's messy enough that I should actually discuss
> > it.
> >
> > Review of the issue
I'm starting to work on letting the merging process see multiple
ancestors, and I think it's messy enough that I should actually discuss
it.
Review of the issue:
It is possible to lost reverts in cases when merging two commits with
multiple ancestors, in the following pattern: (letters representi
On Wed, 24 Aug 2005, Carl Baldwin wrote:
> This is interesting. Can a ref be to a tree rather than a commit? And
> it still works? I guess it would. I hadn't thought about that.
Generally, each subdirectory of refs/ has refs to objects of the same
type, and heads/ is commits, but other direct
On Wed, 24 Aug 2005, Carl Baldwin wrote:
> This brings up a good point (indirectly). "git prune" would destroy the
> undo objects. I had thought of this but decided to ignore it for the
> time being.
If you made undo store the tree under refs somewhere, git prune would
preserve it.
-Da
On Wed, 24 Aug 2005, Linus Torvalds wrote:
> Now, if the shared patch hadn't been a patch, but a shared _commit_, then
> the thing would have been unambiguous - the shared commit would have been
> the merge point, and the revert would have clearly undone that shared
> commit.
Actually, it was a s
On Wed, 24 Aug 2005, Martin Schlemmer wrote:
> Hi,
>
> Recently cogito again say that the rsync method will be deprecated in
> future (due to http-pull now supporting pack objects I suppose), but it
> seems to me that it still have other issues:
>
> -
> lycan linux-2.6 # git pull origin
> Fetc
On Wed, 24 Aug 2005, Junio C Hamano wrote:
> [EMAIL PROTECTED] writes:
>
> > So I have another anomaly in my GIT tree. A patch to
> > back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c
> > in my release branch at commit
> >
> > 62d75f3753647656323b0365faa43fc1a8f7be97
> >
> > appears
On Tue, 23 Aug 2005, Junio C Hamano wrote:
> Only lightly tested, in the sense that I did only this one case
> and nothing else. For a large repository and with complex
> merges, "merge-base -a" _might_ end up reporting many
> candidates, in which case the pre-merge step to figure out the
> best
On Tue, 23 Aug 2005, Carl Baldwin wrote:
> The thing that this doesn't do is remove empty directories when the last
> file is deleted. I once expressed the opinion in a previous thread that
> directories should be added and removed explicitly in git. (Thus
> allowing an empty directory to be add
On Tue, 23 Aug 2005, Jan Veldeman wrote:
> Daniel Barkalow wrote:
>
> > On Tue, 23 Aug 2005, Catalin Marinas wrote:
> >
> > Something is legitimate as a parent if someone took that commit and did
> > something to it to get the new commit. The operation which caused t
On Tue, 23 Aug 2005, Carl Baldwin wrote:
> The point is to push and use a post-update hook to do the checkout. So,
> this won't be possible.
You could have the remote repository be something like
"~/git/website.git", and have a hook which does: "cd ~/www; git pull
~/git/website.git/". That is, h
On Tue, 23 Aug 2005, Carl Baldwin wrote:
> On Tue, Aug 23, 2005 at 03:43:56PM -0400, Daniel Barkalow wrote:
> > On Tue, 23 Aug 2005, Carl Baldwin wrote:
> >
> > > Hello,
> > >
> > > I recently started using git to revision control the source for my
>
On Tue, 23 Aug 2005, Carl Baldwin wrote:
> Hello,
>
> I recently started using git to revision control the source for my
> web-page. I wrote a post-update hook to checkout the files when I push
> to the 'live' repository.
>
> In this particular context I decided that it was important to me to rem
On Tue, 23 Aug 2005, Catalin Marinas wrote:
> > So the point is that there are things which are, in fact, parents, but we
> > don't want to list them, because it's not desired information.
>
> What's the definition of a parent in GIT terms? What are the
> restriction for a commit object to be a pa
On Sun, 21 Aug 2005, Jan Veldeman wrote:
> Catalin Marinas wrote:
>
> > > So for example, you only tag (freeze) the history when exporting the
> > > patches. When an error is being reported on that version, it's easy to
> > > view
> > > it and also view the progress that was already been made on
On Fri, 19 Aug 2005, Martin Langhoff wrote:
> On 8/19/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> > Martin Langhoff <[EMAIL PROTECTED]> writes:
> >
> > > If I remember correctly, Junio added some stuff in the merge & rebase
> > > code that will identify if a particular patch has been seen and
On Fri, 19 Aug 2005, Martin Langhoff wrote:
> After using arch for a while, I've gotten used to getting .rej and
> .orig files instead of big ugly conflict markers inside the file.
> Emacs has a nice 'diff' mode that is a boon when dealing with
> conflicts this way.
>
> Is there a way to convince
On Thu, 18 Aug 2005, Johannes Schindelin wrote:
> tree object::
> - An object containing a list of blob and/or tree objects.
> - (A tree usually corresponds to a directory without
> - subdirectories).
> + An object containing a list of file names and modes along with refs
> +
On Wed, 17 Aug 2005, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 17 Aug 2005, Daniel Barkalow wrote:
>
> > On Wed, 17 Aug 2005, Johannes Schindelin wrote:
> >
> > > object name::
> > > Synonym for SHA1.
> >
> > Have we killed the use of th
On Wed, 17 Aug 2005, Johannes Schindelin wrote:
> Hi,
>
> long, long time. Here?s my first stab at the glossary, attached the
> alphabetically sorted, asciidoc marked up txt file (Comments?
> Suggestions? Pizzas?):
>
> object::
> The unit of storage in GIT. It is uniquely identified by
>
On Tue, 16 Aug 2005, Linus Torvalds wrote:
> If you use the GIT_DIR environment variable approach, it assumes that all
> filenames you give it are absolute and acts the way it always did before.
>
> Comments? Like? Dislike?
I'm all in favor, at least in the general case. I suspect there'll be som
On Tue, 16 Aug 2005, Marco Costalba wrote:
> Martin Langhoff wrote:
>
> >>From what I understand, you'll want the StGIT infrastructure. If you
> >use git/cogito, there is an underlying assumption that you'll want
> >all the patches merged across, and a simple cg-update will bring in
> >all the pe
On Tue, 16 Aug 2005, Linus Torvalds wrote:
> Finally, I have to say that that "info" directory is confusing. Namely,
> there's two of them - the "git info" and the "object info" directories are
> totally different directories - maybe logical, but to me it smells like
> "info" is here a code-name f
On Tue, 16 Aug 2005, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 16 Aug 2005, Junio C Hamano wrote:
>
> > - Are all the files in Documentation/ reachable from git(7)
> > or otherwise made into a standalone document using asciidoc
> > by the Makefile? I haven't looked into documentation
On Tue, 16 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > It might be worth putting the list of things left to do before 1.0 in the
> > tree (since they clearly covary), and it would be useful to know what
> > you're think
If it doesn't find an object, it looks for an index that contains it
and uses the same methods on that instead.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
local-pull.c | 112 +++---
1 files changed, 91 insertions(+), 2
Note that the pack file has to be in the usual location if it gets
installed later.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
cache.h |2 ++
sha1_file.c | 10 --
2 files changed, 10 insertions(+), 2 deletions(-)
59e5c6d163edae5da6136560d48a4750cceacdc6
diff
This adds essentially the same logic to local-pull that http-pull has,
with the exception that it reads the index out of the source directory,
rather than copying it. This, in turn, requires the ability to use an
index file in some other directory.
1: Use index file in another directory
2: Co
On Mon, 15 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > I should be able to get http-pull down to the neighborhood of
> > (current) ssh-pull; http-pull is that slow (when the source repository
> > isn't packed) becau
On Mon, 15 Aug 2005, Junio C Hamano wrote:
> Ryan Anderson <[EMAIL PROTECTED]> writes:
>
> > I was waiting until you said, "Ok, 1.00 tomorrow morning"
>
> Makes sense. There would be some weeks until that happens I am
> afraid.
It might be worth putting the list of things left to do before 1.0
On Sat, 13 Aug 2005, Petr Baudis wrote:
> Hello,
>
> I've wondered how slow the protocols other than rsync are, and the
> (well, a bit dubious; especially wrt. caching on the remote side)
> results are:
>
> git clone-pack:ssh 25s
> git rsync 27s
> git
On Sat, 13 Aug 2005, Martin Langhoff wrote:
> >Yes, developers can just merge with each other directly
>
> I take it that you mean an exchange of patches that does not depend on
> having public repos. What are the mechanisms available on that front,
> other than patchbombs?
If each developer
On Fri, 12 Aug 2005, Linus Torvalds wrote:
> And it's possible that git usage won't expand all that much either. But
> quite frankly, I think git is a lot better than CVS (or even SVN) by now,
> and I wouldn't be surprised if it started getting some use outside of the
> git-only and kernel project
On Fri, 12 Aug 2005, Wolfgang Denk wrote:
> This is somewhat off topic here, so I apologize, but I didn't know
> any better place to ask:
>
> Has anybody any information if SourceForge is going to provide git /
> cogito / ... for the projects they host? I asked SF, and they openend
> a new Fe
On Fri, 12 Aug 2005, Junio C Hamano wrote:
> Good intentions, but I'd rather see these S-O-B lines in the
> actual commit objects. Giving format-patch this option would
> discourage people to do so. Maybe a patch to git commit would
> be more appropriate, methinks.
Maybe also something in forma
On Thu, 11 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > Petr Baudis <[EMAIL PROTECTED]> writes:
> >> Yes, but cg-clone doesn't - it naively depended on the core git tools
> >> actually, er.. working. ;-)
>
int, I have to revisit getting git-ssh-* to generate exactly the
required pack and transfer that, but that's an efficiency issue, not a
correctness one, and shouldn't be relevant to the problem you're having.
---
[PATCH] Also parse objects we already have
In the case where we do
On Thu, 11 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > It should work anyway,...
>
> That is true. Please forget about the "recommendation" to slurp
> packs and not falling back on commit walker.
>
> Th
It didn't refetch an object it already had (good), but didn't process
it, either (bad). Synchronously process anything you already have.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
pull.c | 57 -
1 files changed
On Fri, 5 Aug 2005, Linus Torvalds wrote:
> On Fri, 5 Aug 2005, Johannes Schindelin wrote:
>
> > - The files under $GIT_DIR/refs record object names, and are
> > called "refs". What is under refs/heads/ are called "heads",
> > refs/tags/ "tags". Typically, they are either object names
On Thu, 4 Aug 2005, Johannes Schindelin wrote:
> > * Make git-init-db create an absolute minimum $GIT_DIR
> > structure itself, if the template directory is not available,
> > possibly with a warning.
>
> This would be exactly what I'd like. Let git-init-db create
> .git/objects/[0-9a-f]{2}/, .gi
On Thu, 4 Aug 2005, Petr Baudis wrote:
> Dear diary, on Wed, Aug 03, 2005 at 07:11:00PM CEST, I got a letter
> where [EMAIL PROTECTED] told me that...
> > IIRC, git-local-pull still doesn't work for a packed source repository,
> > because it doesn't include the possibility of copying a pack (or
IIRC, git-local-pull still doesn't work for a packed source repository,
because it doesn't include the possibility of copying a pack (or
extracting an object) if the requested object is in a pack.
I can probably fix it if anyone cares, but it's not something I use
personally, so I don't know if
, because it would always get a short read at
the end of an object, because the next object had not been
requested. This is no longer true.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
cache.h |3 ++-
sha1_file.c | 37 ++---
ssh-pull.c
(), this should have no effect.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
http-pull.c |4 ++
local-pull.c |4 ++
pull.c | 132 ++
pull.h |7 +++
ssh-pull.c |4 ++
5 files changed, 97 inse
Add function to look up an object which is entirely unknown, so that
it can be put in a list. Various other functions related to lists of
objects.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
object.c | 55 ++-
object.h
This series pipelines pulling by ssh; objects are requested as soon as
possible, and read once as many hashes as possible have been stuffed in
the queue. This seems to be a major improvement in throughput, although it
doesn't do any packing, so the total data transferred is higher than it
could
I think I've now got the parallel pull use in ssh-pull to the point where
it could be useful to post. Similar stuff should work for http-pull (where
it will probably be more interesting), but I have to read more libcurl
documentation.
Initial results on ssh-pull are encouraging: on my local eth
.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
http-pull.c |4 ++
local-pull.c |4 ++
pull.c | 128 ++
pull.h |7 +++
ssh-pull.c |4 ++
5 files changed, 93 insertions(+), 54 del
1 - 100 of 202 matches
Mail list logo
