* Re: problem with BOINC repository and CR/LF
From: Dmitry Potapov @ 2012-12-22 18:54 UTC (permalink / raw)
To: Toralf Förster
Cc: Jeff King, Torsten Bögershausen, Andrew Ardill,
git@vger.kernel.org
In-Reply-To: <50D5A81B.1000306@gmx.de>
On Sat, Dec 22, 2012 at 4:31 PM, Toralf Förster <toralf.foerster@gmx.de> wrote:
>
> /me still wonders whether this race condition is a feature or an issue
> in GIT - b/c it means that 2 different people cloning the same
> repository get different results.
The problem is that Git assumes that conversion from git to the worktree
and back produces the same result. Unfortunately, this assumption is not
enforced anywhere and when it is broken by editing .gitattributes, it may
be difficult to notice that immediately unless you do that trick with
removing the index and "git reset". Perhaps, it would be better if
git considered that timestamps on all files changed if .gitattributes
is changed, so it would check all files for consistence, then anyone
who edits .gitattributes will be forced to fix the file ending to be
consistent.
Anyway, when this underlying assumption is broken, it is easy to get
that race, because git checks only those files for modification that
have its timestamp equal or newer than the index. (The equal timestamp
are inspected for modification, because the timestamp resolution can
be 1 second on some systems.) When you check out some version, some
of files are going to have an older timestamp than the index (and thus
they are not inspected for modification) but those that have the same
timestamp as the index are inspected for modification.
Dmitry
^ permalink raw reply
* Re: [PATCH 3/3] Makefile: use -Wdeclaration-after-statement if supported
From: Junio C Hamano @ 2012-12-22 18:39 UTC (permalink / raw)
To: Adam Spiers; +Cc: git list
In-Reply-To: <CAOkDyE_+3n8PS_6vs-HG6v5A4SirBPVVCdgeUPOPpwaNpkk9Uw@mail.gmail.com>
Adam Spiers <git@adamspiers.org> writes:
> Fair enough, but let's not allow perfect to become the enemy of good.
That is why I would prefer a solution without any false positive
while allowing false negatives, i.e. not force everybody to use
these flags without giving a way to turn them off.
You could perhaps sell us a solution like this:
* Put these more strict options to CC_FLAGS_PEDANTIC (you may later
want to come up with LD_FLAGS_PEDANTIC and friends to make other
comands also more strict).
* Introduce PEDANTIC variable that turns XX_FLAGS_PEDANTIC
variables to less strict when set to 0 and more strict when set
to 1, similar to the way the variable V makes "make V=0" and
"make V=1" behave slightly differently.
Then we could introduce PEDANTIC=0 as default first to have people
try it out, with an expectation that later we can flip the default
to 'on' when the feature matures.
^ permalink raw reply
* [PATCH] Sort howto documents in howto-index.txt
From: Thomas Ackermann @ 2012-12-22 18:34 UTC (permalink / raw)
To: th.acker, git
Howto documents in howto-index.txt were listed in a rather
random order. So better sort them.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index d7417b8..ff8ad9a 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -348,7 +348,7 @@ $(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
$(QUIET_GEN)$(RM) $@+ $@ && \
- '$(SHELL_PATH_SQ)' ./howto-index.sh $(wildcard howto/*.txt) >$@+ && \
+ '$(SHELL_PATH_SQ)' ./howto-index.sh $(sort $(wildcard howto/*.txt)) >$@+ && \
mv $@+ $@
$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* Re: Pushing symbolic references to remote repositories?
From: Junio C Hamano @ 2012-12-22 18:27 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Dun Peal, Shawn Pearce, Git ML
In-Reply-To: <m2ehiiv3nb.fsf@linux-m68k.org>
Andreas Schwab <schwab@linux-m68k.org> writes:
> This is not limited to HEAD, any ref may want to be set up as a symref
> at a remote repo. For example, I want to set up a symref master ->
> trunk at a repository I have no shell access to.
That is exactly the "hosting side does not give you an easy way so
pushing seems to be one plausible but not necessarily has to be the
only way" case, so it is already covered in the discussion.
^ permalink raw reply
* Re: Right way to import a repo
From: Michael J Gruber @ 2012-12-22 17:57 UTC (permalink / raw)
To: Florian Lindner; +Cc: git
In-Reply-To: <1530104.jO5zzzN8PS@horus>
Florian Lindner venit, vidit, dixit 21.12.2012 17:11:
> Hello,
>
> I have two repositories. tools and flof. I want to merge flof into tools (and
> flof will be deleted after that) while keeping history intact. Of course I've
> googled that and found a number of different solution which all seem to be
> pretty komplex, so I just tried it myself. It seems to work.... are there any
> problems with my approach?
>
> ~/software/tools.test (git)-[master] % git remote add fl ~/flof
>
> ~/software/tools.test (git)-[master] % git fetch fl
> warning: no common commits
> remote: Counting objects: 475, done.
> remote: Compressing objects: 100% (460/460), done.
> remote: Total 475 (delta 251), reused 0 (delta 0)
> Receiving objects: 100% (475/475), 190.40 KiB, done.
> Resolving deltas: 100% (251/251), done.
> From /home/florian/flof
> * [new branch] master -> fl/master
> * [new branch] v2-rewrite -> fl/v2-rewrite
>
Two disjoint histories, nothing wrong with that.
> /software/tools.test (git)-[master] % git checkout -b import fl/master
> Branch import set up to track remote branch master from fl.
> Switched to a new branch 'import'
>
> Doing some mkdir und git mv for reorganisation.
Here avoid possible problems from both projects using the same root (in
the filesystem/tree sense).
> ~/software/tools.test/flof (git)-[import] % git commit -m "Reorganize flof."
> [import a00ab54] Reorganize flof.
> 152 files changed, 0 insertions(+), 0 deletions(-)
> rename {doc => flof/doc}/common.rst (100%)
> rename {doc => flof/doc}/conf.py (100%)
> [...]
>
> ~/software/tools.test/flof (git)-[import] % git checkout master
> Switched to branch 'master'
>
> ~/software/tools.test (git)-[master] % git merge import
> Auto-merging .gitignore
> CONFLICT (add/add): Merge conflict in .gitignore
> Automatic merge failed; fix conflicts and then commit the result.
>
> Resolving the conflict.
>
> ~/software/tools.test (git)-[master|merge] % git add .gitignore
>
> ~/software/tools.test (git)-[master|merge] % git commit -m "Merged flof."
> [master b8c85be] Merged flof.
>
> ~/software/tools.test (git)-[master] % git remote rm fl
>
> Are thery any problems with this procedure? The history seems to intact. I'm
> quite unsure since still being a git beginner.
It works in the sense that git follows the renames (moves) you had to do
prior to the merge.
Other tools like git-subtree do that history implanting in one step, by
putting the added project into a subtree (rewriting the history). That
way you don't have reorg commits in the history.
Michael
^ permalink raw reply
* cvsps, parsecvs, svn2git and the CVS exporter mess
From: Eric S. Raymond @ 2012-12-22 17:36 UTC (permalink / raw)
To: Yann Dirson, Michael Haggerty, Heiko Voigt, Antoine Pelisse,
Bart Massey, Keith Packard, David Mansfield, git
Wanting reposurgeon to be able to read CVS repositories has landed me
in the middle of a mess. This note explains my thinking, what I
intend to do to fix the mess, and how others can help if they are
motivated. I have copied all the individuals who I know have an
interest in the problem, and the git list because what I'm planning is
going to be significant for them.
My requirement is not complicated to describe. For use as a
reposurgeon front end I need a tool that is basically a
cvs-fast-export, runnable in either a CVS repository or a checkout
(either will do, both is not required) and emitting a fast-import
stream.
There are three competing tools that might fit this bill.
* One is Michael Haggerty's cvs2git. I had bad experiences with the
cvs2svn code it's derived from in the past, but Michael believes those
problems have been fixed and I will accept that - at least until I can
test for myself. Its documented interface is not quite good enough
yet; as the documentation says, "The data that should be fed to git
fast-import are written to two files, which have to be loaded into git
fast-import manually."
* Another is the cvsps code formerly maintained by David Mansfield and
used by git-cvsimport; he passed the maintainer's baton to me, and I
have shipped a 3.0 with a working --fast-export option.
* A third is parsecvs, which Keith Packard and Bart Massey handed off
to me a week before David invited me to take over cvsps. While
parsecvs does not yet have a --fast-export option, I anticipate no
great difficulty in adding one.
It is pure accident that I now maintain two of these. Initially I
was interested in parsecvs, but it failed to build for me. By the
time Bart Massey sent me a fix patch, I had already been handed
cvsps, added --fast-export, and shipped 3.0.
Having three different tools for this job seems to me duplicative and
pointless; two of them should probably be let die an honorable death.
I don't actually care which of the three survives - and, in
particular, if I determine that cvs2git is doing the best job of the
three I am quite willing to declare end-of-life for cvsps and
parsecvs. It's not like I don't have plenty of other projects to work
on.
Therefore, I think my main focus needs to be developing a really
effective test suite to triage these tools with and applying it to all
three. I have already made a solid start on this; see
tests/cvstest.py and tests/basic.tst in the cvsps-3.0 distribution for
my test framework.
I presently know of three test suites other than mine. One was built
by Heiko to test cvsps, another lives in the git t/ directory, and the
third is cvs2git's. I haven't looked at cv2git's yet, but the others
are not in their present form suited to where I am taking cvsps and
parsecvs. Heiko's relies on the default human-readable cvsps format,
which I consider obsolete and uninteresting. The git tests are
dependent on details of porcelain behavior. I think it would be
better to test import-stream output.
Here is what I propose. Let's build a common test suite that cvs2git,
git-cvsimport, cvsps, and parsecvs can all use, apply it rigorously,
and let the best tool win. (This would mean, among other things, that
git can stop carrying things that are essentially cvsps tests in its
tree.)
The two people I most need to sign off on this are, I guess, Michael
Haggerty and either Junio Hamano or whoever specifically owns
git-cvsimport and its tests. Whichever way this comes out, the back
end of git-cvsimport is going to need some work - I don't plan to put
any further effort into the output format it's presently using.
If we can agree on this, I'll start a public repo, and contribute my
Python framework - it's more capable than any of the shell harnesses
out there because it can easily drive interleaved operations on multiple
checkout directories.
Anybody who is still interested in this problem should contribute
tests. Heiko Voigt, I'd particularly like you in on this. David
Mansfield, if you can spare the few minutes required to write
generators for the "funky" and "invalid" tag cases, that would be
really helpful. Michael Haggerty, your piece would be moving the
cvs2git tests to the new framework.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
The kind of charity you can force out of people nourishes about as much as
the kind of love you can buy --- and spreads even nastier diseases.
^ permalink raw reply
* [PATCH 1/2] log: grep author/committer using mailmap
From: Antoine Pelisse @ 2012-12-22 16:58 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1356195512-4846-1-git-send-email-apelisse@gmail.com>
Currently mailmap can be used to display log authors and committers
but there no way to use mailmap to find commits with mapped values.
This commit allows those commands to work:
git log --use-mailmap --author mapped_name_or_email
git log --use-mailmap --committer mapped_name_or_email
Of course it only works if the --use-mailmap option is used.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
I probably missed something but I didn't find the connection with
commit 2d10c55. Let me know if I went the wrong direction.
revision.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++++
t/t4203-mailmap.sh | 18 ++++++++++++++++++
2 files changed, 71 insertions(+)
diff --git a/revision.c b/revision.c
index 95d21e6..fb9fd41 100644
--- a/revision.c
+++ b/revision.c
@@ -13,6 +13,7 @@
#include "decorate.h"
#include "log-tree.h"
#include "string-list.h"
+#include "mailmap.h"
volatile show_early_output_fn_t show_early_output;
@@ -2219,6 +2220,50 @@ static int rewrite_parents(struct rev_info *revs, struct commit *commit)
return 0;
}
+static int commit_rewrite_authors(struct strbuf *buf, const char *what, struct string_list *mailmap)
+{
+ char *author, *endp;
+ size_t len;
+ struct strbuf name = STRBUF_INIT;
+ struct strbuf mail = STRBUF_INIT;
+ struct ident_split ident;
+
+ author = strstr(buf->buf, what);
+ if (!author)
+ goto error;
+
+ author += strlen(what);
+ endp = strstr(author, "\n");
+ if (!endp)
+ goto error;
+
+ len = endp - author;
+
+ if (split_ident_line(&ident, author, len)) {
+ error:
+ strbuf_release(&name);
+ strbuf_release(&mail);
+
+ return 1;
+ }
+
+ strbuf_add(&name, ident.name_begin, ident.name_end - ident.name_begin);
+ strbuf_add(&mail, ident.mail_begin, ident.mail_end - ident.mail_begin);
+
+ map_user(mailmap, &mail, &name);
+
+ strbuf_addf(&name, " <%s>", mail.buf);
+
+ strbuf_splice(buf, ident.name_begin - buf->buf,
+ ident.mail_end - ident.name_begin + 1,
+ name.buf, name.len);
+
+ strbuf_release(&name);
+ strbuf_release(&mail);
+
+ return 0;
+}
+
static int commit_match(struct commit *commit, struct rev_info *opt)
{
int retval;
@@ -2237,6 +2282,14 @@ static int commit_match(struct commit *commit, struct rev_info *opt)
if (buf.len)
strbuf_addstr(&buf, commit->buffer);
+ if (opt->mailmap) {
+ if (!buf.len)
+ strbuf_addstr(&buf, commit->buffer);
+
+ commit_rewrite_authors(&buf, "\nauthor ", opt->mailmap);
+ commit_rewrite_authors(&buf, "\ncommitter ", opt->mailmap);
+ }
+
/* Append "fake" message parts as needed */
if (opt->show_notes) {
if (!buf.len)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index db043dc..e16187f 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -248,11 +248,29 @@ Author: Other Author <other@author.xx>
Author: Some Dude <some@dude.xx>
Author: A U Thor <author@example.com>
EOF
+
test_expect_success 'Log output with --use-mailmap' '
git log --use-mailmap | grep Author >actual &&
test_cmp expect actual
'
+cat >expect <<\EOF
+Author: Santa Claus <santa.claus@northpole.xx>
+Author: Santa Claus <santa.claus@northpole.xx>
+EOF
+
+test_expect_success 'Grep author with --use-mailmap' '
+ git log --use-mailmap --author Santa | grep Author >actual &&
+ test_cmp expect actual
+'
+
+>expect
+
+test_expect_success 'Only grep replaced author with --use-mailmap' '
+ git log --use-mailmap --author "<cto@coompany.xx>" >actual &&
+ test_cmp expect actual
+'
+
# git blame
cat >expect <<\EOF
^OBJI (A U Thor DATE 1) one
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] log: add log.mailmap configuration option
From: Antoine Pelisse @ 2012-12-22 16:58 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1356195512-4846-1-git-send-email-apelisse@gmail.com>
This patch provides a new configuration option 'log.mailmap' to
automatically use the --use-mailmap option from git-show, git-log and
git-whatchanged commands.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
I'm wondering if it would be needed to add a no-use-mailmap option to
log command so that it can cancel this configuration option.
Documentation/config.txt | 4 ++++
builtin/log.c | 8 +++++++-
t/t4203-mailmap.sh | 24 ++++++++++++++++++++++++
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bf8f911..226362a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1509,6 +1509,10 @@ log.showroot::
Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
normally hide the root commit will now show it. True by default.
+log.mailmap::
+ If true, makes linkgit:git-log[1], linkgit:git-show[1], and
+ linkgit:git-whatchanged[1] assume `--use-mailmap`.
+
mailmap.file::
The location of an augmenting mailmap file. The default
mailmap, located in the root of the repository, is loaded
diff --git a/builtin/log.c b/builtin/log.c
index d2bd8ce..f6936ff 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -31,6 +31,7 @@ static int default_abbrev_commit;
static int default_show_root = 1;
static int decoration_style;
static int decoration_given;
+static int use_mailmap;
static const char *fmt_patch_subject_prefix = "PATCH";
static const char *fmt_pretty;
@@ -138,7 +139,7 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix,
if (source)
rev->show_source = 1;
- if (mailmap) {
+ if (mailmap || use_mailmap) {
rev->mailmap = xcalloc(1, sizeof(struct string_list));
read_mailmap(rev->mailmap, NULL);
}
@@ -358,6 +359,11 @@ static int git_log_config(const char *var, const char *value, void *cb)
}
if (!prefixcmp(var, "color.decorate."))
return parse_decorate_color_config(var, 15, value);
+ if (!strcmp(var, "log.mailmap")) {
+ use_mailmap = git_config_bool(var, value);
+ return 0;
+ }
+
if (grep_config(var, value, cb) < 0)
return -1;
return git_diff_ui_config(var, value, cb);
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index e16187f..7d4d31c 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -255,6 +255,21 @@ test_expect_success 'Log output with --use-mailmap' '
'
cat >expect <<\EOF
+Author: CTO <cto@company.xx>
+Author: Santa Claus <santa.claus@northpole.xx>
+Author: Santa Claus <santa.claus@northpole.xx>
+Author: Other Author <other@author.xx>
+Author: Other Author <other@author.xx>
+Author: Some Dude <some@dude.xx>
+Author: A U Thor <author@example.com>
+EOF
+
+test_expect_success 'Log output with log.mailmap' '
+ git -c log.mailmap=True log | grep Author >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<\EOF
Author: Santa Claus <santa.claus@northpole.xx>
Author: Santa Claus <santa.claus@northpole.xx>
EOF
@@ -263,6 +278,15 @@ test_expect_success 'Grep author with --use-mailmap' '
git log --use-mailmap --author Santa | grep Author >actual &&
test_cmp expect actual
'
+cat >expect <<\EOF
+Author: Santa Claus <santa.claus@northpole.xx>
+Author: Santa Claus <santa.claus@northpole.xx>
+EOF
+
+test_expect_success 'Grep author with log.mailmap' '
+ git -c log.mailmap=True log --author Santa | grep Author >actual &&
+ test_cmp expect actual
+'
>expect
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] Mailmap in log improvements
From: Antoine Pelisse @ 2012-12-22 16:58 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
The goal of these patches are to:
- allow the use of mailmap when looking for commits
authored/committed by a mapped name/email.
- add an option so that --use-mailmap option can be used
automatically.
Tests are included.
This series is based on ap/log-mailmap.
Antoine Pelisse (2):
log: grep author/committer using mailmap
log: add log.mailmap configuration option
Documentation/config.txt | 4 ++++
builtin/log.c | 8 ++++++-
revision.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++
t/t4203-mailmap.sh | 42 ++++++++++++++++++++++++++++++++++++
4 files changed, 106 insertions(+), 1 deletion(-)
--
1.7.9.5
^ permalink raw reply
* Re: Opera release Git-splitter, a sub-modularizing tool for Git
From: Michael J Gruber @ 2012-12-22 16:41 UTC (permalink / raw)
To: Yngve Nysaeter Pettersen; +Cc: Matthieu Moy, git
In-Reply-To: <op.wpontloxvqd7e2@damia.oslo.osa>
Yngve Nysaeter Pettersen venit, vidit, dixit 21.12.2012 21:13:
> On Fri, 21 Dec 2012 16:49:21 +0100, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>
>> "Yngve Nysaeter Pettersen" <yngve@opera.com> writes:
>>
>>> The split command will create a new repository for all files foo in a
>>> folder (path/foo) and their commit history.
>>>
>>> The replant command reverses that process, re-adding the path prefix
>>> for each file. It may be possible to extend that process into one that
>>> automatically reintegrates the new commits in the original history,
>>> but I never had time to complete that work.
>>>
>>> I did originally add the "replant" functionality into my version of
>>> the git-subtree script, but given the number of commits in the
>>> original repository, git-subtree turned out to be inefficient, due to
>>> the use of temporary files (tens of thousands of files IIRC).
>>>
>>> Those problems led to my development of git-splitter in Python
>>> (bypassing the problem of temporary files), but just including the
>>> functionality I needed, join was not one of those functions.
>>
>> That still doesn't answer the question: why did you need to write a new
>> tool instead of extending git-subtree?
>
> The primary problem with git-subtree was that I ended up with a temporary
> file directory containing 100+K files, which I tracked back to being used
> to manage the commit-to-tree mapping. On Windows, at least, that literally
> slowed down the process to a crawl.
>
>> If one doesn't use "replant", is your tool different from git-subtree?
>
> No, it is not different. However, my tool will use RAM, not diskspace to
> manage information.
That is some valuable input. It can help improve git-subtree for Windows
users, or replace it by something else.
Michael
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Michael J Gruber @ 2012-12-22 16:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Yann Dirson, Andreas Schwab, Christian Couder,
git list, Jeff King
In-Reply-To: <7vzk171gvh.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 21.12.2012 17:58:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> While replace refs are much more general than grafts, it seems the two
>> main uses are:
>>
>> - grafts (change the recorded parents for a commit)
>> - svn cleanup (convert tagging commits into tag objects)
>>
>> The latter one being quite a special case already.
>>
>> The script below has helped me move from grafts to replace objects.
>> While not being super clean, something like it may be fit for contrib.
>>
>> I think we ought to help John Doe get along with parents, while we can
>> safely leave most more advanced operations to people who know how to
>> edit a raw object file. Putting that facility into "git-commit" seems to
>> be too encouraging, though - people would use replace when they should
>> use amend or rebase-i. I'd prefer a special git-replace mode (be it
>> "--graft" or "--graft-commit") which does just what my script does. We
>> could add things like "--commit-tag" later, a full blown
>> "object-factory" seems like overkill.
>>
>> Michael
>>
>> --->%---
>>
>> #!/bin/sh
>>
>> die () {
>> echo "$@"
>> rm -f "$commitfile"
>> exit 1
>> }
>>
>> warn () {
>> echo "$@"
>> }
>>
>> test $# -gt 0 || die "Usage: $0 <commit> [<parent>]*"
>>
>> for commit
>> do
>> git rev-parse --verify -q "$commit" >/dev/null || die "Cannot parse
>> $commit."
>> test x$(git cat-file -t $commit) == "xcommit" || die "$commit is no
>> commit."
>
> s/==/=/ or you have to say #!/bin/bash on the first line, I think.
> Appears multiple times throughout this script.
>
>
>> done
>>
>> commit="$1"
>> shift
>>
>> commitfile=$(mktemp)
>>
>> git cat-file commit "$commit" | while read a b
>> do
>> if test "$a" != "parent"
>> then
>> echo $a $b
>
> You are losing information on non-header lines by reading without
> "-r" in the above, and also multi-line headers (e.g. mergetag),
> aren't you?
>
Oh yes, it has bashisms and imperfections. It's not a submitted patch,
not even RFC. It's meant to show the git-replace mode that many users
could benefit from: works for commits only and replaces the parent list,
but takes any rev arguments as the new parents, rather than forcing the
user to specify a full sha1.
>> fi
>> if test "$a" == "tree"
>> then
>> for parent
>> do
>> echo "parent $(git rev-parse $parent)"
>> done
>> fi
>> done >$commitfile
>> hash=$(git hash-object -t commit -w "$commitfile") || die "Cannot create
>> commit object."
>> git replace "$commit" $hash
>> rm -f $commitfile
^ permalink raw reply
* Re: Change in cvsps maintainership, abd a --fast-export option
From: Andreas Schwab @ 2012-12-22 16:25 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: esr, Heiko Voigt, Michael Haggerty, git
In-Reply-To: <CALWbr2zZFq_9qa+pTx3nYn+KFv61LrSMcNM4N1Xs5cmnr8teXg@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> I guess 'w' means write
No, 'w' mean gitweb.
Andreas.
--
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
* [PATCH] git-subtree: fix typo in manpage
From: Michael Schubert @ 2012-12-22 14:46 UTC (permalink / raw)
To: git
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
---
contrib/subtree/git-subtree.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
index 0c44fda..c5bce41 100644
--- a/contrib/subtree/git-subtree.txt
+++ b/contrib/subtree/git-subtree.txt
@@ -93,7 +93,7 @@ pull::
repository.
push::
- Does a 'split' (see above) using the <prefix> supplied
+ Does a 'split' (see below) using the <prefix> supplied
and then does a 'git push' to push the result to the
repository and refspec. This can be used to push your
subtree to different branches of the remote repository.
--
1.8.1.rc2.333.g912e06f.dirty
^ permalink raw reply related
* [PATCH] git-subtree: ignore git-subtree executable
From: Michael Schubert @ 2012-12-22 14:45 UTC (permalink / raw)
To: git
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
---
contrib/subtree/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/subtree/.gitignore b/contrib/subtree/.gitignore
index 7e77c9d..91360a3 100644
--- a/contrib/subtree/.gitignore
+++ b/contrib/subtree/.gitignore
@@ -1,4 +1,5 @@
*~
+git-subtree
git-subtree.xml
git-subtree.1
mainline
--
1.8.1.rc2.333.g912e06f.dirty
^ permalink raw reply related
* Re: Change in cvsps maintainership, abd a --fast-export option
From: Andreas Schwab @ 2012-12-22 14:21 UTC (permalink / raw)
To: esr; +Cc: Heiko Voigt, Michael Haggerty, git
In-Reply-To: <20121222140453.GB375@thyrsus.com>
"Eric S. Raymond" <esr@thyrsus.com> writes:
> esr@snark:~/WWW/cvsps/fixrepos$ git clone http://repo.or.cz/w/cvsps-hv.git
>From <http://repo.or.cz/w/cvsps-hv.git>:
URL git://repo.or.cz/cvsps-hv.git
http://repo.or.cz/r/cvsps-hv.git
Andreas.
--
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
* Re: Re: Change in cvsps maintainership, abd a --fast-export option
From: Antoine Pelisse @ 2012-12-22 14:10 UTC (permalink / raw)
To: esr; +Cc: Heiko Voigt, Michael Haggerty, git
In-Reply-To: <20121222140453.GB375@thyrsus.com>
> esr@snark:~/WWW/cvsps/fixrepos$ git clone http://repo.or.cz/w/cvsps-hv.git
> Cloning into 'cvsps-hv'...
> fatal: http://repo.or.cz/w/cvsps-hv.git/info/refs not valid: is this a git repository?
I guess 'w' means write, and you don't have write access. You should use
http://repo.or.cz/r/cvsps-hv.git
instead. It works for me.
^ permalink raw reply
* Re: Re: Change in cvsps maintainership, abd a --fast-export option
From: Eric S. Raymond @ 2012-12-22 14:17 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Heiko Voigt, Michael Haggerty, git
In-Reply-To: <CALWbr2zZFq_9qa+pTx3nYn+KFv61LrSMcNM4N1Xs5cmnr8teXg@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com>:
> > esr@snark:~/WWW/cvsps/fixrepos$ git clone http://repo.or.cz/w/cvsps-hv.git
> > Cloning into 'cvsps-hv'...
> > fatal: http://repo.or.cz/w/cvsps-hv.git/info/refs not valid: is this a git repository?
>
> I guess 'w' means write, and you don't have write access. You should use
>
> http://repo.or.cz/r/cvsps-hv.git
>
> instead. It works for me.
OK, that got it. Looking at the tests now.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Re: Re: Change in cvsps maintainership, abd a --fast-export option
From: Eric S. Raymond @ 2012-12-22 14:15 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Michael Haggerty, git
In-Reply-To: <20121222130452.GB13549@book-mint>
Heiko Voigt <hvoigt@hvoigt.net>:
> Hi,
>
> On Sat, Dec 22, 2012 at 01:21:18AM -0500, Eric S. Raymond wrote:
> > Heiko Voigt <hvoigt@hvoigt.net>:
> > > Back then when I was converting some repositories to git and I also
> > > wrote a quick testsuite for cvsps in an attempt to fix the bugs but gave
> > > up. That was the point when I wrote about cvsimports limitations in the
> > > documentation.
> > >
> > > My commits can be found here:
> > >
> > > http://repo.or.cz/w/cvsps-hv.git
> > >
> > > I just quickly checked and it seems that it does not run cleanly on a
> > > modern Linux anymore. If it is of interest to you I can try to get it
> > > running again.
> >
> > That would be helpful. Please give it some effort.
>
> Here you go. I have pushed my changes on the master branch there.
>
> You should now be able to run my tests with
>
> make test
>
> from the root directory of the repository. The expected and actual
> output can be found in the t[0-9]{4}... directories underneath t/.
>
> Cheers Heiko
sr@snark:~/WWW/cvsps/fixrepos$ git clone http://repo.or.cz/w/cvsps-hv.git
Cloning into 'cvsps-hv'...
fatal: http://repo.or.cz/w/cvsps-hv.git/info/refs not valid: is this a git repository?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Re: Change in cvsps maintainership, abd a --fast-export option
From: Eric S. Raymond @ 2012-12-22 14:04 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Michael Haggerty, git
In-Reply-To: <20121222034751.GA11635@book-mint>
Heiko Voigt <hvoigt@hvoigt.net>:
> My commits can be found here:
>
> http://repo.or.cz/w/cvsps-hv.git
>
> I just quickly checked and it seems that it does not run cleanly on a
> modern Linux anymore. If it is of interest to you I can try to get it
> running again.
esr@snark:~/WWW/cvsps/fixrepos$ git clone http://repo.or.cz/w/cvsps-hv.git
Cloning into 'cvsps-hv'...
fatal: http://repo.or.cz/w/cvsps-hv.git/info/refs not valid: is this a git repository?
Doesn't seem to be a good day for cloning - I can't get Yann's repo either,
something about HEAD pointing to an invalid reference.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Re: Re: Change in cvsps maintainership, abd a --fast-export option
From: Heiko Voigt @ 2012-12-22 13:04 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: Michael Haggerty, git
In-Reply-To: <20121222062118.GA31331@thyrsus.com>
Hi,
On Sat, Dec 22, 2012 at 01:21:18AM -0500, Eric S. Raymond wrote:
> Heiko Voigt <hvoigt@hvoigt.net>:
> > Back then when I was converting some repositories to git and I also
> > wrote a quick testsuite for cvsps in an attempt to fix the bugs but gave
> > up. That was the point when I wrote about cvsimports limitations in the
> > documentation.
> >
> > My commits can be found here:
> >
> > http://repo.or.cz/w/cvsps-hv.git
> >
> > I just quickly checked and it seems that it does not run cleanly on a
> > modern Linux anymore. If it is of interest to you I can try to get it
> > running again.
>
> That would be helpful. Please give it some effort.
Here you go. I have pushed my changes on the master branch there.
You should now be able to run my tests with
make test
from the root directory of the repository. The expected and actual
output can be found in the t[0-9]{4}... directories underneath t/.
Cheers Heiko
^ permalink raw reply
* Re: problem with BOINC repository and CR/LF
From: Toralf Förster @ 2012-12-22 12:31 UTC (permalink / raw)
To: Jeff King; +Cc: Torsten Bögershausen, Andrew Ardill, git@vger.kernel.org
In-Reply-To: <20121218164132.GC20122@sigill.intra.peff.net>
On 12/18/2012 05:41 PM, Jeff King wrote:
> I could reproduce it, too, on Linux.
>
> The reason it does not always happen is that git will not re-examine the
> file content unless the timestamp on the file is older than what's in
> the index. So it is a race condition for git to see whether the file is
> stat-dirty.
/me still wonders whether this race condition is a feature or an issue
in GIT - b/c it means that 2 different people cloning the same
repository get different results.
>
> -Peff
>
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply
* Re: [PATCH 3/3] Makefile: use -Wdeclaration-after-statement if supported
From: Adam Spiers @ 2012-12-22 12:25 UTC (permalink / raw)
To: git list
In-Reply-To: <7v8v8xpazq.fsf@alter.siamese.dyndns.org>
On Mon, Dec 17, 2012 at 4:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Adam Spiers <git@adamspiers.org> writes:
>
>> OK; I expect these issues with the implementation are all
>> surmountable. I did not necessarily expect this to be the final
>> implementation anyhow, as indicated by my comments below the divider
>> line. However it's not clear to me what you think about the idea in
>> principle, and whether other compiler flags would merit inclusion.
>
> As different versions of GCC behave differently, and the same GCC
> (mis)detect issues differently depending on the optimization level,
> I do not know if it will be a fruitful exercise to try to come up
> with one expression to come up with the set of flags to suit
> everybody.
Fair enough, but let's not allow perfect to become the enemy of good.
Other flags aside, surely enabling -Wdeclaration-after-statement when
it is available is an improvement on the status quo, if it is done in
a way which doesn't damage the current build process? History shows
quite a few instances of other developers falling into the same trap I
did, e.g.
http://search.gmane.org/search.php?group=gmane.comp.version-control.git&query=decl-after-statement
So if the check was automated in the majority of cases (I guess the
majority of developers use gcc), it would mean less review work for
you and fewer re-rolls. If you agree, I will try to rework the patch
so that it doesn't damage the build.
> One flag I prefer to use is -Werror, but that means the
> other flags must have zero false positive rate.
Personally I'm a fan of -Werror too. How frequent are false
positives, and are any of them ever insurmountable?
> If you are interested, the flags I personally use with the version
> of GCC I happen to have is in the Make script on the 'todo' branch.
Thanks for the info.
^ permalink raw reply
* Re: Pushing symbolic references to remote repositories?
From: Andreas Schwab @ 2012-12-22 9:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dun Peal, Shawn Pearce, Git ML
In-Reply-To: <7vip7vrof6.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think that the only one and a half sensible use cases that
> unconditionally make sense to update symrefs across repositories are
> to update bare.git/HEAD symref:
>
> - update bare.git/HEAD of a repository that is a local mirror of a
> more authoritative repository with "git fetch --mirror", in which
> case you do want to follow what branch is designated as the
> primary by the project you are mirroring from;
>
> - update bare.git/HEAD from outside by some means to change which
> branch is the primary one for the project. Only because your
> hosting site does not give you an easy way to do so, pushing from
> another repository that happens to point its HEAD at a different
> branch seems to be one plausible way to do so, but that does not
> have to be the only way.
This is not limited to HEAD, any ref may want to be set up as a symref
at a remote repo. For example, I want to set up a symref master ->
trunk at a repository I have no shell access to. Without this I get
spurious error whenever I fetch from that remote (where master and trunk
are separate refs) into a local mirror which does have the symref:
>From git://repo.or.cz/emacs
f0ae89f..5595931 master -> master
error: Ref refs/heads/trunk is at 559593152b9de5a1c144729e0583fa7968abab22 but expected f0ae89f92326beb3f5a19e90c8f4fe0ab6197926
! f0ae89f..5595931 trunk -> trunk (unable to update local ref)
Andreas.
--
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
* [PATCH 5/7] get_patch_filename(): drop "just-numbers" hack
From: Junio C Hamano @ 2012-12-22 8:33 UTC (permalink / raw)
To: git
In-Reply-To: <1356165212-5611-1-git-send-email-gitster@pobox.com>
The function chooses from three operating modes (format using the
subject, the commit, or just number) based on NULL-ness of two of
its parameters, which is an ugly hack for sharing only a bit of
code.
Separate out the "just numbers" part out to the callers.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/log.c | 5 ++++-
log-tree.c | 29 ++++++++++++++---------------
2 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index d9946ec..3c6f20a 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -684,7 +684,10 @@ static int reopen_stdout(struct commit *commit, const char *subject,
strbuf_addch(&filename, '/');
}
- get_patch_filename(&filename, commit, subject, rev);
+ if (rev->numbered_files)
+ strbuf_addf(&filename, "%d", rev->nr);
+ else
+ get_patch_filename(&filename, commit, subject, rev);
if (!quiet)
fprintf(realstdout, "%s\n", filename.buf + outdir_offset);
diff --git a/log-tree.c b/log-tree.c
index ceed6b6..d9f86ce 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -307,21 +307,18 @@ void get_patch_filename(struct strbuf *buf,
int nr = info->nr;
int suffix_len = strlen(suffix) + 1;
int start_len = buf->len;
+ int max_len = start_len + FORMAT_PATCH_NAME_MAX - suffix_len;
- strbuf_addf(buf, commit || subject ? "%04d-" : "%d", nr);
- if (commit || subject) {
- int max_len = start_len + FORMAT_PATCH_NAME_MAX - suffix_len;
+ strbuf_addf(buf, "%04d-", nr);
+ if (subject)
+ strbuf_addstr(buf, subject);
+ else if (commit) {
struct pretty_print_context ctx = {0};
-
- if (subject)
- strbuf_addstr(buf, subject);
- else if (commit)
- format_commit_message(commit, "%f", buf, &ctx);
-
- if (max_len < buf->len)
- strbuf_setlen(buf, max_len);
- strbuf_addstr(buf, suffix);
+ format_commit_message(commit, "%f", buf, &ctx);
}
+ if (max_len < buf->len)
+ strbuf_setlen(buf, max_len);
+ strbuf_addstr(buf, suffix);
}
void log_write_email_headers(struct rev_info *opt, struct commit *commit,
@@ -390,9 +387,11 @@ void log_write_email_headers(struct rev_info *opt, struct commit *commit,
mime_boundary_leader, opt->mime_boundary);
extra_headers = subject_buffer;
- get_patch_filename(&filename,
- opt->numbered_files ? NULL : commit, NULL,
- opt);
+ if (opt->numbered_files)
+ strbuf_addf(&filename, "%d", opt->nr);
+ else
+ get_patch_filename(&filename, commit, NULL,
+ opt);
snprintf(buffer, sizeof(buffer) - 1,
"\n--%s%s\n"
"Content-Type: text/x-patch;"
--
1.8.0.6.gd28b5d4.dirty
^ permalink raw reply related
* [PATCH 7/7] format-patch: add --reroll-count=$N option
From: Junio C Hamano @ 2012-12-22 8:33 UTC (permalink / raw)
To: git
In-Reply-To: <1356165212-5611-1-git-send-email-gitster@pobox.com>
The --reroll-count=$N option, when given a positive integer:
- Adds " v$N" to the subject prefix specified. As the default
subject prefix string is "PATCH", --reroll-count=2 makes it
"PATCH v2".
- Prefixes "v$N-" to the names used for output files. The cover
letter, whose name is usually 0000-cover-letter.patch, becomes
v2-0000-cover-letter.patch when given --reroll-count=2.
This allows users to use the same --output-directory for multiple
iterations of the same series, without letting the output for a
newer round overwrite output files from the earlier rounds. The
user can incorporate materials from earlier rounds to update the
newly minted iteration, and use "send-email v2-*.patch" to send out
the patches belonging to the second iteration easily.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/log.c | 11 +++++++++++
log-tree.c | 2 ++
revision.h | 1 +
3 files changed, 14 insertions(+)
diff --git a/builtin/log.c b/builtin/log.c
index 8cfb4da..e101498 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1061,6 +1061,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
struct strbuf buf = STRBUF_INIT;
int use_patch_format = 0;
int quiet = 0;
+ int reroll_count = -1;
char *branch_name = NULL;
const struct option builtin_format_patch_options[] = {
{ OPTION_CALLBACK, 'n', "numbered", &numbered, NULL,
@@ -1080,6 +1081,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
N_("use <sfx> instead of '.patch'")),
OPT_INTEGER(0, "start-number", &start_number,
N_("start numbering patches at <n> instead of 1")),
+ OPT_INTEGER(0, "reroll-count", &reroll_count,
+ N_("mark the series as Nth re-roll")),
{ OPTION_CALLBACK, 0, "subject-prefix", &rev, N_("prefix"),
N_("Use [<prefix>] instead of [PATCH]"),
PARSE_OPT_NONEG, subject_prefix_callback },
@@ -1152,6 +1155,14 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
PARSE_OPT_KEEP_ARGV0 | PARSE_OPT_KEEP_UNKNOWN |
PARSE_OPT_KEEP_DASHDASH);
+ if (0 < reroll_count) {
+ struct strbuf sprefix = STRBUF_INIT;
+ strbuf_addf(&sprefix, "%s v%d",
+ rev.subject_prefix, reroll_count);
+ rev.reroll_count = reroll_count;
+ rev.subject_prefix = strbuf_detach(&sprefix, NULL);
+ }
+
if (do_signoff) {
const char *committer;
const char *endpos;
diff --git a/log-tree.c b/log-tree.c
index 670beae..5dc126b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -308,6 +308,8 @@ void fmt_output_subject(struct strbuf *filename,
int start_len = filename->len;
int max_len = start_len + FORMAT_PATCH_NAME_MAX - (strlen(suffix) + 1);
+ if (0 < info->reroll_count)
+ strbuf_addf(filename, "v%d-", info->reroll_count);
strbuf_addf(filename, "%04d-%s", nr, subject);
if (max_len < filename->len)
diff --git a/revision.h b/revision.h
index a95bd0b..e4a912a 100644
--- a/revision.h
+++ b/revision.h
@@ -134,6 +134,7 @@ struct rev_info {
const char *mime_boundary;
const char *patch_suffix;
int numbered_files;
+ int reroll_count;
char *message_id;
struct string_list *ref_message_ids;
const char *add_signoff;
--
1.8.0.6.gd28b5d4.dirty
^ 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