* Re: [1.8.0] Provide proper remote ref namespaces
From: Nguyen Thai Ngoc Duy @ 2011-02-03 5:33 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Sverre Rabbelier, Jeff King, Nicolas Pitre
In-Reply-To: <201102020322.00171.johan@herland.net>
On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net> wrote:
> Migration plan:
> ...
> In v1.8.0, we should default to the new default refspecs when creating new
> remotes. However, existing remotes (created pre-v1.8.0) must continue to
> work as before, so we cannot simply remove the implicit refspecs (or tag
> auto-following). Instead we need to make sure that the implicit refspecs is
> NOT applied to the new-style remotes. Identifying new-style vs. old-style
> remotes can be done by looking at the refspec itself (old-style:
> "refs/remotes/$remote/*", new-style: "refs/remotes/$remote/heads/*"), or
> (worst case) by introducing a config variable specifying the desired
> behavior (defaulting to old-style).
How about convert old style remotes to new style? Should it be done
automatically when new git detects old style remotes, or done by
command, or manually?
--
Duy
^ permalink raw reply
* Re: Q: does index-pack work in place on windows?
From: Nicolas Pitre @ 2011-02-03 5:32 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Junio C Hamano, Johannes Sixt, git, Shawn O. Pearce
In-Reply-To: <AANLkTi=m+kERSH7TJFjuRaUfA7FR03zwNn2PKFxrqiOp@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1991 bytes --]
On Wed, 2 Feb 2011, Erik Faye-Lund wrote:
> On Wed, Feb 2, 2011 at 9:21 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > ... or any other (operating / file) system where you cannot unlink a file
> > that is open?
> >
> > When you run
> >
> > $ git clone git://some.where/repo/sitory.git local
> > $ cd local
> > $ git index-pack .git/objects/pack/pack-*.pack
> >
> > there is a call to write_idx_file() in builtin/index-pack.c, that feeds
> > the correct (and existing) name of the corresponding pack idx file.
> >
> > The callee in pack-write.c, after sorting the list of objects contained in
> > the pack, does this:
> >
> > if (!index_name) {
> > static char tmpfile[PATH_MAX];
> > fd = odb_mkstemp(tmpfile, sizeof(tmpfile), "pack/tmp_idx_XXXXXX");
> > index_name = xstrdup(tmpfile);
> > } else {
> > unlink(index_name);
> > fd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);
> > }
> >
> > and then writes out the pack index to the file descriptor. But index-pack
> > uses the usual has_sha1_file() and read_sha1_file() interface to validate
> > the "existing" objects, and is likely to have mmapped the .idx file when
> > it called use_pack_window(). Which makes me suspect that this unlink (or
> > the open that immediately follows) may fail on systems that do not allow
> > unlink on inode that has still users.
>
> ...and you're right:
>
> $ git index-pack
> .git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.pack
> Unlink of file '.git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.idx'
> failed. Should I try again? (y/n)? n
> fatal: unable to create
> '.git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.idx':
> File exists
Why would you do such thing in the first place?
If the pack exists along with its index on disk, there is no point
recreating it. Maybe index-pack should just bail out early in that
case.
Nicolas
^ permalink raw reply
* [PATCH 2/3] Allow git commit --interactive with paths
From: Conrad Irwin @ 2011-02-03 5:25 UTC (permalink / raw)
To: git; +Cc: conrad.irwin
In-Reply-To: <1296710732-12493-1-git-send-email-conrad.irwin@gmail.com>
Make git commit --interactive feel more like git add --interactive by
allowing the user to restrict the list of files they have to deal with.
Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
---
builtin/commit.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 41f0e2e..592c2d2 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1012,8 +1012,6 @@ static int parse_and_validate_options(int argc, const char *argv[],
if (all && argc > 0)
die("Paths with -a does not make sense.");
- else if (interactive && argc > 0)
- die("Paths with --interactive does not make sense.");
if (null_termination && status_format == STATUS_FORMAT_LONG)
status_format = STATUS_FORMAT_PORCELAIN;
--
1.7.4.1.g1c7a9.dirty
^ permalink raw reply related
* [PATCH 3/3] Add support for -p/--patch to git-commit
From: Conrad Irwin @ 2011-02-03 5:25 UTC (permalink / raw)
To: git; +Cc: conrad.irwin
In-Reply-To: <1296710732-12493-1-git-send-email-conrad.irwin@gmail.com>
The --interactive flag is already shared by git add and git commit,
share the -p and --patch flags too.
Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
---
Documentation/git-commit.txt | 25 ++++++++++++++++---------
builtin/add.c | 6 +++---
builtin/commit.c | 10 +++++++---
commit.h | 2 +-
4 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index ca755db..81156f0 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -8,11 +8,12 @@ git-commit - Record changes to the repository
SYNOPSIS
--------
[verse]
-'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
- [(-c | -C | --fixup | --squash) <commit>] [-F <file> | -m <msg>]
- [--reset-author] [--allow-empty] [--allow-empty-message] [--no-verify]
- [-e] [--author=<author>] [--date=<date>] [--cleanup=<mode>]
- [--status | --no-status] [-i | -o] [--] [<file>...]
+'git commit' [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
+ [--dry-run] [(-c | -C | --fixup | --squash) <commit>]
+ [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
+ [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
+ [--date=<date>] [--cleanup=<mode>] [--status | --no-status]
+ [-i | -o] [--] [<file>...]
DESCRIPTION
-----------
@@ -39,10 +40,10 @@ The content to be added can be specified in several ways:
that have been removed from the working tree, and then perform the
actual commit;
-5. by using the --interactive switch with the 'commit' command to decide one
- by one which files should be part of the commit, before finalizing the
- operation. Currently, this is done by invoking 'git add --interactive'
- on a temporary index.
+5. by using the --interactive or --patch switches with the 'commit' command
+ to decide one by one which files or hunks should be part of the commit,
+ before finalizing the operation. Currently, this is done by invoking
+ 'git add --interactive' or 'git add --patch' on a temporary index.
The `--dry-run` option can be used to obtain a
summary of what is included by any of the above for the next
@@ -60,6 +61,12 @@ OPTIONS
been modified and deleted, but new files you have not
told git about are not affected.
+-p::
+--patch::
+ Use the interactive patch selection interface to chose
+ which changes to commit. See linkgit:git-add[1] for
+ details.
+
-C <commit>::
--reuse-message=<commit>::
Take an existing commit object, and reuse the log message
diff --git a/builtin/add.c b/builtin/add.c
index 12b964e..3d074b3 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -242,7 +242,7 @@ int run_add_interactive(const char *revision, const char *patch_mode,
return status;
}
-int interactive_add(int argc, const char **argv, const char *prefix)
+int interactive_add(int argc, const char **argv, const char *prefix, int patch)
{
const char **pathspec = NULL;
@@ -253,7 +253,7 @@ int interactive_add(int argc, const char **argv, const char *prefix)
}
return run_add_interactive(NULL,
- patch_interactive ? "--patch" : NULL,
+ patch ? "--patch" : NULL,
pathspec);
}
@@ -378,7 +378,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (patch_interactive)
add_interactive = 1;
if (add_interactive)
- exit(interactive_add(argc - 1, argv + 1, prefix));
+ exit(interactive_add(argc - 1, argv + 1, prefix, patch_interactive));
if (edit_interactive)
return(edit_patch(argc, argv, prefix));
diff --git a/builtin/commit.c b/builtin/commit.c
index 592c2d2..0c53dc9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -70,7 +70,7 @@ static const char *logfile, *force_author;
static const char *template_file;
static char *edit_message, *use_message;
static char *fixup_message, *squash_message;
-static int all, edit_flag, also, interactive, only, amend, signoff;
+static int all, edit_flag, also, interactive, patch_interactive, only, amend, signoff;
static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
static int no_post_rewrite, allow_empty_message;
static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
@@ -138,6 +138,7 @@ static struct option builtin_commit_options[] = {
OPT_BOOLEAN('a', "all", &all, "commit all changed files"),
OPT_BOOLEAN('i', "include", &also, "add specified files to index for commit"),
OPT_BOOLEAN(0, "interactive", &interactive, "interactively add files"),
+ OPT_BOOLEAN('p', "patch", &patch_interactive, "interactively add changes"),
OPT_BOOLEAN('o', "only", &only, "commit only specified files"),
OPT_BOOLEAN('n', "no-verify", &no_verify, "bypass pre-commit hook"),
OPT_BOOLEAN(0, "dry-run", &dry_run, "show what would be committed"),
@@ -316,7 +317,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
old_index_env = getenv(INDEX_ENVIRONMENT);
setenv(INDEX_ENVIRONMENT, index_lock.filename, 1);
- if (interactive_add(argc, argv, prefix) != 0)
+ if (interactive_add(argc, argv, prefix, patch_interactive) != 0)
die("interactive add failed");
if (old_index_env && *old_index_env)
@@ -989,8 +990,11 @@ static int parse_and_validate_options(int argc, const char *argv[],
use_message_buffer = xstrdup(commit->buffer);
}
+ if (patch_interactive)
+ interactive = 1;
+
if (!!also + !!only + !!all + !!interactive > 1)
- die("Only one of --include/--only/--all/--interactive can be used.");
+ die("Only one of --include/--only/--all/--interactive/--patch can be used.");
if (argc == 0 && (also || (only && !amend)))
die("No paths with --include/--only does not make sense.");
if (argc == 0 && only && amend)
diff --git a/commit.h b/commit.h
index eb6c5af..951c22e 100644
--- a/commit.h
+++ b/commit.h
@@ -160,7 +160,7 @@ extern struct commit_list *get_shallow_commits(struct object_array *heads,
int is_descendant_of(struct commit *, struct commit_list *);
int in_merge_bases(struct commit *, struct commit **, int);
-extern int interactive_add(int argc, const char **argv, const char *prefix);
+extern int interactive_add(int argc, const char **argv, const char *prefix, int patch);
extern int run_add_interactive(const char *revision, const char *patch_mode,
const char **pathspec);
--
1.7.4.1.g1c7a9.dirty
^ permalink raw reply related
* [PATCH 1/3] Use a temporary index for git commit --interactive
From: Conrad Irwin @ 2011-02-03 5:25 UTC (permalink / raw)
To: git; +Cc: conrad.irwin
In-Reply-To: <1296710732-12493-1-git-send-email-conrad.irwin@gmail.com>
Change the behaviour of git commit --interactive so that when you abort
the commit (by leaving the commit message empty) the index remains
unchanged.
Hitherto an aborted commit --interactive has added the selected hunks to
the index regardless of whether the commit succeeded or not.
Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
---
Documentation/git-commit.txt | 3 ++-
builtin/commit.c | 36 ++++++++++++++++++++++++++++--------
2 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index b586c0f..ca755db 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -41,7 +41,8 @@ The content to be added can be specified in several ways:
5. by using the --interactive switch with the 'commit' command to decide one
by one which files should be part of the commit, before finalizing the
- operation. Currently, this is done by invoking 'git add --interactive'.
+ operation. Currently, this is done by invoking 'git add --interactive'
+ on a temporary index.
The `--dry-run` option can be used to obtain a
summary of what is included by any of the above for the next
diff --git a/builtin/commit.c b/builtin/commit.c
index 03cff5a..41f0e2e 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -292,18 +292,11 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
int fd;
struct string_list partial;
const char **pathspec = NULL;
+ char *old_index_env = NULL;
int refresh_flags = REFRESH_QUIET;
if (is_status)
refresh_flags |= REFRESH_UNMERGED;
- if (interactive) {
- if (interactive_add(argc, argv, prefix) != 0)
- die("interactive add failed");
- if (read_cache_preload(NULL) < 0)
- die("index file corrupt");
- commit_style = COMMIT_AS_IS;
- return get_index_file();
- }
if (*argv)
pathspec = get_pathspec(prefix, argv);
@@ -311,6 +304,33 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
if (read_cache_preload(pathspec) < 0)
die("index file corrupt");
+ if (interactive) {
+ fd = hold_locked_index(&index_lock, 1);
+
+ refresh_cache_or_die(refresh_flags);
+
+ if (write_cache(fd, active_cache, active_nr) ||
+ close_lock_file(&index_lock))
+ die("unable to write new_index file");
+
+ old_index_env = getenv(INDEX_ENVIRONMENT);
+ setenv(INDEX_ENVIRONMENT, index_lock.filename, 1);
+
+ if (interactive_add(argc, argv, prefix) != 0)
+ die("interactive add failed");
+
+ if (old_index_env && *old_index_env)
+ setenv(INDEX_ENVIRONMENT, old_index_env, 1);
+ else
+ unsetenv(INDEX_ENVIRONMENT);
+
+ discard_cache();
+ read_cache_from(index_lock.filename);
+
+ commit_style = COMMIT_NORMAL;
+ return index_lock.filename;
+ }
+
/*
* Non partial, non as-is commit.
*
--
1.7.4.1.g1c7a9.dirty
^ permalink raw reply related
* [PATCH v2] git-commit --patch
From: Conrad Irwin @ 2011-02-03 5:25 UTC (permalink / raw)
To: git; +Cc: conrad.irwin
This patch-set adds support for git-commit --patch, and tidies up some of the
rough edges of git commit --interactive.
The motivation is to support my current workflow, which goes something like:
1. Hack out the basic structure of the feature that I'm working on, until I have
something that looks like it will work.
2. Split this into several commits with a more logical flow (i.e. some that add
support for the techniques I want to use for the actual feature, then the
feature itself).
3. Start fleshing out the implementation, and bug-fixing, with lots of
git-commit --fixup so that the changes end up in the right commit.
4. At the end of the day, a big rebase -i to make the history readable.
This is just about doable with git-add -p, or git-commit --interactive, but
it's very inefficient. I take the presence of git commit --fixup to imply that
other people are doing similar, if less extreme things, so assume that they
would like a git-commit -p too.
Conrad
^ permalink raw reply
* Re: Q on "index-pack: smarter memory usage during delta resolution, 2008-10-17"
From: Nicolas Pitre @ 2011-02-03 5:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vfws6xq5t.fsf@alter.siamese.dyndns.org>
On Wed, 2 Feb 2011, Junio C Hamano wrote:
> In find_unresolved_deltas(), there are two loops that walk the range of deltas[]
> array that potentially share the same base object. One loop for ref-delta
> looks like this:
>
> for (i = ref_first; i <= ref_last; i++) {
> struct object_entry *child = objects + deltas[i].obj_no;
> if (child->real_type == OBJ_REF_DELTA) {
> struct base_data result;
> resolve_delta(child, base, &result);
> if (i == ref_last && ofs_last == -1)
> free_base_data(base);
> find_unresolved_deltas(&result, base);
> }
> }
>
> I was wondering what happens when the entry at ref_last was a false match
> (i.e. the "union delta_base" happened to have the same 20-byte pattern but
> was of a wrong kind).
I've never seen that in practice. You'd need at least one object with a
SHA1 made of 12 trailing zero bytes out of 20 to start with. I'm
challenging you to find such an object. ;-) But let's pretend this may
happen in theory, and that's why the test is there.
> The other loop for ofs-delta has the same "if (i == ofs_last)" condition.
No, it is not exactly the same. The first loop walk the deltas list in
the range of deltas requiring the current object for base by SHA1
reference. Once it is done resolving all those deltas it may free this
base object's memory, but _only_ if it is _not_ also required by the
second loop. That is expressed by ofs_last == -1 meaning that the ofs
range is empty.
The second loop does the same, but in the range of deltas requiring this
base by offset reference. Once it is over with it then it may free the
base right away.
Of course, in practice only one of those 2 loops will actually be
entered, as only one between the SHA1 ref range or the offset ref range
will possibly be non empty.
> Admittedly this is rather hard to trigger (you have to find an object
> as a ofs-delta base object, and then come up with another object whose
> object name is the same as the offset of the first base object followed
> by bunch of '\0' and use it as a ref-delta base), and even if it did, it
> will only retain the memory for slightly longer time in the function.
Right. If you ever manage to create such a condition you're probably up
for cracking SHA1 entirely. But for all purposes this is probably never
going to happen.
> Is a patch along the following line worth doing, I wonder.
>
> -- >8 --
> Subject: index-pack: group the delta-base array entries also by type
>
> Entries in the delta_base array are only grouped by the bytepattern in
> the delta_base union, some of which have 20-byte object name of the base
> object (i.e. base for REF_DELTA objects), while others have sizeof(off_t)
> bytes followed by enough NULs to fill 20-byte. The loops to iterate
> through a range inside this array still needs to inspect the type of the
> delta, and skip over false hits.
>
> Group the entries also by type to eliminate the potential of false hits.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the goal here is to eliminate the cost of the inner test on the
object type in the loop then I don't think you actually gain anything.
The same test is moved elsewhere instead (the assertion notwitstanding),
but in a more costly form as the sort will test that condition more
often than a linear walk, plus the extra argument passing in a couple
places.
If instead the goal was to ensure that no delta gets wrongly unresolved
for whatever reason then this is already covered once at the end with:
if (nr_deltas != nr_resolved_deltas)
die("pack has %d unresolved deltas",
nr_deltas - nr_resolved_deltas);
So no, I don't think this patch brings any advantages.
> ---
> builtin/index-pack.c | 61 ++++++++++++++++++++++++++++++++-----------------
> 1 files changed, 40 insertions(+), 21 deletions(-)
>
> diff --git a/builtin/index-pack.c b/builtin/index-pack.c
> index 8dc5c0b..1b5d83a 100644
> --- a/builtin/index-pack.c
> +++ b/builtin/index-pack.c
> @@ -391,7 +391,18 @@ static void *get_data_from_pack(struct object_entry *obj)
> return data;
> }
>
> -static int find_delta(const union delta_base *base)
> +static int compare_delta_bases(const union delta_base *base1,
> + const union delta_base *base2,
> + enum object_type type1,
> + enum object_type type2)
> +{
> + int cmp = type1 - type2;
> + if (cmp)
> + return cmp;
> + return memcmp(base1, base2, UNION_BASE_SZ);
> +}
> +
> +static int find_delta(const union delta_base *base, enum object_type type)
> {
> int first = 0, last = nr_deltas;
>
> @@ -400,7 +411,8 @@ static int find_delta(const union delta_base *base)
> struct delta_entry *delta = &deltas[next];
> int cmp;
>
> - cmp = memcmp(base, &delta->base, UNION_BASE_SZ);
> + cmp = compare_delta_bases(base, &delta->base,
> + type, objects[delta->obj_no].type);
> if (!cmp)
> return next;
> if (cmp < 0) {
> @@ -413,9 +425,10 @@ static int find_delta(const union delta_base *base)
> }
>
> static void find_delta_children(const union delta_base *base,
> - int *first_index, int *last_index)
> + int *first_index, int *last_index,
> + enum object_type type)
> {
> - int first = find_delta(base);
> + int first = find_delta(base, type);
> int last = first;
> int end = nr_deltas - 1;
>
> @@ -543,11 +556,13 @@ static void find_unresolved_deltas(struct base_data *base,
> union delta_base base_spec;
>
> hashcpy(base_spec.sha1, base->obj->idx.sha1);
> - find_delta_children(&base_spec, &ref_first, &ref_last);
> + find_delta_children(&base_spec,
> + &ref_first, &ref_last, OBJ_REF_DELTA);
>
> memset(&base_spec, 0, sizeof(base_spec));
> base_spec.offset = base->obj->idx.offset;
> - find_delta_children(&base_spec, &ofs_first, &ofs_last);
> + find_delta_children(&base_spec,
> + &ofs_first, &ofs_last, OBJ_OFS_DELTA);
> }
>
> if (ref_last == -1 && ofs_last == -1) {
> @@ -559,24 +574,24 @@ static void find_unresolved_deltas(struct base_data *base,
>
> for (i = ref_first; i <= ref_last; i++) {
> struct object_entry *child = objects + deltas[i].obj_no;
> - if (child->real_type == OBJ_REF_DELTA) {
> - struct base_data result;
> - resolve_delta(child, base, &result);
> - if (i == ref_last && ofs_last == -1)
> - free_base_data(base);
> - find_unresolved_deltas(&result, base);
> - }
> + struct base_data result;
> +
> + assert(child->real_type == OBJ_REF_DELTA);
> + resolve_delta(child, base, &result);
> + if (i == ref_last && ofs_last == -1)
> + free_base_data(base);
> + find_unresolved_deltas(&result, base);
> }
>
> for (i = ofs_first; i <= ofs_last; i++) {
> struct object_entry *child = objects + deltas[i].obj_no;
> - if (child->real_type == OBJ_OFS_DELTA) {
> - struct base_data result;
> - resolve_delta(child, base, &result);
> - if (i == ofs_last)
> - free_base_data(base);
> - find_unresolved_deltas(&result, base);
> - }
> + struct base_data result;
> +
> + assert(child->real_type == OBJ_OFS_DELTA);
> + resolve_delta(child, base, &result);
> + if (i == ofs_last)
> + free_base_data(base);
> + find_unresolved_deltas(&result, base);
> }
>
> unlink_base_data(base);
> @@ -586,7 +601,11 @@ static int compare_delta_entry(const void *a, const void *b)
> {
> const struct delta_entry *delta_a = a;
> const struct delta_entry *delta_b = b;
> - return memcmp(&delta_a->base, &delta_b->base, UNION_BASE_SZ);
> +
> + /* group by type (ref vs ofs) and then by value (sha-1 or offset) */
> + return compare_delta_bases(&delta_a->base, &delta_b->base,
> + objects[delta_a->obj_no].type,
> + objects[delta_b->obj_no].type);
> }
>
> /* Parse all objects and return the pack content SHA1 hash */
>
^ permalink raw reply
* Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository
From: Julian Ibarz @ 2011-02-03 4:31 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Junio C Hamano, Jens Lehmann, git
In-Reply-To: <AANLkTimBCeSnR270eWMcrgCVj6rmiRkJizOxQPAPOAnn@mail.gmail.com>
Hi,
After a couple of hours, I have finally succeeded to go through the
entire history of a repository and I can detect the submodules in a
tree of a commit. For those interested here is the source code:
http://gitorious.org/julian_ibarz_git/julian_ibarz_git/blobs/submodule_checkout/builtin/submodulecheckout.c
Next time I will build the list of commits of a submodule in the
entire history. Then I will need to find the distance of each commit
in the list compared to the current commit of a submodule and keep
the closest one (which has to be a parent so an algebric distance
would be good to have).
So now my two questions that could save me some time are:
- is there a function that gives the distance between two commits? I'm
sure there is something like this coded somewhere but I didn't find it
yet
- is the struct decorate a hash map and if yes could someone explain
me how to use it or point me to a location where it is used?
Except from that I think I have all the information I need.
Best regards,
Julian Ibarz
On Sun, Jan 30, 2011 at 4:44 AM, Julian Ibarz <julian.ibarz@gmail.com> wrote:
> Today I have started to implement a proof of concept in C (I know a
> script would be better but I am really not good in sh so...). I
> struggle with the manipulation of the git API. I have pushed my work
> here:
>
> http://gitorious.org/julian_ibarz_git/julian_ibarz_git
>
> in branch submodule_checkout
>
> My work is in:
>
> builtin/submodulecheckout.c
>
> And my questions are prepended by the keyword QUESTION (two questions
> for now only).
>
> Any help is welcome.
>
> Thanks,
>
> Julian Ibarz
>
> On Sat, Jan 29, 2011 at 6:08 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
>> Hi,
>>
>> On Wed, Jan 26, 2011 at 02:05:43PM -0800, Junio C Hamano wrote:
>>> If that version of submodule B is explicitly bound to a commit in the
>>> superproject A, you know which version of A and C were recorded, and the
>>> problem is solved.
>>>
>> [...]
>>>
>>> If you are confident that you didn't introduce different kind of
>>> dependency to other submodules while developing your "old_feature" branch
>>> in submodule B, one strategy may be to find an ancestor, preferrably the
>>> fork point, of your "old_feature" branch that is bound to the superproject
>>> A. Then at that point at least you know whoever made that commit in A
>>> tested the combination of what was recorded in that commit, together with
>>> the version of B and C, and you can go forward from there, replaying the
>>> changes you made to the "old_feature" branch in submodule B.
>>
>> Lets extend your explanation a little further and maybe demonstrate the problem
>> Julian is having a little more. I think what Julian searches for is a tool in
>> git that does the lookup for you which is AFAIK not that easy currently. It
>> seems to be a quite useful feature. Here what I understand Julian wants:
>>
>> 1. Find the most recent superproject commit X'' in A that records a submodule
>> commit X' in B which contains the commit X in B you are searching for.
>>
>> For this we would need use something similar to git describe --contains
>> but instead of using the list of existing tags in B it should use the list
>> of commits in B which are recorded in A.
>>
>> Here a drawing to explain (linear history for simplicity):
>>
>> superproject A:
>>
>> O---O---X''---O
>> \
>> submodule B: \
>> \
>> O---X---O---X'---O---O
>>
>> 2. Look up the commit of C which is recorded in X'' of A and check it
>> out.
>>
>> Step 2 is easy but for Step 1 the lookup of X' is missing for the commandline.
>> Is there already anything that implements git describe --contains for a defined
>> list of commits instead of refs?
>>
>> Cheers Heiko
>>
>
^ permalink raw reply
* Also seeing the "problem with cherry-picking a commit which comes before introducing a new submodule"
From: Joshua Jensen @ 2011-02-03 4:08 UTC (permalink / raw)
To: git@vger.kernel.org
Described in this thread, http://lists.zerezo.com/git/msg737184.html,
and this thread, http://lists.zerezo.com/git/msg705275.html, is a
problem similar to what I've been seeing today. It seems I can resolve
the "conflicting" submodule(s) and continue on, but it is a bit painful
as there are a small number of them. I also tried an interactive rebase
and assigning a 'pick' entry with the commit I'd like to cherry-pick,
and the same problem manifests.
In any case, it seems Jonathan Nieder has potentially identified the
problem at http://lists.zerezo.com/git/msg737401.html.
Has a patch come through that addresses this? If one did, did it make
it into 1.7.4?
Thanks!
Josh
^ permalink raw reply
* Re: moving to a git-backed wiki
From: J.H. @ 2011-02-03 2:24 UTC (permalink / raw)
To: Vincent Hanquez; +Cc: Jay Soffian, Jeff King, Scott Chacon, Junio C Hamano, git
In-Reply-To: <4D4929F4.3020805@snarc.org>
On 02/02/2011 01:55 AM, Vincent Hanquez wrote:
> On 01/02/11 22:48, J.H. wrote:
>> The wiki will almost universally have a "central site" no matter what
>> the backend. Personally I see little advantage to having a git backed
>> wiki myself.
> with git based wiki, you can clone the whole wiki on your local machine,
> and read/edit/commit on it locally using standard editor tool (i.e.
> $EDITOR). and the history/revision/diff is completely built-in.
That would be fine for things like source code or documentation, but you
end up with a single person who would need to merge / push things to a
central location, a-la git.wiki.kernel.org. You are now taking
something, that is already editable by anyone, and making it only
editable by a single person.
You also have a scalability problem. Git is *VERY* memory and i/o
intensive. While you basically have a cache of data that is static (the
basic pages you are viewing) things like the history, edits, etc can be
quite expensive to generate.
Think about a site, we'll use git.wiki.kernel.org, where it's not
running on a single machine, but a cluster of machines (how many web
infrastructures, including git.wiki.kernel.org run) and now you have a
problem of an edit happens and commits on node3, a different conflicting
edit happens on node9 and when those try to merge - you get conflicts.
Let me be clear here, I think the idea is interesting, but I think in
trying to replace a full wiki it's a horrible idea, particularly since
you are pushing a lot of manual work - somewhere, and trying to use git
as a nosql database without some sort of locking system.
Just my $0.02 though.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: Wesley J. Landaker @ 2011-02-03 2:21 UTC (permalink / raw)
To: David Aguilar; +Cc: Jay Soffian, Jakub Narebski, git@vger.kernel.org
In-Reply-To: <4928FF12-E593-4CDB-AC68-B4078CC5920E@gmail.com>
On Wednesday, February 02, 2011 16:33:09 David Aguilar wrote:
> I don't like where this is going. Users are not always right.
> Touch .gitignore and be done with it. This is a big change with
> negligible benefits. I don't understand why this is needed.
I am not usually bothered too much that git doesn't story directories, and
when I need to do it, I can do the .gitignore trick just like anyone else.
However here are a few reasons that I miss this feature sometimes:
1) Why WOULDN'T you want to track empty directories? We track empty files:
isn't that just as pointless? What if git couldn't track empty files and
automatically removed files when they became empty? Well, I could live with
that just as well, with some silly workarounds every once in a while (e.g.
echo empty > some_file).
2) One of git's best strengths is that it's so easy to interact with other
SCM software, primarily because git's features are a SUPERSET of other SCMs.
However, almost every other SCM can track empty directories, except git,
which makes it much harder to use as universal tool, where I can trust that
everything will round-trip as well as possible. Also, other SCMs don't want
".gitignore" files cluttering their repository any more than we want their
SCM tool's random control files in our repositories.
3) Forget for a moment the cuddly git idosynchracies that through use we
have come to know and "love". From a design perspective, does putting and
tracking, a file called IGNORE in a directory you want to KEEP make sense?
It's one thing to use "touch .gitignore" in an empty directory to keep it
*as a workaround*, based on implementation details (i.e. any file in the
directory will do, but we probably will have a .gitignore anyway eventually,
so might as well as use that) but it's a strange *design*. =)
4) On many projects I work on with a huge number of people, the workflow
is to create a very, very intricate directory hierarchy skeleton, so that
it's clear to everyone where everything goes and how it is organized, even
before any work is started. In this case with git, it's annoying to do this
because there are worthless .gitignore files cluttering up everything, which
makes it harder to find where there are *actual* ignore rules being applied.
5) Git not tracking empty directories and the (perceived?) arrogant
reaction from git experts ("no big deal, just touch .gitignore" -- I've said
this to people too, since it's the canonical answer, but I always feel a
little chagrined after hyping up everything git can do) sometimes is just
one more thing that makes git harder to sell to others, especially when they
are already in love with Subversion or whatever.
Most of all, think of it this way: maybe git doesn't need to track empty
directories in order to be awesome, but is there some reason that tracking
empty directories would make it less awesome?
Anyway, just some thoughts.
^ permalink raw reply
* [PATCH] git-p4: Improve branch support.
From: Vitor Antunes @ 2011-02-03 1:01 UTC (permalink / raw)
To: git; +Cc: Thomas Berg, Vitor Antunes
In-Reply-To: <1296694913-7844-1-git-send-email-vitor.hda@gmail.com>
Add new config option branchUser to allow filtering P4 branch list by user.
Allow defining the branch list through branchList config option.
Correct base branch directory detection to use '/' as the split character.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
contrib/fast-import/git-p4 | 27 +++++++++++++++++++++++----
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 9b67ae2..af1ba43 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -338,6 +338,11 @@ def gitConfig(key):
_gitConfig[key] = read_pipe("git config %s" % key, ignore_error=True).strip()
return _gitConfig[key]
+def gitConfigList(key):
+ if not _gitConfig.has_key(key):
+ _gitConfig[key] = read_pipe("git config --get-all %s" % key, ignore_error=True).strip().split(os.linesep)
+ return _gitConfig[key]
+
def p4BranchesInGit(branchesAreInRemotes = True):
branches = {}
@@ -1253,7 +1258,13 @@ class P4Sync(Command):
def getBranchMapping(self):
lostAndFoundBranches = set()
- for info in p4CmdList("branches"):
+ user = gitConfig("git-p4.branchUser")
+ if len(user) > 0:
+ command = "branches -u %s" % user
+ else:
+ command = "branches"
+
+ for info in p4CmdList(command):
details = p4Cmd("branch -o %s" % info["branch"])
viewIdx = 0
while details.has_key("View%s" % viewIdx):
@@ -1286,6 +1297,12 @@ class P4Sync(Command):
for branch in lostAndFoundBranches:
self.knownBranches[branch] = branch
+ configBranches = gitConfigList("git-p4.branchList")
+ for branch in configBranches:
+ if branch:
+ (source, destination) = branch.split(":")
+ self.knownBranches[destination] = source
+
def getBranchMappingFromGitBranches(self):
branches = p4BranchesInGit(self.importIntoRemotes)
for branch in branches.keys():
@@ -1581,12 +1598,14 @@ class P4Sync(Command):
else:
paths = []
for (prev, cur) in zip(self.previousDepotPaths, depotPaths):
- for i in range(0, min(len(cur), len(prev))):
- if cur[i] <> prev[i]:
+ prev_list = prev.split("/")
+ cur_list = cur.split("/")
+ for i in range(0, min(len(cur_list), len(prev_list))):
+ if cur_list[i] <> prev_list[i]:
i = i - 1
break
- paths.append (cur[:i + 1])
+ paths.append ("/".join(cur_list[:i + 1]))
self.previousDepotPaths = paths
--
1.7.2.3
^ permalink raw reply related
* [PATCH] git-p4 : Small improvement patches
From: Vitor Antunes @ 2011-02-03 1:01 UTC (permalink / raw)
To: git; +Cc: Thomas Berg, Vitor Antunes
This patch finishes all the changes that I've done to git-p4 script and that
I've been using in my daily work. Although most of the changes are trivial, it
would be nice if someone could test these updates and provide feedback.
The script, as it is, still has one limitation: when it detects a new branch it
will base it on the last commit of the origin branch. This may not be true,
because the branch may have been created from an old change list. My idea would
be to find a commit to which the new branch would have a null diff... but I
don't know what would be the best way to do something like this through git
commands. Suggestions are welcome on this point :)
Thank in advance,
Vitor
Vitor Antunes (1):
git-p4: Improve branch support.
contrib/fast-import/git-p4 | 27 +++++++++++++++++++++++----
1 files changed, 23 insertions(+), 4 deletions(-)
--
1.7.2.3
^ permalink raw reply
* Re: [PATCH] post-receive-email: suppress error if description file missing
From: Sitaram Chamarty @ 2011-02-03 1:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ralf Hemmecke, git
In-Reply-To: <7vbp2uxozo.fsf@alter.siamese.dyndns.org>
Signed-off-by: Sitaram Chamarty <sitaramc@gmail.com>
---
On Wed, Feb 02, 2011 at 10:36:43AM -0800, Junio C Hamano wrote:
> I suspect that you would want to have the redirection outside the dq pair,
> but other than that, well spotted.
doh! Thanks for catching the stupid error -- I shouldn't attempt even a
simple patch when half-asleep I guess :)
> You forgot to sign-off, though ;-)
done!
contrib/hooks/post-receive-email | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index f99ea95..21989fc 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -709,7 +709,7 @@ if [ -z "$GIT_DIR" ]; then
exit 1
fi
-projectdesc=$(sed -ne '1p' "$GIT_DIR/description")
+projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null)
# Check if the description is unchanged from it's default, and shorten it to
# a more manageable length if it is
if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
--
1.7.3.4
^ permalink raw reply related
* Re: [1.8.0] 't/' is standard name for directory with tests
From: Sam Vilain @ 2011-02-02 23:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Alex Budovski, Jakub Narebski, git
In-Reply-To: <7v4o8o4kt7.fsf@alter.siamese.dyndns.org>
On 01/02/11 14:15, Junio C Hamano wrote:
> I am fine with "tests/", by the way.
FWIW, CCAN and Rubygems both use plain "test".
"t/" is a long standing convention for many projects, dating back to at
least 1987 with Perl 1.0. As far as I know it was unusual at the time
for being a very test-driven development and inventing the TAP (Test
Anything Protocol). It is something of a mark of respect to the
heritage of TDD to have it there, but that doesn't mean that "test"
might be better for the project now.
I'd also think about removing the "t" from the front of all the test
script names, those are a PITA :-). And possibly allowing the scripts
to be broken into subdirectories.
Sam
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: Jakub Narebski @ 2011-02-02 23:52 UTC (permalink / raw)
To: David Aguilar; +Cc: Jay Soffian, git@vger.kernel.org
In-Reply-To: <4928FF12-E593-4CDB-AC68-B4078CC5920E@gmail.com>
Dnia czwartek 3. lutego 2011 00:33, David Aguilar napisał:
> On Feb 2, 2011, at 3:23 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
>> On Wed, Feb 2, 2011 at 6:56 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>> The problem with backward compatibility is twofold. First and more
>>> important is while git supports empty tree object (it has it
>>> hardcoded
>>> for some time, as it is necessary e.g. for initial diff, or merging
>>> unrelated branches without common ancestor), and there is no problem
>>> with entry for empty tree in a tree object
>>>
>>> 040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb empty
>>>
>>> there is (supposedly) problem when checking out such tree (see email
>>> referenced above) with an old git.
>>>
>>> Second is that tracking empty directories would require extension
>>> to the
>>> git index (storing trees in index, like we store submodules)... but
>>> that
>>> is purely local matter.
>>
>> Instead of using an empty tree, construct a tree containing a single
>> sentinel file whose contents are a suitable warning not to delete/edit
>> said file using pre-1.8.0 git. Meanwhile git-1.8.0 never writes the
>> file to the filesystem. Too ugly?
Too ugly.
> I don't like where this is going. Users are not always right.
> Touch .gitignore and be done with it. This is a big change with
> negligible benefits. I don't understand why this is needed.
Two issues: first is interaction with other SCM which keep empty files
(or keep empty files when requested). Second is skeleton of directory
structure automatically generated by some git-unaware tool.
I've never felt the need but more than 50% of Git User's Survey 2010
responders did.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: David Aguilar @ 2011-02-02 23:33 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jakub Narebski, git@vger.kernel.org
In-Reply-To: <AANLkTi=bK7mFS3eWVMWXqZSnv73tafL9AGazk4jPLddp@mail.gmail.com>
On Feb 2, 2011, at 3:23 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Wed, Feb 2, 2011 at 6:56 AM, Jakub Narebski <jnareb@gmail.com>
> wrote:
>> The problem with backward compatibility is twofold. First and more
>> important is while git supports empty tree object (it has it
>> hardcoded
>> for some time, as it is necessary e.g. for initial diff, or merging
>> unrelated branches without common ancestor), and there is no problem
>> with entry for empty tree in a tree object
>>
>> 040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb empty
>>
>> there is (supposedly) problem when checking out such tree (see email
>> referenced above) with an old git.
>>
>> Second is that tracking empty directories would require extension
>> to the
>> git index (storing trees in index, like we store submodules)... but
>> that
>> is purely local matter.
>
> Instead of using an empty tree, construct a tree containing a single
> sentinel file whose contents are a suitable warning not to delete/edit
> said file using pre-1.8.0 git. Meanwhile git-1.8.0 never writes the
> file to the filesystem. Too ugly?
>
> j.
I don't like where this is going. Users are not always right.
Touch .gitignore and be done with it. This is a big change with
negligible benefits. I don't understand why this is needed.
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: Jay Soffian @ 2011-02-02 23:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3zkqe8xc8.fsf_-_@localhost.localdomain>
On Wed, Feb 2, 2011 at 6:56 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> The problem with backward compatibility is twofold. First and more
> important is while git supports empty tree object (it has it hardcoded
> for some time, as it is necessary e.g. for initial diff, or merging
> unrelated branches without common ancestor), and there is no problem
> with entry for empty tree in a tree object
>
> 040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb empty
>
> there is (supposedly) problem when checking out such tree (see email
> referenced above) with an old git.
>
> Second is that tracking empty directories would require extension to the
> git index (storing trees in index, like we store submodules)... but that
> is purely local matter.
Instead of using an empty tree, construct a tree containing a single
sentinel file whose contents are a suitable warning not to delete/edit
said file using pre-1.8.0 git. Meanwhile git-1.8.0 never writes the
file to the filesystem. Too ugly?
j.
^ permalink raw reply
* Re: untracked symlinks are less precious than untracked files?
From: Johannes Sixt @ 2011-02-02 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7hdixkys.fsf@alter.siamese.dyndns.org>
On Mittwoch, 2. Februar 2011, Junio C Hamano wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
> > Is it by design that symlinks are less precious than files, or is it an
> > oversight?
>
> I don't recall making conscious distinction between symmlinks and regular
> files, so it is likely to be just a bug. Perhaps using stat() where
> lstat() should be used and mistaking an error return as missing, or
> something silly like that?
Hm, I don't think so. It seems to interact with the lstat_cache. When lstat
reports a symlink, this result is cached; but if it is a regular file, it is
not cached. I don't know, what the consequences are, though... I have to stop
my investigations for tonight.
-- Hannes
^ permalink raw reply
* Re: Q: does index-pack work in place on windows?
From: Erik Faye-Lund @ 2011-02-02 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, Shawn O. Pearce
In-Reply-To: <7v39o6xk5q.fsf@alter.siamese.dyndns.org>
On Wed, Feb 2, 2011 at 9:21 PM, Junio C Hamano <gitster@pobox.com> wrote:
> ... or any other (operating / file) system where you cannot unlink a file
> that is open?
>
> When you run
>
> $ git clone git://some.where/repo/sitory.git local
> $ cd local
> $ git index-pack .git/objects/pack/pack-*.pack
>
> there is a call to write_idx_file() in builtin/index-pack.c, that feeds
> the correct (and existing) name of the corresponding pack idx file.
>
> The callee in pack-write.c, after sorting the list of objects contained in
> the pack, does this:
>
> if (!index_name) {
> static char tmpfile[PATH_MAX];
> fd = odb_mkstemp(tmpfile, sizeof(tmpfile), "pack/tmp_idx_XXXXXX");
> index_name = xstrdup(tmpfile);
> } else {
> unlink(index_name);
> fd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);
> }
>
> and then writes out the pack index to the file descriptor. But index-pack
> uses the usual has_sha1_file() and read_sha1_file() interface to validate
> the "existing" objects, and is likely to have mmapped the .idx file when
> it called use_pack_window(). Which makes me suspect that this unlink (or
> the open that immediately follows) may fail on systems that do not allow
> unlink on inode that has still users.
...and you're right:
$ git index-pack
.git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.pack
Unlink of file '.git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.idx'
failed. Should I try again? (y/n)? n
fatal: unable to create
'.git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.idx':
File exists
^ permalink raw reply
* Re: [PATCH 2/2] fast-import: introduce "feature notes" command
From: Jonathan Nieder @ 2011-02-02 20:22 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Thomas Rast, git, Johan Herland, Ramkumar Ramachandra,
Shawn O. Pearce, Sam Vilain
In-Reply-To: <AANLkTi=bEi6J3wcex8JCowU6PRt3BKix5v67v8Ds-MN2@mail.gmail.com>
Sverre Rabbelier wrote:
> Perhaps we can submit a patch to maint to have it (the
> oldest git that supports the 'feature' command) recognize 'feature
> notes' though?
Smart idea. My concerns would evaporate.
[v1.7.0-rc0~95^2~4 (2009-12-04) is the relevant git.]
^ permalink raw reply
* Q: does index-pack work in place on windows?
From: Junio C Hamano @ 2011-02-02 20:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Shawn O. Pearce
... or any other (operating / file) system where you cannot unlink a file
that is open?
When you run
$ git clone git://some.where/repo/sitory.git local
$ cd local
$ git index-pack .git/objects/pack/pack-*.pack
there is a call to write_idx_file() in builtin/index-pack.c, that feeds
the correct (and existing) name of the corresponding pack idx file.
The callee in pack-write.c, after sorting the list of objects contained in
the pack, does this:
if (!index_name) {
static char tmpfile[PATH_MAX];
fd = odb_mkstemp(tmpfile, sizeof(tmpfile), "pack/tmp_idx_XXXXXX");
index_name = xstrdup(tmpfile);
} else {
unlink(index_name);
fd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);
}
and then writes out the pack index to the file descriptor. But index-pack
uses the usual has_sha1_file() and read_sha1_file() interface to validate
the "existing" objects, and is likely to have mmapped the .idx file when
it called use_pack_window(). Which makes me suspect that this unlink (or
the open that immediately follows) may fail on systems that do not allow
unlink on inode that has still users.
^ permalink raw reply
* Re: git svn clone stops after r2 for svn://mlton.org/mlton/trunk
From: Pascal Obry @ 2011-02-02 20:19 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87aaijso0j.fsf@mid.deneb.enyo.de>
Florian,
> There's something strange going on there:
>
> $ git svn clone svn://mlton.org/mlton/trunk mlton
> Initialized empty Git repository in /home/fw/src/mlton/.git/
> r2 = 61f0dd5ba401ece2ff4668bc7454b7742c60fa99 (refs/remotes/git-svn)
> Checked out HEAD:
> svn://mlton.org/mlton/trunk r2
This is probably because the first revision in trunk is r2 and there is
no r0 nor a r1. This repository has been converted from CVS (see r2). In
such a case you can convert properly using:
$ git svn clone -s -r3:7500 svn://mlton.org/mlton mlton
r3 is the first actual revision, all see can be seen using:
$ svn://mlton.org/mlton/trunk mlton
Note that I have used -s as this repository is using a standard svn layout.
Hope this helps.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Pascal Obry @ 2011-02-02 20:01 UTC (permalink / raw)
To: kusmabite; +Cc: George Spelvin, git
In-Reply-To: <AANLkTikBH8Qs3izT86WW7qyJ2etwFFj9GPVJ2QeRCmag@mail.gmail.com>
Le 02/02/2011 09:31, Erik Faye-Lund a écrit :
> On Wed, Feb 2, 2011 at 3:29 AM, George Spelvin <linux@horizon.com> wrote:
>> If there's a compelling reason to change, could someone please describe it?
>
> I think the most compelling argument I can think of is that it makes
> top-level entries like Documentation, RelNotes, COPYING, README and
> INSTALL easier to spot when doing "ls". For some users (first-time
> hackers etc) that's a pretty big plus, I'd think.
I was about to say that too. That's an argument strong enough I would
say. Today it is hard to see the structure.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: untracked symlinks are less precious than untracked files?
From: Junio C Hamano @ 2011-02-02 20:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <201102022025.06140.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Is it by design that symlinks are less precious than files, or is it an
> oversight?
I don't recall making conscious distinction between symmlinks and regular
files, so it is likely to be just a bug. Perhaps using stat() where
lstat() should be used and mistaking an error return as missing, or
something silly like that?
^ 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