* [PATCH 1/3] git-remote-mediawiki: trivial fixes
From: Matthieu Moy @ 2011-09-27 17:54 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
Fix a whitespace issue (no space before :) and remove unused %status in
mw_push.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
contrib/mw-to-git/git-remote-mediawiki | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki b/contrib/mw-to-git/git-remote-mediawiki
index 0ba88de..768b42d 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -656,7 +656,7 @@ sub mw_push_file {
$mediawiki->{error}->{code} .
' from mediwiki: ' . $mediawiki->{error}->{details};
$newrevid = $result->{edit}->{newrevid};
- print STDERR "Pushed file : $new_sha1 - $title\n";
+ print STDERR "Pushed file: $new_sha1 - $title\n";
} else {
print STDERR "$complete_file_name not a mediawiki file (Not pushable on this version of git-remote-mediawiki).\n"
}
@@ -666,7 +666,6 @@ sub mw_push_file {
sub mw_push {
# multiple push statements can follow each other
my @refsspecs = (shift, get_more_refs("push"));
- my %status;
my $pushed;
for my $refspec (@refsspecs) {
my ($force, $local, $remote) = $refspec =~ /^(\+)?([^:]*):([^:]*)$/
--
1.7.7.rc0.75.g56f27
^ permalink raw reply related
* [PATCH 2/3] git-remote-mediawiki: set 'basetimestamp' to let the wiki handle conflicts
From: Matthieu Moy @ 2011-09-27 17:54 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1317146100-22938-1-git-send-email-Matthieu.Moy@imag.fr>
We already have a check that no new revisions are on the wiki at the
beginning of the push, but this didn't handle concurrent accesses to the
wiki.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
contrib/mw-to-git/git-remote-mediawiki | 43 +++++++++++++++++++++++++++----
1 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki b/contrib/mw-to-git/git-remote-mediawiki
index 768b42d..9bb58ab 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -287,6 +287,9 @@ sub get_last_local_revision {
return $lastrevision_number;
}
+# Remember the timestamp corresponding to a revision id.
+my %basetimestamps;
+
sub get_last_remote_revision {
mw_connect_maybe();
@@ -300,7 +303,7 @@ sub get_last_remote_revision {
my $query = {
action => 'query',
prop => 'revisions',
- rvprop => 'ids',
+ rvprop => 'ids|timestamp',
pageids => $id,
};
@@ -308,6 +311,8 @@ sub get_last_remote_revision {
my $lastrev = pop(@{$result->{query}->{pages}->{$id}->{revisions}});
+ $basetimestamps{$lastrev->{revid}} = $lastrev->{timestamp};
+
$max_rev_num = ($lastrev->{revid} > $max_rev_num ? $lastrev->{revid} : $max_rev_num);
}
@@ -649,18 +654,32 @@ sub mw_push_file {
action => 'edit',
summary => $summary,
title => $title,
+ basetimestamp => $basetimestamps{$newrevid},
text => mediawiki_clean($file_content, $page_created),
}, {
skip_encoding => 1 # Helps with names with accentuated characters
- }) || die 'Fatal: Error ' .
- $mediawiki->{error}->{code} .
- ' from mediwiki: ' . $mediawiki->{error}->{details};
+ });
+ if (!$result) {
+ if ($mediawiki->{error}->{code} == 3) {
+ # edit conflicts, considered as non-fast-forward
+ print STDERR 'Warning: Error ' .
+ $mediawiki->{error}->{code} .
+ ' from mediwiki: ' . $mediawiki->{error}->{details} .
+ ".\n";
+ return ($newrevid, "non-fast-forward");
+ } else {
+ # Other errors. Shouldn't happen => just die()
+ die 'Fatal: Error ' .
+ $mediawiki->{error}->{code} .
+ ' from mediwiki: ' . $mediawiki->{error}->{details};
+ }
+ }
$newrevid = $result->{edit}->{newrevid};
print STDERR "Pushed file: $new_sha1 - $title\n";
} else {
print STDERR "$complete_file_name not a mediawiki file (Not pushable on this version of git-remote-mediawiki).\n"
}
- return $newrevid;
+ return ($newrevid, "ok");
}
sub mw_push {
@@ -767,13 +786,25 @@ sub mw_push_revision {
chomp($commit_msg);
# Push every blob
while (@diff_info_list) {
+ my $status;
# git diff-tree -z gives an output like
# <metadata>\0<filename1>\0
# <metadata>\0<filename2>\0
# and we've split on \0.
my $info = shift(@diff_info_list);
my $file = shift(@diff_info_list);
- $mw_revision = mw_push_file($info, $file, $commit_msg, $mw_revision);
+ ($mw_revision, $status) = mw_push_file($info, $file, $commit_msg, $mw_revision);
+ if ($status eq "non-fast-forward") {
+ # we may already have sent part of the
+ # commit to MediaWiki, but it's too
+ # late to cancel it. Stop the push in
+ # the middle, but still give an
+ # accurate error message.
+ return error_non_fast_forward($remote);
+ }
+ if ($status ne "ok") {
+ die("Unknown error from mw_push_file()");
+ }
}
unless ($dumb_push) {
run_git("notes --ref=$remotename/mediawiki add -m \"mediawiki_revision: $mw_revision\" $sha1_commit");
--
1.7.7.rc0.75.g56f27
^ permalink raw reply related
* Re: [PATCH] gitweb: Add js=1 before an URI fragment to fix line number links
From: Junio C Hamano @ 2011-09-27 17:40 UTC (permalink / raw)
To: Peter Stuge; +Cc: Johannes Sixt, git
In-Reply-To: <20110927094947.10955.qmail@stuge.se>
Peter Stuge <peter@stuge.se> writes:
> I disagree, but I agree with you if we qualify that a little. The
> right balance is a matter of subjective review, so the only way it
> can be practiced with relevance is by actually working with the same
> reviewers for a while, to learn what they consider right.
>
> It can absolutely not be practiced out of context,...
You are right that you need to practice in the context of working in the
Git project to explain your change with the right amount of details when
preparing a change for the Git project, and the same goes for the openocd
project.
We aim to write our commit log messages primarily for future developers
who want to read "git log -p" output and understand why these changes had
to be made, to help them avoid intentionally breaking what the old commit
wanted to achieve when they want to modify the existing code 6 months down
the road. Your reviewers aim to make sure that your log message gives
sufficient information to such future developers, as opposed to themselves
while reviewing the patch and the issue is still fresh in their head.
I suspect that the target audience of log message may even be different
depending on the project, and openocd may not work that way, and that is
perfectly fine.
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Junio C Hamano @ 2011-09-27 17:25 UTC (permalink / raw)
To: Michael Witten; +Cc: Michael J Gruber, Carlos Martín Nieto, vra5107, git
In-Reply-To: <CAMOZ1BsvnZ7PyfjOJURX+B7vCZcYheLS4pissGvPNjEivbYXtw@mail.gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> It seems like a more logical approach would be instead for "git
> commit" to take a "--root" option that would create a new root commit
> based on the current index and then point the current branch head to
> the new root commit. Thus:
>
> $ git checkout -b new_branch old_branch
> $ # Manipulate or not
> $ git commit --root
>
> That's how people think.
This may indeed be an improvement. I suspect that we'd need to think about
it a bit more, but it feels right (perhaps introduce this new option,
deprecate --orphan from the checkout, and then eventually remove it
sometime in 1.8.0 timeframe).
>>> The index and the working tree are adjusted as if you had previously run
>>> "git checkout <start_point>". This allows you to start a new history
>>> -that records a set of paths similar to <start_point> by easily running
>>> +that records a set of paths similar to <start_point> by just running
>>> "git commit -a" to make the root commit.
>>
>> "similar" is an understatement here, maybe "as in"?
I do not think "as in" is an improvement. It completely ignores the
"Manipulate or not" part in the above, and "similar" was very much an
attempt to say "you do not have to commit it right away, but start from
the state and commit a deviation of it".
^ permalink raw reply
* Re: [PATCH] gitweb: Fix links to lines in blobs when javascript-actions are enabled
From: Junio C Hamano @ 2011-09-27 17:17 UTC (permalink / raw)
To: Peter Stuge; +Cc: git
In-Reply-To: <1317117060-3955-1-git-send-email-peter@stuge.se>
Peter Stuge <peter@stuge.se> writes:
> Some javascript code will run in the browser onLoad and signals back to
> gitweb that the browser can actually do javascript.
>
> The code adds [?;]js=1 into the URL of all links on the page. The code
> always added [?;]js=1 to the end of links, which is wrong when links
> contain a URI fragment, such as links directly to a line in a blob:
> ..?p=repo.git;a=blob;f=file#l123
>
> In this case, [?;]js=1 must be added before the hashmark.
>
> Signed-off-by: Peter Stuge <peter@stuge.se>
Nicely done. You forgot to mention another bug you fixed (see Jakub's
sample in the thread), so I'll amend in a few sentences to describe it as
well.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-27 17:09 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <vpq8vpa2agq.fsf@bauges.imag.fr>
On Tue, Sep 27, 2011 at 16:53, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> I think that the last paragraph provides enough context to understand
>> its usefulness.
>
> The last paragraph tells the user how to commit something different from
> what is already here, which is pretty much the opposite.
>
> IOW, I see two uses for --orphan:
>
> 1) Publish the same tree without its history
>
> 2) Start a different project, but for some reason you wanted it to leave
> in the same repository and you didn't want a "git init".
>
> The next paragraph documents 2), but your removed paragraph was
> documenting 1). Reading the new version, it feels like the user is
> encourraged to modify the index, while it's just an option.
Those 2 uses are not really different; both are manifestations of
creating a new root commit using some tree.
The way I see it, people would think:
1. I've got to get rid of this proprietary stuff
before I publish as open source.
2. I'll need a new root commit for the open source
stuff, too, otherwise it'll still be accessible.
3a. Aha! I can create a root commit based on the
proprietary stuff, but altered in any way that
I need.
3b. Aha! I've already got a cleaned commit, I can
just use that as the basis for the root commit
without further alteration.
In any case, removing history is probably better handled by
filter-branch or rebase, as I bet more often than not there are
existing descendants of the proposed root commit that need to be
played back anyway.
^ permalink raw reply
* Re: [PATCH] notes_merge_commit(): do not pass temporary buffer to other function
From: Junio C Hamano @ 2011-09-27 16:59 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Johan Herland
In-Reply-To: <1317098813-30839-1-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> I discovered this problem when an innocent modification to unrelated
> code triggered test failures.
>
> notes-merge.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git notes-merge.c notes-merge.c
> index e1aaf43..baaf31f 100644
> --- notes-merge.c
> +++ notes-merge.c
It is Ok to play with -p0 yourself but please don't do that in the public.
> @@ -680,7 +680,7 @@ int notes_merge_commit(struct notes_merge_options *o,
> * Finally store the new commit object SHA1 into 'result_sha1'.
> */
> struct dir_struct dir;
> - const char *path = git_path(NOTES_MERGE_WORKTREE "/");
> + char *path = xstrdup(git_path(NOTES_MERGE_WORKTREE "/"));
> int path_len = strlen(path), i;
> const char *msg = strstr(partial_commit->buffer, "\n\n");
>
> @@ -720,6 +720,7 @@ int notes_merge_commit(struct notes_merge_options *o,
> result_sha1);
> OUTPUT(o, 4, "Finalized notes merge commit: %s",
> sha1_to_hex(result_sha1));
> + free(path);
> return 0;
> }
^ permalink raw reply
* Re: [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref
From: Junio C Hamano @ 2011-09-27 16:56 UTC (permalink / raw)
To: Pang Yan Han
Cc: git, Sitaram Chamarty, Shawn O. Pearce, Jeff King,
Johannes Schindelin
In-Reply-To: <20110927090225.GA1493@myhost>
[offtopic: where does that annoying M-F-T header come from? It even seems
to be pointless in this case as it lists the same people as are already on
To/Cc/From of the message.]
Pang Yan Han <pangyanhan@gmail.com> writes:
> Should I reroll this patch with this behaviour:
>
> - Everything as usual for valid ref updates and deletes
> - For deleting corrupt (dangling?) ref, post-receive and post-update hooks
> also receive the same args as per valid update / delete
Suonds sensible.
> - For deleting non-existent refs:
> - post-receive shall have empty stdin for those refs
> - post-update shall have an empty arg for those refs
I do not think these hooks should see names of refs that ended up being a
no-op. If the push is only about attempting to delete a ref that did not
exist, these hooks should not even get called. If there were other refs
that got updated, these hooks have to be called, but they should not be
told about the no-op. IOW
$ git push $there :no-such-ref master:refs/remotes/origin/master
should:
(1) not call the post-* hooks if the refs/remotes/origin/master was
already pointing at the same commit; or
(2) invoke the post-* hooks if refs/remotes/origin/master is updated, but
should tell hooks only about the update of refs/remotes/origin/master.
That is pretty much in line with how a normal attempt to push the same
commit to an already up-to-date ref works. For example, if you:
$ git push $there master next
when 'master' is lagging and 'next' is already up-to-date, post-update and
post-receive hooks run and told only about 'master' and not 'next'.
^ permalink raw reply
* Re: [PATCH v2] Docs: git checkout --orphan: `root commit' and `branch head'
From: Matthieu Moy @ 2011-09-27 16:53 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <CAMOZ1Buf5KxbN59o8QK_dMmF_SEY_Ckuz4DALorZpwuL9gx-Pg@mail.gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> I think that the last paragraph provides enough context to understand
> its usefulness.
The last paragraph tells the user how to commit something different from
what is already here, which is pretty much the opposite.
IOW, I see two uses for --orphan:
1) Publish the same tree without its history
2) Start a different project, but for some reason you wanted it to leave
in the same repository and you didn't want a "git init".
The next paragraph documents 2), but your removed paragraph was
documenting 1). Reading the new version, it feels like the user is
encourraged to modify the index, while it's just an option.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: "Resetting" a repository
From: Randal L. Schwartz @ 2011-09-27 16:22 UTC (permalink / raw)
To: gitlist; +Cc: git
In-Reply-To: <4E81EAA7.5030708@myword.co.uk>
>>>>> "gitlist" == gitlist <gitlist@myword.co.uk> writes:
gitlist> I have a project with a test repository and a live repository (and a
gitlist> development repository).
You haven't mentioned what kind of access you have to the two repos.
Are they both bare remote repos? Or can you just rsync one over the
other?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
^ permalink raw reply
* Re: [PATCH v2] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-27 16:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <vpqsjni6kkk.fsf@bauges.imag.fr>
On Tue, Sep 27, 2011 at 16:01, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> -This can be useful when you want to publish the tree from a commit
>> -without exposing its full history. You might want to do this to publish
>> -an open source branch of a project whose current tree is "clean", but
>> -whose full history contains proprietary or otherwise encumbered bits of
>> -code.
>
> This part used to be just this in v1:
>
> -This can be useful when you want to publish the tree from a commit
> -without exposing its full history. You might want to do this to publish
> +This can be useful when you want to publish a tree without exposing its
> +full history; for instance, you might want to do this to publish
> an open source branch of a project whose current tree is "clean", but
> whose full history contains proprietary or otherwise encumbered bits of
> code.
>
> is it intentionnal that you discarded completely the paragraph? If so,
> then I disagree, the paragraph was one of the main motivation for
> someone to use --orphan, without it, someone may understand _what_ it
> does, but not _why_ it is useful.
It was intentional; I was finding it difficult to express that
paragraph succintly in a way that is consistent with correct
terminology. Then I realized it's fairly redundant, anyway.
I think that the last paragraph provides enough context to understand
its usefulness. Also, anybody who ever independently decided to carve
out proprietary bits in that way would immediately recognize the need
for creating a commit without parents, a notion which would lead him
or her pretty quickly to this documentation or jog his or her memory
about it based on the text of v2.
If everyone else is quite set on keeping that paragraph, though, I'll
take the challenge; however, I think that would be a waste of time.
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-27 16:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <4E81F080.7010905@drmicha.warpmail.net>
On Tue, Sep 27, 2011 at 15:49, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Michael Witten venit, vidit, dixit 27.09.2011 16:43:
>> See:
>>
>> Re: Can a git changeset be created with no parent
>> Carlos Martín Nieto <cmn@elego.de>
>> Message-ID: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
>> http://article.gmane.org/gmane.comp.version-control.git/182170
>>
>> and:
>>
>> git help glossary
>>
>> Signed-off-by: Michael Witten <mfwitten@gmail.com>
>> ---
>> Documentation/git-checkout.txt | 13 +++++--------
>> 1 files changed, 5 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
>> index c0a96e6..c963a0f 100644
>> --- a/Documentation/git-checkout.txt
>> +++ b/Documentation/git-checkout.txt
>> @@ -125,19 +125,16 @@ explicitly give a name with '-b' in such a case.
>> below for details.
>>
>> --orphan::
>> - Create a new 'orphan' branch, named <new_branch>, started from
>> - <start_point> and switch to it. The first commit made on this
>> - new branch will have no parents and it will be the root of a new
>> - history totally disconnected from all the other branches and
>> - commits.
>> + Tell git to make the next commit you make a root commit referenced by
>> + the branch head <new_branch>.
>
> I recall objecting to the name "--orphan" (to no avail) because the
> first commit is the root commit and there is no "orphan branch nor
> "parent branch"...
It seems like a more logical approach would be instead for "git
commit" to take a "--root" option that would create a new root commit
based on the current index and then point the current branch head to
the new root commit. Thus:
$ git checkout -b new_branch old_branch
$ # Manipulate or not
$ git commit --root
That's how people think.
> In any case, I think the above is indeed an improvement, but I would
> keep at least something which connects to the misnamed option, e.g.
>
> ...root commit (i.e. without parents) referenced by...
>
Agreed! See the new v2 patch:
http://article.gmane.org/gmane.comp.version-control.git/182245
>> +
>> The index and the working tree are adjusted as if you had previously run
>> "git checkout <start_point>". This allows you to start a new history
>> -that records a set of paths similar to <start_point> by easily running
>> +that records a set of paths similar to <start_point> by just running
>> "git commit -a" to make the root commit.
>
> "similar" is an understatement here, maybe "as in"?
Damn! I'll send a patch on top of v2.
>> +
>> -This can be useful when you want to publish the tree from a commit
>> -without exposing its full history. You might want to do this to publish
>> +This can be useful when you want to publish a tree without exposing its
>> +full history; for instance, you might want to do this to publish
>> an open source branch of a project whose current tree is "clean", but
>> whose full history contains proprietary or otherwise encumbered bits of
>> code.
>
> +1 ;)
Actually, in v2, I got rid of that entire paragraph, as it's redundant
and difficult to state succinctly AND consistently.
^ permalink raw reply
* Re: [PATCH v2] Docs: git checkout --orphan: `root commit' and `branch head'
From: Matthieu Moy @ 2011-09-27 16:01 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <69d6fb3199bc4f74b25dae7992a9f132-mfwitten@gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> -This can be useful when you want to publish the tree from a commit
> -without exposing its full history. You might want to do this to publish
> -an open source branch of a project whose current tree is "clean", but
> -whose full history contains proprietary or otherwise encumbered bits of
> -code.
This part used to be just this in v1:
-This can be useful when you want to publish the tree from a commit
-without exposing its full history. You might want to do this to publish
+This can be useful when you want to publish a tree without exposing its
+full history; for instance, you might want to do this to publish
an open source branch of a project whose current tree is "clean", but
whose full history contains proprietary or otherwise encumbered bits of
code.
is it intentionnal that you discarded completely the paragraph? If so,
then I disagree, the paragraph was one of the main motivation for
someone to use --orphan, without it, someone may understand _what_ it
does, but not _why_ it is useful.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH v2] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-27 15:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, Carlos Martín Nieto, vra5107, git
In-Reply-To: <vpq39fi9gf5.fsf@bauges.imag.fr>
See:
Re: Can a git changeset be created with no parent
Carlos Martín Nieto <cmn@elego.de>
Message-ID: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
http://article.gmane.org/gmane.comp.version-control.git/182170
and:
git help glossary
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
Documentation/git-checkout.txt | 32 ++++++++++++++++----------------
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index c0a96e6..68ae6c9 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -125,29 +125,22 @@ explicitly give a name with '-b' in such a case.
below for details.
--orphan::
- Create a new 'orphan' branch, named <new_branch>, started from
- <start_point> and switch to it. The first commit made on this
- new branch will have no parents and it will be the root of a new
- history totally disconnected from all the other branches and
- commits.
+ Tell git to make the next commit you create a root commit (that is,
+ a commit without any parent); creating the next commit is similar to
+ creating the first commit after running "git init", except that the
+ new commit will be referenced by the branch head <new_branch> rather
+ than "master".
+
-The index and the working tree are adjusted as if you had previously run
-"git checkout <start_point>". This allows you to start a new history
-that records a set of paths similar to <start_point> by easily running
-"git commit -a" to make the root commit.
+Furthermore, the index and the working tree are adjusted as if you ran
+"git checkout <start_point>"; by just running "git commit -a", you can
+create a root commit that records a tree similar to that of <start_point>.
+
-This can be useful when you want to publish the tree from a commit
-without exposing its full history. You might want to do this to publish
-an open source branch of a project whose current tree is "clean", but
-whose full history contains proprietary or otherwise encumbered bits of
-code.
-+
-If you want to start a disconnected history that records a set of paths
-that is totally different from the one of <start_point>, then you should
-clear the index and the working tree right after creating the orphan
-branch by running "git rm -rf ." from the top level of the working tree.
-Afterwards you will be ready to prepare your new files, repopulating the
-working tree, by copying them from elsewhere, extracting a tarball, etc.
+Naturally, before creating the commit, you may manipulate the index in any
+way you want. For example, if you want to create a root commit that records
+a tree that is totally different from the one of <start_point>, then just
+clear the working tree and index by running "git rm -rf ." from the top
+level of the working tree, after which you may prepare your new working
+tree and index as desired.
-m::
--merge::
--
1.7.6.409.ge7a85
^ permalink raw reply related
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael J Gruber @ 2011-09-27 15:49 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <e88b6e560cab4ed1937dd191b4180387-mfwitten@gmail.com>
Michael Witten venit, vidit, dixit 27.09.2011 16:43:
> See:
>
> Re: Can a git changeset be created with no parent
> Carlos Martín Nieto <cmn@elego.de>
> Message-ID: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
> http://article.gmane.org/gmane.comp.version-control.git/182170
>
> and:
>
> git help glossary
>
> Signed-off-by: Michael Witten <mfwitten@gmail.com>
> ---
> Documentation/git-checkout.txt | 13 +++++--------
> 1 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> index c0a96e6..c963a0f 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -125,19 +125,16 @@ explicitly give a name with '-b' in such a case.
> below for details.
>
> --orphan::
> - Create a new 'orphan' branch, named <new_branch>, started from
> - <start_point> and switch to it. The first commit made on this
> - new branch will have no parents and it will be the root of a new
> - history totally disconnected from all the other branches and
> - commits.
> + Tell git to make the next commit you make a root commit referenced by
> + the branch head <new_branch>.
I recall objecting to the name "--orphan" (to no avail) because the
first commit is the root commit and there is no "orphan branch nor
"parent branch"...
In any case, I think the above is indeed an improvement, but I would
keep at least something which connects to the misnamed option, e.g.
...root commit (i.e. without parents) referenced by...
> +
> The index and the working tree are adjusted as if you had previously run
> "git checkout <start_point>". This allows you to start a new history
> -that records a set of paths similar to <start_point> by easily running
> +that records a set of paths similar to <start_point> by just running
> "git commit -a" to make the root commit.
"similar" is an understatement here, maybe "as in"?
> +
> -This can be useful when you want to publish the tree from a commit
> -without exposing its full history. You might want to do this to publish
> +This can be useful when you want to publish a tree without exposing its
> +full history; for instance, you might want to do this to publish
> an open source branch of a project whose current tree is "clean", but
> whose full history contains proprietary or otherwise encumbered bits of
> code.
+1 ;)
Michael
^ permalink raw reply
* "Resetting" a repository
From: gitlist @ 2011-09-27 15:24 UTC (permalink / raw)
To: git
I have a project with a test repository and a live repository (and a
development repository).
Over time, the test repository has had merges which were in a quite
different order to the live repository, so it no longer fulfills its
role of being pretty much like the live repository and therefore a good
place to test. The two have diverged too far.
We've reached a point in the project when it would be good to reset the
test repository so that it is exactly the same as the live one. We can
then merge new work from the development repository.
I think that if I just merge the live repository into the test
respository it will not remove extra (non-conflicting) code. On this
occasion I want to remove all extra code and resolve all conflicts in
favour of the live repository version.
I'd appreciate advice on the best way to do this.
Thanks
Roddie Grant
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Matthieu Moy @ 2011-09-27 15:02 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <e88b6e560cab4ed1937dd191b4180387-mfwitten@gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> + Tell git to make the next commit you make a root commit
I'd even add
(just like the first commit after "git init")
at this point.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-27 14:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlos Martín Nieto, vra5107, git
In-Reply-To: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
See:
Re: Can a git changeset be created with no parent
Carlos Martín Nieto <cmn@elego.de>
Message-ID: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
http://article.gmane.org/gmane.comp.version-control.git/182170
and:
git help glossary
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
Documentation/git-checkout.txt | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index c0a96e6..c963a0f 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -125,19 +125,16 @@ explicitly give a name with '-b' in such a case.
below for details.
--orphan::
- Create a new 'orphan' branch, named <new_branch>, started from
- <start_point> and switch to it. The first commit made on this
- new branch will have no parents and it will be the root of a new
- history totally disconnected from all the other branches and
- commits.
+ Tell git to make the next commit you make a root commit referenced by
+ the branch head <new_branch>.
+
The index and the working tree are adjusted as if you had previously run
"git checkout <start_point>". This allows you to start a new history
-that records a set of paths similar to <start_point> by easily running
+that records a set of paths similar to <start_point> by just running
"git commit -a" to make the root commit.
+
-This can be useful when you want to publish the tree from a commit
-without exposing its full history. You might want to do this to publish
+This can be useful when you want to publish a tree without exposing its
+full history; for instance, you might want to do this to publish
an open source branch of a project whose current tree is "clean", but
whose full history contains proprietary or otherwise encumbered bits of
code.
--
1.7.6.409.ge7a85
^ permalink raw reply related
* Re: [PATCH] show git tag output in pager
From: Matthieu Moy @ 2011-09-27 14:19 UTC (permalink / raw)
To: Michal Vyskocil; +Cc: git
In-Reply-To: <20110927134235.GA27478@zelva.suse.cz>
The commit message should explain why this is needed, and in particular
why you prefer this to setting pager.tag in your ~/.gitconfig.
Michal Vyskocil <mvyskocil@suse.cz> writes:
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -147,6 +147,8 @@ static int list_tags(const char **patterns, int lines,
> struct commit_list *with_commit)
> {
> struct tag_filter filter;
> +
> + setup_pager();
Git indents with tabs, not spaces, and does not leave trailing
whitespaces.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] show git tag output in pager
From: Michal Vyskocil @ 2011-09-27 13:42 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
---
builtin/tag.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 667515e..9f70fa8 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -147,6 +147,8 @@ static int list_tags(const char **patterns, int lines,
struct commit_list *with_commit)
{
struct tag_filter filter;
+
+ setup_pager();
filter.patterns = patterns;
filter.lines = lines;
--
1.7.6.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [RFC/PATCHv2] git-p4: handle files with shell metacharacters
From: Pete Wyckoff @ 2011-09-27 13:03 UTC (permalink / raw)
To: Luke Diamand; +Cc: git, vitor.hda
In-Reply-To: <1317112836-14135-1-git-send-email-luke@diamand.org>
luke@diamand.org wrote on Tue, 27 Sep 2011 09:40 +0100:
> Updated git-p4 changes incorporating Pete's comments.
>
> - p4CmdList's stdin argument can now be a list.
I think this fits in with the rest of the patch and can stay.
> - Getting rid of the string option entirely is very hard; there are
> places where currently git-p4 creates a pipeline.
Yeah, thanks for checking though. Best to leave it consistent
like you did.
> - I wonder if verbose should actually be enabled for all the test
> cases?
It is way too verbose, even for test, but I see the argument.
One easy place to change it would be in the definition in
t/lib-git-p4.sh. You could do this by hand when testing the
tests perhaps.
> - The $ENV{PWD} is needed now because the shell used to set that; now
> that the shell isn't in use git-p4 has to set it.
>
> Pete - I wasn't sure whether you were saying I should rework
> my patch against next (and you would then rework your series) or
> something else. That sounds complicated though - let me know!
If you don't mind, I'll just queue it up with the utf16 and
test-refactor stuff I have, and send it all to Junio post-1.7.7.
Here's how I plan to adjust your tests, given the feedback that
Junio gave earlier and from reading other tests in t/.
-- Pete
-----------8<------------------
From 6b4bd671df338210ffd0348358420f0feb6f35c0 Mon Sep 17 00:00:00 2001
From: Pete Wyckoff <pw@padd.com>
Date: Tue, 27 Sep 2011 08:53:25 -0400
Subject: [PATCH] git-p4 t9803: align syntax with other tests
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9803-git-shell-metachars.sh | 30 ++++++++++++------------------
1 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/t/t9803-git-shell-metachars.sh b/t/t9803-git-shell-metachars.sh
index c166603..6cf4298 100755
--- a/t/t9803-git-shell-metachars.sh
+++ b/t/t9803-git-shell-metachars.sh
@@ -5,9 +5,7 @@ test_description='git-p4 transparency to shell metachars in filenames'
. ./lib-git-p4.sh
test_expect_success 'start p4d' '
- kill_p4d || : &&
- start_p4d &&
- cd "$TRASH_DIRECTORY"
+ start_p4d
'
test_expect_success 'init depot' '
@@ -30,25 +28,18 @@ test_expect_success 'shell metachars in filenames' '
echo f2 >"file with spaces" &&
git add "file with spaces" &&
P4EDITOR=touch git commit -m "add files" &&
- "$GITP4" submit --verbose &&
+ "$GITP4" submit
+ ) &&
+ (
cd "$cli" &&
p4 sync ... &&
- ls -l "file with spaces" &&
- ls -l "foo\$bar"
+ test -e "file with spaces" &&
+ test -e "foo\$bar"
)
'
-check_missing () {
- for i in $*; do
- if [ -f $i ]; then
- echo $i found but should be missing 1>&2
- exit 1
- fi
- done
-}
-
test_expect_success 'deleting with shell metachars' '
- "$GITP4" clone --dest="$git" --verbose //depot &&
+ "$GITP4" clone --dest="$git" //depot &&
test_when_finished cleanup_git &&
(
cd "$git" &&
@@ -56,10 +47,13 @@ test_expect_success 'deleting with shell metachars' '
git rm foo\$bar &&
git rm file\ with\ spaces &&
P4EDITOR=touch git commit -m "remove files" &&
- "$GITP4" submit --verbose
+ "$GITP4" submit
+ ) &&
+ (
cd "$cli" &&
p4 sync ... &&
- check_missing "file with spaces" foo\$bar
+ test ! -e "file with spaces" &&
+ test ! -e foo\$bar
)
'
--
1.7.6.3
^ permalink raw reply related
* Re: Git is not scalable with too many refs/*
From: Julian Phillips @ 2011-09-27 12:10 UTC (permalink / raw)
To: Michael Haggerty
Cc: Sverre Rabbelier, Martin Fick, git, Junio C Hamano,
David Michael Barr
In-Reply-To: <4E81AE63.8040008@alum.mit.edu>
[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]
On Tue, 27 Sep 2011 13:07:15 +0200, Michael Haggerty wrote:
> On 09/27/2011 11:01 AM, Julian Phillips wrote:
>> It has to be hot-cache, otherwise time taken to read the refs from
>> disk
>> will mean that it is always slow. On my Mac it seems to _always_ be
>> slow reading the refs from disk, so even the "fast" case still takes
>> ~17m.
>
> This case should be helped by lazy-loading of loose references, which
> I
> am working on. So if you develop some benchmarking code, it would
> help
> me with my work.
The attached script creates the repo structure I was testing with ...
If you create a repo with 100k refs it takes quite a while to read the
refs from disk. If you are lazy-loading then it should take practically
no time, since the only interesting ref is refs/heads/master.
The following is the hot-cache timing for "./refs-stress c 40000", with
the sorting patch applied (wasn't prepared to wait for numbers with 100k
refs).
jp3@rayne: refs>(cd c; time ~/misc/git/git/git branch)
* master
real 0m0.885s
user 0m0.161s
sys 0m0.722s
After doing "rm -rf c/.git/refs/changes/*", I get:
jp3@rayne: refs>(cd c; time ~/misc/git/git/git branch)
* master
real 0m0.004s
user 0m0.001s
sys 0m0.002s
--
Julian
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: refs-stress --]
[-- Type: text/x-java; name=refs-stress, Size: 1406 bytes --]
#!/usr/bin/env python
import os
import random
import subprocess
import sys
def die(msg):
print >> sys.stderr, msg
sys.exit(1)
def new_ref(a, b, commit):
d = ".git/refs/changes/%d/%d" % (a, b)
if not os.path.exists(d):
os.makedirs(d)
e = 1
p = "%s/%d" % (d, e)
while os.path.exists(p):
e += 1
p = "%s/%d" % (d, e)
f = open(p, "w")
f.write(commit)
f.close()
def make_refs(count, commit):
while count > 0:
sys.stdout.write("left: %d%s\r" % (count, " " * 30))
a = random.randrange(10, 30)
b = random.randrange(10000, 50000)
new_ref(a, b, commit)
count -= 1
print "refs complete"
def main():
if len(sys.argv) != 3:
die("usage: %s <name> <ref count>" % sys.argv[0])
_, name, refs = sys.argv
os.mkdir(name)
os.chdir(name)
if subprocess.call(["git", "init"]) != 0:
die("failed to init repo")
f = open("foobar.txt", "w")
f.write("%s: %s refs\n" % (name, refs))
f.close()
if subprocess.call(["git", "add", "foobar.txt"]) != 0:
die("failed to add foobar.txt")
if subprocess.call(["git", "commit", "-m", "inital commit"]) != 0:
die("failed to create initial commit")
commit = subprocess.check_output(["git", "show-ref", "-s", "master"]).strip()
make_refs(int(refs), commit)
if __name__ == "__main__":
main()
^ permalink raw reply
* [PATCH] templates/hooks--*: remove sample hooks without any functionality
From: Gerrit Pape @ 2011-09-27 11:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbou742eg.fsf@alter.siamese.dyndns.org>
Remove the sample post-commit and post-receive hooks. The sample
post-commit doesn't contain any sample functionality and the comments do
not provide more information than already found in the documentation.
The sample post-receive hooks doesn't provide any sample functionality
either and refers in the comments to a contrib hook that might be
installed in different locations on different systems, which isn't that
helpful.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
On Mon, Sep 26, 2011 at 10:52:23AM -0700, Junio C Hamano wrote:
> I removed the "-" lines above. Looking at the result, I really have to
> wonder if it makes much sense to keep the file here. It is not even an
> example anymore, and the user does not gain anything by enabling it,
> following the suggestion.
>
> Let's instead remove the file altogether, Ok?
Fine with me. As the same applies to the sample post-commit hook, I
made this patch to remove both of them.
Thanks for your patience, Gerrit.
templates/hooks--post-commit.sample | 8 --------
templates/hooks--post-receive.sample | 15 ---------------
2 files changed, 0 insertions(+), 23 deletions(-)
delete mode 100755 templates/hooks--post-commit.sample
delete mode 100755 templates/hooks--post-receive.sample
diff --git a/templates/hooks--post-commit.sample b/templates/hooks--post-commit.sample
deleted file mode 100755
index 2266821..0000000
--- a/templates/hooks--post-commit.sample
+++ /dev/null
@@ -1,8 +0,0 @@
-#!/bin/sh
-#
-# An example hook script that is called after a successful
-# commit is made.
-#
-# To enable this hook, rename this file to "post-commit".
-
-: Nothing
diff --git a/templates/hooks--post-receive.sample b/templates/hooks--post-receive.sample
deleted file mode 100755
index 7a83e17..0000000
--- a/templates/hooks--post-receive.sample
+++ /dev/null
@@ -1,15 +0,0 @@
-#!/bin/sh
-#
-# An example hook script for the "post-receive" event.
-#
-# The "post-receive" script is run after receive-pack has accepted a pack
-# and the repository has been updated. It is passed arguments in through
-# stdin in the form
-# <oldrev> <newrev> <refname>
-# For example:
-# aa453216d1b3e49e7f6f98441fa56946ddcd6a20 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master
-#
-# see contrib/hooks/ for a sample, or uncomment the next line and
-# rename the file to "post-receive".
-
-#. /usr/share/doc/git-core/contrib/hooks/post-receive-email
--
1.7.6.3
^ permalink raw reply related
* Re: Git is not scalable with too many refs/*
From: Michael Haggerty @ 2011-09-27 11:07 UTC (permalink / raw)
To: Julian Phillips
Cc: Sverre Rabbelier, Martin Fick, git, Junio C Hamano,
David Michael Barr
In-Reply-To: <22f055b34840e3c64f3339f7b3dc6920@quantumfyre.co.uk>
On 09/27/2011 11:01 AM, Julian Phillips wrote:
> It has to be hot-cache, otherwise time taken to read the refs from disk
> will mean that it is always slow. On my Mac it seems to _always_ be
> slow reading the refs from disk, so even the "fast" case still takes ~17m.
This case should be helped by lazy-loading of loose references, which I
am working on. So if you develop some benchmarking code, it would help
me with my work.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Nguyen Thai Ngoc Duy @ 2011-09-27 10:25 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Julian Phillips, Martin Fick, git, Junio C Hamano,
David Michael Barr
In-Reply-To: <CAGdFq_j2aa8bwxWuJvEsgA_1zkR4mMzoKjGs9TQVqw+0XYr98A@mail.gmail.com>
On Tue, Sep 27, 2011 at 8:01 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Tue, Sep 27, 2011 at 11:01, Julian Phillips <julian@quantumfyre.co.uk> wrote:
>> It has to be hot-cache, otherwise time taken to read the refs from disk will
>> mean that it is always slow. On my Mac it seems to _always_ be slow reading
>> the refs from disk, so even the "fast" case still takes ~17m.
>
> Ah, that seems unfortunate. Not sure how to test it then.
If you care about performance, a perf test suite could be made,
perhaps as a separate project. The output would be charts or
spreadsheets, that interesting parties can look at and point out
regressions. We may start with a set of common used operations.
--
Duy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox