* Re: [RFC] gitweb wishlist and TODO list (part 1)
From: Junio C Hamano @ 2006-12-17 1:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Kernel Org Admin, Petr Baudis
In-Reply-To: <200612170000.06771.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> This is yet another series of planned gitweb features. This part
> concentrates on improving gitweb rather than on adding new features.
> Comments appreciated.
>
> Copy send to Kernel.Org admin (which probably is most interested
> in improving gitweb and git performance), and to Petr Baudis which
> maintains repo.or.cz public git hosting site, which runs new(est)
> version of gitweb.
To be honest, I think the 0th item of this wishlist and TODO
list would be to find a sucker^Wvolunteer who will maintain the
gitweb installation at kernel.org, for the message to be of any
interest to kernel.org admins.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Brian Gernhardt @ 2006-12-17 4:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodq3a136.fsf@assigned-by-dhcp.cox.net>
> ** jc/reflog (Thu Dec 14 15:58:56 2006 -0800) 1 commit
> - Teach show-branch how to show ref-log data.
>
> A strawman to make reflog data a bit more browsable; it would be
> useful while recovering from a mistake you made recently. Not
> essential and can wait or be dropped if people do not find it
> useful.
I'd prefer not to add clutter into show-branch. I use it on a
regular basis to see what I've added to what topic branch recently,
and to look at branches before rebasing. It also just seems like the
wrong place to have that kind of data, although I guess it's more
useful for people who do merges more often than I do.
What about a "git reflog [<branch>]" command instead? Would show
output similar to "git log" (or "git show-branch" for brevity).
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Shawn Pearce @ 2006-12-17 4:42 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Junio C Hamano, git
In-Reply-To: <3C540990-B78E-405B-ACFF-F558DB776C85@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> wrote:
> >** jc/reflog (Thu Dec 14 15:58:56 2006 -0800) 1 commit
> > - Teach show-branch how to show ref-log data.
>
> What about a "git reflog [<branch>]" command instead? Would show
> output similar to "git log" (or "git show-branch" for brevity).
It has been proposed on the list. I even sketched out what such
a command would look like, how it should present the data, etc.
But I never wrote it. Nobody else has taken up the task either. :-)
--
^ permalink raw reply
* [PATCH] revision: introduce ref@{N..M} syntax.
From: Junio C Hamano @ 2006-12-17 6:46 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <3C540990-B78E-405B-ACFF-F558DB776C85@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
>> ** jc/reflog (Thu Dec 14 15:58:56 2006 -0800) 1 commit
>> - Teach show-branch how to show ref-log data.
>>
>> A strawman to make reflog data a bit more browsable; it would be
>> useful while recovering from a mistake you made recently. Not
>> essential and can wait or be dropped if people do not find it
>> useful.
>
> I'd prefer not to add clutter into show-branch. I use it on a regular
> basis to see what I've added to what topic branch recently, and to
> look at branches before rebasing. It also just seems like the wrong
> place to have that kind of data, although I guess it's more useful
> for people who do merges more often than I do.
I happen to find it a reasonable way to present how a topic was
rewind and rebuilt, but I think that is I rewind my internal
topic (i.e. the parts that have not been merged into 'next' yet)
all the time.
> What about a "git reflog [<branch>]" command instead? Would show
> output similar to "git log" (or "git show-branch" for brevity).
This is not a 'git reflog' command, but is another way to show
the tips of reflog entries (use it with 'git show'). I find the
show-branch variant easier to see, but you can judge for
yourself.
This happens to show why pruning while not culling reflog
entries is a bad idea. If your master@{2} is gone due to rewind
and prune, and master@{0}, master@{1} and master@{3} are still
available, the pattern master@{0..3} would not give you a usable
result.
-- >8 --
This allows you to add between Nth and Mth (inclusive) reflog entries.
"git show master@{1} master@{2} master@{3}" is equivalent to
"git show master@{1..3}".
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
revision.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/revision.c b/revision.c
index 993bb66..3f1d65e 100644
--- a/revision.c
+++ b/revision.c
@@ -592,6 +592,59 @@ static void prepare_show_merge(struct rev_info *revs)
revs->prune_data = prune;
}
+static int parse_digits(const char *p, int len)
+{
+ int accum = 0;
+ while (0 < len--) {
+ int ch = *p++;
+ if ('0' <= ch && ch <= '9')
+ accum = accum * 10 + ch - '0';
+ else
+ return -1;
+ }
+ return accum;
+}
+
+static int list_of_reflog_entries(const char *arg, const char *dotdot,
+ struct rev_info *revs, int flags)
+{
+ /*
+ * "ref@{N..M}" -- push them for "git show".
+ * dotdot points at the first dot
+ */
+ int n, m, i, added;
+ int len;
+ char *at_brace = strstr(arg, "@{");
+
+
+ if (!at_brace)
+ return 0;
+ len = strlen(arg);
+ if (arg[len-1] != '}')
+ return 0;
+ if ((m = parse_digits(dotdot + 2, len - (dotdot - arg) - 3)) < 0)
+ return 0;
+ if ((n = parse_digits(at_brace + 2, dotdot - at_brace - 2)) < 0)
+ return 0;
+ if (n > m)
+ return 0;
+
+ added = 0;
+ for (i = n; i <= m; i++) {
+ char buf[1024];
+ unsigned char sha1[20];
+
+ snprintf(buf, sizeof(buf), "%.*s@{%d}",
+ (int) (at_brace - arg), arg, i);
+ if (!get_sha1(buf, sha1)) {
+ /* this is synthetic -- do not check filename */
+ handle_revision_arg(buf, revs, flags, 1);
+ added = 1;
+ }
+ }
+ return added;
+}
+
int handle_revision_arg(const char *arg, struct rev_info *revs,
int flags,
int cant_be_filename)
@@ -648,7 +701,13 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
add_pending_object(revs, &b->object, next);
return 0;
}
+
*dotdot = '.';
+
+ /* It could be ref@{N..M} */
+ if (list_of_reflog_entries(arg, dotdot, revs, flags))
+ return 0;
+
}
dotdot = strstr(arg, "^@");
if (dotdot && !dotdot[2]) {
--
1.4.4.2.g83c5
^ permalink raw reply related
* [PATCH] Default GIT_COMMITTER_NAME to login name in recieve-pack.
From: Shawn O. Pearce @ 2006-12-17 8:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If GIT_COMMITTER_NAME is not available in receive-pack but reflogs
are enabled we would normally die out with an error message asking
the user to correct their environment settings.
Now that reflogs are enabled by default in (what we guessed to be)
non-bare Git repositories this may cause problems for some users
who don't have their full name in the gecos field and who don't
have access to the remote system to correct the problem.
So rather than die()'ing out in receive-pack when we try to log a
ref change and have no committer name we default to the username,
as obtained from the host's password database.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
cache.h | 1 +
ident.c | 15 +++++++++++++++
receive-pack.c | 2 ++
3 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index bfab4f9..8ad5920 100644
--- a/cache.h
+++ b/cache.h
@@ -309,6 +309,7 @@ void datestamp(char *buf, int bufsize);
unsigned long approxidate(const char *);
extern int setup_ident(void);
+extern void ignore_missing_committer_name();
extern const char *git_author_info(int);
extern const char *git_committer_info(int);
diff --git a/ident.c b/ident.c
index e415fd3..d7faba6 100644
--- a/ident.c
+++ b/ident.c
@@ -221,3 +221,18 @@ const char *git_committer_info(int error_on_no_name)
getenv("GIT_COMMITTER_DATE"),
error_on_no_name);
}
+
+void ignore_missing_committer_name()
+{
+ /* If we did not get a name from the user's gecos entry then
+ * git_default_name is empty; so instead load the username
+ * into it as a 'good enough for now' approximation of who
+ * this user is.
+ */
+ if (!*git_default_name) {
+ struct passwd *pw = getpwuid(getuid());
+ if (!pw)
+ die("You don't exist. Go away!");
+ strlcpy(git_default_name, pw->pw_name, sizeof(git_default_name));
+ }
+}
diff --git a/receive-pack.c b/receive-pack.c
index ec3bab3..c9eaf55 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -420,6 +420,8 @@ int main(int argc, char **argv)
die("'%s': unable to chdir or not a git archive", dir);
setup_ident();
+ /* don't die if gecos is empty */
+ ignore_missing_committer_name();
git_config(receive_pack_config);
write_head_info();
--
^ permalink raw reply related
* Re: [RFC/PATCH] Change "refs/" references to symbolic constants
From: Andy Parkins @ 2006-12-17 9:00 UTC (permalink / raw)
To: git
In-Reply-To: <7vslffcy80.fsf@assigned-by-dhcp.cox.net>
On Saturday 2006, December 16 21:44, Junio C Hamano wrote:
> This is not rejected nor forgotten but has not been applied yet,
> and may not be immediately.
Oh good.
> I would love to have this; it would reduce mistakes (spelling
> "refs/head/" would silently compile fine and result in a broken
> command, while spelling PATH_REFS_HEAD would be caught by the
> compiler).
I'd not even considered that; I liked it because of a natural disinclination
towards repeated use semanitcally identical literals.
> A sad thing is this needs to be done when things are relatively
> quiescent.
While true - is there ever such a time? :-)
On the other hand, this is (hopefully) a zero-impact change, and should leave
the object the same... I might even test it by comparing objects.
> So I would apply this before v1.5.0 (or a replacement, if you
> have updates), but it might have to wait a bit until I I can say
> "ok, no big patches to C part is pending right now and it is a
> good time to do this clean-up".
If I know it's wanted I will happily maintain it indefinitely. It's part of
my rebase on master set anyway, so it's no pain to do so. I'll keep an eye
out for quiet times, or if you prod me when you want it I'll make you a
rebased version instantly.
While we're on this subject, does the same apply to my hashsize literals patch
which swapped 20 for HASH_WIDTH?
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* [PATCH] git-add: remove conflicting entry when adding.
From: Junio C Hamano @ 2006-12-17 9:11 UTC (permalink / raw)
To: git
In-Reply-To: <7vk60r7139.fsf@assigned-by-dhcp.cox.net>
When replacing an existing file A with a directory A that has a
file A/B in it in the index, 'git add' did not succeed because
it forgot to pass the allow-replace flag to add_cache_entry().
It might be safer to leave this as an error and require the user
to explicitly remove the existing A first before adding A/B
since it is an unusual case, but doing that automatically is
much easier to use.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
read-cache.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index e856a2e..b8d83cc 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -358,7 +358,7 @@ int add_file_to_index(const char *path, int verbose)
if (index_path(ce->sha1, path, &st, 1))
die("unable to index file %s", path);
- if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD))
+ if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE))
die("unable to add %s to index",path);
if (verbose)
printf("add '%s'\n", path);
--
1.4.4.2.g83c5
^ permalink raw reply related
* Re: Subprojects tasks
From: Alan Chandler @ 2006-12-17 8:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Martin Waitz
In-Reply-To: <7vzm9nelob.fsf@assigned-by-dhcp.cox.net>
On Saturday 16 December 2006 18:32, Junio C Hamano wrote:
> Because I am primarily a plumber, I was thinking about the
> changes that need to be done at the plumbing level. I only
> looked at the prototype when it was announced, and I do not know
> the progress you made since then. Could you tell us the current
> status?
>
> I am assuming that the overall design is based on what Linus
> proposed long time ago with his "gitlink" object. That is,
>
> * the index and the tree object for the superproject has a
> "link" object that tells there is a directory and the
> corresponding commit object name from the subproject. Unlike
> my previous "bind commit" based prototype, index does not
> have any blobs nor trees from the subproject.
>
> * the subproject is on its own, and can exist unaware of the
> existence of its superproject (there is no back-link at the
> object layer).
I have been following the submodules (subprojects - is there any
difference?) discussion from afar, getting lost quite frequently in
what is actually being discussed and why. I don't think the idea I
express below has been mentioned, but apologies if it has.
One element I felt has been missing is a vigorous discussion of what
submodules are for and what are their use cases. The "submodule is on
its own" issue seems to have crept into the discussion - but there was
one use case that was discussed, where some actually help by the
submodule could be useful.
The use case was when the supermodule wanted to make use of the header
files of the submodule because it was using the submodule as a library.
This did make me wonder if the submodule should not export some form
of "approved" set of content (or files - and I do think care is needed
here as to which it is when we think about renames) which is both
a) a subset of the full tree that is stored at commit time, and
b) does itself have a commit history
(I am clearly thinking that would be the standard "include" files, but
not the actual source of the library - (but it might include the
library it self as a prebuilt binary library?)
This does suggest it is a tree object stored in the repository - and
that it is linked in time via a set of commit objects - I'll call them
the "export commits". I am not sure whether a new commit should be
made everytime there is any change (via a normal commit) to this
content, or (and I slightly favour this) there is a new commit made
which is somewhat akin to a tag when the project wants to release a new
version of its interface.
Supermodules, which then made use of that library would, the do some
form of shallow clone, shallow in the sense that it only pulled in the
exported commit content and also (possibly) shallow in the sense that
it does not need to go back in time to get old versions of the exported
commit.
--
Alan Chandler
^ permalink raw reply
* Re: Subprojects tasks
From: Jakub Narebski @ 2006-12-17 10:01 UTC (permalink / raw)
To: git
In-Reply-To: <200612170848.10092.alan@chandlerfamily.org.uk>
Alan Chandler wrote:
> The use case was when the supermodule wanted to make use of the header
> files of the submodule because it was using the submodule as a library.
>
> This did make me wonder if the submodule should not export some form
> of "approved" set of content (or files - and I do think care is needed
> here as to which it is when we think about renames) which is both
>
> a) a subset of the full tree that is stored at commit time, and
> b) does itself have a commit history
>
> (I am clearly thinking that would be the standard "include" files, but
> not the actual source of the library - (but it might include the
> library it self as a prebuilt binary library?)
>
> This does suggest it is a tree object stored in the repository - and
> that it is linked in time via a set of commit objects - I'll call them
> the "export commits". I am not sure whether a new commit should be
> made everytime there is any change (via a normal commit) to this
> content, or (and I slightly favour this) there is a new commit made
> which is somewhat akin to a tag when the project wants to release a new
> version of its interface.
In the absence of sparse/partial checkout, and it's use in submodule
support, this can be solvd purely on porcelain level.
You would have to simply maintain separate 'includes' branch, similarly
to how 'html' and 'man' (and 'todo') branches are maintained in git.git
repository -- it would be your 'set of commit objects'. Then the only
think that would be needed is some commit / post-commit hook which would
examine if commit touches "include" files and if it does, make a commit
in the 'includes' ('inc' for short) branch.
Suportmodule would then use either 'master' branch for full sources,
or 'includes' branch for headers only.
P.S. Cc: Alan Chandler <alan@chandlerfamily.org.uk>,
Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Can git be tweaked to work cross-platform, on FAT32?
From: Martin Langhoff @ 2006-12-17 10:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Florian v. Savigny, git
In-Reply-To: <Pine.LNX.4.63.0612161227510.3635@wbgn013.biozentrum.uni-wuerzburg.de>
On 12/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > 3. ad Johannes: This does sound quite simple and straightforward. If I
> > got it right, it would involve having one repository on a, say,
> > ext2 partition to work with under Linux, and one on a FAT32
> > partition to work with under Windows, and syncing the two after
> > booting (fetching from FAT32) and before shutting down (pushing to
> > FAT32) Linux.
>
> This is how I'd do it.
And I concur - I had only introduced Samba to the conversation because
I thought you were talking about several computers. If you are
dual-booting on one machine, I'd do as above.
Note that under windows you can use ext2 -- haven't used it, and don't
know how cygwin behaves with it, but it may be *just* what you need to
avoid case sensitivity problems and have symlink support.
http://sourceforge.net/projects/ext2fsd
http://www.fs-driver.org/
cheers,
^ permalink raw reply
* Re: Subprojects tasks
From: Martin Waitz @ 2006-12-17 11:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzm9nelob.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 7963 bytes --]
hoi :)
On Sat, Dec 16, 2006 at 10:32:36AM -0800, Junio C Hamano wrote:
> Because I am primarily a plumber, I was thinking about the
> changes that need to be done at the plumbing level. I only
> looked at the prototype when it was announced, and I do not know
> the progress you made since then. Could you tell us the current
> status?
Most of the things you described are already implemented in
http://git.admingilde.org/tali/git.git/module2
If there is interest in it, I can generate some nice patches out of it.
However with Linus concerns about scalability I'm not sure it is ready
yet. But if you prefer patches for discussion I'll send them here.
> I am assuming that the overall design is based on what Linus
> proposed long time ago with his "gitlink" object. That is,
>
> * the index and the tree object for the superproject has a
> "link" object that tells there is a directory and the
> corresponding commit object name from the subproject. Unlike
> my previous "bind commit" based prototype, index does not
> have any blobs nor trees from the subproject.
In contrast to your description, my implementation does not
introduce a new "link" type but instead adds the reference to the
submodule commit directly to the parent tree object and to its
index.
> * the subproject is on its own, and can exist unaware of the
> existence of its superproject (there is no back-link at the
> object layer).
yes, this is essential.
There may be links in this particular instance of the submodule, i.e.
the repository/working directory which are checked out by the
supermodule may be coupled to the supermodule, but it must always
be possible to clone/push/pull the submodule alone.
> * the subproject and the superproject are loosely coupled. An
> act of committing in one does not automatically make a
> corresponding commit in the other at the plumbing level.
this is essential, too.
> With the index, in addition to the mode bits and "link" object's
> SHA-1, you would need to decide what to do with ce_match_stat(),
> to keep track of the information "update-index --refresh" updates.
> My recommendation is to:
>
> (1) Look at the directory the "link" is at, and find .git/
> subdirectory (that is the $GIT_DIR for the subproject) and
> its .git/HEAD;
>
> (2) If that points at a loose ref, use the file's stat()
> information (e.g stat("$sub/.git/refs/heads/master"));
>
> (3) Otherwise, use the packed-ref file's stat() information
> (e.g stat("$sub/.git/packed-refs")).
>
> Then ce_match_stat() for a "link" entry can do the same
> computation and tell if the subproject has changed its HEAD.
yes.
However I decicided not to read in HEAD but some specific branch.
This may sound arbitrary and I did not really like to make
"master" (the branch I chose) even more special, but you will
understand it when looking at the checkout below.
> Another issue with the index is what to put in the cache_tree
> structure; I think "link" can be treated just like blob (both
> files and symlinks).
Hmm, I never cared about cache_tree up to now. I guess I should learn
about it to understand the influence on submodules.
> Then read-tree (bulk of it is in unpack-trees.c) needs to be
> taught to read in "link" and put that into the index -- this
> should be straightforward.
>
> After you have a working index, you should be able to do
> write-tree (writes the new "link" entry as is, without
> descending into the subproject) trivially.
Where do you want to write the link to?
What I do here is update one branch ("master") of the submodule to
the new commit which was stored in the parent index.
If this branch is currently checked out, the working directory will
be updated, too. If there is no working directory for the submodule
yet, it will be created.
Updating one special branch instead of HEAD is because the submodule
commits which are stored in the supermodule really can be considered
as a special branch which happens to not be stored in an ordinary ref.
In order to make it visible to the user the commit is copied to a
normal ref.
This approach also integrates better with branches in the submodule.
When you want to start parallel development in a branch you eigther
want to do this in the complete supermodule scope -- then you have
to branch the supermodule --, or you want to do it independent to the
version stored in the supermodule -- then you don't want a supermodule
checkout to mess with your branch.
So it makes sense to have one branch which is tracked by the parent
and other branches which are independent from the parent.
> It is debatable what 'checkout-index -f' should do when the
> subproject is already checked out and its HEAD points at a
> different commit. I am tempted to say that it should go there
> and run "reset --hard", but I feel uneasy about that because it
> is a blatant layering violation. Maybe it should simply ignore
> link entries and let the Porcelain layer take care of them.
Where exactly do you see the layering violation?
Well I think it makes sense to use read-tree -m <old> <new> in the
submodule instead of a hard reset, but when the supermodule is checked
out the submodule really should move to its new version.
(At least the branch which is tracked by the parent should do so.)
> Then there are three diff- brothers at the plumbing level.
All the diff stuff is what is still missing in my implementation.
If you ask for a diff in the parent, it will happily diff the
submodules commit objects ;-)
> I suspect the hardest part is "rev-list --objects" (now most of
> it is found in revision.c). Theoretically, if the code can
> handle "tag"s, it should be able to handle "link"s, but I have a
> feeling that the ancestry traversal code that walks commits is
> not prepared to see "commit" object to appear from somewhere in
> the middle of traversal. A commit so far can be wrapped only by
> tags zero or more times, and a tag never appears inside anything
> but another tag, so the code can just keep peeling the tag until
> it sees a non-tag and after that it will be living in the world
> that has only commit->tree->blob hierarchy, and can afford to do
> the ancestry based solely on "commit" and can treat reachability
> for "tree" and "blob" as afterthought. But I think the updated
> code needs to know that "link" needs to be unwrapped and
> contained "commit" needs to be injected back to the ancestry
> walking machinery.
Well, a simple and dump version (i.e. my current implementation) can
just do the same for commits as it does for trees: just recursively
descend. Of course this is prohibitive in anything but toy projects.
A better approach is to put all the submodule commits on the pending
list and do the normal ancestry walk for them again. But this would
also need all reachable objects from all modules to be known to one
process.
This could be solved by having one pending list per submodule and
then flush all objects before moving to the next submodule, or
just processing the submodule in a different process.
But when the SEEN information is not shared between submodules then
rev-list could output the same object twice if a blob or tree is
used by several submodules. This may not be a problem if all the
code which processes rev-list output is idempotent, but I haven't
looked into this in detail.
Of course, when rev-list for submodules is already split out there
is the valid question if it really makes sense to descend into
submodules when doing rev-list.
Not doing so would natually decouple sub- from supermodule but then
a lot of operations that depend on rev-list (clone, push, pull)
have to be heavily modified.
Getting this straight in an efficient way is the next challenge.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: http git and curl 7.16.0
From: Sven Verdoolaege @ 2006-12-17 11:32 UTC (permalink / raw)
To: George Sherwood; +Cc: Git List
In-Reply-To: <20061118080708.428cbff6@athlon>
On Sat, Nov 18, 2006 at 08:07:08AM +0400, George Sherwood wrote:
> I seem to be having a problem doing an http checkout with git built
> with curl 7.16.0 enabled. If I build against curl 7.16.0 and try a
> clone, I get:
>
> git clone http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git
> error: Unable to start request error: Could not interpret heads/master
> as something to pull
>
> If I rebuild git against curl 7.15.5 then I get:
[..]
> and the checkout finishes.
>
> Has any one else seen this?
FWIW, I've seen the same with curl 7.16.0 on a Solaris 9 machine.
It worked fine with curl 7.15.0.
^ permalink raw reply
* Re: Subprojects tasks
From: Martin Waitz @ 2006-12-17 11:45 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Jakub Narebski, git
In-Reply-To: <200612170101.09615.Josef.Weidendorfer@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
hoi :)
On Sun, Dec 17, 2006 at 01:01:09AM +0100, Josef Weidendorfer wrote:
> IMHO it simply is added flexibility to allow a checkout to be separate from
> the .git/ directory, same as explicitly setting $GIT_DIR would do.
> So this .gitlink file is on the one hand one kind of convenience for users
> which want to keep their repository separate, yet do not want to specify
> $GIT_DIR all the time in front of git commands.
> The .gitlink file simply makes the linkage to the separate repository
> persistent.
I can see the reason for wanting to use another object database,
but HEAD and index should always be stored together with the
checked out directory. So perhaps we just need some smart way to
search for the object database, but keep the .git directory.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Subprojects tasks
From: Jakub Narebski @ 2006-12-17 13:01 UTC (permalink / raw)
To: Martin Waitz; +Cc: Josef Weidendorfer, git, Junio C Hamano
In-Reply-To: <20061217114546.GG12411@admingilde.org>
Martin Waitz wrote:
> On Sun, Dec 17, 2006 at 01:01:09AM +0100, Josef Weidendorfer wrote:
>> IMHO it simply is added flexibility to allow a checkout to be separate from
>> the .git/ directory, same as explicitly setting $GIT_DIR would do.
>> So this .gitlink file is on the one hand one kind of convenience for users
>> which want to keep their repository separate, yet do not want to specify
>> $GIT_DIR all the time in front of git commands.
>> The .gitlink file simply makes the linkage to the separate repository
>> persistent.
>
> I can see the reason for wanting to use another object database,
> but HEAD and index should always be stored together with the
> checked out directory. So perhaps we just need some smart way to
> search for the object database, but keep the .git directory.
Well, in the .gitlink proposal you could specify GIT_DIR for checkout,
or separately: GIT_OBJECT_DIRECTORY, GIT_INDEX_FILE, GIT_REFS_DIRECTORY
(does not exist yet), GIT_HEAD_FILE (does not exist yet, and I suppose
it wouldn't be easy to implement it). By the way, that's why I'm for
.gitlink name for the file, not .git -- this way .gitlink can "shadow"
what's in .git, for example specifying in a smart way where to search
(where to find) object database, but HEAD and index would be stored
together with the checked out directory in .git
By the way, I'm rather partial to supermodule following HEAD in submodule,
not specified branch. First, I think it is easier from implementation
point of view: you don't have to remember which branch supermodule should
take submodule commits from; and this cannot be fixed branch name like
'master'. For example 'maint' branch of supermodule could track 'maint'
branch of submodule, 'master' branch of supermodule track 'master'
branch of submodule, 'next' branch of supermodule tranck 'master' (!)
branch of submodule, 'pu' branch of supermodule track 'next' (!) branch
of submodule.
Second, if you want to do some independent work on the module not related
to work on submodule you should really clone (clone -l -s) submodule
and work in separate checkout; the complaint that with tracking HEAD
you can check-in wrong version of submodule to supermodule commit
doesn't hold, because you still would have problem that _tree_
of supermodule would have wrong version of submodule. And moving to
using single defined branch of submodule brings multitude of other
problems: for example you might usually track 'master' version of
submodule, but for a short time need to track 'next' branch because
it has functionality you need; and another time you need to move
to 'maint' branch or even your own branch because 'master' version
breaks something in supermodule.
Hmmm... I wonder how planned allowing to checking out tags, non-head
branches (e.g. tracking/remote branches) and arbitrary commits but
forbidding committing when HEAD is not a refs/heads/ branch would
affect submodules / subprojects...
--
Jakub Narebski
^ permalink raw reply
* Re: Subprojects tasks
From: Martin Waitz @ 2006-12-17 13:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Josef Weidendorfer, git, Junio C Hamano
In-Reply-To: <200612171401.10585.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6154 bytes --]
hoi :)
On Sun, Dec 17, 2006 at 02:01:09PM +0100, Jakub Narebski wrote:
> Well, in the .gitlink proposal you could specify GIT_DIR for checkout,
> or separately: GIT_OBJECT_DIRECTORY, GIT_INDEX_FILE, GIT_REFS_DIRECTORY
> (does not exist yet), GIT_HEAD_FILE (does not exist yet, and I suppose
> it wouldn't be easy to implement it). By the way, that's why I'm for
> .gitlink name for the file, not .git -- this way .gitlink can "shadow"
> what's in .git, for example specifying in a smart way where to search
> (where to find) object database, but HEAD and index would be stored
> together with the checked out directory in .git
What about .git/link or something?
(Obviously without the capability to change GIT_DIR)
> By the way, I'm rather partial to supermodule following HEAD in submodule,
> not specified branch. First, I think it is easier from implementation
> point of view: you don't have to remember which branch supermodule should
> take submodule commits from; and this cannot be fixed branch name like
> 'master'. For example 'maint' branch of supermodule could track 'maint'
> branch of submodule, 'master' branch of supermodule track 'master'
> branch of submodule, 'next' branch of supermodule tranck 'master' (!)
> branch of submodule, 'pu' branch of supermodule track 'next' (!) branch
> of submodule.
The version tracked by the supermodule is completely independent from
any branches you define in your submodule.
It is of course possible to use different versions of your submodule in
different branches of your supermodule. But the supermodule does not
know the name of these branches.
In the setup you described a git-checkout in the supermodule would have
to switch to a different branch in the submodule, depending on the
branchname which would have to be stored in the supermodule.
This a lot more complex.
Your scenario can also be solved in this way:
cd supermodule
(cd sub && git-reset --hard origin/master)
git add sub && git commit -m "track master of sub"
git checkout next
(cd sub && git-reset --hard origin/master)
git add sub && git commit -m "track master of sub"
git checkout pu
(cd sub && git-reset --hard origin/next)
git add sub && git commit -m "track next of sub"
git checkout maint
(cd sub && git-reset --hard origin/maint)
git add sub && git commit -m "track maint of sub"
You only store a link to the commit of the current submodule version,
just like a normal ref. The reference stored in the supermodule really
is equivalent to a normal ref, just that it is stored and updated
slightly different to a normal one.
So whenever you checkout a different version of the supermodule, the
submodule ref automatically gets the correct version. In the example
above, when you checkout supermodules pu, your submodules branch will be
reset to its origin/next (to be more precise: to the commit which was at
the tip of origin/next at the time it was stored in the supermodule).
The fact that the reference to the current submodule commit does not
only exist in the supermodule tree but also as a physical ref in the
submodule is very similiar to normal files: you have one version stored
in the object database, one in the index and one as a real file in the
working directory (and this working file is the equivalent of the
submodule ref which is stored in submodule/.git/refs/whatever)
The reference in the submodule is just a way to be able to work on
the submodule. Because well, refs are the kind of thing that is changed
by a commit. And these submodule commits are exactly the kind of work
you want to store in the supermodule. So the equivalent to a working
file is not the HEAD of the submodule, but the ref which gets all
changes which are intended for the supermodule.
The fact that the submodule repository still supports other branches has
nothing to do with submodule support. These branches are totally
independent from the supermodule.
> Second, if you want to do some independent work on the module not related
> to work on submodule you should really clone (clone -l -s) submodule
> and work in separate checkout;
Yes.
But I really like the possibility to switch one module to a branch which
is not tracked by the parent, because it perhaps contains some debugging
code which is needed to debug some other submodule. You can't move it
out because you need the common build infrastructure but you don't want
to branch the entire toplevel project because you don't want your
debugging changes to ever become visible at that level.
So by switching to a different branch you can effectivly say: this is
temporary, not meant for the superproject.
If you change your mind later you can always merge the submodule branch
back to master.
> the complaint that with tracking HEAD you can check-in wrong version
> of submodule to supermodule commit doesn't hold, because you still
> would have problem that _tree_ of supermodule would have wrong version
> of submodule.
Sorry, I don't understand you here.
> And moving to using single defined branch of submodule brings
> multitude of other problems: for example you might usually track
> 'master' version of submodule, but for a short time need to track
> 'next' branch because it has functionality you need; and another time
> you need to move to 'maint' branch or even your own branch because
> 'master' version breaks something in supermodule.
That is no problem.
The supermodule can track whatever _version_ it wants. You can set
it to any version which is available in the repository, including all
those well known external branches.
But the supermodule itself does not know (and should not know) about
"maint" / "next" / whatever branch names in the submodule.
> Hmmm... I wonder how planned allowing to checking out tags, non-head
> branches (e.g. tracking/remote branches) and arbitrary commits but
> forbidding committing when HEAD is not a refs/heads/ branch would
> affect submodules / subprojects...
It only affects submodules if you really track HEAD directly.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Subprojects tasks
From: Jakub Narebski @ 2006-12-17 14:29 UTC (permalink / raw)
To: Martin Waitz; +Cc: Josef Weidendorfer, git, Junio C Hamano
In-Reply-To: <20061217134848.GH12411@admingilde.org>
Martin Waitz wrote:
> On Sun, Dec 17, 2006 at 02:01:09PM +0100, Jakub Narebski wrote:
>> Well, in the .gitlink proposal you could specify GIT_DIR for checkout,
>> or separately: GIT_OBJECT_DIRECTORY, GIT_INDEX_FILE, GIT_REFS_DIRECTORY
>> (does not exist yet), GIT_HEAD_FILE (does not exist yet, and I suppose
>> it wouldn't be easy to implement it). By the way, that's why I'm for
>> .gitlink name for the file, not .git -- this way .gitlink can "shadow"
>> what's in .git, for example specifying in a smart way where to search
>> (where to find) object database, but HEAD and index would be stored
>> together with the checked out directory in .git
>
> What about .git/link or something?
> (Obviously without the capability to change GIT_DIR)
Well, the .gitlink proposal at it is now (by Josef) serves both as a way
to implement lightweight checkout (i.e. having additional working dir to
some repository, or having working dir separate from bare repository),
and as a way to have "smart" submodules (which you can move and rename)
in submodules/subproject support.
Besides, I'd rather either use config file for this (core.link or
core.git_dir), or use .git/GIT_DIR.
>> By the way, I'm rather partial to supermodule following HEAD in submodule,
>> not specified branch. First, I think it is easier from implementation
>> point of view: you don't have to remember which branch supermodule should
>> take submodule commits from; and this cannot be fixed branch name like
>> 'master'.
[...]
> In the setup you described a git-checkout in the supermodule would have
> to switch to a different branch in the submodule, depending on the
> branchname which would have to be stored in the supermodule.
> This a lot more complex.
O.K. Now I understand why you prefer specified branch to HEAD.
I have forgot that checkout must update submodule ref, and if we track HEAD
we would have to remember the branch it pointed to.
By the way, should this ref be in submodule, or in supermodule, e.g. in
refs/modules/<name>/HEAD? And there is a problam _what_ branch should
be that.
Both approaches have advantages and disadvantages...
--
Jakub Narebski
^ permalink raw reply
* Re: Can git be tweaked to work cross-platform, on FAT32?
From: Stefano Spinucci @ 2006-12-17 14:33 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Johannes Schindelin, Florian v. Savigny, git
In-Reply-To: <46a038f90612170221u4c3b5c2asef378d3d4e159ba7@mail.gmail.com>
I just tried to use git writing to my FAT32 formatted usb stick.
On windows XP, I compiled git with and without NO_D_TYPE_IN_DIRENT,
but after the
following actions I always got the error "fatal: Unable to write new
index file" or
"fatal: unable to create '.git/index': File exists":
mkdir git-test-repo
cd git-test-repo
git-init-db
echo iii>test
git add test
git commit -m "test msg"
echo ooo>test1
git add test1 ***error***
converting the stick to NTFS I have no problems.
any hint ???
---
^ permalink raw reply
* [PATCH] Adjust t5510 to put remotes in config
From: Johannes Schindelin @ 2006-12-17 14:46 UTC (permalink / raw)
To: git, junkio
Since .git/remotes/ is no longer created by default, t5510 failed.
While at it, convert the tests to use the config way of specifying
remotes instead of creating a file in .git/remotes/.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
t/t5510-fetch.sh | 14 +++++---------
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index a11ab0a..6229433 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -23,20 +23,16 @@ test_expect_success "clone and setup child repos" '
git clone . two &&
cd two &&
git repo-config branch.master.remote one &&
- {
- echo "URL: ../one/.git/"
- echo "Pull: refs/heads/master:refs/heads/one"
- } >.git/remotes/one
+ git repo-config remote.one.url ../one/.git/ &&
+ git repo-config remote.one.fetch refs/heads/master:refs/heads/one &&
cd .. &&
git clone . three &&
cd three &&
git repo-config branch.master.remote two &&
git repo-config branch.master.merge refs/heads/one &&
- {
- echo "URL: ../two/.git/"
- echo "Pull: refs/heads/master:refs/heads/two"
- echo "Pull: refs/heads/one:refs/heads/one"
- } >.git/remotes/two
+ git repo-config remote.two.url ../two/.git/ &&
+ git repo-config remote.two.fetch refs/heads/master:refs/heads/two &&
+ git repo-config --add remote.two.fetch refs/heads/one:refs/heads/one
'
test_expect_success "fetch test" '
--
1.4.4.2.ga4be2-dirty
^ permalink raw reply related
* [PATCH] Documentation/git-merge-file.txt: make asciidoc not complain
From: Johannes Schindelin @ 2006-12-17 14:48 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Randal L. Schwartz, git, junkio
In-Reply-To: <4584857D.703@gmail.com>
Noticed by Randal L. Schwartz, this is a fix proposed by
A Large Angry SCM.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Sat, 16 Dec 2006, A Large Angry SCM wrote:
> Randal L. Schwartz wrote:
> > asciidoc -b xhtml11 -d manpage -f asciidoc.conf git-merge-file.txt
> > ERROR: manpage document title is mandatory
> > ERROR: git-merge-file.txt: line 3: title not permitted in sidebar body
> > [...]
> > make[1]: *** [git-merge-file.html] Error 1
> > make: *** [doc] Error 2
>
> Add 5 "=" to line 2.
... which this patch does. This time, it is asciidoc-tested, too.
Documentation/git-merge-file.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt
index 0b41d66..09fe24f 100644
--- a/Documentation/git-merge-file.txt
+++ b/Documentation/git-merge-file.txt
@@ -1,5 +1,5 @@
git-merge-file(1)
-============
+=================
NAME
----
--
1.4.4.2.ga4be2-dirty
^ permalink raw reply related
* [PATCH] Documentation: new option -P for git-svnimport
From: Quy Tonthat @ 2006-12-17 14:50 UTC (permalink / raw)
To: git
Documentation: new option -P for git-svnimport.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
---
Documentation/git-svnimport.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index b1b87c2..df604e1 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -15,6 +15,7 @@ SYNOPSIS
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
[ -s start_chg ] [ -m ] [ -r ] [ -M regex ]
[ -I <ignorefile_name> ] [ -A <author_file> ]
+ [ -P <path_from_trunk> ]
<SVN_repository_URL> [ <path> ]
@@ -107,6 +108,14 @@ repository without -A.
Formerly, this option controlled how many revisions to pull,
due to SVN memory leaks. (These have been worked around.)
+-P <path_from_trunk>::
+ Partial import of the SVN tree.
+
+ By default, the whole tree on the SVN trunk (/trunk) is imported.
+ '-P my/proj' will import starting only from '/trunk/my/proj'.
+ This option is useful when you want to import one project from a
+ svn repo which hosts multiple projects under the same trunk.
+
-v::
Verbosity: let 'svnimport' report what it is doing.
--
1.4.4.1.GIT
^ permalink raw reply related
* Re: Can git be tweaked to work cross-platform, on FAT32?
From: Johannes Schindelin @ 2006-12-17 14:54 UTC (permalink / raw)
To: Stefano Spinucci; +Cc: Martin Langhoff, Florian v. Savigny, git
In-Reply-To: <906f26060612170633h50e3e974h3b84f1829e546278@mail.gmail.com>
Hi,
On Sun, 17 Dec 2006, Stefano Spinucci wrote:
> I just tried to use git writing to my FAT32 formatted usb stick.
>
> On windows XP, I compiled git with and without NO_D_TYPE_IN_DIRENT, but
> after the following actions I always got the error "fatal: Unable to
> write new index file" or "fatal: unable to create '.git/index': File
> exists":
Come to think of it, I probably never tried to actually _commit_ on
FAT32... Sorry.
I will not be able to test this scenario until Tuesday, though. Sorry
again!
Ciao,
^ permalink raw reply
* git-diff & cg-diff behavior difference
From: Vincent Legoll @ 2006-12-17 17:11 UTC (permalink / raw)
To: git
I did not find something relevant in the docs, so I'll ask here.
git-diff works from everywhere in the tree, whereas cg-diff
does not, is that intentional ?
steps to reproduce:
--------------------
mkdir tmp
cd tmp
touch titi.txt
mkdir tutu
touch tutu/toto.txt
cg-init -I
cg-add -r .
cg-commit -C -m INIT
echo "tata" > titi.txt
git-diff
cg-diff
cd tutu
git-diff
cg-diff
--------------------
The 2 git-diff & 1st cg-diff outputs are the same, whereas the 2nd
cg-diff one is empty...
Quite a minor thing, but this could be added in the cg-diff man-page as a
difference of behavior.
--
^ permalink raw reply
* Re: [PATCH] revision: introduce ref@{N..M} syntax.
From: Linus Torvalds @ 2006-12-17 18:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, git
In-Reply-To: <7vbqm36mv6.fsf_-_@assigned-by-dhcp.cox.net>
On Sat, 16 Dec 2006, Junio C Hamano wrote:
>
> This allows you to add between Nth and Mth (inclusive) reflog entries.
> "git show master@{1} master@{2} master@{3}" is equivalent to
> "git show master@{1..3}".
Well, logically, if you do that, then you should also allow
git log master@{one.week.ago..yesterday}
as a reflog expression.
"Because It Only Makes Sense(tm)".
Linus
PS. Yeah, I'm only half serious. I like our revision parsing, and the
above _would_ actually be consistent with the "master@{1..3}" kind of
specification, but at the same time, it's also obviously more complex, and
maybe it's not THAT usable.
But I think the "master@{date..date}" syntax would actually fall out
automatically if you did the {x..y} parsing at a higher level and didn't
^ permalink raw reply
* Re: [BUG] making docs blows up in b1bfcae438ad:git-merge-file.txt
From: Randal L. Schwartz @ 2006-12-17 18:20 UTC (permalink / raw)
To: git
In-Reply-To: <20061216234717.15ECE8F5A8@blue.stonehenge.com>
>>>>> "The" == The Answering Machine <merlyn.'s-answering.machine@stonehenge.com> writes:
The> I've received your mail.
The> Your message has been queued, and will probably be read within 48 hours.
Naughty SCM sent email addressed to me personally, but added a reply-to
of the list.
My answering machine behaved perfectly in this case, but SCM triggered it
badly. :(
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Yann Dirson @ 2006-12-17 17:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <em1vgj$bc3$1@sea.gmane.org>
On Sun, Dec 17, 2006 at 12:29:25AM +0100, Jakub Narebski wrote:
> > I am thinking about teaching fsck-objects and prune to keep
> > revisions recorded in the reflog; we would need an end-user
> > way to prune older reflog entries and I would appreciate
> > somebody codes it up, but even without it, people can always
> > use "vi" or "ed" on reflog files ;-).
>
> I'd rather not have prune keep revisions recorded in reflog. Reflog
> keeps also amended commits, and blobs from incrementally staged
> commits. Or perhaps make it an configuration option, default to
> true for new users (or have an option to git-prune to ignore reflog).
I think that is quite near to other issues: we already have other pieces
of information that we would like to sometimes have ignored and
sometimes not, when running fsck-objects/prune. Namely, revisions
hidden by grafts, as already discussed on this list.
An idea I had to handle that case, and which could be useful with the
current problem, as well as others, like dealing with stgit's patch
logging, would be to define "reachable commits" using a modular
architecture. That way we would be able to select what we want
fsck-object/prune to consider reachable, in objects reachable from:
- raw "parents" field of commit objects
- the latter as modified by info/grafts
- reflogs
- stgit patchlogs
The set of rules to consider could be declared in repo-config, thus
stgit would be able to declare that its patchlogs should not be ignored,
and people wishing to prune commits hidden by grafts in one repo could
just remove the "raw-parents" rule from their repo's config.
Obviously, mentionning stgit-specific rules here immediately suggests a
plugin-based architecture.
Does that make any sense ?
--
^ 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