Re: Couple of read-tree questions
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 populated working tree) You are correct. I was wondering myself why *both* of us thought (or Linus *seemed* to be agreeing, at least to me) what I was referring to as I+H made any sense while re-reaing the thread. > I should have asked sooner, then. :) There's a bunch of clutter to get it > to work that I can remove if it's not actually necessary. Yeah, removal of dead code! Go wild, please. - 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.kernel.org/majordomo-info.html
Re: Couple of read-tree questions
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 complain. > > I have never thought about using multiple trees without -m, and > I do not remember hearing any plan nor purpose of using it to do > something interesting from Linus. I think its allowing multiple > trees without -m is simply a bug. I guess it was probably that its behavior was obvious and didn't require any extra code. It still follows entirely from one tree without -m, but it might be worth prohibiting unless someone has a reason to do it intentionally. > > 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 that git was supposed to work without > having _any_ files in the working tree. The reason why > multi-tree read-tree has so many special cases that says "must > match *if* work file exists", is that not having a corresponding > working file was supposed to be equivalent to having the file > checked out *and* unmodified. But they'd not only be missing from the working tree but also from the (pre-read-tree) index, which should only happen, assuming the index came from "read-tree H", if they were subsequently removed from the index. I'd understand treating index entries for files missing from the working tree as up to date. (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 populated working tree) > I do not think anybody currently uses --emu23. I did it because > it has a potential of making the two-tree fast forward (which is > used in "git checkout" to switch between branches) easier to > manage when the working tree is dirty than doing straight > two-tree merge, but that is just a theoretical potential never > tested in the field. Frankly, I do not mind, and I do not think > anybody else minds, too much if you need to break or remove > emu23 if that would make your code clean-up and redoing > read-tree easier. I should have asked sooner, then. :) There's a bunch of clutter to get it to work that I can remove if it's not actually necessary. -Daniel *This .sig left intentionally blank* - 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.kernel.org/majordomo-info.html
Re: Couple of read-tree questions
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 things than my faulty memory. The thread beginning here is a good summary of the thinking behind the current design: http://article.gmane.org/gmane.comp.version-control.git/4737 - 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.kernel.org/majordomo-info.html
Re: Couple of read-tree questions
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 without -m, and I do not remember hearing any plan nor purpose of using it to do something interesting from Linus. I think its allowing multiple trees without -m is simply a bug. > 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 that git was supposed to work without having _any_ files in the working tree. The reason why multi-tree read-tree has so many special cases that says "must match *if* work file exists", is that not having a corresponding working file was supposed to be equivalent to having the file checked out *and* unmodified. That assumption and design goal was partially broken at around the beginning of June when we started touching working tree during a merge. Until that timeframe, we did not touch (nor even look at) files in the working tree during the merge, mainly due to the desire of performing the merge operation entirely in the cache (which was the name of "index file" back then). I do not think anybody currently uses --emu23. I did it because it has a potential of making the two-tree fast forward (which is used in "git checkout" to switch between branches) easier to manage when the working tree is dirty than doing straight two-tree merge, but that is just a theoretical potential never tested in the field. Frankly, I do not mind, and I do not think anybody else minds, too much if you need to break or remove emu23 if that would make your code clean-up and redoing read-tree easier. - 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.kernel.org/majordomo-info.html
Re: bug in git-fsck-cache?
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 does fsck-cache report it as >> > dangling? >> >> Hmph. You ran fsck-cache by hand without --full (i.e. you told >> it not to worry about objects already in packs); 'git prune' >> runs it with '--full' to do the full connectivity analysis. I >> think that's where the difference comes from. > > ok, with '--full' nothing gets reported as dangling. That commit is not > in a pack, but is in an object directory referenced through > objects/info/alternates. Ahh. Yes, it is the same thing. I said "not in the pack", but I should have said "exists locally unpacked". - 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.kernel.org/majordomo-info.html
Re: bug in git-fsck-cache?
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 not get rid of it, but why does fsck-cache report it as > > dangling? > > Hmph. You ran fsck-cache by hand without --full (i.e. you told > it not to worry about objects already in packs); 'git prune' > runs it with '--full' to do the full connectivity analysis. I > think that's where the difference comes from. ok, with '--full' nothing gets reported as dangling. That commit is not in a pack, but is in an object directory referenced through objects/info/alternates. > Is that commit reachable from any of the refs hanging under your > $GIT_DIR/refs/? For example, do you have the Linus tip of the > master branch in $GIT_DIR/refs/heads/origin? yes, master == origin and that commit is reachable from master according to gitk. > If an object is already in a pack and later became unreachable > from any of your refs, there is no way to remove that object > from the pack, so dangling commits in a pack will be left > dangling even after 'git prune'. It is still reachable as fsck-cache --full shows (I guess). Cheers, Stephen Rothwell - 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.kernel.org/majordomo-info.html
What's in git.git today.
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 for your repository' section, that talks not just about packing, but the general repository organization issues like: - Public (naked) repository vs working tree repository. - What each hook is for. - Why pack? When to pack? - Why prune? When to prune? - Should I use objects/info/alternates? - Transport specific hints: - For dumb transports, update-server-info is a must. - For git: transport, 'git-daemon-export-ok' is needed. - Git-native transport is inefficient when bootstrapping. But other than that I consider the tutorial in a pretty good shape. ... and that can only mean one thing. I want to really start 1.0pre, but I'd settle for 0.99.6 for now. By the way. A couple of people privately asked me what the extra "branch" `todo` is doing in the git.git repository. That "branch" does not share any tree namespace with the real git source. Its tree has only one blob, TODO, and keeps my notes on the current progress. So you should *not* do this: $ git clone kernel.org/pub/scm/git/git.git/ $ git pull . todo You would end up merging completely different things together if you did so. There is another mystery branch called "dbrt-test"; I'll blow it away after we are done with the read-tree change Daniel is working on. The changed read-tree code looks much cleaner and I like the general direction it is going, but there are some debugging ahead of us. That mystery branch holds standalone test suite that is supposed to be extracted in a repository independent from the main git repository, so please do not merge from it, either. - 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.kernel.org/majordomo-info.html
Re: bug in git-fsck-cache?
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-cache by hand without --full (i.e. you told it not to worry about objects already in packs); 'git prune' runs it with '--full' to do the full connectivity analysis. I think that's where the difference comes from. Is that commit reachable from any of the refs hanging under your $GIT_DIR/refs/? For example, do you have the Linus tip of the master branch in $GIT_DIR/refs/heads/origin? If an object is already in a pack and later became unreachable from any of your refs, there is no way to remove that object from the pack, so dangling commits in a pack will be left dangling even after 'git prune'. Originally, the distinction between with and without --full was made so that once you fsck and repack, you do not have to spend time doing full object integrity analysis (I think it still does full reachability analysis, but I have to check). It might be better to remove '--full' option from fsck-cache and make the default ot do full integrity, and introduce '--fast' option to skip it, that is, to default on the safe side. - 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.kernel.org/majordomo-info.html
Re: My Embarrasingly Stupid Git question....(*)
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 involved in git was to help people who do Linux kernel, so any question regarding the Linus kernel tree extracted from a copy of his git repository is welcome here, at least to me. I do not know Cogito very well. I keep the latest Cogito source around all the time so that I can figure things out whenever need arises by reading it. Most of the time, I would not offhand know answers to questions like "what does cg-rm do and what's the difference between it and 'cvs rm'". Using the core GIT tools only, the sequence of what you did would have been: $ git clone && cd $ git checkout -b jdl master $ rm include/asm-ppc/sockios.h $ rm include/asm-ppc/socket.h $ rm include/asm-ppc64/sockios.h $ rm include/asm-ppc64/socket.h $ git add include/asm-powerpc/sockios.h $ git add include/asm-powerpc/socket.h $ git commit -a -s - 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.kernel.org/majordomo-info.html
Re: please pull ppc64-2.6.git
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/git/torvalds/linux-2.6/objects > > objects/info/alternates" looks like a horrible hack). There has never been a way to publish a partial GIT repository. I personally am not convinced it is even a good idea for people to be able to do so. $GIT_OBJECT_DIRECTORY/info/alternates is a mechanism to solve completely different issue -- borrowing objects locally from different object store to save space. This is only a local 'repository organization' issue, just like packing objects or leaving them unpacked in a repository _should_ not make any difference to people who are interacting with it. The use of info/alternates is internal to the git aware server side, be it git-daemon and git-upload-pack when somebody fetches from it, or git-receive-pack when somebody pushes into it. The other end _should_ never have to care if the repository uses info/alternates, just like it _shouldn't_ matter if the repository is packed or unpacked. Most importantly, for people who are interacting with it, the repository has _everything_ it claims to have by having pointers to head commits under refs/ hierarchy, and is _not_ partial at all. Yes, you could peek into the remote repository filesystem by other means, and even slurp the info/alternates file via rsync, but as stated many times before, a lot of things that rsync does are by accident not by design. Some historical explanation may be helpful. info/alternates is merely an improvement for existing ALTERNATE_OBJECT_DIRECTORIES mechanism. The latter required individual processes to tell git what other object stores to consult to find missing objects when working on a repository whose object store is a partial object database. This was clearly not per-process information; it was specific to that partial object store, and that was the reason info/alternates was invented. The processes do not have to have that environment variable; instead the necessary information is recorded in the partial object store itself. I kept saying '_should_' because commit walkers would not currently understand alternates, just like they had trouble with packed repositories earlier. This _is_ a defect, but I personally feel that this is a problem not worth solving. Earlier, when commit walkers did not understand packed repositories, the only workaround was 'then do not pack your public repository'. This was unacceptable from storage consumption point of view, and it had to be solved in some way. Daniel solved it for 0.99.4. But what info/alternates does is different. If you care about commit walkers (and I certainly do), there are other means to save space without using info/alternates; first try packing, and then hard linking object files with whichever other repository you would have placed in info/alternates, and you are done. Now you may argue that being able to publish truly partial repository that does not have all the objects and depends on some other repository, very likely to be on completely different server (otherwise you would not be advocating for a non-local path such as URL) a worthwhile goal. I personally do not even believe that a repository relying on a foreign object store is a good idea, and much less so if you are making that repository publicly available. I like your local-mirror-mapping idea very much, but I do not think it is something that is specific to git. If you have such a mechanism to map remote URL into local filesystem namespace and automount/mirror them on demand, I'd like to be able to use that when I am browsing files in my Emacs (yes, there is 'ange-ftp') or even 'cat' files from it. Its more useful that way than limiting its use to only when git wants to find missing object files from its alternate object store. - 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.kernel.org/majordomo-info.html
Re: [RFC] Stgit - patch history / add extra parents
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 of everything that happened > > elsewhere. The point is to be able to reach some commits between which > > there are interesting diffs. > > > > This also depends on how exactly freeze is used; if you use it before > > commiting a modification to the patch without rebasing, you get: > > > > old-top -> new-top > > ^^ > >\ / > > bottom > > > > bottom to old-top is the old patch > > bottom to new-top is the new patch > > old-top to new-top is the change to the patch > > > > Then you want to keep new-top as a parent for rebasings until one of these > > is frozen. These links are not interesting to look at, but preserve the > > path to the old-top:new-top change, which is interesting. > > This was my initial StGIT implementation (up to version 0.3), only that > there was no freeze command. Since I want an StGIT tree to be clean to > the outside world, I wouldn't keep multiple parents for the visible top > of a patch. > > As I understand from Junio's and Linus' e-mails (on the 23rd of August), > there might be problems with merging the HEAD of an StGIT-managed tree > if the above method is accessible via HEAD. Right, you'd want a separate head which is what you ask people to merge; the rest is only visible to people who are working on preparing the patch. But you could keep both sets of stuff (sharing tree objects but not commits). > > Ignoring the links to the corresponding bottoms, the development therefore > > looks like: > > > > local1 -> local2 -> merge -> local3 -> merge > > ^ ^ ^ > > mainline>-->->-->-->-> > > > > And this is how development is normally supposed to look. The trick is to > > only include a minimal number of merges. > > A merge occurs every time a patch is rebased. Anyway, having the bottoms > in the graph (which is the main idea of StGIT) together with the old-top > (or frozen state) parents make the graph pretty complicated. It should be possible to drop merges such that there's only one between any pair of local changes. That is, if you rebase at the end of the line above, it would get as parents local3 and the new bottom, not the last merge and the new bottom. The mainline changes only come in through the bottoms, so higher levels should look the same, but with the lower levels in the place of mainline. -Daniel *This .sig left intentionally blank* - 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.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Reorganize read-tree
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 know which of > > the common ancestors contributed which, and, if some of them don't have a > > path, we wouldn't be able to tell. > > I don't have time to look at the patch and I don't have a good > knowledge of the GIT internals, so I will just ask. Does this patch > changes the call convention for git-merge-one-file-script? I have my > own script for StGIT and I would need to know whether it is affected > or not. Nope, it only changes the trivial merge calling convention within read-tree.c; I think it's plausible that we might like to add information at some point, but the short-term goal is just to prevent a few bad cases in trivial merges. - 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.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Reorganize read-tree
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 patch to SubmittingPatches, MUA specific help section for > users of Pine 4.63 would be very much appreciated. Ah, it looks like a recent version changed the default behavior to do the right thing, and inverted the sense of the configuration option. (Either that or Gentoo did it.) So you need to set the "no-strip-whitespace-before-send" option, unless the option you have is "strip-whitespace-before-send", in which case you should avoid checking it. I don't actually have things set up for preparing patches from work, although I can resend the patches I prepared earlier. -Daniel *This .sig left intentionally blank* - 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.kernel.org/majordomo-info.html
[PATCH 1/2 (resend)] Object model additions for read-tree
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(-)
49d33c385aa69d17c991300f73e77c6718a2b4a6
diff --git a/object.c b/object.c
--- a/object.c
+++ b/object.c
@@ -184,6 +184,17 @@ struct object_list *object_list_insert(s
return new_list;
}
+void object_list_append(struct object *item,
+ struct object_list **list_p)
+{
+ while (*list_p) {
+ list_p = &((*list_p)->next);
+ }
+ *list_p = xmalloc(sizeof(struct object_list));
+ (*list_p)->next = NULL;
+ (*list_p)->item = item;
+}
+
unsigned object_list_length(struct object_list *list)
{
unsigned ret = 0;
diff --git a/object.h b/object.h
--- a/object.h
+++ b/object.h
@@ -41,6 +41,9 @@ void mark_reachable(struct object *obj,
struct object_list *object_list_insert(struct object *item,
struct object_list **list_p);
+void object_list_append(struct object *item,
+ struct object_list **list_p);
+
unsigned object_list_length(struct object_list *list);
int object_list_contains(struct object_list *list, struct object *obj);
diff --git a/tree.c b/tree.c
--- a/tree.c
+++ b/tree.c
@@ -1,5 +1,7 @@
#include "tree.h"
#include "blob.h"
+#include "commit.h"
+#include "tag.h"
#include "cache.h"
#include
@@ -212,3 +214,20 @@ int parse_tree(struct tree *item)
free(buffer);
return ret;
}
+
+struct tree *parse_tree_indirect(const unsigned char *sha1)
+{
+ struct object *obj = parse_object(sha1);
+ do {
+ if (!obj)
+ return NULL;
+ if (obj->type == tree_type)
+ return (struct tree *) obj;
+ else if (obj->type == commit_type)
+ return ((struct commit *) obj)->tree;
+ else if (obj->type == tag_type)
+ obj = ((struct tag *) obj)->tagged;
+ else
+ return NULL;
+ } while (1);
+}
diff --git a/tree.h b/tree.h
--- a/tree.h
+++ b/tree.h
@@ -32,4 +32,7 @@ int parse_tree_buffer(struct tree *item,
int parse_tree(struct tree *tree);
+/* Parses and returns the tree in the given ent, chasing tags and commits. */
+struct tree *parse_tree_indirect(const unsigned char *sha1);
+
#endif /* TREE_H */
-
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.kernel.org/majordomo-info.html
[PATCH 2/2 (resend)] Change read-tree to merge before using the index.
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/read-tree.c
@@ -5,28 +5,280 @@
*/
#include "cache.h"
-static int stage = 0;
+#include "object.h"
+#include "tree.h"
+
+static int merge = 0;
+static int emu23 = 0;
static int update = 0;
-static int unpack_tree(unsigned char *sha1)
+static struct object_list *trees = NULL;
+
+typedef int (*merge_fn_t)(struct cache_entry **src,
+ struct cache_entry **dest,
+ int df_conflicts_2,
+ int df_conflicts_3);
+
+static int unpack_trees_rec(struct tree_entry_list **posns, int len,
+ const char *base, merge_fn_t fn,
+ int file2, int file3, int *indpos)
+{
+ int baselen = strlen(base);
+ int src_size = len + 1;
+ if (emu23)
+ src_size++;
+ if (src_size > 4)
+ src_size = 4;
+ do {
+ int i;
+ char *first = NULL;
+ int pathlen;
+ unsigned ce_size;
+ int dir2 = 0;
+ int dir3 = 0;
+ int subfile2 = file2;
+ int subfile3 = file3;
+ struct tree_entry_list **subposns = NULL;
+ struct cache_entry **src = NULL;
+ char *cache_name = NULL;
+
+ /* Find the first name in the input. */
+
+ /* Check the cache */
+ if (merge && *indpos < active_nr) {
+ /* This is a bit tricky: */
+ /* If the index has a subdirectory (with
+* contents) as the first name, it'll get a
+* filename like "foo/bar". But that's after
+* "foo", so the entry in trees will get
+* handled first, at which point we'll go into
+* "foo", and deal with "bar" from the index,
+* because the base will be "foo/". The only
+* way we can actually have "foo/bar" first of
+* all the things is if the trees don't
+* contain "foo" at all, in which case we'll
+* handle "foo/bar" without going into the
+* directory, but that's fine (and will return
+* an error anyway, with the added unknown
+* file case.
+*/
+
+ cache_name = active_cache[*indpos]->name;
+ if (strlen(cache_name) > baselen &&
+ !memcmp(cache_name, base, baselen)) {
+ cache_name += baselen;
+ first = cache_name;
+ } else {
+ cache_name = NULL;
+ }
+ }
+
+ for (i = 0; i < len; i++) {
+ if (!posns[i])
+ continue;
+ if (!first || strcmp(first, posns[i]->name) > 0)
+ first = posns[i]->name;
+ }
+ /* No name means we're done */
+ if (!first)
+ return 0;
+
+ pathlen = strlen(first);
+ ce_size = cache_entry_size(baselen + pathlen);
+
+ if (cache_name && !strcmp(cache_name, first)) {
+ src = xmalloc(sizeof(struct cache_entry *) *
+ src_size);
+ memset(src, 0,
+ sizeof(struct cache_entry *) *
+ src_size);
+ src[0] = active_cache[*indpos];
+ remove_cache_entry_at(*indpos);
+ if (emu23) {
+ // we need this in stage 2 as well as stage 0
+ struct cache_entry *copy =
+ xmalloc(ce_size);
+ memcpy(copy, src[0], ce_size);
+ copy->ce_flags =
+ create_ce_flags(baselen + pathlen, 2);
+ if (dir2 || file2) {
+ die("cannot merge index and our head
tree");
+ }
+ src[2] = copy;
+ subfile2 = 1;
+ }
+ }
+
+ for (i = 0; i < len; i++) {
+ struct cache_entry *ce;
+ int ce_stage;
+ if (!posns[i] ||
+
Re: [PATCH 0/2] Reorganize read-tree
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 which, and, if some of them don't have a > path, we wouldn't be able to tell. I don't have time to look at the patch and I don't have a good knowledge of the GIT internals, so I will just ask. Does this patch changes the call convention for git-merge-one-file-script? I have my own script for StGIT and I would need to know whether it is affected or not. Thanks. -- Catalin - 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.kernel.org/majordomo-info.html
Re: please pull ppc64-2.6.git
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 filesystem. > It also does opendir()/readdir()/closedir() to find what's > available. > > If you can arrange to automount via luserfs (or whatever; we do > not care much about particular implementation) so that it can do > these filesystem operations, git will happily use it. > > Even in that case, the alternate you would tell git should look > like a local filesystem path --- your automounting from remote > specified with URL for such a path would happen outside GIT. 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/git/torvalds/linux-2.6/objects > objects/info/alternates" looks like a horrible hack). What if we create a mapping layer from URLs to local mirrors of corresponding repositories? Store this mapping, e.g., in ~/.git-core/mirrors, then if git reads an URL instead of an absolute local path from objects/info/alternates, it will consult that file and either use the specified local mirror, or complain that a local copy of the base repository is not available. The partial repository will then contain no system-specific paths and could be published without problems. pgpgbKks1DKX5.pgp Description: PGP signature
Re: [RFC] Stgit - patch history / add extra parents
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 place, using stgit >> * still make changes (none of these gets tracked, intermittent versions are >> lost) >> * having a good day: changes looks good, I want to push this out: >> * push my tree out >> * stgit-free (which makes the pushed out commits, the new parents of my >> stgit patches) >> * restart from top > > 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 the mainline as the mainline advances. > > For your application, I'd just have a git branch full of various stuff, > and then generate clean commits by branching mainline, diffing development > against it, cutting the diff down to just what I want to push, and > applying that. Then the clean patch goes into stgit. StGIT has the 'refresh' command which allows a patch to be indefinitely modified (that's pretty much how I use StGIT). I use it for the case where I would like to keep the changes in separate logical entities (patches) but they are not independent enough to create separate branches. Take for example a new platform port, you can have some of the existing code re-worked in a patch, some CPU support in the next patch, basic platform support in another patch, some device drivers specific to this platform in yet another patch. Subsequent patches are dependent on the previous ones. Branching from the mainline for each of these features might not make sense and keeping all of them in the same branch can make maintenance a bit more difficult. -- Catalin - 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.kernel.org/majordomo-info.html
Re: [RFC] Stgit - patch history / add extra parents
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 these gets tracked, intermittent versions are > lost) > * having a good day: changes looks good, I want to push this out: > * push my tree out > * stgit-free (which makes the pushed out commits, the new parents of my > stgit patches) When the tree status looks good, you could tag it and the whole stack (the commits corresponding to the patches) would be available via this tag. As I said, I agree with the idea of freezing a patch and even having multiple parents to a commit but this commit should not be visible via HEAD. We could have another id for a patch, 'frozen', which stores the last frozen state with the parents being the previous frozen states. Its SHA1 value could be accessed via 'stg id /frozen' (in the same way as /top and /bottom ids). -- Catalin - 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.kernel.org/majordomo-info.html
Re: [RFC] Stgit - patch history / add extra parents
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.kernel.org/majordomo-info.html
