* [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
* git-cvsserver and (edit|watch) support?
From: david.hagood @ 2009-11-19 17:31 UTC (permalink / raw)
To: git
I have an application that, unfortunately, is both closed source and does
not support GIT natively. However, it DOES support CVS. It also makes
heavy use of CVS's locking features (watch/edit).
git-cvsserver (or at least the version I have, 1.5.6.5), does not seem to
support "cvs watch" or "cvs edit".
Attempting to do a "cvs watch" results in:
cvs watch on *xml
server doesn't support gzip-file-contents
Unknown command watch-on at /usr/bin/git-cvsserver line 198, <STDIN> line 49.
cvs [watch aborted]: end of file from server (consult above messages if any)
Likewise:
cvs edit *xml
server doesn't support gzip-file-contents
Unknown command Notify 7200.xml at /usr/bin/git-cvsserver line 198,
<STDIN> line 6.
cvs [edit aborted]: end of file from server (consult above messages if any)
Are there any plans on supporting these functions?
^ permalink raw reply
* Using `git tag -l` to get non-matching tags
From: Tim Visher @ 2009-11-19 17:49 UTC (permalink / raw)
To: Git Mailing List
Hello Everyone,
I'm trying to use `git tag -l` to get non-matching tags. I can't find
anywhere in the documentation describing what is allowed in the tag
pattern. Brief testing leads me to believe that it's only basic bash
like pattern support.
Thoughts?
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH v4] git remote: Separate usage strings for subcommands
From: Junio C Hamano @ 2009-11-19 18:10 UTC (permalink / raw)
To: Tim Henigan; +Cc: Nanako Shiraishi, jrnieder, git
In-Reply-To: <32c343770911190651w3f1ac9b6i2d3b1a62a032489f@mail.gmail.com>
Tim Henigan <tim.henigan@gmail.com> writes:
> 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
Sorry, but I think you misunderstood what I meant, then. in [2], I said...
> ... hunk to remove literal strings from builtin_remote_usage[]
> ... and replace them with REMOTE_BARE_USAGE, REMOTE_ADD_USAGE
I am not sure about the value of reusing option string like this, and for
Here, please note that I was objecting to the use of _the same string_ in
both contexts ("reusing").
all other subcommands the same comment applies. For example, in the case
of "remote add -h", you would use
"git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
from REMOTE_ADD_USAGE, but ...
> ... hunk to give the builtin_remote_add_usage[] that uses the same
> ... REMOTE_ADD_USAGE to parse_options()
... the options list is used to reproduce the information in a major part
of that string already. So I would prefer builtin_remote_add_usage[] to
be something like:
"git remote add [<options>...] <name> <url>"
I meant that we want to change "remote add -h" to show this here; and the
reason why I doubted "the value of reusing option string" was because I
wanted to do so without touching the concise list of the subcommands and
their options given by "remote -h". Otherwise, it would have made perfect
sense to use preprocessor macros to share the two identical strings.
In your response to my above comment, you indicated that you wanted to do
the [<options>] thing as a separate patch (your original patch spelled
options in full). I took it to mean that you would do that only for the
subcommand help, and did not respond, because
(1) doing that to the subcommand help would be a good idea anyway; and
(2) you will realize what I said in the message about "the value of
reusing option string" was correct when you see the end result, which
will regress "remote -h" output.
In this case, unfortunately (2) didn't happen before Nana pointed it out.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #04; Tue, 17)
From: Junio C Hamano @ 2009-11-19 18:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4B03B315.2080407@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Ramsay suggested to drop the one at the tip, and I agree. The other two
> patches are good.
Thanks; will drop one and queue the rest to 'next'.
^ 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