Re: [PATCH v5 00/14] New remote-hg helper
On Tue, Oct 30, 2012 at 7:00 PM, Chris Webb ch...@arachsys.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Yes, it seems this is an API issue; repo.branchtip doesn't exist in python 2.2. Hi. Presumably this is a problem with old mercurial not a problem with old python as mentioned in the commit? Yeah, mercurial. Both issues should be fixed now :) They are indeed, and it now works nicely on all the repos I've tested it with, including http://selenic.com/hg: very impressive! I wonder whether it's worth ignoring heads with bookmarks pointing to them when it comes to considering heads of branches, or at least allowing the hg branch tracking to be easily disabled? A common idiom when working with hg bookmarks is to completely ignore the (not very useful) hg branches (i.e. all commits are on the default hg branch) and have a bookmark for each line of development used exactly as a git branch would be. On such a repository, at the moment you will always get a warning about multiple heads on branches/default, even though you actually don't care about branches/default (and would prefer it not to exist) and just want the branches coming from the bookmarks. I've also seen repositories with no hg branches, but with a single unbookmarked tip and bookmarks on some other heads to mark non-mainline development. It would be nice for branches/default to track the unbookmarked tip in this case, without warning about the other, bookmarked heads. Implemented now. I'm not handling the 'tip' revision, but most likely it's also the '.' revision. In this case a fake 'master' bookmark will be created to track that revision. Finally, on a simple repo with no branches and where there's no clash with a bookmark called master, I'd love to be able to a get a more idiomatic origin/master rather than origin/branches/default. Yeah, you can get that now. If there are no branches or bookmarks, 'master' will point to '.'. As for your preference of not tracking branches, there's a new option: % git config --global remote-hg.track-branches false So you don't have to use hg-git-compat mode :) Cheers. -- Felipe Contreras -- 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: [OT] How to get the discussion details via notes
On Wed, Oct 31, 2012 at 10:10:24AM -0400, Jeff King wrote: On Wed, Oct 31, 2012 at 10:53:27AM +0100, Peter Baumann wrote: covers the basics (current behavior and intent of the change) in its first two paragraphs and anyone wanting more detail can use GIT_NOTES_REF=refs/remotes/charon/notes/full \ git show --show-notes commit to find more details. I seem to miss something here, but I don't get it how the notes ref becomes magically filled with the details of this discussion. Thomas Rast (aka charon) keeps a mapping of commits to the email threads that led to them. You can fetch it from: git://repo.or.cz/git/trast.git (try the notes/full and notes/terse refs). Nice! I didn't know about that. -Peter -- 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 v2 0/3] Introduce diff.submodule
Hi, v1 is here: http://mid.gmane.org/1349196670-2844-1-git-send-email-artag...@gmail.com I've fixed the issues pointed out in the review by Jens. Sorry about the delay; need to find a new dayjob. Ramkumar Ramachandra (3): Documentation: move diff.wordRegex from config.txt to diff-config.txt diff: introduce diff.submodule configuration variable submodule: display summary header in bold Documentation/config.txt |6 -- Documentation/diff-config.txt| 13 + Documentation/diff-options.txt |3 ++- builtin/diff.c |4 cache.h |1 + diff.c |7 ++- submodule.c |8 submodule.h |2 +- t/t4041-diff-submodule-option.sh | 30 +- 9 files changed, 60 insertions(+), 14 deletions(-) -- 1.7.8.1.362.g5d6df.dirty -- 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 1/3] Documentation: move diff.wordRegex from config.txt to diff-config.txt
19299a8 (Documentation: Move diff.driver.* from config.txt to diff-config.txt, 2011-04-07) moved the diff configuration options to diff-config.txt, but forgot about diff.wordRegex, which was left behind in config.txt. Fix this. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/config.txt |6 -- Documentation/diff-config.txt |6 ++ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 11f320b..d1de857 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -962,12 +962,6 @@ difftool.tool.cmd:: difftool.prompt:: Prompt before each invocation of the diff tool. -diff.wordRegex:: - A POSIX Extended Regular Expression used to determine what is a word - when performing word-by-word difference calculations. Character - sequences that match the regular expression are words, all other - characters are *ignorable* whitespace. - fetch.recurseSubmodules:: This option can be either set to a boolean value or to 'on-demand'. Setting it to a boolean changes the behavior of fetch and pull to diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt index 75ab8a5..decd370 100644 --- a/Documentation/diff-config.txt +++ b/Documentation/diff-config.txt @@ -107,6 +107,12 @@ diff.suppressBlankEmpty:: A boolean to inhibit the standard behavior of printing a space before each empty output line. Defaults to false. +diff.wordRegex:: + A POSIX Extended Regular Expression used to determine what is a word + when performing word-by-word difference calculations. Character + sequences that match the regular expression are words, all other + characters are *ignorable* whitespace. + diff.driver.command:: The custom diff driver command. See linkgit:gitattributes[5] for details. -- 1.7.8.1.362.g5d6df.dirty -- 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 2/3] diff: introduce diff.submodule configuration variable
Introduce a diff.submodule configuration variable corresponding to the
'--submodule' command-line option of 'git diff'.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/diff-config.txt|7 +++
Documentation/diff-options.txt |3 ++-
builtin/diff.c |4
cache.h |1 +
diff.c |5 +
t/t4041-diff-submodule-option.sh | 30 +-
6 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index decd370..89dd634 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -107,6 +107,13 @@ diff.suppressBlankEmpty::
A boolean to inhibit the standard behavior of printing a space
before each empty output line. Defaults to false.
+diff.submodule::
+ Specify the format in which differences in submodules are
+ shown. The log format lists the commits in the range like
+ linkgit:git-submodule[1] `summary` does. The short format
+ format just shows the names of the commits at the beginning
+ and end of the range. Defaults to short.
+
diff.wordRegex::
A POSIX Extended Regular Expression used to determine what is a word
when performing word-by-word difference calculations. Character
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index cf4b216..f4f7e25 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -170,7 +170,8 @@ any of those replacements occurred.
the commits in the range like linkgit:git-submodule[1] `summary` does.
Omitting the `--submodule` option or specifying `--submodule=short`,
uses the 'short' format. This format just shows the names of the commits
- at the beginning and end of the range.
+ at the beginning and end of the range. Can be tweaked via the
+ `diff.submodule` configuration variable.
--color[=when]::
Show colored diff.
diff --git a/builtin/diff.c b/builtin/diff.c
index 9650be2..6d00311 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -297,6 +297,10 @@ int cmd_diff(int argc, const char **argv, const char
*prefix)
DIFF_OPT_SET(rev.diffopt, ALLOW_EXTERNAL);
DIFF_OPT_SET(rev.diffopt, ALLOW_TEXTCONV);
+ /* Set SUBMODULE_LOG if diff.submodule config var was set */
+ if (submodule_format_cfg !strcmp(submodule_format_cfg, log))
+ DIFF_OPT_SET(rev.diffopt, SUBMODULE_LOG);
+
if (nongit)
die(_(Not a git repository));
argc = setup_revisions(argc, argv, rev, NULL);
diff --git a/cache.h b/cache.h
index a58df84..5fc7ba3 100644
--- a/cache.h
+++ b/cache.h
@@ -1220,6 +1220,7 @@ int add_files_to_cache(const char *prefix, const char
**pathspec, int flags);
/* diff.c */
extern int diff_auto_refresh_index;
+extern const char *submodule_format_cfg;
/* match-trees.c */
void shift_tree(const unsigned char *, const unsigned char *, unsigned char *,
int);
diff --git a/diff.c b/diff.c
index 86e5f2a..835eb26 100644
--- a/diff.c
+++ b/diff.c
@@ -29,6 +29,7 @@ static int diff_use_color_default = -1;
static int diff_context_default = 3;
static const char *diff_word_regex_cfg;
static const char *external_diff_cmd_cfg;
+const char *submodule_format_cfg;
int diff_auto_refresh_index = 1;
static int diff_mnemonic_prefix;
static int diff_no_prefix;
@@ -168,6 +169,8 @@ int git_diff_ui_config(const char *var, const char *value,
void *cb)
diff_stat_graph_width = git_config_int(var, value);
return 0;
}
+ if (!strcmp(var, diff.submodule))
+ return git_config_string(submodule_format_cfg, var, value);
if (!strcmp(var, diff.external))
return git_config_string(external_diff_cmd_cfg, var, value);
if (!strcmp(var, diff.wordregex))
@@ -3656,6 +3659,8 @@ int diff_opt_parse(struct diff_options *options, const
char **av, int ac)
else if (!prefixcmp(arg, --submodule=)) {
if (!strcmp(arg + 12, log))
DIFF_OPT_SET(options, SUBMODULE_LOG);
+ if (!strcmp(arg + 12, short))
+ DIFF_OPT_CLR(options, SUBMODULE_LOG);
}
/* misc options */
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index 6c01d0c..e401814 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -33,6 +33,7 @@ test_create_repo sm1
add_file . foo /dev/null
head1=$(add_file sm1 foo1 foo2)
+fullhead1=$(cd sm1; git rev-list --max-count=1 $head1)
test_expect_success 'added submodule'
git add sm1
@@ -43,6 +44,34 @@ EOF
test_cmp expected actual
+test_expect_success 'added submodule, set diff.submodule'
+ git config diff.submodule log
+ git add sm1
+ git diff --cached actual
+
[PATCH 3/3] submodule: display summary header in bold
Currently, 'git diff --submodule' displays output with a bold diff
header for non-submodules. So this part is in bold:
diff --git a/file1 b/file1
index 30b2f6c..2638038 100644
--- a/file1
+++ b/file1
For submodules, the header looks like this:
Submodule submodule1 012b072..248d0fd:
Unfortunately, it's easy to miss in the output because it's not bold.
Change this.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
diff.c |2 +-
submodule.c |8
submodule.h |2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/diff.c b/diff.c
index 835eb26..115f384 100644
--- a/diff.c
+++ b/diff.c
@@ -2244,7 +2244,7 @@ static void builtin_diff(const char *name_a,
const char *add = diff_get_color_opt(o, DIFF_FILE_NEW);
show_submodule_summary(o-file, one ? one-path : two-path,
one-sha1, two-sha1, two-dirty_submodule,
- del, add, reset);
+ set, del, add, reset);
return;
}
diff --git a/submodule.c b/submodule.c
index e3e0b45..c10182e 100644
--- a/submodule.c
+++ b/submodule.c
@@ -258,7 +258,7 @@ int parse_fetch_recurse_submodules_arg(const char *opt,
const char *arg)
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
- unsigned dirty_submodule,
+ unsigned dirty_submodule, const char *set,
const char *del, const char *add, const char *reset)
{
struct rev_info rev;
@@ -292,15 +292,15 @@ void show_submodule_summary(FILE *f, const char *path,
return;
}
- strbuf_addf(sb, Submodule %s %s.., path,
+ strbuf_addf(sb, %sSubmodule %s %s.., set, path,
find_unique_abbrev(one, DEFAULT_ABBREV));
if (!fast_backward !fast_forward)
strbuf_addch(sb, '.');
strbuf_addf(sb, %s, find_unique_abbrev(two, DEFAULT_ABBREV));
if (message)
- strbuf_addf(sb, %s\n, message);
+ strbuf_addf(sb, %s%s\n, message, reset);
else
- strbuf_addf(sb, %s:\n, fast_backward ? (rewind) : );
+ strbuf_addf(sb, %s:%s\n, fast_backward ? (rewind) : ,
reset);
fwrite(sb.buf, sb.len, 1, f);
if (!message) {
diff --git a/submodule.h b/submodule.h
index f2e8271..997fd06 100644
--- a/submodule.h
+++ b/submodule.h
@@ -20,7 +20,7 @@ void handle_ignore_submodules_arg(struct diff_options
*diffopt, const char *);
int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg);
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
- unsigned dirty_submodule,
+ unsigned dirty_submodule, const char *set,
const char *del, const char *add, const char *reset);
void set_config_fetch_recurse_submodules(int value);
void check_for_new_submodule_commits(unsigned char new_sha1[20]);
--
1.7.8.1.362.g5d6df.dirty
--
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-users] Git clone fails with bad pack header, how to get remote log
On Wed, Oct 31, 2012 at 03:34:22PM +0100, kevin molcard wrote: I forgot to mention that I am using scm manager: https://bitbucket.org/sdorra/scm-manager/wiki/Home So that maybe the custom layer you are talking about. Yeah, that is very important. If I am reading the scm-manager code right (and I might not be, as I only just looked at it), it is built entirely around JGit, and is not calling git-core programs at all. So it is either an issue in scm-manager, or in JGit. Your best bet is probably to report the issue to the scm-manager folks, who can probably help you dig into the problem further (it may even have more detailed logs of what happened, but I don't know). -Peff -- 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: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
Am 01.11.2012 03:58, schrieb Felipe Contreras: On Thu, Nov 1, 2012 at 2:32 AM, Junio C Hamano gits...@pobox.com wrote: Johannes Schindelin johannes.schinde...@gmx.de wrote: On Wed, 31 Oct 2012, Felipe Contreras wrote: It doesn't get any more obvious than that. But to each his own. In my opinion, Jonathan does not deserve any of such condescending words. But maybe the Git maintainers are okay with such a tone on this list? Agreed, and no. We've been hoping we can do without a rigid code of conduct written down to maintain cordial community focused on technical merits, and instead relied on people's common sense, but sense may not be so common, unfortunately, so we may have to have one. Just for the record, what exactly is the problem with the above? 1) The fact that I say it's obvious 2) The fact that I say everyone is entitled to their own opinions Obviousness is in the eye of the beholder. This is a fact that I tend to forget just too easily as well. You probably didn't intend it, but your sentences at the top can be read more like: This is a logical consequence. If you don't understand that, your mental capabilities must be lacking.. That's obviously (ha!) a rude thing to say. Also, and I'm sure you didn't know that, Jedem das Seine (to each his own) was the slogan of the Buchenwald concentration camp. For that reason some (including me) hear the unspoken cynical half-sentence and some people just have to be sent to the gas chamber when someone uses this proverb. No accusations intended, just trying to answer your question from my point of view. René -- 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: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
On Thu, Nov 1, 2012 at 1:46 PM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: Also, and I'm sure you didn't know that, Jedem das Seine (to each his own) was the slogan of the Buchenwald concentration camp. For that reason some (including me) hear the unspoken cynical half-sentence and some people just have to be sent to the gas chamber when someone uses this proverb. Godwin's Law. That went fast, just one day :) -- 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: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
On Thu, Nov 1, 2012 at 9:46 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
You probably didn't intend it, but your sentences at the top can be read
more like: This is a logical consequence. If you don't understand that,
your mental capabilities must be lacking.. That's obviously (ha!) a rude
thing to say.
+1
Also, and I'm sure you didn't know that, Jedem das Seine (to each his own)
Ouch! I sure didn't know that. Thanks for that tidbit. Working with
people from all over the world always teaches me that I might be
saying the wrong thing... accidentally. And to be tolerant of others'
sayings.
{ To dispel any confusion, no, I am not German. I'm from a big
melting-pot of peoples :-) }
m
--
martin.langh...@gmail.com
mar...@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
--
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: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
On Thu, Nov 1, 2012 at 2:46 PM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: Am 01.11.2012 03:58, schrieb Felipe Contreras: On Thu, Nov 1, 2012 at 2:32 AM, Junio C Hamano gits...@pobox.com wrote: Johannes Schindelin johannes.schinde...@gmx.de wrote: On Wed, 31 Oct 2012, Felipe Contreras wrote: It doesn't get any more obvious than that. But to each his own. In my opinion, Jonathan does not deserve any of such condescending words. But maybe the Git maintainers are okay with such a tone on this list? Agreed, and no. We've been hoping we can do without a rigid code of conduct written down to maintain cordial community focused on technical merits, and instead relied on people's common sense, but sense may not be so common, unfortunately, so we may have to have one. Just for the record, what exactly is the problem with the above? 1) The fact that I say it's obvious 2) The fact that I say everyone is entitled to their own opinions Obviousness is in the eye of the beholder. Sometimes. Other times things are obviously obvious, not for the person uttering the words, but for everyone. But I agree that others would disagree, which is why I followed that sentence to one making sure that I understand that there's a disagreement. This is a fact that I tend to forget just too easily as well. I didn't. And even if I did, what is the problem with saying this is obvious? You probably didn't intend it, but your sentences at the top can be read more like: This is a logical consequence. If you don't understand that, your mental capabilities must be lacking.. That's obviously (ha!) a rude thing to say. People can read things in many ways. If you need to pass every sentence you write in a *technical* mailing list through a public relation professional, well, the throughput of such mailing list is going to suffer. That being said, I did wonder what must be going through his mind to not see that as obvious, but I did NOT *say* anything offensive. Specially because I know people have different perspectives, and the fact that a perspective doesn't allow you to see something obvious doesn't say anything about your mental capabilities, only about your perspectives, biases, or even current mental state. Who knows, maybe you skipped your coffee. To assume otherwise is reading too much into things. Read what is being said, and nothing more. Don't make assumptions. And a guideline I love from Wikipedia: Always assume *good faith*. Sometimes, of course, even if you assume good faith things are offensive. This is not the case here. Also, and I'm sure you didn't know that, Jedem das Seine (to each his own) was the slogan of the Buchenwald concentration camp. No, I don't know, and frankly, I don't care. Cultural differences go both ways. You need to assume that whatever cultural reference you are thinking of, might not be the same for the other person. Again: assume *good faith*. And in English, and probably most Latin language countries, to each his own is pretty well understood: http://en.wiktionary.org/wiki/to_each_his_own Etymology A calque of Latin suum cuique, short for suum cuique pulchrum est (“to each his own is beautiful”). Proverb to each his own Every person is entitled to his or her personal preferences and tastes. I would never want my bathroom decorated in chartreuse and turquoise, but to each his own, I suppose. Synonyms there's no accounting for taste For that reason some (including me) hear the unspoken cynical half-sentence and some people just have to be sent to the gas chamber when someone uses this proverb. I never said anything of the sort, and assuming otherwise is a mistake. If you always assume bad faith you will inevitably get offended by things that were never meant to be offensive. It's not a good guideline. No accusations intended, just trying to answer your question from my point of view. Thanks, but I think if others are thinking along the same lines, this is not good. Following the guideline of always assuming good faith makes it easier for people to communicate, and people not getting hurt when in fact no offense was intended, which it turns out to be most of the time. Cheers. -- Felipe Contreras -- 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: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
Felipe, I'll invite you to reread some of your words: That being said, I did wonder what must be going through his mind to not see that as obvious, (...) Following the guideline of always assuming good faith So perhaps it does apply that you could try to assume good intellectual faith in others. When you wonder what must be going through his mind to not see it as obvious... you should consider hey, maybe I am missing some aspect of this. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- 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-users] Git clone fails with bad pack header, how to get remote log
Hi Peff, thanks for this information. I will report the issue to scm-manager. In the meantime I will try to use ssh protocol to connect to my remote server. Thanks again, Kevin 2012/11/1 Jeff King p...@peff.net: On Wed, Oct 31, 2012 at 03:34:22PM +0100, kevin molcard wrote: I forgot to mention that I am using scm manager: https://bitbucket.org/sdorra/scm-manager/wiki/Home So that maybe the custom layer you are talking about. Yeah, that is very important. If I am reading the scm-manager code right (and I might not be, as I only just looked at it), it is built entirely around JGit, and is not calling git-core programs at all. So it is either an issue in scm-manager, or in JGit. Your best bet is probably to report the issue to the scm-manager folks, who can probably help you dig into the problem further (it may even have more detailed logs of what happened, but I don't know). -Peff -- 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: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
On Thu, Nov 1, 2012 at 3:47 PM, Martin Langhoff martin.langh...@gmail.com wrote: Felipe, I'll invite you to reread some of your words: That being said, I did wonder what must be going through his mind to not see that as obvious, (...) Following the guideline of always assuming good faith So perhaps it does apply that you could try to assume good intellectual faith in others. When you wonder what must be going through his mind to not see it as obvious... you should consider hey, maybe I am missing some aspect of this. That's what I did. But even if I didn't, that's not offensive, that only means I made a mistake and it is actually not obvious. But that would be a *technical* mistake. When I feel something is obvious, I say I think this is obvious, when I feel something is obvious to me, but not to others, I say This is obvious to me, when I believe with every fiber of my being that something is obvious with a very low margin of error, not only to me, but to other people, I say this is as obvious as it gets. Of course, there's the possibility that I missed something, there's always that possibility, but even if I did, that would be a *technical* mistake. If you want to discuss the technical aspect of whether or not that is obvious, feel free to comment in the other thread. This one is about netiquette. And I've yet to see what is wrong with saying this is obvious, *specially* if we are assuming good faith from both sides, and both sides have already agreed that there's a disagreement, no insults, no name calling, not ad hominem attacks; simply a disagreement. Nothing wrong with disagreeing, even if it's strongly. Cheers. -- Felipe Contreras -- 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: Wrap commit messages on `git commit -m`
Hi, On 1 November 2012 16:07, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, Some of my colleagues are lazy to fire up an editor and write proper commit messages- they often write one-liners using `git commit -m`. However, that line turns out to be longer than 72 characters, and the resulting `git log` output is ugly. So, I was wondering if it would be a good idea to wrap these one-liners to 72 characters automatically. Can't you do this already? From git-log(1): %w([w[,i1[,i2]]]): switch line wrapping, like the -w option of git-shortlog(1). -- Thomas Adam -- 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 (Oct 2012, #09; Mon, 29)
Jeff King wrote: What's cooking in git.git (Oct 2012, #09; Mon, 29) -- [snip] * cr/cvsimport-local-zone (2012-10-16) 1 commit - git-cvsimport: allow author-specific timezones Allows cvsimport to read per-author timezone from the author info file. Will merge to 'next'. Just FYI, t9604-cvsimport-timestamps.sh is still failing for me. I haven't spent too long on this yet, but I had hoped that setting TZ would sidestep any DST issues. (I have downloaded new tzdata, but have yet to install - actually I don't really want to!). It is not clear from the tzset manpage what happens if you use the DST format for TZ, but you don't provide the start/end date for DST, which is what this test is doing. Perhaps the test should use the non-DST format? e.g. TZ=CST6 git ... Does the test really care about DST? (*if* that is indeed the problem). Also: Note that the first test calls git-cvsimport twice, first *with* TZ set then again without; I suspect a cut/paste editing error. I have added the output of ./t9604-cvsimport-timestamps.sh -v below. ATB, Ramsay Jones ramsay@ramsay-laptop:$ ./t9604-cvsimport-timestamps.sh -v Initialized empty Git repository in /home/ramsay/git/t/trash directory.t9604-cvsimport-timestamps/.git/ expecting success: TZ=CST6CDT git cvsimport -p-x -C module-1 module git cvsimport -p-x -C module-1 module ( cd module-1 git log --format=%s %ai ) actual-1 cat expect-1 -EOF Rev 16 2006-10-29 07:00:01 + Rev 15 2006-10-29 06:59:59 + Rev 14 2006-04-02 08:00:01 + Rev 13 2006-04-02 07:59:59 + Rev 12 2005-12-01 00:00:00 + Rev 11 2005-11-01 00:00:00 + Rev 10 2005-10-01 00:00:00 + Rev 9 2005-09-01 00:00:00 + Rev 8 2005-08-01 00:00:00 + Rev 7 2005-07-01 00:00:00 + Rev 6 2005-06-01 00:00:00 + Rev 5 2005-05-01 00:00:00 + Rev 4 2005-04-01 00:00:00 + Rev 3 2005-03-01 00:00:00 + Rev 2 2005-02-01 00:00:00 + Rev 1 2005-01-01 00:00:00 + EOF test_cmp actual-1 expect-1 Initialized empty Git repository in /home/ramsay/git/t/trash directory.t9604-cvsimport-timestamps/module-1/.git/ * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: * UNKNOWN LINE * Branches: Already up-to-date. --- actual-12012-10-31 21:20:20.0 + +++ expect-12012-10-31 21:20:20.0 + @@ -13,4 +13,4 @@ Rev 4 2005-04-01 00:00:00 + Rev 3 2005-03-01 00:00:00 + Rev 2 2005-02-01 00:00:00 + -Rev 1 2004-12-31 18:00:00 + +Rev 1 2005-01-01 00:00:00 + not ok 1 - check timestamps are UTC (TZ=CST6CDT) # # # TZ=CST6CDT git cvsimport -p-x -C module-1 module # git cvsimport -p-x -C module-1 module # ( # cd module-1 # git log --format=%s %ai # ) actual-1 # cat expect-1 -EOF # Rev 16 2006-10-29 07:00:01 + # Rev 15 2006-10-29 06:59:59 + # Rev 14 2006-04-02 08:00:01 + # Rev 13 2006-04-02 07:59:59 + # Rev 12 2005-12-01 00:00:00 + # Rev 11 2005-11-01 00:00:00 + # Rev 10 2005-10-01 00:00:00 + # Rev 9 2005-09-01 00:00:00 + # Rev 8 2005-08-01 00:00:00 + # Rev 7 2005-07-01 00:00:00 + # Rev 6 2005-06-01 00:00:00 + # Rev 5 2005-05-01 00:00:00 + # Rev 4 2005-04-01 00:00:00 + # Rev 3 2005-03-01 00:00:00 + # Rev 2 2005-02-01 00:00:00 + # Rev 1 2005-01-01 00:00:00 + # EOF # test_cmp actual-1 expect-1 # expecting success: cat cvs-authors -EOF user1=User One us...@domain.org user2=User Two us...@domain.org CST6CDT user3=User Three us...@domain.org EST5EDT user4=User Four us...@domain.org
Re: crash on git diff-tree -Ganything tree for new files with textconv filter
Jeff King wrote: Thinking on it more, my patch, hacky thought it seems, may not be the worst solution. Here are the options that I see: 1. Use a regex library that does not require NUL termination. If we are bound by the regular regexec interface, this is not feasible. But the GNU implementation works on arbitrary-length buffers (you just have to use a slightly different interface), and we already carry it in compat. It would mean platforms which provide a working but non-GNU regexec would have to start defining NO_REGEX. I have thought about the possibility of doing this for unrelated reasons in the past. On cygwin, there have been two unexpected test passes since about v1.6.0 (I reported it to the list in passing), like so: [ ... ] All tests successful. Test Summary Report --- t0050-filesystem.sh (Wstat: 0 Tests: 9 Failed: 0) TODO passed: 5 t7008-grep-binary.sh (Wstat: 0 Tests: 20 Failed: 0) TODO passed: 12 Files=604, Tests=8439, 11190 wallclock secs ( 2.59 usr 1.59 sys + 7294.86 cusr 3416.65 csys = 10715.70 CPU) Result: PASS In particular, t7008.12 passes on cygwin because the regex library apparently matches '.' to NUL. Indeed if you add a test_pause to the script and execute grep .fi a (note grep *not* git-grep) then Binary file a matches on Linux, cygwin and MinGW. (So I assume the test was added to document a difference in behaviour to GNU grep). So, if we use the GNU interface to the regex routines in compat, then we may specify the grep syntax for use in git-grep. (Well that's the theory, I've not actually tried to code it up, so take this with a pinch of salt! :-P ). ATB, Ramsay Jones -- 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
checkout-index: unable to create file foo (File exists)
When we use git on a network filesystem, occasionally and sporadically
we will see the following from a git checkout command:
error: git checkout-index: unable to create file foo (File exists)
Through a very basic grepping and following of the source it seems that
the core of the error message is coming from write_entry() in entry.c:
fd = open_output_fd(path, ce, to_tempfile);
if (fd 0) {
free(new);
return error(unable to create file %s (%s),
path, strerror(errno));
}
So looking into open_output_fd() there is a call to create_file() which
does:
return open(path, O_WRONLY | O_CREAT | O_EXCL, mode);
I am able to prevent the problem from happening with 100% success by
simply giving the git checkout a -q argument to prevent it from
emitting progress reports. This would seem to indicate that the problem
likely revolves around the fact that the progress reporting uses SIGALRM.
Given that O_CREAT | O_EXCL are used in the open() call and that SIGALRM
(along with SA_RESTART) is being used frequently to do progress updates,
it seems reasonable to suspect that the problem is that open() is being
interrupted (but only after it creates the file and before completing)
by the progress reporting mechanism's SIGALRM and when the progress
reporting is done, open() is restarted automatically (due to the use of
SA_RESTART) and fails because the file exists and O_CREAT | O_EXCL are
used in the open() call.
Does this seem like a reasonable hypothesis?
If it does, where does the problem lie here? Is it that SA_RESTART
should not be used since it's not safe with open() and O_CREAT | O_EXCL
(and every system call caller should be handling EINTR) or should the
open() be idempotent so that it can be restarted automatically with
SA_RESTART? If open(2) is supposed to be idempotent, it would be most
useful to have a citation to standard where that is specified.
If open() is not required to be idempotent, it's use with O_CREAT |
O_EXCL and SA_RESTART seems fatally flawed.
Any insight or opinions would be much appreciated.
Cheers,
b.
signature.asc
Description: OpenPGP digital signature
Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
Junio C Hamano wrote: We've been hoping we can do without a rigid code of conduct written down to maintain cordial community focused on technical merits, and instead relied on people's common sense, but sense may not be so common, unfortunately, so we may have to have one. I think that except for occasional lapses this list stays pretty close to what, for example, the Fedora[1] and Ubuntu[2] codes of conduct require, and what Emily Postnews's guide[3] explains not to do. What's the next step? [1] http://www.ubuntu.com/project/about-ubuntu/conduct [2] http://www.ubuntu.com/project/about-ubuntu/conduct [3] http://www.templetons.com/brad/emily.html -- 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: Wrap commit messages on `git commit -m`
On Thu, Nov 1, 2012 at 2:12 PM, Thomas Adam tho...@xteddy.org wrote: Hi, On 1 November 2012 16:07, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, Some of my colleagues are lazy to fire up an editor and write proper commit messages- they often write one-liners using `git commit -m`. However, that line turns out to be longer than 72 characters, and the resulting `git log` output is ugly. So, I was wondering if it would be a good idea to wrap these one-liners to 72 characters automatically. Can't you do this already? From git-log(1): I think he's talking about git-commit wrapping the message as it is being committed, instead of git-log doing the wrapping as it is being displayed. I personally would rather see git-commit refuse to accept messages wider than 72 characters. -- 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 v2 0/3] Introduce diff.submodule
Am 01.11.2012 11:43, schrieb Ramkumar Ramachandra: Hi, v1 is here: http://mid.gmane.org/1349196670-2844-1-git-send-email-artag...@gmail.com I've fixed the issues pointed out in the review by Jens. Thanks, looking good to me. -- 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: Wrap commit messages on `git commit -m`
Ramkumar Ramachandra artag...@gmail.com writes: | Hi, | Some of my colleagues are lazy to fire up an editor and write proper | commit messages- they often write one-liners using `git commit -m`. | However, that line turns out to be longer than 72 characters, and the | resulting `git log` output is ugly. So, I was wondering if it would | be a good idea to wrap these one-liners to 72 characters | automatically. git commit -m 'foo: fix this problem This problem is fixed by doing foo, bar and baz. Signed-off-by: me ' works. -- Lgb -- 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: Wrap commit messages on `git commit -m`
As I see it, the problem is not the possibility to add new lines, but colleagues being too lazy to add them. On Thu, Nov 1, 2012 at 5:29 PM, Lars Gullik Bjønnes lar...@gullik.org wrote: Ramkumar Ramachandra artag...@gmail.com writes: | Hi, | Some of my colleagues are lazy to fire up an editor and write proper | commit messages- they often write one-liners using `git commit -m`. | However, that line turns out to be longer than 72 characters, and the | resulting `git log` output is ugly. So, I was wondering if it would | be a good idea to wrap these one-liners to 72 characters | automatically. git commit -m 'foo: fix this problem This problem is fixed by doing foo, bar and baz. Signed-off-by: me ' works. -- Lgb -- 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 -- 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
Request: git fetch --timeout
Right now, there are events which can cause git fetch to hang forever. This is really problematic in automatic use. A git fetch --timeout which would exit with a nonzero exit code if no forward progress is made would be really helpful. -hpa -- 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: Wrap commit messages on `git commit -m`
Kevin wrote: As I see it, the problem is not the possibility to add new lines, but colleagues being too lazy to add them. I suspect the underlying problem is that we make it too hard to tell git which text editor to run. Ram, what platform do your colleagues use? Thanks, Jonathan -- 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 (Oct 2012, #09; Mon, 29)
On Thu, Nov 1, 2012 at 1:40 PM, Ramsay Jones ram...@ramsay1.demon.co.uk wrote: Jeff King wrote: What's cooking in git.git (Oct 2012, #09; Mon, 29) -- [snip] * cr/cvsimport-local-zone (2012-10-16) 1 commit - git-cvsimport: allow author-specific timezones Allows cvsimport to read per-author timezone from the author info file. Will merge to 'next'. Just FYI, t9604-cvsimport-timestamps.sh is still failing for me. I haven't spent too long on this yet, but I had hoped that setting TZ would sidestep any DST issues. (I have downloaded new tzdata, but have yet to install - actually I don't really want to!). It is not clear from the tzset manpage what happens if you use the DST format for TZ, but you don't provide the start/end date for DST, which is what this test is doing. Perhaps the test should use the non-DST format? e.g. TZ=CST6 git ... Does the test really care about DST? (*if* that is indeed the problem). It actually looks like your TZ database is fine and the problem is with the conversion to a struct tm. In each case, the time is localized to the previous TZ value while the offset for the current TZ value. For example, look at the first commit in the first test. It converted the timestamp to 18:00 (CST6) while all the rest came through as expected.I suspect the previous version of cvsimport would exhibit similar behavior with the first imported commit. What is your platform? Also: Note that the first test calls git-cvsimport twice, first *with* TZ set then again without; I suspect a cut/paste editing error. Oops. The second invocation should have no effect on the repo so the unit test is still valid, but that was a mistake for sure. Thanks. Chris -- 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
Overlong lines with git-merge --log
Hey all. Using git-merge --log to merge commit messages that spawn multiple lines will produce overlong summary lines. That's because each summary line for a commit includes the entire commit message (all lines concatenated). According to git-fmt-merge-msg(1), --log should 'populate the log message with one-line descriptions' instead of using the entire commit messages. Which would make a lot of sense, it's just not working as advertised. Encountered with git version 1.7.9.5. -- Yours sincerely, Tim Janik --- http://timj.testbit.eu/ - Free software Author -- 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 v4 00/14] fast-export and remote-testgit improvements
Hi, I found more issues in fast-export. remote-testgit, and eventually I decided there's no reason to use this python script, so I wrote a much simpler version that does the same, and more. I'm not going to list all the reasons because apparently opinions are not welcome in the list any more. For the actual differences you can check the patch itself. The old remote-testgit is now remote-testpy (as it's testing the python framework, not really remote helpers). The tests are simplified, and exercise more features of transport-helper, and unsuprisingly, find more bugs. Some of these bugs are fixed in this patch series as well, for which I already sent 3 versions, and they come at the end. I was surprised they did fix them, but hey... good is good. I know how to fix the rest of the issues, but I'm not going to bother sending a patch because obvious... er, simple? fixes are not accepted, so there's no chance of something less... evident? getting through. Cheers. Felipe Contreras (14): fast-export: avoid importing blob marks remote-testgit: fix direction of marks Rename git-remote-testgit to git-remote-testpy Add new simplified git-remote-testgit remote-testgit: get rid of non-local functionality remote-testgit: remove irrelevant test remote-testgit: cleanup tests remote-testgit: exercise more features remote-testgit: report success after an import remote-testgit: make clear the 'done' feature fast-export: trivial cleanup fast-export: fix comparison in tests fast-export: make sure updated refs get updated fast-export: don't handle uninteresting refs .gitignore | 2 +- Documentation/git-remote-testgit.txt | 2 +- Makefile | 2 +- builtin/fast-export.c| 20 ++- git-remote-testgit | 82 +++ git-remote-testgit.py| 272 --- git-remote-testpy.py | 272 +++ git_remote_helpers/git/importer.py | 2 +- t/t5800-remote-helpers.sh| 148 --- t/t5800-remote-testpy.sh | 148 +++ t/t5801-remote-helpers.sh| 153 t/t9350-fast-export.sh | 41 +- 12 files changed, 712 insertions(+), 432 deletions(-) create mode 100755 git-remote-testgit delete mode 100644 git-remote-testgit.py create mode 100644 git-remote-testpy.py delete mode 100755 t/t5800-remote-helpers.sh create mode 100755 t/t5800-remote-testpy.sh create mode 100644 t/t5801-remote-helpers.sh -- 1.8.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
[PATCH v4 01/14] fast-export: avoid importing blob marks
We want to be able to import, and then export, using the same marks, so that we don't push things that the other side already received. Unfortunately, fast-export doesn't store blobs in the marks, but fast-import does. This creates a mismatch when fast export is reusing a mark that were previously stored by fast-import. There is no point in one tool saving blobs, and the other not, but for now let's just check in fast-export that the objects are indeed commits. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- builtin/fast-export.c | 4 t/t9350-fast-export.sh | 14 ++ 2 files changed, 18 insertions(+) diff --git a/builtin/fast-export.c b/builtin/fast-export.c index 12220ad..a06fe10 100644 --- a/builtin/fast-export.c +++ b/builtin/fast-export.c @@ -614,6 +614,10 @@ static void import_marks(char *input_file) if (object-flags SHOWN) error(Object %s already has a mark, sha1_to_hex(sha1)); + if (object-type != 1) + /* only commits */ + continue; + mark_object(object, mark); if (last_idnum mark) last_idnum = mark; diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh index 3e821f9..0c8d828 100755 --- a/t/t9350-fast-export.sh +++ b/t/t9350-fast-export.sh @@ -440,4 +440,18 @@ test_expect_success 'fast-export quotes pathnames' ' ) ' +test_expect_success 'test biridectionality' ' + echo -n marks-cur + echo -n marks-new + git init marks-test + git fast-export --export-marks=marks-cur --import-marks=marks-cur --branches | \ + git --git-dir=marks-test/.git fast-import --export-marks=marks-new --import-marks=marks-new + (cd marks-test + git reset --hard + echo Wohlauf file + git commit -a -m back in time) + git --git-dir=marks-test/.git fast-export --export-marks=marks-new --import-marks=marks-new --branches | \ + git fast-import --export-marks=marks-cur --import-marks=marks-cur +' + test_done -- 1.8.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
[PATCH v4 02/14] remote-testgit: fix direction of marks
Basically this is what we want: == pull == testgit transport-helper * export - import # testgit.marks git.marks == push == testgit transport-helper * import- export # testgit.marks git.marks Each side should be agnostic of the other side. Because testgit.marks (our helper marks) could be anything, not necesarily a format parsable by fast-export or fast-import. In this test hey happen to be compatible, because we use those tools, but in the real world it would be something compelely different. For example, they might be mapping marks to mercurial revisions (certainly not parsable by fast-import/export). This is what we have: == pull == testgit transport-helper * export - import # testgit.marks git.marks == push == testgit transport-helper * import- export # git.marks testgit.marks The only reason this is working is that git.marks and testgit.marks are roughly the same. This new behavior used to not be possible before due to a bug in fast-export, but with the bug fixed, it works fine. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- git-remote-testgit.py | 2 +- git_remote_helpers/git/importer.py | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/git-remote-testgit.py b/git-remote-testgit.py index 5f3ebd2..ade797b 100644 --- a/git-remote-testgit.py +++ b/git-remote-testgit.py @@ -91,7 +91,7 @@ def do_capabilities(repo, args): if not os.path.exists(dirname): os.makedirs(dirname) -path = os.path.join(dirname, 'testgit.marks') +path = os.path.join(dirname, 'git.marks') print *export-marks %s % path if os.path.exists(path): diff --git a/git_remote_helpers/git/importer.py b/git_remote_helpers/git/importer.py index 5c6b595..e28cc8f 100644 --- a/git_remote_helpers/git/importer.py +++ b/git_remote_helpers/git/importer.py @@ -39,7 +39,7 @@ class GitImporter(object): gitdir = self.repo.gitpath else: gitdir = os.path.abspath(os.path.join(dirname, '.git')) -path = os.path.abspath(os.path.join(dirname, 'git.marks')) +path = os.path.abspath(os.path.join(dirname, 'testgit.marks')) if not os.path.exists(dirname): os.makedirs(dirname) -- 1.8.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
[PATCH v4 03/14] Rename git-remote-testgit to git-remote-testpy
This script is not really exercising the remote-helper functionality, but more the python framework for remote helpers that live in git_remote_helpers. It's also not a good example of how to write remote-helpers, unless you are planning to use python, and even then you might not want to use this framework. So let's use a more appropriate name: git-remote-testpy. A patch that replaces git-remote-testgit with a simpler version is on the way. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- .gitignore| 2 +- Makefile | 2 +- git-remote-testgit.py | 272 -- git-remote-testpy.py | 272 ++ t/t5800-remote-helpers.sh | 148 - t/t5800-remote-testpy.sh | 148 + 6 files changed, 422 insertions(+), 422 deletions(-) delete mode 100644 git-remote-testgit.py create mode 100644 git-remote-testpy.py delete mode 100755 t/t5800-remote-helpers.sh create mode 100755 t/t5800-remote-testpy.sh diff --git a/.gitignore b/.gitignore index a188a82..48d1bbb 100644 --- a/.gitignore +++ b/.gitignore @@ -124,7 +124,7 @@ /git-remote-ftps /git-remote-fd /git-remote-ext -/git-remote-testgit +/git-remote-testpy /git-repack /git-replace /git-repo-config diff --git a/Makefile b/Makefile index f69979e..e18ee48 100644 --- a/Makefile +++ b/Makefile @@ -470,7 +470,7 @@ SCRIPT_PERL += git-relink.perl SCRIPT_PERL += git-send-email.perl SCRIPT_PERL += git-svn.perl -SCRIPT_PYTHON += git-remote-testgit.py +SCRIPT_PYTHON += git-remote-testpy.py SCRIPT_PYTHON += git-p4.py SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \ diff --git a/git-remote-testgit.py b/git-remote-testgit.py deleted file mode 100644 index ade797b..000 --- a/git-remote-testgit.py +++ /dev/null @@ -1,272 +0,0 @@ -#!/usr/bin/env python - -# This command is a simple remote-helper, that is used both as a -# testcase for the remote-helper functionality, and as an example to -# show remote-helper authors one possible implementation. -# -# This is a Git - Git importer/exporter, that simply uses git -# fast-import and git fast-export to consume and produce fast-import -# streams. -# -# To understand better the way things work, one can activate debug -# traces by setting (to any value) the environment variables -# GIT_TRANSPORT_HELPER_DEBUG and GIT_DEBUG_TESTGIT, to see messages -# from the transport-helper side, or from this example remote-helper. - -# hashlib is only available in python = 2.5 -try: -import hashlib -_digest = hashlib.sha1 -except ImportError: -import sha -_digest = sha.new -import sys -import os -import time -sys.path.insert(0, os.getenv(GITPYTHONLIB,.)) - -from git_remote_helpers.util import die, debug, warn -from git_remote_helpers.git.repo import GitRepo -from git_remote_helpers.git.exporter import GitExporter -from git_remote_helpers.git.importer import GitImporter -from git_remote_helpers.git.non_local import NonLocalGit - -def get_repo(alias, url): -Returns a git repository object initialized for usage. - - -repo = GitRepo(url) -repo.get_revs() -repo.get_head() - -hasher = _digest() -hasher.update(repo.path) -repo.hash = hasher.hexdigest() - -repo.get_base_path = lambda base: os.path.join( -base, 'info', 'fast-import', repo.hash) - -prefix = 'refs/testgit/%s/' % alias -debug(prefix: '%s', prefix) - -repo.gitdir = os.environ[GIT_DIR] -repo.alias = alias -repo.prefix = prefix - -repo.exporter = GitExporter(repo) -repo.importer = GitImporter(repo) -repo.non_local = NonLocalGit(repo) - -return repo - - -def local_repo(repo, path): -Returns a git repository object initalized for usage. - - -local = GitRepo(path) - -local.non_local = None -local.gitdir = repo.gitdir -local.alias = repo.alias -local.prefix = repo.prefix -local.hash = repo.hash -local.get_base_path = repo.get_base_path -local.exporter = GitExporter(local) -local.importer = GitImporter(local) - -return local - - -def do_capabilities(repo, args): -Prints the supported capabilities. - - -print import -print export -print refspec refs/heads/*:%s* % repo.prefix - -dirname = repo.get_base_path(repo.gitdir) - -if not os.path.exists(dirname): -os.makedirs(dirname) - -path = os.path.join(dirname, 'git.marks') - -print *export-marks %s % path -if os.path.exists(path): -print *import-marks %s % path - -print # end capabilities - - -def do_list(repo, args): -Lists all known references. - -Bug: This will always set the remote head to master for non-local -repositories, since we have no way of determining what the remote -head is at clone time. - - -for ref in repo.revs: -debug(? refs/heads/%s, ref) -print ? refs/heads/%s % ref - -if repo.head: -
[PATCH v4 04/14] Add new simplified git-remote-testgit
It's way simpler. It exerceises the same features of remote helpers.
It's easy to read and understand. It doesn't depend on python.
It does _not_ exercise the python remote helper framework; there's
another tool and another test for that.
For now let's just copy the old remote-helpers test script, although
some of those tests don't make sense for this testgit (they still pass).
In addition, this script would be able to test other features not
currently being tested.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-remote-testgit.txt | 2 +-
git-remote-testgit | 62
t/t5801-remote-helpers.sh| 134 +++
3 files changed, 197 insertions(+), 1 deletion(-)
create mode 100755 git-remote-testgit
create mode 100755 t/t5801-remote-helpers.sh
diff --git a/Documentation/git-remote-testgit.txt
b/Documentation/git-remote-testgit.txt
index 2a67d45..612a625 100644
--- a/Documentation/git-remote-testgit.txt
+++ b/Documentation/git-remote-testgit.txt
@@ -19,7 +19,7 @@ testcase for the remote-helper functionality, and as an
example to
show remote-helper authors one possible implementation.
The best way to learn more is to read the comments and source code in
-'git-remote-testgit.py'.
+'git-remote-testgit'.
SEE ALSO
diff --git a/git-remote-testgit b/git-remote-testgit
new file mode 100755
index 000..6650402
--- /dev/null
+++ b/git-remote-testgit
@@ -0,0 +1,62 @@
+#!/bin/bash
+# Copyright (c) 2012 Felipe Contreras
+
+alias=$1
+url=$2
+
+# huh?
+url=${url#file://}
+
+dir=$GIT_DIR/testgit/$alias
+prefix=refs/testgit/$alias
+refspec=refs/heads/*:${prefix}/heads/*
+
+gitmarks=$dir/git.marks
+testgitmarks=$dir/testgit.marks
+
+export GIT_DIR=$url/.git
+
+mkdir -p $dir
+
+test -e $gitmarks || echo -n $gitmarks
+test -e $testgitmarks || echo -n $testgitmarks
+
+while read line; do
+case $line in
+capabilities)
+echo 'import'
+echo 'export'
+echo refspec $refspec
+echo *import-marks $gitmarks
+echo *export-marks $gitmarks
+echo
+;;
+list)
+git for-each-ref --format='? %(refname)' 'refs/heads/'
+head=$(git symbolic-ref HEAD)
+echo @$head HEAD
+echo
+;;
+import*)
+# read all import lines
+while true; do
+ref=${line#* }
+refs=$refs $ref
+read line
+test ${line%% *} != import break
+done
+
+echo feature import-marks=$gitmarks
+echo feature export-marks=$gitmarks
+git fast-export --use-done-feature
--{import,export}-marks=$testgitmarks $refs | \
+sed -e s#refs/heads/#${prefix}/heads/#g
+;;
+export)
+git fast-import --{import,export}-marks=$testgitmarks --quiet
+echo
+;;
+'')
+exit
+;;
+esac
+done
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
new file mode 100755
index 000..67bc8eb
--- /dev/null
+++ b/t/t5801-remote-helpers.sh
@@ -0,0 +1,134 @@
+#!/bin/sh
+#
+# Copyright (c) 2010 Sverre Rabbelier
+#
+
+test_description='Test remote-helper import and export commands'
+
+. ./test-lib.sh
+
+compare_refs() {
+ git --git-dir=$1/.git rev-parse --verify $2 expect
+ git --git-dir=$3/.git rev-parse --verify $4 actual
+ test_cmp expect actual
+}
+
+test_expect_success 'setup repository' '
+ git init --bare server/.git
+ git clone server public
+ (cd public
+echo content file
+git add file
+git commit -m one
+git push origin master)
+'
+
+test_expect_success 'cloning from local repo' '
+ git clone testgit::${PWD}/server localclone
+ test_cmp public/file localclone/file
+'
+
+test_expect_success 'cloning from remote repo' '
+ git clone testgit::file://${PWD}/server clone
+ test_cmp public/file clone/file
+'
+
+test_expect_success 'create new commit on remote' '
+ (cd public
+echo content file
+git commit -a -m two
+git push)
+'
+
+test_expect_success 'pulling from local repo' '
+ (cd localclone git pull)
+ test_cmp public/file localclone/file
+'
+
+test_expect_success 'pulling from remote remote' '
+ (cd clone git pull)
+ test_cmp public/file clone/file
+'
+
+test_expect_success 'pushing to local repo' '
+ (cd localclone
+ echo content file
+ git commit -a -m three
+ git push)
+ compare_refs localclone HEAD server HEAD
+'
+
+# Generally, skip this test. It demonstrates a now-fixed race in
+# git-remote-testgit, but is too slow to leave in for general use.
+: test_expect_success 'racily pushing to local repo' '
+ test_when_finished rm -rf server2 localclone2
+ cp -R server server2
+ git clone testgit::${PWD}/server2 localclone2
+ (cd localclone2
+ echo content file
+ git
[PATCH v4 06/14] remote-testgit: remove irrelevant test
Only makes sense for remote-testpy.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t5801-remote-helpers.sh | 13 -
1 file changed, 13 deletions(-)
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index 2eca42e..a03d087 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -48,19 +48,6 @@ test_expect_success 'pushing to local repo' '
compare_refs localclone HEAD server HEAD
'
-# Generally, skip this test. It demonstrates a now-fixed race in
-# git-remote-testgit, but is too slow to leave in for general use.
-: test_expect_success 'racily pushing to local repo' '
- test_when_finished rm -rf server2 localclone2
- cp -R server server2
- git clone testgit::${PWD}/server2 localclone2
- (cd localclone2
- echo content file
- git commit -a -m three
- GIT_REMOTE_TESTGIT_SLEEPY=2 git push)
- compare_refs localclone2 HEAD server2 HEAD
-'
-
test_expect_success 'fetch new branch' '
(cd public
git checkout -b new
--
1.8.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
[PATCH v4 07/14] remote-testgit: cleanup tests
We don't need a bare 'server' and an intermediary 'public'. The repos
can talk to each other directly; that's what we want to exercise.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t5801-remote-helpers.sh | 67 +++
1 file changed, 33 insertions(+), 34 deletions(-)
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index a03d087..3c4e09a 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -14,96 +14,95 @@ compare_refs() {
}
test_expect_success 'setup repository' '
- git init --bare server/.git
- git clone server public
- (cd public
+ git init server
+ (cd server
echo content file
git add file
-git commit -m one
-git push origin master)
+git commit -m one)
'
test_expect_success 'cloning from local repo' '
- git clone testgit::${PWD}/server localclone
- test_cmp public/file localclone/file
+ git clone testgit::${PWD}/server local
+ test_cmp server/file local/file
'
test_expect_success 'create new commit on remote' '
- (cd public
+ (cd server
echo content file
-git commit -a -m two
-git push)
+git commit -a -m two)
'
test_expect_success 'pulling from local repo' '
- (cd localclone git pull)
- test_cmp public/file localclone/file
+ (cd local git pull)
+ test_cmp server/file local/file
'
test_expect_success 'pushing to local repo' '
- (cd localclone
+ (cd local
echo content file
git commit -a -m three
git push)
- compare_refs localclone HEAD server HEAD
+ compare_refs local HEAD server HEAD
'
test_expect_success 'fetch new branch' '
- (cd public
+ (cd server
+git reset --hard
git checkout -b new
echo content file
-git commit -a -m five
-git push origin new
+git commit -a -m five
)
- (cd localclone
+ (cd local
git fetch origin new
)
- compare_refs public HEAD localclone FETCH_HEAD
+ compare_refs server HEAD local FETCH_HEAD
'
-test_expect_success 'bump commit in public' '
- (cd public
+#
+# This is only needed because of a bug not detected by this script. It will be
+# fixed shortly, but for now lets not cause regressions.
+#
+test_expect_success 'bump commit in server' '
+ (cd server
git checkout master
- git pull
echo content file
- git commit -a -m four
- git push)
- compare_refs public HEAD server HEAD
+ git commit -a -m four)
+ compare_refs server HEAD server HEAD
'
test_expect_success 'fetch multiple branches' '
- (cd localclone
+ (cd local
git fetch
)
- compare_refs server master localclone refs/remotes/origin/master
- compare_refs server new localclone refs/remotes/origin/new
+ compare_refs server master local refs/remotes/origin/master
+ compare_refs server new local refs/remotes/origin/new
'
test_expect_success 'push when remote has extra refs' '
- (cd localclone
+ (cd local
git reset --hard origin/master
echo content file
git commit -a -m six
git push
)
- compare_refs localclone master server master
+ compare_refs local master server master
'
test_expect_success 'push new branch by name' '
- (cd localclone
+ (cd local
git checkout -b new-name
echo content file
git commit -a -m seven
git push origin new-name
)
- compare_refs localclone HEAD server refs/heads/new-name
+ compare_refs local HEAD server refs/heads/new-name
'
test_expect_failure 'push new branch with old:new refspec' '
- (cd localclone
+ (cd local
git push origin new-name:new-refspec
)
- compare_refs localclone HEAD server refs/heads/new-refspec
+ compare_refs local HEAD server refs/heads/new-refspec
'
test_done
--
1.8.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
[PATCH v4 08/14] remote-testgit: exercise more features
Unfortunately they do not work.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-remote-testgit| 18 +
t/t5801-remote-helpers.sh | 49 +++
2 files changed, 63 insertions(+), 4 deletions(-)
mode change 100755 = 100644 t/t5801-remote-helpers.sh
diff --git a/git-remote-testgit b/git-remote-testgit
index b9810fd..6c348b0 100755
--- a/git-remote-testgit
+++ b/git-remote-testgit
@@ -6,24 +6,34 @@ url=$2
dir=$GIT_DIR/testgit/$alias
prefix=refs/testgit/$alias
-refspec=refs/heads/*:${prefix}/heads/*
+
+default_refspec=refs/heads/*:${prefix}/heads/*
+
+refspec=${GIT_REMOTE_TESTGIT_REFSPEC-$default_refspec}
gitmarks=$dir/git.marks
testgitmarks=$dir/testgit.marks
+test -z $refspec prefix=refs
+
export GIT_DIR=$url/.git
mkdir -p $dir
-test -e $gitmarks || echo -n $gitmarks
-test -e $testgitmarks || echo -n $testgitmarks
+if [ -z $GIT_REMOTE_TESTGIT_NO_MARKS ]; then
+test -e $gitmarks || echo -n $gitmarks
+test -e $testgitmarks || echo -n $testgitmarks
+else
+echo -n $gitmarks
+echo -n $testgitmarks
+fi
while read line; do
case $line in
capabilities)
echo 'import'
echo 'export'
-echo refspec $refspec
+test -n $refspec echo refspec $refspec
echo *import-marks $gitmarks
echo *export-marks $gitmarks
echo
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
old mode 100755
new mode 100644
index 3c4e09a..83561f8
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -105,4 +105,53 @@ test_expect_failure 'push new branch with old:new refspec'
'
compare_refs local HEAD server refs/heads/new-refspec
'
+test_expect_failure 'cloning without refspec' '
+ GIT_REMOTE_TESTGIT_REFSPEC= \
+ git clone testgit::${PWD}/server local2
+ compare_refs local2 HEAD server HEAD
+'
+
+test_expect_failure 'pulling without refspecs' '
+ (cd local2
+ git reset --hard
+ GIT_REMOTE_TESTGIT_REFSPEC= git pull)
+ compare_refs local2 HEAD server HEAD
+'
+
+test_expect_failure 'pushing without refspecs' '
+ (cd local2
+ echo content file
+ git commit -a -m three
+ GIT_REMOTE_TESTGIT_REFSPEC= git push)
+ compare_refs local2 HEAD server HEAD
+'
+
+test_expect_failure 'pulling with straight refspec' '
+ (cd local2
+ GIT_REMOTE_TESTGIT_REFSPEC=*:* git pull)
+ compare_refs local2 HEAD server HEAD
+'
+
+test_expect_failure 'pushing with straight refspec' '
+ (cd local2
+ echo content file
+ git commit -a -m three
+ GIT_REMOTE_TESTGIT_REFSPEC=*:* git push)
+ compare_refs local2 HEAD server HEAD
+'
+
+test_expect_failure 'pulling without marks' '
+ (cd local2
+ GIT_REMOTE_TESTGIT_NO_MARKS=1 git pull)
+ compare_refs local2 HEAD server HEAD
+'
+
+test_expect_failure 'pushing without marks' '
+ (cd local2
+ echo content file
+ git commit -a -m three
+ GIT_REMOTE_TESTGIT_NO_MARKS=1 git push)
+ compare_refs local2 HEAD server HEAD
+'
+
test_done
--
1.8.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
[PATCH v4 09/14] remote-testgit: report success after an import
Doesn't make a difference for the tests, but it does for the ones
seeking reference.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-remote-testgit | 11 +++
1 file changed, 11 insertions(+)
diff --git a/git-remote-testgit b/git-remote-testgit
index 6c348b0..4e8b356 100755
--- a/git-remote-testgit
+++ b/git-remote-testgit
@@ -59,7 +59,18 @@ while read line; do
sed -e s#refs/heads/#${prefix}/heads/#g
;;
export)
+declare -A before after
+
+eval $(git for-each-ref --format='before[%(refname)]=%(objectname)')
+
git fast-import --{import,export}-marks=$testgitmarks --quiet
+
+eval $(git for-each-ref --format='after[%(refname)]=%(objectname)')
+
+for ref in ${!after[@]}; do
+test ${before[$ref]} == ${after[$ref]} continue
+echo ok $ref
+done
echo
;;
'')
--
1.8.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
[PATCH v4 10/14] remote-testgit: make clear the 'done' feature
People seeking for reference would find it useful.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-remote-testgit | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/git-remote-testgit b/git-remote-testgit
index 4e8b356..1116587 100755
--- a/git-remote-testgit
+++ b/git-remote-testgit
@@ -55,8 +55,10 @@ while read line; do
echo feature import-marks=$gitmarks
echo feature export-marks=$gitmarks
-git fast-export --use-done-feature
--{import,export}-marks=$testgitmarks $refs | \
+echo feature done
+git fast-export --{import,export}-marks=$testgitmarks $refs | \
sed -e s#refs/heads/#${prefix}/heads/#g
+echo done
;;
export)
declare -A before after
--
1.8.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
[PATCH v4 12/14] fast-export: fix comparison in tests
First the expected, then the actual, otherwise the diff would be the opposite of what we want. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- t/t9350-fast-export.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh index 0c8d828..b7d3009 100755 --- a/t/t9350-fast-export.sh +++ b/t/t9350-fast-export.sh @@ -303,7 +303,7 @@ test_expect_success 'dropping tag of filtered out object' ' ( cd limit-by-paths git fast-export --tag-of-filtered-object=drop mytag -- there output - test_cmp output expected + test_cmp expected output ) ' @@ -320,7 +320,7 @@ test_expect_success 'rewriting tag of filtered out object' ' ( cd limit-by-paths git fast-export --tag-of-filtered-object=rewrite mytag -- there output - test_cmp output expected + test_cmp expected output ) ' @@ -351,7 +351,7 @@ test_expect_failure 'no exact-ref revisions included' ' ( cd limit-by-paths git fast-export master~2..master~1 output - test_cmp output expected + test_cmp expected output ) ' -- 1.8.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
[PATCH v4 13/14] fast-export: make sure updated refs get updated
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we can't know if a ref was exported or not, let's just assume that
if the commit was marked (flags SHOWN), the user still wants the ref
updated.
IOW: If it's specified in the command line, it will get updated,
regardless of wihether or not the object was marked.
So:
% git branch test master
% git fast-export $mark_flags master
% git fast-export $mark_flags test
Would export 'test' properly.
Additionally, this fixes issues with remote helpers; now they can push
refs wich objects have already been exported, and a few other issues as
well. So update the tests accordingly.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/fast-export.c | 10 +++---
t/t5801-remote-helpers.sh | 24 ++--
t/t9350-fast-export.sh| 15 +++
3 files changed, 32 insertions(+), 17 deletions(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 4f3c35f..26f6d1c 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -523,10 +523,14 @@ static void get_tags_and_duplicates(struct object_array
*pending,
typename(e-item-type));
continue;
}
- if (commit-util)
- /* more than one name for the same object */
+
+ /*
+* This ref will not be updated through a commit, lets make
+* sure it gets properly upddated eventually.
+*/
+ if (commit-util || commit-object.flags SHOWN)
string_list_append(extra_refs, full_name)-util =
commit;
- else
+ if (!commit-util)
commit-util = full_name;
}
}
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index 83561f8..6e4e078 100644
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -58,18 +58,6 @@ test_expect_success 'fetch new branch' '
compare_refs server HEAD local FETCH_HEAD
'
-#
-# This is only needed because of a bug not detected by this script. It will be
-# fixed shortly, but for now lets not cause regressions.
-#
-test_expect_success 'bump commit in server' '
- (cd server
- git checkout master
- echo content file
- git commit -a -m four)
- compare_refs server HEAD server HEAD
-'
-
test_expect_success 'fetch multiple branches' '
(cd local
git fetch
@@ -105,13 +93,13 @@ test_expect_failure 'push new branch with old:new refspec'
'
compare_refs local HEAD server refs/heads/new-refspec
'
-test_expect_failure 'cloning without refspec' '
+test_expect_success 'cloning without refspec' '
GIT_REMOTE_TESTGIT_REFSPEC= \
git clone testgit::${PWD}/server local2
compare_refs local2 HEAD server HEAD
'
-test_expect_failure 'pulling without refspecs' '
+test_expect_success 'pulling without refspecs' '
(cd local2
git reset --hard
GIT_REMOTE_TESTGIT_REFSPEC= git pull)
@@ -154,4 +142,12 @@ test_expect_failure 'pushing without marks' '
compare_refs local2 HEAD server HEAD
'
+test_expect_success 'push ref with existing object' '
+ (cd local
+ git branch dup master
+ git push origin dup
+ )
+ compare_refs local dup server dup
+'
+
test_done
diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh
index b7d3009..67a7372 100755
--- a/t/t9350-fast-export.sh
+++ b/t/t9350-fast-export.sh
@@ -454,4 +454,19 @@ test_expect_success 'test biridectionality' '
git fast-import --export-marks=marks-cur --import-marks=marks-cur
'
+cat expected EOF
+reset refs/heads/master
+from :12
+
+EOF
+
+test_expect_success 'refs are updated even if no commits need to be exported' '
+ echo -n tmp-marks
+ git fast-export --import-marks=tmp-marks \
+ --export-marks=tmp-marks master /dev/null
+ git fast-export --import-marks=tmp-marks \
+ --export-marks=tmp-marks master actual
+ test_cmp expected actual
+'
+
test_done
--
1.8.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
[PATCH v4 11/14] fast-export: trivial cleanup
Setting 'commit' to 'commit' is a no-op. It might have been there to
avoid a compiler warning, but if so, it was the compiler to blame, and
it's certainly not there any more.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/fast-export.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index a06fe10..4f3c35f 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -483,7 +483,7 @@ static void get_tags_and_duplicates(struct object_array
*pending,
for (i = 0; i pending-nr; i++) {
struct object_array_entry *e = pending-objects + i;
unsigned char sha1[20];
- struct commit *commit = commit;
+ struct commit *commit;
char *full_name;
if (dwim_ref(e-name, strlen(e-name), sha1, full_name) != 1)
--
1.8.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
[PATCH v4 14/14] fast-export: don't handle uninteresting refs
They have been marked as UNINTERESTING for a reason, lets respect that.
Currently the first ref is handled properly, but not the rest, so:
% git fast-export master ^master
Would currently throw a reset for master (2nd ref), which is not what we
want.
% git fast-export master ^foo ^bar ^roo
% git fast-export master salsa..tacos
Even if all these refs point to the same object; foo, bar, roo, salsa,
and tacos would all get a reset, and to a non-existing object (invalid
mark :0).
And even more, it would only happen if the ref is pointing to exactly
the same commit, but not otherwise:
% git fast-export ^next next
reset refs/heads/next
from :0
% git fast-export ^next next^{commit}
# nothing
% git fast-export ^next next~0
# nothing
% git fast-export ^next next~1
# nothing
% git fast-export ^next next~2
# nothing
The reason this happens is that before traversing the commits,
fast-export checks if any of the refs point to the same object, and any
duplicated ref gets added to a list in order to issue 'reset' commands
after the traversing. Unfortunately, it's not even checking if the
commit is flagged as UNINTERESTING. The fix of course, is to do
precisely that.
The current behavior is most certainly not what we want. After this patch,
nothing gets exported, because nothing was selected (everything is
UNINTERESTING).
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/fast-export.c | 4 +++-
t/t9350-fast-export.sh | 6 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 26f6d1c..7a310e4 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -529,7 +529,9 @@ static void get_tags_and_duplicates(struct object_array
*pending,
* sure it gets properly upddated eventually.
*/
if (commit-util || commit-object.flags SHOWN)
- string_list_append(extra_refs, full_name)-util =
commit;
+ if (!(commit-object.flags UNINTERESTING))
+ string_list_append(extra_refs, full_name)-util
= commit;
+
if (!commit-util)
commit-util = full_name;
}
diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh
index 67a7372..9b53ba7 100755
--- a/t/t9350-fast-export.sh
+++ b/t/t9350-fast-export.sh
@@ -469,4 +469,10 @@ test_expect_success 'refs are updated even if no commits
need to be exported' '
test_cmp expected actual
'
+test_expect_success 'proper extra refs handling' '
+ git fast-export master ^master master..master actual
+ echo -n expected
+ test_cmp expected actual
+'
+
test_done
--
1.8.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
