* Re: Subprojects tasks
From: Martin Waitz @ 2006-12-18 7:44 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Jakub Narebski, git, Junio C Hamano
In-Reply-To: <200612180023.45815.Josef.Weidendorfer@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]
hoi :)
On Mon, Dec 18, 2006 at 12:23:45AM +0100, Josef Weidendorfer wrote:
> I see that you always use "refs/heads/master" in the submodule.
> What happens if you do development in the submodule, create a new commit
> there, and want to switch supermodule branch afterwards?
> Wouldn't you lose your new work, as "refs/heads/master" has to be reset
> to another commit when you switch the supermodule branch?
It should behave the same as for files:
Refuse to update the working directory if files (or the submodule here)
are dirty. I guess this is not yet handled correctly by my prototype,
but it should not be hard to do.
> IMHO it would be nice to have refs in the submodule matching all the
> branches/tags of the supermodule.
> Meaning: "this is the commit which is used by branch/tag XYZ in the
> supermodule". This can be valuable information, and a "gitk --all" in
> the submodule would show you all the uses of your subproject in the
> scope of the given superproject.
I like the idea. Perhaps make them available similiar to the remotes
information in refs/tracked/{heads,tags} or something.
> When switching branches in the supermodule, it simply would switch
> to the same name in submodules.
Nice idea, but I don't yet know how it really works out.
It may be confusing to the user if he manually switches the branch in
the submodule to another branch of the supermodule. Then he really is
using one tracked branch, but not the currently tracked branch.
> Thus, this would allow to do bug fix commits for a submodule at all
> places where the supermodule has a branch, without the need to switch
> supermodule branches.
Hmm, but when switching to another supermodule branch it would try to
update the submodule branch.
And simply allow the current submodule branch to be a fast forward of
the submodule version that the parent wants to set is a bad, as you
would not be able to go back to an old supermodule version then.
> > > 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.
>
> In general, I agree with not following submodule's HEAD for supermodule
> commits. As you cannot store any submodule branch names, this really
> would be confusing, as after switching to another supermodule branch
> and back again, the submodule branch name would reset to a given name
> ("master" in your current implementation).
>
> But why wouldn't you create a temporary branch "debug_submodule1" in the
> supermodule for your use case? Branches are cheap with git, even in supermodules.
> Supermodule branches also are pure local, you never have to publish
> it somewhere, and can delete it afterwards.
Sure, you can of course always use supermodule branches.
I just wanted to point out that it still is useful to have submodule
branches which are independent from supermodule branches.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] vim syntax: follow recent changes to commit template
From: Jeff King @ 2006-12-18 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch changes the syntax highlighting to correctly match the new
text of the commit message introduced by
82dca84871637ac9812c0dec27f56d07cfba524c
Signed-off-by: Jeff King <peff@peff.net>
---
contrib/vim/syntax/gitcommit.vim | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/vim/syntax/gitcommit.vim b/contrib/vim/syntax/gitcommit.vim
index a9de09f..d911efb 100644
--- a/contrib/vim/syntax/gitcommit.vim
+++ b/contrib/vim/syntax/gitcommit.vim
@@ -1,7 +1,7 @@
syn region gitLine start=/^#/ end=/$/
-syn region gitCommit start=/^# Updated but not checked in:$/ end=/^#$/ contains=gitHead,gitCommitFile
+syn region gitCommit start=/^# Added but not yet committed:$/ end=/^#$/ contains=gitHead,gitCommitFile
syn region gitHead contained start=/^# (.*)/ end=/^#$/
-syn region gitChanged start=/^# Changed but not updated:/ end=/^#$/ contains=gitHead,gitChangedFile
+syn region gitChanged start=/^# Changed but not added:/ end=/^#$/ contains=gitHead,gitChangedFile
syn region gitUntracked start=/^# Untracked files:/ end=/^#$/ contains=gitHead,gitUntrackedFile
syn match gitCommitFile contained /^#\t.*/hs=s+2
--
^ permalink raw reply related
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2006-12-18 7:28 UTC (permalink / raw)
To: git
Here are the topics cooking in git.git and their status.
* jc/leftright (Sat Dec 16 16:07:20 2006 -0800) 3 commits
+ Make left-right automatic.
+ Teach all of log family --left-right output.
+ rev-list --left-right
* jc/clone (Sat Dec 16 01:53:10 2006 -0800) 4 commits
+ git-clone: lose the traditional 'no-separate-remote' layout
+ git-clone: lose the artificial "first" fetch refspec
+ git-pull: refuse default merge without branch.*.merge
+ git-clone: use wildcard specification for tracking branches
Will likely to be in 'master' soonish.
* ew/svn-pm (Fri Dec 15 23:58:08 2006 -0800) 3 commits
+ git-svn: rename 'commit' command to 'set-tree'
+ git-svn: remove support for the svn command-line client
+ git-svn: convert to using Git.pm
On hold -- the users will decide.
*^ jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
- git-add --interactive: hunk splitting
- git-add --interactive
*^ jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
- git-explain
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
+ git-merge: preserve and merge local changes when doing fast
forward
*^ jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
- gitweb: steal loadavg throttle from kernel.org
Undecided.
*^ jc/reflog (Sat Dec 16 18:35:00 2006 -0800) 1 commit
- revision: introduce ref@{N..M} syntax.
I do not think this is of general use enough, so I'd shelve this
for now.
*^ jn/web (Sat Dec 16 17:12:55 2006 +0100) 1 commit
- gitweb: Add some mod_perl specific support
Jakub says this needs review, so it is on hold for now.
* js/shallow (Fri Nov 24 16:00:13 2006 +0100) 15 commits
+ fetch-pack: Do not fetch tags for shallow clones.
+ get_shallow_commits: Avoid memory leak if a commit has been
reached already.
+ git-fetch: Reset shallow_depth before auto-following tags.
+ upload-pack: Check for NOT_SHALLOW flag before sending a shallow
to the client.
+ fetch-pack: Properly remove the shallow file when it becomes
empty.
+ shallow clone: unparse and reparse an unshallowed commit
+ Why didn't we mark want_obj as ~UNINTERESTING in the old code?
+ Why does it mean we do not have to register shallow if we have
one?
+ We should make sure that the protocol is still extensible.
+ add tests for shallow stuff
+ Shallow clone: do not ignore shallowness when following tags
+ allow deepening of a shallow repository
+ allow cloning a repository "shallowly"
+ support fetching into a shallow repository
+ upload-pack: no longer call rev-list
Post v1.5.0
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
+ git-diff/git-apply: make diff output a bit friendlier to GNU patch
(part 2)
*^ jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
- blame: --show-stats for easier optimization work.
*^ jc/diff (Mon Sep 25 23:03:34 2006 -0700) 1 commit
- para-walk: walk n trees, index and working tree in parallel
On hold.
*^ sv/git-svn (Tue Dec 5 16:17:38 2006 +1100) 5 commits
. git-svn: re-map repository URLs and UUIDs on SVK mirror paths
. git-svn: collect revision properties when fetching
. git-svn: collect SVK source URL on mirror paths
. git-svn: let libsvn_ls_fullurl return properties too
. git-svn: make test for SVK mirror path import
On hold -- waiting for updates or responses to Eric's comment; I
am holding onto this series but it is temporarily dropped from
'pu'.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2006-12-18 7:26 UTC (permalink / raw)
To: git
I've updated 'master' with a handful topics along with a few
fixes:
- Jakub's gitweb updates;
- blame A..B's output shows lines attributed to the boundary
commit with commit SHA-1 prefixed with '^';
- "branch -m $old $new" renames branch.$old.* configuration
variables to branch.$new.*;
- "git add A/B C", when A and C/D used to be tracked files, now
properly works, it used to result in a bogus index you cannot
write-tree out;
- "git show-branch --reflog=<n> <branch>" shows latest n entries
of the reflog of the branch.
- "git fetch" between repositories with tons of refs had huge
performance problem; hopefully fixed.
* The 'master' branch has these since the last announcement.
Jakub Narebski (8):
gitweb: Don't use Content-Encoding: header in git_snapshot
gitweb: Show target of symbolic link in "tree" view
gitweb: Add generic git_object subroutine to display object of any type
gitweb: Hyperlink target of symbolic link in "tree" view (if possible)
gitweb: SHA-1 in commit log message links to "object" view
gitweb: Do not show difftree for merges in "commit" view
gitweb: Add title attribute to ref marker with full ref name
gitweb: Add "next" link to commit view
Johannes Schindelin (2):
add a function to rename sections in the config
git-branch: rename config vars branch.<branch>.*, too
Junio C Hamano (11):
git-blame: show lines attributed to boundary commits differently.
update-index: make D/F conflict error a bit more verbose.
git-add: remove conflicting entry when adding.
Fix check_file_directory_conflict().
Fix mis-mark-up in git-merge-file.txt documentation
markup fix in svnimport documentation.
Teach show-branch how to show ref-log data.
git-fetch: Avoid reading packed refs over and over again
avoid accessing _all_ loose refs in git-show-ref --verify
show-ref: fix --quiet --verify
show-ref: fix --verify --hash=length
Quy Tonthat (1):
Documentation: new option -P for git-svnimport
Shawn Pearce (1):
Default GIT_COMMITTER_NAME to login name in recieve-pack.
^ permalink raw reply
* Re: [PATCH] git-branch: deleting remote branches in new layout
From: Junio C Hamano @ 2006-12-18 7:08 UTC (permalink / raw)
To: Quy Tonthat; +Cc: git
In-Reply-To: <45863044.4040406@gmail.com>
Quy Tonthat <qtonthat@gmail.com> writes:
> Now that remote branches are in refs/remotes/, branch -D needs to know
> where to find them.
>
> Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
I recognize that giving end users a way to remove a "remote
tracking branch" might be a worthy goal ("update-ref -d" _could_
be used, but "branch -D" feels more natural).
> + char ** s;
> + static char * branches_dir[] = {"refs/heads", "refs/remotes", NULL};
But I do not like these two entries in branches_dir[].
(style: lose SP after '*' in these two lines, by the way).
If you had refs/heads/$X and refs/remotes/$X, I do not think
this code allows you to disambiguate. You cannot remove
"remote" one without first removing the local one, can you?
> + for (s = branches_dir; *s != NULL; s++) {
> + name = xstrdup(mkpath("%s/%s", *s, argv[i]));
> + if (resolve_ref(name, sha1, 1, NULL))
> + break;
> + }
> + if (*s == NULL)
> die("Branch '%s' not found.", argv[i]);
(style: we seem to prefer "if (!*s)").
^ permalink raw reply
* [PATCH] git-branch: deleting remote branches in new layout
From: Quy Tonthat @ 2006-12-18 6:08 UTC (permalink / raw)
To: git
Now that remote branches are in refs/remotes/, branch -D needs to know
where to find them.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
---
builtin-branch.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 560309c..b2f0aae 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -95,6 +95,8 @@ static void delete_branches(int argc, const char **argv, int force)
unsigned char sha1[20];
char *name;
int i;
+ char ** s;
+ static char * branches_dir[] = {"refs/heads", "refs/remotes", NULL};
if (!force) {
head_rev = lookup_commit_reference(head_sha1);
@@ -105,8 +107,12 @@ static void delete_branches(int argc, const char **argv, int force)
if (!strcmp(head, argv[i]))
die("Cannot delete the branch you are currently on.");
- name = xstrdup(mkpath("refs/heads/%s", argv[i]));
- if (!resolve_ref(name, sha1, 1, NULL))
+ for (s = branches_dir; *s != NULL; s++) {
+ name = xstrdup(mkpath("%s/%s", *s, argv[i]));
+ if (resolve_ref(name, sha1, 1, NULL))
+ break;
+ }
+ if (*s == NULL)
die("Branch '%s' not found.", argv[i]);
rev = lookup_commit_reference(sha1);
--
1.4.4.1.GIT
^ permalink raw reply related
* Re: [PATCH] git-fetch: Avoid reading packed refs over and over again
From: Junio C Hamano @ 2006-12-18 1:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612172048331.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Since this option is purely for use in git-fetch, I did not even
> bother documenting it.
I think the name --filter-blah makes it unclear if it is a
filter that picks up items that match the criteria "blah" out of
its input, or if it filters out the ones that do not match the
criteria.
In either case, you are not filtering "invalid vs valid" but
"existing vs missing".
If you are making a git-fetch specific extension, it would make
sense to include what the upstream sed does as well. That is,
the user would become:
echo "$ls_remote_result" |
- sed -n -e 's|^\('"$_x40"'\) \(refs/tags/.*\)^{}$|\1 \2|p' \
- -e 's|^\('"$_x40"'\) \(refs/tags/.*\)$|\1 \2|p' |
+ git show-ref --exclude-existing=refs/tags/ |
while read sha1 name
do
- git-show-ref --verify --quiet -- "$name" && continue
- git-check-ref-format "$name" || {
- echo >&2 "warning: tag ${name} ignored"
- continue
The 'exclude-existing' flag would filter out the ones that do not
head-match the specified hierarchy, the ones that we have, and
the ones that do not conform to a valid refname pattern (which
would filter out ^{} entries).
How about this as a replacement?
---
builtin-show-ref.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++-
git-fetch.sh | 12 ++-------
2 files changed, 62 insertions(+), 10 deletions(-)
diff --git a/builtin-show-ref.c b/builtin-show-ref.c
index 0739798..b36f15e 100644
--- a/builtin-show-ref.c
+++ b/builtin-show-ref.c
@@ -2,8 +2,9 @@
#include "refs.h"
#include "object.h"
#include "tag.h"
+#include "path-list.h"
-static const char show_ref_usage[] = "git show-ref [-q|--quiet] [--verify] [-h|--head] [-d|--dereference] [-s|--hash[=<length>]] [--abbrev[=<length>]] [--tags] [--heads] [--] [pattern*]";
+static const char show_ref_usage[] = "git show-ref [-q|--quiet] [--verify] [-h|--head] [-d|--dereference] [-s|--hash[=<length>]] [--abbrev[=<length>]] [--tags] [--heads] [--] [pattern*] | --filter-invalid < ref-list";
static int deref_tags = 0, show_head = 0, tags_only = 0, heads_only = 0,
found_match = 0, verify = 0, quiet = 0, hash_only = 0, abbrev = 0;
@@ -86,6 +87,59 @@ match:
return 0;
}
+static int add_existing(const char *refname, const unsigned char *sha1, int flag, void *cbdata)
+{
+ struct path_list *list = (struct path_list *)cbdata;
+ path_list_insert(refname, list);
+ return 0;
+}
+
+/*
+ * read "^(?:<anything>\s)?<refname>(?:\^\{\})?$" from the standard input,
+ * and
+ * (1) strip "^{}" at the end of line if any;
+ * (2) ignore if match is provided and does not head-match refname;
+ * (3) warn if refname is not a well-formed refname and skip;
+ * (4) ignore if refname is a ref that exists in the local repository;
+ * (5) otherwise output the line.
+ */
+static int exclude_existing(const char *match)
+{
+ static struct path_list existing_refs = { NULL, 0, 0, 0 };
+ char buf[1024];
+ int matchlen = match ? strlen(match) : 0;
+
+ for_each_ref(add_existing, &existing_refs);
+ while (fgets(buf, sizeof(buf), stdin)) {
+ int len = strlen(buf);
+ char *ref;
+ if (len > 0 && buf[len - 1] == '\n')
+ buf[--len] = '\0';
+ if (!strcmp(buf + len - 3, "^{}")) {
+ len -= 3;
+ buf[len] = '\0';
+ }
+ for (ref = buf + len; buf < ref; ref--)
+ if (isspace(ref[-1]))
+ break;
+ if (match) {
+ int reflen = buf + len - ref;
+ if (reflen < matchlen)
+ continue;
+ if (strncmp(ref, match, matchlen))
+ continue;
+ }
+ if (check_ref_format(ref)) {
+ fprintf(stderr, "warning: ref '%s' ignored\n", ref);
+ continue;
+ }
+ if (!path_list_has_path(&existing_refs, ref)) {
+ printf("%s\n", buf);
+ }
+ }
+ return 0;
+}
+
int cmd_show_ref(int argc, const char **argv, const char *prefix)
{
int i;
@@ -153,6 +207,10 @@ int cmd_show_ref(int argc, const char **argv, const char *prefix)
heads_only = 1;
continue;
}
+ if (!strcmp(arg, "--exclude-existing"))
+ return exclude_existing(NULL);
+ if (!strncmp(arg, "--exclude-existing=", 19))
+ return exclude_existing(arg + 19);
usage(show_ref_usage);
}
if (show_head)
diff --git a/git-fetch.sh b/git-fetch.sh
index fb35815..38101a6 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -242,7 +242,7 @@ esac
reflist=$(get_remote_refs_for_fetch "$@")
if test "$tags"
then
- taglist=`IFS=" " &&
+ taglist=`IFS=' ' &&
echo "$ls_remote_result" |
while read sha1 name
do
@@ -438,17 +438,11 @@ case "$no_tags$tags" in
*:refs/*)
# effective only when we are following remote branch
# using local tracking branch.
- taglist=$(IFS=" " &&
+ taglist=$(IFS=' ' &&
echo "$ls_remote_result" |
- sed -n -e 's|^\('"$_x40"'\) \(refs/tags/.*\)^{}$|\1 \2|p' \
- -e 's|^\('"$_x40"'\) \(refs/tags/.*\)$|\1 \2|p' |
+ git-show-ref --exclude-existing=refs/tags/ |
while read sha1 name
do
- git-show-ref --verify --quiet -- "$name" && continue
- git-check-ref-format "$name" || {
- echo >&2 "warning: tag ${name} ignored"
- continue
- }
git-cat-file -t "$sha1" >/dev/null 2>&1 || continue
echo >&2 "Auto-following $name"
echo ".${name}:${name}"
^ permalink raw reply related
* Re: Can git be tweaked to work cross-platform, on FAT32?
From: Stefano Spinucci @ 2006-12-18 1:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Juergen Ruehle, Martin Langhoff, Florian v. Savigny, git
In-Reply-To: <Pine.LNX.4.63.0612172027400.3635@wbgn013.biozentrum.uni-wuerzburg.de>
On 12/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> ...
> I am sure that there are more problems with it. BTW the problem stems from
> Windows having _no_ equivalent to fork().
> ...
I recompiled git with NO_MMAP and used it successfully, then I added a
note in the wiki
page http://git.or.cz/gitwiki/WindowsInstall on how to compile git to
work on a FAT32
filesystem.
Now, two questions...
if you are sure that there are more problems with using MMAP, shouldn't NO_MMAP
be commented better in the Makefile and in INSTALL, pointing out to
use it always on
cygwin ???
finally on cygwin there is a precompiled git package (v 1.4.4.1);
however, I found if it was
compiled *with* MMAP support... should I write to the cygwin-apps list
asking for a
different compilation (with NO_MMAP), or for the majority of the users
the standard
compilation is a better choice ???
bye
---
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Andy Parkins @ 2006-12-17 23:41 UTC (permalink / raw)
To: git
In-Reply-To: <7vodq3a136.fsf@assigned-by-dhcp.cox.net>
On Saturday 2006, December 16 23:10, Junio C Hamano wrote:
> * revisions recorded in the reflog can be pruned out,
> rendering some entries in reflog useless.
Can I suggest that it should be fine to prune reflog entries but that the act
of pruning be a log entry itself?
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Josef Weidendorfer @ 2006-12-17 23:38 UTC (permalink / raw)
To: Yann Dirson; +Cc: Jakub Narebski, git
In-Reply-To: <20061217173534.GA16838@nan92-1-81-57-214-146.fbx.proxad.net>
On Sunday 17 December 2006 18:35, Yann Dirson wrote:
> 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
Could be interesting for pruning support in submodules, too.
> 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.
Isn't it enough to specify further subdirectories of .git/, holding
references which should be taken into account while pruning?
Hmm.. Grafting would be a special case.
^ permalink raw reply
* Re: Subprojects tasks
From: Josef Weidendorfer @ 2006-12-17 23:27 UTC (permalink / raw)
To: Martin Waitz; +Cc: Jakub Narebski, git, Junio C Hamano
In-Reply-To: <20061217195417.GI12411@admingilde.org>
On Sunday 17 December 2006 20:54, Martin Waitz wrote:
> I added a symlink .git/refs/module/<submodule> -> <submodule>/.git/refs,
> so that the submodule branch is also available as
> refs/module/<submodule>/heads/master in the supermodule.
Ah.
What is "<submodule>" in your implementation?
Is this some encoding of the path where the submodule currently lives
in the supermodule, or are you giving the submodules unique names
in the context of the supermodule?
^ permalink raw reply
* Re: Subprojects tasks
From: Josef Weidendorfer @ 2006-12-17 23:23 UTC (permalink / raw)
To: Martin Waitz; +Cc: Jakub Narebski, git, Junio C Hamano
In-Reply-To: <20061217134848.GH12411@admingilde.org>
On Sunday 17 December 2006 14:48, Martin Waitz wrote:
> 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.
I see that you always use "refs/heads/master" in the submodule.
What happens if you do development in the submodule, create a new commit
there, and want to switch supermodule branch afterwards?
Wouldn't you lose your new work, as "refs/heads/master" has to be reset
to another commit when you switch the supermodule branch?
IMHO it would be nice to have refs in the submodule matching all the
branches/tags of the supermodule.
Meaning: "this is the commit which is used by branch/tag XYZ in the
supermodule". This can be valuable information, and a "gitk --all" in
the submodule would show you all the uses of your subproject in the
scope of the given superproject.
We could occupy the local refs namespace of the
submodule with the same refs as there are in the supermodule. But that
is no problem as the original branches of the subproject would be
in "refs/remotes/".
When switching branches in the supermodule, it simply would switch
to the same name in submodules. The submodule refs would not need
to match the submodule object in the tree of the supermodule; instead,
it would represent the development done in the submodule while on a
given branch in the supermodule. Thus, this would allow to do bug fix commits
for a submodule at all places where the supermodule has a branch, without
the need to switch supermodule branches.
However, "git commit" in branch X in the supermodule should give a warning
when submodules are not all at the same branch X, as the commit would use
branch X for committing.
> > 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.
In general, I agree with not following submodule's HEAD for supermodule
commits. As you cannot store any submodule branch names, this really
would be confusing, as after switching to another supermodule branch
and back again, the submodule branch name would reset to a given name
("master" in your current implementation).
But why wouldn't you create a temporary branch "debug_submodule1" in the
supermodule for your use case? Branches are cheap with git, even in supermodules.
Supermodule branches also are pure local, you never have to publish
it somewhere, and can delete it afterwards.
^ permalink raw reply
* Re: Collection of stgit issues and wishes
From: Yann Dirson @ 2006-12-17 23:21 UTC (permalink / raw)
To: Karl Hasselstr?m; +Cc: Andreas Ericsson, David K?gedal, git
In-Reply-To: <20061213110314.GA22670@diana.vm.bytemark.co.uk>
On Wed, Dec 13, 2006 at 12:03:14PM +0100, Karl Hasselstr?m wrote:
> > > That approach can cause problems later on. If "stgit st" is
> > > currently a unique prefix of "stgit status", people might use it
> > > in scripts. Then, one day, you add the "stgit store" command, or
> > > whatever, and their scripts start breaking for no good reason.
Such shortcuts are *definitely* not for script writers.
> > People who use abbreviations of commands in scripts ought to be
> > shot, not catered to, especially if they know this abbreviation is
> > automagically calculated.
>
> Well, yes, but there's no reason to not shoot them _politely_ ...
At least we could shoot them when stdout is not a tty ?
Not sure there is a good way of detecting if we're being run directly
from an interactive shell.
> I'd prefer hand-picked command abbreviations to reduce namespace
> clutter. That way, it's even possible to have "ambiguous" shortcuts --
> for example, "stg st" -> "stg status" even if "stg store" exists. And
> shortcuts that aren't prefixes, like "stg ua" -> "stg unapplied". And
> the user doesn't need to retrain her fingers just because a prefix
> gets ambiguous.
Sure, I'd hate having to type "stg sta" :)
Best regards,
--
^ permalink raw reply
* Re: Collection of stgit issues and wishes
From: Yann Dirson @ 2006-12-17 23:15 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <b0943d9e0612100825h3ef2fa77kd5d9fd5022cbb3f9@mail.gmail.com>
On Sun, Dec 10, 2006 at 04:25:52PM +0000, Catalin Marinas wrote:
> Since this list gets changed pretty often, I would rather add TODO
> Bugs wiki pages on http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT
Great idea.
> (maybe I should create a page on one of the open-source hosting sites
> and get some bug-tracking support).
If you're only looking for bugtracking, I wonder whether
bugzilla.kernel.org could be used (as well as for core git and other
git-related tools). Or maybe a new git-specialized bugzilla could be
setup somewhere ?
BTW, and a bit off-topic, one thing that would be great to have would be
git-bugzilla coupling (mainly, recording into bugzilla when a commit
addressing an issue gets pushed to an official tree).
Scmbug already provides a framework for such couplings, and already has
bugilla/mantis/RT support on the BTS side.
> I keep the TODO file mainly for
> what I plan to implement and, while I agree with many of the issues
> you point below, I don't guarantee I have time to fix/implement.
I tend do that myself too - in fact, a number of the issues I reported
are candidates for future patches from me :)
> >- "stg import" leaves empty patch on the stack after failed patch
> >application
>
> That's a feature in the sense that it creates the empty patch with the
> description and author information. It also leaves a
> .stgit-failed.patch which you can manually apply.
I was not aware of this. It would be useful to tell the user when such
a failed patch is left behind (that would have saved me some timing
already ;).
> >- "patches -d" may be confused by files added then removed (below,
> >file added to platform-v0, removed in rm-junk, problem encountered on
> >2006-08-14, probably on 0.10):
>
> Is this still the case now? I fixed a similar issue a few months ago
> (commit a57bd72016d3cf3ee8e8fd7ae2c12e047999b602; GIT considers a file
> name to be revision name if the file isn't found on disk; easily
> fixable by adding the "--" separator).
I should check.
> >- "stg show" should catch inexistant patch instead of saying "Unknown
> >revision: that-patch^{commit}"
>
> This command works for commit ids as well as patches. If the patch
> isn't found, it considers the name to be a commit id.
OK. Then some message like "No patch or commit id found matching
$commit" could be more informative.
> >- "clean" should give enough info for the user to locate any problem
> >(eg. conflict with files removed from revision control), eg. with a
> >"popping to ..." message
>
> Clean only removes empty patches and there shouldn't be any conflicts
> caused by this operation (unless there is a bug).
I have already described the problem in a previous thread. There is a
conflict when a generated file gets committed by error, and then a stgit
patch removes it. If one tries to pop that patch when the generated
file exists, there is a conflict.
> >- "sink" or "burry" as opposite to "float" (possibly with a target
> >patch)
>
> But how deep to burry it?
I'd think to bottom of stack by default (mostly to get a sane default),
but with an option to specify the position.
Or maybe as "stg bury-below <target> <patches-to-bury>".
> >- lacks "pick --patch=XXX" to pick by name
>
> I don't understand this.
Hm, I must have been confused, just ignore.
> >- interactive merge tools could only be called automatically after
> >failed merge, instead of requiring not-so-intuitive "resolved -i"
>
> You can set the stgit.merger config option for this (diff3 followed by
> xxdiff or emacs). I even have a .py file for doing this, I can add it
> to the contrib dir.
What about automatically triggering stgit.imerger when stgit.merger
failed ?
> >- needs a config example to call ediff via gnuserv (possibly sending
> >several merges at a time, making use of the session registry)
>
> Don't know how to do it.
That's one of the TODO items directed at myself (unless some good soul
takes care of that first ;)
> >- "stg fold" should allow to run a merge (insert conflict markers, or
> >even just output a .rej patch somewhere)
>
> It just calls git-apply. If this can do it, StGIT would use it.
I still have to invest some time into the available merge algorithms.
If nothing is available yet for this, we shall find out how to do it :)
> >- support for atomicity of complex transactions (stg begin/snapshot,
> >rollback, commit/finish - possibly with a transaction name so nesting would
> >just work)
>
> Would be nice but probably not that easy.
Full logging of series file would help, I think. Once we have full
logging of the stack, we get cheap transactions as well as arbitrary
undo depth, and the "stg undo" command to replace all those --undo
flags. But right, it still requires some work :)
> >- "stg patches" should be able to report on unapplied patches
>
> It invokes GIT to find out the commits modifying the give file. An
> unapplied patch doesn't modify any local file.
Right, but I think we could invoke GIT to report on each of the unapplied
patches that form a head, and restrict the output to those commits that
are stgit patches.
Best regards,
--
^ permalink raw reply
* Re: [PATCH] git-diff: don't add trailing blanks (i.e., do what GNU diff -u now does)
From: Jakub Narebski @ 2006-12-17 20:54 UTC (permalink / raw)
To: git
In-Reply-To: <7vtzzu5lp1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> On Sun, 17 Dec 2006, Jim Meyering wrote:
>>>
>>> You may recall that GNU diff -u changed recently so that it no
>>> longer outputs any trailing space unless the input data has it.
>>
>> I still consider that to be a bug in GNU "diff -u".
>>
>> We work around that bug when applying patches, but I don't think we should
>> replicate it.
>
> Me neither.
Perhaps with --gnu-diff-compatibility then?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-diff: don't add trailing blanks (i.e., do what GNU diff -u now does)
From: Jim Meyering @ 2006-12-17 20:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vtzzu5lp1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>> On Sun, 17 Dec 2006, Jim Meyering wrote:
>>> You may recall that GNU diff -u changed recently so that it no
>>> longer outputs any trailing space unless the input data has it.
>>
>> I still consider that to be a bug in GNU "diff -u".
>>
>> We work around that bug when applying patches, but I don't think we should
>> replicate it.
>
> Me neither.
I can't say I didn't expect this.
^ permalink raw reply
* Re: [PATCH] git-diff: don't add trailing blanks (i.e., do what GNU diff -u now does)
From: Junio C Hamano @ 2006-12-17 20:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Jim Meyering
In-Reply-To: <Pine.LNX.4.64.0612171200290.3479@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 17 Dec 2006, Jim Meyering wrote:
>>
>> You may recall that GNU diff -u changed recently so that it no
>> longer outputs any trailing space unless the input data has it.
>
> I still consider that to be a bug in GNU "diff -u".
>
> We work around that bug when applying patches, but I don't think we should
> replicate it.
Me neither.
^ permalink raw reply
* Re: [PATCH] git-diff: don't add trailing blanks (i.e., do what GNU diff -u now does)
From: Linus Torvalds @ 2006-12-17 20:00 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87y7p6nwsh.fsf@rho.meyering.net>
On Sun, 17 Dec 2006, Jim Meyering wrote:
>
> You may recall that GNU diff -u changed recently so that it no
> longer outputs any trailing space unless the input data has it.
I still consider that to be a bug in GNU "diff -u".
We work around that bug when applying patches, but I don't think we should
replicate it.
^ permalink raw reply
* Re: Subprojects tasks
From: Martin Waitz @ 2006-12-17 19:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Josef Weidendorfer, git, Junio C Hamano
In-Reply-To: <200612171529.03165.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]
hoi :)
On Sun, Dec 17, 2006 at 03:29:02PM +0100, Jakub Narebski wrote:
> 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.
At the moment I simply use refs/heads/master of the submodule
repository, just because it is the default branch anyway.
In order to make the submodule refs which are not added to the
supermodule available to the supermodule anyway (for fsck and prune),
I added a symlink .git/refs/module/<submodule> -> <submodule>/.git/refs,
so that the submodule branch is also available as
refs/module/<submodule>/heads/master in the supermodule.
But I expect that all this setup stuff can be greatly simplified with a
little bit more knowledge of submodules in the core. But this cleanup
is for later, when the basis is settled.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git-fetch: Avoid reading packed refs over and over again
From: Johannes Schindelin @ 2006-12-17 19:52 UTC (permalink / raw)
To: git, junkio
When checking which tags to fetch, the old code used to call
git-show-ref --verify for _each_ remote tag. Since reading even
packed refs is not a cheap operation when there are a lot of
local refs, the code became quite slow.
This fixes it by teaching git-show-ref to filter out valid
(i.e. locally stored) refs from stdin, when passing the parameter
--filter-invalid to git-show-ref, and feeding it lines in the
form 'sha1 refname'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Since this option is purely for use in git-fetch, I did not even
bother documenting it.
This patch would have been so much cleaner if git-fetch was written
in C... But since it accumulated so many functions by now, I see
not much chance for that (at least in the near future).
In very unscientific tests, a single read_packed_refs() in the
lilypond repo took 0.1 seconds. Yep, that's 1/10th second. So, the
while loop in git-fetch took more than 10 seconds for 107 tags.
builtin-show-ref.c | 28 +++++++++++++++++++++++++++-
git-fetch.sh | 2 +-
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/builtin-show-ref.c b/builtin-show-ref.c
index f6929d9..c0b55c1 100644
--- a/builtin-show-ref.c
+++ b/builtin-show-ref.c
@@ -2,8 +2,9 @@
#include "refs.h"
#include "object.h"
#include "tag.h"
+#include "path-list.h"
-static const char show_ref_usage[] = "git show-ref [-q|--quiet] [--verify] [-h|--head] [-d|--dereference] [-s|--hash[=<length>]] [--abbrev[=<length>]] [--tags] [--heads] [--] [pattern*]";
+static const char show_ref_usage[] = "git show-ref [-q|--quiet] [--verify] [-h|--head] [-d|--dereference] [-s|--hash[=<length>]] [--abbrev[=<length>]] [--tags] [--heads] [--] [pattern*] | --filter-invalid < ref-list";
static int deref_tags = 0, show_head = 0, tags_only = 0, heads_only = 0,
found_match = 0, verify = 0, quiet = 0, hash_only = 0, abbrev = 0;
@@ -86,6 +87,29 @@ match:
return 0;
}
+static int add_valid(const char *refname, const unsigned char *sha1, int flag, void *cbdata)
+{
+ struct path_list *list = (struct path_list *)cbdata;
+ path_list_insert(refname, list);
+ return 0;
+}
+
+static int filter_invalid()
+{
+ static struct path_list valid_refs = { NULL, 0, 0, 0 };
+ char buf[1024];
+
+ for_each_ref(add_valid, &valid_refs);
+ while (fgets(buf, sizeof(buf), stdin)) {
+ int len = strlen(buf);
+ if (len > 0 && buf[len - 1] == '\n')
+ buf[--len] = '\0';
+ if (len < 41 || !path_list_has_path(&valid_refs, buf + 41))
+ printf("%s\n", buf);
+ }
+ return 0;
+}
+
int cmd_show_ref(int argc, const char **argv, const char *prefix)
{
int i;
@@ -153,6 +177,8 @@ int cmd_show_ref(int argc, const char **argv, const char *prefix)
heads_only = 1;
continue;
}
+ if (!strcmp(arg, "--filter-invalid"))
+ return filter_invalid();
usage(show_ref_usage);
}
if (verify) {
diff --git a/git-fetch.sh b/git-fetch.sh
index 3feba32..d1c00db 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -474,9 +474,9 @@ case "$no_tags$tags" in
echo "$ls_remote_result" |
sed -n -e 's|^\('"$_x40"'\) \(refs/tags/.*\)^{}$|\1 \2|p' \
-e 's|^\('"$_x40"'\) \(refs/tags/.*\)$|\1 \2|p' |
+ git-show-ref --filter-invalid |
while read sha1 name
do
- git-show-ref --verify --quiet -- "$name" && continue
git-check-ref-format "$name" || {
echo >&2 "warning: tag ${name} ignored"
continue
--
1.4.4.1.g3c2a-dirty
^ permalink raw reply related
* [PATCH] git-diff: don't add trailing blanks (i.e., do what GNU diff -u now does)
From: Jim Meyering @ 2006-12-17 19:32 UTC (permalink / raw)
To: git
You may recall that GNU diff -u changed recently so that it no
longer outputs any trailing space unless the input data has it.
This means that blank context lines are now blank also in diff -u output.
Before, they would have a single trailing space.
Then, git was changed to allow that new diff output format.
Now that git-diff generates output using its internal diff, its
output is no longer identical to what you get when using GNU diff.
This patch makes the output of git-diff the same as GNU diff's.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
t/t4016-diff-trailing-space.sh | 31 +++++++++++++++++++++++++++++++
xdiff/xutils.c | 3 +++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/t/t4016-diff-trailing-space.sh b/t/t4016-diff-trailing-space.sh
new file mode 100755
index 0000000..95c4674
--- /dev/null
+++ b/t/t4016-diff-trailing-space.sh
@@ -0,0 +1,31 @@
+#!/bin/bash
+#
+# Copyright (c) Jim Meyering
+#
+test_description='diff does not add trailing spaces'
+
+. ./test-lib.sh
+
+cat <<\EOF > exp ||
+diff --git a/f b/f
+index 5f6a263..8cb8bae 100644
+--- a/f
++++ b/f
+@@ -1,2 +1,2 @@
+
+-x
++y
+EOF
+exit 1
+
+test_expect_success \
+ "$test_description" \
+ '(echo; echo x) > f &&
+ git-add f &&
+ git-commit -q -m. f &&
+ (echo; echo y) > f &&
+ git-diff f > actual &&
+ cmp exp actual
+ '
+
+test_done
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 1b899f3..8b7380a 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -51,6 +51,9 @@ int xdl_emit_diffrec(char const *rec, long size, char const *pre, long psize,
mb[0].size = psize;
mb[1].ptr = (char *) rec;
mb[1].size = size;
+ /* Don't emit a trailing space for an empty context line. */
+ if (size == 1 && rec[0] == '\n' && psize == 1 && *pre == ' ')
+ mb[0].size = 0;
if (size > 0 && rec[size - 1] != '\n') {
mb[2].ptr = (char *) "\n\\ No newline at end of file\n";
mb[2].size = strlen(mb[2].ptr);
--
^ permalink raw reply related
* Re: [PATCH] revision: introduce ref@{N..M} syntax.
From: Junio C Hamano @ 2006-12-17 19:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brian Gernhardt, git
In-Reply-To: <Pine.LNX.4.64.0612171009550.3479@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Well, logically, if you do that, then you should also allow
>
> git log master@{one.week.ago..yesterday}
>
> as a reflog expression.
> ...
> 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
> force "x" and "y" to be digits only.
Syntax, yes, usage of it in "git show" yes,
But giving it to "git log" would not work as a naive user would
expect, which your example suggested ;-).
^ permalink raw reply
* Re: Can git be tweaked to work cross-platform, on FAT32?
From: Johannes Schindelin @ 2006-12-17 19:33 UTC (permalink / raw)
To: Juergen Ruehle; +Cc: Stefano Spinucci, Martin Langhoff, Florian v. Savigny, git
In-Reply-To: <17797.35177.550000.996862@lapjr.intranet.kiel.bmiag.de>
Hi,
On Sun, 17 Dec 2006, Juergen Ruehle wrote:
> Johannes claims that there are additional problems with mmap on cygwin,
> but it passes the complete test suite on NTFS, so it should be ok for
> most operations
I encountered a problem with git-log, where the fork() tried to
reestablish a mmap()ed file, which unfortunately was renamed (since it was
a .lock file[*1*]). This triggered the implementation of NO_MMAP.
I am sure that there are more problems with it. BTW the problem stems from
Windows having _no_ equivalent to fork().
Notefoot 1: Isn't it funny that Windows cannot delete files which are
still opened, but does not care when it is renamed?
Ciao,
^ permalink raw reply
* Re: Can git be tweaked to work cross-platform, on FAT32?
From: Juergen Ruehle @ 2006-12-17 18:16 UTC (permalink / raw)
To: Stefano Spinucci
Cc: Martin Langhoff, Johannes Schindelin, Florian v. Savigny, git
In-Reply-To: <906f26060612170633h50e3e974h3b84f1829e546278@mail.gmail.com>
Stefano Spinucci writes:
> 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":
Compile git with NO_MMAP. The problem is that the old index file is
mmaped while it is replaced. Cygwin supports this operation only on
NTFS. I don't know whether this is a bug in cygwin or a windows
limitation (I suspect the latter).
Unfortunately NO_MMAP makes git pretty slow if the pack files get
larger than about 10-20 MB.
Johannes claims that there are additional problems with mmap on
cygwin, but it passes the complete test suite on NTFS, so it should be
ok for most operations
IIRC it has been suggested on the list that mmaping the index isn't
that important for git performance and it could be replaced by simply
reading the index file into memory on access.
It would be nice to have mmap work on non-NTFS partitions since my
tests suggest that FAT32 is up to twice as fast (in the hot cache
case). (My test version simply uses an unlink before the rename in
lockfile.c to hack around the cygwin rename problem.)
^ 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