* Re: [PATCH v3 4/4] fast-export: make sure refs are updated properly
From: Jeff King @ 2012-11-02 13:12 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Felipe Contreras, git, Junio C Hamano, Sverre Rabbelier,
Johannes Schindelin, Elijah Newren
In-Reply-To: <20121031003721.GV15167@elie.Belkin>
On Tue, Oct 30, 2012 at 05:37:21PM -0700, Jonathan Nieder wrote:
> If the commit does not have the SHOWN or UNINTERESTING flag set but it
> is going to get the UNINTERESTING flag set during the walk because of
> a negative commit listed on the command line, this patch won't help.
Right, so my understanding of the situation is that doing this:
$ git branch foo master~1
$ git fast-export foo master~1..master
won't show "foo", which seems wrong to me. _But_ we currently get that
wrong already, so Felipe's patches are not making anything worse, but
are fixing some situations (namely when master~1 is not mentioned on the
command-line, but rather in a marks file).
Is that correct?
If so, then this series isn't regressing behavior; the only downside is
that it's an incomplete fix. In theory this could get in the way of the
full fix later on, but given the commit messages and the archive of this
discussion, it would be simple enough to revert it later in favor of a
more full fix. Is that accurate?
Sorry if I am belaboring the discussion. I just want to make sure I
understand the situation before deciding what to do with the topic. It
sounds like the consensus at this point is "not perfect, but good enough
to make forward progress".
-Peff
^ permalink raw reply
* Re: Wishlist: git commit --no-edit
From: Jeff King @ 2012-11-02 12:45 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <CACnwZYe-za3Q0qvkfQ=qatB1-8eLUFA6ZzfS41yeqrV=8rVzGA@mail.gmail.com>
[+cc git@vger; please keep discussion on list]
On Fri, Nov 02, 2012 at 10:37:27AM -0200, Thiago Farina wrote:
> >> > git commit --amend --no-edit
> [...]
> > Yup, should be working since 1.7.9.
> [...]
> I doesn't appear in the help either:
>
> $ git version
> git version 1.8.0.rc2
>
> $ git commit -h 2>&1 | grep edit
> -c, --reedit-message <commit>
> reuse and edit message from specified commit
> -e, --edit force edit of commit
Yeah, parse_options doesn't advertise negative forms of boolean options,
as they are implied. I don't think it's a big deal, especially now that
it is covered in more detail in the manpage.
I think changing it would probably involve adding "--no-edit" as a
separate entry in the options struct.
-Peff
^ permalink raw reply
* [PATCH] commit: fixup misplacement of --no-post-rewrite description
From: Andreas Schwab @ 2012-11-02 12:26 UTC (permalink / raw)
To: git
In e858af6 (commit: document a couple of options) the description of the
--no-post-rewrite option was put inside the paragraph for the --amend
option. Move it down after the paragraph.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
Documentation/git-commit.txt | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 9594ac8..28a5aeb 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -193,10 +193,6 @@ OPTIONS
current tip -- if it was a merge, it will have the parents of
the current tip as parents -- so the current top commit is
discarded.
-
---no-post-rewrite::
- Bypass the post-rewrite hook.
-
+
--
It is a rough equivalent for:
@@ -213,6 +209,9 @@ You should understand the implications of rewriting history if you
amend a commit that has already been published. (See the "RECOVERING
FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
+--no-post-rewrite::
+ Bypass the post-rewrite hook.
+
-i::
--include::
Before making a commit out of staged contents so far,
--
1.8.0
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: [PATCH] Document 'git commit --no-edit' explicitly
From: Jeff King @ 2012-11-02 11:53 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, nisse
In-Reply-To: <1351852770-13897-1-git-send-email-Matthieu.Moy@imag.fr>
On Fri, Nov 02, 2012 at 11:39:30AM +0100, Matthieu Moy wrote:
> I was tempted to merge the paragraph with --edit::, but I thought this
> may add confusion. The use-cases for --edit and --no-edit are really
> different so I went for a separate paragraph, right below the --edit one.
Yeah, usually I think it would be better to keep the positive and
negative forms together, but the way you have done it does seem a lot
more clear to me. I think it is because the default flips based on other
options. So you would be stuck writing something like:
-e, --edit::
Edit the commit message using `$EDITOR`. This is the default
unless the `-F`, `-m`, or `-C` options are used; in those
cases, `-e` or `--edit` can be used to invoke the editor.
Likewise, `--no-edit` can be used to suppress the editor when
using an existing commit message. For example, `git commit
--amend --no-edit` amends a commit without changing its commit
message.
Your split reads much better, IMHO.
Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH] Document 'git commit --no-edit' explicitly
From: Matthieu Moy @ 2012-11-02 11:29 UTC (permalink / raw)
To: Niels Möller; +Cc: git, peff
In-Reply-To: <nnlieki6xs.fsf@stalhein.lysator.liu.se>
nisse@lysator.liu.se (Niels Möller) writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> +--no-edit::
>> + Use the selected commit message without launching an editor.
>> + For example, `git commit --amend --no-edit` amends a commit
>> + without changing its commit message.
>
> Looks clear enough to me. Thanks for fixing.
>
> Are -c --no-edit and -C really equivalent in all cases?
I guess so, but I didn't check.
> If so, maybe you want to say that in the documentation for -C.
I don't think we should target exhaustivity in the documentation, so I'm
not in favor of *adding* it. But maybe we should replace the doc with
stg like:
-c <commit>::
--reedit-message=<commit>::
Like '-C --edit'.
(it could even make sense to deprecate one of -C/-c)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Document 'git commit --no-edit' explicitly
From: Niels Möller @ 2012-11-02 11:24 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, peff
In-Reply-To: <1351852770-13897-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> +--no-edit::
> + Use the selected commit message without launching an editor.
> + For example, `git commit --amend --no-edit` amends a commit
> + without changing its commit message.
Looks clear enough to me. Thanks for fixing.
Are -c --no-edit and -C really equivalent in all cases? If so, maybe you
want to say that in the documentation for -C. (And if not, maybe they
*ought* to be equivalent).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Michael J Gruber @ 2012-11-02 11:03 UTC (permalink / raw)
To: Andreas Ericsson
Cc: René Scharfe, Felipe Contreras, Junio C Hamano,
Johannes Schindelin, Jonathan Nieder, Jeff King, git,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <5093949D.4070509@op5.se>
Andreas Ericsson venit, vidit, dixit 02.11.2012 10:38:
> On 11/01/2012 02:46 PM, René Scharfe 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.
>>
>
> It goes further back than that.
>
> "Suum cuique pulchrum est" ("To each his own is a beautiful thing") is
> a latin phrase said to be used frequently in the roman senate when
> senators politely agreed to disagree and let a vote decide the outcome
> rather than debating further.
>
> Please don't let the twisted views of whatever nazi idiot thought it
> meant "you may have the wrong faith and therefore deserve to die, so you
> shall" pollute it. The original meaning is both poetic and democratic,
> and I firmly believe most people have the original meaning to the fore
> of their mind when using it. After all, very few people knowingly quote
> nazi concentration camp slogans.
>
In fact, many German terms and words are "forbidden area" since Nazi
times, but I don't think this one carries the same connotation.
But that is a side track.
Collaboration (and code review is a form of collaboration) requires
communication. The linked code of conduct pages describe quite well how
to ensure a productive environment in which "everyone" feels comfortable
communicating and collaborating. But even reading pages like these
requires a common sense (of the many undefined terms therein), a sense
which is usually present here on the list, and thus renders a page like
these unnecessary for us. Once there is a lack of commonality, there is
a lack of agreement about those undefined terms (what constitutes a
personal attack etc.).
Consequently, the only practical test for commonality and community
acceptance appears to be just that: commonality and community
acceptance. If many people in a community consider a tone or formulation
offensive, then it is offensive by the very definition of common sense
(common to that community), and there's no point at all in arguing about
it. If I don't like a community's sense I either deal with it or leave it.
It's really not that different from coding style. If we prefer
if (cond) {
over
if (cond)
{
then you either do it that way or your code gets rejected. The
difference is that coding style is easier to define, of course. The
common thing is that there's no point in arguing about it.
Michael
^ permalink raw reply
* [PATCH] Document 'git commit --no-edit' explicitly
From: Matthieu Moy @ 2012-11-02 10:39 UTC (permalink / raw)
To: git; +Cc: peff, nisse, Matthieu Moy
In-Reply-To: <nnpq3wiaha.fsf@stalhein.lysator.liu.se>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
I was tempted to merge the paragraph with --edit::, but I thought this
may add confusion. The use-cases for --edit and --no-edit are really
different so I went for a separate paragraph, right below the --edit one.
Documentation/git-commit.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 3acf2e7..44b4347 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -188,6 +188,11 @@ OPTIONS
commit log message unmodified. This option lets you
further edit the message taken from these sources.
+--no-edit::
+ Use the selected commit message without launching an editor.
+ For example, `git commit --amend --no-edit` amends a commit
+ without changing its commit message.
+
--amend::
Used to amend the tip of the current branch. Prepare the tree
object you would want to replace the latest commit as usual
--
1.8.0.319.g8abfee4
^ permalink raw reply related
* Re: Wishlist: git commit --no-edit
From: Niels Möller @ 2012-11-02 10:07 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqfw4sgx33.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Err, isn't this already working? (maybe your version of Git is too old,
> but my 1.7.9.5 does this at least)
It may be that I'm confused.
It doesn't work in the version I have (1.7.2.5, debian packaged).
And then I also had a quick look in the source code (of a fresh pull
from https://github.com/git/git.git). In builtin/commit.c, I didn't see
any no-edit flag (but I maybe it's in the OPT_BOOL magic (which is
different from OPT_BOOLEAN?)).
And it's also not mentioned in Documentation/git-commit.txt or on
http://kernel.org/pub/software/scm/git/docs/git-commit.html.
If commit --no-edit does work in recent versions, then all is fine,
except possibly the documentation of it. Thanks.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
^ permalink raw reply
* Re: Overlong lines with git-merge --log
From: Jeff King @ 2012-11-02 10:05 UTC (permalink / raw)
To: Tim Janik; +Cc: git
In-Reply-To: <50932227.3090401@gnu.org>
On Fri, Nov 02, 2012 at 02:30:15AM +0100, Tim Janik wrote:
> 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.
The "subject" or "first line" is not actually the first line; these days
it is typically the "first paragraph". The reason is that git always
expected commit messages to look like:
one line describing the change
more detailed explanation
that might go on for several lines
or even several paragraphs
However, as people imported commits from previous systems, they ended up
with a lot of commit messages where the closest thing to a subject was
split across several lines like:
here's a description of the commit that is probably overly long,
but that's how we did it back in CVS days
Taking just the first line of those often cuts off the useful part. It
was deemed less bad to show the whole message as a subject rather than
cut it off arbitrarily.
If you are developing with git and not splitting the subject out with a
blank line, there are a lot of tools that are going to look ugly (e.g.,
format-patch will generate overly long subjects, "log --oneline" will be
ugly, and browsers like "tig" and "gitk" may be overwhelmed).
-Peff
^ permalink raw reply
* Re: Wishlist: git commit --no-edit
From: Jeff King @ 2012-11-02 9:59 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Niels Möller, git
In-Reply-To: <vpqfw4sgx33.fsf@grenoble-inp.fr>
On Fri, Nov 02, 2012 at 10:42:24AM +0100, Matthieu Moy wrote:
> nisse@lysator.liu.se (Niels Möller) writes:
>
> > I'd like to have a git commit option which is the opposite of --edit, to
> > use the selected commit message as is, without invoking any editor.
> >
> > Main use case I see would be
> >
> > git commit --amend --no-edit
>
> Err, isn't this already working? (maybe your version of Git is too old,
> but my 1.7.9.5 does this at least)
Yup, should be working since 1.7.9.
$ git tag --contains ':/commit: honour --no-edit' |
sort -V |
head -1
v1.7.9
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)
From: Jeff King @ 2012-11-02 9:56 UTC (permalink / raw)
To: Chris Rorvick; +Cc: Ramsay Jones, git
In-Reply-To: <20121102094259.GA28414@sigill.intra.peff.net>
On Fri, Nov 02, 2012 at 05:43:00AM -0400, Jeff King wrote:
> Yeah, I think that is it. IIRC, Ramsay is on cygwin, and I noticed this
> in perl 5.16's POSIX.xs:
>
> [...]
> * (4) The CRT strftime() "%Z" implementation calls __tzset(). That
> * calls CRT tzset(), but only the first time it is called, and in turn
> * that uses CRT getenv("TZ") to retrieve the timezone info from the CRT
> * local copy of the environment and hence gets the original setting as
> * perl never updates the CRT copy when assigning to $ENV{TZ}.
> [...]
> I wonder if Ramsay has an older perl that does not do this special
> hackery right. I'll see if I can dig up where it first appeared.
It looks like that code went into perl 5.11.
I wonder, even with this fix, though, if we need to be calling tzset to
reliably update from the environment. It sounds like it _should_ happen
automatically, except that if the CRT is calling the internal tzset, it
would not do the perl "grab from $ENV" magic. Calling tzset would make
sure the internal TZ is up to date.
Ramsay, what happens with this patch on top?
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index ceb119d..4c44050 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -24,11 +24,12 @@ use File::Basename qw(basename dirname);
use Time::Local;
use IO::Socket;
use IO::Pipe;
-use POSIX qw(strftime dup2 ENOENT);
+use POSIX qw(strftime tzset dup2 ENOENT);
use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
+tzset();
our ($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P, $opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r, $opt_R);
my (%conv_author_name, %conv_author_email, %conv_author_tz);
@@ -855,8 +856,10 @@ sub commit {
}
$ENV{'TZ'}=$author_tz;
+ tzset();
my $commit_date = strftime("%s %z", localtime($date));
$ENV{'TZ'}="UTC";
+ tzset();
$ENV{GIT_AUTHOR_NAME} = $author_name;
$ENV{GIT_AUTHOR_EMAIL} = $author_email;
$ENV{GIT_AUTHOR_DATE} = $commit_date;
^ permalink raw reply related
* Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)
From: Jeff King @ 2012-11-02 9:43 UTC (permalink / raw)
To: Chris Rorvick; +Cc: Ramsay Jones, git
In-Reply-To: <CAEUsAPb7hUViLn7V7v65r6mOqRHr+180ynRX8K9t3nuJVyePfg@mail.gmail.com>
On Thu, Nov 01, 2012 at 08:12:20PM -0500, Chris Rorvick wrote:
> > 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?
Yeah, I think that is it. IIRC, Ramsay is on cygwin, and I noticed this
in perl 5.16's POSIX.xs:
#ifdef WIN32
/*
* (1) The CRT maintains its own copy of the environment, separate from
* the Win32API copy.
*
* (2) CRT getenv() retrieves from this copy. CRT putenv() updates this
* copy, and then calls SetEnvironmentVariableA() to update the Win32API
* copy.
*
* (3) win32_getenv() and win32_putenv() call GetEnvironmentVariableA() and
* SetEnvironmentVariableA() directly, bypassing the CRT copy of the
* environment.
*
* (4) The CRT strftime() "%Z" implementation calls __tzset(). That
* calls CRT tzset(), but only the first time it is called, and in turn
* that uses CRT getenv("TZ") to retrieve the timezone info from the CRT
* local copy of the environment and hence gets the original setting as
* perl never updates the CRT copy when assigning to $ENV{TZ}.
*
* Therefore, we need to retrieve the value of $ENV{TZ} and call CRT
* putenv() to update the CRT copy of the environment (if it is different)
* whenever we're about to call tzset().
[...]
I wonder if Ramsay has an older perl that does not do this special
hackery right. I'll see if I can dig up where it first appeared.
-Peff
^ permalink raw reply
* Re: Wishlist: git commit --no-edit
From: Matthieu Moy @ 2012-11-02 9:42 UTC (permalink / raw)
To: Niels Möller; +Cc: git
In-Reply-To: <nntxt8ice9.fsf@stalhein.lysator.liu.se>
nisse@lysator.liu.se (Niels Möller) writes:
> I'd like to have a git commit option which is the opposite of --edit, to
> use the selected commit message as is, without invoking any editor.
>
> Main use case I see would be
>
> git commit --amend --no-edit
Err, isn't this already working? (maybe your version of Git is too old,
but my 1.7.9.5 does this at least)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Andreas Ericsson @ 2012-11-02 9:38 UTC (permalink / raw)
To: René Scharfe
Cc: Felipe Contreras, Junio C Hamano, Johannes Schindelin,
Jonathan Nieder, Jeff King, git, Michael J Gruber,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <50927D29.3020703@lsrfire.ath.cx>
On 11/01/2012 02:46 PM, René Scharfe 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.
>
It goes further back than that.
"Suum cuique pulchrum est" ("To each his own is a beautiful thing") is
a latin phrase said to be used frequently in the roman senate when
senators politely agreed to disagree and let a vote decide the outcome
rather than debating further.
Please don't let the twisted views of whatever nazi idiot thought it
meant "you may have the wrong faith and therefore deserve to die, so you
shall" pollute it. The original meaning is both poetic and democratic,
and I firmly believe most people have the original meaning to the fore
of their mind when using it. After all, very few people knowingly quote
nazi concentration camp slogans.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Wishlist: git commit --no-edit
From: Niels Möller @ 2012-11-02 9:26 UTC (permalink / raw)
To: git
I'd like to have a git commit option which is the opposite of --edit, to
use the selected commit message as is, without invoking any editor.
Main use case I see would be
git commit --amend --no-edit
(say you fix a typo in the previous commit which doesn't affect the
commit message). Today, one can get the same effect more clumsily as
EDITOR=touch git commit --amend
Or maybe as
git commit --amend -C HEAD
But I'd really prefer a --no-edit option over those alternatives. And it
might be useful also in combination with other options, e.g., it would
make the -C option equivalent to -c --no-edit, if I understand it
correctly.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
^ permalink raw reply
* [PATCH v4 14/14] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-02 2:02 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Elijah Newren,
Ilari Liusvaara, Sverre Rabbelier, Felipe Contreras
In-Reply-To: <1351821738-17526-1-git-send-email-felipe.contreras@gmail.com>
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.contreras@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
^ permalink raw reply related
* [PATCH v4 13/14] fast-export: make sure updated refs get updated
From: Felipe Contreras @ 2012-11-02 2:02 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Elijah Newren,
Ilari Liusvaara, Sverre Rabbelier, Felipe Contreras
In-Reply-To: <1351821738-17526-1-git-send-email-felipe.contreras@gmail.com>
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.contreras@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
^ permalink raw reply related
* [PATCH v4 12/14] fast-export: fix comparison in tests
From: Felipe Contreras @ 2012-11-02 2:02 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Elijah Newren,
Ilari Liusvaara, Sverre Rabbelier, Felipe Contreras
In-Reply-To: <1351821738-17526-1-git-send-email-felipe.contreras@gmail.com>
First the expected, then the actual, otherwise the diff would be the
opposite of what we want.
Signed-off-by: Felipe Contreras <felipe.contreras@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
^ permalink raw reply related
* [PATCH v4 11/14] fast-export: trivial cleanup
From: Felipe Contreras @ 2012-11-02 2:02 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Elijah Newren,
Ilari Liusvaara, Sverre Rabbelier, Felipe Contreras
In-Reply-To: <1351821738-17526-1-git-send-email-felipe.contreras@gmail.com>
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.contreras@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
^ permalink raw reply related
* [PATCH v4 10/14] remote-testgit: make clear the 'done' feature
From: Felipe Contreras @ 2012-11-02 2:02 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Elijah Newren,
Ilari Liusvaara, Sverre Rabbelier, Felipe Contreras
In-Reply-To: <1351821738-17526-1-git-send-email-felipe.contreras@gmail.com>
People seeking for reference would find it useful.
Signed-off-by: Felipe Contreras <felipe.contreras@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
^ permalink raw reply related
* [PATCH v4 09/14] remote-testgit: report success after an import
From: Felipe Contreras @ 2012-11-02 2:02 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Elijah Newren,
Ilari Liusvaara, Sverre Rabbelier, Felipe Contreras
In-Reply-To: <1351821738-17526-1-git-send-email-felipe.contreras@gmail.com>
Doesn't make a difference for the tests, but it does for the ones
seeking reference.
Signed-off-by: Felipe Contreras <felipe.contreras@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
^ permalink raw reply related
* [PATCH v4 07/14] remote-testgit: cleanup tests
From: Felipe Contreras @ 2012-11-02 2:02 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Elijah Newren,
Ilari Liusvaara, Sverre Rabbelier, Felipe Contreras
In-Reply-To: <1351821738-17526-1-git-send-email-felipe.contreras@gmail.com>
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.contreras@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
^ permalink raw reply related
* [PATCH v4 08/14] remote-testgit: exercise more features
From: Felipe Contreras @ 2012-11-02 2:02 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Elijah Newren,
Ilari Liusvaara, Sverre Rabbelier, Felipe Contreras
In-Reply-To: <1351821738-17526-1-git-send-email-felipe.contreras@gmail.com>
Unfortunately they do not work.
Signed-off-by: Felipe Contreras <felipe.contreras@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
^ permalink raw reply related
* [PATCH v4 06/14] remote-testgit: remove irrelevant test
From: Felipe Contreras @ 2012-11-02 2:02 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Elijah Newren,
Ilari Liusvaara, Sverre Rabbelier, Felipe Contreras
In-Reply-To: <1351821738-17526-1-git-send-email-felipe.contreras@gmail.com>
Only makes sense for remote-testpy.
Signed-off-by: Felipe Contreras <felipe.contreras@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
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox