* Re: [PATCH] git-send-email: handle email address with quoted comma
From: Junio C Hamano @ 2008-12-19 6:40 UTC (permalink / raw)
To: Wu Fengguang; +Cc: git
In-Reply-To: <1229658012-9240-1-git-send-email-fengguang.wu@intel.com>
Wu Fengguang <fengguang.wu@intel.com> writes:
> Correctly handle email addresses containing quoted commas, e.g.
>
> "Zhu, Yi" <yi.zhu@intel.com>, "Li, Shaohua" <shaohua.li@intel.com>
>
> Here the commas inside the double quotes are NOT email separators.
Thanks.
> @@ -359,6 +360,12 @@ foreach my $entry (@bcclist) {
> die "Comma in --bcclist entry: $entry'\n" unless $entry !~ m/,/;
> }
>
> +sub split_addrs($) {
> + my ($addrs) = @_;
> +
> + return "ewords('\s*,\s*', 1, $addrs);
> +}
> +
Does it add real value (e.g. type safety, simplified interface to the
caller, etc.) to force scalar context to the callers? It has been my
experience that use of prototypes (aka "parameter context templates") in
Perl programs tend to make the code less readable and more error prone in
longer term. I would further say that, even though you do not have any
existing caller of split_addrs sub that uses it for more than two values,
not using the prototype would be a better way to write this sub in this
particular case, because it would allow callers to say [*1*]:
@addrs = split_addr(@list_of_addr_lines);
It also is a bit funny-looking to invoke &function() (it is Perl4 style,
isn't it?)
IOW, wouldn't this be a better alternative?
sub split_addrs {
return quotewords('\s*,\s*', 1, @_);
}
[Footnote]
*1* This program demonstrates why use of prototype in this case is more
confusing than it is worth.
-- >8 --
#!/usr/bin/perl -w
use Text::ParseWords;
sub foo ($) { my ($addrs) = @_; return quotewords('\s*,\s*', 1, $addrs); }
sub bar { return quotewords('\s*,\s*', 1, @_); }
my @addrs = ('Frotz, "Xyzzy, Zork", Nitfol', 'Yomin, Rezrov');
my @addr = ($addrs[0]);
for (foo($addrs[0])) {
print "foo(\$addrs[0]) <<$_>>\n";
}
for (foo(@addr)) {
print "foo(\@addr) <<$_>>\n";
}
for (bar($addrs[0])) {
print "bar(\$addrs[0]) <<$_>>\n";
}
for (bar(@addr)) {
print "bar(\@addr) <<$_>>\n";
}
-- 8< --
The output from the above (the fourth one is the most interesting) looks
like this.
foo($addrs[0]) <<Frotz>>
foo($addrs[0]) <<"Xyzzy, Zork">>
foo($addrs[0]) <<Nitfol>>
foo(@addr) <<1>>
bar($addrs[0]) <<Frotz>>
bar($addrs[0]) <<"Xyzzy, Zork">>
bar($addrs[0]) <<Nitfol>>
bar(@addr) <<Frotz>>
bar(@addr) <<"Xyzzy, Zork">>
bar(@addr) <<Nitfol>>
*2* A more detailed discussion on Perl's "prototypes" is found here:
http://web.archive.org/web/20080210085941/http://library.n0i.net/programming/perl/articles/fm_prototypes/
^ permalink raw reply
* Re: [PATCH] Remove the requirement opaquelocktoken uri scheme
From: Junio C Hamano @ 2008-12-19 7:32 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: git
In-Reply-To: <1229651491-23060-1-git-send-email-catap@catap.ru>
"Kirill A. Korinskiy" <catap@catap.ru> writes:
> Server can use any URI for token by rfc 4918 section 6.5 paragraph five
>
> Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
Could you give a bit more high-level background information behind this
patch?
I can make a guess without knowing much about DAV that this might be...
The program flow of pushing over http is:
- call lock_remote() to issue a DAV_LOCK request to the server to lock
info/refs and branch refs being pushed into; handle_new_lock_ctx() is
used to parse its response to populate "struct remote_lock" that is
returned from lock_remote();
- send objects;
- call unlock_remote() to drop the lock.
The handle_new_lock_ctx() function assumed that the server will use a
lock token in opaquelocktoken URI scheme, which may have been an Ok
assumption under RFC 2518, but under RFC 4918 which obsoletes the older
standard it is not necessarily true.
This resulted in push failure (often resulted in "xxxxx" error message)
when talking to a server that does not use opaquelocktoken URI scheme.
But I shouldn't have to guess or write the commit log message for you.
Giving a bit higher level background is important for people who may have
seen the error message (so filling in the "xxxxx" blank in the above
hypothetical commit log message is *important*) to find your message and
try your commit to see if it fixes the issue for them.
^ permalink raw reply
* Re: [PATCH] git-send-email: handle email address with quoted comma
From: Wu Fengguang @ 2008-12-19 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org, Matt Kraai
In-Reply-To: <7vej04d5wy.fsf@gitster.siamese.dyndns.org>
On Fri, Dec 19, 2008 at 08:40:13AM +0200, Junio C Hamano wrote:
> Wu Fengguang <fengguang.wu@intel.com> writes:
>
> > Correctly handle email addresses containing quoted commas, e.g.
> >
> > "Zhu, Yi" <yi.zhu@intel.com>, "Li, Shaohua" <shaohua.li@intel.com>
> >
> > Here the commas inside the double quotes are NOT email separators.
>
> Thanks.
>
> > @@ -359,6 +360,12 @@ foreach my $entry (@bcclist) {
> > die "Comma in --bcclist entry: $entry'\n" unless $entry !~ m/,/;
> > }
> >
> > +sub split_addrs($) {
> > + my ($addrs) = @_;
> > +
> > + return "ewords('\s*,\s*', 1, $addrs);
> > +}
> > +
>
> Does it add real value (e.g. type safety, simplified interface to the
> caller, etc.) to force scalar context to the callers? It has been my
> experience that use of prototypes (aka "parameter context templates") in
> Perl programs tend to make the code less readable and more error prone in
> longer term. I would further say that, even though you do not have any
> existing caller of split_addrs sub that uses it for more than two values,
> not using the prototype would be a better way to write this sub in this
> particular case, because it would allow callers to say [*1*]:
>
> @addrs = split_addr(@list_of_addr_lines);
>
> It also is a bit funny-looking to invoke &function() (it is Perl4 style,
> isn't it?)
>
> IOW, wouldn't this be a better alternative?
>
> sub split_addrs {
> return quotewords('\s*,\s*', 1, @_);
> }
Hi Junio and Matt,
Thank you for the helpful information. The patch is updated and tested
according to your comments.
Thanks,
Fengguang
---
git-send-email: handle email address with quoted comma
Correctly handle email addresses containing quoted commas, e.g.
"Zhu, Yi" <yi.zhu@intel.com>, "Li, Shaohua" <shaohua.li@intel.com>
Here the commas inside the double quotes are NOT email separators.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
git-send-email.perl | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 3112f76..6114401 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -20,6 +20,7 @@ use strict;
use warnings;
use Term::ReadLine;
use Getopt::Long;
+use Text::ParseWords;
use Data::Dumper;
use Term::ANSIColor;
use File::Temp qw/ tempdir /;
@@ -359,6 +360,10 @@ foreach my $entry (@bcclist) {
die "Comma in --bcclist entry: $entry'\n" unless $entry !~ m/,/;
}
+sub split_addrs {
+ return parse_line('\s*,\s*', 1, @_);
+}
+
my %aliases;
my %parse_alias = (
# multiline formats can be supported in the future
@@ -367,7 +372,7 @@ my %parse_alias = (
my ($alias, $addr) = ($1, $2);
$addr =~ s/#.*$//; # mutt allows # comments
# commas delimit multiple addresses
- $aliases{$alias} = [ split(/\s*,\s*/, $addr) ];
+ $aliases{$alias} = [ split_addrs($addr) ];
}}},
mailrc => sub { my $fh = shift; while (<$fh>) {
if (/^alias\s+(\S+)\s+(.*)$/) {
@@ -379,7 +384,7 @@ my %parse_alias = (
chomp $x;
$x .= $1 while(defined($_ = <$fh>) && /^ +(.*)$/);
$x =~ /^(\S+)$f\t\(?([^\t]+?)\)?(:?$f){0,2}$/ or next;
- $aliases{$1} = [ split(/\s*,\s*/, $2) ];
+ $aliases{$1} = [ split_addrs($2) ];
}},
gnus => sub { my $fh = shift; while (<$fh>) {
if (/\(define-mail-alias\s+"(\S+?)"\s+"(\S+?)"\)/) {
@@ -588,7 +593,7 @@ if (!@to) {
}
my $to = $_;
- push @to, split /,\s*/, $to;
+ push @to, split_addrs($to);
$prompting++;
}
--
1.6.0.4
^ permalink raw reply related
* Re: Odd merge behaviour involving reverts
From: Junio C Hamano @ 2008-12-19 8:45 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Linus Torvalds, Alan, git
In-Reply-To: <20081219124452.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> If I understand Alan's case correctly, I think he does not want to
> "undo" the revert but wants to merge an updated version of the branch,
> as if no mistaken merge nor its revert happened in the past.
>
> If you revert the revert on the branch before merging, doesn't it mean
> that you will be merging what the older version of the branch did (that
> is in the revert of the revert as a single huge patch) and what the
> updated version of the branch wants to do? Wouldn't that lead to a mess
> with huge conflicts?
The history immediately after the "revert of the merge" would look like
this:
---o---o---o---M---x---x---W---x
/
---A---B
where A and B are on the side development that was not so good, M is the
merge that brings those premature changes into the mainline, x are
unrelated changes already made on the mainline and W is the "revert of the
merge M" (doesn't W look M upside down?). IOW, "diff W^..W" is similar to
"diff -R M^..M".
I think you misunderstood what "merging an updated version of the branch"
meant by Alan's description to mean that the side branch developers
discarded their faulty A and B, and redone the changes, which would have
resulted in something like:
---o---o---o---M---x---x---W---x---x
\
A'--B'--C'
If that were the situation, suggestion by Linus to revert the revert and
then merge would result in something like this:
---o---o---o---M---x---x---W---x---x---Y---*
\ /
A'--B'--C'
where Y is the revert of W, A' and B'are rerolled A and B, and there may
also be a further fix-up C' on the side branch. "diff Y^..Y" is similar
to "diff -R W^..W" (which in turn means it is similar to "diff M^..M"),
and "diff A'^..C'" by definition would be similar but different from that,
because it is a rerolled series of the earlier change. There would be a
lot of overlap as you feared. In such a case, not having Y (revert of the
revert) would result in a much more trivial merge:
---o---o---o---M---x---x---W---x---x-------*
\ /
A'--B'--C'
because problematic large commits M and W are already outside of the scope
of this final merge.
But I think what Alan's developers did is different. They did this
instead:
---o---o---o---M---x---x---W---x
/
---A---B-------------------C---D
where C and D are to fix what was broken in A and B. In such a situation,
what Linus suggests makes perfect sense. You first revert the revert,
which would result in this:
---o---o---o---M---x---x---W---x---Y
/
---A---B-------------------C---D
where Y is the revert of W, which would (ignoring possible conflicts
between what W and W..Y changed) be equivalent to not having W nor Y at
all in the history:
---o---o---o---M---x---x-------x----
/
---A---B-------------------C---D
and merging the side branch again will not have conflict arising from an
earlier revert and revert of revert.
---o---o---o---M---x---x-------x-------*
/ /
---A---B-------------------C---D
Of course the changes made in C and D still can conflict with what was
done by any of the x, but that is just a normal merge conflict.
To recap, these are two very different scenarios, and wants two very
different resolution strategies:
- If the faulty side branch whose effects were discarded by an earlier
revert of a merge was rebuilt from scratch (i.e. rebasing and fixing,
as you seem to have interpreted), then re-merging the result without
doing anything else fancy would be the right thing to do.
- If the faulty side branch was fixed by adding corrections on top, then
doing a revert of the previous revert would be the right thing to do.
I hope this clears up confusion and fear.
^ permalink raw reply
* jgit doesn't support "compare with" and "replace with"?
From: Martin_S @ 2008-12-19 9:10 UTC (permalink / raw)
To: git
Hi, I'm using eclipse 3.4 and jgit 0.4. The right click context menus don't
list "compare with" and "replace with". Am I doing something wrong?
Thanks in Advance, Martin
--
View this message in context: http://n2.nabble.com/jgit-doesn%27t-support-%22compare-with%22-and-%22replace-with%22--tp1677009p1677009.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Michael J Gruber @ 2008-12-19 9:26 UTC (permalink / raw)
To: C. Scott Ananian; +Cc: David Howells, git, linux-kernel
In-Reply-To: <c6d9bea0812181647n55fbb6b9w333702fc80127198@mail.gmail.com>
C. Scott Ananian venit, vidit, dixit 19.12.2008 01:47:
> On Fri, Dec 12, 2008 at 1:28 PM, David Howells <dhowells@redhat.com> wrote:
>> Add a guide to using GIT's simpler features.
>> diff --git a/Documentation/git-haters-guide.txt b/Documentation/git-haters-guide.txt
>> +In the above example, I've assumed that you've got your own tree with the head
>> +at commit C3, and that you've got a branch that you want to merge, which has
>> +its head at commit B3. After merging them, you'd end up with a directed,
>> +cyclic tree:
>
> That should be, "acyclic". There are no cycles, because the graph is directed.
Well, directed graphs can have cycles. But the revision graph of a
revision control system has to be an acyclic directed graph. Otherwise
parenthood would be a complicated matter ;)
And no, trees by definition don't have cycles. Also, a "tree" in git
lingo is not the graph theoretic notion (which David uses, though
incorrectly); this only adds unnecessary points of confusion.
For whatever reason the graphs in version control systems are called
"dag"s, i.e. directed acyclic graphs, even though "acyclicity" depends
on whether you look at the directed or undirected graphs. (Branching
then merging gives an undirected cycle.) I guess one may read "directed"
as an attribute to "acyclic" here, i.e. ((directed acyclic) graph)
rather than (directed (acyclic graph)); so to say "directedly acyclic
graph". Or it's just that "dag" reads much better than "adg"...
So, please: Simplification yes, but not if it's unnecessarily misleading
or even plain wrong (referring to the original proposal, not the comment).
Cheers,
Michael
^ permalink raw reply
* Re: is it possible filter the revision history of a single file into another repository?
From: Thomas Jarosch @ 2008-12-19 9:44 UTC (permalink / raw)
To: Whit Armstrong; +Cc: git, Junio C Hamano
In-Reply-To: <8ec76080812181151y4a5a6f5cna57785c935032e77@mail.gmail.com>
On Thursday, 18. December 2008 20:51:38 Whit Armstrong wrote:
> Sorry, seem to be getting this error:
> `/home/whit/dvl/risk.metrics.utils/RiskMetrics/.git-rewrite/t/../index.new'
>: No such file or directory
>
> do I need to set up the index file first?
Hmm, I guess you have an empty commit in your repository like I did.
This is currently a corner case in update-index, which does not create empty
index files. I posted a patch a few days ago and Junio posted an updated
version of that. I could send you my version for git 1.6.0.5 if you need it.
> Is there a good site that documents this procedure?
A good start is the git-filter-branch man page and the mailinglist archive.
Thomas
^ permalink raw reply
* Re: Announcement: Git Extensions stable (windows shell extensions)
From: Peter Krefting @ 2008-12-19 10:36 UTC (permalink / raw)
To: Henk; +Cc: git
In-Reply-To: <1229547366402-1669761.post@n2.nabble.com>
Henk:
> I just rereleased a 0.9 version without the visual studio plugin. Too bad it
> causes problems, I will try to fix them soon. I was able to reproduce the
> error on my laptop, so thats a good start.
I tried with the 0.91 version but ran into a different problem:
"The system cannot open the device or file specified."
followed by
"The installer has encountered an unexpected error installing this
package. This may indicate a problem with this package. The error code
is 2755."
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* remote tracking branch deletion problem
From: Thomas Jarosch @ 2008-12-19 11:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Hello together,
while playing around with git, I stumbled upon a strange remote tracking
branch deletion problem. It seems I'm unable to delete the remote tracking
branch "origin/HEAD" using git 1.6.0.5. Here's what I did:
[tomj@storm repo]$ git init
Initialized empty Git repository in /tmp/repo/.git/
[tomj@storm repo]$ echo "test" >test
[tomj@storm repo]$ git add test
[tomj@storm repo]$ git commit -m "Test"
[tomj@storm tmp]$ git clone repo alice
Initialized empty Git repository in /tmp/alice/.git/
[tomj@storm alice]$ git branch -r
origin/HEAD
origin/master
[tomj@storm alice]$ git branch -r -d origin/HEAD
Deleted remote branch origin/HEAD.
[tomj@storm alice]$ git branch -r -d origin/master
Deleted remote branch origin/master.
[tomj@storm alice]$ ls -al .git/refs/remotes/origin/HEAD
-rw-rw---- 1 tomj intra2net 32 19. Dec 12:43 .git/refs/remotes/origin/HEAD
[tomj@storm alice]$ git branch -r
error: refs/remotes/origin/HEAD points nowhere!
Is this supposed to be? git 1.6.1.rc3.35.gc0ceb shows a similar behavior.
Cheers,
Thomas
^ permalink raw reply
* [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Markus Heidelberg @ 2008-12-19 12:14 UTC (permalink / raw)
To: gitster; +Cc: git
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Documentation/diff-format.txt | 2 +-
Documentation/diff-generate-patch.txt | 6 +++---
Documentation/git-commit.txt | 2 +-
Documentation/git-diff-tree.txt | 4 ++--
Documentation/git-mailinfo.txt | 2 +-
Documentation/git-receive-pack.txt | 4 ++--
Documentation/git-reflog.txt | 4 ++--
Documentation/git-show-branch.txt | 4 ++--
Documentation/git-submodule.txt | 2 +-
Documentation/git-update-index.txt | 8 ++++----
Documentation/gitcore-tutorial.txt | 8 ++++----
Documentation/gitk.txt | 4 ++--
Documentation/i18n.txt | 4 ++--
13 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index aafd3a3..1eeb1c7 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -58,7 +58,7 @@ Possible status letters are:
be committed)
- X: "unknown" change type (most probably a bug, please report it)
-Status letters C and M are always followed by a score (denoting the
+Status letters C and R are always followed by a score (denoting the
percentage of similarity between the source and target of the move or
copy), and are the only ones to be so.
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
index 517e1eb..0f25ba7 100644
--- a/Documentation/diff-generate-patch.txt
+++ b/Documentation/diff-generate-patch.txt
@@ -143,15 +143,15 @@ different from it.
A `-` character in the column N means that the line appears in
fileN but it does not appear in the result. A `+` character
-in the column N means that the line appears in the last file,
+in the column N means that the line appears in the result,
and fileN does not have that line (in other words, the line was
added, from the point of view of that parent).
In the above example output, the function signature was changed
from both files (hence two `-` removals from both file1 and
file2, plus `++` to mean one line that was added does not appear
-in either file1 nor file2). Also two other lines are the same
-from file1 but do not appear in file2 (hence prefixed with ` +`).
+in either file1 nor file2). Also eight other lines are the same
+from file1 but do not appear in file2 (hence prefixed with `{plus}`).
When shown by `git diff-tree -c`, it compares the parents of a
merge commit with the merge result (i.e. file1..fileN are the
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 6203461..b5d81be 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -166,7 +166,7 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
'git-commit' if any paths are given on the command line,
in which case this option can be omitted.
If this option is specified together with '--amend', then
- no paths need be specified, which can be used to amend
+ no paths need to be specified, which can be used to amend
the last commit without committing changes that have
already been staged.
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 5d48664..23b7abd 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -43,7 +43,7 @@ include::diff-options.txt[]
show tree entry itself as well as subtrees. Implies -r.
--root::
- When '--root' is specified the initial commit will be showed as a big
+ When '--root' is specified the initial commit will be shown as a big
creation event. This is equivalent to a diff against the NULL tree.
--stdin::
@@ -63,7 +63,7 @@ and terminated by a newline) is printed before the difference. When
comparing commits, the ID of the first (or only) commit, followed by a
newline, is printed.
+
-The following flags further affects the behavior when comparing
+The following flags further affect the behavior when comparing
commits (but not trees).
-m::
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 31eccea..8d95aaa 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Reading a single e-mail message from the standard input, and
+Reads a single e-mail message from the standard input, and
writes the commit log message in <msg> file, and the patches in
<patch> file. The author name, e-mail and e-mail subject are
written out to the standard output to be used by 'git-am'
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index 6b2f8c4..514f03c 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -86,7 +86,7 @@ post-receive Hook
-----------------
After all refs were updated (or attempted to be updated), if any
ref update was successful, and if $GIT_DIR/hooks/post-receive
-file exists and is executable, it will be invoke once with no
+file exists and is executable, it will be invoked once with no
parameters. The standard input of the hook will be one line
for each successfully updated ref:
@@ -133,7 +133,7 @@ post-update Hook
----------------
After all other processing, if at least one ref was updated, and
if $GIT_DIR/hooks/post-update file exists and is executable, then
-post-update will called with the list of refs that have been updated.
+post-update will be called with the list of refs that have been updated.
This can be used to implement any repository wide cleanup tasks.
The exit code from this hook invocation is ignored; the only thing
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index d99236e..7f7a544 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -28,7 +28,7 @@ updated. This command is to manage the information recorded in it.
The subcommand "expire" is used to prune older reflog entries.
Entries older than `expire` time, or entries older than
-`expire-unreachable` time and are not reachable from the current
+`expire-unreachable` time and not reachable from the current
tip, are removed from the reflog. This is typically not used
directly by the end users -- instead, see linkgit:git-gc[1].
@@ -71,7 +71,7 @@ them.
which in turn defaults to 90 days.
--expire-unreachable=<time>::
- Entries older than this time and are not reachable from
+ Entries older than this time and not reachable from
the current tip of the branch are pruned. Without the
option it is taken from configuration
`gc.reflogExpireUnreachable`, which in turn defaults to
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index d3f2588..8277577 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -30,7 +30,7 @@ OPTIONS
-------
<rev>::
Arbitrary extended SHA1 expression (see linkgit:git-rev-parse[1])
- that typically names a branch HEAD or a tag.
+ that typically names a branch head or a tag.
<glob>::
A glob pattern that matches branch or tag names under
@@ -172,7 +172,7 @@ only the primary branches. In addition, if you happen to be on
your topic branch, it is shown as well.
------------
-$ git show-branch --reflog='10,1 hour ago' --list master
+$ git show-branch --reflog="10,1 hour ago" --list master
------------
shows 10 reflog entries going back from the tip as of 1 hour ago.
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index babaa9b..2f207fb 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -87,7 +87,7 @@ use by subsequent users cloning the superproject. If the URL is
given relative to the superproject's repository, the presumption
is the superproject and submodule repositories will be kept
together in the same relative location, and only the
-superproject's URL need be provided: git-submodule will correctly
+superproject's URL needs to be provided: git-submodule will correctly
locate the submodule using the relative URL in .gitmodules.
status::
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 1d9d81a..25e0bbe 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -55,7 +55,7 @@ OPTIONS
default behavior is to error out. This option makes
'git-update-index' continue anyway.
---ignore-submodules:
+--ignore-submodules::
Do not try to update submodules. This option is only respected
when passed before --refresh.
@@ -78,9 +78,9 @@ OPTIONS
--assume-unchanged::
--no-assume-unchanged::
- When these flags are specified, the object name recorded
+ When these flags are specified, the object names recorded
for the paths are not updated. Instead, these options
- sets and unsets the "assume unchanged" bit for the
+ set and unset the "assume unchanged" bit for the
paths. When the "assume unchanged" bit is on, git stops
checking the working tree files for possible
modifications, so you need to manually unset the bit to
@@ -122,7 +122,7 @@ you will need to handle the situation manually.
'git-update-index' refuses an attempt to add `path/file`.
Similarly if a file `path/file` exists, a file `path`
cannot be added. With --replace flag, existing entries
- that conflicts with the entry being added are
+ that conflict with the entry being added are
automatically removed with warning messages.
--stdin::
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 96bf353..da8fa44 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -999,8 +999,8 @@ Fast forward
2 files changed, 2 insertions(+), 0 deletions(-)
----------------
-Because your branch did not contain anything more than what are
-already merged into the `master` branch, the merge operation did
+Because your branch did not contain anything more than what had
+already been merged into the `master` branch, the merge operation did
not actually do a merge. Instead, it just updated the top of
the tree of your branch to that of the `master` branch. This is
often called 'fast forward' merge.
@@ -1353,7 +1353,7 @@ $ GIT_DIR=my-git.git git init
------------
Make sure this directory is available for others you want your
-changes to be pulled by via the transport of your choice. Also
+changes to be pulled via the transport of your choice. Also
you need to make sure that you have the 'git-receive-pack'
program on the `$PATH`.
@@ -1512,7 +1512,7 @@ You can repack this private repository whenever you feel like.
6. Push your changes to the public repository, and announce it
to the public.
-7. Every once in a while, "git-repack" the public repository.
+7. Every once in a while, 'git-repack' the public repository.
Go back to step 5. and continue working.
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index 317f631..4673a75 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -21,7 +21,7 @@ git repository.
OPTIONS
-------
-To control which revisions to shown, the command takes options applicable to
+To control which revisions to show, the command takes options applicable to
the 'git-rev-list' command (see linkgit:git-rev-list[1]).
This manual page describes only the most
frequently used options.
@@ -80,7 +80,7 @@ Examples
--------
gitk v2.6.12.. include/scsi drivers/scsi::
- Show as the changes since version 'v2.6.12' that changed any
+ Show the changes since version 'v2.6.12' that changed any
file in the include/scsi or drivers/scsi subdirectories
gitk --since="2 weeks ago" \-- gitk::
diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt
index 2cdacd9..708da6c 100644
--- a/Documentation/i18n.txt
+++ b/Documentation/i18n.txt
@@ -7,11 +7,11 @@ At the core level, git is character encoding agnostic.
to be what lstat(2) and creat(2) accepts. There is no such
thing as pathname encoding translation.
- - The contents of the blob objects are uninterpreted sequence
+ - The contents of the blob objects are uninterpreted sequences
of bytes. There is no encoding translation at the core
level.
- - The commit log messages are uninterpreted sequence of non-NUL
+ - The commit log messages are uninterpreted sequences of non-NUL
bytes.
Although we encourage that the commit log messages are encoded
--
1.6.1.rc3.27.gf650d1
^ permalink raw reply related
* [PATCH] Documentation: sync example output with git output
From: Markus Heidelberg @ 2008-12-19 12:14 UTC (permalink / raw)
To: gitster; +Cc: git
Don't confuse the user with old git messages.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Documentation/git-checkout.txt | 1 -
Documentation/git-reset.txt | 2 +-
Documentation/gitcore-tutorial.txt | 11 +++++------
Documentation/pretty-formats.txt | 6 +++---
4 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 79824f4..9cd5151 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -232,7 +232,6 @@ the `-m` option, you would see something like this:
------------
$ git checkout -m mytopic
Auto-merging frotz
-merge: warning: conflicts during merge
ERROR: Merge conflict in frotz
fatal: merge program failed
------------
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 29156f6..2049f3d 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -130,7 +130,7 @@ Undo a merge or pull::
$ git pull <1>
Auto-merging nitfol
CONFLICT (content): Merge conflict in nitfol
-Automatic merge failed/prevented; fix up by hand
+Automatic merge failed; fix conflicts and then commit the result.
$ git reset --hard <2>
$ git pull . topic/branch <3>
Updating from 41223... to 13134...
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 96bf353..df48045 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -899,7 +899,7 @@ file, which had no differences in the `mybranch` branch), and say:
----------------
Auto-merging hello
CONFLICT (content): Merge conflict in hello
- Automatic merge failed; fix up by hand
+ Automatic merge failed; fix conflicts and then commit the result.
----------------
It tells you that it did an "Automatic merge", which
@@ -993,7 +993,7 @@ would be different)
----------------
Updating from ae3a2da... to a80b4aa....
-Fast forward
+Fast forward (no commit created; -m option ignored)
example | 1 +
hello | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
@@ -1265,9 +1265,8 @@ file, using 3-way merge. This is done by giving
------------
$ git merge-index git-merge-one-file hello
-Auto-merging hello.
-merge: warning: conflicts during merge
-ERROR: Merge conflict in hello.
+Auto-merging hello
+ERROR: Merge conflict in hello
fatal: merge program failed
------------
@@ -1447,7 +1446,7 @@ public repository you might want to repack & prune often, or
never.
If you run `git repack` again at this point, it will say
-"Nothing to pack". Once you continue your development and
+"Nothing new to pack.". Once you continue your development and
accumulate the changes, running `git repack` again will create a
new pack, that contains objects created since you packed your
repository the last time. We recommend that you pack your project
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index f18d33e..0a8a948 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -30,7 +30,7 @@ This is designed to be as compact as possible.
commit <sha1>
Author: <author>
- Date: <author date>
+ Date: <author date>
<title line>
@@ -49,9 +49,9 @@ This is designed to be as compact as possible.
* 'fuller'
commit <sha1>
- Author: <author>
+ Author: <author>
AuthorDate: <author date>
- Commit: <committer>
+ Commit: <committer>
CommitDate: <committer date>
<title line>
--
1.6.1.rc3.27.gf650d1
^ permalink raw reply related
* Re: is it possible filter the revision history of a single file into another repository?
From: Whit Armstrong @ 2008-12-19 13:08 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: git, Junio C Hamano
In-Reply-To: <200812191044.47830.thomas.jarosch@intra2net.com>
thanks, Thomas. I could definitely pull from your tree. seems like
the path of least resistance to get my repo split.
Cheers,
Whit
On Fri, Dec 19, 2008 at 4:44 AM, Thomas Jarosch
<thomas.jarosch@intra2net.com> wrote:
> On Thursday, 18. December 2008 20:51:38 Whit Armstrong wrote:
>> Sorry, seem to be getting this error:
>> `/home/whit/dvl/risk.metrics.utils/RiskMetrics/.git-rewrite/t/../index.new'
>>: No such file or directory
>>
>> do I need to set up the index file first?
>
> Hmm, I guess you have an empty commit in your repository like I did.
> This is currently a corner case in update-index, which does not create empty
> index files. I posted a patch a few days ago and Junio posted an updated
> version of that. I could send you my version for git 1.6.0.5 if you need it.
>
>> Is there a good site that documents this procedure?
>
> A good start is the git-filter-branch man page and the mailinglist archive.
>
> Thomas
>
>
^ permalink raw reply
* Re: is it possible filter the revision history of a single file into another repository?
From: Thomas Jarosch @ 2008-12-19 13:17 UTC (permalink / raw)
To: Whit Armstrong; +Cc: git, Junio C Hamano
In-Reply-To: <8ec76080812190508v2ef0f982pab66a698f06a80d5@mail.gmail.com>
On Friday, 19. December 2008 14:08:23 Whit Armstrong wrote:
> thanks, Thomas. I could definitely pull from your tree. seems like
> the path of least resistance to get my repo split.
Here's the patch I use for git 1.6.0.5. According to Junio
it has the small drawback of always writing out the index,
even if there are no changes.
If you need an updated patch against HEAD, look for Junio's reply
to my patch in the list archive.
Enjoy,
Thomas
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
--- git-1.6.0.5/builtin-update-index.c 2008-12-08 02:21:49.000000000 +0100
+++ git-1.6.0.5.index/builtin-update-index.c 2008-12-13 12:43:14.000000000
+0100
@@ -297,6 +297,8 @@ static void read_index_info(int line_ter
struct strbuf buf;
struct strbuf uq;
+ int found_something = 0;
+
strbuf_init(&buf, 0);
strbuf_init(&uq, 0);
while (strbuf_getline(&buf, stdin, line_termination) != EOF) {
@@ -307,6 +309,8 @@ static void read_index_info(int line_ter
unsigned long ul;
int stage;
+ found_something = 1;
+
/* This reads lines formatted in one of three formats:
*
* (1) mode SP sha1 TAB path
@@ -382,6 +386,11 @@ static void read_index_info(int line_ter
bad_line:
die("malformed index info %s", buf.buf);
}
+
+ /* Force creation of empty index - needed by git filter-branch */
+ if (!found_something)
+ active_cache_changed = 1;
+
strbuf_release(&buf);
strbuf_release(&uq);
}
^ permalink raw reply
* Re: remote tracking branch deletion problem
From: Michael J Gruber @ 2008-12-19 14:56 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: git, Junio C Hamano
In-Reply-To: <200812191257.18678.thomas.jarosch@intra2net.com>
Thomas Jarosch venit, vidit, dixit 19.12.2008 12:57:
> Hello together,
>
> while playing around with git, I stumbled upon a strange remote tracking
> branch deletion problem. It seems I'm unable to delete the remote tracking
> branch "origin/HEAD" using git 1.6.0.5. Here's what I did:
>
> [tomj@storm repo]$ git init
> Initialized empty Git repository in /tmp/repo/.git/
>
> [tomj@storm repo]$ echo "test" >test
> [tomj@storm repo]$ git add test
> [tomj@storm repo]$ git commit -m "Test"
>
> [tomj@storm tmp]$ git clone repo alice
> Initialized empty Git repository in /tmp/alice/.git/
>
> [tomj@storm alice]$ git branch -r
> origin/HEAD
> origin/master
>
> [tomj@storm alice]$ git branch -r -d origin/HEAD
> Deleted remote branch origin/HEAD.
> [tomj@storm alice]$ git branch -r -d origin/master
> Deleted remote branch origin/master.
>
> [tomj@storm alice]$ ls -al .git/refs/remotes/origin/HEAD
> -rw-rw---- 1 tomj intra2net 32 19. Dec 12:43 .git/refs/remotes/origin/HEAD
> [tomj@storm alice]$ git branch -r
> error: refs/remotes/origin/HEAD points nowhere!
>
> Is this supposed to be? git 1.6.1.rc3.35.gc0ceb shows a similar behavior.
I think the point here is that HEAD is really a symref. "git remote rm
origin" makes sure that symrefs are removed, and is the right command to
use here.
"git branch -r -d", as well as "git update-ref -d" fail to remove HEAD
because it's really not a branch but a symref.
You can use "git update-ref -d --no-deref" to remove HEAD.
Making builtin-branch use delete_ref(,,REF_ISSYMREF) leads to success
for your above commands. I don't know about side effects, though all
tests pass. Is this sensible?
I guess I should come up with a test for this along with the patch.
Michael
^ permalink raw reply
* Re: jgit doesn't support "compare with" and "replace with"?
From: Shawn O. Pearce @ 2008-12-19 15:20 UTC (permalink / raw)
To: Martin_S; +Cc: git
In-Reply-To: <1229677848765-1677009.post@n2.nabble.com>
Martin_S <iksdrijf@yahoo.com> wrote:
>
> Hi, I'm using eclipse 3.4 and jgit 0.4. The right click context menus don't
> list "compare with" and "replace with". Am I doing something wrong?
We haven't implemented them in EGit. So its not surprising that
they aren't appearing.
--
Shawn.
^ permalink raw reply
* how to check remote git repo for updates without pull/fetch
From: Ivan Zorin @ 2008-12-19 16:15 UTC (permalink / raw)
To: git
Hello. I have not very hard question, but I don't know how to better do
it - could you tell me, please, does exist some way to check remote git
repository for updates without downloading any essential files? I
suppose, that such command should just type something like: "already
updated", if current working tree identical to remote repo, and
something like "there is some updates in remote repo", if remote repo
has some new commits and/or branches. Thanks.
^ permalink raw reply
* Re: how to check remote git repo for updates without pull/fetch
From: Shawn O. Pearce @ 2008-12-19 16:33 UTC (permalink / raw)
To: Ivan Zorin; +Cc: git
In-Reply-To: <494BC89F.9070107@gmail.com>
Ivan Zorin <ivan.a.zorin@gmail.com> wrote:
> Hello. I have not very hard question, but I don't know how to better do
> it - could you tell me, please, does exist some way to check remote git
> repository for updates without downloading any essential files? I
> suppose, that such command should just type something like: "already
> updated", if current working tree identical to remote repo, and
> something like "there is some updates in remote repo", if remote repo
> has some new commits and/or branches. Thanks.
There aren't any commands to do it.
What you could do is write a script based upon git ls-remote. A
really simple one might be:
#!/bin/sh
remote=$1
o=.git/remote_cache.$remote
n=$o.new$$
git ls-remote $remote >$n
if [ -f $o ]
then
if diff $o $n >/dev/null
then
echo "No changes"
else
mv $n $o
echo "Updates available"
else
mv $n $o
echo "New remote remembered..."
fi
A much more complex one would actually rewrite refs/heads/ to
the correct refs/remotes/ namespace on your local repository and
compare the remote ref values to the local refs/remotes values.
Patches for git fetch --pretend or something might be interesting.
Though I recall a thread about this before on the MLand saying there
was no point. Its not like you can see how big the download would
be until after its over.
--
Shawn.
^ permalink raw reply
* Re: how to check remote git repo for updates without pull/fetch
From: Ivan Zorin @ 2008-12-19 16:39 UTC (permalink / raw)
To: git
In-Reply-To: <494BC89F.9070107@gmail.com>
> does exist some way to check remote git repository for updates without downloading any essential files?
Well, actually, I think, that I've found one of possible soulution already:
First, check remote repo:
$ git ls-remote /path/to/git/repo
<some sha1-hash> HEAD
...
Then check local repo:
$ cat .git/HEAD
ref: refs/heads/master
$ cat .git/refs/heads/master
<other sha1-hash>
So, if both hashes identical, then current working tree with HEAD, which points to "master", already up-to-dated,
but if they don't, then there is some updates at remote repo.
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: C. Scott Ananian @ 2008-12-19 17:08 UTC (permalink / raw)
To: Michael J Gruber; +Cc: David Howells, git, linux-kernel
In-Reply-To: <494B68B8.20107@drmicha.warpmail.net>
On Fri, Dec 19, 2008 at 4:26 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> C. Scott Ananian venit, vidit, dixit 19.12.2008 01:47:
>> On Fri, Dec 12, 2008 at 1:28 PM, David Howells <dhowells@redhat.com> wrote:
>>> Add a guide to using GIT's simpler features.
>>> diff --git a/Documentation/git-haters-guide.txt b/Documentation/git-haters-guide.txt
>>> +In the above example, I've assumed that you've got your own tree with the head
>>> +at commit C3, and that you've got a branch that you want to merge, which has
>>> +its head at commit B3. After merging them, you'd end up with a directed,
>>> +cyclic tree:
>>
>> That should be, "acyclic". There are no cycles, because the graph is directed.
>
> Well, directed graphs can have cycles. But the revision graph of a
> revision control system has to be an acyclic directed graph. Otherwise
> parenthood would be a complicated matter ;)
I mean that the example given didn't have a cycle (even though it has
nodes arranged in a circle) because of the orientation of the edges.
But you're right, "directed acyclic graph" is a better correction; the
nodes in git do not form a tree.
--scott
--
( http://cscott.net/ )
^ permalink raw reply
* Re: Git Notes idea.
From: Govind Salinas @ 2008-12-19 17:18 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <20081217101110.GC18265@coredump.intra.peff.net>
On Wed, Dec 17, 2008 at 4:11 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Dec 17, 2008 at 04:43:57AM +0100, Johannes Schindelin wrote:
>
>> > I agree, I haven't thought of any fix along these lines other than to
>> > make gc do the clean up.
>>
>> I have, and IIRC I briefly mentioned it back then. Basically, you will
>> have to add a "git notes gc" or some such, which basically reads in the
>> whole notes, traverses all reachable commits, marking the corresponding
>> notes, and then writes out all marked notes (leaving the other notes
>> behind).
>
> I was thinking something similar, but I think it is even easier. Make
> the rule "if we still have the object, then we still have the note".
> That has three benefits:
>
> - implementation is simple: for each note $n, delete it unless
> has_sha1_file($n).
>
> - it handles notes on non-commit objects
>
> - it kills off notes when an object is _pruned_, not when it stops
> being _reachable_. So if I delete a branch with a commit found
> nowhere else, its notes will hang around until it is actually pruned.
> If I pull it from lost+found, I still keep the notes.
>
> Note that all of this garbage collection of notes is really just
> removing them from the most current notes _tree_. If the notes structure
> is actually composed of commits, then old notes that are "deleted" will
> still be available historically.
>
This is my concern with keeping a history of the notes pseudo-branch. Let
us say that I do the following
1) on branch A commit a
2) add note a`
3) on branch B commit b
4) add note b`
5) on branch B commit c
6) add note c`
7) delete branch A
8) gc after a time such that a is pruned
Now either I will always have anote a`
^ permalink raw reply
* Re: Git Notes idea.
From: Govind Salinas @ 2008-12-19 17:38 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <5d46db230812190918qf22b874n8d8aeea557083df8@mail.gmail.com>
Sorry, hit the send key accidentally.
On Wed, Dec 17, 2008 at 4:11 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Dec 17, 2008 at 04:43:57AM +0100, Johannes Schindelin wrote:
>
> > I agree, I haven't thought of any fix along these lines other than to
> > make gc do the clean up.
>
> I have, and IIRC I briefly mentioned it back then. Basically, you will
>> have to add a "git notes gc" or some such, which basically reads in the
>> whole notes, traverses all reachable commits, marking the corresponding
>> notes, and then writes out all marked notes (leaving the other notes
>> behind).
>
> I was thinking something similar, but I think it is even easier. Make
> the rule "if we still have the object, then we still have the note".
> That has three benefits:
>
> - implementation is simple: for each note $n, delete it unless
> has_sha1_file($n).
>
> - it handles notes on non-commit objects
>
> - it kills off notes when an object is _pruned_, not when it stops
> being _reachable_. So if I delete a branch with a commit found
> nowhere else, its notes will hang around until it is actually pruned.
> If I pull it from lost+found, I still keep the notes.
>
> Note that all of this garbage collection of notes is really just
> removing them from the most current notes _tree_. If the notes structure
> is actually composed of commits, then old notes that are "deleted" will
> still be available historically.
>
This is my concern with keeping a history of the notes pseudo-branch. Let
me restate what you are saying with an example
1) on branch A commit a
2) add note a`
3) on branch B commit b
4) add note b`
5) on branch B commit c
6) add note c`
7) delete branch A
8) gc after a time such that a is pruned
Now either I will always have a note a` as an object forever even though
the only commit that points to it is gone or I have to re-write the history of
the notes branch from the point that it was added.
Given this problem, is it really such a good idea to keep the history?
Of course the other side of this conversation is that the merge operation
will be more complex since the following can also happen
9) push notes
10) user 2 pulls notes but still has commit a and note a`
On the other, other hand, pushing and pulling notes if a history is kept
will have to involve a lot of rebasing/merging.
Just to throw an idea out...
A possible solution is that notes are per-branch,
refs/notes/heads/master
refs/notes/heads/foo/bar
refs/notes/remotes/baz/bang
and then it is easier to deal with. A published branch's notes are isolated
from the changes in unpublished branches. And since published branches
aren't *supposed* to change, then the notes should also always be fast
forwards. Similarly, if a branch is not considered stable, like pu or even
next, then the associated notes branch could be forced in the same way.
Rebase, cherry-pick and merge (and possibly branch/checkout) would have
to be updated to handle notes, which is the down side. It also doesn't solve
the issue of a history causing us to keep notes after the aren't useful anymore.
So perhaps we could use the above layout with no history?
Thanks,
Govind.
^ permalink raw reply
* Re: Git Notes idea.
From: Govind Salinas @ 2008-12-19 17:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812171233270.28560@intel-tinevez-2-302>
On Wed, Dec 17, 2008 at 5:38 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 17 Dec 2008, Jeff King wrote:
>> If he is planning on doing a separate pyrite implementation, then it
>> _hasn't_ been implemented yet. And I don't care there if he uses hash
>> tables or sorted lists or whatever. I think the most important thing is
>> getting down the design of the _data structure_, so that we can have a
>> compatible implementation inside git itself.
>
> Well, I don't care about pyrite. As far as I am concerned, it might as
> well use an incompatible version. I really don't care.
Well I do care. It would not be a good thing for anyone to have 2 separate
systems for notes. Let us say that someone who you work with uses pyrite
and you don't. They will add notes which you can't see and vice versa.
Thanks,
Govind.
^ permalink raw reply
* Re: [PATCH] Make git revert warn the user when reverting a merge commit.
From: Alan @ 2008-12-19 18:07 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: git, Junio C Hamano, Johannes Schindelin, Linus Torvalds
In-Reply-To: <200812182129.01021.bss@iguanasuicide.net>
On Thu, 2008-12-18 at 21:29 -0600, Boyd Stephen Smith Jr. wrote:
> On Thursday 2008 December 18 21:03:46 Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > > warning("revert on a merge commit may not do what you "
> > > "expect.");
> >
> > [T]he new warning does
> > not give you enough clue where to go next, so this warning does not give
> > real value. It is pretty much meaningless noise to users.
>
> At least, it might make someone read the manpage again. Still, I'm unhappy
> with the message, but I didn't want to be too wordy. A URL or manpage
> reference would be nice, but I didn't know of a good guide that explained the
> dangers of reverting a merge commit as well as Linus's emails.
That would be OK if the man page actually explained how this is supposed
to work. it does not. (Especially where it concerns "parent number"
and reverts of merges, which has no real explanation.)
^ permalink raw reply
* [PATCH] Clarify git-format-patch --in-reply-to
From: jidanni @ 2008-12-19 19:12 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7vzlitho1o.fsf@gitster.siamese.dyndns.org>
Signed-off-by: jidanni <jidanni@jidanni.org>
diff --git a/git-format-patch.txt b/git-format-patch.txt
index ee27eff..04958de 100644
--- a/git-format-patch.txt
+++ b/git-format-patch.txt
@@ -130 +130,2 @@ include::diff-options.txt[]
- provide a new patch series.
+ provide a new patch series. Generates coresponding References and
+ In-Reply-To headers. Angle brackets around <Message-Id> are optional.
--
1.5.6.5
^ permalink raw reply related
* How to extract files out of a "git bundle", no matter what?
From: jidanni @ 2008-12-19 19:29 UTC (permalink / raw)
To: mdl123; +Cc: git
Someone has handed you a "git bundle".
How do you get the files out of it?
If it were cpio, you would use -i, if it were tar, you would use -x...
You read the git-bundle man page.
You only get as far as
# git-bundle verify bundle.bdl
The bundle contains 1 ref
d01... /heads/master
The bundle requires these 0 ref
bundle.bdl is okay
The rest is mish-mosh. There should be an emergency example for non
git club members, even starting from apt-get install git-core, of the
all the real steps needed _to get the files out of the bundle_.
Assume the user _just wants to get the files out of the bundle_ and
not learn about or participate in some project.
^ 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