* Re: [ANNOUNCE] GIT 1.5.4-rc3
From: Ismail Dönmez @ 2008-01-12 7:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejcnwl85.fsf@gitster.siamese.dyndns.org>
Saturday 12 January 2008 09:34:34 tarihinde şunları yazmıştınız:
> sh t9200-git-cvsexportcommit.sh -i -v
Thanks for the tip, I saw the following error :
cvs
commit -F .msg 'A/newfile1.txt' 'B/newfile2.txt' 'C/newfile3.png' 'D/newfile4.png'
cvs [commit aborted]: 'root' is not allowed to commit files
So looks like tests no longer work as root, so I run make test as normal user
and I now see t7300-clean.sh fail, this time a real failure:
Removing part3.c
./test-lib.sh: line 193: 19413 Aborted git-clean
* FAIL 5: git-clean with prefix
mkdir -p build docs &&
touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
(cd src/ && git-clean) &&
test -f Makefile &&
test -f README &&
test -f src/part1.c &&
test -f src/part2.c &&
test -f a.out &&
test ! -f src/part3.c &&
test -f docs/manual.txt &&
test -f obj.o &&
test -f build/lib.so
Regards,
ismail
--
Never learn by your mistakes, if you do you may never dare to try again.
^ permalink raw reply
* Re: [PATCH decompress BUG] Fix decompress_next_from() wrong argument value
From: Marco Costalba @ 2008-01-12 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vir1zwlcw.fsf@gitster.siamese.dyndns.org>
On Jan 12, 2008 8:31 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> By the way, I was looking at the earlier two series from you
> (compress and decompress), and noticed some of them were corrupt
> with linewrap. As I think they are good clean-up patches, I'd
> like to apply them as one of the first series post 1.5.4. As
> such, this request is not urgent at all, but please resend with
> a clean-up when 'master'/'next' reopens.
>
Sure.
Do you prefer patches differently organized or I can keep the same
patch contents (of course with squashing the bug fixes in) ?
Marco
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.4-rc3
From: Junio C Hamano @ 2008-01-12 7:34 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: git, linux-kernel
In-Reply-To: <200801120926.14307.ismail@pardus.org.tr>
Ismail Dönmez <ismail@pardus.org.tr> writes:
> Saturday 12 January 2008 09:11:23 tarihinde Junio C Hamano şunları yazmıştı:
>> The third rc for the next feature release GIT 1.5.4 is available
>> at the usual places:
>>
>> http://www.kernel.org/pub/software/scm/git/
>>
>> git-1.5.4.rc3.tar.{gz,bz2} (tarball)
>> git-htmldocs-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
>> git-manpages-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
>> testing/git-*-1.5.4.rc3-1.$arch.rpm (RPM)
>
> I am seeing new failures compared to rc2 :
>
> *** t9200-git-cvsexportcommit.sh ***
> * FAIL 1: New file
> mkdir A B C D E F &&
> echo hello1 >A/newfile1.txt &&
> echo hello2 >B/newfile2.txt &&
> cp ../test9200a.png C/newfile3.png &&
> cp ../test9200a.png D/newfile4.png &&
> git add A/newfile1.txt &&
> git add B/newfile2.txt &&
> git add C/newfile3.png &&
> git add D/newfile4.png &&
> git commit -a -m "Test: New file" &&
> id=$(git rev-list --max-count=1 HEAD) &&
> (cd "$CVSWORK" &&
> git cvsexportcommit -c $id &&
> check_entries A "newfile1.txt/1.1/" &&
> check_entries B "newfile2.txt/1.1/" &&
> check_entries C "newfile3.png/1.1/-kb" &&
> check_entries D "newfile4.png/1.1/-kb" &&
> diff A/newfile1.txt ../A/newfile1.txt &&
> diff B/newfile2.txt ../B/newfile2.txt &&
> diff C/newfile3.png ../C/newfile3.png &&
> diff D/newfile4.png ../D/newfile4.png
> )
> Ideas appreciated.
Often the first failure is the most interesting one. Running
the test under sh -x like this:
$ cd t
$ sh t9200-git-cvsexportcommit.sh -i -v
and then looking at "trash" directory would tell you which one
of the long sequence of commands failed, and further
investigation can be made from there.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH decompress BUG] Fix decompress_next_from() wrong argument value
From: Junio C Hamano @ 2008-01-12 7:31 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550801112306g6b8127dft80484c9fd8554992@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> The only two points in the current code in master that I would like to
> report to you are a _possible_ missing inflateEnd() before a new
> inflateInit(), but I am not confident with that part of code to judge
> if is a bug or not, anyway that's the _possible_ diff.
>
> diff --git a/http-push.c b/http-push.c
> index 55d0c94..e0a4cc6 100644
> --- a/http-push.c
> +++ b/http-push.c
> @@ -307,6 +307,7 @@ static void start_fetch_loose(struct
> transfer_request *request)
> /* Reset inflate/SHA1 if there was an error reading the previous temp
> file; also rewind to the beginning of the local file. */
> if (prev_read == -1) {
> + inflateEnd(&request->stream);
> memset(&request->stream, 0, sizeof(request->stream));
> inflateInit(&request->stream);
> SHA1_Init(&request->c);
I think this could leak if request->stream already had
something in it, but I do not see anything that is done to it
after it is initialized and the code reaches to this point.
In fact, I suspect that it would make more sense to remove the
earlier memset() that clears request->stream and inflateInit(),
and moving the memset() and inflateInit() we see above out of
that if clause (before checking prev_read).
The same comment applies to the other hunk.
By the way, I was looking at the earlier two series from you
(compress and decompress), and noticed some of them were corrupt
with linewrap. As I think they are good clean-up patches, I'd
like to apply them as one of the first series post 1.5.4. As
such, this request is not urgent at all, but please resend with
a clean-up when 'master'/'next' reopens.
Thanks.
^ permalink raw reply
* Re: [PATCH] Add committer and author names to top of COMMIT_EDITMSG.
From: Stephen Sinclair @ 2008-01-12 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vve5zy72p.fsf@gitster.siamese.dyndns.org>
> You omitted the part that matters from the part you quoted
> above, but this discussion was about "showing AUTHOR if it is
> different from me", which was _one of_ the two conditions I
> suggested in my counterproposal, and I was saying that it is
> useless to expect that you would be able to find a
> misconfiguration when AUTHOR is shown for this first reason.
> This part is _not_ about catching your misconfiguration.
>
> The other part is about the misconfiguration catching.
Okay, sorry I guess I was misreading it because that wasn't really my
original intention with the patch. However in that context I can see
that showing author information when it differs from yourself could
definitely be useful.
> Yes, and earlier you said one of the undesirable ones was
> "yourname@foo.local" (and others were "yourname@foo.(none)").
> IOW, "localhost" is one of the things you want to catch as
> unconfigured bogosity that you want to catch, isn't it?
Well, it was only an example to show that it's easily possible (in
fact, common) to have hostnames that are not configured as actual
email domains. The fact that the hostname contained the word "local"
was an indication, but I'm not really sure that filtering for that
word in the hostname would be such a good idea. I'm also not sure how
many admins will even end up sticking ".local" as their domain, it's
probably just a quirk of the administrator for my lab.
I guess "localhost" really clearly is a "bogus" host name, but other
than that I can't think of any real rules that would make sense.
Rather, IMHO, the error is earlier in the chain: doing anything with
the hostname in the first place.
> To rephrase, you would show AUTHOR when one of the conditions
> holds true, either:
>
> (1) "not me" (so that we can remind that other's commit is
> being amended); _OR_
>
> (2) "funny me" (so that we can catch misconfiguration.
I definitely agree with (1), though having not really done much
amending of other people's commits I can't vouch for it. I think (2)
might not be very reliable.
Since submitting the patch, I have added a post-receive hook to my
repo which checks all incoming commits and verifies whether any names
or email addresses are not in a whitelist. If any are flagged, a
warning is displayed. This is actually quite satisfactory for me,
since it'll warn me when I accidentally push commits with the wrong
name to my private repo, but before I push to public. Let me know if
something like this would be useful for the contrib folder..
Steve
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.4-rc3
From: Ismail Dönmez @ 2008-01-12 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vsl13wmas.fsf@gitster.siamese.dyndns.org>
Saturday 12 January 2008 09:11:23 tarihinde Junio C Hamano şunları yazmıştı:
> The third rc for the next feature release GIT 1.5.4 is available
> at the usual places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.5.4.rc3.tar.{gz,bz2} (tarball)
> git-htmldocs-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
> git-manpages-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
> testing/git-*-1.5.4.rc3-1.$arch.rpm (RPM)
I am seeing new failures compared to rc2 :
*** t9200-git-cvsexportcommit.sh ***
* FAIL 1: New file
mkdir A B C D E F &&
echo hello1 >A/newfile1.txt &&
echo hello2 >B/newfile2.txt &&
cp ../test9200a.png C/newfile3.png &&
cp ../test9200a.png D/newfile4.png &&
git add A/newfile1.txt &&
git add B/newfile2.txt &&
git add C/newfile3.png &&
git add D/newfile4.png &&
git commit -a -m "Test: New file" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
check_entries A "newfile1.txt/1.1/" &&
check_entries B "newfile2.txt/1.1/" &&
check_entries C "newfile3.png/1.1/-kb" &&
check_entries D "newfile4.png/1.1/-kb" &&
diff A/newfile1.txt ../A/newfile1.txt &&
diff B/newfile2.txt ../B/newfile2.txt &&
diff C/newfile3.png ../C/newfile3.png &&
diff D/newfile4.png ../D/newfile4.png
)
* FAIL 2: Remove two files, add two and update two
echo Hello1 >>A/newfile1.txt &&
rm -f B/newfile2.txt &&
rm -f C/newfile3.png &&
echo Hello5 >E/newfile5.txt &&
cp ../test9200b.png D/newfile4.png &&
cp ../test9200a.png F/newfile6.png &&
git add E/newfile5.txt &&
git add F/newfile6.png &&
git commit -a -m "Test: Remove, add and update" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
check_entries A "newfile1.txt/1.2/" &&
check_entries B "" &&
check_entries C "" &&
check_entries D "newfile4.png/1.2/-kb" &&
check_entries E "newfile5.txt/1.1/" &&
check_entries F "newfile6.png/1.1/-kb" &&
diff A/newfile1.txt ../A/newfile1.txt &&
diff D/newfile4.png ../D/newfile4.png &&
diff E/newfile5.txt ../E/newfile5.txt &&
diff F/newfile6.png ../F/newfile6.png
)
* FAIL 4: Remove only binary files
git reset --hard HEAD^^ &&
rm -f D/newfile4.png &&
git commit -a -m "test: remove only a binary file" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
check_entries A "newfile1.txt/1.2/" &&
check_entries B "" &&
check_entries C "" &&
check_entries D "" &&
check_entries E "newfile5.txt/1.1/" &&
check_entries F "newfile6.png/1.1/-kb" &&
diff A/newfile1.txt ../A/newfile1.txt &&
diff E/newfile5.txt ../E/newfile5.txt &&
diff F/newfile6.png ../F/newfile6.png
)
* FAIL 5: Remove only a text file
rm -f A/newfile1.txt &&
git commit -a -m "test: remove only a binary file" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
check_entries A "" &&
check_entries B "" &&
check_entries C "" &&
check_entries D "" &&
check_entries E "newfile5.txt/1.1/" &&
check_entries F "newfile6.png/1.1/-kb" &&
diff E/newfile5.txt ../E/newfile5.txt &&
diff F/newfile6.png ../F/newfile6.png
)
* FAIL 6: New file with spaces in file name
mkdir "G g" &&
echo ok then >"G g/with spaces.txt" &&
git add "G g/with spaces.txt" && \
cp ../test9200a.png "G g/with spaces.png" && \
git add "G g/with spaces.png" &&
git commit -a -m "With spaces" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git-cvsexportcommit -c $id &&
check_entries "G g" "with spaces.png/1.1/-kb|with
spaces.txt/1.1/"
)
* FAIL 7: Update file with spaces in file name
echo Ok then >>"G g/with spaces.txt" &&
cat ../test9200a.png >>"G g/with spaces.png" && \
git add "G g/with spaces.png" &&
git commit -a -m "Update with spaces" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git-cvsexportcommit -c $id
check_entries "G g" "with spaces.png/1.2/-kb|with
spaces.txt/1.2/"
)
* FAIL 8: File with non-ascii file name
mkdir -p
Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö &&
echo Foo
>Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/gårdetsågårdet.txt
&&
git add
Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/gårdetsågårdet.txt
&&
cp ../test9200a.png
Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/gårdetsågårdet.png
&&
git add
Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/gårdetsågårdet.png
&&
git commit -a -m "Går det så går det" && \
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git-cvsexportcommit -v -c $id &&
check_entries \
"Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö"
\
"gårdetsågårdet.png/1.1/-kb|gårdetsågårdet.txt/1.1/"
)
[...]
* failed 7 among 10 test(s)
Ideas appreciated.
/ismail
--
Never learn by your mistakes, if you do you may never dare to try again.
^ permalink raw reply
* [PATCH] git-svn: handle leading/trailing whitespace from svnsync revprops
From: Eric Wong @ 2008-01-12 7:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dennis Schridde, git
In-Reply-To: <7vmyrd5p81.fsf@gitster.siamese.dyndns.org>
Repositories generated by svnsync cannot be relied on to have
properly set revprops without newlines in UUIDs and URLs. There
may be broken versions of svnsync out there that append extra
newlines to UUIDs, or the revprops could've been changed by
repository administrators at any time, too.
At least one repository we've come across has an embedded
newline erroneously set in the svnsync-uuid prop. This is bad
because the trailing newline is taken as another record by the
Git.pm library, and the wantarray detection causes tmp_config()
to return an array with an empty-but-existing second element.
We will now strip leading and trailing whitespace both before
setting and after reading the uuid and url for svnsync values.
We will also force tmp_config to return a single scalar when
reading existing values.
SVN UUIDs should never have whitespace in them, and SVN
repository URLs should be URI-escaped, so neither of those
values we ever see in git-svn should actually have whitespace
in them.
Thanks to Dennis Schridde for the bug report and Junio for
helping diagnose this.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 18 ++++++++++++------
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 3308fe1..f40ad2c 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1758,10 +1758,16 @@ sub svnsync {
# see if we have it in our config, first:
eval {
my $section = "svn-remote.$self->{repo_id}";
- $svnsync = {
- url => tmp_config('--get', "$section.svnsync-url"),
- uuid => tmp_config('--get', "$section.svnsync-uuid"),
- }
+
+ my $url = tmp_config('--get', "$section.svnsync-url");
+ ($url) = ($url =~ m{^([a-z\+]+://\S+)$}) or
+ die "doesn't look right - svn:sync-from-url is '$url'\n";
+
+ my $uuid = tmp_config('--get', "$section.svnsync-uuid");
+ ($uuid) = ($uuid =~ m{^([0-9a-f\-]{30,})$}) or
+ die "doesn't look right - svn:sync-from-uuid is '$uuid'\n";
+
+ $svnsync = { url => $url, uuid => $uuid }
};
if ($svnsync && $svnsync->{url} && $svnsync->{uuid}) {
return $self->{svnsync} = $svnsync;
@@ -1772,11 +1778,11 @@ sub svnsync {
my $rp = $self->ra->rev_proplist(0);
my $url = $rp->{'svn:sync-from-url'} or die $err . "url\n";
- $url =~ m{^[a-z\+]+://} or
+ ($url) = ($url =~ m{^([a-z\+]+://\S+)$}) or
die "doesn't look right - svn:sync-from-url is '$url'\n";
my $uuid = $rp->{'svn:sync-from-uuid'} or die $err . "uuid\n";
- $uuid =~ m{^[0-9a-f\-]{30,}$} or
+ ($uuid) = ($uuid =~ m{^([0-9a-f\-]{30,})$}) or
die "doesn't look right - svn:sync-from-uuid is '$uuid'\n";
my $section = "svn-remote.$self->{repo_id}";
--
Eric Wong
^ permalink raw reply related
* [ANNOUNCE] GIT 1.5.4-rc3
From: Junio C Hamano @ 2008-01-12 7:11 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The third rc for the next feature release GIT 1.5.4 is available
at the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.4.rc3.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
testing/git-*-1.5.4.rc3-1.$arch.rpm (RPM)
Sorry, this is a few days late than I promised. Partly due to
day-job pressure, partly because I am not familiar with RPM spec
file and ended up failing to get the spec file into a reasonable
shape after gitk i18n merge more than twice, and partly because
I involved myself to discussion on the list I should not have
been deeply involved in during the rc freeze.
In any case, we managed to keep the changes only to fixes (both
code and documentation) this round, aside from the promised gitk
i18n enhancements. This should be pretty much the same as what
we will have in final, hopefully due by the end of the month.
Please give it a good beating. Especially if you care about the
final RPM, and you are familiar with RPM generation, I would
appreciate extra set of eyeballs to see if dependencies and
other metainformation is set up correctly, as I do not think
many people have tested it.
----------------------------------------------------------------
Changes since v1.5.4-rc2 are as follows:
Alexandre Julliard (6):
git.el: Support for getting diffs from inside the log-edit buffer.
git.el: Retrieve the permissions for up-to-date files.
git.el: Display file types and type changes.
git.el: Make sure we never insert the same file twice.
git.el: Refresh files from their real state upon commit.
git.el: Make status refresh faster.
Bernt Hansen (1):
git-gui: Make commit log messages end with a newline
Brandon Casey (1):
git-relink.txt: describe more clearly how hard linking occurs
Charles Bailey (1):
gitk: Fix the Makefile to cope with systems lacking msgfmt
Christian Couder (1):
Documentation: config: add 'help.*' and 'instaweb.*' variables.
Christian Stimming (10):
gitk i18n: Add Makefile with rules for po file creation and installation
gitk i18n: Import msgcat for message string translation; load translation catalogs
gitk i18n: Markup several strings for translation
gitk i18n: Initial German translation
gitk i18n: More markup -- various options menus
gitk i18n: Recode gitk from latin1 to utf8 so that the (c) copyright character is valid utf8.
gitk: Update and fix Makefile
gitk: Update German translation
gitk: Fix typo in user message.
gitk: Update German translation.
Dan McGee (1):
Documentation: rename gitlink macro to linkgit
Eric Wong (4):
git-svn: allow dcommit --no-rebase to commit multiple, dependent changes
git-svn: unlink index files that were globbed, too
git-svn: support for funky branch and project names over HTTP(S)
git-svn: clarify the "Ignoring error from SVN" piece
Florian La Roche (1):
Change git-gc documentation to reflect gc.packrefs implementation.
Gerrit Pape (1):
gitk: use user-configured background in view definition dialog
Grégoire Barbier (1):
Fix double-free() in http-push.c:remote_exists()
Gustaf Hendeby (1):
Documentation/user-manual.txt: fix typo
J. Bruce Fields (1):
Documentation: fix remote.<name>.skipDefaultUpdate description
James Bowes (1):
Make the git metapackage require the same version of the subpackages.
Jeff King (8):
config: handle lack of newline at end of file better
git-reset: refuse to do hard reset in a bare repository
add a "basic" diff config callback
diff: load funcname patterns in "basic" config
diff: remove lazy config loading
add--interactive: remove unused diff colors
add--interactive: allow diff colors without interactive colors
Document the color.interactive semantics
Jim Meyering (3):
Fix grammar nits in documentation and in code comments.
Don't access line[-1] for a zero-length "line" from fgets.
bundle, fast-import: detect write failure
Johannes Schindelin (2):
Optimize prefixcmp()
shortlog: mention the "-e" option in the usage
Johannes Sixt (2):
git-gui: Move frequently used commands to the top of the context menu.
recv_sideband: Do not use ANSI escape sequence on dumb terminals.
Junio C Hamano (27):
Documentation/git-submodule.txt: typofix
"git pull --tags": error out with a better message.
git-rebase -i behaves better on commits with incomplete messages
git-rebase -i: clean-up error check codepath.
lock_any_ref_for_update(): reject wildcard return from check_ref_format
Update callers of check_ref_format()
Uninline prefixcmp()
git-clean: make "Would remove ..." path relative to cwd again
t/t7600: avoid GNUism in grep
t/t{3600,3800,5401}: do not use egrep when grep would do
t/t3800: do not use a temporary file to hold expected result.
Update draft release notes for 1.5.4
git-stash clear: refuse to work with extra parameter for now
git-rev-parse --symbolic-full-name
filter-branch: work correctly with ambiguous refnames
custom pretty format: tolerate empty e-mail address
Documentation: remove gitman.info with "make clean"
Documentation: fix "gitlink::foobar[s]"
utf8: pick_one_utf8_char()
utf8_width(): allow non NUL-terminated input
diff: do not chomp hunk-header in the middle of a character
Update draft release notes for 1.5.4
GIT 1.5.3.8
"git-apply --check" should not report "fixed"
pack-objects: remove redundant and wrong call to deflateEnd()
RPM spec: include gitk message files.
GIT 1.5.4-rc3
Kevin Ballard (1):
Trim leading / off of paths in git-svn prop_walk
Marco Costalba (2):
Document git-reset defaults to HEAD if no commit is given
git-stash: use stdout instead of stderr for non error messages
Mark Levedahl (2):
git-gui: Unconditionally use absolute paths with Cygwin
Documentation/Makefile - honor $DESTDIR for quick-install target
Martin Koegler (4):
receive-pack: check object type of sha1 before using them as commits
receive-pack: reject invalid refnames
parse_tag_buffer: don't parse invalid tags
tree-walk: don't parse incorrect entries
Michael Stefaniuc (1):
git-am: Run git gc only once and not for every patch.
Michele Ballabio (1):
Document some default values in config.txt
Miklos Vajna (2):
git-sh-setup: document git_editor() and get_author_ident_from_commit()
t/t7001: avoid unnecessary ERE when using grep
Nicolas Pitre (1):
slightly better auto gc message
Paul Mackerras (2):
gitk: Recode de.po to UTF-8
gitk: Restore some widget options whose defaults changed in Tk 8.5
Peter Karlsson (1):
Added Swedish translation.
Ralf Wildenhues (1):
Documentation: typofix
Rogan Dawes (1):
Allow git-mergetool to handle paths with a leading space
Shawn O. Pearce (1):
git-gui: Handle file mode changes (644->755) in diff viewer
^ permalink raw reply
* Re: [PATCH decompress BUG] Fix decompress_next_from() wrong argument value
From: Marco Costalba @ 2008-01-12 7:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vfxx3290v.fsf@gitster.siamese.dyndns.org>
On Jan 12, 2008 1:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Next time around, please mark the patch on the Subject: line to
> be squashed to your earlier [PATCH 5/6] before [PATCH 6/6].
>
Very sorry for wasting your time I should have been more clear that it
was a bug in the new series. And of course this series is not to be
applied to stable git.
The only two points in the current code in master that I would like to
report to you are a _possible_ missing inflateEnd() before a new
inflateInit(), but I am not confident with that part of code to judge
if is a bug or not, anyway that's the _possible_ diff.
diff --git a/http-push.c b/http-push.c
index 55d0c94..e0a4cc6 100644
--- a/http-push.c
+++ b/http-push.c
@@ -307,6 +307,7 @@ static void start_fetch_loose(struct
transfer_request *request)
/* Reset inflate/SHA1 if there was an error reading the previous temp
file; also rewind to the beginning of the local file. */
if (prev_read == -1) {
+ inflateEnd(&request->stream);
memset(&request->stream, 0, sizeof(request->stream));
inflateInit(&request->stream);
SHA1_Init(&request->c);
diff --git a/http-walker.c b/http-walker.c
index 2c37868..a18067c 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -182,6 +182,7 @@ static void start_object_request(struct walker *walker,
/* Reset inflate/SHA1 if there was an error reading the previous temp
file; also rewind to the beginning of the local file. */
if (prev_read == -1) {
+ inflateEnd(&obj_req->stream);
memset(&obj_req->stream, 0, sizeof(obj_req->stream));
inflateInit(&obj_req->stream);
SHA1_Init(&obj_req->c);
I have not created a proper patch becuase I don't know if the missing
inflateEnd(), it is a bug or not. The above diff it's just a way to
point you quickly and hopefully clearly to the interested code .
Sorry again for the trouble I had caused to you. For sure I will be
much more careful in the future to be clear in the subjects. And also
sorry for my rant but it was very late and I was tired after fighting
with that _my_ bug.
Marco
^ permalink raw reply related
* Re: [PATCH] Teach remote machinery about remotes.default config variable
From: Junio C Hamano @ 2008-01-12 6:27 UTC (permalink / raw)
To: Mark Levedahl; +Cc: git
In-Reply-To: <47885B2C.8020809@gmail.com>
Mark Levedahl <mlevedahl@gmail.com> writes:
> Junio C Hamano wrote:
>> Mark Levedahl <mlevedahl@gmail.com> writes:
>>
>> It's that simple. Isn't it?
>>
> Yes, until you hit submodules whose state you are managing from a
> super project. Then it gets hard because the machinery brings origin
> into play.
Sorry, I may be missing something.
Even if you have a submodule, you can go there and that will be
a valid freestanding repository. You can always be explicit,
bypassing any behaviour that defaults to 'origin' to avoid
ambiguity.
^ permalink raw reply
* Re: [PATCH] Teach remote machinery about remotes.default config variable
From: Mark Levedahl @ 2008-01-12 6:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbq7ry405.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Mark Levedahl <mlevedahl@gmail.com> writes:
>
>
>
> It's that simple. Isn't it?
>
>
Yes, until you hit submodules whose state you are managing from a super
project. Then it gets hard because the machinery brings origin into play.
Mark
^ permalink raw reply
* Re: [PATCH] Teach remote machinery about remotes.default config variable
From: Junio C Hamano @ 2008-01-12 6:03 UTC (permalink / raw)
To: Mark Levedahl; +Cc: git
In-Reply-To: <478855B5.9070600@gmail.com>
Mark Levedahl <mlevedahl@gmail.com> writes:
> My use really is a different use-case than is typical....
>
> This breaks down in a project like mine where there are multiple
> servers and the differences are important. Content and usage vary
> server to server, not just connectivity. At this point, hiding the
> server names is counterproductive. Basically, use of origin is data
> hiding, and data hiding is not good when you actually need the data.
If you need explicit name, you do not have to use "origin".
You can spell URL explicitly to name which exact repository you
mean to reach over which datapath (one physical host may have
different name depending on the network interface you reach it
via). You can always say
$ git pull git://that.exact.machine/repo that-branch
if you want to avoid ambiguity.
And that is not atypical at all. Scan the kernel mailing list,
looking for "please pull" requests. You will never see 'origin'
or any short nickname. The names used in communication should
be unambiguous in the context of the communication. If you know
'origin' mean different things to different people, do not use
that in public communication.
It's that simple. Isn't it?
^ permalink raw reply
* Re: [PATCH] Add committer and author names to top of COMMIT_EDITMSG.
From: Jeff King @ 2008-01-12 5:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Sinclair, git
In-Reply-To: <7vhchjy4cg.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 11, 2008 at 09:56:15PM -0800, Junio C Hamano wrote:
> > list (ISTR that Linus _likes_ pulling the hostname from gecos).
>
> You do not pull hostname from gecos, but I agree with your main
> point.
Heh. Sorry, the sentence made more sense before I edited it.
-Peff
^ permalink raw reply
* Re: [PATCH] Add committer and author names to top of COMMIT_EDITMSG.
From: Junio C Hamano @ 2008-01-12 5:56 UTC (permalink / raw)
To: Jeff King; +Cc: Stephen Sinclair, git
In-Reply-To: <20080112053225.GA6059@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Jan 11, 2008 at 09:30:24PM -0800, Junio C Hamano wrote:
>
>> I think what we could do if we wanted to protect people from
>> unconfigured identity is to stop pulling names from gecos and
>> hostname, and respect _only_ environment and config.
>
> I am fine with that, as I have always set up the configuration manually
> anyway. But I think it would need a significant comment period from the
> list (ISTR that Linus _likes_ pulling the hostname from gecos).
You do not pull hostname from gecos, but I agree with your main
point.
^ permalink raw reply
* [PATCH] git-submodule - Possibly inherit parent's default remote on init/clone
From: Mark Levedahl @ 2008-01-12 5:54 UTC (permalink / raw)
To: gitster; +Cc: git, Mark Levedahl
In-Reply-To: <1200117273-3524-3-git-send-email-mlevedahl@gmail.com>
For submodules defined relative to their parent, it is likely that the
parent's defined default remote is correct for the child as well. This
allows use of remote names other than "origin", important as managed
submodules are typically checked out on a detached head and therefore
submodule-update invokes git-fetch using the default remote. Without this
change, submodules effectively had to have a default remote of "origin."
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
Documentation/git-submodule.txt | 8 +++++---
git-submodule.sh | 19 +++++++++++++------
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index cffc6d4..440e234 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -36,9 +36,11 @@ status::
init::
Initialize the submodules, i.e. register in .git/config each submodule
- name and url found in .gitmodules. The key used in .git/config is
- `submodule.$name.url`. This command does not alter existing information
- in .git/config.
+ name and url found in .gitmodules, along with the default remote origin.
+ For submodules using a relative url, the default remote is inherited
+ from the parent project, for absolute urls the default "origin" is used.
+ The key used in .git/config is submodule.$name.url`. This command does
+ not alter existing information in .git/config.
update::
Update the registered submodules, i.e. clone missing submodules and
diff --git a/git-submodule.sh b/git-submodule.sh
index ad9fe62..42be4b9 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -7,6 +7,7 @@
USAGE='[--quiet] [--cached] [add <repo> [-b branch]|status|init|update] [--] [<path>...]'
OPTIONS_SPEC=
. git-sh-setup
+. git-parse-remote
require_work_tree
add=
@@ -43,9 +44,7 @@ get_repo_base() {
# Resolve relative url by appending to parent's url
resolve_relative_url ()
{
- branch="$(git symbolic-ref HEAD 2>/dev/null)"
- remote="$(git config branch.${branch#refs/heads/}.remote)"
- remote="${remote:-origin}"
+ remote="$(get_default_remote)"
remoteurl="$(git config remote.$remote.url)" ||
die "remote ($remote) does not have a url in .git/config"
url="$1"
@@ -95,6 +94,7 @@ module_clone()
{
path=$1
url=$2
+ origin=${3:-origin}
# If there already is a directory at the submodule path,
# expect it to be empty (since that is the default checkout
@@ -110,7 +110,7 @@ module_clone()
test -e "$path" &&
die "A file already exist at path '$path'"
- git-clone -n "$url" "$path" ||
+ git-clone -n -o "$origin" "$url" "$path" ||
die "Clone of '$url' into submodule path '$path' failed"
}
@@ -130,9 +130,11 @@ module_add()
usage
fi
+ origin=origin
case "$repo" in
./*|../*)
# dereference source url relative to parent's url
+ origin=$(get_default_remote)
realrepo="$(resolve_relative_url $repo)" ;;
*)
# Turn the source into an absolute path if
@@ -157,7 +159,7 @@ module_add()
git ls-files --error-unmatch "$path" > /dev/null 2>&1 &&
die "'$path' already exists in the index"
- module_clone "$path" "$realrepo" || exit
+ module_clone "$path" "$realrepo" "$origin" || exit
(unset GIT_DIR; cd "$path" && git checkout -q ${branch:+-b "$branch" "origin/$branch"}) ||
die "Unable to checkout submodule '$path'"
git add "$path" ||
@@ -189,12 +191,15 @@ modules_init()
die "No url found for submodule path '$path' in .gitmodules"
# Possibly a url relative to parent
+ origin=origin
case "$url" in
./*|../*)
url="$(resolve_relative_url "$url")"
+ origin=$(get_default_remote)
;;
esac
+ git config submodule."$name".origin "$origin" &&
git config submodule."$name".url "$url" ||
die "Failed to register url for submodule path '$path'"
@@ -222,10 +227,12 @@ modules_update()
say "Submodule path '$path' not initialized"
continue
fi
+ origin=$(git config submodule."$name".origin)
+ origin=${origin:-origin}
if ! test -d "$path"/.git
then
- module_clone "$path" "$url" || exit
+ module_clone "$path" "$url" "$origin" || exit
subsha1=
else
subsha1=$(unset GIT_DIR; cd "$path" &&
--
1.5.4.rc2.98.g1f3d5
^ permalink raw reply related
* [PATCH] git-clone - Set remotes.origin config variable
From: Mark Levedahl @ 2008-01-12 5:54 UTC (permalink / raw)
To: gitster; +Cc: git, Mark Levedahl
In-Reply-To: <1200117273-3524-2-git-send-email-mlevedahl@gmail.com>
This records the users choice of default remote name (by default "origin")
as given by the -o option.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
Documentation/git-clone.txt | 3 ++-
git-clone.sh | 1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index fdccbd4..6c15fa4 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -95,7 +95,8 @@ OPTIONS
--origin <name>::
-o <name>::
Instead of using the remote name 'origin' to keep track
- of the upstream repository, use <name> instead.
+ of the upstream repository, use <name> instead. The name
+ is recorded in the core.origin config variable.
--upload-pack <upload-pack>::
-u <upload-pack>::
diff --git a/git-clone.sh b/git-clone.sh
index b4e858c..7208d68 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -242,6 +242,7 @@ fi &&
export GIT_DIR &&
GIT_CONFIG="$GIT_DIR/config" git-init $quiet ${template+"$template"} || usage
+git config core.origin $origin
if test -n "$bare"
then
GIT_CONFIG="$GIT_DIR/config" git config core.bare true
--
1.5.4.rc2.98.g1f3d5
^ permalink raw reply related
* [PATCH] git-remote - Unset core.origin when deleting the default remote
From: Mark Levedahl @ 2008-01-12 5:54 UTC (permalink / raw)
To: gitster; +Cc: git, Mark Levedahl
In-Reply-To: <1200117273-3524-1-git-send-email-mlevedahl@gmail.com>
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
git-remote.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git-remote.perl b/git-remote.perl
index d13e4c1..75d2371 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -328,6 +328,11 @@ sub rm_remote {
$git->command('config', '--remove-section', "remote.$name");
+ my $defremote = $git->config("core.origin");
+ if (defined $defremote && $defremote eq $name) {
+ $git->command("config", "--unset", "core.origin");
+ }
+
eval {
my @trackers = $git->command('config', '--get-regexp',
'branch.*.remote', $name);
--
1.5.4.rc2.98.g1f3d5
^ permalink raw reply related
* [PATCH] Teach remote machinery about core.origin config variable
From: Mark Levedahl @ 2008-01-12 5:54 UTC (permalink / raw)
To: gitster; +Cc: git, Mark Levedahl
In-Reply-To: <7v63xzzszp.fsf@gitster.siamese.dyndns.org>
This introduces a new configuration variable, core.origin, that
defines the name of the default remote to be used. Traditionally, this
is "origin", and could be overridden for a given branch. This change
introduces a way to redefine the default as desired and have that honored
regardless of the currently checked out head (e.g., core.origin is
used when on a detached head or any other non-tracking branch).
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
Documentation/config.txt | 6 ++++++
git-parse-remote.sh | 5 +++--
remote.c | 11 ++++++++++-
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1b6d6d6..a0bdf14 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -291,6 +291,12 @@ core.editor::
`GIT_EDITOR` environment, `core.editor`, `VISUAL` and
`EDITOR` environment variables and then finally `vi`.
+core.origin::
+ The name of the remote used by default for fetch / pull. If unset,
+ origin is assumed. This value is used whenever the current branch
+ has no corresponding branch.<name>.remote, such as when working on
+ a detached head.
+
core.pager::
The command that git will use to paginate output. Can be overridden
with the `GIT_PAGER` environment variable.
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 695a409..c7ac7c7 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -56,8 +56,9 @@ get_remote_url () {
get_default_remote () {
curr_branch=$(git symbolic-ref -q HEAD | sed -e 's|^refs/heads/||')
- origin=$(git config --get "branch.$curr_branch.remote")
- echo ${origin:-origin}
+ git config --get "branch.$curr_branch.remote" ||
+ git config --get "core.origin" ||
+ echo origin
}
get_remote_default_refs_for_push () {
diff --git a/remote.c b/remote.c
index 0e00680..302d499 100644
--- a/remote.c
+++ b/remote.c
@@ -10,6 +10,7 @@ static int allocated_branches;
static struct branch *current_branch;
static const char *default_remote_name;
+static const char *core_origin;
#define BUF_SIZE (2048)
static char buffer[BUF_SIZE];
@@ -233,6 +234,11 @@ static int handle_config(const char *key, const char *value)
add_merge(branch, xstrdup(value));
return 0;
}
+ if (!strcmp(key, "core.origin")) {
+ if (value)
+ core_origin = xstrdup(value);
+ return 0;
+ }
if (prefixcmp(key, "remote."))
return 0;
name = key + 7;
@@ -291,7 +297,6 @@ static void read_config(void)
int flag;
if (default_remote_name) // did this already
return;
- default_remote_name = xstrdup("origin");
current_branch = NULL;
head_ref = resolve_ref("HEAD", sha1, 0, &flag);
if (head_ref && (flag & REF_ISSYMREF) &&
@@ -300,6 +305,10 @@ static void read_config(void)
make_branch(head_ref + strlen("refs/heads/"), 0);
}
git_config(handle_config);
+ if (!default_remote_name) {
+ default_remote_name = core_origin ?
+ core_origin : xstrdup("origin");
+ }
}
struct refspec *parse_ref_spec(int nr_refspec, const char **refspec)
--
1.5.4.rc2.98.g1f3d5
^ permalink raw reply related
* Re: [PATCH] Teach remote machinery about remotes.default config variable
From: Mark Levedahl @ 2008-01-12 5:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63xzzszp.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> "Mark Levedahl" <mlevedahl@gmail.com> writes:
>
> Thanks.
>
> I have to admit that I happen to agree with Dscho. I do not see
> this helping to solve communication issues very much.
>
Junio,
My use really is a different use-case than is typical. Origin is a great
concept for the common case of projects with a single upstream
repository. Except for cloning, you don't have to know or care the name
of the upstream as you move from project to project, it is just always
"origin" and you use the same remote nickname in each.
This breaks down in a project like mine where there are multiple servers
and the differences are important. Content and usage vary server to
server, not just connectivity. At this point, hiding the server names is
counterproductive. Basically, use of origin is data hiding, and data
hiding is not good when you actually need the data.
Across the git project, I believe everyone basically understands origin
as git.kernel.org/..., and origin is not ambiguous. There is just one
server. For my project, there are multiple servers and a number of us
pull from and push to multiple servers with no intent that any one
server has everything (This multiplicity is necessary for several
reasons, and we have various guards in place restrict the content of
different servers). Thus, there really is no usefully defined *origin*.
There just isn't. This is where the disagreements lie.
The argument against my approach of explicitly naming the server rests
upon the premise that hiding a half-dozen servers, all different and
with those differences being important, under the single universal name
"origin", makes things easier. It doesn't when different servers are
different. Yes, it is possible to figure out what "origin" means at a
given client, and thus understand how to address a given server from
that client. That is the essence of the problem. It is clear to address
server1 as "server1", and server3 as "server3." It is not helpful to
sometimes refer to server1 as origin, sometimes as server3, and thus
need to know the definition of origin to know how to name the server.
For the "normal" git use-case the specific definition of origin is
unimportant when you use it and so provides a useful abstraction. That I
must know what origin means in order to know what to do indicates the
abstraction is counter-productive.
Until we started using sub-modules, we used git clone --origin
<nickname> and per our standard usage never even had "origin" defined.
We just agreed on a common set of nicknames for our servers and used
those. Not everyone had all the remotes defined, but nickname "foo"
meant the same thing everywhere it was defined. That worked very well
for us.
So, all I am doing here is trying to extend a basic multi-server
capability git already has for a monolithic project into projects using
sub-modules. This will let us resume working the way we did before and
stop overloading a single nickname (origin) with multiple meanings.
Mark
^ permalink raw reply
* Re: [PATCH] Add committer and author names to top of COMMIT_EDITMSG.
From: Jeff King @ 2008-01-12 5:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Sinclair, git
In-Reply-To: <7vlk6vy5jj.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 11, 2008 at 09:30:24PM -0800, Junio C Hamano wrote:
> I think what we could do if we wanted to protect people from
> unconfigured identity is to stop pulling names from gecos and
> hostname, and respect _only_ environment and config.
I am fine with that, as I have always set up the configuration manually
anyway. But I think it would need a significant comment period from the
list (ISTR that Linus _likes_ pulling the hostname from gecos).
-Peff
^ permalink raw reply
* Re: [PATCH] Add committer and author names to top of COMMIT_EDITMSG.
From: Junio C Hamano @ 2008-01-12 5:30 UTC (permalink / raw)
To: Jeff King; +Cc: Stephen Sinclair, git
In-Reply-To: <7vprw7y6mz.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> This is obviously not 1.5.4 material, so I haven't given it that much
>> thought either. But perhaps Stephen's "author message" should simply
>> trigger any time the author is pulled from gecos?
I think what we could do if we wanted to protect people from
unconfigured identity is to stop pulling names from gecos and
hostname, and respect _only_ environment and config.
And fail any operation that we would want configured name and
email (names in reflog does not count as such an operation ---
we've made that mistake once, which made "git clone" impossible
before setting up $HOME/.gitconfig).
That I think I can live with.
If we do that, we do not have to see two extra lines (COMMITTER
and AUTHOR) that spells our own name in the commit message
buffer, which almost always will be a total waste of space.
^ permalink raw reply
* Re: [PATCH] Add committer and author names to top of COMMIT_EDITMSG.
From: Junio C Hamano @ 2008-01-12 5:06 UTC (permalink / raw)
To: Jeff King; +Cc: Stephen Sinclair, git
In-Reply-To: <20080112045231.GB5211@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This is obviously not 1.5.4 material, so I haven't given it that much
> thought either. But perhaps Stephen's "author message" should simply
> trigger any time the author is pulled from gecos? I suppose that would
> annoy people who use this feature all the time, but they can silence the
> "warning" with a simple git-config.
Well, we could certainly do that.
But I am not entirely happy with the idea of having to make the
default silly and inconvenient, only because otherwise new
people who did not even bother to read and follow the VERY FIRST
subsection of the tutorial that tells them that the first thing
to do is to use user.name and user.email would not notice their
problems, and experts know enough to squelch that broken
default. Middle level people (and newbies will quickly become
one of them) will be inconvenienced even though they followed
the tutorial's instruction, until they find the configuration
variable to turn that silly AUTHOR output off.
^ permalink raw reply
* Re: [PATCH] gitk: Update and fix Makefile
From: Jeff King @ 2008-01-12 5:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, Christian Stimming, git
In-Reply-To: <7vr6gn29w1.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 11, 2008 at 03:57:34PM -0800, Junio C Hamano wrote:
> I agree with you that both are valid spellings, but when I
> received 9e5d87d49070fe0463040e826824d6ce41beb089, I consulted a
> couple of dictionaries and descendant seemed to be more widely
> used. Besides, I think the german translation update depends on
> it ;-).
Descendant is a noun, whereas descendent is an adjective. Though like
many such distinctions, the two forms increasingly are used
interchangeably.
-Peff
^ permalink raw reply
* Re: Signing by StGIT broken
From: Pavel Roskin @ 2008-01-12 4:58 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20080110074252.GA18629@diana.vm.bytemark.co.uk>
On Thu, 2008-01-10 at 08:42 +0100, Karl Hasselström wrote:
> On 2008-01-09 21:53:16 -0500, Pavel Roskin wrote:
>
> > "stg edit --sign" is not working anymore. It was working in version
> > 0.14.
>
> Thanks for the report and the detailed analysis. I'll write a test and
> fix it (but not quite immediately, so feel free to beat me to it).
The fix below appears to work (thus making it a self-signing patch :))
but with my modest Python experience it absolutely needs to be reviewed.
I don't even know how to wrap the long line without making it look
misleading.
No testsuite fixes, sorry. But the existing testsuite passes.
Fix "stg edit --sign"
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
stgit/commands/edit.py | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/stgit/commands/edit.py b/stgit/commands/edit.py
index b9699d5..650d5a3 100644
--- a/stgit/commands/edit.py
+++ b/stgit/commands/edit.py
@@ -90,7 +90,10 @@ def __update_patch(pname, text, options):
bottom = patch.get_bottom()
top = patch.get_top()
- message, author_name, author_email, author_date, diff = parse_patch(text)
+ if text:
+ message, author_name, author_email, author_date, diff = parse_patch(text)
+ else:
+ message = author_name = author_email = author_date = diff = None
out.start('Updating patch "%s"' % pname)
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: [PATCH] Add committer and author names to top of COMMIT_EDITMSG.
From: Junio C Hamano @ 2008-01-12 4:57 UTC (permalink / raw)
To: Stephen Sinclair; +Cc: Junio C Hamano, git
In-Reply-To: <9b3e2dc20801111825i644da598i7556ef700b870445@mail.gmail.com>
"Stephen Sinclair" <radarsat1@gmail.com> writes:
>> In a properly configured repository, telling you who git thinks
>> you are is _ALWAYS_ useless (that's the definition of "properly
>> configured"). Just admit it.
>
> Well, I'll admit that I don't really understand you here.
> Maybe I'm still too much of a git newbie on this. (Fair enough.)
> Right now the only way to make sure I'm committing as myself with my
> proper email address is to:
>
> -- remember to "git-config --list", and check that my email is listed.
> -- "git-commit; git-log", and remember to check the last entry before
> doing a "git-push".
>
> Am I missing something?
They are both valid means to make sure you did not misconfigure.
You omitted the part that matters from the part you quoted
above, but this discussion was about "showing AUTHOR if it is
different from me", which was _one of_ the two conditions I
suggested in my counterproposal, and I was saying that it is
useless to expect that you would be able to find a
misconfiguration when AUTHOR is shown for this first reason.
This part is _not_ about catching your misconfiguration.
The other part is about the misconfiguration catching.
> Especially considering the default name is taken from the hostname
> anyway -- you're taking the local hostname and then checking with a
> rule to see if it might be localhost.
Yes, and earlier you said one of the undesirable ones was
"yourname@foo.local" (and others were "yourname@foo.(none)").
IOW, "localhost" is one of the things you want to catch as
unconfigured bogosity that you want to catch, isn't it?
And that is _the other_ condition in my counterproposal to show
AUTHOR.
To rephrase, you would show AUTHOR when one of the conditions
holds true, either:
(1) "not me" (so that we can remind that other's commit is
being amended); _OR_
(2) "funny me" (so that we can catch misconfiguration.
The latter would not have to trigger once you configure your
~/.gitconfig (or .git/config) properly.
^ 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