* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: david @ 2009-11-19 6:06 UTC (permalink / raw)
To: Intland Software; +Cc: Petr Baudis, git
In-Reply-To: <4B03F451.4050709@intland.com>
On Wed, 18 Nov 2009, Intland Software wrote:
> More precisely: parts of the source code are actually open, including
> the wiki plugins and the remote clients, for instance. The core source
> is closed, because the same core is also used in our commercial offerings,
> and
> our commercial license doesn't (currently) allow publishing the
> complete code. We have quite some large customers from the defense space
> that would not be happy if we opened everything ;)
are you sure? did you see the recent memo about OpenSource by the DOD?
David Lang
> We are currently in the midst of rethinking our licensing scheme
> in general, to make things more liberal or to set up some kind of a
> dual license.
>
>> I think a lot of people wonder now, how does this compare to existing
>> solutions; from your announcement I thought it's something like
>> Gitosis/Gitolite, but in fact it seems more similar to Gitorious or
>> GitHub (if it was publicly available, of course); perhaps it would be
>> good idea to present comparison to these on the project homepage.
> Good point. More on this later.
> ---
> Intland
> --
> 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
* [PATCH 1/2] Documentation: fix typos and spelling in replace documentation
From: Christian Couder @ 2009-11-19 6:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
This patch fix a missing "s" at the end of an occurence of
"--no-replace-objects" and, while at it, it also improves spelling
and rendering.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replace.txt | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
This is a fix that could go into 'maint'.
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 8adc1ef..69f704f 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -17,31 +17,32 @@ DESCRIPTION
Adds a 'replace' reference in `.git/refs/replace/`
The name of the 'replace' reference is the SHA1 of the object that is
-replaced. The content of the replace reference is the SHA1 of the
+replaced. The content of the 'replace' reference is the SHA1 of the
replacement object.
-Unless `-f` is given, the replace reference must not yet exist in
+Unless `-f` is given, the 'replace' reference must not yet exist in
`.git/refs/replace/` directory.
-Replace references will be used by default by all git commands except
-those doing reachability traversal (prune, pack transfer and fsck).
+Replacement references will be used by default by all git commands
+except those doing reachability traversal (prune, pack transfer and
+fsck).
-It is possible to disable use of replacement refs for any command
-using the --no-replace-objects option just after "git".
+It is possible to disable use of replacement references for any
+command using the `--no-replace-objects` option just after 'git'.
-For example if commit "foo" has been replaced by commit "bar":
+For example if commit 'foo' has been replaced by commit 'bar':
------------------------------------------------
-$ git --no-replace-object cat-file commit foo
+$ git --no-replace-objects cat-file commit foo
------------------------------------------------
-show information about commit "foo", while:
+shows information about commit 'foo', while:
------------------------------------------------
$ git cat-file commit foo
------------------------------------------------
-show information about commit "bar".
+shows information about commit 'bar'.
OPTIONS
-------
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH 2/2] Documentation: talk a little bit about GIT_NO_REPLACE_OBJECTS
From: Christian Couder @ 2009-11-19 6:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replace.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
This patch should go in my series that introduced the
GIT_NO_REPLACE_OBJECTS env variable.
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 69f704f..65a0da5 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -44,6 +44,9 @@ $ git cat-file commit foo
shows information about commit 'bar'.
+The 'GIT_NO_REPLACE_OBJECTS' environment variable can be set to
+achieve the same effect as the `--no-replace-objects` option.
+
OPTIONS
-------
-f::
--
1.6.5.1.gaf97d
^ permalink raw reply related
* Re: Hey - A Conceptual Simplication....
From: Björn Steinbrink @ 2009-11-19 7:42 UTC (permalink / raw)
To: George Dennie
Cc: 'Jason Sewall', 'Jakub Narebski',
'Jan Krüger', git
In-Reply-To: <009401ca68bc$7e4b12b0$7ae13810$@com>
On 2009.11.18 21:03:31 -0500, George Dennie wrote:
> Jason Sewell wrote....
> > I find this leads to big, shapeless commits and, as I mentioned
> > before, it seriously limits the utility of 'git bisect'. I also
> > fail to see how 'selectively saving parts of the document' is
> > versioning and publishing - what is the publishing part? The act of
> > committing is one thing (and 'saving...
>
> The notion of a shapeless commit is curious. Intuitively, I consider a
> commit as capturing the state of my work at a transactional boundary
> (i.e. a successful unit test...or even lunch break). However, your
> characterization of "shape" suggest that you are constructing
> something other than the immediate functionality of the software.
> Consequently, your software document is not really the solution files
> alone but also this commit history that you meticulously craft.
Your "lunch break" as a transaction boundary is a great example of
something that probably most people on this list would consider to
create commits that need rewriting before publishing them. Let's take an
extreme example:
You work on adding a feature to some webmail site that adds colors to
the mail being displayed, using different colors for the headers, quoted
sections and the text from the sender. The colors should be configurable
by the user.
*work*
git commit -m "Go for a coffee"
*work*
git commit -m "Lunch break"
*work*
git commit -m "Meeting"
*work*
git commit -m "Time to go home"
*come back to work*
*work*
git commit -m "Finished the mail coloring support"
This gives you:
* Finished the mail coloring support
|
* Time to go home
|
* Meeting
|
* Lunch break
|
* Go for a coffee
Such a history is basically completely useless. It's (ab)using the VCS
as a plain code dump. In a week, you'll be able to see that you had a
meeting that day, but it doesn't tell you anything about what you did to
the project. And even with less "insane" commit messages, the
"transactional boundaries" are totally arbitrary. They're aligned to
things you did that have absolutely nothing to do with the stuff you're
tracking in your VCS.
A far more useful history might look like this:
* Colorize quoted text in a mail, depending on its quoting depth
|
* Parse mails into a tree structure to represent sections of quoted text
|
* Colorize mail headers
|
* Add support for the user to change the colors used for mails
|
* Add configuration variable for the colors used for mails
At each step, something functionally changed about the software. The
commit messages tell you something about how the software evolved. And
if you get bogus values for the colors in the configuration, you can be
90% sure, by only looking at the commit messages, that you have a bug in
the "Add support for the user to change the colors ..." commit, and not
in one of the others. So you can run "git show $that_commit" to see the
diff of the changes you made in that commit and quickly check them for
your bug.
And while that's not sooo useful for commits that added new
functionality, it's extremely useful for commits that just made small
changes to existing functionality. Finding a bug in a large piece of
code (say 2000 lines) isn't trivial. But if you know that a commit that
changed 5 lines in that code is responsible for the breakage, all you
have to do is to identify the faulty change, which is a lot easier.
And with a large history, where it's not obvious in which commit
something got broken, "git bisect" can help to quickly find the bad
commit. Now consider "git bisect" finding your "Lunch break" commit.
Looking at the commit message tells nothing. The diff is pretty much
arbitrary, might be huge. Not much help. Finding the "Add support for
the user to change the colors ..." commit already tells you something
just because of the commit message. And the diff is about just one
specific change. It's all nicely separated, and that's a huge value.
Using git and producing nice commits is about _documenting_ the history
of your code. And having small, self-contained and well separated
commits is key to that.
And the index can be a great help with that. Given the above example,
you might already have some code to use the configured colors, just for
testing, so things aren't so boring. Maybe even some hack-up of the
code you'll be using later. If that part of the code would be committed
right away, you'd mess up your commit, because it wouldn't be about a
single change anymore, but would also have your testing code in there.
Bad.
But you don't want to throw the testing code away either, because it's
useful right now, and you might need it later, because it might evolve
into the final code used for the actual coloring. So, what now? You have
code that you want to commit, and some code you don't want to commit,
and which needs to go away temporarily, so you can test without it. No
problem, here comes the index.
Say you have:
config.c # Has changes for the colors
show_mail.c # Has changes to use the colors
whatever.c # Has some changes for both
You do:
git add config.c # Add to the index
git add -p whatever.c # Only add some hunks to the index
So now the index has what you want to commit, and the working tree still
has everything.
git stash save --keep-index
Now your working tree and index only have the things you want to commit.
You run your unit tests, everythings fine. You commit and get a nice
clean commit, for which you write a useful commit message.
git stash pop
You've got your changes back that you didn't want to commit just yet,
and you can continue working.
Another use-case I have found for myself is to use the index to separate
reviewed and not-yet-reviewed changes. Before I commit, I always review
the diff of the things I'm going to commit. So I start out with "git
diff" and start reading. When I finished reviewing a file, I can do "git
add $that_file", so the diff for that file will no longer be shown by
"git diff". That nicely cuts down the size of the "git diff" output to
things I'm still interested in. Quite useful when you are forced to do a
large commit, because you did some refactoring. If I find a bug during
the review, I can fix that and re-run "git diff", which will only show
changes to me that I didn't declare as "good" already by adding them to
the index.
Sure, it takes some pratice and discipline to generate a nice, useful
history. But that's not much different from writing code. Others will
hate you for writing unreadable spaghetti code, and so will they hate
you for producing a useless history that tells them that you had lunch,
instead of telling them what you did to the code ;-)
Björn
^ permalink raw reply
* [PATCH v2] git am/mailinfo: Don't look at in-body headers when rebasing
From: Lukas Sandström @ 2009-11-19 8:51 UTC (permalink / raw)
To: Philip Hofstetter, Junio C Hamano; +Cc: Lukas Sandström, Jeff King, git
In-Reply-To: <aa2993680911181547p4cbbf12cq74b482f63e59d007@mail.gmail.com>
When we are rebasing we know that the header lines in the
patch are good and that we don't need to pick up any headers
from the body of the patch.
This makes it possible to rebase commits whose commit message
start with "From" or "Date".
Test vectors by Jeff King.
Signed-off-by: Lukas Sandström <luksan@gmail.com>
---
Argh. I just realized that the change to t5100 in the previous patch
doesn't actually test the new option, since I forgot to change the
+ if test -f "$TEST_DIRECTORY"/t5100/msg$mail--use-first-header
line to "--no-inbody-headers", after my first attempt at an option name.
This time I checked that the tests actually fail when the test is broken.
Still passes, just one line changed since the previous version.
/Lukas
builtin-mailinfo.c | 5 +++++
git-am.sh | 13 ++++++++++---
t/t5100-mailinfo.sh | 6 +++++-
t/t5100/info0015 | 5 +++++
t/t5100/info0015--no-inbody-headers | 5 +++++
t/t5100/info0016 | 5 +++++
t/t5100/info0016--no-inbody-headers | 5 +++++
t/t5100/msg0015 | 2 ++
t/t5100/msg0015--no-inbody-headers | 3 +++
t/t5100/msg0016 | 2 ++
t/t5100/msg0016--no-inbody-headers | 4 ++++
t/t5100/patch0015 | 8 ++++++++
t/t5100/patch0015--no-inbody-headers | 8 ++++++++
t/t5100/patch0016 | 8 ++++++++
t/t5100/patch0016--no-inbody-headers | 8 ++++++++
t/t5100/sample.mbox | 33 +++++++++++++++++++++++++++++++++
16 files changed, 116 insertions(+), 4 deletions(-)
create mode 100644 t/t5100/info0015
create mode 100644 t/t5100/info0015--no-inbody-headers
create mode 100644 t/t5100/info0016
create mode 100644 t/t5100/info0016--no-inbody-headers
create mode 100644 t/t5100/msg0015
create mode 100644 t/t5100/msg0015--no-inbody-headers
create mode 100644 t/t5100/msg0016
create mode 100644 t/t5100/msg0016--no-inbody-headers
create mode 100644 t/t5100/patch0015
create mode 100644 t/t5100/patch0015--no-inbody-headers
create mode 100644 t/t5100/patch0016
create mode 100644 t/t5100/patch0016--no-inbody-headers
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index c90cd31..a81526e 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -26,6 +26,7 @@ static struct strbuf charset = STRBUF_INIT;
static int patch_lines;
static struct strbuf **p_hdr_data, **s_hdr_data;
static int use_scissors;
+static int use_inbody_headers = 1;
#define MAX_HDR_PARSED 10
#define MAX_BOUNDARIES 5
@@ -771,6 +772,8 @@ static int handle_commit_msg(struct strbuf *line)
return 0;
if (still_looking) {
+ if (!use_inbody_headers)
+ still_looking = 0;
strbuf_ltrim(line);
if (!line->len)
return 0;
@@ -1033,6 +1036,8 @@ int cmd_mailinfo(int argc, const char **argv, const char *prefix)
use_scissors = 1;
else if (!strcmp(argv[1], "--no-scissors"))
use_scissors = 0;
+ else if (!strcmp(argv[1], "--no-inbody-headers"))
+ use_inbody_headers = 0;
else
usage(mailinfo_usage);
argc--; argv++;
diff --git a/git-am.sh b/git-am.sh
index c132f50..96869a2 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -289,7 +289,7 @@ split_patches () {
prec=4
dotest="$GIT_DIR/rebase-apply"
sign= utf8=t keep= skip= interactive= resolved= rebasing= abort=
-resolvemsg= resume= scissors=
+resolvemsg= resume= scissors= no_inbody_headers=
git_apply_opt=
committer_date_is_author_date=
ignore_date=
@@ -322,7 +322,7 @@ do
--abort)
abort=t ;;
--rebasing)
- rebasing=t threeway=t keep=t scissors=f ;;
+ rebasing=t threeway=t keep=t scissors=f no_inbody_headers=t ;;
-d|--dotest)
die "-d option is no longer supported. Do not use."
;;
@@ -448,6 +448,7 @@ else
echo "$utf8" >"$dotest/utf8"
echo "$keep" >"$dotest/keep"
echo "$scissors" >"$dotest/scissors"
+ echo "$no_inbody_headers" >"$dotest/no_inbody_headers"
echo "$GIT_QUIET" >"$dotest/quiet"
echo 1 >"$dotest/next"
if test -n "$rebasing"
@@ -495,6 +496,12 @@ t)
f)
scissors=--no-scissors ;;
esac
+if test "$(cat "$dotest/no_inbody_headers")" = t
+then
+ no_inbody_headers=--no-inbody-headers
+else
+ no_inbody_headers=
+fi
if test "$(cat "$dotest/quiet")" = t
then
GIT_QUIET=t
@@ -549,7 +556,7 @@ do
# by the user, or the user can tell us to do so by --resolved flag.
case "$resume" in
'')
- git mailinfo $keep $scissors $utf8 "$dotest/msg" "$dotest/patch" \
+ git mailinfo $keep $no_inbody_headers $scissors $utf8 "$dotest/msg" "$dotest/patch" \
<"$dotest/$msgnum" >"$dotest/info" ||
stop_here $this
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index 0279d07..ebc36c1 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -11,7 +11,7 @@ test_expect_success 'split sample box' \
'git mailsplit -o. "$TEST_DIRECTORY"/t5100/sample.mbox >last &&
last=`cat last` &&
echo total is $last &&
- test `cat last` = 14'
+ test `cat last` = 16'
check_mailinfo () {
mail=$1 opt=$2
@@ -30,6 +30,10 @@ do
if test -f "$TEST_DIRECTORY"/t5100/msg$mail--scissors
then
check_mailinfo $mail --scissors
+ fi &&
+ if test -f "$TEST_DIRECTORY"/t5100/msg$mail--no-inbody-headers
+ then
+ check_mailinfo $mail --no-inbody-headers
fi
'
done
diff --git a/t/t5100/info0015 b/t/t5100/info0015
new file mode 100644
index 0000000..0114f10
--- /dev/null
+++ b/t/t5100/info0015
@@ -0,0 +1,5 @@
+Author:
+Email:
+Subject: check bogus body header (from)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/info0015--no-inbody-headers b/t/t5100/info0015--no-inbody-headers
new file mode 100644
index 0000000..c4d8d77
--- /dev/null
+++ b/t/t5100/info0015--no-inbody-headers
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: check bogus body header (from)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/info0016 b/t/t5100/info0016
new file mode 100644
index 0000000..38ccd0d
--- /dev/null
+++ b/t/t5100/info0016
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: check bogus body header (date)
+Date: bogus
+
diff --git a/t/t5100/info0016--no-inbody-headers b/t/t5100/info0016--no-inbody-headers
new file mode 100644
index 0000000..f4857d4
--- /dev/null
+++ b/t/t5100/info0016--no-inbody-headers
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: check bogus body header (date)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/msg0015 b/t/t5100/msg0015
new file mode 100644
index 0000000..9577238
--- /dev/null
+++ b/t/t5100/msg0015
@@ -0,0 +1,2 @@
+- a list
+ - of stuff
diff --git a/t/t5100/msg0015--no-inbody-headers b/t/t5100/msg0015--no-inbody-headers
new file mode 100644
index 0000000..be5115b
--- /dev/null
+++ b/t/t5100/msg0015--no-inbody-headers
@@ -0,0 +1,3 @@
+From: bogosity
+ - a list
+ - of stuff
diff --git a/t/t5100/msg0016 b/t/t5100/msg0016
new file mode 100644
index 0000000..0d9adad
--- /dev/null
+++ b/t/t5100/msg0016
@@ -0,0 +1,2 @@
+and some content
+
diff --git a/t/t5100/msg0016--no-inbody-headers b/t/t5100/msg0016--no-inbody-headers
new file mode 100644
index 0000000..1063f51
--- /dev/null
+++ b/t/t5100/msg0016--no-inbody-headers
@@ -0,0 +1,4 @@
+Date: bogus
+
+and some content
+
diff --git a/t/t5100/patch0015 b/t/t5100/patch0015
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0015
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/patch0015--no-inbody-headers b/t/t5100/patch0015--no-inbody-headers
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0015--no-inbody-headers
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/patch0016 b/t/t5100/patch0016
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0016
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/patch0016--no-inbody-headers b/t/t5100/patch0016--no-inbody-headers
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0016--no-inbody-headers
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 13fa4ae..de10312 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -650,3 +650,36 @@ index b0b5d8f..461c47e 100644
convert_to_utf8(line, charset.buf);
--
1.6.4.1
+From nobody Mon Sep 17 00:00:00 2001
+From: A U Thor <a.u.thor@example.com>
+Subject: check bogus body header (from)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
+From: bogosity
+ - a list
+ - of stuff
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
+From nobody Mon Sep 17 00:00:00 2001
+From: A U Thor <a.u.thor@example.com>
+Subject: check bogus body header (date)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
+Date: bogus
+
+and some content
+
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH v2 2/2] gitk: add --no-replace-objects option
From: Paul Mackerras @ 2009-11-19 9:01 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Michael J Gruber, Jakub Narebski,
Johannes Sixt, bill lam, Andreas Schwab
In-Reply-To: <20091118065100.4206.48820.chriscool@tuxfamily.org>
Christian Couder writes:
> This option simply sets the GIT_NO_REPLACE_OBJECTS environment
> variable, and that is enough to make gitk ignore replace refs.
For the commit message, could you add a couple of lines telling us
what replace refs are and why you might want gitk to ignore them?
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: Paul Mackerras @ 2009-11-19 9:03 UTC (permalink / raw)
To: David Aguilar; +Cc: peff, sam, git
In-Reply-To: <1258341126-2108-1-git-send-email-davvid@gmail.com>
David Aguilar writes:
> This teaches gitk about git-difftool. A benefit of this change is
> that gitk's external diff now works with read-only repositories.
What version of git does git difftool first appear in? I prefer not
to introduce hard requirements on very recent versions of git into
gitk.
Paul.
^ permalink raw reply
* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Paul Mackerras @ 2009-11-19 9:07 UTC (permalink / raw)
To: Laszlo Papp; +Cc: git, Laszlo Papp
In-Reply-To: <1258284204-17247-1-git-send-email-djszapi@archlinux.us>
Laszlo Papp writes:
> Signed-off-by: Laszlo Papp <djszapi@archlinux.us>
> ---
> gitk-git/po/hu.po | 1151 +++++++++++++++++++++++++++++++++++++++++++++++++++++
Is there a patch 1/2 that needs to be applied first, as the subject
line might imply?
Paul.
^ permalink raw reply
* Re: [gitk] [PATCH] Fix selection of tags.
From: Paul Mackerras @ 2009-11-19 9:33 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git
In-Reply-To: <87r5s0vnas.fsf@users.sourceforge.net>
Pat Thoyts writes:
> When a tag is clicked an error is raised due to a missing parameter in
> a function call.
>
> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: git-svn of both trunk and tags while having no access to the 'parent' of those
From: Eric Wong @ 2009-11-19 9:53 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Yaroslav Halchenko, git
In-Reply-To: <4B040D95.9040901@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Yaroslav Halchenko venit, vidit, dixit 18.11.2009 15:23:
> >
> > On Wed, 18 Nov 2009, Michael J Gruber wrote:
> >>> git svn clone --no-minimize-url --prefix=upstream-svn/ -T trunk -t releases http://domain.com/svnrepo/trunk svnrepo.gitsvn
> >> Is the trunk really at svnrepo/trunk/trunk?
> > nope... it is just svnrepo/trunk but if I set url to point to parent --
> > git svn seeks authentication right away
> >
> >> I would try both
> >> git svn clone --no-minimize-url --prefix=upstream-svn/ -T trunk -t
> >> releases http://domain.com/svnrepo/ svnrepo.gitsvn
> >
> > asks for authentication since there is no public access to
> > http://domain.com/svnrepo/
> >
> >> and also the seemingly equivalent
> >
> >> git svn clone --no-minimize-url --prefix=upstream-svn/ -T
> >> http://domain.com/svnrepo/trunk -t http://domain.com/svnrepo/releases
> >> svnrepo.gitsvn
> > seems to not work since it wants url as a parameter
> >
> > Bad URL passed to RA layer: Illegal repository URL svnrepo.gitsvn at /usr/lib/git-core/git-svn line 940
Hi Michael, Yaroslav,
I think that second command syntax only works for "git svn init" right
now, not sure if it ever worked with "clone".
> >> Also, I assume you can svn list http://domain.com/svnrepo/trunk and
> >> http://domain.com/svnrepo/releases ;)
> > yeap -- I can list both of those but not their parent.
> >
>
> OK, so the way it's implemented --no-minimize-url might be half as
> useful as it could be. One last try (before asking Eric...) would be
>
> git svn clone --no-minimize-url --prefix=upstream-svn/ -T
> http://domain.com/svnrepo/trunk -t http://domain.com/svnrepo/releases
> http://domain.com/svnrepo/trunk svnrepo.gitsvn
>
> because that involves accessible URLs only and trunk and branch URLs are
> absolute.
>
> [Meanwhile I git the actual URL PMed by Yaroslov.]
Any chance I could get that URL? (I probably won't get a chance to
spend time debugging this until Friday). Might be worth it to get an
strace or tcpdump to see what exactly is going on. Or at least some
print statements around Git::SVN::Ra::new()...
> So, what happens with the above is that git-svn tries to set the URL
> config again from the URL part of an absolute tags argument. I don't
> know how absolute URLs (which are documented) for tags etc. could
> possibly work if git-svn tries to do that. Eric?
It looks like support for specifying absolute URLs with "clone"
has been broken for a while. Guess I'll need test cases...
> I tried also with two svn sections to circumvent this:
>
> [svn-remote "svn"]
> url = http://domain.com:/project/trunk
> fetch = :refs/remotes/trunk
> [svn-remote "svnr"]
> url = http://domain.com:/project/releases
> tags = /*:refs/remotes/tags/*
>
> Fetching -Rsvn works fine, but fetching -Rsvnr gives the same
> authentication problems. And fetch does not accept --no-minimize-url as
> an option. OTOH: If the option is not used it seems to me (from the
> source) that not minimizing is the default, which leaves me really
> stomped. Eric?? ;)
Odd that the svnr one doesn't work. Does changing:
tags = /*:refs/remotes/tags/*
to:
tags = *:refs/remotes/tags/*
help at all?
Minimizing should be the default in 1.6.5. I'm a bit stumped, too :x
I'd like to see what network traffic git svn is sending for
the "svnr" case vs "svn ls http://domain.com/project/releases"
--
Eric Wong
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Intland Software @ 2009-11-19 10:06 UTC (permalink / raw)
To: david; +Cc: Petr Baudis, git
In-Reply-To: <alpine.DEB.2.00.0911182205590.5646@asgard.lang.hm>
Hey David,
david@lang.hm wrote:
>> our commercial license doesn't (currently) allow publishing the
>> complete code. We have quite some large customers from the defense space
>> that would not be happy if we opened everything ;)
>
> are you sure? did you see the recent memo about OpenSource by the DOD?
> David Lang
Can you direct us to an URL please? Thanks.
---
Intland
^ permalink raw reply
* Re: Hey - A Conceptual Simplication....
From: Jakub Narebski @ 2009-11-19 10:27 UTC (permalink / raw)
To: George Dennie; +Cc: 'Jason Sewall', 'Jan Krüger', git
In-Reply-To: <009401ca68bc$7e4b12b0$7ae13810$@com>
Side-note: you are employing very strange line wrapping... you should
word wrap your lines so they do not exceed 70-76 characters, and you
should not (except when required for readability) rewrap quoted text.
On Thu, 19 Nov 2009, George Dennie wrote:
> Thanks Linus, Jason, and Jakub...
>
> Linus Torvalds wrote....
>>On Wed, 18 Nov 2009, George Dennie wrote:
>>>
>>> The Git model does not seem to go far enough conceptually, for some
>>> unexplainable reason...
>>
>> Others already mentioned this, but the concept you missed is the git
>> 'index', which is actually very central (it is actually the first
>> part of git written, before even the object database) but is
>> something that most people who get started with git can (and do)
>> ignore.
>
> Uhmmm, subtle. I hear you. Thanks for the heads up. But before that,
> I just put these two cents down...
> [...] Now, I have not had occasions to do merges, as such. So I am
> finding the justification for the index vague. [...]
Errr... you didn't do any merges? What is then your experience with
using version control, then?
As for using index during merge: merge is joining two (or more) lines
of history (lines of development), bringing contents of another branch
into current branch. Some of changes are independent, for example
if one branch changes one file, and other branch changed other file.
This is so called trivial merge, example of tree-level merge. Even
if branches merged touch the same file, if changes were made in separate
sections of file git can merge changes (using three-way merge / diff3
algorithm).
The problem starts if there are changes which touch the same sections
of a file. This generates so called merge conflict (contents conflict),
and you have to resolve such conflict manually.
During merge index helps to manage information about yet unmerged parts.
Let's assume for example that you made a mistake in merge resolution in
some file, and you want to scratch your attempt and try it anew.
Without index it would be very hard to do without trashing resolutions
of other conflicts.
> For example, the functional notion of the repository seems well
> defined: a growing web of immutable commits each created as either
> an isolated commit or more typically an update and/or merger of
> one or more pre-existing commits.
If by "web" you mean DAG (Directed Acyclic Graph) of commits, then
yes, it is _part_ of repository.
There are also refs (branches, tags, remote-tracking branches), which
are also part of repository, very important part. Those are named
references into DAG of commits.
As to commits being created as update of existing commit or from
scratch: that would depend on the way of development. Merge commits
are much, much more rare than ordinary commits (especially that git
favors fast-forwards by default when there is no need for merge).
>
> With such a description the rest of the structure becomes almost
> implicit: Commits may be annotated such as with release number labels.
> Commits that have not been linked to such as by an update or merger
> remain dangling like loose threads in the web and are called branches.
> Branches may be given special labels that the repository will then
> automatically update so as to refer to the latest commit to that
> branch.
Almost right.
> I don't yet have such a clear model for the index. Yes it is a staging
> platform, but so is the IDE....I'll do more reading.
The index is area where you prepare commits, if needed. But you
don't need to care that there is something like the index, and prepare
your commits in working area. But when you need it, it is there.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Jakub Narebski @ 2009-11-19 10:43 UTC (permalink / raw)
To: Intland Software; +Cc: david, Petr Baudis, git
In-Reply-To: <4B0518A3.90903@intland.com>
Intland Software <marketing@intland.com> writes:
> david@lang.hm wrote:
>>> our commercial license doesn't (currently) allow publishing the
>>> complete code. We have quite some large customers from the defense space
>>> that would not be happy if we opened everything ;)
>>
>> are you sure? did you see the recent memo about OpenSource by the
>> DOD?
>
> Can you direct us to an URL please? Thanks.
Indirect links:
* "New DoD memo on Open Source Software" (David A. Wheeler)
http://www.dwheeler.com/blog/2009/10/27/#dod-oss-2009
* "Notes about the DoD and OSS memo" (David A. Wheeler)
http://www.dwheeler.com/blog/2009/10/28/#dod-oss-2009-notes
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Rakotomandimby Mihamina @ 2009-11-19 11:39 UTC (permalink / raw)
To: git
In-Reply-To: <4B03F451.4050709@intland.com>
11/18/2009 04:19 PM, Intland Software::
> We have quite some large customers from the defense space
> that would not be happy if we opened everything
I think they are just dumb.
But they pay you, so let's just say it's OK. :-)
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 33 11 207 36
^ permalink raw reply
* Re: git-svn not fetching all revisions
From: Marcus Better @ 2009-11-19 12:07 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4AFA36F0.6070501@vilain.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sam Vilain wrote:
> Marcus Better wrote:
>> The problem is that the trunk was replaced by a branch at some point.
> Yeah. Try doing it in parts - fetch the two stages of the history
> explicitly using the revision range arguments to 'git svn fetch' - and
> then graft the histories together and fix up with git filter-branch.
Ok, that works, but how can I now sync with the svn repository with git
svn rebase/dcommit? I think the filter-branch rewriting confuses git-svn.
Cheers,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksFNPsACgkQXjXn6TzcAQkr+QCgxQ1r68v2O1Ux7YFoS5IQS1GT
/cgAoLoTgRcIK7vMTJWfmN2XAhcy0eOa
=dnet
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Aron Gombas @ 2009-11-19 12:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: david, Petr Baudis, git
In-Reply-To: <m33a4adcbu.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Intland Software <marketing@intland.com> writes:
>
>> david@lang.hm wrote:
>
>>>> our commercial license doesn't (currently) allow publishing the
>>>> complete code. We have quite some large customers from the defense space
>>>> that would not be happy if we opened everything ;)
>>> are you sure? did you see the recent memo about OpenSource by the
>>> DOD?
>> Can you direct us to an URL please? Thanks.
>
> Indirect links:
> * "New DoD memo on Open Source Software" (David A. Wheeler)
> http://www.dwheeler.com/blog/2009/10/27/#dod-oss-2009
> * "Notes about the DoD and OSS memo" (David A. Wheeler)
> http://www.dwheeler.com/blog/2009/10/28/#dod-oss-2009-notes
Hmm, very interesting reading! Thanks a lot.
---
Intland
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Intland Software @ 2009-11-19 13:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20091118120936.GL17748@machine.or.cz>
Petr Baudis wrote:
> I think a lot of people wonder now, how does this compare to existing
> solutions; from your announcement I thought it's something like
> Gitosis/Gitolite, but in fact it seems more similar to Gitorious or
> GitHub (if it was publicly available, of course); perhaps it would be
All right, some quick comparisons with codeBeamer Managed Repository (MR).
* MR against Gitosis
In terms of access control, MR has the concept of "role", and it makes our security model more fine grained. Permissions
can be set by role. One user account can have multiple roles. Roles are project-dependent. When you add a group to a
project, you can assign multiple roles to the group (which is equivalent with assigning those roles to each group member
one by one).
On the other hand, MR has a much broader scope than Gitosis. MR helps you to manage your repos, to track your
tasks/bugs/issues, to follow commit activities, to browse repos in the web, can be extended using its APIs, etc. (And
you don't have to install and maintain Git extensions for this.)
* MR against Gitolite
Pretty much the same applies here as well.
* MR against GitHub & Gitorious
Probably the most significant difference is that MR is available as free download, and can run behind your firewall.
MR was derived from the source code of our commercial product codeBeamer. CodeBeamer is a full-blown enterprise
collaboration solution, thus MR is likely to focus more on the enterprise needs, not on the "social" aspect.
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Thomas Rast @ 2009-11-19 14:01 UTC (permalink / raw)
To: Intland Software; +Cc: Petr Baudis, git
In-Reply-To: <4B054D0A.5030802@intland.com>
Intland Software wrote:
> * MR against GitHub & Gitorious
> Probably the most significant difference is that MR is available as free download
Umm... unlike Gitorious, you mean:
http://gitorious.org/gitorious
http://gitorious.org/gitorious/mainline/blobs/master/LICENSE
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v4] git remote: Separate usage strings for subcommands
From: Tim Henigan @ 2009-11-19 14:51 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, jrnieder, git
In-Reply-To: <20091119124040.6117@nanako3.lavabit.com>
On Wed, Nov 18, 2009 at 10:40 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Tim Henigan <tim.henigan@gmail.com>
>
>> When the usage string for a subcommand must be printed,
>> only print the information relevant to that command.
>
> I think this is a huge improvement.
>
> Often people look at this part of the manual page to quickly remind
> themselves what options are available, and it is better to keep the
> current text. Some manual pages have to use [options...] when there
> are too many to list, but each subcommand of git-remote doesn't have
> that many options.
... snip ...
> For the same reason, I don't think this is a good change, if these
> lines are used to show the first lines of 'git-remote -h' output.
The original version of this patch [1] left the contents of the usage
strings intact. However, Junio expressed a preference to change
them to use the generic <options>. See this thread for the
discussion [2].
[1] http://article.gmane.org/gmane.comp.version-control.git/133048/
[2] http://thread.gmane.org/gmane.comp.version-control.git/132968/focus=133050
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Intland Software @ 2009-11-19 15:22 UTC (permalink / raw)
To: Thomas Rast; +Cc: Petr Baudis, git
In-Reply-To: <4B05588B.5080501@intland.com>
> Thomas Rast wrote:
>> Intland Software wrote:
>>> * MR against GitHub & Gitorious
>>> Probably the most significant difference is that MR is available as
>>> free download
>>
>> Umm... unlike Gitorious, you mean:
>>
>> http://gitorious.org/gitorious
>> http://gitorious.org/gitorious/mainline/blobs/master/LICENSE
I'm sorry, you're right: Gitorious is also available as download.
Thanks for spotting it, Thomas.
---
Intland
^ permalink raw reply
* [PATCH] expand_user_path: expand ~ to $HOME, not to the actual homedir.
From: Matthieu Moy @ 2009-11-19 15:21 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1258534693-7220-1-git-send-email-Matthieu.Moy@imag.fr>
In 395de250d (Expand ~ and ~user in core.excludesfile, commit.template),
we introduced the mechanism. But expanding ~ using getpw is not what
people overriding $HOME would usually expect. In particular, git looks
for the user's .gitconfig using $HOME, so it's better to be consistent.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
This is basically my patch v4, but since an earlier version is already
in next, I resend the last bits of it, based on next.
Documentation/config.txt | 9 +++++----
path.c | 13 +++++++++----
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 468e285..39d1226 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -381,9 +381,9 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
core.excludesfile::
In addition to '.gitignore' (per-directory) and
'.git/info/exclude', git looks into this file for patterns
- of files which are not meant to be tracked. "~/" and "~user/"
- are expanded to the specified user's home directory. See
- linkgit:gitignore[5].
+ of files which are not meant to be tracked. "~/" is expanded
+ to the value of `$HOME` and "~user/" to the specified user's
+ home directory. See linkgit:gitignore[5].
core.editor::
Commands such as `commit` and `tag` that lets you edit
@@ -683,7 +683,8 @@ color.ui::
commit.template::
Specify a file to use as the template for new commit messages.
- "~/" and "~user/" are expanded to the specified user's home directory.
+ "~/" is expanded to the value of `$HOME` and "~user/" to the
+ specified user's home directory.
diff.autorefreshindex::
When using 'git-diff' to compare with work tree
diff --git a/path.c b/path.c
index b4a8075..2ec950b 100644
--- a/path.c
+++ b/path.c
@@ -235,10 +235,15 @@ char *expand_user_path(const char *path)
if (path[0] == '~') {
const char *username = path + 1;
size_t username_len = first_slash - username;
- struct passwd *pw = getpw_str(username, username_len);
- if (!pw)
- goto return_null;
- strbuf_add(&user_path, pw->pw_dir, strlen(pw->pw_dir));
+ if (username_len == 0) {
+ const char *home = getenv("HOME");
+ strbuf_add(&user_path, home, strlen(home));
+ } else {
+ struct passwd *pw = getpw_str(username, username_len);
+ if (!pw)
+ goto return_null;
+ strbuf_add(&user_path, pw->pw_dir, strlen(pw->pw_dir));
+ }
to_copy = first_slash;
}
strbuf_add(&user_path, to_copy, strlen(to_copy));
--
1.6.5.2.152.gbbe9e
^ permalink raw reply related
* Re: [PATCH 2/2] diffcore-break: save cnt_data for other phases
From: Jeff King @ 2009-11-19 15:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdhanp4v.fsf@alter.siamese.dyndns.org>
On Mon, Nov 16, 2009 at 01:20:00PM -0800, Junio C Hamano wrote:
> The change looks correct, but I initially got worried about your change
> interacts badly with this part in estimate_similarity() around line 176:
>
> if (!src->cnt_data && diff_populate_filespec(src, 0))
> return 0;
> if (!dst->cnt_data && diff_populate_filespec(dst, 0))
> return 0;
>
> I think the reason why it (not your patch but the original code) felt a
> bit brittle is because the above if() statements know too much about the
> internal of d-c-c (namely, it never looks at src->data when src->cnt_data
> is already available, so it is safe to leave src->data NULL).
No, I am counting on those lines to actually optimize out the count
later on. But I agree it is a bit brittle. Probably a better design
would have been for diffcore_count_changes to simply call a new
"diff_filespec_hash", which would assign to the cnt_data member and
perform any optimizations, just as we do already with
diff_populate_filespec and the actual blob contents.
I don't know if it is worth refactoring though. This is a pretty static
part of the code these days, and what is there now is working.
> The same logic suggests that the loop to build the matrix in
> diffcore_rename() could free two->data at the end of the innermost loop.
>
> We currently loop this way (around ll. 505-530):
>
> for each two (i.e. rename destination candidate):
> for each one (i.e. rename source candidate):
> compute and record how similar one and two are
> free one->data
> free two->data
>
> After computing how similar "one" and something else is only once, we have
> one->cnt_data so we won't need one->data (the same fact is exploited by
> your patch for optimization), and that is why freeing one->data in the
> innermost loop does not result in constant re-reading of the same blob
> data when we iterate more than one rename destination. But the same logic
> applies to "two" and we should be able to free the blob data early to
> reduce the memory pressure.
>
> I dunno if it would give us measurable performance benefit, though.
>
> Here is the idea on top of your patch, but I think it can be applied
> independently.
With your patch, I shaved 0.2 seconds off of a 46-second rename
detection (one of my pathological "rename and tweak the tags on a bunch
of photos" commits). To be fair, though, that commit is now quite old,
so some of that CPU time was spent assembling delta chains.
It should also relieve memory pressure for large repositories, though
that is not nearly as big an issue for renames as for breaks, as we tend
to have many fewer candidates.
I think it is worth applying. Though perhaps the free-ing should simply
happen in estimate_similarity, which is the function that actually
populates the filespec.
Also, I don't see where we ever actually free the cnt_data. After we run
the whole O(n^2) loop, we should be able to drop cnt_data entirely. I
think in practice it doesn't matter all that much, since it isn't that
big, and afterwards we just generate the patch and exit (unless we are
doing diffcore-break, too, which will actually free all of the data).
-Peff
^ permalink raw reply
* Re: [PATCH] expand_user_path: expand ~ to $HOME, not to the actual homedir.
From: Jeff King @ 2009-11-19 15:23 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <1258644075-16191-1-git-send-email-Matthieu.Moy@imag.fr>
On Thu, Nov 19, 2009 at 04:21:15PM +0100, Matthieu Moy wrote:
> - of files which are not meant to be tracked. "~/" and "~user/"
> - are expanded to the specified user's home directory. See
> - linkgit:gitignore[5].
> + of files which are not meant to be tracked. "~/" is expanded
> + to the value of `$HOME` and "~user/" to the specified user's
> + home directory. See linkgit:gitignore[5].
Thanks. As a side effect, this wording change addresses my original
ambiguity concern (and I also think using $HOME is the right thing to
do).
-Peff
^ permalink raw reply
* Re: [PATCH v2] git am/mailinfo: Don't look at in-body headers when rebasing
From: Jeff King @ 2009-11-19 15:36 UTC (permalink / raw)
To: Lukas Sandström; +Cc: Philip Hofstetter, Junio C Hamano, git
In-Reply-To: <4B050718.8070506@gmail.com>
On Thu, Nov 19, 2009 at 09:51:36AM +0100, Lukas Sandström wrote:
> When we are rebasing we know that the header lines in the
> patch are good and that we don't need to pick up any headers
> from the body of the patch.
>
> This makes it possible to rebase commits whose commit message
> start with "From" or "Date".
>
> Test vectors by Jeff King.
Thanks, it did end up being a pretty small change. Though I think we may
be better off with _both_ patches. Your patch protects the message
absolutely during rebasing, and my patch improves the heuristic when
applying non-rebase patches.
> @@ -771,6 +772,8 @@ static int handle_commit_msg(struct strbuf *line)
> return 0;
>
> if (still_looking) {
> + if (!use_inbody_headers)
> + still_looking = 0;
> strbuf_ltrim(line);
> if (!line->len)
> return 0;
Hmm. But we still end up in this conditional for the very first line.
Which I guess happens to work because the first line we feed is
presumably the empty blank line (but I didn't check). Still, wouldn't it
be more clear as:
if (use_inbody_headers && still_looking) {
...
in which case still_looking simply becomes irrelevant when the feature
is disabled?
> +From nobody Mon Sep 17 00:00:00 2001
> +From: A U Thor <a.u.thor@example.com>
> +Subject: check bogus body header (from)
> +Date: Fri, 9 Jun 2006 00:44:16 -0700
> +
> +From: bogosity
> + - a list
> + - of stuff
> +---
Since your feature is meant to prevent us looking at inbody headers no
matter if they are valid-looking or not, wouldn't a better test be to
actually have:
From: Other Author <other@example.com>
Otherwise, you don't know if it is your feature blocking it, or my patch
(if it gets applied on top).
> +From nobody Mon Sep 17 00:00:00 2001
> +From: A U Thor <a.u.thor@example.com>
> +Subject: check bogus body header (date)
> +Date: Fri, 9 Jun 2006 00:44:16 -0700
> +
> +Date: bogus
> +
> +and some content
> +
And ditto for the Date here.
-Peff
^ permalink raw reply
* Re: [PATCH] expand_user_path: expand ~ to $HOME, not to the actual homedir.
From: Matthieu Moy @ 2009-11-19 16:32 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
In-Reply-To: <20091119152359.GB6877@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Nov 19, 2009 at 04:21:15PM +0100, Matthieu Moy wrote:
>
>> - of files which are not meant to be tracked. "~/" and "~user/"
>> - are expanded to the specified user's home directory. See
>> - linkgit:gitignore[5].
>> + of files which are not meant to be tracked. "~/" is expanded
>> + to the value of `$HOME` and "~user/" to the specified user's
>> + home directory. See linkgit:gitignore[5].
>
> Thanks. As a side effect, this wording change addresses my original
> ambiguity concern (and I also think using $HOME is the right thing to
> do).
Not a pure coincidence indeed ;-). In this new version, ~ and ~foo do
actually different things so they definitely deserve the heaviness of
a few extra words.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ 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