* Re: git svn dcommit crashed -- how do I resume?
From: Teemu Likonen @ 2008-11-26 9:42 UTC (permalink / raw)
To: Jens Neuhalfen; +Cc: git
In-Reply-To: <E8293DEF-109A-4F57-BD4F-7F189976DA79@gmx.de>
Jens Neuhalfen (2008-11-26 09:22 +0100) wrote:
> I am using git as a frontend to my SVN-Repository. When I tried to
> "git svn dcommit" several changes from my local git-repository, git
> crashed (SEGFAULT, AFAIR).
> I am confused (an slightly panicked), because my old commits seem to
> be "gone", my WC does not contain the most recent files and there
> seems to be no "backup-branch" with my old HEAD.
I don't know why the the dcommit crashed but I'm certain that you can
find your previous commits through the reflog. Try (one of) these
commands:
git log --walk-reflogs [branchname]
git log --walk-reflogs HEAD
They will show a list of commits about where [branchname] or HEAD has
been previously in _your_ repository. If/when you find the correct
commit (where you think the branch's head should be) copy its SHA1 and
create a new branch from it (git branch new-branch [SHA1]) - or just
reset the broken branch to that commit (git reset --hard [SHA1]).
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Ondrej Certik @ 2008-11-26 9:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Fabian Seoane
In-Reply-To: <alpine.DEB.1.00.0811260113140.30769@pacific.mpi-cbg.de>
On Wed, Nov 26, 2008 at 1:14 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 25 Nov 2008, Ondrej Certik wrote:
>
>> I would like to export our whole git repository to patches, and then
>> reconstruct it again from scratch. Following the man page of "git
>> fast-export":
>>
>> [...]
>>
>> However, the repository is very different to the original one. It
>> contains only 191 patches:
>
> Can you try again with a Git version that contains the commit
> 2075ffb5(fast-export: use an unsorted string list for extra_refs)?
I tried the next branch:
$ git --version
git version 1.6.0.4.1060.g9433b
that contains the 2075ffb5 patch. I haven't observed any change ---
the "git log" still only shows 191 commits (git log --all shows
everything).
Ondrej
^ permalink raw reply
* Re: French git user
From: Nicolas Morey-Chaisemartin @ 2008-11-26 9:31 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200811260955.57421.johan@herland.net>
Johan Herland a écrit :
> On Wednesday 26 November 2008, Nicolas Morey-Chaisemartin wrote:
>
>> I've been allowed to share my presentation:
>> http://nicolas.morey-chaisemartin.com/git_tuto.pdf
>>
>> Please send me any feedback, I'm always glad to imrpove my work.
>>
>
> I have no knowledge of French, but on page 15 the command
> "git-commit --append" is mentioned. There is no "--append"
> option. I'm guessing the "--amend" option is meant instead.
>
> Also, the very next command is "git-revert COMIT_ID".
> "COMIT_ID" should probably have an extra "M".
>
> Finally, on page 11, you say something about "git foo" vs.
> "git-foo" (hopefully that the "git-foo" form is deprecated),
> but in the rest of the presentation you use a mix of "git foo"
> and "git-foo" (mostly "git-foo"). This seems inconsistent.
>
>
> Have fun! :)
>
> ...Johan
>
>
Thanks, good catch.
Yes I say in french that git-foo is deprecated.
However I'm still using it in the following slides because people have
directly the good command to look at the man.
I know it's not really consistent but asI'd rahter keep it that way and
insist while presenting it, it should only be used for man pages.
I added your vchanged and updated the pdf.
Thanks
Nicolas
^ permalink raw reply
* Re: [PATCH] tg export: implement skipping empty patches for quilt mode
From: martin f krafft @ 2008-11-26 9:25 UTC (permalink / raw)
To: Uwe Kleine-König, git, Petr Baudis
In-Reply-To: <20081125205440.GA28679@strlen.de>
[-- Attachment #1: Type: text/plain, Size: 791 bytes --]
also sprach Uwe Kleine-König <ukleinek@strlen.de> [2008.11.25.2154 +0100]:
> TODO: -n option to prevent exporting of empty patches
>
> I'm not sure if this was meant for collapse or quilt or both. I assumed
> the last and implemented -n as suggested.
Hm, except...
+! "$skipempty" || [ "$driver" = "quilt" ] ||
+ die "-n is only implemented for the quilt driver"
+
so you assumed "quilt", not both.
Anyway, Petr, I'd make this default for all drivers, unless you object.
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
http://www.vcnet.com/bms/
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: French git user
From: Johan Herland @ 2008-11-26 8:55 UTC (permalink / raw)
To: git, devel; +Cc: Jean-Francois Veillette
In-Reply-To: <492D0295.6060808@morey-chaisemartin.com>
On Wednesday 26 November 2008, Nicolas Morey-Chaisemartin wrote:
> I've been allowed to share my presentation:
> http://nicolas.morey-chaisemartin.com/git_tuto.pdf
>
> Please send me any feedback, I'm always glad to imrpove my work.
I have no knowledge of French, but on page 15 the command
"git-commit --append" is mentioned. There is no "--append"
option. I'm guessing the "--amend" option is meant instead.
Also, the very next command is "git-revert COMIT_ID".
"COMIT_ID" should probably have an extra "M".
Finally, on page 11, you say something about "git foo" vs.
"git-foo" (hopefully that the "git-foo" form is deprecated),
but in the rest of the presentation you use a mix of "git foo"
and "git-foo" (mostly "git-foo"). This seems inconsistent.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH v2] config.txt: alphabetize configuration sections
From: Matt McCutchen @ 2008-11-26 8:26 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <1227556809.2628.8.camel@mattlaptop2.local>
I figured the sections might as well be in some order, so I chose alphabetical
but with "core" at the beginning. This should help people add new variables
in the right places.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
Documentation/config.txt | 128 +++++++++++++++++++---------------------
Documentation/merge-config.txt | 8 +++
2 files changed, 68 insertions(+), 68 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d536732..17627ac 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -572,9 +572,6 @@ color.status.<slot>::
to red). The values of these variables may be specified as in
color.branch.<slot>.
-commit.template::
- Specify a file to use as the template for new commit messages.
-
color.ui::
When set to `always`, always use colors in all git commands which
are capable of colored output. When false (or `never`), never. When
@@ -582,6 +579,9 @@ color.ui::
terminal. When more specific variables of color.* are set, they always
take precedence over this setting. Defaults to false.
+commit.template::
+ Specify a file to use as the template for new commit messages.
+
diff.autorefreshindex::
When using 'git-diff' to compare with work tree
files, do not consider stat-only change as changed.
@@ -714,18 +714,6 @@ gc.rerereunresolved::
kept for this many days when 'git-rerere gc' is run.
The default is 15 days. See linkgit:git-rerere[1].
-rerere.autoupdate::
- When set to true, `git-rerere` updates the index with the
- resulting contents after it cleanly resolves conflicts using
- previously recorded resolution. Defaults to false.
-
-rerere.enabled::
- Activate recording of resolved conflicts, so that identical
- conflict hunks can be resolved automatically, should they
- be encountered again. linkgit:git-rerere[1] command is by
- default enabled if you create `rr-cache` directory under
- `$GIT_DIR`, but can be disabled by setting this option to false.
-
gitcvs.enabled::
Whether the CVS server interface is enabled for this repository.
See linkgit:git-cvsserver[1].
@@ -917,6 +905,10 @@ i18n.logOutputEncoding::
Character encoding the commit messages are converted to when
running 'git-log' and friends.
+imap::
+ The configuration variables in the 'imap' section are described
+ in linkgit:git-imap-send[1].
+
instaweb.browser::
Specify the program that will be used to browse your working
repository in gitweb. See linkgit:git-instaweb[1].
@@ -952,8 +944,6 @@ man.viewer::
Specify the programs that may be used to display help in the
'man' format. See linkgit:git-help[1].
-include::merge-config.txt[]
-
man.<tool>.cmd::
Specify the command to invoke the specified man viewer. The
specified command is evaluated in shell with the man page
@@ -963,13 +953,7 @@ man.<tool>.path::
Override the path for the given tool that may be used to
display help in the 'man' format. See linkgit:git-help[1].
-merge.conflictstyle::
- Specify the style in which conflicted hunks are written out to
- working tree files upon merge. The default is "merge", which
- shows `<<<<<<<` conflict marker, change made by one side,
- `=======` marker, change made by the other side, and then
- `>>>>>>>` marker. An alternate style, "diff3", adds `|||||||`
- marker and the original text before `=======` marker.
+include::merge-config.txt[]
mergetool.<tool>.path::
Override the path for the given tool. This is useful in case
@@ -1079,6 +1063,41 @@ pull.octopus::
pull.twohead::
The default merge strategy to use when pulling a single branch.
+receive.fsckObjects::
+ If it is set to true, git-receive-pack will check all received
+ objects. It will abort in the case of a malformed object or a
+ broken link. The result of an abort are only dangling objects.
+ Defaults to false.
+
+receive.unpackLimit::
+ If the number of objects received in a push is below this
+ limit then the objects will be unpacked into loose object
+ files. However if the number of received objects equals or
+ exceeds this limit then the received pack will be stored as
+ a pack, after adding any missing delta bases. Storing the
+ pack from a push can make the push operation complete faster,
+ especially on slow filesystems. If not set, the value of
+ `transfer.unpackLimit` is used instead.
+
+receive.denyDeletes::
+ If set to true, git-receive-pack will deny a ref update that deletes
+ the ref. Use this to prevent such a ref deletion via a push.
+
+receive.denyNonFastForwards::
+ If set to true, git-receive-pack will deny a ref update which is
+ not a fast forward. Use this to prevent such an update via a push,
+ even if that push is forced. This configuration variable is
+ set when initializing a shared repository.
+
+receive.denyCurrentBranch::
+ If set to true or "refuse", receive-pack will deny a ref update
+ to the currently checked out branch of a non-bare repository.
+ Such a push is potentially dangerous because it brings the HEAD
+ out of sync with the index and working tree. If set to "warn",
+ print a warning of such a push to stderr, but allow the push to
+ proceed. If set to false or "ignore", allow such pushes with no
+ message. Defaults to "warn".
+
remote.<name>.url::
The URL of a remote repository. See linkgit:git-fetch[1] or
linkgit:git-push[1].
@@ -1128,6 +1147,18 @@ repack.usedeltabaseoffset::
"false" and repack. Access from old git versions over the
native protocol are unaffected by this option.
+rerere.autoupdate::
+ When set to true, `git-rerere` updates the index with the
+ resulting contents after it cleanly resolves conflicts using
+ previously recorded resolution. Defaults to false.
+
+rerere.enabled::
+ Activate recording of resolved conflicts, so that identical
+ conflict hunks can be resolved automatically, should they
+ be encountered again. linkgit:git-rerere[1] command is by
+ default enabled if you create `rr-cache` directory under
+ `$GIT_DIR`, but can be disabled by setting this option to false.
+
showbranch.default::
The default set of branches for linkgit:git-show-branch[1].
See linkgit:git-show-branch[1].
@@ -1164,6 +1195,11 @@ tar.umask::
archiving user's umask will be used instead. See umask(2) and
linkgit:git-archive[1].
+transfer.unpackLimit::
+ When `fetch.unpackLimit` or `receive.unpackLimit` are
+ not set, the value of this variable is used instead.
+ The default value is 100.
+
url.<base>.insteadOf::
Any URL that starts with this value will be rewritten to
start, instead, with <base>. In cases where some site serves a
@@ -1192,50 +1228,6 @@ user.signingkey::
unchanged to gpg's --local-user parameter, so you may specify a key
using any method that gpg supports.
-imap::
- The configuration variables in the 'imap' section are described
- in linkgit:git-imap-send[1].
-
-receive.fsckObjects::
- If it is set to true, git-receive-pack will check all received
- objects. It will abort in the case of a malformed object or a
- broken link. The result of an abort are only dangling objects.
- Defaults to false.
-
-receive.unpackLimit::
- If the number of objects received in a push is below this
- limit then the objects will be unpacked into loose object
- files. However if the number of received objects equals or
- exceeds this limit then the received pack will be stored as
- a pack, after adding any missing delta bases. Storing the
- pack from a push can make the push operation complete faster,
- especially on slow filesystems. If not set, the value of
- `transfer.unpackLimit` is used instead.
-
-receive.denyDeletes::
- If set to true, git-receive-pack will deny a ref update that deletes
- the ref. Use this to prevent such a ref deletion via a push.
-
-receive.denyNonFastForwards::
- If set to true, git-receive-pack will deny a ref update which is
- not a fast forward. Use this to prevent such an update via a push,
- even if that push is forced. This configuration variable is
- set when initializing a shared repository.
-
-receive.denyCurrentBranch::
- If set to true or "refuse", receive-pack will deny a ref update
- to the currently checked out branch of a non-bare repository.
- Such a push is potentially dangerous because it brings the HEAD
- out of sync with the index and working tree. If set to "warn",
- print a warning of such a push to stderr, but allow the push to
- proceed. If set to false or "ignore", allow such pushes with no
- message. Defaults to "warn".
-
-transfer.unpackLimit::
- When `fetch.unpackLimit` or `receive.unpackLimit` are
- not set, the value of this variable is used instead.
- The default value is 100.
-
web.browser::
Specify a web browser that may be used by some commands.
Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index c735788..b10ce38 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -26,6 +26,14 @@ merge.verbosity::
above outputs debugging information. The default is level 2.
Can be overridden by 'GIT_MERGE_VERBOSITY' environment variable.
+merge.conflictstyle::
+ Specify the style in which conflicted hunks are written out to
+ working tree files upon merge. The default is "merge", which
+ shows `<<<<<<<` conflict marker, change made by one side,
+ `=======` marker, change made by the other side, and then
+ `>>>>>>>` marker. An alternate style, "diff3", adds `|||||||`
+ marker and the original text before `=======` marker.
+
merge.<driver>.name::
Defines a human readable name for a custom low-level
merge driver. See linkgit:gitattributes[5] for details.
--
1.6.0.2.593.g91df
^ permalink raw reply related
* git svn dcommit crashed -- how do I resume?
From: Jens Neuhalfen @ 2008-11-26 8:22 UTC (permalink / raw)
To: git
Hi,
I am using git as a frontend to my SVN-Repository. When I tried to
"git svn dcommit" several changes from my local git-repository, git
crashed (SEGFAULT, AFAIR).
Now I have a working copy (master branch) that points "somewhere in
the past" (at least my files are old). I have a git-svn remote branch
that points to the same SHA1.
$ git branch -a
dokument-zusammenfuehren
* master
git-svn
I cannot dcommit
$ git svn dcommit
Cannot dcommit with a dirty index. Commit your changes first, or
stash them with `git stash'.
at /Users/jens/libexec/git-core/git-svn line 415
And, indeed, the index is dirty.
I am confused (an slightly panicked), because my old commits seem to
be "gone", my WC does not contain the most recent files and there
seems to be no "backup-branch" with my old HEAD.
Any idea, how I might get my data back and how to 'resume' the dead
dcommit? Google did not turn up anything usefull, unfortunally.
BTW: I am currently using git version 1.6.0.rc0.24.gf45e0.dirty.
Jens
^ permalink raw reply
* Re: French git user
From: Nicolas Morey-Chaisemartin @ 2008-11-26 8:02 UTC (permalink / raw)
To: devel; +Cc: Jean-Francois Veillette, git
In-Reply-To: <492C2F2E.2050200@morey-chaisemartin.com>
Nicolas Morey-Chaisemartin a écrit :
> Christian MICHON a écrit :
>
>> On Tue, Nov 25, 2008 at 2:38 PM, Jean-Francois Veillette
>> <jean_francois_veillette@yahoo.ca> wrote:
>>
>>
>>> I'll probably need to do the same here (Montréal, Qc), so if you can share
>>> your slides (or else), that would be nice.
>>>
>>> Merci ! (thanks),
>>>
>>> - jfv
>>>
>>>
>>>
>> you'll need to ask Nicolas. what I did was to provide feedback to his
>> slides only (done).
>> it's up to him to share his work or not.
>>
>>
>>
>
> I'd gladly share it, I just have to check my company policy.
> I asked my boss tonight so I'll get an answer by tomorrow and post it on
> a ftp somewhere, if I can share it
>
> Nicolas
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
I've been allowed to share my presentation:
http://nicolas.morey-chaisemartin.com/git_tuto.pdf
Please send me any feedback, I'm always glad to imrpove my work.
Regards
Nicolas Morey-Chaisemartin
^ permalink raw reply
* Re: [PATCH (Eek!)] git diff does not honor --no-ext-diff
From: René Scharfe @ 2008-11-26 7:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nazri Ramliy, git
In-Reply-To: <7vprkihqk6.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> "Nazri Ramliy" <ayiehere@gmail.com> writes:
>
>> git-diff does not honor the --no-ext-diff option in both cases when the external
>> diff program is set via diff.external and gitattributes.
>>
>> Is this intentional?
>
> Judging from 72909be (Add diff-option --ext-diff, 2007-06-30), I think
> this was intended in the sense that --ext-diff and --no-ext-diff were
> meant to be no-op for "diff" itself when they were introduced.
>
> Having said that, I do not know if I agree with the original intention.
> It looks more like an oversight that came from focusing only on what a new
> behaviour for the "log" family should be, than a logical design decision
> to exclude "diff" from this codepath.
>
> Wouldn't this be a better patch?
Yes. And feel free to squash in the following. :)
diff --git a/t/t4020-diff-external.sh b/t/t4020-diff-external.sh
index dfe3fbc..ec787b4 100755
--- a/t/t4020-diff-external.sh
+++ b/t/t4020-diff-external.sh
@@ -43,6 +43,13 @@ test_expect_success 'GIT_EXTERNAL_DIFF environment should apply only to diff' '
'
+test_expect_success 'GIT_EXTERNAL_DIFF environment and --no-ext-diff' '
+
+ GIT_EXTERNAL_DIFF=echo git diff --no-ext-diff |
+ grep "^diff --git a/file b/file"
+
+'
+
test_expect_success 'diff attribute' '
git config diff.parrot.command echo &&
@@ -68,6 +75,13 @@ test_expect_success 'diff attribute should apply only to diff' '
'
+test_expect_success 'diff attribute and --no-ext-diff' '
+
+ git diff --no-ext-diff |
+ grep "^diff --git a/file b/file"
+
+'
+
test_expect_success 'diff attribute' '
git config --unset diff.parrot.command &&
@@ -94,6 +108,13 @@ test_expect_success 'diff attribute should apply only to diff' '
'
+test_expect_success 'diff attribute and --no-ext-diff' '
+
+ git diff --no-ext-diff |
+ grep "^diff --git a/file b/file"
+
+'
+
test_expect_success 'no diff with -diff' '
echo >.gitattributes "file -diff" &&
git diff | grep Binary
^ permalink raw reply related
* Re: [PATCH (Eek!)] git diff does not honor --no-ext-diff
From: Junio C Hamano @ 2008-11-26 7:52 UTC (permalink / raw)
To: Nazri Ramliy; +Cc: git
In-Reply-To: <544dda350811252312u7ef5533bwb20b37640d861487@mail.gmail.com>
"Nazri Ramliy" <ayiehere@gmail.com> writes:
> git-diff does not honor the --no-ext-diff option in both cases when the external
> diff program is set via diff.external and gitattributes.
>
> Is this intentional?
Judging from 72909be (Add diff-option --ext-diff, 2007-06-30), I think
this was intended in the sense that --ext-diff and --no-ext-diff were
meant to be no-op for "diff" itself when they were introduced.
Having said that, I do not know if I agree with the original intention.
It looks more like an oversight that came from focusing only on what a new
behaviour for the "log" family should be, than a logical design decision
to exclude "diff" from this codepath.
Wouldn't this be a better patch?
builtin-diff.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git c/builtin-diff.c w/builtin-diff.c
index 7ceceeb..b90d8bc 100644
--- c/builtin-diff.c
+++ w/builtin-diff.c
@@ -290,6 +290,9 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
/* Otherwise, we are doing the usual "git" diff */
rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
+ /* Default to let external be used */
+ DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
+
if (nongit)
die("Not a git repository");
argc = setup_revisions(argc, argv, &rev, NULL);
@@ -298,7 +301,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
if (diff_setup_done(&rev.diffopt) < 0)
die("diff_setup_done failed");
}
- DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
+
DIFF_OPT_SET(&rev.diffopt, RECURSIVE);
DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
^ permalink raw reply related
* Re: git svn rebase creates some commits with empty author, commiter and date fields
From: Peter Kirk @ 2008-11-26 7:36 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20081125220617.GA21644@mayonaise>
On Tuesday 25 November 2008 23:06:17 Eric Wong wrote:
> Weird.
>
> Does this happen on other repositories you may use as well? Do you know
> of any strange hooks or otherwise non-standard setup with the SVN
> server?
This is the only svn server I use with git-svn with, so I don't know if this
would happen on other servers.
About "strange hooks"...there is a pre-commit hook verifying that the
svn:eolstyle is set properly on text files, but since git > 1.6.0 can do
"autoproperties" like svn that has never failed for me. Then there is a post-
commit hook which sends out a commit mail and scans the commit message for
certain commands which trigger the software to be built.
Since that other post I linked was related to the "authors" file, I added a
text file which maps all the svn users to git users, and that works (I can see
the assigned names instead of the svn names for commits that aren't broken),
but it hasn't helped reduce/eliminate the frequency of broken commits.
>
> Which version of the SVN perl bindings are you using?
I am using the SVN perl bindings that came with my distribution (ubuntu), the
version string reads: 1.5.1dfsg1-1ubuntu2, might this be the problem?
Peter
^ permalink raw reply
* [PATCH (Eek!)] git diff does not honor --no-ext-diff
From: Nazri Ramliy @ 2008-11-26 7:12 UTC (permalink / raw)
To: git
Hello list,
git-diff does not honor the --no-ext-diff option in both cases when the external
diff program is set via diff.external and gitattributes.
Is this intentional? If not the following patch seems to fix it.
I think there must be a cleaner way of fixing this than doing it by
`hand' hence the Eek!
Nazri.
builtin-diff.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index 7ceceeb..4ac7e15 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -290,6 +290,19 @@ int cmd_diff(int argc, const char **argv, const
char *prefix)
/* Otherwise, we are doing the usual "git" diff */
rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
+ DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
+ /*
+ * Do we have --no-ext-diff and have external diff setup via either
+ * gitconfig or gitattributes, then clear ALLOW_EXTERNAL by hand. Eek.
+ */
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+ if (!strcmp(arg, "--"))
+ break;
+ else if (!strcmp(arg, "--no-ext-diff"))
+ DIFF_OPT_CLR(&rev.diffopt, ALLOW_EXTERNAL);
+ }
+
if (nongit)
die("Not a git repository");
argc = setup_revisions(argc, argv, &rev, NULL);
@@ -298,7 +311,6 @@ int cmd_diff(int argc, const char **argv, const
char *prefix)
if (diff_setup_done(&rev.diffopt) < 0)
die("diff_setup_done failed");
}
- DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
DIFF_OPT_SET(&rev.diffopt, RECURSIVE);
DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
^ permalink raw reply related
* Re: [PATCH] send-email: Fix Pine address book parsing
From: Junio C Hamano @ 2008-11-26 6:44 UTC (permalink / raw)
To: Trent Piepho; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0811252137250.5161@t2.domain.actdsltmp>
Trent Piepho <tpiepho@freescale.com> writes:
> The tech docs I linked to just say pine continues lines with leading space,
> but not how many spaces exactly.
My reading of the wording "spaces" it uses is that any number. I agree it
is underspecified what would happen to them.
> It also appears to only split lines between whitespace and
> non-whitespace. ...
> ... like "a b \n c \n d\n". If I didn't eat the leading spaces in the
> continuations, it would be re-assembled as "a b c d". This might cause
> an address to become "John Doe <jdoe@anon.org>"
Which would still work. If you had two addresses a and b and smashed them
together into ab on the other hand it wouldn't. That is why I asked.
If you know for sure (e.g. by reading the Pine source) that it only splits
a line at a whitespace to non-whitespace transition, that it keeps the
whitespace at the end of the first line, and that the non-whitespace and
everything after that on the second line (prefixed by extra unspecified
number of spaces as the continuation sign), then I think what you had in
your patch is exactly what we want. I just wanted to make sure you know
what you are doing, as I do not use Pine nor its address book myself.
^ permalink raw reply
* Re: [PATCH] send-email: Fix Pine address book parsing
From: Trent Piepho @ 2008-11-26 5:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod03hyna.fsf@gitster.siamese.dyndns.org>
On Tue, 25 Nov 2008, Junio C Hamano wrote:
> Trent Piepho <tpiepho@freescale.com> writes:
>> See: http://www.washington.edu/pine/tech-notes/low-level.html
>>
>> Entries with a fcc or comment field after the address weren't parsed
>> correctly.
>>
>> Continuation lines, identified by leading spaces, were also not handled.
>>
>> Distribution lists which had ( ) around a list of addresses did not have
>> the parenthesis removed.
>
>> + pine => sub { my $fh = shift; my $f='\t[^\t]*';
>> + for (my $x = ''; defined($x); $x = $_) {
>> + chomp $x;
>> + $x .= $1 while(defined($_ = <$fh>) && /^ +(.*)$/);
>> + $x =~ /^(\S+)$f\t\(?([^\t]+?)\)?(:?$f){0,2}$/ or next;
>
> Hmm, so you chomp each continuation line with /^ +(.*)$/ and concatenate
> that to the hold buffer ($x) as long as you see continuation lines,
> a non-continuation line that you read ahead is given to the next round
> (the third part of for(;;) control), checked if you hit an EOF and then
> chomped. Which means the complicated regexp about the parentheses is
> applied to a logical single line in $x that does not have any newline in
> it, right?
Yes. The previous regex would just grab the email address with (\S+)$, but
that's not right. There can be email address with spaces in them, like
"John Doe <jdoe@anon.org>". And the email address isn't always the last
field. So each field has to be put in the regex and \S+ and \s* have to
become [^\t]* and \t to count fields properly. That's why the regex got so
complex.
> I wonder what this does:
>
> $x .= $1 while (defined($_ = <$fh>) && /^ +(.*)$/);
>
> when you have "a b" in $x and feed " c\n d\ne\n" to it. When it leaves
> the loop, you would have "e\n" in $_ for the next round, and "a bcd" (note
> that "bcd" becomes one word) in $x, which I suspect may not be what you
> want.
The tech docs I linked to just say pine continues lines with leading space,
but not how many spaces exactly. From what I can see it appears to usually
use three spaces, but sometimes it uses one space when wrapping a very long
comment field. It also appears to only split lines between whitespace and
non-whitespace. So if "a b c d\n" were to be wrapped, it would be something
like "a b \n c \n d\n". If I didn't eat the leading spaces in the
continuations, it would be re-assembled as "a b c d". This might cause
an address to become "John Doe <jdoe@anon.org>"
^ permalink raw reply
* Re: [RFC/PATCH] bisect: teach "skip" to accept special arguments like "A..B"
From: Junio C Hamano @ 2008-11-26 5:42 UTC (permalink / raw)
To: Christian Couder; +Cc: Johannes Schindelin, git, H. Peter Anvin
In-Reply-To: <20081123220249.2e7f30a5.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> The current "git bisect skip" syntax is "git bisect skip [<rev>...]"
> so it's already possible to skip a range of revisions using
> something like:
>
> $ git bisect skip $(git rev-list A..B)
>
> where A and B are the bounds of the range we want to skip.
>
> This patch teaches "git bisect skip" to accept:
>
> $ git bisect skip A..B
>
> as an abbreviation for the former command.
Although I fully realize that the established semantics of A..B in git is
bottom-exclusive, top-inclusive, and this suggestion breaks the UI
uniformity by deviating from that convention, I have to wonder if it would
be more useful if you let the bottom commit (A in your example) also be
skipped.
I would suspect that it would be more useful than the "replace" one, but
that is a separate issue.
^ permalink raw reply
* Re: [PATCH] send-email: Fix Pine address book parsing
From: Junio C Hamano @ 2008-11-26 4:58 UTC (permalink / raw)
To: Trent Piepho; +Cc: git, gitster
In-Reply-To: <1227668100-5563-1-git-send-email-tpiepho@freescale.com>
Trent Piepho <tpiepho@freescale.com> writes:
> See: http://www.washington.edu/pine/tech-notes/low-level.html
>
> Entries with a fcc or comment field after the address weren't parsed
> correctly.
>
> Continuation lines, identified by leading spaces, were also not handled.
>
> Distribution lists which had ( ) around a list of addresses did not have
> the parenthesis removed.
> + pine => sub { my $fh = shift; my $f='\t[^\t]*';
> + for (my $x = ''; defined($x); $x = $_) {
> + chomp $x;
> + $x .= $1 while(defined($_ = <$fh>) && /^ +(.*)$/);
> + $x =~ /^(\S+)$f\t\(?([^\t]+?)\)?(:?$f){0,2}$/ or next;
Hmm, so you chomp each continuation line with /^ +(.*)$/ and concatenate
that to the hold buffer ($x) as long as you see continuation lines,
a non-continuation line that you read ahead is given to the next round
(the third part of for(;;) control), checked if you hit an EOF and then
chomped. Which means the complicated regexp about the parentheses is
applied to a logical single line in $x that does not have any newline in
it, right?
I wonder what this does:
$x .= $1 while (defined($_ = <$fh>) && /^ +(.*)$/);
when you have "a b" in $x and feed " c\n d\ne\n" to it. When it leaves
the loop, you would have "e\n" in $_ for the next round, and "a bcd" (note
that "bcd" becomes one word) in $x, which I suspect may not be what you
want.
But I do not use Pine nor its aliases file.
^ permalink raw reply
* Problem deleting remote branches
From: Jeff Mitchell @ 2008-11-26 4:04 UTC (permalink / raw)
To: git
I'm running into a problem where it seems that you can't delete branches
from a remote WebDAV/HTTP repository (at least, not using the methods
you would use for a git protocol-based repo). It seems to be looking
for the wrong ref head.
Here's a log of running the commands against github, using the native
git protocol:
$ git checkout --track -b gittest jefferai
Branch gittest set up to track local branch refs/heads/jefferai.
Switched to a new branch "gittest"
$ git push origin gittest
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:jefferai/portage.git
* [new branch] gittest -> gittest
$ git checkout jefferai
Switched to branch "jefferai"
$ git branch -d -r origin/gittest
Deleted remote branch origin/gittest.
$ git push origin :gittest
To git@github.com:jefferai/portage.git
- [deleted] gittest
Here's the same (near as I could get it) commands against my http-based
server. Note that because of some other weirdness, I delete the local
branch that I push up, then re-fetch it as a remote tracking branch,
then try to do the delete:
$ git checkout --track -b gittest jefferai
Branch gittest set up to track local branch refs/heads/jefferai.
Switched to a new branch "gittest"
$ git push myremote gittest
Fetching remote heads...
refs/
refs/tags/
refs/heads/
updating 'refs/heads/gittest'
from 0000000000000000000000000000000000000000
to a4641f663ae86739b623a4b5bba7b284e5999549
done
Updating remote server info
$ git checkout jefferai
Switched to branch "jefferai"
$ git branch -d gittest
Deleted branch gittest.
$ git fetch myremote
From https://[my,server.com]/amarok
* [new branch] gittest -> myremote/gittest
$ git checkout --track -b gittest myremote/gittest
Branch gittest set up to track remote branch refs/remotes/myremote/gittest.
Switched to a new branch "gittest"
$ git checkout jefferai
Switched to branch "jefferai"
$ git branch -r -d myremote/gittest
Deleted branch gittest.
$ git push myremote :gittest
Fetching remote heads...
refs/
refs/tags/
refs/heads/
fatal: Couldn't get https://[my.server.com]/amarok.git/refs/heads/master
for remote symref
The requested URL returned error: 404
error: failed to push some refs to 'https://[my.server.com]/amarok.git'
Note the third to last line:
Couldn't get https://[my.server.com]/amarok.git/refs/heads/master
On my webserver, in the repository, I have the following in refs/heads:
bookcase amarok.git # ls refs/heads/
gittest jefferai
I do have a "master" branch -- that's where the "jefferai" branch was
spawned from, which the "gittest" branch was spawned from -- but I have
no idea why it's looking for it.
My remote ref for github looks like:
[remote "origin"]
url = git@github.com:jefferai/portage.git
fetch = +refs/heads/*:refs/remotes/origin/*
and my remote ref for my server looks like:
[remote "myremote"]
url = https://[my.server.com]/amarok.git
fetch = +refs/heads/*:refs/remotes/myremote/*
This smells like a bug, unless there's something I'm doing wrong that I
can't figure out.
Help much appreciated.
Thanks,
Jeff
^ permalink raw reply
* [PATCH] send-email: Fix Pine address book parsing
From: Trent Piepho @ 2008-11-26 2:55 UTC (permalink / raw)
To: git; +Cc: Trent Piepho, gitster
See: http://www.washington.edu/pine/tech-notes/low-level.html
Entries with a fcc or comment field after the address weren't parsed
correctly.
Continuation lines, identified by leading spaces, were also not handled.
Distribution lists which had ( ) around a list of addresses did not have
the parenthesis removed.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
---
git-send-email.perl | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 94ca5c8..007e2c6 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -345,10 +345,13 @@ my %parse_alias = (
# spaces delimit multiple addresses
$aliases{$1} = [ split(/\s+/, $2) ];
}}},
- pine => sub { my $fh = shift; while (<$fh>) {
- if (/^(\S+)\t.*\t(.*)$/) {
+ pine => sub { my $fh = shift; my $f='\t[^\t]*';
+ for (my $x = ''; defined($x); $x = $_) {
+ chomp $x;
+ $x .= $1 while(defined($_ = <$fh>) && /^ +(.*)$/);
+ $x =~ /^(\S+)$f\t\(?([^\t]+?)\)?(:?$f){0,2}$/ or next;
$aliases{$1} = [ split(/\s*,\s*/, $2) ];
- }}},
+ }},
gnus => sub { my $fh = shift; while (<$fh>) {
if (/\(define-mail-alias\s+"(\S+?)"\s+"(\S+?)"\)/) {
$aliases{$1} = [ $2 ];
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH] Invoke "gc --auto" from git commit
From: Jean-Luc Herren @ 2008-11-26 1:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0811260056480.30769@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> On Tue, 25 Nov 2008, Jean-Luc Herren wrote:
>> This feature was lost during the port of git commit to C.
>
> See http://article.gmane.org/gmane.comp.version-control.git/82125
Oh, I missed that. But then the only commands ever invoking git
gc --auto would be git rebase -i, git merge, git svn and git am.
I don't know if some people have repositories where they never use
any of those, but I certainly have repositories where I only ever
use git rebase -i and never any of the other. 'git commit' is
something everyone is bound to use and thus it would be the best
place for running 'git gc --auto'.
As for the performance impact, on my machine 'git gc --auto' runs
500 times per second in a loop on the git repository (it won't
call the hook unless repacking is necessary). I suppose any
script calling git commit in a loop would do substantially more
work than git gc --auto itself. And if that bit of performance
really matters, it could be invoked by git commit only if (rand()
% 20 == 0).
My two cents anyway.
jlh
^ permalink raw reply
* Re: Extra pair of double quotes in "git commit" output?
From: Santi Béjar @ 2008-11-26 0:06 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, git
In-Reply-To: <20081125232521.GC30942@coredump.intra.peff.net>
On Wed, Nov 26, 2008 at 12:25 AM, Jeff King <peff@peff.net> wrote:
[...]
>
> So I sympathize with the desire to remove the quotes, as they look bad
> and are obviously not too rare. But I'd like to find a solution which
> maintains a better visual separation between the subject and the other
> text than simply removing them.
Maybe just use the output of "git branch -v":
master d9a5491 foo: bar
or even literally:
* master d9a5491 [ahead 1] foo: bar
or to make the separation more evident:
[master d9a5491] foo: bar
Santi
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Johannes Schindelin @ 2008-11-26 0:14 UTC (permalink / raw)
To: Ondrej Certik; +Cc: Git Mailing List, Fabian Seoane
In-Reply-To: <85b5c3130811250844u498fbb97m9d1aef6e1397b8c7@mail.gmail.com>
Hi,
On Tue, 25 Nov 2008, Ondrej Certik wrote:
> I would like to export our whole git repository to patches, and then
> reconstruct it again from scratch. Following the man page of "git
> fast-export":
>
> [...]
>
> However, the repository is very different to the original one. It
> contains only 191 patches:
Can you try again with a Git version that contains the commit
2075ffb5(fast-export: use an unsorted string list for extra_refs)?
Ciao,
Dscho
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: david @ 2008-11-25 23:53 UTC (permalink / raw)
To: Ondrej Certik
Cc: Miklos Vajna, Michael J Gruber, Git Mailing List, Fabian Seoane,
Shawn O. Pearce, Johannes Schindelin
In-Reply-To: <85b5c3130811251539n6cb175b4p185d37385bf43d1e@mail.gmail.com>
On Wed, 26 Nov 2008, Ondrej Certik wrote:
> On Tue, Nov 25, 2008 at 9:41 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> On Tue, Nov 25, 2008 at 06:31:41PM +0100, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>>> I don't know, I just noticed that turning on rename and copy detection
>>> makes git-fast-import crash, which shouldn't happen either. Something's
>>> not right here. CC'ing the authors of im- and export.
>>
>> Could you please write a testcase that reproduces your problem?
>>
>>> Why export|import directly to git?
>>
>> I guess he did not know about filter-branch. :)
>
> I know about filter-branch (but I am not sure it can do what I want).
> I made a mistake of not explaining what I want, instead I suggested (a
> possibly wrong) solution. I want to export the whole git repository as
> a set of human readable patches, that can be assembled back into a git
> repository (with the same hashes as the original one)
the same hashes on the file is easy, the same hashes on the commits is
extremely hard. which is it that you are looking for.
that being said, the test of being able to do a export|import is a good
one to test that the export format and import format actually match.
David Lang
> if needed. The
> reason I want that is that if we later decide to switch to another
> VCS, we have all the information to reproduce the repository. Another
> reason is to be sure that we know all the sources that are needed to
> construct the repository, e.g. that there are no binary blobs
> (possibly containing malicious code). Another reason I want that is to
> be able to rewrite the history, in particular, we have one Mercurial
> repository with some old history and another Mercurial history with a
> newer history and I just want to concatenate them together into one
> git repository.
>
> In each case I know several workarounds, but if there is a way to just
> convert the whole git repository into a set of patches and (and be
> able to convert everything back including the same hashes), then it'd
> be awesome.
>
> See also this thread why people want this (and I assumed git can do
> this from this thread):
>
> http://groups.google.com/group/sage-devel/browse_thread/thread/7b116d902ee20d9c/
>
> Thanks,
> Ondrej
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Invoke "gc --auto" from git commit
From: Johannes Schindelin @ 2008-11-25 23:57 UTC (permalink / raw)
To: Jean-Luc Herren; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <492C24B9.6090200@gmx.ch>
Hi,
On Tue, 25 Nov 2008, Jean-Luc Herren wrote:
> This feature was lost during the port of git commit to C.
See http://article.gmane.org/gmane.comp.version-control.git/82125
Ciao,
Dscho
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Ondrej Certik @ 2008-11-25 23:44 UTC (permalink / raw)
To: Michael J Gruber
Cc: Git Mailing List, Fabian Seoane, Shawn O. Pearce,
Johannes Schindelin
In-Reply-To: <492C367D.3030209@drmicha.warpmail.net>
On Tue, Nov 25, 2008 at 6:31 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Ondrej Certik venit, vidit, dixit 25.11.2008 17:44:
>> Hi,
>>
>> I would like to export our whole git repository to patches, and then
>> reconstruct it again from scratch. Following the man page of "git
>> fast-export":
>>
>> $ git clone git://git.sympy.org/sympy-full-history-20081023.git
>> $ cd sympy-full-history-20081023
>> $ git fast-export --all --export-marks=marks > patches
>> $ cd ..
>> $ mkdir sympy-new
>> $ cd sympy-new
>> $ git init
>> $ git fast-import --export-marks=marks < ../sympy-full-history-20081023/patches
>> git-fast-import statistics:
>> ---------------------------------------------------------------------
>> Alloc'd objects: 25000
>> Total objects: 21355 ( 144 duplicates )
>> blobs : 8009 ( 0 duplicates 4529 deltas)
>> trees : 10627 ( 144 duplicates 9189 deltas)
>> commits: 2719 ( 0 duplicates 0 deltas)
>> tags : 0 ( 0 duplicates 0 deltas)
>> Total branches: 21 ( 26 loads )
>> marks: 1048576 ( 10728 unique )
>> atoms: 726
>> Memory total: 2880 KiB
>> pools: 2098 KiB
>> objects: 781 KiB
>> ---------------------------------------------------------------------
>> pack_report: getpagesize() = 4096
>> pack_report: core.packedGitWindowSize = 33554432
>> pack_report: core.packedGitLimit = 268435456
>> pack_report: pack_used_ctr = 40706
>> pack_report: pack_mmap_calls = 2791
>> pack_report: pack_open_windows = 1 / 2
>> pack_report: pack_mapped = 26177739 / 35513414
>> ---------------------------------------------------------------------
>>
>>
>>
>> However, the repository is very different to the original one. It
>> contains only 191 patches:
>>
>> $ git log --pretty=oneline | wc -l
>> 191
>>
>> and it only contains couple files. Compare this with the original repository:
>>
>> $ git log --pretty=oneline | wc -l
>> 2719
>
> I get the same stats (with the dups) but a perfect rev count, when I use
> git log --all. The reason is that the history in the imported repo is
> disconnected at various places (at tagging commits)! Your command counts
> only the revs backwards to the first "disconnection".
You are right! I didn't know about "git log --all".
>
> So, the real issue is: Why has the result these cuts in the history?
Yes, I would like to know this too. E.g. if it is a problem with our
repository, or a problem in git, or whether it is just not supposed to
work.
> I don't know, I just noticed that turning on rename and copy detection
> makes git-fast-import crash, which shouldn't happen either. Something's
> not right here. CC'ing the authors of im- and export.
>
> BTW: Maybe you can accomplish what you want with different means? Why
> export|import directly to git?
I just answered this in my other email. Basically there are
workarounds, but I would feel safe if I can (correctly) reconstruct
the whole git repository from a human readable patches.
Ondrej
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Ondrej Certik @ 2008-11-25 23:39 UTC (permalink / raw)
To: Miklos Vajna
Cc: Michael J Gruber, Git Mailing List, Fabian Seoane,
Shawn O. Pearce, Johannes Schindelin
In-Reply-To: <20081125204108.GF4746@genesis.frugalware.org>
On Tue, Nov 25, 2008 at 9:41 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Tue, Nov 25, 2008 at 06:31:41PM +0100, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>> I don't know, I just noticed that turning on rename and copy detection
>> makes git-fast-import crash, which shouldn't happen either. Something's
>> not right here. CC'ing the authors of im- and export.
>
> Could you please write a testcase that reproduces your problem?
>
>> Why export|import directly to git?
>
> I guess he did not know about filter-branch. :)
I know about filter-branch (but I am not sure it can do what I want).
I made a mistake of not explaining what I want, instead I suggested (a
possibly wrong) solution. I want to export the whole git repository as
a set of human readable patches, that can be assembled back into a git
repository (with the same hashes as the original one) if needed. The
reason I want that is that if we later decide to switch to another
VCS, we have all the information to reproduce the repository. Another
reason is to be sure that we know all the sources that are needed to
construct the repository, e.g. that there are no binary blobs
(possibly containing malicious code). Another reason I want that is to
be able to rewrite the history, in particular, we have one Mercurial
repository with some old history and another Mercurial history with a
newer history and I just want to concatenate them together into one
git repository.
In each case I know several workarounds, but if there is a way to just
convert the whole git repository into a set of patches and (and be
able to convert everything back including the same hashes), then it'd
be awesome.
See also this thread why people want this (and I assumed git can do
this from this thread):
http://groups.google.com/group/sage-devel/browse_thread/thread/7b116d902ee20d9c/
Thanks,
Ondrej
^ 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