Re: [Announce] submitGit for patch submission (was "Diffing submodule does not yield complete logs")
Hi Philip, On 2015-05-22 23:35, Philip Oakley wrote: > Do I read you right.. That it's necessary to create a PR on git/git > before submitGit can be used. Yep. > And that if I already have a PR which goes back to an alternate fork > (e.g. my example), then I must move or duplicate that PR onto git/git > before it can be used. Yep, the rationale being that you most likely have to rebase your PR to git/git's `master` branch, anyway. Ciao, Dscho -- 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: [Announce] submitGit for patch submission (was "Diffing submodule does not yield complete logs")
Hi Roberto, On 2015-05-22 23:28, Roberto Tyley wrote: > I'm currently on a cycling holiday on an island off the west coast of > Scotland, **without a laptop**, so updates to submitGit (based on the > excellent feedback I've been receiving) will probably start mid-next week. Ah, I am jealous. Enjoy your trip! Ciao, Dscho P.S.: The only exposure I had to Scala was for desktop application programming, so I guess I won't try my hand at patching submitGit without your hand-holding. Not urgent, of course. -- 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: [Announce] submitGit for patch submission (was "Diffing submodule does not yield complete logs")
Hi Junio, On 2015-05-22 22:04, Junio C Hamano wrote: > On Fri, May 22, 2015 at 12:59 PM, Johannes Schindelin > wrote: >> >> On 2015-05-22 21:23, Stefan Beller wrote: >>> >>> So first of all: >>> Where do I find the Amazon SES account for submitGit, to register >>> my email with? >>> >>> Also can I change the email in the process or change it before? >> >> FWIW I did not have to register my email. All I needed to do was to give >> submitGit >> permissions to read my personal email address and my public repositories. > > Hmph, I was asked way more than that (especially, read and write access). > Does the site ask different authorizations depending on who you are? Well, I did not try to send to the mailing list yet. Maybe that's the difference? Or maybe it is because I just registered with Heroku before... Ciao, Dscho -- 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 1/3] stat_validity: handle non-regular files
On 05/23/2015 01:51 AM, Jeff King wrote:
> The stat_validity code was originally written to avoid
> re-reading the packed-refs file when it has not changed. It
> makes sure that the file continues to match S_ISREG() when
> we check it.
>
> However, we can use the same concept on a directory to see
> whether it has been modified. Even though we still have to
> touch the filesystem to do the stat, this can provide a
> speedup even over opendir/readdir/closedir, especially on
> high-latency filesystems like NFS.
>
> This patch adds a "mode" field to stat_validity, which lets
> us check that the mode has stayed the same (rather than
> explicitly checking that it is a regular file).
I don't have any insight about whether mtimes are reliable change
indicators for directories.
But if you make this change, you are changing the contract of the
stat_validity functions:
* Have you verified that no callers rely on the old stat_validity's
check that the file is a regular file?
* The docstrings in cache.h need to be updated.
> As a bonus cleanup, we can stop allocating the embedded
> "stat_data" on the heap. Prior to this patch, we needed to
> represent the case where the file did not exist, and we used
> "sv->sd == NULL" for that. Now we can simply check that
> "sv->mode" is 0.
>
> Signed-off-by: Jeff King
> ---
> cache.h | 3 ++-
> read-cache.c | 16 ++--
> 2 files changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/cache.h b/cache.h
> index c97d807..2941e7e 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1660,7 +1660,8 @@ int sane_execvp(const char *file, char *const argv[]);
> * for the index.
> */
> struct stat_validity {
> - struct stat_data *sd;
> + struct stat_data sd;
> + unsigned mode;
> };
Could the mode be stored directly in stat_data?
By comparing modes, you are not only comparing file type (S_ISREG vs
S_ISDIR etc.) but also all of the file permissions. That seems OK with
me but you might want to document that fact. Plus, I don't know whether
POSIX allows additional, implementation-defined information to be stored
in st_mode. If so, you would be comparing that, too.
> [...]
Otherwise, looks OK.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
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: git status doesn't ignore GIT_DIR directory?
On Sat, May 23, 2015 at 12:39 PM, Mike Hommey wrote: > On Sat, May 23, 2015 at 09:22:56AM +0700, Duy Nguyen wrote: >> --- a/Documentation/git.txt >> +++ b/Documentation/git.txt >> @@ -691,6 +691,9 @@ Git so take care if using Cogito etc. >> specifies a path to use instead of the default `.git` >> for the base of the repository. >> The '--git-dir' command-line option also sets this value. >> ++ >> +Note that if GIT_DIR is set explicitly to a directory inside working >> +tree, the directory name must be ".git". > > Isn't the requirement that it _ends_ with ".git" (that is, > GIT_DIR=/path/to/foo.git would work) If $GIT_DIR points to somewhere inside worktree, ".git" exactly (it's strcmp(), not ends_with()) is the only exception. If it points outside worktree, the directory name could be anything. -- 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
Re: git status doesn't ignore GIT_DIR directory?
On Sat, May 23, 2015 at 11:41 AM, Thorsten von Eicken wrote: > On 5/22/2015 7:22 PM, Duy Nguyen wrote: >> On Fri, May 22, 2015 at 07:03:48PM -0700, Junio C Hamano wrote: >>> As far as I know, GIT_DIR was prepared as a mechanism to point at >>> another .git directory that does not live inside the working tree, not >>> as a mechanism to rename it to arbitrary name. E.g. >>> >>> $ git init >>> $ mv .git .svn >>> $ GIT_DIR=$(pwd)/.svn ; export GIT_DIR >>> >>> is not expected to work. >> >> ++ >> +Note that if GIT_DIR is set explicitly to a directory inside working >> +tree, the directory name must be ".git". > This is not at all what I was hoping to hear, but thanks for the response. To elaborate a bit more, I think ".git" was cooked in the code near the beginning and for too long. By the time people wanted flexibility, ".git" string was already all over the place and changing it may require some (and maybe big) code reorganization, and all that is for a rare use case.. I think I saw at least two attempts to fix this but they went nowhere. On the bright side, you can work around this easily by adding ".svn" to your ignore list. -- 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
[PATCH v5 1/1] send-email: Add sendmail email aliases format
Note that this only adds support for a limited subset of the sendmail
format. The format is is as follows.
: [, ...]
Aliases are specified one per line, and must start on the first column of the
line. Blank lines are ignored. If the first non whitespace character
on a line is a '#' symbol, then the whole line is considered a comment,
and is ignored.
Example:
alice: Alice W Land
bob: Robert Bobbyton
# this is a comment
# this is also a comment
chloe: ch...@example.com
abgroup: alice, bob
bcgrp: bob, chloe, Other
Unlike the standard sendmail format, this does not support quoted
aliases or quoted addresses. Line continuations are not supported.
Warnings are printed for explicitly unsupported constructs, and any
other lines that are not recognized.
Signed-off-by: Allen Hubbe
---
Notes:
This v5 renames the parser 'sendmail' again, from 'simple'.
Therefore, the subject line is changed again, too.
Previous subject line: send-email: Add simple email aliases format
The format is restricted to a subset of sendmail. When the subset
diverges from sendmail, the parser warns about the line that diverges,
and ignores the line. The supported format is described in the
documentation, as well as the behavior when an unsupported format
construct is detected.
A badly constructed sentence was corrected in the documentation.
The test case was changed to use a here document, and the unsupported
comment after an alias was removed from the test case alias file input.
Documentation/git-send-email.txt | 37 -
git-send-email.perl | 29 +
t/t9001-send-email.sh| 27 +++
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 804554609def..97387fd27a8d 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -383,7 +383,42 @@ sendemail.aliasesFile::
sendemail.aliasFileType::
Format of the file(s) specified in sendemail.aliasesFile. Must be
- one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.
+ one of 'sendmail', 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.
++
+If the format is 'sendmail', then the alias file format is described below.
+Descriptions of the other file formats can be found by searching the
+documentation of the email program of the same name.
++
+The 'sendmail' format is is as follows. Note that 'git-send-email' currently
+only supports a limited subset of the sendmail format.
++
+ : [, ...]
++
+Aliases are specified one per line, and must start on the first column of the
+line. Blank lines are ignored. If the first non whitespace character on a
+line is a `#` symbol, then the whole line is considered a comment, and is
+ignored.
++
+Example of the 'sendmail' format:
++
+ alice: Alice W Land
+ bob: Robert Bobbyton
+ # this is a comment
+ # this is also a comment
+ chloe: ch...@example.com
+ abgroup: alice, bob
+ bcgrp: bob, chloe, Other
++
+Unlike the standard sendmail format, 'git-send-email' currently diverges in the
+following ways.
++
+* Quoted aliases and quoted addresses are not supported: lines that
+ contain a `"` symbol are ignored.
+* Line continuations are not supported: any lines that start with
+ whitespace, or end with a `\` symbol are ignored.
+* Warnings are printed on the standard error output for any explicitly
+ unsupported constructs, and any other lines that are not recognized
+ by the parser.
sendemail.multiEdit::
If true (default), a single editor instance will be spawned to edit
diff --git a/git-send-email.perl b/git-send-email.perl
index e1e9b1460ced..ffea50094a48 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -487,6 +487,8 @@ sub split_addrs {
}
my %aliases;
+
+
my %parse_alias = (
# multiline formats can be supported in the future
mutt => sub { my $fh = shift; while (<$fh>) {
@@ -516,6 +518,33 @@ my %parse_alias = (
}
} },
+ sendmail => sub { my $fh = shift; while (<$fh>) {
+ # ignore comment lines
+ if (/^\s*(?:#.*)?$/) { }
+
+ # warn on lines that contain quotes
+ elsif (/"/) {
+ print STDERR "sendmail alias with quotes is not
supported: $_\n";
+ next;
+ }
+
+ # warn on lines that continue
+ elsif (/^\s|\\$/) {
+ print STDERR "sendmail continuation line is not
supported: $_\n";
+ next;
+ }
+
+ # recognize lines that look like an alias
+ elsif (/^(\S+)\s*:\s*(.+?)$/) {
+
Re: [Announce] submitGit for patch submission (was "Diffing submodule does not yield complete logs")
Stefan Beller writes: > Ok, I am trying it out now, all I have left is > > Register your email address > (stefanbel...@googlemail.com) > with submitGit's Amazon SES > account in order for it to send > emails from you. > > So first of all: > Where do I find the Amazon SES account for submitGit, to register > my email with? > > Also can I change the email in the process or change it before? I was confused at the same point, but at the top of the screen showing this message, there was a link to do this registration. I was just not looking at the right place. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 2/4] ref-filter: add ref-filter API
karthik nayak writes:
>> At some point, I'd expect something like
>>
>>filtered_list_of_refs = filer(full_list_of_refs, description_of_filter);
>>
>> That would remove some refs from full_list_of_refs according to
>> description_of_filter.
>>
>> (totally invented code, only to show the idea)
>>
>> If there's a piece of code looking like this, then you need a data
>> structure to store list of refs (full_list_of_refs and
>> filtered_list_of_refs) and another to describe what you're doing with it
>> (description_of_filter).
>>
>> The name ref_filter implies to me that it contains the description of
>> the filter, but looking at the code it doesn't seem to be the case.
>>
>
> But it does just that, doesn't it?
>
> struct ref_filter {
> int count, alloc;
> struct ref_filter_item **items;
> const char **name_patterns;
> };
>
> If you see it does contain 'name_patterns' according to which it will
> filter the given refs,
But it also contains struct ref_filter_item **items, which as I
understand it contains a list of refs (with name, sha1 & such).
That's the part I do not find natural: the same structure contains both
the list of refs and the way it should be filtered.
Re-reading the patch, I seem to understand that you're putting both on
the same struct because of the API of for_each_ref() which takes one
'data' pointer to be casted, so you want both the input (filter
description) and the output (list of refs after filtering) to be
contained in the same struct.
But I think this could be clearer in the code (and/or comment + commit
message). Perhaps stg like:
struct ref_filter_data /* Probably not the best name */ {
struct ref_list list;
struct ref_filter filter;
};
struct ref_list {
int count, alloc;
struct ref_filter_item **items;
const char **name_patterns;
};
struct ref_filter {
const char **name_patterns;
/* There will be more here later */
};
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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 2/4] ref-filter: add ref-filter API
On Sat, May 23, 2015 at 4:42 PM, Matthieu Moy
wrote:
> karthik nayak writes:
>
>>> At some point, I'd expect something like
>>>
>>>filtered_list_of_refs = filer(full_list_of_refs, description_of_filter);
>>>
>>> That would remove some refs from full_list_of_refs according to
>>> description_of_filter.
>>>
>>> (totally invented code, only to show the idea)
>>>
>>> If there's a piece of code looking like this, then you need a data
>>> structure to store list of refs (full_list_of_refs and
>>> filtered_list_of_refs) and another to describe what you're doing with it
>>> (description_of_filter).
>>>
>>> The name ref_filter implies to me that it contains the description of
>>> the filter, but looking at the code it doesn't seem to be the case.
>>>
>>
>> But it does just that, doesn't it?
>>
>> struct ref_filter {
>> int count, alloc;
>> struct ref_filter_item **items;
>> const char **name_patterns;
>> };
>>
>> If you see it does contain 'name_patterns' according to which it will
>> filter the given refs,
>
> But it also contains struct ref_filter_item **items, which as I
> understand it contains a list of refs (with name, sha1 & such).
>
> That's the part I do not find natural: the same structure contains both
> the list of refs and the way it should be filtered.
>
> Re-reading the patch, I seem to understand that you're putting both on
> the same struct because of the API of for_each_ref() which takes one
> 'data' pointer to be casted, so you want both the input (filter
> description) and the output (list of refs after filtering) to be
> contained in the same struct.
>
> But I think this could be clearer in the code (and/or comment + commit
> message). Perhaps stg like:
>
> struct ref_filter_data /* Probably not the best name */ {
> struct ref_list list;
> struct ref_filter filter;
> };
>
> struct ref_list {
> int count, alloc;
> struct ref_filter_item **items;
> const char **name_patterns;
> };
Matthieu, I think you forgot to remove "const char **name_patterns;"
in the above struct, as you put it in the "ref_filter" struct below:
> struct ref_filter {
> const char **name_patterns;
> /* There will be more here later */
> };
I agree that it might be clearer to separate both. In this case
instead of "ref_list" the struct might be called "ref_filter_array" as
we already have "argv_array" in argv-array.h and "sha1_array" in
"sha1-array.h".
--
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: git status doesn't ignore GIT_DIR directory?
Mike Hommey writes: > On Sat, May 23, 2015 at 09:22:56AM +0700, Duy Nguyen wrote: >> On Fri, May 22, 2015 at 07:03:48PM -0700, Junio C Hamano wrote: >> > As far as I know, GIT_DIR was prepared as a mechanism to point at >> > another .git directory that does not live inside the working tree, not >> > as a mechanism to rename it to arbitrary name. E.g. >> > >> > $ git init >> > $ mv .git .svn >> > $ GIT_DIR=$(pwd)/.svn ; export GIT_DIR >> > >> > is not expected to work. >> ... >> ++ >> +Note that if GIT_DIR is set explicitly to a directory inside working >> +tree, the directory name must be ".git". > > Isn't the requirement that it _ends_ with ".git" (that is, > GIT_DIR=/path/to/foo.git would work) I think both of you are wrong ;-) The thing is, what you are seeing does not have much to do with GIT_DIR. It is "what Git does when it finds a directory inside the working tree of a project". And ".git" is the only special thing in that context. When we find a directory whose name is ".git", whether it is the same as GIT_DIR or not (and "not" case includes when you do not have GIT_DIR defined), "git add" thinks "Ah, that is a repository proper, and I wouldn't add it to my project". It can do two things. (1) if it is not at the top of the working tree, i.e. some/directory/.git, then some/directory is a submodule of the project that has the working tree we are talking about (unless some/.git exists which makes some/directory/.git a submodule of the project that has some/ as its working tree, of course), so "git add" would treat some/directory as a thing to add. (2) if it is at the top of the working tree, it does not do anything to it, as it does not make sense to add the whole working tree as a separate submodule of ourselves. The same for "git status". (1) is treated as a submodule and we do not consider individual files in some/directory/.git as untracked. (2) we do not cconsider individual files in .git as untracked. GIT_DIR further comes into play when it is _not_ defined. In that case we try upwards to find a directory that has ".git" subdirectory and contains our $(cwd), and then declare it as our repository. And when GIT_DIR points at somewhere that does not affect all of the above (i.e. trying to see if a random directory inside our working tree is a ".git" repository), it can be named anything. If you are working in /path/to/my/work/tree with GIT_DIR set, it can point at /path/to/my/repository_git (note that it does not end with ".git", and note also that it is outside our working tree) just fine. If you move that directory to /path/to/my/worktree/repository_git, and point at it with GIT_DIR, we will notice that is our repository metadata, but "git add" and friends will see "repository_git" is different from ".git" and the special casing rules for directories inside working tree do not kick in. -- 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: git status doesn't ignore GIT_DIR directory?
Junio C Hamano writes: > I think both of you are wrong ;-) > > The thing is, what you are seeing does not have much to do with > GIT_DIR. It is "what Git does when it finds a directory inside the > working tree of a project". And ".git" is the only special thing in > that context. In short, I think Duy's "how about this" means well, but adds documentation at a wrong place. Having said all that, the message I am responding to showed the right way to look at, understand, and explain the current behaviour. It is a separate issue if the current behaviour is optimal from the usability point of view. It is not entirely implausible to extend the special casing rules from "a directory named '.git' only" to "in addition, the directory pointed at by GIT_DIR, if exists, is treated the same way". -- 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 2/4] ref-filter: add ref-filter API
Christian Couder writes:
>> struct ref_list {
>> int count, alloc;
>> struct ref_filter_item **items;
>> const char **name_patterns;
>> };
>
> Matthieu, I think you forgot to remove "const char **name_patterns;"
> in the above struct, as you put it in the "ref_filter" struct below:
Yes, indeed. Too quick cut-and-paste.
> I agree that it might be clearer to separate both. In this case
> instead of "ref_list" the struct might be called "ref_filter_array" as
> we already have "argv_array" in argv-array.h and "sha1_array" in
> "sha1-array.h".
I'd drop the "filter" part and make it ref_array then. There's no reason
we could not use it it places other than filter.
But we also have string_list which is an array underneath, so I think
both names (_array and _list) are fine.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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: recovering from "unordered stage entries in index" error
"McHenry, Matt" writes: > Yes, that does turn up some interesting stuff. It looks > like the repository contains some paths with non-ASCII > characters, for example this one has some en-dashes (U+2013) > in its name: Then the recipe in the message you are responding to shoulld be changed somewhat to tell Git that it is OK to show non-ASCII in verbatim. Perhaps doing this once git config core.quotepath false before asking ls-files to show the paths should be sufficient. Thanks. -- 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 2/4] ref-filter: add ref-filter API
Matthieu Moy writes:
> But I think this could be clearer in the code (and/or comment + commit
> message). Perhaps stg like:
>
> struct ref_filter_data /* Probably not the best name */ {
> struct ref_list list;
> struct ref_filter filter;
> };
>
> struct ref_list {
> int count, alloc;
> struct ref_filter_item **items;
> };
If you plan to use ALLOC_GROW() API, name the bookkeeping variables
"alloc" & "nr", unless you have a compelling reason to deviate from
the prevailing practice.
> struct ref_filter {
> const char **name_patterns;
> /* There will be more here later */
> };
Very good suggestion.
Whatever the final name would be, it is a good idea to separate the
"list of things that are operated on" and the "set of operations to
be applied". That makes things conceptually cleaner; you can have
multiple of the former operated on with a singleton of the latter
and then their results merged, etc. etc.
And I do not think an array of things that are operated on should
not be named "ref_filter_item".
Surely, the latter "set of operations to be applied" may currently
be only filtering, but who says it has to stay that way? "I have a
set of refs that represent my local branches I am interested
in. Please map them to their corresponding @{upstream}" is a
reasonable request once you have an infrastructure to represent "set
of refs to be worked on" and "set of operations to apply", and at
that point, the items are no longer filter-items (map-items?).
--
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: git status doesn't ignore GIT_DIR directory?
Junio C Hamano writes: > Junio C Hamano writes: > >> I think both of you are wrong ;-) >> >> The thing is, what you are seeing does not have much to do with >> GIT_DIR. It is "what Git does when it finds a directory inside the >> working tree of a project". And ".git" is the only special thing in >> that context. > > In short, I think Duy's "how about this" means well, but adds > documentation at a wrong place. > > Having said all that, the message I am responding to showed the > right way to look at, understand, and explain the current behaviour. > It is a separate issue if the current behaviour is optimal from the > usability point of view. It is not entirely implausible to extend > the special casing rules from "a directory named '.git' only" to "in > addition, the directory pointed at by GIT_DIR, if exists, is treated > the same way". If somebody is interested in pursuing this further in the direction of changing the behaviour (so that Thorsten's original would work as expected), one thing to be careful about is the case (1) (case (2) is more or less straight-forward and obvious). If you do $ GIT_DIR=/path/to/worktree/sub/repo.git $ GIT_WORK_TREE=/path/to/worktree $ export GIT_DIR GIT_WORK_TREE $ cd $GIT_WORK_TREE $ git add sub with the current rule, because sub/repo.git does not trigger the special casing, we may end up adding everything inside our own repository, which is clearly crazy. But if you change the rule to special case the directory pointed at by $GIT_DIR, then we would start treating that directory as "ah, there is a Git repository". But the updated code must not say "hence, sub/ is the top level of the working tree of that repository, so we add it as a submodule". It instead should just ignore that repo.git directory, just like a plain vanilla "git add ." ignores ".git" at the top-level, and add other things in sub/ directory, i.e. treating sub/ as just a normal subdirectory in our working tree. I am not planning to do this in a near future myself, but I thought I should caution in case anybody is interested. Thanks. -- 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 v5 1/1] send-email: Add sendmail email aliases format
Allen Hubbe writes:
> Note that this only adds support for a limited subset of the sendmail
> format. The format is is as follows.
>
> : [, ...]
>
> Aliases are specified one per line, and must start on the first column of the
> line. Blank lines are ignored. If the first non whitespace character
> on a line is a '#' symbol, then the whole line is considered a comment,
> and is ignored.
>
> Example:
>
> alice: Alice W Land
> bob: Robert Bobbyton
> # this is a comment
> # this is also a comment
> chloe: ch...@example.com
> abgroup: alice, bob
> bcgrp: bob, chloe, Other
>
> Unlike the standard sendmail format, this does not support quoted
> aliases or quoted addresses. Line continuations are not supported.
> Warnings are printed for explicitly unsupported constructs, and any
> other lines that are not recognized.
>
> Signed-off-by: Allen Hubbe
> ---
>
> Notes:
> This v5 renames the parser 'sendmail' again, from 'simple'.
> Therefore, the subject line is changed again, too.
>
> Previous subject line: send-email: Add simple email aliases format
>
> The format is restricted to a subset of sendmail. When the subset
> diverges from sendmail, the parser warns about the line that diverges,
> and ignores the line. The supported format is described in the
> documentation, as well as the behavior when an unsupported format
> construct is detected.
>
> A badly constructed sentence was corrected in the documentation.
>
> The test case was changed to use a here document, and the unsupported
> comment after an alias was removed from the test case alias file input.
Thanks.
A small thing I noticed in the test (and this patch is not adding a
new "breakage"---there are a few existing instances) is the use of
"~/"; it should be spelled "$HOME/" instead for portability (not in
POSIX, even though bash, dash and ksh all seem to understand it).
I think this round looks good from a cursory read.
Eric, what do you think?
> Documentation/git-send-email.txt | 37 -
> git-send-email.perl | 29 +
> t/t9001-send-email.sh| 27 +++
> 3 files changed, 92 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-send-email.txt
> b/Documentation/git-send-email.txt
> index 804554609def..97387fd27a8d 100644
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -383,7 +383,42 @@ sendemail.aliasesFile::
>
> sendemail.aliasFileType::
> Format of the file(s) specified in sendemail.aliasesFile. Must be
> - one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.
> + one of 'sendmail', 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.
> ++
> +If the format is 'sendmail', then the alias file format is described below.
> +Descriptions of the other file formats can be found by searching the
> +documentation of the email program of the same name.
> ++
> +The 'sendmail' format is is as follows. Note that 'git-send-email' currently
> +only supports a limited subset of the sendmail format.
> ++
> + : [, ...]
> ++
> +Aliases are specified one per line, and must start on the first column of the
> +line. Blank lines are ignored. If the first non whitespace character on a
> +line is a `#` symbol, then the whole line is considered a comment, and is
> +ignored.
> ++
> +Example of the 'sendmail' format:
> ++
> + alice: Alice W Land
> + bob: Robert Bobbyton
> + # this is a comment
> +# this is also a comment
> + chloe: ch...@example.com
> + abgroup: alice, bob
> + bcgrp: bob, chloe, Other
> ++
> +Unlike the standard sendmail format, 'git-send-email' currently diverges in
> the
> +following ways.
> ++
> +*Quoted aliases and quoted addresses are not supported: lines that
> + contain a `"` symbol are ignored.
> +*Line continuations are not supported: any lines that start with
> + whitespace, or end with a `\` symbol are ignored.
> +*Warnings are printed on the standard error output for any explicitly
> + unsupported constructs, and any other lines that are not recognized
> + by the parser.
>
> sendemail.multiEdit::
> If true (default), a single editor instance will be spawned to edit
> diff --git a/git-send-email.perl b/git-send-email.perl
> index e1e9b1460ced..ffea50094a48 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -487,6 +487,8 @@ sub split_addrs {
> }
>
> my %aliases;
> +
> +
> my %parse_alias = (
> # multiline formats can be supported in the future
> mutt => sub { my $fh = shift; while (<$fh>) {
> @@ -516,6 +518,33 @@ my %parse_alias = (
> }
> } },
>
> + sendmail => sub { my $fh = shift; while (<$fh>) {
> + # ignore comment lines
> + if (/^\s*(?:#.*)?$/) { }
> +
> + # warn o
Re: [PATCH 2/4] ref-filter: add ref-filter API
But it also contains struct ref_filter_item **items, which as I
understand it contains a list of refs (with name, sha1 & such).
That's the part I do not find natural: the same structure contains both
the list of refs and the way it should be filtered.
Re-reading the patch, I seem to understand that you're putting both on
the same struct because of the API of for_each_ref() which takes one
'data' pointer to be casted, so you want both the input (filter
description) and the output (list of refs after filtering) to be
contained in the same struct.
Was kinda confused, This clears out things, Thanks.
But I think this could be clearer in the code (and/or comment + commit
message). Perhaps stg like:
struct ref_filter_data /* Probably not the best name */ {
struct ref_list list;
struct ref_filter filter;
};
struct ref_list {
int count, alloc;
struct ref_filter_item **items;
const char **name_patterns;
};
struct ref_filter {
const char **name_patterns;
/* There will be more here later */
};
This seems cleaner, agreed.
>
> I agree that it might be clearer to separate both. In this case
> instead of "ref_list" the struct might be called "ref_filter_array" as
> we already have "argv_array" in argv-array.h and "sha1_array" in
> "sha1-array.h".
>
Somehow ref_list seems more real to me, list of refs.
>
> And I do not think an array of things that are operated on should
> not be named "ref_filter_item".
>
> Surely, the latter "set of operations to be applied" may currently
> be only filtering, but who says it has to stay that way? "I have a
> set of refs that represent my local branches I am interested
> in. Please map them to their corresponding @{upstream}" is a
> reasonable request once you have an infrastructure to represent "set
> of refs to be worked on" and "set of operations to apply", and at
> that point, the items are no longer filter-items (map-items?).
>
That's also a good point to consider, I shall rename and restructure the
code as discussed here, thanks.
--
Regards,
Karthik
--
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 v5 1/1] send-email: Add sendmail email aliases format
Junio C Hamano writes: >> diff --git a/Documentation/git-send-email.txt >> b/Documentation/git-send-email.txt >> index 804554609def..97387fd27a8d 100644 >> --- a/Documentation/git-send-email.txt >> +++ b/Documentation/git-send-email.txt >> @@ -383,7 +383,42 @@ sendemail.aliasesFile:: >> >> sendemail.aliasFileType:: >> Format of the file(s) specified in sendemail.aliasesFile. Must be >> -one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'. >> +one of 'sendmail', 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'. We prefer to append to an existing list of equals, not prepend. >> ++ >> +If the format is 'sendmail', then the alias file format is described below. >> +Descriptions of the other file formats can be found by searching the >> +documentation of the email program of the same name. The phrasing feels somewhat awkward. How about dropping the first line, pretending as if 'sendmail' is also fully 'sendmail' format, and then describe the limitations (like you already did below)? I have a feeling that other formats have similar limitations (e.g. I do not think piping to commands in any other formats would be supported by send-email), and other people can follow suit and describe the limitations. That is, drop the paragraph that describes the basics (which can be learned by searching the documentation of the email program of the same name), and dive right into the differences. IOW, What an alias file in each format looks like can be found in the documentation of the email program of the same name. The differences and limitations from the standard formats are described below: + -- sendmail;; >> +* Quoted aliases and quoted addresses are not supported: lines that >> +contain a `"` symbol are ignored. >> +* Line continuations are not supported: any lines that start with >> +whitespace, or end with a `\` symbol are ignored. >> +* Warnings are printed on the standard error output for any explicitly >> +unsupported constructs, and any other lines that are not recognized >> +by the parser. -- That way, limitations and deviations of other formats can be added later in a consistent way. Just a thought. -- 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 v5 1/1] send-email: Add sendmail email aliases format
Junio C Hamano writes: > A small thing I noticed in the test (and this patch is not adding a > new "breakage"---there are a few existing instances) is the use of > "~/"; it should be spelled "$HOME/" instead for portability (not in > POSIX, even though bash, dash and ksh all seem to understand it). Well, I was wrong. Tilde expansion is in POSIX. Nevertheless, I'd prefer if we avoided it. -- 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: What's cooking in git.git (May 2015, #06; Fri, 22)
On 22/05/15 23:14, Junio C Hamano wrote: Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. ry_matches(): inline function + is_> The fourth batch of topics have been merged to 'master'. * ld/p4-editor-multi-words (2015-05-20) 6 commits - SQUASH - git-p4: tests: use test-chmtime in place of touch - SQUASH - git-p4: fix handling of multi-word P4EDITOR - SQUASH - git-p4: add failing test for P4EDITOR handling Unlike "$EDITOR" and "$GIT_EDITOR" that can hold the path to the command and initial options (e.g. "/path/to/emacs -nw"), 'git p4' did not let the shell interpolate the contents of the environment variable that name the editor "$P4EDITOR" (and "$EDITOR", too). Make it in line with the rest of Git, as well as with Perforce. The latest versions in the branch (with the SQUASH) all look good to me. The other thing still missing from this series is fixing Windows builds. I've been attempting to get a Windows build environment going to actually test it (if it hasn't been tested, it doesn't work :-). I'm slowly getting there, but I'm not very familiar with this particular OS. Thanks, Luke -- 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
Please Acknowledge My Proposal!!
Please Acknowledge My Proposal!! My name is Mr. Juan Martin Domingo a lawyer resident in Spain. I am writing to let you know I have some FUNDS I want to transfer and am seeking if you can be a beneficiary...Do not hesitate to Contact me for more information if interested: gva.abogad...@aim.com). Sincerely Juan Martin Domingo. -- 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: recovering from "unordered stage entries in index" error
Per Junio's email, with core.quotepath=false, there are no differences with sorting in either ls-files or the tree named in the GIT_TRACE_2 output: $ git config --local core.quotepath false $ git ls-tree --name-only -r 74332b7d653cde7ba3b999cc7b0adcfd9d924440 > ls-tree $ LANG=C LC_ALL=C sort ls-tree > ls-tree-sorted-lc-all $ diff -s ls-tree ls-tree-sorted-lc-all Files ls-tree and ls-tree-sorted-lc-all are identical $ git ls-files > ls-files $ LANG=C LC_ALL=C sort ls-files > ls-files-sorted-lc-all $ diff -s ls-files ls-files-sorted-lc-all Files ls-files and ls-files-sorted-lc-all are identical From: McHenry, Matt Sent: Friday, May 22, 2015 10:47 PM To: Duy Nguyen Cc: Junio C Hamano; git@vger.kernel.org Subject: RE: recovering from "unordered stage entries in index" error > So maybe you can do "GIT_TRACE=2 git svn fetch" and post the output. > I'd expect to see something like "git read-tree " before "fatal: > unorder...". You can then use git ls-tree to examine this tree, > try to sort the file list with "LANG=C sort" and compare with the > original list. There is no read-tree in the output (below). The sha1 that is mentioned, 74332b7, is the one for the current trunk: $ git svn log -1 --show-commit --oneline trunk r231655 | 74332b7 | CLT: changed skill from not compound to compound. So not surprisingly, I guess, I get basically the same results as with the ls-files commands earlier: files with Unicode chars are quoted and sort at the front: $ git ls-tree --name-only -r 74332b7d653cde7ba3b999cc7b0adcfd9d924440 > ls-tree $ LANG=C LC_ALL=C sort ls-tree > ls-tree-sorted-lc-all $ grep -n Ninja__Beta ls-tree* ls-tree:36974:"curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \342\200\223 Ninja/FT3 \342\200\223 Ninja__Beta.zip" ls-tree-sorted-lc-all:89:"curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \342\200\223 Ninja/FT3 \342\200\223 Ninja__Beta.zip" (Just sorting with LANG=C but without LC_ALL=C produced a ton of other differences, mostly around numeric vs. lexical ordering as far as I could tell.) I tried this same thing with my test repo, and it exhibits the same quoted-filename-sorts-to-the-top behaviour, but does not exhibit the git svn fetch write-tree error. $ GIT_TRACE=2 git svn fetch 22:21:16.683918 git.c:557 trace: exec: 'git-svn' 'fetch' 22:21:16.683945 run-command.c:351 trace: run_command: 'git-svn' 'fetch' 02:21:16.918593 git.c:348 trace: built-in: git 'rev-parse' '--git-dir' 02:21:16.920218 git.c:348 trace: built-in: git 'rev-parse' '--show-cdup' 02:21:16.921997 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.fetchall' 02:21:16.923609 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.repack' 02:21:16.925164 git.c:348 trace: built-in: git 'config' '--get' 'svn.repackflags' 02:21:16.926706 git.c:348 trace: built-in: git 'config' '--get' 'svn.revision' 02:21:16.928847 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.nocheckout' 02:21:16.930410 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvnsyncProps' 02:21:16.931963 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.localtime' 02:21:16.933538 git.c:348 trace: built-in: git 'config' '--get' 'svn.includepaths' 02:21:16.935107 git.c:348 trace: built-in: git 'config' '--get' 'svn.username' 02:21:16.936675 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noauthcache' 02:21:16.940413 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.quiet' 02:21:16.942064 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.uselogauthor' 02:21:16.943696 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noMetadata' 02:21:16.945344 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvmProps' 02:21:16.947607 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.parent' 02:21:16.950737 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.addauthorfrom' 02:21:16.952532 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsprog' 02:21:16.954133 git.c:348 trace: built-in: git 'config' '--get' 'svn.ignorepaths' 02:21:16.955704 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.followparent' 02:21:16.957287 git.c:348 trace: built-in: git 'config' '--get' 'svn.configdir' 02:21:16.958930 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsfile' 02:21:16.962142 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.logwindowsize' 02:21:16.963913 git.c:348
Re: [PATCH v5 1/1] send-email: Add sendmail email aliases format
On Sat, May 23, 2015 at 2:07 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> A small thing I noticed in the test (and this patch is not adding a >> new "breakage"---there are a few existing instances) is the use of >> "~/"; it should be spelled "$HOME/" instead for portability (not in >> POSIX, even though bash, dash and ksh all seem to understand it). > > Well, I was wrong. Tilde expansion is in POSIX. > > Nevertheless, I'd prefer if we avoided it. Alright, $HOME it will be. -- 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 2/4] ref-filter: add ref-filter API
Junio C Hamano writes: > And I do not think an array of things that are operated on should > not be named "ref_filter_item". Is the double-negation intended? It seems contradictory with: > Surely, the latter "set of operations to be applied" may currently > be only filtering, but who says it has to stay that way? (With which I do agree) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 v5 1/1] send-email: Add sendmail email aliases format
On Sat, May 23, 2015 at 2:00 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >>> diff --git a/Documentation/git-send-email.txt >>> b/Documentation/git-send-email.txt >>> index 804554609def..97387fd27a8d 100644 >>> --- a/Documentation/git-send-email.txt >>> +++ b/Documentation/git-send-email.txt >>> @@ -383,7 +383,42 @@ sendemail.aliasesFile:: >>> >>> sendemail.aliasFileType:: >>> Format of the file(s) specified in sendemail.aliasesFile. Must be >>> -one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'. >>> +one of 'sendmail', 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'. > > We prefer to append to an existing list of equals, not prepend. > I initially thought to put it last, too. I'll move it back to the end. I moved it to the beginning, because it seemed odd to me for only the last thing in the list to have a further description. If the intent is that eventually (perhaps in an ideal world), the other formats will have expanded documentation, too, then you are right that adding new things to the end makes the most sense. >>> ++ >>> +If the format is 'sendmail', then the alias file format is described below. >>> +Descriptions of the other file formats can be found by searching the >>> +documentation of the email program of the same name. > > The phrasing feels somewhat awkward. How about dropping the first > line, pretending as if 'sendmail' is also fully 'sendmail' format, > and then describe the limitations (like you already did below)? I > have a feeling that other formats have similar limitations (e.g. I > do not think piping to commands in any other formats would be > supported by send-email), and other people can follow suit and > describe the limitations. > > That is, drop the paragraph that describes the basics (which can be > learned by searching the documentation of the email program of the > same name), and dive right into the differences. > > IOW, > > What an alias file in each format looks like can be found in > the documentation of the email program of the same name. The > differences and limitations from the standard formats are > described below: > + > -- > sendmail;; >>> +* Quoted aliases and quoted addresses are not supported: lines that >>> +contain a `"` symbol are ignored. >>> +* Line continuations are not supported: any lines that start with >>> +whitespace, or end with a `\` symbol are ignored. >>> +* Warnings are printed on the standard error output for any explicitly >>> +unsupported constructs, and any other lines that are not recognized >>> +by the parser. > -- Alright. Thanks for showing me '--'. I had some trouble with asciidoc, where my intention was to insert a bulleted list between two paragraphs in a containing definition-list item. The paragraph that I intended to be after the bulleted list was instead nested in the last bulleted item in the list. The documentation for asciidoc soesn't seem to be very helpful in describing this construct. There is one example, that I could find, and I didn't find a description of the syntax for it. Perhaps I missed it among all the other uses of a series of '-'. I don't see any way for this to distinguish between different levels of nesting, like a block of --/-- in another block of --/--; that might be syntactically indistinguishable from a block of --/-- followed by another block of --/--. > > That way, limitations and deviations of other formats can be added > later in a consistent way. > > Just a thought. -- 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: [RESOLVED NOTABUG] "git commit --date" format parsing
Le 23/05/2015 00:06, Jeff King a écrit : > OK, this is weird. When I tried to reproduce, I couldn't. But I had > typed in the date string myself while reading your email in another > window. And though I was sure that I had typed it correctly, just to be > double-plus-sure I copied and pasted your string. And it failed! > > The date string in your email looks like this (using cut and paste): > > $ echo 2015-05-21T16∶31+02:00 | xxd > : 3230 3135 2d30 352d 3231 5431 36e2 88b6 2015-05-21T16... > 0010: 3331 2b30 323a 3030 0a 31+02:00. > > Your "colon" is actually UTF-8 for code point . So git's > date parser does not recognize it, and punts to approxidate(), which > does all manner of crazy guessing trying to figure out what you meant. Okay, this is crazy. Now I can't reproduce it myself either: I just repeated the procedure and date parsing works as expected. The only difference with my last email is that I upgraded and rebooted my system (there was a kernel update for 4.0.4 on Arch... Among other things). I guess that would have reset my keyboard layout, but I swear I tested it multiple times over a few days before posting here. Anyway, thanks for your insight I would have never figured this myself. I'll be wary of silent unicode character substitution :) Just for the record: $ localectl System Locale: LANG=fr_FR.UTF8 VC Keymap: fr X11 Layout: fr X11 Variant: oss And I am using the default monospace font in gnome-terminal and gedit. Pretty basic stuff, really. Thanks again, Bastien -- 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: Pushing and pulling the result of `git replace` and objects/info/alternates
Hi, On Fri, May 22, 2015 at 4:38 PM, Stephen Kelly wrote: > Hello, > > I have an 'integration repo' which contains other git repos as submodules. > > One of the submodules is to be split in two to extract a library. > > A common way of doing that is to use git-filter-branch. A disadvantage > of that is that it results in duplicated partial-history in the > extracted repo. So, git log shows the entire history, but there is not > one canonical sha which represents the history at that point. The > split repo will contain 'false history', and checking it out will not > be useful. > > So, I want to avoid git-filter-branch. > > I have tried out using `git replace --graft` and > .git/objects/info/alternates to 'refer to' the history in the origin > repo instead of 'duplicating' it. This is similar to how Qt5 repos > refer to Qt 4 history in a different repo. > > Question 1) Is this a reasonable thing to do for this scenario? I think it should work without too much work, but see the answer to the next question. > Question 2) Is there a way to push the `git replace` result and the > `info/alternates` content so that clients cloning the 'integration > repo' do not have to do that 'manually' or with a 'setup-repo.sh' > script? In short no. "git replace" creates replace refs in "refs/replace/". To fetch these refs, people need to use either "git fetch 'refs/replace/*:refs/replace/*'" or add a "fetch = refs/replace/*:refs/replace/*" line in their config. For simplicity and security reasons fetching replace refs is not on by default. Also changing the objects/info/alternates to make it point to another repo cannot be done automatically when cloning. > The sequence of commands below can be pasted into a tmp directory to > see the scenario in action. > > Thanks! > > > mkdir calculator > cd calculator > mkdir mainui libcalc > echo "print \"hello\"" > mainui/app.py > echo "print \"hello\"" > libcalc/adder.py > echo "print \"hello\"" > libcalc/subtracter.py > git init > git add . > git commit -am "Initial commit" > git checkout `git rev-parse HEAD` > > cd .. > mkdir appsuite > cd appsuite > git init > git submodule add ../calculator > git commit -m "Add calculator submodule" > > # Add other submodules in the suite... > > cd calculator > > echo "print \"goodbye\"" > libcalc/subtracter.py > git add libcalc/subtracter.py > git commit -am "Fix bug in subtracter" > > echo "print \"Hi\"" > libcalc/adder.py > git add libcalc/adder.py > git commit -am "Make adder more efficient" > > echo "print \"Hello, world!\"" > mainui/app.py > git add mainui/app.py > git commit -am "Improve app" > > echo "print \"hello, hello\"" > libcalc/multiplier.py > git add libcalc/multiplier.py > git commit -am "Add multiplier" > > cd .. > git add calculator > git commit -m "Update calculator submodule" > > mkdir compute > cd calculator > mv libcalc ../compute > > extraction_sha=`git rev-parse HEAD` > git commit -am "Remove libcalc from calculator repo" -m "It is moved > to a new compute repo" > removal_sha=`git rev-parse HEAD` > git push > > cd ../compute > git init > git add . > git commit -m "Create the compute repo." -m "This commit will not be > normally visible after the replace --graft below." > > echo "This is the compute framework. It contains the libcalc library." > > README > git add README > git commit -m "Initialize the compute repo." -m "This has been > extracted from calculator.git at $removal_sha" > git checkout `git rev-parse HEAD` > > cd .. > mv compute .. > git submodule add ../compute > > git add calculator compute > git commit -m "Split compute framework out of calculator repo." > > cd compute > git log --oneline > # We don't see older history from the calculator repo > > # Let's add alternates > echo "../../calculator/objects" > > ../.git/modules/compute/objects/info/alternates > > # ... and graft onto the extraction commit > git replace --graft HEAD $extraction_sha > > git log --oneline > # Great, now we see history from the calculator repo. > > cd ../.. > git clone appsuite appsuite-clone > cd appsuite-clone > git submodule update --init > cd compute > ls ../.git/modules/compute/objects/info > git log --oneline > # The replacement and alternatives did not get cloned ... :( > > echo "../../calculator/objects" > > ../.git/modules/compute/objects/info/alternates > git replace --graft HEAD $extraction_sha Maybe use the following instead of the above line: git fetch 'refs/replace/*:refs/replace/*' > # And now we see the history from the calculator repo. Great. But, it > required user action after the clone. Yeah, but if the 2 above commands are in a script maybe it's reasonable to ask the user to launch the script once after cloning. Best, Christian. -- 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
