* 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
* Re: Subprojects tasks
From: Martin Waitz @ 2006-12-18 7:45 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Jakub Narebski, git, Junio C Hamano
In-Reply-To: <200612180027.25308.Josef.Weidendorfer@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
On Mon, Dec 18, 2006 at 12:27:25AM +0100, Josef Weidendorfer wrote:
> 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?
At the moment, it's just the path inside the parent.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-branch: deleting remote branches in new layout
From: Junio C Hamano @ 2006-12-18 7:49 UTC (permalink / raw)
To: Quy Tonthat; +Cc: git
In-Reply-To: <7vbqm13cm0.fsf@assigned-by-dhcp.cox.net>
How about this instead?
Because -r already means "remote" when listing, you can say:
$ git branch -d -r origin/todo origin/html origin/man
I just twisted it not to do fast-forward check with the current
branch, because remote tracking branches are more like tags than
branches, and when you are removing them, most likely that is
not because you are "done with" them (for a local branch, it
usually means "you merged it up") but because you are not even
interested in them.
--
Junio C Hamano <junkio@cox.net> writes:
> 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).
builtin-branch.c | 41 ++++++++++++++++++++++++++++-------------
1 files changed, 28 insertions(+), 13 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 560309c..7fb93e7 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -12,8 +12,12 @@
#include "builtin.h"
static const char builtin_branch_usage[] =
- "git-branch (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>] | (-m | -M) [<oldbranch>] <newbranch> | [-r | -a] [-v [--abbrev=<length>]]";
+ "git-branch [-r] (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>] | (-m | -M) [<oldbranch>] <newbranch> | [-r | -a] [-v [--abbrev=<length>]]";
+#define REF_UNKNOWN_TYPE 0x00
+#define REF_LOCAL_BRANCH 0x01
+#define REF_REMOTE_BRANCH 0x02
+#define REF_TAG 0x04
static const char *head;
static unsigned char head_sha1[20];
@@ -89,25 +93,40 @@ static int in_merge_bases(const unsigned char *sha1,
return ret;
}
-static void delete_branches(int argc, const char **argv, int force)
+static void delete_branches(int argc, const char **argv, int force, int kinds)
{
struct commit *rev, *head_rev = head_rev;
unsigned char sha1[20];
char *name;
+ const char *fmt, *remote;
int i;
+ switch (kinds) {
+ case REF_REMOTE_BRANCH:
+ fmt = "refs/remotes/%s";
+ remote = "remote ";
+ force = 1;
+ break;
+ case REF_LOCAL_BRANCH:
+ fmt = "refs/heads/%s";
+ remote = "";
+ break;
+ default:
+ die("cannot use -a with -d");
+ }
+
if (!force) {
head_rev = lookup_commit_reference(head_sha1);
if (!head_rev)
die("Couldn't look up commit object for HEAD");
}
for (i = 0; i < argc; i++) {
- if (!strcmp(head, argv[i]))
+ if (kinds == REF_LOCAL_BRANCH && !strcmp(head, argv[i]))
die("Cannot delete the branch you are currently on.");
- name = xstrdup(mkpath("refs/heads/%s", argv[i]));
+ name = xstrdup(mkpath(fmt, argv[i]));
if (!resolve_ref(name, sha1, 1, NULL))
- die("Branch '%s' not found.", argv[i]);
+ die("%sbranch '%s' not found.", remote, argv[i]);
rev = lookup_commit_reference(sha1);
if (!rev)
@@ -128,19 +147,15 @@ static void delete_branches(int argc, const char **argv, int force)
}
if (delete_ref(name, sha1))
- printf("Error deleting branch '%s'\n", argv[i]);
+ printf("Error deleting %sbranch '%s'\n", remote,
+ argv[i]);
else
- printf("Deleted branch %s.\n", argv[i]);
+ printf("Deleted %sbranch %s.\n", remote, argv[i]);
free(name);
}
}
-#define REF_UNKNOWN_TYPE 0x00
-#define REF_LOCAL_BRANCH 0x01
-#define REF_REMOTE_BRANCH 0x02
-#define REF_TAG 0x04
-
struct ref_item {
char *name;
unsigned int kind;
@@ -435,7 +450,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
head += 11;
if (delete)
- delete_branches(argc - i, argv + i, force_delete);
+ delete_branches(argc - i, argv + i, force_delete, kinds);
else if (i == argc)
print_ref_list(kinds, verbose, abbrev);
else if (rename && (i == argc - 1))
^ permalink raw reply related
* Re: [PATCH] vim syntax: follow recent changes to commit template
From: Junio C Hamano @ 2006-12-18 8:02 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20061218072642.GA13858@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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>
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2006-12-18 8:09 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612172341.27709.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> 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?
I do not understand. What would that "pruning event" log entry
would say?
By definition each reflog entry says "it was pointing at this
object before, and it was changed by this user to point at that
object at this time and the reason for the change was this".
I personally do not think recording "at this point these things
were pruned" makes _any_ sense whatsoever --- if you care about
the pruned objects that simply means you pruned them before you
are ready to lose them. But even if for whatever reason you
choose to log that anyway, I have a feeling that that record
does not belong to the reflog itself.
^ permalink raw reply
* [PATCH] git-parse-remote: fix ambiguous shell bug in expand_refs_wildcard
From: Jeff King @ 2006-12-18 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Bash and dash parse "${name%'^{}'}" differently, with bash quoting the
^{}, and dash assuming the first } is the end of the variable (and thus
tacking '} to the end). Instead, use backslash to quote the closing
brace.
Signed-off-by: Jeff King <peff@peff.net>
---
Please sanity check that I understand what the code is supposed to be
doing. The bug I was getting was this:
$ readlink /bin/sh
dash
$ git-clone git://git.kernel.org/pub/scm/git/git.git
[...]
$ cd git && git-pull
Warning: No merge candidate found because value of config option
"branch.master.merge" does not match any remote branch fetched.
A shell trace showed lots of tests against strings like
"refs/heads/master'}". Expand_refs_wildcard returned no entries, so it
couldn't match the branch.master.merge field.
git-parse-remote.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index f27c3c2..ab79042 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -116,7 +116,7 @@ expand_refs_wildcard () {
while read sha1 name
do
mapped=${name#"$from"}
- if test "z$name" != "z${name%'^{}'}" ||
+ if test "z$name" != "z${name%'^{\}'}" ||
test "z$name" = "z$mapped"
then
continue
--
^ permalink raw reply related
* Re: [PATCH] git-parse-remote: fix ambiguous shell bug in expand_refs_wildcard
From: Jeff King @ 2006-12-18 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20061218080941.GA3857@coredump.intra.peff.net>
On Mon, Dec 18, 2006 at 03:09:41AM -0500, Jeff King wrote:
> - if test "z$name" != "z${name%'^{}'}" ||
> + if test "z$name" != "z${name%'^{\}'}" ||
Urgh, sorry, this is wrong. It should be:
${name%^{\}}
IOW, the \ replaces the quote, not in addition to.
^ permalink raw reply
* Unnecessary fetch warning
From: Shawn Pearce @ 2006-12-18 8:16 UTC (permalink / raw)
To: git
Current 'next':
$ git fetch
Warning: No merge candidate found because value of config option
"branch.sp/username-reflog.merge" does not match any remote branch fetched.
uhhh.. i asked for a fetch, not a merge.
I have no branch.*.merge or branch.*.remote in my .git/config,
and I only use the remote.*.url/remote.*.fetch format for my
remote configs.
Commit 62b339a5 added the warning, and its intended for pull, but
it is tripping during fetch too.
What about removing this warning from fetch, letting it mark
everything as `not-for-merge` and let pull trigger the warning
instead?
--
^ permalink raw reply
* [PATCH] Only warn about missing branch.<n>.merge in pull.
From: Shawn O. Pearce @ 2006-12-18 9:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Commit 62b339a5 added a warning for git-pull to notify the user when
they have not configured the setting 'branch.<n>.merge' (where <n>
is the current branch) and no arguments were given to git-pull to
specify the branches to merge.
Unfortunately this warning also appears in git-fetch when no
arguments were supplied, as the warning is being output at the
same time that the contents of FETCH_HEAD is being determined.
This causes users who fetch into local tracking branches prior
to merging to receive unexpected/unnecessary warnings:
$ git fetch
Warning: No merge candidate found because value of config option
"branch.sp/topic.merge" does not match any remote branch fetched.
This warning may also cause problems for other Porcelain that use
git-fetch as "plumbing", as the other Porcelain may not actually
use (or honor) the branch.<n>.merge configuration option.
Instead we should delay the warning about no matching branches until
we are actually in git-pull and are trying to setup the call to
git-merge to actually carry out the merge. This way direct users
of git-fetch do not receive these warnings.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-parse-remote.sh | 10 ----------
git-pull.sh | 16 +++++++++++++++-
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index f27c3c2..7a1cf5c 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -134,7 +134,6 @@ canon_refs_list_for_fetch () {
# or the first one otherwise; add prefix . to the rest
# to prevent the secondary branches to be merged by default.
merge_branches=
- found_mergeref=
curr_branch=
if test "$1" = "-d"
then
@@ -174,10 +173,6 @@ canon_refs_list_for_fetch () {
dot_prefix= && break
done
fi
- if test -z $dot_prefix
- then
- found_mergeref=true
- fi
case "$remote" in
'') remote=HEAD ;;
refs/heads/* | refs/tags/* | refs/remotes/*) ;;
@@ -198,11 +193,6 @@ canon_refs_list_for_fetch () {
fi
echo "${dot_prefix}${force}${remote}:${local}"
done
- if test -z "$found_mergeref" -a "$curr_branch"
- then
- echo >&2 "Warning: No merge candidate found because value of config option
- \"branch.${curr_branch}.merge\" does not match any remote branch fetched."
- fi
}
# Returns list of src: (no store), or src:dst (store)
diff --git a/git-pull.sh b/git-pull.sh
index e23beb6..d43a565 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -76,7 +76,21 @@ merge_head=$(sed -e '/ not-for-merge /d' \
case "$merge_head" in
'')
- echo >&2 "No changes."
+ echo >&2 "warning: No branches were selected for merge."
+ if test $# = 0
+ then
+ branch=$(git-symbolic-ref HEAD | sed -e 's|^refs/heads/||')
+ remote=$(git-repo-config --get-all "branch.$branch.remote")
+ if test -z "$remote"
+ then
+ echo >&2 "warning: (Config option 'branch.$branch.remote' not set.)"
+ fi
+ merge=$(git-repo-config --get-all "branch.$branch.merge")
+ if test -z "$merge"
+ then
+ echo >&2 "warning: (Config option 'branch.$branch.merge' not set.)"
+ fi
+ fi
exit 0
;;
?*' '?*)
--
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Andy Parkins @ 2006-12-18 9:17 UTC (permalink / raw)
To: git
In-Reply-To: <7vac1l1v8e.fsf@assigned-by-dhcp.cox.net>
On Monday 2006 December 18 08:09, Junio C Hamano wrote:
> By definition each reflog entry says "it was pointing at this
> object before, and it was changed by this user to point at that
> object at this time and the reason for the change was this".
I'm daft. I've realised, pruning doesn't remove the ref, it removes one of
the hashes in the reflog. I withdraw my comment.
I'd imagined it' as the opposite of a creation.
000000 abcdef branch created
abcdef 000000 branch deleted
Which is fine, except that isn't what prune is doing at all.
> I personally do not think recording "at this point these things
> were pruned" makes _any_ sense whatsoever --- if you care about
I think you're right. :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Shawn Pearce @ 2006-12-18 9:33 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612180917.46214.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> I'm daft. I've realised, pruning doesn't remove the ref, it removes one of
> the hashes in the reflog. I withdraw my comment.
>
> I'd imagined it' as the opposite of a creation.
>
> 000000 abcdef branch created
> abcdef 000000 branch deleted
Except that branch deletion also deletes the reflog. So yes, we
could log it as you show above, but right after we appended it to
the log we'd delete the log anyway. :-)
The immediate log deletion is necessary to support something like:
git branch foo
git branch -d foo
git branch foo/bar
as foo switches from being a file to a directory, which means that
.git/logs/refs/heads/foo also needs to switch from being a file to
being a directory.
The only way to fix the above situation is to make the reflog a
single log for the entire repository, rather than one log per ref.
This may cause locking problems for us as we need to lock not only
the ref but also the repository-wide reflog lock. Note that right
now the reflog is also protected by the ref lock itself, killing
two birds with one stone. :-)
--
^ permalink raw reply
* [PATCH 1/2] add for_each_reflog_ent() iterator
From: Junio C Hamano @ 2006-12-18 9:40 UTC (permalink / raw)
To: git
In-Reply-To: <7vodq3a136.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
refs.c | 25 +++++++++++++++++++++++++
refs.h | 4 ++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/refs.c b/refs.c
index d911b9e..db8fdd4 100644
--- a/refs.c
+++ b/refs.c
@@ -1093,3 +1093,28 @@ int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *
logfile, show_rfc2822_date(date, tz));
return 0;
}
+
+void for_each_reflog_ent(const char *ref, each_reflog_ent_fn fn, void *cb_data)
+{
+ const char *logfile;
+ FILE *logfp;
+ char buf[1024];
+
+ logfile = git_path("logs/%s", ref);
+ logfp = fopen(logfile, "r");
+ if (!logfp)
+ return;
+ while (fgets(buf, sizeof(buf), logfp)) {
+ unsigned char osha1[20], nsha1[20];
+ int len;
+
+ /* old SP new SP name <email> SP time TAB msg LF */
+ len = strlen(buf);
+ if (len < 83 || buf[len-1] != '\n' ||
+ get_sha1_hex(buf, osha1) || buf[40] != ' ' ||
+ get_sha1_hex(buf + 41, nsha1) || buf[81] != ' ')
+ continue; /* corrupt? */
+ fn(osha1, nsha1, buf+82, cb_data);
+ }
+ fclose(logfp);
+}
diff --git a/refs.h b/refs.h
index 51aab1e..de43cc7 100644
--- a/refs.h
+++ b/refs.h
@@ -44,6 +44,10 @@ extern int write_ref_sha1(struct ref_lock *lock, const unsigned char *sha1, cons
/** Reads log for the value of ref during at_time. **/
extern int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *sha1);
+/* iterate over reflog entries */
+typedef int each_reflog_ent_fn(unsigned char *osha1, unsigned char *nsha1, char *, void *);
+void for_each_reflog_ent(const char *ref, each_reflog_ent_fn fn, void *cb_data);
+
/** Returns 0 if target has the right format for a ref. **/
extern int check_ref_format(const char *target);
--
1.4.4.2.gc30f
^ permalink raw reply related
* [PATCH 2/2] Protect commits recorded in reflog from pruning.
From: Junio C Hamano @ 2006-12-18 9:42 UTC (permalink / raw)
To: git
In-Reply-To: <7vodq3a136.fsf@assigned-by-dhcp.cox.net>
This teaches fsck-objects and prune to protect objects referred
to by reflog entries.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
>> - now reflog is enabled by default for user repositories, I
>> have two worries about its effect, fortunately can be killed
>> with a single stone.
>>
>> * the reflog grows unbounded;
>>
>> * revisions recorded in the reflog can be pruned out,
>> rendering some entries in reflog useless.
>>
>> 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 ;-).
Rewinding would not lose any objects from the object database
with this; somebody needs to code up a garbage collector and/or
expiration mechanism for reflogs.
builtin-prune.c | 16 ++++++++++++++++
fsck-objects.c | 22 ++++++++++++++++++++++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/builtin-prune.c b/builtin-prune.c
index 8591d28..00a53b3 100644
--- a/builtin-prune.c
+++ b/builtin-prune.c
@@ -181,12 +181,28 @@ static void walk_commit_list(struct rev_info *revs)
}
}
+static int add_one_reflog_ent(unsigned char *osha1, unsigned char *nsha1, char *datail, void *cb_data)
+{
+ struct object *object;
+
+ object = parse_object(osha1);
+ if (object)
+ add_pending_object(&revs, object, "");
+ object = parse_object(nsha1);
+ if (object)
+ add_pending_object(&revs, object, "");
+ return 0;
+}
+
static int add_one_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
{
struct object *object = parse_object(sha1);
if (!object)
die("bad object ref: %s:%s", path, sha1_to_hex(sha1));
add_pending_object(&revs, object, "");
+
+ for_each_reflog_ent(path, add_one_reflog_ent, NULL);
+
return 0;
}
diff --git a/fsck-objects.c b/fsck-objects.c
index 46b628c..e3746e8 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -402,6 +402,25 @@ static void fsck_dir(int i, char *path)
static int default_refs;
+static int fsck_handle_reflog_ent(unsigned char *osha1, unsigned char *nsha1, char *datail, void *cb_data)
+{
+ struct object *obj;
+
+ if (!is_null_sha1(osha1)) {
+ obj = lookup_object(osha1);
+ if (obj) {
+ obj->used = 1;
+ mark_reachable(obj, REACHABLE);
+ }
+ }
+ obj = lookup_object(nsha1);
+ if (obj) {
+ obj->used = 1;
+ mark_reachable(obj, REACHABLE);
+ }
+ return 0;
+}
+
static int fsck_handle_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
struct object *obj;
@@ -419,6 +438,9 @@ static int fsck_handle_ref(const char *refname, const unsigned char *sha1, int f
default_refs++;
obj->used = 1;
mark_reachable(obj, REACHABLE);
+
+ for_each_reflog_ent(refname, fsck_handle_reflog_ent, NULL);
+
return 0;
}
--
1.4.4.2.gc30f
^ permalink raw reply related
* Re: [PATCH] git-branch: deleting remote branches in new layout
From: Quy Tonthat @ 2006-12-18 10:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodq11w49.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> How about this instead?
>
> Because -r already means "remote" when listing, you can say:
>
> $ git branch -d -r origin/todo origin/html origin/man
>
> I just twisted it not to do fast-forward check with the current
> branch, because remote tracking branches are more like tags than
> branches, and when you are removing them, most likely that is
> not because you are "done with" them (for a local branch, it
> usually means "you merged it up") but because you are not even
> interested in them.
It sure is much more unambiguous that way.
Users won't be able to mix "local" and "remote" on one command
line as they were with the old layout. But that's OK for such an
infrequently used command.
> if (!resolve_ref(name, sha1, 1, NULL))
> - die("Branch '%s' not found.", argv[i]);
> + die("%sbranch '%s' not found.", remote, argv[i]);
This should not be a fatal error. We should only give warning
and move on to the next item. The way "rm" does.
Quy
^ permalink raw reply
* Re: Subprojects tasks
From: Josef Weidendorfer @ 2006-12-18 10:30 UTC (permalink / raw)
To: Martin Waitz; +Cc: Jakub Narebski, git, Junio C Hamano
In-Reply-To: <20061218074441.GJ12411@admingilde.org>
On Monday 18 December 2006 08:44, Martin Waitz wrote:
> 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.
Ah, I see.
Yes, this is consistent with other dirty files.
> > 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.
Yes.
However, you want to do development on these branches. And
"refs/tracked/..." is read-only. However, taking the whole local
refs namespace is not good, as you perhaps want branches independent
of the supermodule, which could give name conflicts.
What about using "refs/{heads,tags}/supermodule/..."? This could
be a compromise.
> > 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.
But you already have the same problem with your current approach, don't
you?
Actually, the most expected thing for the user really would be to use
HEAD in supermodule commits. Every other behavior can get confusing for
the user: (S)He simply expects the state of the checkout to be committed.
Any branch switching in submodules should be temporary.
Actually, you can be on a temporary branch in a submodule and still switch
branches in the supermodule. It is the same as with dirty files: The
modifications can be carried over to other branches and back, as long as
there are no conflicts.
However, I think it is important to check that you are back on the
right branch when committing. With warning or even error.
^ permalink raw reply
* Re: [PATCH] Only warn about missing branch.<n>.merge in pull.
From: Santi Béjar @ 2006-12-18 11:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061218091206.GA11284@spearce.org>
On 12/18/06, Shawn O. Pearce <spearce@spearce.org> wrote:
> Commit 62b339a5 added a warning for git-pull to notify the user when
> they have not configured the setting 'branch.<n>.merge' (where <n>
> is the current branch) and no arguments were given to git-pull to
> specify the branches to merge.
>
> Unfortunately this warning also appears in git-fetch when no
> arguments were supplied, as the warning is being output at the
> same time that the contents of FETCH_HEAD is being determined.
> This causes users who fetch into local tracking branches prior
> to merging to receive unexpected/unnecessary warnings:
>
> $ git fetch
> Warning: No merge candidate found because value of config option
> "branch.sp/topic.merge" does not match any remote branch fetched.
>
> This warning may also cause problems for other Porcelain that use
> git-fetch as "plumbing", as the other Porcelain may not actually
> use (or honor) the branch.<n>.merge configuration option.
>
> Instead we should delay the warning about no matching branches until
> we are actually in git-pull and are trying to setup the call to
> git-merge to actually carry out the merge. This way direct users
> of git-fetch do not receive these warnings.
>
I think it is a sensible thing to do, but:
[...]
> diff --git a/git-pull.sh b/git-pull.sh
> index e23beb6..d43a565 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -76,7 +76,21 @@ merge_head=$(sed -e '/ not-for-merge /d' \
>
> case "$merge_head" in
> '')
> - echo >&2 "No changes."
> + echo >&2 "warning: No branches were selected for merge."
> + if test $# = 0
> + then
> + branch=$(git-symbolic-ref HEAD | sed -e 's|^refs/heads/||')
> + remote=$(git-repo-config --get-all "branch.$branch.remote")
There is only support for one branch.<n>.remote.
> + if test -z "$remote"
> + then
> + echo >&2 "warning: (Config option 'branch.$branch.remote' not set.)"
It is OK not to have a branch.<n>.remote, it defaults to origin.
> + fi
> + merge=$(git-repo-config --get-all "branch.$branch.merge")
> + if test -z "$merge"
> + then
> + echo >&2 "warning: (Config option 'branch.$branch.merge' not set.)"
> + fi
> + fi
I don't like the (), and it's missing the other possibility:
else
echo >&2 "Warning: config option 'branch.$branch.merge' does not
match any remote branch fetched."
Also we could check that the number of to be merge branches equals to
the number of branch.<n>.merge (I'll do it).
^ permalink raw reply
* Re: [RFC] A unique way to express "all" (vs "add vs "update") ?
From: Jerome Lovy @ 2006-12-18 11:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <4582906A.7020204@op5.se>
Hi,
Andreas Ericsson wrote:
> Jerome Lovy wrote:
>> While I am very happy with the refactorings undertaken with regard to
>> "git add/git commit" (both for UI and documentation), I am still a
>> little confused by the different ways I seem to find to express the idea
>> "I want to add (sort of) all file contents".
>>
>> To be more specific, I find the following in the current documentation:
>>
>> git add <dir>
>> "adds content from all files under <dir> directory and its
>> subdirectories."
>> (as interpreted from the "EXAMPLES" section of the git-add
>> man-page)
>> (BTW, could this <dir> usage be documented in the SYNOPSIS and
>> DESCRIPTION sections (admittedly at a 2nd rank after the
>> currently documented usage) as well as in the EXAMPLES ?
>> Besides this reference sections would probably include the
>> <dir>/<regexp> usage that I've not mentioned here for the sake
>> of simplicity.)
>> Moreover, the tutorial documents the typical usage "git add ."
>>
>> git commit -a|--all
>> "automatically stage files that have been modified and deleted,
>> but new files you have not told git about are not affected."
>>
>> Granted, the latter semantics for "all" is not exactly the same as the
>> former. Nonetheless, I think it would be very nice to only have to
>> memorize one way to express "all".
>>
>
> But the former isn't "all"; It's a specific directory, although "."
> happens to *look* like "all", you can run "git add ." in a subdirectory
> inside the repository and it won't mean "all" anymore. Likewise, you can
> say "git commit ." from a subdirectory and have it commit all changes to
> all tracked files under that directory.
OK. For my information, are the following commands completely
equivalent ?
1) git commit -a
2) (cd `git-rev-parse --git-dir`/..; git commit .)
>
>> To this end, I would be very happy with the following:
>> (X-mas is coming soon, isn't it ;-) )
>>
>> git add <dir>
>> same semantics
>>
>> git commit -a|--add <files>
>> "adds content from the specified files before committing
>> (files that are already tracked have their current content
>> staged)"
>>
>> git commit -a|--add <dir>
>> "adds content from all files under <dir> directory and its
>> subdirectories before committing"
>> (once again, for simplification of my explanations, I omit the
>> <dir>/<regexp> usage here)
>>
>> git commit -u|--update <dir>
>> "automatically stage files that have been modified and deleted
>> under <dir> directory and its subdirectories, but new files you
>> have not told git about are not affected."
>> (once again, for simplification of my explanations, I omit the
>> <dir>/<regexp> usage here)
>>
>
> But this isn't "commit" at all. It's "git add".
OK. To faithfully follow the current existing description of
'git commit -a', I should have indeed written:
git commit -u|--update <dir>
"_Tell the command to_ automatically stage files that have been
modified and deleted under <dir> directory and its subdirectories,
but new files you have not told git about are not affected."
>
>> (This would allow the typical usage "git commit -u ." which is
>> barely longer than the current "git commit -a")
>>
>> For interface completeness, "git commit -u|--update <files>" could also
>> exist but would probably be of no use.
>>
>> To sum up, "all" would be consistently expressed with the <dir> syntax.
>> "git commit -a" would not mean "--all" anymore. Lastly, a distinction
>> would be made between "--add" and "--update":
>> - "git commit -add" would have the same semantics as "git add"
>
> This is bollocks. git commit should commit things. We'll be in some
> serious trouble if "git commit -a" stops working the way it has and
> starts just adding things to index.
OK. I obviously wasn't precise enough. Let me restate:
- "git commit -add" would allow the same <file>/<dir> parameter usage as
"git add"
>
>> - "git commit --update" on the other hand would only affect the files
>> already tracked
>>
>
> I fail to see what you're after with the changes propsed in this mail.
> Is there a use-case you've encountered where you wanted to do something
> that wasn't possible, or easy enough, that made you post this?
My case is not that I've encountered something that wasn't possible or
easy enough (everything is indeed possible with the right combination of
"git add" and "git commit"), but rather that I candidly felt that
"--all" is more difficult to understand/learn/memorize/teach than
expected since it doesn't really mean "all" (because it excludes "new
files you have not told git about").
>
> Unless it's a very, very good reason I most urgently think we're better
> off keeping the current "git commit -a" behaviour.
>
^ permalink raw reply
* Can't fetch 2.6.20-rc1 tag...
From: Francis Moreau @ 2006-12-18 11:56 UTC (permalink / raw)
To: git
Hi
I've got this problem when issuing the following command in a kernel repo:
$ git branch
* master
origin
$ git pull -tags
fatal: unexpected EOF
Fetch failure:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
My git version is '1.4.4.2'
Can anybody tell me what I'm doing wrong ?
thanks
--
^ permalink raw reply
* Re: [PATCH] git-diff: don't add trailing blanks (i.e., do what GNU diff -u now does)
From: Johannes Schindelin @ 2006-12-18 12:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <em4all$b2c$1@sea.gmane.org>
Hi,
On Sun, 17 Dec 2006, Jakub Narebski wrote:
> 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?
Rather --braindead-gnu-bug-compatibility.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-fetch: Avoid reading packed refs over and over again
From: Johannes Schindelin @ 2006-12-18 12:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslfe3r4d.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 17 Dec 2006, Junio C Hamano wrote:
> How about this as a replacement?
Makes sense, except for:
> --- 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";
Here, you want to either not mention it at all, or add
"--exclude-existing[=<pattern>]" instead of "--filter-invalid".
> + if (!strcmp(buf + len - 3, "^{}")) {
Here you have to check first, if len > 3. Strictly speaking, there should
not be any line coming in which is shorter than 42 bytes. But I was
recentely bitten by such an assuption...
Overall, I like it. I even have the impression that this could actually
open a way to build in fetch instead of relying on a POSIX conformant and
fast shell for such a central part of git.
Ciao,
Dscho
^ permalink raw reply
* Re: Can't fetch 2.6.20-rc1 tag...
From: Sean @ 2006-12-18 12:29 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <38b2ab8a0612180356t5c04f5bn29d7be3d0aa40764@mail.gmail.com>
On Mon, 18 Dec 2006 12:56:09 +0100
"Francis Moreau" <francis.moro@gmail.com> wrote:
> fatal: unexpected EOF
> Fetch failure:
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> My git version is '1.4.4.2'
>
> Can anybody tell me what I'm doing wrong ?
You're not doing anything wrong. There is a problem on one of the
kernel.org mirrors, it seems to have been that way for a few days.
If you use "204.152.191.37" instead of git.kernel.org it should work.
^ permalink raw reply
* Re: Can't fetch 2.6.20-rc1 tag...
From: Francis Moreau @ 2006-12-18 13:09 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP1091AB27E446DFAD251A6DAEC90@CEZ.ICE>
On 12/18/06, Sean <seanlkml@sympatico.ca> wrote:
> You're not doing anything wrong. There is a problem on one of the
> kernel.org mirrors, it seems to have been that way for a few days.
> If you use "204.152.191.37" instead of git.kernel.org it should work.
>
Yes it does.
thanks for your answer.
--
^ permalink raw reply
* Re: Can git be tweaked to work cross-platform, on FAT32?
From: Johannes Schindelin @ 2006-12-18 13:38 UTC (permalink / raw)
To: Stefano Spinucci; +Cc: Juergen Ruehle, Martin Langhoff, Florian v. Savigny, git
In-Reply-To: <906f26060612171736pab766b7t15a36d4d3fc7e85f@mail.gmail.com>
Hi,
On Mon, 18 Dec 2006, Stefano Spinucci wrote:
> 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().
> > ...
>
> 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 ???
I argued for that a long time ago, but there were a couple "works-for-me"s
and I just shut up.
It could also be the case that for most operations, git became safe over
time. For example, my biggest problem was the fork()ed diff in git-log,
which was substituted by a non-forking inbuilt diff.
> 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 ???
Given that most Windows setups nowadays run on NTFS, I doubt that this is
necessary. I use NO_MMAP myself on Windows, just in case, though.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] (Take 2) git-branch: deleting remote branches in new layout
From: Quy Tonthat @ 2006-12-18 13:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodq11w49.fsf@assigned-by-dhcp.cox.net>
This patch is based on Junio's patch (all errors are my fault, of
course) to provide the following features to 'git-branch -d|-D'
o Option -r can be used with -d or -D to delete "remote" (tracking)
branch(es), for examples,
git branch -d -r origin/man origin/html
this command will delete the named branches in $GIT_DIR/refs/remotes,
according to the new layout.
(No, you can no longer mix "local" and "remote" branches in one
deletion command.)
o If there are more than one branches to be deleted, failure on one will
no longer stop git-branch to process the next ones.
o 'git-branch -d|-D' now returns error code 1 if at least one of
branches deleting is failed. (0 returned for fully success as before)
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
---
This patch is to replace my previous patch.
builtin-branch.c | 57 ++++++++++++++++++++++++++++++++++++-----------------
1 files changed, 39 insertions(+), 18 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 7fb93e7..52b6b5a 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -93,13 +93,14 @@ static int in_merge_bases(const unsigned char *sha1,
return ret;
}
-static void delete_branches(int argc, const char **argv, int force, int kinds)
+static int delete_branches(int argc, const char **argv, int force, int kinds)
{
struct commit *rev, *head_rev = head_rev;
unsigned char sha1[20];
- char *name;
+ char *name = NULL;
const char *fmt, *remote;
int i;
+ int ret = 0;
switch (kinds) {
case REF_REMOTE_BRANCH:
@@ -121,16 +122,30 @@ static void delete_branches(int argc, const char **argv, int force, int kinds)
die("Couldn't look up commit object for HEAD");
}
for (i = 0; i < argc; i++) {
- if (kinds == REF_LOCAL_BRANCH && !strcmp(head, argv[i]))
- die("Cannot delete the branch you are currently on.");
+ if (kinds == REF_LOCAL_BRANCH && !strcmp(head, argv[i])) {
+ error("Cannot delete the branch '%s' "
+ "which you are currently on.", argv[i]);
+ ret = 1;
+ continue;
+ }
+
+ if (name)
+ free(name);
name = xstrdup(mkpath(fmt, argv[i]));
- if (!resolve_ref(name, sha1, 1, NULL))
- die("%sbranch '%s' not found.", remote, argv[i]);
+ if (!resolve_ref(name, sha1, 1, NULL)) {
+ error("%sbranch '%s' not found.",
+ remote, argv[i]);
+ ret = 1;
+ continue;
+ }
rev = lookup_commit_reference(sha1);
- if (!rev)
- die("Couldn't look up commit object for '%s'", name);
+ if (!rev) {
+ error("Couldn't look up commit object for '%s'", name);
+ ret = 1;
+ continue;
+ }
/* This checks whether the merge bases of branch and
* HEAD contains branch -- which means that the HEAD
@@ -139,21 +154,26 @@ static void delete_branches(int argc, const char **argv, int force, int kinds)
if (!force &&
!in_merge_bases(sha1, rev, head_rev)) {
- fprintf(stderr,
- "The branch '%s' is not a strict subset of your current HEAD.\n"
- "If you are sure you want to delete it, run 'git branch -D %s'.\n",
+ error("The branch '%s' is not a strict subset of your current HEAD."
+ "If you are sure you want to delete it, run 'git branch -D %s'.",
argv[i], argv[i]);
- exit(1);
+ ret = 1;
+ continue;
}
- if (delete_ref(name, sha1))
- printf("Error deleting %sbranch '%s'\n", remote,
+ if (delete_ref(name, sha1)) {
+ error("Error deleting %sbranch '%s'", remote,
argv[i]);
- else
+ ret = 1;
+ } else
printf("Deleted %sbranch %s.\n", remote, argv[i]);
- free(name);
}
+
+ if (name)
+ free(name);
+
+ return(ret);
}
struct ref_item {
@@ -372,6 +392,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
int reflog = 0;
int kinds = REF_LOCAL_BRANCH;
int i;
+ int status = 0;
setup_ident();
git_config(git_branch_config);
@@ -450,7 +471,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
head += 11;
if (delete)
- delete_branches(argc - i, argv + i, force_delete, kinds);
+ status = delete_branches(argc - i, argv + i, force_delete, kinds);
else if (i == argc)
print_ref_list(kinds, verbose, abbrev);
else if (rename && (i == argc - 1))
@@ -464,5 +485,5 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
else
usage(builtin_branch_usage);
- return 0;
+ return (status);
}
--
1.4.4.1.GIT
^ permalink raw reply related
* Re: [RFC] A unique way to express "all" (vs "add vs "update") ?
From: Jerome Lovy @ 2006-12-18 14:04 UTC (permalink / raw)
To: git
In-Reply-To: <87mz5o4v2v.wl%cworth@cworth.org>
Carl Worth wrote:
> On Fri, 15 Dec 2006 12:38:51 +0100, Jerome Lovy wrote:
>> While I am very happy with the refactorings undertaken with regard to
>> "git add/git commit" (both for UI and documentation), I am still a
>> little confused by the different ways I seem to find to express the idea
>> "I want to add (sort of) all file contents".
>
> I agree that there have been huge improvements---particularly in
> documentation. So thanks to everybody!
>
> Here's a simpler idea that might add the unification you're looking
> for. How about a new option:
>
> git add -a|--all
>
> This would allow "git commit -a|--all" to be understood as a simple
> helper for:
>
> git add -a|--all
> git commit
>
> That kind of unification seems like it could be helpful while learning
> things.
Exactly. I like it.
Now, it underlines the fact that this "--all" should IMHO rather be
called "--all-known" or the like - both for "add" and "commit" - but all
the same, I would be very happy with a more complete "git add" following
your proposed unification.
Jérôme
^ 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