* [PATCH 1/1] Don't append -lintl when there is no gettext support
From: John Szakmeister @ 2012-02-18 19:38 UTC (permalink / raw)
To: git; +Cc: John Szakmeister
In-Reply-To: <1329593884-9999-1-git-send-email-john@szakmeister.net>
The check for libintl in a C library incorrectly assumes that if it's
not builtin then it must exist externally. Instead, let's check for
the existence of libintl.h first. If libintl.h exists, and libintl is
not in libc, then we append the library.
Signed-off-by: John Szakmeister <john@szakmeister.net>
---
configure.ac | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/configure.ac b/configure.ac
index 630dbdd..8471f5c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -640,7 +640,18 @@ AC_CHECK_LIB([c], [gettext],
[LIBC_CONTAINS_LIBINTL=YesPlease],
[LIBC_CONTAINS_LIBINTL=])
AC_SUBST(LIBC_CONTAINS_LIBINTL)
-test -n "$LIBC_CONTAINS_LIBINTL" || LIBS="$LIBS -lintl"
+
+#
+# Define NO_GETTEXT if you don't want Git output to be translated.
+# A translated Git requires GNU libintl or another gettext implementation
+AC_CHECK_HEADER([libintl.h],
+[NO_GETTEXT=],
+[NO_GETTEXT=YesPlease])
+AC_SUBST(NO_GETTEXT)
+
+if test -z "$NO_GETTEXT"; then
+ test -n "$LIBC_CONTAINS_LIBINTL" || LIBS="$LIBS -lintl"
+fi
## Checks for header files.
AC_MSG_NOTICE([CHECKS for header files])
@@ -824,13 +835,6 @@ AC_CHECK_HEADER([paths.h],
[HAVE_PATHS_H=])
AC_SUBST(HAVE_PATHS_H)
#
-# Define NO_GETTEXT if you don't want Git output to be translated.
-# A translated Git requires GNU libintl or another gettext implementation
-AC_CHECK_HEADER([libintl.h],
-[NO_GETTEXT=],
-[NO_GETTEXT=YesPlease])
-AC_SUBST(NO_GETTEXT)
-#
# Define HAVE_LIBCHARSET_H if have libcharset.h
AC_CHECK_HEADER([libcharset.h],
[HAVE_LIBCHARSET_H=YesPlease],
--
1.7.9.1
^ permalink raw reply related
* [PATCH 0/1] Make libintl in libc detection more robust
From: John Szakmeister @ 2012-02-18 19:38 UTC (permalink / raw)
To: git; +Cc: John Szakmeister
When building the latest release, I noticed that pthreads support
was disabled. It turns out that the libintl in libc support is
adding "-lintl" to LIBS, even though I don't have that library on my
Mac. This patch fixes the issue by moving the check for libintl.h
closer to the checks for libintl in libc, and only adding "-lintl"
when NO_GETTEXT is empty.
This is my first time submitting a patch to git. I hope I've done
things correctly!
John Szakmeister (1):
Don't append -lintl when there is no gettext support
configure.ac | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
--
1.7.9.1
^ permalink raw reply
* [PATCH] cherry-pick -x: always insert an empty line
From: Beat Bolli @ 2012-02-18 21:14 UTC (permalink / raw)
To: git; +Cc: Beat Bolli, Eric Raible
When cherry-picking a commit that has only a summary, the -x option
creates an invalid commit message because it puts the hash of the commit
being picked on the second line which should be left empty.
This patch fixes this buglet by always inserting an empty line before
the added line.
Aside from that, even with a non-trivial commit the generated note
"(cherry picked from commit 555c9864971744abb558796aea28e12a1ac20839)"
seems abrupt when appended directly.
Cc: Eric Raible <raible@nextest.com>
Signed-off-by: Beat Bolli <bbolli@ewanet.ch>
---
sequencer.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 5fcbcb8..63fd589 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -382,7 +382,7 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
}
if (opts->record_origin) {
- strbuf_addstr(&msgbuf, "(cherry picked from commit ");
+ strbuf_addstr(&msgbuf, "\n(cherry picked from commit ");
strbuf_addstr(&msgbuf, sha1_to_hex(commit->object.sha1));
strbuf_addstr(&msgbuf, ")\n");
}
--
1.7.9
^ permalink raw reply related
* git clean is not removing a submodule added to a branch when switching branches
From: Adrian Cornish @ 2012-02-18 21:27 UTC (permalink / raw)
To: git
If I add a submodule to a branch and then switch branches, git
checkout warns it cannot
remove the submodule. If I then issue a git clean - it says it removes
the submodule but
in fact does nothing at all. Is this a bug or expected behaviour.
TIA
Adrian
Below are cut&paste steps to reproduce.
git --version
#git version 1.7.8.4
git init submod
cd submod
echo "This is a submodule" > README.txt
git add .
git commit -m "Initial commit"
cd ..
git init prog
cd prog
echo "This is a program" > README.txt
git add .
git commit -a -m "Initial commit"
git checkout -b topic1
git submodule add ../submod
git commit -m "Added submodule"
git checkout master
#warning: unable to rmdir submod: Directory not empty
#Switched to branch 'master'
git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# submod/
#nothing added to commit but untracked files present (use "git add" to track)
git clean -fd
#Removing submod/
git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# submod/
#nothing added to commit but untracked files present (use "git add" to track)
^ permalink raw reply
* Re: git-svn won't remember pem password
From: Eric Wong @ 2012-02-19 1:30 UTC (permalink / raw)
To: Igor; +Cc: Matthijs Kooijman, Gustav Munkby, Edward Rudd, Carsten Bormann,
git
In-Reply-To: <E56535F6-2C9B-4D14-A88F-2471E34D2769@gmail.com>
Igor <mrigor83@gmail.com> wrote:
> I'm running into an issue where I have to enter my pem certificate
> password every time I git-svn fetch or git-svn dcommit. Vanilla svn
> uses OS X KeyChain and remembers my password just fine. Is there a
> known solution for this? Other users have ran into same issue as
> described here:
> http://stackoverflow.com/questions/605519/does-git-svn-store-svn-passwords.
> However, that solution of removing .subversion folder did not work for
> me.
Hi Igor, this issue seems related to the platform specific auth
providers patches. There have been bugs in the SVN bindings in
previous releases and uncertainty about how everything works.
I haven't been interested enough to follow along closely[1], but maybe
some other folks Cc:-ed can finally push this through.
http://mid.gmane.org/20120103204403.GI17548@login.drsnuggles.stderr.nl
Basically I'm waiting for a patch that we can be certain won't break the
majority of existing use cases (especially no triggering of segfaults
and other nastiness in released versions of SVN bindings).
[1] - I barely use git-svn anymore, and wouldn't touch GNOME or OSX
with a 10-foot pole...
^ permalink raw reply
* Re: git-svn won't remember pem password
From: Nikolaus Demmel @ 2012-02-19 4:03 UTC (permalink / raw)
To: git
In-Reply-To: <m3zkcgqt0g.fsf@localhost.localdomain>
Jakub Narebski wrote
>
> Igor <mrigor83@> writes:
>
>> I'm running into an issue where I have to enter my pem certificate
>> password every time I git-svn fetch or git-svn dcommit. Vanilla svn
>> uses OS X KeyChain and remembers my password just fine. Is there a
>> known solution for this?
>
> I don't know if it is svn that has to remember password, or git that
> has to remember password. Git 1.7.9 learned "credentials API" that
> allows integration with platform native keychain mechanisms, and I
> think OS X Keychain is one of examples / supported platforms (but it
> might not made it into core git)... though I am not sure if it affects
> git-svn, or only HTTP(S) transport.
>
Wow, I just signed up to the mainling list to post about this, but it turns
out the latest message is exactly what I wanted to ask.
Like Eric wrote, I'm pretty sure it is svn that is meant to store the
password here and the perl bindings or the git-svn part fails to deal with
the os x keychain right. With pure svn the keychain authentication works
just fine. If I set up plaintext password storage in the svn configs, then
git svn is also able to store passwords.
There is also this macports ticket [1] that has been around for a while. But
that can only be fixed by an upstream fix here.
I would love to help to get this working, but I'm not sure how I can.
Cheers,
Nikolaus
[1] https://trac.macports.org/ticket/28329
--
View this message in context: http://git.661346.n2.nabble.com/git-svn-won-t-remember-pem-password-tp7295962p7298035.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] git-svn: enable platform-specific authentication
From: Nikolaus Demmel @ 2012-02-19 4:06 UTC (permalink / raw)
To: git
In-Reply-To: <20120103204403.GI17548@login.drsnuggles.stderr.nl>
Matthijs Kooijman wrote
>
> I sent the below patch a few months ago, and not having it applied in
> git-svn bit me again just now. Did any of you get a chance to have a
> look at it?
>
> I'm still not 100% sure if this patch is correct for all the corner
> cases, but it works like a charm in the regular case.
>
> Perhaps it should just be included as is?
>
Hi,
is this patch also meant to deal with / fix the handling the keychain as an
authentication handler on OS X?
Is there anything I could do to help getting this moving forward? I could
try test it on OS X, if noone else can.
Cheers,
Nikolaus
--
View this message in context: http://git.661346.n2.nabble.com/PATCH-git-svn-enable-platform-specific-authentication-tp6376961p7298038.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH/RFC v2] Document format of basic Git objects
From: Nguyễn Thái Ngọc Duy @ 2012-02-19 4:15 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jonathan Niedier, Shawn O. Pearce, Scott Chacon,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1329312140-24089-1-git-send-email-pclouds@gmail.com>
Still draft for discussion. Of three people who participated on this
thread, two favor a man page (me and Jonathan), one techincal/
(Junio), so let's put it as a man page for now.
Some notes:
- I'm tempted to include pack-format.txt because I also document
loose object format here. If it's included and
gitrepository-layout.txt links to this, we have a quite complete
documentation of what's inside $GIT_DIR (assuming rebase-apply and
such are of private use)
- Not sure if we fix the order of gpgsig and mergetag, or they can be
mixed together. Also not sure if we can have multiple gpgsig, I
haven't checked the code.
- I skipped the experimental loose object format (it's what it's
called in sha1_file.c). I think we can call it deprecated and move
on.
- Do we assume tag/commit header in utf-8 or ascii?
- We don't do any encoding on ident strings, right?
Mostly-written-by: Jonathan Nieder <jrnieder@gmail.com>
Mostly-written-by: Junio C Hamano <gitster@pobox.com>
Remaining-stolen-from: Documentation/user-manual.txt
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/git-object.txt | 273 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 273 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-object.txt
diff --git a/Documentation/git-object.txt b/Documentation/git-object.txt
new file mode 100644
index 0000000..359af37
--- /dev/null
+++ b/Documentation/git-object.txt
@@ -0,0 +1,273 @@
+git-object(5)
+=============
+
+NAME
+----
+git-object - Git object format
+
+SYNOPSIS
+--------
+$GIT_DIR/objects/*
+
+OBJECT ON-DISK REPRESENTATIONS
+------------------------------
+Objects can be stored on disk as loose (unpacked) objects or
+in packs. Loose objects are in $GIT_DIR/objects/[0-9a-f][0-9a-f]
+directories. Packs are $GIT_DIR/objects/pack/pack-*.pack. Each pack
+has a corresponding index file to speed up pack access.
+
+Object SHA-1
+~~~~~~~~~~~~
+An object SHA-1 is calculated on its header and payload. The content
+to be consumed by SHA-1 calculation is:
+
+- Object type in ascii, either "commit", "tree", "tag" or "blob"
+ (without quotes)
+- One space (ASCII SP)
+- The payload length in ascii canonical decimal format
+- ASCII NUL
+- Object payload
+
+Loose objects
+~~~~~~~~~~~~~
+Loose objects are simply a compressed form using zlib(3) of the
+object's header and payload, as described in Object SHA-1 section
+above.
+
+Packed objects
+~~~~~~~~~~~~~~
+FIXME maybe include Documentation/pack-format.txt
+
+BLOB OBJECTS
+------------
+Blob object payload is file data.
+
+TREE OBJECTS
+------------
+Tree object payload contains a list of entries, each with a mode,
+object type, object name, and filename, sorted by filename. It
+represents the contents of a single directory tree.
+
+The object type may be a blob, representing the contents of a file,
+another tree, representing the contents of a subdirectory, or a commit
+(representing a subproject). Since trees and blobs, like all other
+objects, are named by a hash of their contents, two trees have the
+same object name if and only if their contents (including,
+recursively, the contents of all subdirectories) are identical. This
+allows git to quickly determine the differences between two related
+tree objects, since it can ignore any entries with identical object
+names.
+
+Note that the files all have mode 644 or 755: git actually only pays
+attention to the executable bit.
+
+Encoding
+~~~~~~~~
+Entries are of variable length and self-delimiting. Each entry
+consists of
+
+- a POSIX file mode in octal ascii representation, no 0 padding to the
+ left
+- exactly one space (ASCII SP)
+- filename for the entry, as a NUL-terminated string
+- 20-byte binary object name
+
+The mode should be 100755 (executable file), 100644 (regular file),
+120000 (symlink), 40000 (subdirectory), or 160000 (subproject), with
+no leading zeroes. Modes with one leading zero and the synonym 100664
+for 100644 are also accepted for historical reasons. Other modes are
+not accepted.
+
+The filename may be an arbitrary nonempty string of bytes, as long as
+it contains no '/' or NUL character.
+
+The associated object must be a valid blob if the mode indicates a
+file or symlink, tree if it indicates a subdirectory, or commit if it
+indicates a subproject. The blob associated to a symlink entry
+indicates the link target and its content not have any embedded NULs.
+
+Sorting
+~~~~~~~
+Entries are sorted by memcmp(3) on file name. No duplicate file names
+allowed.
+
+COMMIT OBJECT
+-------------
+The commit object links a physical state of a tree with a description
+of how we got there and why. Commit object payload contains the
+associated tree SHA-1, parent commits's SHA-1, author and comitter
+information.
+
+------------------------------------------------
+$ git cat-file commit 81d48f0aee54
+tree 093f37084c133795e4ce71befa57185328737171
+parent f5e4e20faa1eee3feaa0394897bbd1aca544e809
+parent 661db794eb8179c7bea02f159bb691a2fff4a8e0
+parent 14c173eb63432ba5d0783b6c4b23a8fe0c76fb0f
+author Linus Torvalds <torvalds@linux-foundation.org> 1326576355 -0800
+committer Linus Torvalds <torvalds@linux-foundation.org> 1326576355 -0800
+mergetag object 661db794eb8179c7bea02f159bb691a2fff4a8e0
+ type commit
+ tag devicetree-for-linus
+ tagger Grant Likely <grant.likely@secretlab.ca> 1326520038 -0700
+
+ 2nd set of device tree changes for v3.3
+ -----BEGIN PGP SIGNATURE-----
+ Version: GnuPG v1.4.11 (GNU/Linux)
+
+ iQIcBAABAgAGBQJPERbzAAoJEEFnBt12D9kBmDIP/R9Vspc6yhjSAEvdp/VET2gi
+ TgAQfdp4VuYjjIt4cUPO5UQU9kw478GjTuP2blZEC9DlG1jSf/L8U+A7FHJIVVzU
+ QfjwV1Lqaqk+sQQ1bsp2ixbesKECmqU9IweOIFmn0U2ZD+xlPFIpE2iTKEqymejf
+ PVZsFlkVmhQZgudPNieyZMjQpQ9hEb6UcSfXT//nmoRRxCL/PiMHGRx3UdS3eRe7
+ FApSW0Mty/PD07QXPsDjg1GvK59Gf6R1/4Bd31+rXEz9yaxf4I4I02fL553NDVIt
+ tAPfo/4YKW1rLMWQRkAUqCaMk9v/DWxeWYbbiJNZ2R3kys9o8k26XXxvcuYnecS2
+ G8DDJpmOikbN3Gvlskh40Tn3TJb5Wlgc7o/10L/fq6FovS4Uk7yUeFMqXUYfl8TU
+ ziIlrlt9IGabXBN4JKJl3OabgkeO+Oz9DKhTQFJLY4/121LAtFVk3xd316mY+wpX
+ mI83VmWMlp3sK+OLr+UdMTCXZvSIpu3KlGKMpAssHKUKxIV20NHLFNbm94/ywXBn
+ Zb8arjcv7+WzwhSqQJj851cq4/sEYx5HB4wU5Nm5SXBwcO3ixiij6lHCoHU+NudR
+ eyPIFLfrzwnUu3yTRgUfAnkgOce+2I+vUsU4pXUR6FyK73wSmm0+4WXQfB+OBlwD
+ 2O1RjZedZCb6zzf17H2k
+ =mup8
+ -----END PGP SIGNATURE-----
+mergetag object 14c173eb63432ba5d0783b6c4b23a8fe0c76fb0f
+ type commit
+ tag spi-for-linus
+ tagger Grant Likely <grant.likely@secretlab.ca> 1326520366 -0700
+
+ SPI bug fixes for v3.3
+ -----BEGIN PGP SIGNATURE-----
+ Version: GnuPG v1.4.11 (GNU/Linux)
+
+ iQIcBAABAgAGBQJPERgyAAoJEEFnBt12D9kBRMsP/RBv6kWIb/qD7yJhrdbzJ4Tv
+ 1f7coSytuHupZVpxJstELKPugRmp2R6YeFbKw8P4P/12233Q0FcdKTF6ZE2h3cBp
+ bfCtyyzlFeY/nMfJKkwh37x2fHxNHynCCJEjHhecLday7NKQoTmmafivTfVmolWK
+ /MGjDarTAzC1FaP1xpBnuiI8eCr5WIgb4WmtvOmxIntVT077xggdJLL/Co7fBCqn
+ iibz3U/VyC68kQTGw6ELhnW1d7doHp7H3DJ2gPsh6lzpbv8JAnOMPpD+3Me1DVHE
+ Ay0kxPHV4bqnDyB+uEGppUiNoaTd5InrMAw+udDad60TMwOZzIvMkgxo0PIVM9Mm
+ k6mCcE2+TSnJetueX3cfrS5bRTPxUX7KRDC/WSp67/QPmelbYeRDLR7hrrQVqOPq
+ 5hIKMfz/kTBXcaXk643TEveaZlMuOZxHBYAvsbu5BX/3SQqYFS4POdxdeZVnUf54
+ ITHhftBtrXacCsjKujp0xmKCIpF+8v3yKRxGEQssByv8v+CaymNrEls2vTF8tn5P
+ sAIjPFJYG+IHtDMIsTHOvSPA7uwWYsOVHFEYsbC1758esiBD8+qtfvFS3jAH99z+
+ v2/aGsfMnjYEIsRtSm7PVTybJAo22Gr62yE/Q+rP//O0JaDahgdm009MjUo6BSgg
+ XNhZjQRYAYEExMTjJ2TK
+ =q39P
+ -----END PGP SIGNATURE-----
+
+Merge tags 'devicetree-for-linus' and 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6
+
+2nd set of device tree changes and SPI bug fixes for v3.3
+
+* tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux-2.6:
+ of/irq: Add interrupts-names property to name an irq resource
+ of/address: Add reg-names property to name an iomem resource
+
+* tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6:
+ spi/tegra: depend instead of select TEGRA_SYSTEM_DMA
+------------------------------------------------
+
+More precisely, a commit object begins with of one or more lines
+delimited by ASCII LF. The end of the header is signalled by an empty
+line. Any remaining text after the empty line forms the commit
+message. The header must not contain NUL.
+
+A "continuation line" in the header begins with an SP. The remainder
+of the line, after removing that SP, is concatenated to the previous
+line, while retaining the LF at the end of the previous line.
+
+When a line in the header begins with a letter other than SP, and has
+at least one SP in it, it is called a "field". A field consists of the
+"field name", which is the string before the first SP on the line, and
+its "value", which is everything after that SP. When the value
+consists of multiple lines, continuation lines are used.
+
+More than one field with the same name can appear in the header of an
+object, and the order in which they appear is significant. A commit
+object can contain these fields in the listed order:
+
+1. one "tree" field with the 40-character textual object name of the
+ associated tree object
+2. zero or more "parent" fields, each with 40-character textual object
+ name of the parent commit object
+3. one "author" field with an ident string
+4. one "committer" field with an ident string
+5. zero or one "encoding" field with an ascii string
+6. zero or more "mergetag" fields with associated tag object content
+7. zero or one "gpgsig" field with gpg signature content
+
+New kinds of fields may be added in later versions of git.
+
+Ident strings
+~~~~~~~~~~~~~
+Ident strings record who's responsible of doing something at what
+time. For a commit, the ident string in "author" line records who is
+the author of the associated changes and when the changes are
+made. The ident string in "committer" line records who commits the
+changes to the repository and at what time.
+
+An ident string consists of an email address and a timestamp. More
+precisely:
+
+1. Optionally, a name
+2. An email address wrapped around by `<` and `>`, followed by one
+ space (ASCII SP)
+3. The number of seconds since Epoch (00:00:00 UTC, January 1, 1970)
+ followed by a space (ASCII SP)
+4. Timezone: either plus or minus sign, followed by 4 decimal digits
+
+Name and email are encoded in UTF-8 and must must not contain ASCII
+NUL characters.
+
+Commit encoding
+~~~~~~~~~~~~~~~
+Encoding field describes that encoding that the commit message is
+encoded in. Encoding names must be recognized by iconv(3). By default,
+commit message is in UTF-8. It's discouraged to use encodings that can
+generate ASCII NUL characters.
+
+TAG OBJECTS
+-----------
+Tag object payload contains an object, object type, tag name, the name
+of the person ("tagger") who created the tag, and a message, which may
+contain a signature.
+
+------------------------------------------------
+$ git cat-file tag v1.5.0
+object 437b1b20df4b356c9342dac8d38849f24ef44f27
+type commit
+tag v1.5.0
+tagger Junio C Hamano <junkio@cox.net> 1171411200 +0000
+
+GIT 1.5.0
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.6 (GNU/Linux)
+
+iD8DBQBF0lGqwMbZpPMRm5oRAuRiAJ9ohBLd7s2kqjkKlq1qqC57SbnmzQCdG4ui
+nLE/L9aUXdWeTFPron96DLA=
+=2E+0
+-----END PGP SIGNATURE-----
+------------------------------------------------
+
+Tag object format resembles commit format. A tag commit may have the
+following fields in listed order:
+
+1. one "object" field with 40-character textual object name of the
+ tagged object
+2. one "type" field with type of the tagged object ("commit", "tag",
+ "blob", or "tree")
+3. one "tag" field with the name of the tag
+4. one "tagger" with an ident string
+
+New kinds of fields may be added in later versions of git.
+
+Any remaining text after the header forms the tag message. Tag message
+has no specified encoding. Anything that does not contain ASCII NUL
+characters are accepted.
+
+The object field must point to a valid object of type indicated by the
+type field. The tag name can be an arbitrary string without NUL bytes
+or embedded newlines; in practice it usually follows the restrictions
+described in linkgit:git-check-ref-format[1].
+
+GIT
+---
+Part of the linkgit:git[1] suite
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Re: git-svn: simple user-level versions question, plus help request
From: Nikolaus Demmel @ 2012-02-19 4:25 UTC (permalink / raw)
To: git
In-Reply-To: <CAJaBf=oFpNZ3gf=Oqj9415_WpMyAM=EYnW6R9cZCPteqSxnogQ@mail.gmail.com>
Richard Holmes wrote
>
> After looking at the respective versions, it appears that git svn
> shows svn version 1.6.16 and my svn (standalone) client shows svn
> version 1.6.17 (and its associated RA modules):
>
I'm not quite sure how everything fits together, but AFAIK git-svn uses the
perl subversion module, meaning that you might possibly need to update
those.
Best regards,
Nikolaus
--
View this message in context: http://git.661346.n2.nabble.com/git-svn-simple-user-level-versions-question-plus-help-request-tp7292358p7298053.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* git-svn support for svn:externals
From: Nikolaus Demmel @ 2012-02-19 5:58 UTC (permalink / raw)
To: git
Hi,
has there been any recent interest / activity in getting support for svn:externals? Digging in the archives [1,2,3] I found a couple of initiatives, but none seem to have ever been completed. Also, there are a couple of independent scripts floating around the web, that implement some special cases, but most don't work very well, e.g. because they only serve the pre-1.5 syntax for svn:externals.
Support for svn:externals would make my live so much simpler :-).
Cheers,
Nikolaus
[1] http://git.661346.n2.nabble.com/Re-git-svn-and-svn-externals-was-Re-Hackontest-ideas-tc667598.html
[2] http://git.661346.n2.nabble.com/PATCH-0-3-git-svn-externals-PoC-in-a-sh-script-tc791045.html#none
[3] http://git.661346.n2.nabble.com/git-svn-importing-internal-externals-tc2982345.html#none
^ permalink raw reply
* Re: [PATCH/RFC v2] Document format of basic Git objects
From: Junio C Hamano @ 2012-02-19 8:39 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Jonathan Niedier, Shawn O. Pearce, Scott Chacon
In-Reply-To: <1329624946-32173-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Still draft for discussion. Of three people who participated on this
> thread, two favor a man page (me and Jonathan), one technical/
> (Junio), so let's put it as a man page for now.
Personally I do not have strong preference either way.
The original motivation of technical/ was that we wanted to have a place
to keep documentation that would help ourselves, the people who write the
internals of git, even though we did not yet know and did not want to have
to decide if it is a good idea to expose the end users, who may not care
about the gory details of the internal, with reams of such documents.
> - Not sure if we fix the order of gpgsig and mergetag, or they can be
> mixed together. Also not sure if we can have multiple gpgsig.
You can merge a signed tag and then sign the resulting commit yourself,
and the order of the mixing would not matter. Technically a gpgsig is a
signature over the commit object payload without gpgsig lines, so you
could have two or more gpgsigs on the same commit object but from a larger
workflow point of view it would not be so useful, as it would involve
steps like this:
* You prepare a commit object, you may perhaps sign it yourself;
* You expose this commit object to chosen others from whom you want their
signature on it;
* They sign it with "commit -S --amend", but when they do so they make
sure the resulting commit has the same committer/author header as the
original. Note that the resulting commits will all have different
object name, as the object name is over all payload including their
gpgsigs.
* You grab the gpgsig lines from these commits, paste them into the
header part of the original, and then re-hash the result with
"hash-object -w -t commit". The result will have all valid gpgsigs
over the payload in the commit without its gpgsig lines, because the
gpgsig lines from all the signers were generated that way.
* Then you give the general public the resulting commit.
> - I skipped the experimental loose object format (it's what it's
> called in sha1_file.c). I think we can call it deprecated and move
> on.
Good.
> - Do we assume tag/commit header in utf-8 or ascii?
Author-ident is typically utf-8 already, so you cannot assume "ASCII".
> +Object SHA-1
> +~~~~~~~~~~~~
> +An object SHA-1 is calculated on its header and payload. The content
> +to be consumed by SHA-1 calculation is:
> +
> +- Object type in ascii, either "commit", "tree", "tag" or "blob"
> + (without quotes)
> +- One space (ASCII SP)
> +- The payload length in ascii canonical decimal format
"canonical" may make it sound as if the document is more formal, but then
you would have to define what is canonical and what is not somewhere else,
so I would suggest dropping it.
The length of the payload in bytes, represented as a decimal integer.
Also if you spell ASCII, consistently spell it in all-caps.
> +- ASCII NUL
> +- Object payload
----------------------------------------------------------------
> +BLOB OBJECTS
> +------------
> +Blob object payload is file data.
What's the significance of saying "file data" here? In a document that
describes the structure, saying "is uninterpreted sequence of bytes" is
more accurate (the important point is that git does not care what it is)
and covers cases where blob was recorded with "hash-object -w --stdin"
where no such "file data" has ever existed in a 'file". Also a blob may
record contents of a symbolic link ;-).
> +TREE OBJECTS
> +------------
> +Tree object payload contains a list of entries, each with a mode,
> +object type, object name, and filename, sorted by filename. It
> +represents the contents of a single directory tree.
Drop "object type," from this list. It is inferred from the mode. I
personally would prefer to say "path" or "pathname" when the entity
referred to may not be a regular file. I am not sure the last sentence is
necessary, but if you must say something, say "It represents a
directory". It is by definition redundant to say that a tree represents a
"tree". Replace the above with something line this:
... entries, each with a mode, object name and path. The type of
the object is encoded in the "mode":
- 100644 or 100755: the object is a "blob" that records the
contents of a regular non-executable or executable file,
respectively, that exists at the path.
- 120000: the object is a "blob" that records the contents of a
symbolic link that exists at the path.
- 40000: the object is a "tree" that represents a subdirectory
that exists at the path.
- 160000: the object is a "commit" that records the state of a
submodule that exists at the path.
> +The object type may be a blob, representing the contents of a file,
> +another tree, representing the contents of a subdirectory, or a commit
> +(representing a subproject).
and drop the above line.
> +Since trees and blobs, like all other
> +objects, are named by a hash of their contents, two trees have the
> +same object name if and only if their contents (including,
> +recursively, the contents of all subdirectories) are identical. This
> +allows git to quickly determine the differences between two related
> +tree objects, since it can ignore any entries with identical object
> +names.
It does not make sense to say 'trees and blobs' when you explain that a
single top-level tree object defines the entire tree's state. Just say
'trees'. I know you would say "I wanted to say if tree A and tree B are
the same except for the content of a single blob recorded at path P, the
result of hash for A and B would be different", but the same can be said
for a submodule, so singling out 'blob' is incomplete. Also these trees
may record the same set of blobs but tree B may record what tree A had at
path P at path Q, so it is not like the only thing that matter in the tree
is the object names.
I personally do not think it is necessary to have the above paragraph at
all in this object.
> +Note that the files all have mode 644 or 755: git actually only pays
> +attention to the executable bit.
Saying 644 or 755 here is misleading as it does not match any reality
(except for very early incarnation of git). By rewriting the first
paragraph, these two lines can be safely eliminated.
> +Encoding
> +~~~~~~~~
"Encoding" is such a loaded word and does not help clarify what this
section is really about, which is "format of a tree entry", or simply
"Entries".
> +Entries are of variable length and self-delimiting. Each entry
> +consists of
> +
> +- a POSIX file mode in octal ascii representation, no 0 padding to the
> + left
This is not "a POSIX file mode" at all. The mode in a tree entry was
modelled after that, but there is no need to mention it, especially
because POSIX does not define the exact bit assignment for types (the
permission are defined from S_IXOTH to S_IRWXU and S_ISUID/S_ISGID with
exact bit locations) and because of S_IFGITLINK which is clearly not
POSIX. As we have enumerated them in the first paragraph,
The "mode" (see above).
is sufficient here.
> +- exactly one space (ASCII SP)
> +- filename for the entry, as a NUL-terminated string
Again, "pathname" or just "path" for this entire document.
> +- 20-byte binary object name
> +
> +The mode should be 100755 (executable file), 100644 (regular file),
> +120000 (symlink), 40000 (subdirectory), or 160000 (subproject), with
> +no leading zeroes. Modes with one leading zero and the synonym 100664
> +for 100644 are also accepted for historical reasons. Other modes are
> +not accepted.
This is made redundant by the first paragraph above.
> +The filename may be an arbitrary nonempty string of bytes, as long as
> +it contains no '/' or NUL character.
s/, as long as it contains no/; it cannot contain any/
> +The associated object must be a valid blob if the mode indicates a
> +file or symlink, tree if it indicates a subdirectory, or commit if it
> +indicates a subproject. The blob associated to a symlink entry
> +indicates the link target and its content not have any embedded NULs.
I doubt that we should even mention "and its content not have ...". It is
for readlink(2) and symlink(2) to decide.
> +Sorting
> +~~~~~~~
> +Entries are sorted by memcmp(3) on file name. No duplicate file names
> +allowed.
A sentence without a verb seen at the end of this paragraph.
> +COMMIT OBJECT
> +-------------
> +The commit object links a physical state of a tree with a description
> +of how we got there and why.
What is the intended audience and the purpose of this document? If this
were to strictly define and describe the "structure", then "and why" is
inappropriate. It is merely the best-current-practice at the human level
to describe the "why" in their commit log messages---it does not break the
structure if nobody explains "why".
On the other hand, "how we got there" is a good phrase to explain that by
refering to its immediate parents, all the previous histories are also
described.
> +... Commit object payload contains the
> +associated tree SHA-1, parent commits's SHA-1, author and comitter
> +information.
s/.$/, among other things./; as the log message is also part of the
payload.
Start by labeling what the large block of example you are going to throw
at the reader here.
> +------------------------------------------------
> +$ git cat-file commit 81d48f0aee54
> +tree 093f37084c133795e4ce71befa57185328737171
> +parent f5e4e20faa1eee3feaa0394897bbd1aca544e809
> +parent 661db794eb8179c7bea02f159bb691a2fff4a8e0
> +parent 14c173eb63432ba5d0783b6c4b23a8fe0c76fb0f
> +author Linus Torvalds <torvalds@linux-foundation.org> 1326576355 -0800
> +committer Linus Torvalds <torvalds@linux-foundation.org> 1326576355 -0800
> +mergetag object 661db794eb8179c7bea02f159bb691a2fff4a8e0
> + type commit
> + tag devicetree-for-linus
> + tagger Grant Likely <grant.likely@secretlab.ca> 1326520038 -0700
> +
> + 2nd set of device tree changes for v3.3
> + -----BEGIN PGP SIGNATURE-----
> + Version: GnuPG v1.4.11 (GNU/Linux)
> +
> + iQIcBAABAgAGBQJPERbzAAoJEEFnBt12D9kBmDIP/R9Vspc6yhjSAEvdp/VET2gi
> + TgAQfdp4VuYjjIt4cUPO5UQU9kw478GjTuP2blZEC9DlG1jSf/L8U+A7FHJIVVzU
Elide the above like so:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPERbzAAoJEEFnBt12D9kBmDIP/R9Vspc6yhjSAEvdp/VET2gi
TgAQfdp4VuYjjIt4cUPO5UQU9kw478GjTuP2blZEC9DlG1jSf/L8U+A7FHJIVVzU
...
=mup8
-----END PGP SIGNATURE-----
> +Merge tags 'devicetree-for-linus' and 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6
> +
> +2nd set of device tree changes and SPI bug fixes for v3.3
> +
> +* tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux-2.6:
> + of/irq: Add interrupts-names property to name an irq resource
> + of/address: Add reg-names property to name an iomem resource
> +
> +* tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6:
> + spi/tegra: depend instead of select TEGRA_SYSTEM_DMA
> +------------------------------------------------
> +
> +More precisely, a commit object begins with of one or more lines
> +delimited by ASCII LF. The end of the header is signalled by an empty
> +line. Any remaining text after the empty line forms the commit
Drop "More precisely, ". Also notice that you abruptly said "end of the
header" without mentioning anything about "header" in the previous
sentence.
A commit object begins with the "header" part, that consists of
one or more lines delimited by LF, and the "body" part, that
records the commit log message. The first empty line delimits the
header and the body.
> +The header must not contain NUL.
I vaguely recall that you made sure neither the header nor the body
contains NUL.
> +A "continuation line" in the header begins with an SP. The remainder
> +of the line, after removing that SP, is concatenated to the previous
> +line, while retaining the LF at the end of the previous line.
> +
> +When a line in the header begins with a letter other than SP, and has
> +at least one SP in it, it is called a "field". A field consists of the
> +"field name", which is the string before the first SP on the line, and
> +its "value", which is everything after that SP. When the value
> +consists of multiple lines, continuation lines are used.
> +
> +More than one field with the same name can appear in the header of an
> +object, and the order in which they appear is significant. A commit
> +object can contain these fields in the listed order:
s/can contain/contains/; as you are marking optional ones with "zero or".
> +1. one "tree" field with the 40-character textual object name of the
> + associated tree object
> +2. zero or more "parent" fields, each with 40-character textual object
> + name of the parent commit object
> +3. one "author" field with an ident string
> +4. one "committer" field with an ident string
> +5. zero or one "encoding" field with an ascii string
s/zero or one/optionally, one/ (not a strong preference--I just felt that
would be easier to read).
After the above fields, other fields may follow, and new types of
fields may be added in later versions of git. Example of these
optional fields are:
- "mergetag" that copies the contents of a signed tag on one of
the parent commit;
- "gpgsig" that records a GPG signature for this commit object.
> +6. zero or more "mergetag" fields with associated tag object content
> +7. zero or one "gpgsig" field with gpg signature content
and exclude these two from the numbering above to make it clear they are
optional.
> +Ident strings
> +~~~~~~~~~~~~~
> +Ident strings record who's responsible of doing something at what
> +time. For a commit, the ident string in "author" line records who is
> +the author of the associated changes and when the changes are
s/are/were/, perhaps? Again, what the purpose of this document? If this
were more than to strictly describe the "structure", it is OK and even
preferable to leave the meaning the "author" as vague, but if this were
also to suggest the best current practice interpretation, it may be worth
to add something like
There may be a case where it is difficult to attribute a commit to
a single author; think of it as recording the primary contact, the
person to ask any questions about the commit if needed later.
> +made. The ident string in "committer" line records who commits the
s/commits/committed/, perhaps?
> +changes to the repository and at what time.
> +
> +An ident string consists of an email address and a timestamp. More
> +precisely:
s/of an email/of a name, an email/;
s/. More precisely:/:/;
> +1. Optionally, a name
> +2. An email address wrapped around by `<` and `>`, followed by one
> + space (ASCII SP)
The above makes it sound as if "A U Thor<author@example.xz>" is usual and
valid. How about
1. A name, followed by one ASCII SP
and after this enumeration, say something like:
Name may be missing in commit objects produced by repository
conversion from other SCMs that do not have it. Name and email
are typically encoded in UTF-8.
even though I am not sure the last sentence should be in this document.
> +3. The number of seconds since Epoch (00:00:00 UTC, January 1, 1970)
> + followed by a space (ASCII SP)
> +4. Timezone: either plus or minus sign, followed by 4 decimal digits
> +
> +Name and email are encoded in UTF-8 and must must not contain ASCII
> +NUL characters.
Drop " and must must ...characters"; you already said that the header does
not have any NUL. As I already said, I am not sure if you should mention
"UTF-8" at all in this document.
> +Commit encoding
> +~~~~~~~~~~~~~~~
> +Encoding field describes that encoding that the commit message is
> +encoded in.
s/that encoding that/the character encoding in which/;
s/encoded in/recorded/;
> +... Encoding names must be recognized by iconv(3). By default,
> +commit message is in UTF-8. It's discouraged to use encodings that can
> +generate ASCII NUL characters.
Here we would probably want to have a paragraph each for "mergetag" and
"gpgsig".
> +TAG OBJECTS
> +-----------
> +Tag object payload contains an object, object type, tag name, the name
> +of the person ("tagger") who created the tag, and a message, which may
> +contain a signature.
s/a signature/a signature at the end/;
> +------------------------------------------------
> +$ git cat-file tag v1.5.0
> +object 437b1b20df4b356c9342dac8d38849f24ef44f27
> +type commit
> +tag v1.5.0
> +tagger Junio C Hamano <junkio@cox.net> 1171411200 +0000
> +
> +GIT 1.5.0
> +-----BEGIN PGP SIGNATURE-----
> +Version: GnuPG v1.4.6 (GNU/Linux)
> +
> +iD8DBQBF0lGqwMbZpPMRm5oRAuRiAJ9ohBLd7s2kqjkKlq1qqC57SbnmzQCdG4ui
> +nLE/L9aUXdWeTFPron96DLA=
> +=2E+0
> +-----END PGP SIGNATURE-----
> +------------------------------------------------
> +
> +Tag object format resembles commit format. A tag commit may have the
> +following fields in listed order:
> +
> +1. one "object" field with 40-character textual object name of the
> + tagged object
> +2. one "type" field with type of the tagged object ("commit", "tag",
> + "blob", or "tree")
> +3. one "tag" field with the name of the tag
> +4. one "tagger" with an ident string
> +
> +New kinds of fields may be added in later versions of git.
> +
> +Any remaining text after the header forms the tag message. Tag message
> +has no specified encoding. Anything that does not contain ASCII NUL
> +characters are accepted.
> +
> +The object field must point to a valid object of type indicated by the
> +type field. The tag name can be an arbitrary string without NUL bytes
> +or embedded newlines; in practice it usually follows the restrictions
> +described in linkgit:git-check-ref-format[1].
A description of how the signature part is formed needs to come here.
> +GIT
> +---
> +Part of the linkgit:git[1] suite
^ permalink raw reply
* Re: [PATCH] cherry-pick -x: always insert an empty line
From: Junio C Hamano @ 2012-02-19 8:44 UTC (permalink / raw)
To: Beat Bolli; +Cc: git, Eric Raible
In-Reply-To: <1329599690-9152-1-git-send-email-bbolli@ewanet.ch>
Beat Bolli <bbolli@ewanet.ch> writes:
> When cherry-picking a commit that has only a summary, the -x option
> creates an invalid commit message because it puts the hash of the commit
> being picked on the second line which should be left empty.
>
> This patch fixes this buglet by always inserting an empty line before
> the added line.
>
> Aside from that, even with a non-trivial commit the generated note
> "(cherry picked from commit 555c9864971744abb558796aea28e12a1ac20839)"
> seems abrupt when appended directly.
>
> Cc: Eric Raible <raible@nextest.com>
> Signed-off-by: Beat Bolli <bbolli@ewanet.ch>
> ---
> sequencer.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index 5fcbcb8..63fd589 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -382,7 +382,7 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
> }
>
> if (opts->record_origin) {
> - strbuf_addstr(&msgbuf, "(cherry picked from commit ");
> + strbuf_addstr(&msgbuf, "\n(cherry picked from commit ");
Doesn't this need to be conditional?
If we cherry pick your commit somewhere else with "-x -s", the resulting
commit log message would end like this:
Aside from that, even with a non-trivial commit the generated note
"(cherry picked from commit 555c9864971744abb558796aea28e12a1ac20839)"
seems abrupt when appended directly.
Cc: Eric Raible <raible@nextest.com>
Signed-off-by: Beat Bolli <bbolli@ewanet.ch>
(cherry picked from commit 555c9864971744abb558796aea28e12a1ac20839)
Signed-off-by: Frotz Xyzzy <nitfol@example.xz>
which clearly is worse-looking with the extra LF you added in this patch.
> strbuf_addstr(&msgbuf, sha1_to_hex(commit->object.sha1));
> strbuf_addstr(&msgbuf, ")\n");
> }
^ permalink raw reply
* Re: [PATCH/RFC v2] Document format of basic Git objects
From: Junio C Hamano @ 2012-02-19 9:14 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Jonathan Niedier, Shawn O. Pearce, Scott Chacon
In-Reply-To: <7vlinzp67m.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> Still draft for discussion.
Small clarifications and corrections.
> ... from a larger
> workflow point of view it would not be so useful, as it would involve
> steps like this:
>
> ...
> * Then you give the general public the resulting commit.
The point of the above is *not* that it involves hash-object or having to
preserve both author and committer dates when secondary signers sign the
commit---these are something the tool *could* learn to assist. The point
is that adding more signatures *must* change the resulting commit object
name, making it necessary not to expose it to the general public in order
to avoid history rewinding, which *is* what makes it "not so useful".
And that is why I didn't add such a tool support to help producing the end
result that wouldn't be so useful anyway.
>> +TREE OBJECTS
>> +------------
>> +Tree object payload contains a list of entries, each with a mode,
>> +object type, object name, and filename, sorted by filename. It
>> +represents the contents of a single directory tree.
>
> Drop "object type," from this list. It is inferred from the mode. I
> personally would prefer to say "path" or "pathname" when the entity
> referred to may not be a regular file.
The principle is not to say "filename" to give an incorrect impression
that we are only talking about a regular file. This principle applies to
pathnames in general (i.e. covers what is recorded in the index, too), but
because we are talking about an entry in a tree, "pathname component" is
even better than "path" or "pathname", because it has a specific meaning:
one part of pathname delimited by a slash.
POSIX does use "filename" for this purpose (and mentions "pathname
component" as a synonym), but if we use the word, without clarifying that
this document uses it in the strict POSIX sense, the reader can easily
misunderstand that we mean a more general "name of a regular file".
>> +The object type may be a blob, representing the contents of a file,
>> +another tree, representing the contents of a subdirectory, or a commit
>> +(representing a subproject).
>
> and drop the above line.
Should be obvious from the context, but I meant "drop the above three
lines".
> I personally do not think it is necessary to have the above paragraph at
> all in this object.
s/in this object/in this document/;
>> +Encoding
>> +~~~~~~~~
>
> "Encoding" is such a loaded word and does not help clarify what this
> section is really about, which is "format of a tree entry", or simply
> "Entries".
>
>> +Entries are of variable length and self-delimiting. Each entry
>> +consists of
Actually, title this section as "Tree Entries", and begin the paragraph
with
Tre entries are of ...delimiting. Each entry consists of...
>> +Ident strings
>> +~~~~~~~~~~~~~
>> +Ident strings record who's responsible of doing something at what
>> +time. For a commit, the ident string in "author" line records who is
>> +the author of the associated changes and when the changes are
>
> s/are/were/, perhaps? Again, what the purpose of this document? If this
> were more than to strictly describe the "structure", it is OK and even
s/ more than to/to/;
> preferable to leave the meaning the "author" as vague, but if this were
> also to suggest the best current practice interpretation, it may be worth
> to add something like
>
> There may be a case where it is difficult to attribute a commit to
> a single author; think of it as recording the primary contact, the
> person to ask any questions about the commit if needed later.
^ permalink raw reply
* Re: [PATCH 1/2] git-svn.perl: perform deletions before anything else
From: Eric Wong @ 2012-02-19 10:54 UTC (permalink / raw)
To: Steven Walter; +Cc: gitster, git
In-Reply-To: <CAK8d-a+tdK=Jn6D+X=bJmKTzbESPqd8+S2nJr9_sfdb7MhLN1A@mail.gmail.com>
Steven Walter <stevenrwalter@gmail.com> wrote:
> I don't think git-svn should artificially fail in the case. This is
> using svn 1.6.17
> What's the oldest version of svn supported by git-svn? Perhaps if I
> retry with that version of svn, I would see a failure. However, if
> libsvn-perl reports the failure correctly, isn't that good enough
> behavior? No need to fail in git-svn before even trying, IMHO.
Originally (back in 2006/2007), the goal was to support SVN 1.1.x+.
I'm not sure if I we ever lost support for such old versions.
I use Debian stable for testing patches, and SVN is 1.6.12 there.
Otherwise, whatever people are willing to support and send
patches/bugreports for is good.
> Is there a way to validate what the checksums should be, other than to
> look at it and say, "yup, the trees look okay?"
As far as I remember, that's how I originally wrote the tests.
> Assuming you agree with the above analysis, should I squash the test
> changes into my 2/2, or would you prefer a separate patch?
Your analysis seems correct. I always prefer test changes to be
combined with corresponding commits to avoid breakage during bisect.
Thanks!
^ permalink raw reply
* [PATCH] tag: refuse tag messages that contain NULs
From: Nguyễn Thái Ngọc Duy @ 2012-02-19 11:43 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
This follows the paranoid spirit in 37576c1 (commit_tree(): refuse
commit messages that contain NULs - 2011-12-15) and stops users from
creating tags that contain NULs. If these tags are merged into a commit
as mergetag lines, they may break the commit header processing badly.
While at it, check for NULs in mergetag and gpgsig lines before
committing too.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/mktag.c | 3 +++
builtin/tag.c | 2 ++
commit.c | 2 ++
t/t7004-tag.sh | 4 ++++
4 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/builtin/mktag.c b/builtin/mktag.c
index 640ab64..f51ce20 100644
--- a/builtin/mktag.c
+++ b/builtin/mktag.c
@@ -165,6 +165,9 @@ int cmd_mktag(int argc, const char **argv, const char *prefix)
if (verify_tag(buf.buf, buf.len) < 0)
die("invalid tag signature file");
+ if (memchr(buf.buf, '\0', buf.len))
+ die("a NUL byte in tag message not allowed.");
+
if (write_sha1_file(buf.buf, buf.len, tag_type, result_sha1) < 0)
die("unable to write tag file");
diff --git a/builtin/tag.c b/builtin/tag.c
index 31f02e8..e66811e 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -259,6 +259,8 @@ static int build_tag_object(struct strbuf *buf, int sign, unsigned char *result)
{
if (sign && do_sign(buf) < 0)
return error(_("unable to sign the tag"));
+ if (memchr(buf->buf, '\0', buf->len))
+ return error("a NUL byte in tag message not allowed.");
if (write_sha1_file(buf->buf, buf->len, tag_type, result) < 0)
return error(_("unable to write tag file"));
return 0;
diff --git a/commit.c b/commit.c
index 4b39c19..545325f 100644
--- a/commit.c
+++ b/commit.c
@@ -1144,6 +1144,8 @@ int commit_tree_extended(const struct strbuf *msg, unsigned char *tree,
strbuf_addf(&buffer, "encoding %s\n", git_commit_encoding);
while (extra) {
+ if (memchr(extra->value, '\0', extra->len))
+ return error("a NUL byte in commit header %s not allowed.", extra->key);
add_extra_header(&buffer, extra);
extra = extra->next;
}
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index e93ac73..8cb13e5 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1269,4 +1269,8 @@ test_expect_success 'mixing incompatibles modes and options is forbidden' '
test_must_fail git tag -v -s
'
+test_expect_success 'tag content contains NUL' '
+ test_must_fail git tag -F "$TEST_DIRECTORY"/t3900/UTF-16.txt utf16
+'
+
test_done
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Working with remotes with (too) many branches
From: Philip Jägenstedt @ 2012-02-19 15:29 UTC (permalink / raw)
To: git
Hi,
I work on a project where topic branches are allowed in the main
repository and are not removed even if/when they are merged. This
results in an ever-growing number of branches (and tags), making e.g.
tab completion slow to the point of being useless. We know that this
is not great and it will probably change, but in the meantime I have
set up an alternative origin that only includes the master branch and
annotated tags. However, I still need to collaborate on some topic
branches in the main repository, and have arrived at this solution:
$ git remote add -t footopic -f --no-tags main example.com:/git/main.git
$ git checkout -t main/footopic
# next day
$ git remote set-branches --add main bartopic
$ git fetch main
$ git checkout -t main/bartopic
This works fairly well, but there are a few wrinkles:
1. If I make a typo with remote set-branches, fetch will fail with
"fatal: Couldn't find remote ref refs/heads/typotopic" and not fetch
anything at all.
2. If I forget that I've previously worked with footopic and
set-branches --add it again, I'll get a duplicate line in my config.
3. When I don't care about footopic anymore, there's no clear way to
stop fetching it and remove refs/remotes/main/footopic.
4. If set-branches --delete existed one could end up with no fetch
lines in the remote config, at which point fetch falls back to
fetching HEAD, instead of the expected nothing.
1 and 2 seem fairly easy to fix: add set-branches --delete and use the
same logic to make --add also remove duplicates. Would changing the
git_config_set_multivar call in add_branch (remote.c) be the right
kind of fix here?
3 is less clear to me. Is it a bug that fetch --prune only prunes refs
that it actually tried to fetch, or is it remote prune that should be
taking care of this? Alternatively, should it be the non-existent
set-branches --delete?
4 could be a deliberate fallback, or is it a bug waiting to be exposed?
I'd appreciate feedback on these issues so that I don't waste time
trying to patch the wrong problems. Suggestions for an alternative
work flow is of course also most welcome!
--
Philip Jägenstedt
^ permalink raw reply
* Manually decoding a git object
From: Philip Oakley @ 2012-02-19 18:07 UTC (permalink / raw)
To: Git List
In-Reply-To: <1329624946-32173-1-git-send-email-pclouds@gmail.com>
If I have a renamed file which is a git object, such a "Git_Object", was
8c-something-or-other, what is the easiest way of examining / decoding /
recreating the original file (either as its sha1, or a cat-file).
I don't appear to be able to unzip the file in its raw format... I'm using
Msysgit on windows XP.
Philip
^ permalink raw reply
* git-svn show-externals and svn version
From: Nikolaus Demmel @ 2012-02-19 18:53 UTC (permalink / raw)
To: git
Hi,
I am currently investigating getting support for svn externals in git-svn (you might have noticed my other mails).
It turns out that there are quite a few scripts floating around that use the output of show-externals and then try to pull these externals with git-svn into independent repositories and add the folders as submodules to the root repository.
However, none of them work for me, and the primary reason AFAICT is that they were written for the pre svn1.5 format of svn:externals. From 1.5 svn supports a new format of svn:externals, which changes the order of revision, repository-url, and local folder, and also adds the posibility to add relative urls, peg-revisions, etc [1].
On top that it seems to me that the output of show-externals was purely designed for the old format. For example, if you compare the output of "git svn show-externals" with "git svn propget svn:externals" in an example repository using the new format [2], you find that the in the show-externals output the prepended "/" and "/instantiations/" at the beginning of each line does not make sense. If the target url (all relative with the ^ syntax in this case) and the sub-folder were swapped in order, as of pre 1.5 svn, it would make much more sense. Also apparently the code for show-externals was added in 2007 and not changed since, whereas svn 1.5 was released in 2008.
What I am not completely clear about is, whether svn 1.5 and later enforces the new syntax, or whether it just adds the new syntax and still has to support the old syntax (which could be distinguished, I guess, by checking of the last part on an entry is an absolute URL instead of a subfolder). Also, I'm not sure if the format depends on the version of the svn-server or the client. I would assume you can check out a repository hosted with svn 1.4 with a 1.5 client. Does the client process the svn:externals and present it in the new format, or is this the text string just taken from the server unaltered (I have not much knowledge of how svn actually works internally)?
Another question is whether the perl svn bindings present the svn:externals in some parsed, standard format, or do they just give you the raw text string?
In order to make show-externals more useful with the svn 1.5 and later syntax, one would maybe need to check the underlying svn version. I guess it is also quite important to retain backwards compatibility, such that users of externals with the old syntax would still get the same output as before.
I would suggest that the show-externals output should be as close as possible to the svn:externals syntax, possibly adapting the subfolder path for nested folders. However here the recursive display of externals for subfolders becomes a bit more tricky, since the URL can also be relative to the subfolder as of the new syntax. Maybe the easiest way to deal with the new syntax in show-externals would be to have each line like it is in the svn-properties, but add a space separated relative path to the corresponding subfolder at the beginning. A tool that uses this is then responsible for making sure the relative URLs are resolved correctly.
To sum up, given that all the questions I have are answered like I think is most likely, it would boil down to changing the output of show-externals for svn 1.5 and later just slightly, namely by inserting an additional space between the prepended subfolder and the actual svn:externals definition in each line.
Any thoughts and/or answers?
Cheers,
Nikolaus
[1] http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html
[2] http://paste.lisp.org/display/127858
^ permalink raw reply
* Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)
From: Nicolas Mailhot @ 2012-02-19 21:03 UTC (permalink / raw)
To: git
Since
http://code.google.com/p/chromium/issues/detail?id=7338 and
https://bugzilla.mozilla.org/show_bug.cgi?id=479880
there is no clean way for a proxy or captive portal to get a web client to
display an authentication dialog when user credentials expire while he is
browsing on an https url.
(to be sure, the previous methods were insecure and hackish but they existed
because nothing better was available)
The IETF finally set up to fix this problem and defined a standard HTTP error
that lets access control equipments tell the web client authentication or
re-authentication is needed and where the authentication form is located.
http://tools.ietf.org/id/draft-nottingham-http-new-status-04.txt
→ <http://www.rfc-editor.org/queue2.html#draft-nottingham-http-new-status> (the
spec is approved and in the queue for publication as RFC)
Please add error 511 handling in git, so git users that try to access external
git repositories over http can authenticate on the corporate proxy
^ permalink raw reply
* Re: Working with remotes with (too) many branches
From: Junio C Hamano @ 2012-02-19 21:36 UTC (permalink / raw)
To: Philip Jägenstedt; +Cc: git, Jonathan Nieder
In-Reply-To: <CAKHWUka763XRWyMz2Xq1qQ2rfKqSYdTX0xtdVFm8zWJ_+6tGqA@mail.gmail.com>
Philip Jägenstedt <philip@foolip.org> writes:
> 1. If I make a typo with remote set-branches, fetch will fail with
> "fatal: Couldn't find remote ref refs/heads/typotopic" and not fetch
> anything at all.
At that point you can notice the earlier typo and remove or fix the fetch
refspec you have.
Alternatively, set-branches could run ls-remote against the remote and
notice that there is no such branch over there. However, even if you got
the branch name right when you did "set-branches", you would still see the
same "Couldn't find" when the branch gets removed over there, so you would
need a way to remove or fix the fetch refspec you have *anyway*.
So, assuming that there is no easy way to remove one branch from the set
of branches tracked from a given remote, it is much more important to add
such a way. Checking against a typo when "set-branches" is run is "nicer
to have" but lack of it is not a show-stopper.
Wouldn't "git config --unset remote.origin.fetch '/typotopic'" be
sufficient in the meantime even if a user fears "vi .git/config"?
> 2. If I forget that I've previously worked with footopic and
> set-branches --add it again, I'll get a duplicate line in my config.
I do not know the duplicate hurts anything, but I agree that it would be
more aescetically pleasing if "--add" noticed what you already had and
avoided duplicates.
> 3. When I don't care about footopic anymore, there's no clear way to
> stop fetching it and remove refs/remotes/main/footopic.
Isn't the lack of "set-branches --delete" the same as #1 above? The
latter would be "branch -r -d main/footopic" but I could imagine
"set-branches --delete" would do that for you once implemented.
> 4. If set-branches --delete existed one could end up with no fetch
> lines in the remote config, at which point fetch falls back to
> fetching HEAD, instead of the expected nothing.
Don't do that, then ;-)
I could imagine a new preference "fetch.$remote.default=nothing" that
causes "git fetch" to fail with "You have fetch.$remote.default=nothing
set, so I am not fetching anything from there without any configured
refspec". The default would be fetch.$remote.default=HEAD, I would guess.
The preference can be set automatically when you use "set-branches"
without "--add" for a given remote, as use of "set-branches" is a clear
indication that you want to deviate from the built-in default behaviour
when interacting with that remote.
> I'd appreciate feedback on these issues so that I don't waste time
> trying to patch the wrong problems. Suggestions for an alternative
> work flow is of course also most welcome!
Admittedly I wouldn't use "set-branches" myself (it is far easier to tweak
with "vi .git/config", and I wasn't involved in), but looking at the whole
history of the feature with "git log --grep=set-branch builtin/remote.c",
I have a feeling that not many people used, cut by its still-unrounded
edges, and polished the subcommand by rounding them out yet, and it has a
large room for improvement.
It would have saved you time to wait for a round-trip if you did the above
"git log" yourself to find out from whom this subcommand came from, and
looked at list archive to see if the original author is still active here
(in this case he is), and Cc'ed him before posting the message I am
responding to.
^ permalink raw reply
* Re: [PATCH] tag: refuse tag messages that contain NULs
From: Junio C Hamano @ 2012-02-19 21:40 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1329651837-1102-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> diff --git a/builtin/mktag.c b/builtin/mktag.c
> index 640ab64..f51ce20 100644
> --- a/builtin/mktag.c
> +++ b/builtin/mktag.c
> @@ -165,6 +165,9 @@ int cmd_mktag(int argc, const char **argv, const char *prefix)
> if (verify_tag(buf.buf, buf.len) < 0)
> die("invalid tag signature file");
>
> + if (memchr(buf.buf, '\0', buf.len))
> + die("a NUL byte in tag message not allowed.");
> +
Is there a good reason why you check _after_ calling verify_tag(), instead
of before?
> if (write_sha1_file(buf.buf, buf.len, tag_type, result_sha1) < 0)
> die("unable to write tag file");
>
> diff --git a/builtin/tag.c b/builtin/tag.c
> index 31f02e8..e66811e 100644
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -259,6 +259,8 @@ static int build_tag_object(struct strbuf *buf, int sign, unsigned char *result)
> {
> if (sign && do_sign(buf) < 0)
> return error(_("unable to sign the tag"));
> + if (memchr(buf->buf, '\0', buf->len))
> + return error("a NUL byte in tag message not allowed.");
Is there a good reason why you check _after_ calling do_sign(), instead of
before?
^ permalink raw reply
* RE: Mixing and matching multiple projects
From: Holding, Lawrence @ 2012-02-20 0:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v39a9tf45.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > But I wonder if we can do without forking the /s/xyzzy/os/.git
submodule?
> >
> > If we *could* do this:
> >
> > cd /s/xyzzy
> > mkdir os/drivers/frotz && populate the directory with sources
>
> A crucial step was missing here for my story to make *any* sense.
Sorry.
> A step to create a repository at /s/xyzzy/os/drivers/frotz/.git must
be
> here, like this:
>
> (cd os/drivers/frotz && git init && git add . && git commit)
>
> And then that is added as a submodule to the superproject.
>
> > git add os/drivers/frotz ;# to the top-level superproject!!
> >
> > to add the "frotz driver" submodule directly to the superproject,
then we
> > could leave /s/xyzzy/os/.git intact, letting it follow the open
source
> > world. Because the superproject must be forked in order to keep
track of
> > what happens in the appliance that supports the "frotz" driver
anyway,
> > this could result in the minimum amount of forking from the end
user's
> > point of view.
> >
> ........
> >
How about
- creating a "driver" project in the superproject,
- add a .gitignore or .git/exclude entry for the
/s/xyzzy/os/drivers/frotz folder into the os project
- symlinking the /s/xyzzy/os/drivers/frotz folder to the
/s/xyzzy/driver/frotz folder
some of this can be automated in the post checkout script of the
superproject.
^ permalink raw reply
* Re: Mixing and matching multiple projects
From: Junio C Hamano @ 2012-02-20 0:36 UTC (permalink / raw)
To: Holding, Lawrence; +Cc: git
In-Reply-To: <A5E8E180685CEF45AB9E737A010799802D972E@cdnz-ex1.corp.cubic.cub>
"Holding, Lawrence" <Lawrence.Holding@cubic.com> writes:
> How about
> - creating a "driver" project in the superproject,
> - add a .gitignore or .git/exclude entry for the
> /s/xyzzy/os/drivers/frotz folder into the os project
> - symlinking the /s/xyzzy/os/drivers/frotz folder to the
> /s/xyzzy/driver/frotz folder
Thanks.
I think that is essentially the same as what I wrote with "symlink" in my
last paragraph as a known-to-work workaround. The real location of the
frotz driver, whether it is in a directory directly in the superproject,
or a separate submodule that is bound to the superproject outside the "os"
submodule, does not make an essential difference, as long as it is outside
"os".
I was asking if people who have used submodules have better solutions than
that "symlink" solution.
^ permalink raw reply
* Re: git-svn won't remember pem password
From: Jeff King @ 2012-02-20 0:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Igor, git, Eric Wong
In-Reply-To: <m3zkcgqt0g.fsf@localhost.localdomain>
On Sat, Feb 18, 2012 at 03:30:00AM -0800, Jakub Narebski wrote:
> Igor <mrigor83@gmail.com> writes:
>
> > I'm running into an issue where I have to enter my pem certificate
> > password every time I git-svn fetch or git-svn dcommit. Vanilla svn
> > uses OS X KeyChain and remembers my password just fine. Is there a
> > known solution for this? Other users have ran into same issue as
> > described here:
> >
> > http://stackoverflow.com/questions/605519/does-git-svn-store-svn-passwords
>
> > However, that solution of removing .subversion folder did not work
> > for me.
>
> I don't know if it is svn that has to remember password, or git that
> has to remember password. Git 1.7.9 learned "credentials API" that
> allows integration with platform native keychain mechanisms, and I
> think OS X Keychain is one of examples / supported platforms (but it
> might not made it into core git)... though I am not sure if it affects
> git-svn, or only HTTP(S) transport.
It does not affect git-svn currently.
I have some thoughts on providing access to the credentials API for
scripts like git-svn (right now, it is accessible only by C git
programs). However, there is an important question: should password
prompting in git-svn behave like git, or behave like svn?
So far, it has been the latter, and I think that is reasonable. The
resource that requires the credentials is an svn repo, not a git repo,
so you are more likely to want to share credentials for it with real
svn, and not other git commands.
As to the lack of keychain support, it looks like libsvn should be
handling this for us. We simply give it a callback function that gets
called if the user needs prompted, but I would think things like the
keychain handling would happen before it gets to our prompt (and if I
understand it, for _some_ credential storage formats, it does). So
either there is a bug in libsvn, or we are somehow invoking it
incorrectly.
-Peff
^ permalink raw reply
* Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)
From: Jeff King @ 2012-02-20 1:06 UTC (permalink / raw)
To: Nicolas Mailhot; +Cc: git
In-Reply-To: <4b8f33ba4c870528a82ab85d6dad68bd.squirrel@arekh.dyndns.org>
On Sun, Feb 19, 2012 at 10:03:37PM +0100, Nicolas Mailhot wrote:
> The IETF finally set up to fix this problem and defined a standard HTTP error
> that lets access control equipments tell the web client authentication or
> re-authentication is needed and where the authentication form is located.
>
> http://tools.ietf.org/id/draft-nottingham-http-new-status-04.txt
>
> → <http://www.rfc-editor.org/queue2.html#draft-nottingham-http-new-status> (the
> spec is approved and in the queue for publication as RFC)
>
> Please add error 511 handling in git, so git users that try to access external
> git repositories over http can authenticate on the corporate proxy
If I'm reading this right, the process works something like this:
1. Git wants to make a request to http://example.com
2. We make our request to a proxy server which is transparently
proxying our traffic (i.e, a "captive portal").
3. The proxy returns 511 along with some URL (e.g.,
"http://login.corporatenetwork"), indicating that we need
to go to that URL to complete some authentication.
As a non-browser client, what should git do? We can't make sense of the
content at http://login.corporatenetwork, which is most likely an HTML
form asking for credentials (or even money, if the captive portal is
something like a public wireless provider). The best we can probably do
is die and say "apparently you need to go http://login.corporatenetwork
in a browser before making your request".
Reading that rfc draft, the man impetus for non-browser clients seems
not to get them to do anything useful, but rather to return them a code
that is clearly not from the actual site (if it were a redirect, for
example, then we would think that example.com is redirecting is, which
is simply not true).
-Peff
^ 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