git subtree split - nested subtree history not preserved on parent split
Hello, I've been playing around with nested subtrees, and I've discovered what I'm pretty sure is a bug: when I import a repo into a nested directory with `git subtree add`, then split the imported directory's parent, the subtree's history is lost. To clarify: # Create a repo with a single file git init nested cd nested echo contents > test git add test git commit -m "Add foo" cd .. # Create an outer repo git init outer cd outer echo contents > bar git add bar git commit -m "Add bar" # Import nested into outer/dir/nested git subtree add --prefix dir/nested ../nested master # Split outer/dir git subtree split --prefix dir --branch history-of-dir Now `git log master` includes "Add foo" in its history but `git log history-of-dir` doesn't, even though 'nested' is a child of 'dir'. I have a (very) rough guess as to what's going on: `git subtree split` sees the side of the merge importing nested's changes as only touching files "outside of" the directory it's splitting out, so it happily omits them from the split history. Has anyone else run into this? -Alex -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] trailer: read and process config information
On Tue, Dec 24, 2013 at 7:37 AM, Christian Couder
wrote:
>
> +static int git_trailer_config(const char *conf_key, const char *value, void
> *cb)
> +{
> + if (starts_with(conf_key, "trailer.")) {
> + const char *orig_conf_key = conf_key;
> + struct trailer_item *item;
> + struct conf_info *conf;
> + char *name;
> + enum trailer_info_type type;
> +
> + conf_key += 8;
> + if (!set_name_and_type(conf_key, ".key", TRAILER_VALUE,
> &name, &type) &&
> + !set_name_and_type(conf_key, ".command", TRAILER_COMMAND,
> &name, &type) &&
> + !set_name_and_type(conf_key, ".where", TRAILER_WHERE,
> &name, &type) &&
> + !set_name_and_type(conf_key, ".ifexist",
> TRAILER_IF_EXIST, &name, &type) &&
> + !set_name_and_type(conf_key, ".ifmissing",
> TRAILER_IF_MISSING, &name, &type))
> + return 0;
> +
> + item = get_conf_item(name);
> + conf = item->conf;
> +
> + if (type == TRAILER_VALUE) {
> + if (conf->key)
> + warning(_("more than one %s"), orig_conf_key);
> + conf->key = xstrdup(value);
> + } else if (type == TRAILER_COMMAND) {
> + if (conf->command)
> + warning(_("more than one %s"), orig_conf_key);
> + conf->command = xstrdup(value);
> + } else if (type == TRAILER_WHERE) {
> + if (set_where(conf, value))
> + warning(_("unknow value '%s' for key '%s'"),
> value, orig_conf_key);
I realize that I forgot to s/unknow/unknown/.
Sorry about that. It will be in the next version.
> + } else if (type == TRAILER_IF_EXIST) {
> + if (set_if_exist(conf, value))
> + warning(_("unknow value '%s' for key '%s'"),
> value, orig_conf_key);
> + } else if (type == TRAILER_IF_MISSING) {
> + if (set_if_missing(conf, value))
> + warning(_("unknow value '%s' for key '%s'"),
> value, orig_conf_key);
> + } else {
> + die("internal bug in trailer.c");
> + }
> + }
> + return 0;
> +}
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Error with git-svn pushing a rename
Benjamin Pabst gmail.com> writes:
> is it possible to debug git-svn or get a more verbose / debug output
> from it? I already tried with the "GIT_TRACE" variable, but it does
> not include any further output on the svn methods.
I've hit this problem too, and tracked it down to what I think is a
bug in svn. It fails in libsvn_ra_serf/commit.c:close_file() on invalid
->copy_path on the file context.
AFAICT this is do to the ra_serf version of add_file() lacking
apr_pstrdup() on the "copy_path" argument passed to it; as a result it
gets overwritten with garbage on further use:
libsvn_ra_serf/commit.c:
...
1852 static svn_error_t *
1853 add_file(const char *path,
1854 void *parent_baton,
1855 const char *copy_path,
1856 svn_revnum_t copy_revision,
1857 apr_pool_t *file_pool,
1858 void **file_baton)
1859 {
...
1875 new_file->copy_path = copy_path;
..
You can apply this workaround to get it to work:
--- a/perl/Git/SVN/Editor.pm
+++ b/perl/Git/SVN/Editor.pm
@@ -304,8 +304,9 @@ sub C {
my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
my $pbat = $self->ensure_path($dir, $deletions);
+ my $upa = $self->url_path($m->{file_a});
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
- $self->url_path($m->{file_a}), $self->{r});
+ $upa, $self->{r});
print "\tC\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
@@ -323,8 +324,9 @@ sub R {
my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
my $pbat = $self->ensure_path($dir, $deletions);
+ my $upa = $self->url_path($m->{file_a});
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
- $self->url_path($m->{file_a}), $self->{r});
+ $upa, $self->{r});
print "\tR\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
$self->apply_autoprops($file, $fbat);
$self->chg_file($fbat, $m);
What it does is store the value to be passed to add_file() in a local
variable, and rely on perl to keep it alive through the end of function
scope, beyond the call to close_file() where it's actually used.
I'm going to submit a patch adding apr_pstrdup() to subversion folks.
Meanwhile if people find the above workarond a sensible thing to do in
git, I can submit a properly formed patch here too.
Roman.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add: don't complain when adding empty project root
On 2013-12-24 00.46, Duy Nguyen wrote: > [snip] > We don't complain about adding an empty directory before or after this patch. Ok, thanks for the explanation. I think that https://www.kernel.org/pub/software/scm/git/docs/git-add.html could deserve an update. My understanding is that is related to $GIT_DIR, but "." is the current directory. I will be happy to write a patch, (or to review one, whatever comes first) /Torsten -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add: don't complain when adding empty project root
On Wed, Dec 25, 2013 at 4:48 AM, Torsten Bögershausen wrote: > On 2013-12-24 00.46, Duy Nguyen wrote: >> > [snip] >> We don't complain about adding an empty directory before or after this patch. > Ok, thanks for the explanation. > > I think that > https://www.kernel.org/pub/software/scm/git/docs/git-add.html > could deserve an update. > > My understanding is that is related to $GIT_DIR, > but "." is the current directory. > > I will be happy to write a patch, > (or to review one, whatever comes first) > /Torsten filepattern is related to current directory too (e.g. "*.sh" from "t" won't cover git-rebase.sh, ":/*.sh" does). Yes a patch to update git-add.txt to use the term "pathspec" instead of "filepattern" would be nice. A pointer to pathspec glossary could help discover case-insensitive matching, negative matching.. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
