* Re: Bug: git log --numstat counts wrong
From: Alexander Pepper @ 2011-09-22 13:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tay Ray Chuan
In-Reply-To: <7vobyd1vmo.fsf@alter.siamese.dyndns.org>
Am 21.09.2011 um 22:35 schrieb Junio C Hamano:
> That's a tad old master you seem to have.
Up until now I only followed the github clone, but that seems to be dated. Since kernel.org is still down, I'll now follow the google code clone.
Am 21.09.2011 um 22:35 schrieb Junio C Hamano:
>> Am 21.09.2011 um 14:24 schrieb Junio C Hamano:
>>>> $ git log --numstat 48a07e7e533f507228e8d1c99d4d48e175e14260
>>>> [...]
>>>> 11 10 src/java/voldemort/server/storage/StorageService.java
>>>
>>> Didn't we update it this already? I seem to get 10/9 here not 11/10.
>>
>> Current 'maint' (cd2b8ae9), 'master' (4b5eac7f)...
>
> Strangely, bisection points at 27af01d5523, which was supposed to be only
> about performance and never about correctness. There is something fishy
> going on....
I also did some tests, and besides --numstat also git show sometimes show different patches in comparison to older git versions. The last version with the "old" git show output is 1.7.7.rc0 and the first version with the "new" git show output is 1.7.7.rc1.
with git version 1.7.7.rc0:
$ git show 679e1d5cd007a0a9cb2813bd155622d7a1e904bd :
[...]
diff --git a/src/java/voldemort/store/stats/RequestCounter.java b/src/java/voldemort/store/stats/RequestCounter.java
index b012e98..c6be603 100644
--- a/src/java/voldemort/store/stats/RequestCounter.java
+++ b/src/java/voldemort/store/stats/RequestCounter.java
@@ -64,16 +64,21 @@ public class RequestCounter {
Accumulator accum = values.get();
long now = System.currentTimeMillis();
- if(now - accum.startTimeMS > durationMS) {
- Accumulator newWithTotal = accum.newWithTotal();
- values.set(newWithTotal);
-
- /*
- * try to set. if we fail, then someone else set it, so just keep going
- */
- if(values.compareAndSet(accum, newWithTotal)) {
- return newWithTotal;
- }
+ /*
+ * if still in the window, just return it
+ */
+ if(now - accum.startTimeMS <= durationMS) {
+ return accum;
+ }
+
+ /*
+ * try to set. if we fail, then someone else set it, so just return that new one
+ */
+
+ Accumulator newWithTotal = accum.newWithTotal();
+
+ if(values.compareAndSet(accum, newWithTotal)) {
+ return newWithTotal;
}
return values.get();
with git version 1.7.7.rc1:
$ git show 679e1d5cd007a0a9cb2813bd155622d7a1e904bd
[...]
diff --git a/src/java/voldemort/store/stats/RequestCounter.java b/src/java/voldemort/store/stats/RequestCounter.java
index b012e98..c6be603 100644
--- a/src/java/voldemort/store/stats/RequestCounter.java
+++ b/src/java/voldemort/store/stats/RequestCounter.java
@@ -64,16 +64,21 @@ public class RequestCounter {
Accumulator accum = values.get();
long now = System.currentTimeMillis();
- if(now - accum.startTimeMS > durationMS) {
- Accumulator newWithTotal = accum.newWithTotal();
- values.set(newWithTotal);
+ /*
+ * if still in the window, just return it
+ */
+ if(now - accum.startTimeMS <= durationMS) {
+ return accum;
+ }
- /*
- * try to set. if we fail, then someone else set it, so just keep going
- */
- if(values.compareAndSet(accum, newWithTotal)) {
- return newWithTotal;
- }
+ /*
+ * try to set. if we fail, then someone else set it, so just return that new one
+ */
+
+ Accumulator newWithTotal = accum.newWithTotal();
+
+ if(values.compareAndSet(accum, newWithTotal)) {
+ return newWithTotal;
}
return values.get();
The difference is, that now it's shown as two delete and two added hunks instead of one bigger delete and one bigger added hunk.
with git version 1.7.7.rc1:
$ git show 679e1d5cd007a0a9cb2813bd155622d7a1e904bd | diffstat
RequestCounter.java | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
with git version 1.7.7.rc0:
$ git show 679e1d5cd007a0a9cb2813bd155622d7a1e904bd | diffstat
RequestCounter.java | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
When used git version 1.7.7.rc1 I didn't observed any case where git show and git log --numstat mismatch. I'm only a little confused, that 'git show' yields different results, depending on the git version.
Greetings from Berlin
Alex
^ permalink raw reply related
* [PATCH v2 2/2] Add explanation why we do not allow to sparse checkout to empty working tree
From: Nguyễn Thái Ngọc Duy @ 2011-09-22 11:24 UTC (permalink / raw)
To: git, Junio C Hamano
Cc: Michael J Gruber, Joshua Jensen,
Nguyễn Thái Ngọc Duy
In-Reply-To: <7vk4911ux8.fsf@alter.siamese.dyndns.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
unpack-trees.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index fcf40a0..bacb473 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1119,8 +1119,13 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
}
if (ret < 0)
goto return_failed;
+ /*
+ * Sparse checkout is meant to narrow down checkout area
+ * but it does not make sense to narrow down to empty working
+ * tree. This is usually a mistake in sparse checkout rules.
+ * Do not allow users to do that.
+ */
if (o->result.cache_nr && empty_worktree) {
- /* dubious---why should this fail??? */
ret = unpack_failed(o, "Sparse checkout leaves no entry on working directory");
goto done;
}
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* [PATCH v2 1/2] sparse checkout: show error messages when worktree shaping fails
From: Nguyễn Thái Ngọc Duy @ 2011-09-22 11:24 UTC (permalink / raw)
To: git, Junio C Hamano
Cc: Michael J Gruber, Joshua Jensen,
Nguyễn Thái Ngọc Duy
In-Reply-To: <7vk4911ux8.fsf@alter.siamese.dyndns.org>
verify_* functions can queue errors up and to be printed later at
label return_failed. In case of errors, do not go to label "done"
directly because all queued messages would be dropped on the floor.
Found-by: Joshua Jensen <jjensen@workspacewhiz.com>
Tracked-down-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Now print all errors.
t/t1011-read-tree-sparse-checkout.sh | 15 +++++++++++++++
unpack-trees.c | 13 ++++++++++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/t/t1011-read-tree-sparse-checkout.sh b/t/t1011-read-tree-sparse-checkout.sh
index 018c354..efcd8ab 100755
--- a/t/t1011-read-tree-sparse-checkout.sh
+++ b/t/t1011-read-tree-sparse-checkout.sh
@@ -234,4 +234,19 @@ test_expect_success 'read-tree --reset removes outside worktree' '
test_cmp empty result
'
+test_expect_success 'print errors when failed to update worktree' '
+ echo sub >.git/info/sparse-checkout &&
+ git checkout -f init &&
+ mkdir sub &&
+ touch sub/added sub/addedtoo &&
+ test_must_fail git checkout top 2>actual &&
+ cat >expected <<\EOF &&
+error: The following untracked working tree files would be overwritten by checkout:
+ sub/added
+ sub/addedtoo
+Please move or remove them before you can switch branches.
+EOF
+ test_cmp expected actual
+'
+
test_done
diff --git a/unpack-trees.c b/unpack-trees.c
index cc616c3..fcf40a0 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1089,6 +1089,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
*/
mark_new_skip_worktree(o->el, &o->result, CE_ADDED, CE_SKIP_WORKTREE | CE_NEW_SKIP_WORKTREE);
+ ret = 0;
for (i = 0; i < o->result.cache_nr; i++) {
struct cache_entry *ce = o->result.cache[i];
@@ -1101,17 +1102,23 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
* correct CE_NEW_SKIP_WORKTREE
*/
if (ce->ce_flags & CE_ADDED &&
- verify_absent(ce, ERROR_WOULD_LOSE_UNTRACKED_OVERWRITTEN, o))
- return -1;
+ verify_absent(ce, ERROR_WOULD_LOSE_UNTRACKED_OVERWRITTEN, o)) {
+ if (!o->show_all_errors)
+ goto return_failed;
+ ret = -1;
+ }
if (apply_sparse_checkout(ce, o)) {
+ if (!o->show_all_errors)
+ goto return_failed;
ret = -1;
- goto done;
}
if (!ce_skip_worktree(ce))
empty_worktree = 0;
}
+ if (ret < 0)
+ goto return_failed;
if (o->result.cache_nr && empty_worktree) {
/* dubious---why should this fail??? */
ret = unpack_failed(o, "Sparse checkout leaves no entry on working directory");
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Michael Schubert @ 2011-09-22 9:14 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Junio C Hamano, git
In-Reply-To: <1316680641.11165.2.camel@bee.lab.cmartin.tk>
On 09/22/2011 10:37 AM, Carlos Martín Nieto wrote:
> On Wed, 2011-09-21 at 22:04 -0700, Junio C Hamano wrote:
>> * cn/eradicate-working-copy (2011-09-21) 2 commits
>> - patch-id.c: use strbuf instead of a fixed buffer
>> - Remove 'working copy' from the documentation and C code
>
> It looks like that first commit sneaked in there. Shouldn't that be its
> own topic?
It's in pu twice:
On 09/22/2011 07:04 AM, Junio C Hamano wrote:
> * cn/eradicate-working-copy (2011-09-21) 2 commits
> - patch-id.c: use strbuf instead of a fixed buffer
> - Remove 'working copy' from the documentation and C code
> * ms/patch-id-with-overlong-line (2011-09-21) 1 commit
> - patch-id.c: use strbuf instead of a fixed buffer
64128da and a6c5c60
There's also a minor typo in the last sentence of the commit message.
Should I resend?
^ permalink raw reply
* Re: [PATCH] abspath: increase array size of cwd variable to PATH_MAX
From: wanghui @ 2011-09-22 8:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramsay Jones, git
In-Reply-To: <7vty851wg9.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>
>> Hmm, the subject line says "... increase array size ...", but that is not
>> necessarily what this patch is doing! :-D
>>
>
> True; will revert it out of 'next'.
>
> Thanks for noticing.
>
>
Hi Junio and Ramsay,
In fact, i found lots of similar usage in the git source code. E.G.
in the dir.c,
int is_inside_dir(const char *dir)
{
char cwd[PATH_MAX];
if (!dir)
return 0;
if (!getcwd(cwd, sizeof(cwd)))
die_errno("can't find the current directory");
return dir_inside_of(cwd, dir) >= 0;
}
Since this implementation is not cross-OS safe, Could we use below solution?
step1, add a new function xgetcwd() to wrapper getcwd() like this:
char *xgetcwd(void)
{
size_t size = 100;
while (1) {
char *buffer = (char *) xmalloc (size);
if (getcwd (buffer, size) == buffer)
return buffer;
free (buffer);
if (errno != ERANGE)
return 0;
size *= 2;
}
}
step2, use xgetcwd to replace all getcwd occurrence in the git source code.
This will add a little bit overhead to the git, but it is cross-OS safe.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Carlos Martín Nieto @ 2011-09-22 8:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa9xyxpf.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 328 bytes --]
On Wed, 2011-09-21 at 22:04 -0700, Junio C Hamano wrote:
> * cn/eradicate-working-copy (2011-09-21) 2 commits
> - patch-id.c: use strbuf instead of a fixed buffer
> - Remove 'working copy' from the documentation and C code
It looks like that first commit sneaked in there. Shouldn't that be its
own topic?
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Michael Haggerty @ 2011-09-22 8:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git discussion list, Jay Soffian
In-Reply-To: <7vy5xh1whq.fsf@alter.siamese.dyndns.org>
On 09/21/2011 10:17 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> I was thinking of using git attributes to configure a server-side
>> "update" hook that does some basic sanity checking before accepting a
>> push. I thought I could do something like
>>
>> ~/.gitattributes:
>> *.c whitespace
>>
>> ~/crappy-vendor-code/.gitattributes:
>> # This code doesn't conform to our standards; disable check:
>> *.c -whitespace
>>
>> This would allow fine-grained specification of which checks are applied
>> to which files, and ensure that the hook configuration is kept
>> synchronized with changes to the content.
>
> The words "server side" automatically mean that there should be no working
> tree, and where there is no working tree there should be no index, so the
> direction should not make any difference. The attributes that are used to
> help whitespace checks should come from project.git/info/attributes in
> such a case [*1*].
Thanks for the reply and for explaining how the index can(not) be used
for this purpose. But what you propose is not flexible enough for me.
I would like the checking configuration to be *versioned* along with the
code. For example, suppose my project decides to enforce a rule that
all Python code needs to be indented with spaces. It might be that not
all of our old code adheres to this rule, and that we only want to clean
up the code in master. I would like to be able to
1. Implement a new "check-space-indent" option in our update hook, which
is applied to any file that has the "check-space-indent" attribute. At
first, no files have this attribute, so the new test has no effect.
2. Start cleaning up code in master. Each time a subdirectory tree is
cleaned up, add a line like
*.py check-space-indent
in a .gitattributes file at the root of the subdirectory tree. While
this procedure proceeds incrementally, git ensures that code that has
been cleaned up stays cleaned up.
3. When all code is cleaned up, add the above line to the top-level
.gitattributes file in the master branch. But if there are some parts
of the code that we don't want to clean up (for example, code acquired
from elsewhere that uses different coding standards), we can turn off
the check for that subdirectory tree.
Note that during this whole process all code passes the update hook,
because we can configure it to ignore problems in code that hasn't been
cleaned up yet. And even at the end of the procedure, it is still
possible to commit to older branches where tabs are still used for
indentation because they don't use the new attribute.
For this to be possible, I would need to determine the git attributes to
apply to a particular file in a particular commit; something like
git check-attr check-space-indent $SHA1:path/to/file
This does not seem to be possible today without writing my own code to
crawl and parse the gitattributes files from a particular commit.
> (1) grab the new commits introduced to the project using rev-list, and
> invoke "git show --check" on each and every one of them; or
Where does "git show --check" read its gitattributes (i.e.,
"whitespace") from?
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH v3] Docs: Clarify the --tags option of `git fetch'
From: Michael Witten @ 2011-09-22 7:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Anatol Pomozov, Drew Northup, Andrew Ardill, Daniel Johnson, git
In-Reply-To: <7vfwjpyzds.fsf@alter.siamese.dyndns.org>
On Wed, 21 Sep 2011 21:28:15 -0700, Junio C Hamano wrote:
> I expect the readers to, and I hope the documentation to help them to,
> understand the following three basic facts and rules before diving into
> descriptions of individual options, such as the paragraph we are
> discussing:
>
> * "git fetch" command serves two purposes:
>
> (1) It transfers objects the repository the command is invoked in does
> not have from the remote repository. The objects transferred are the
> commits that are necessary to complete the ancestry chain of _some_
> history, and data (i.e. trees and blobs) associated to use these
> commits.
>
> (2) It optionally can update the local refs (e.g. branches and tags)
> with copies of the refs taken from the remote repository.
>
> * In the above, the user needs to tell the command two things. One is
> "where the remote repository is". The other is "what refs to fetch and
> (optionally) how to store them". The latter "what to fetch" also
> determines what that "_some_ history" above is (i.e. everything
> reachable from the refs that are fetched).
>
> * "What to fetch and how to store" have a default, recorded in the
> repository configuration file, that is used when the user does not give
> that information to the command from the command line. If the user does
> give that information from the command line, that default is not used
> at all. IOW, the command line overrides the default.
>
> With that understanding, the _only_ thing that "--tags" description needs
> to talk about is that it is an explicit way to give that "what to fetch
> and how to store" information from the command line. It instructs the
> command to fetch all the tags from the remote repository and store them
> locally.
For at least the near term, this patch may do a pretty good job of
achieving those goals without having to change too much; I do some
careful maneuvering to avoid mentioning refspecs until quite late
in the description.
8<-----------8<-----------8<-----------8<-----------8<-----------8<-----------
See the discussion starting here:
[PATCH] Clarify that '--tags' fetches tags only
Message-ID: <1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com>
http://thread.gmane.org/gmane.comp.version-control.git/180636
Suggested-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
Documentation/fetch-options.txt | 31 +++++++++++++++++++++++--------
1 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 39d326a..4cc5a80 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -56,14 +56,29 @@ endif::git-pull[]
ifndef::git-pull[]
-t::
--tags::
- Most of the tags are fetched automatically as branch
- heads are downloaded, but tags that do not point at
- objects reachable from the branch heads that are being
- tracked will not be fetched by this mechanism. This
- flag lets all tags and their associated objects be
- downloaded. The default behavior for a remote may be
- specified with the remote.<name>.tagopt setting. See
- linkgit:git-config[1].
+ Most of a remote's tags are fetched automatically as branches are
+ downloaded. However, git does not automatically fetch any tag that,
+ when 'git fetch' completes, would not be reachable from any local
+ branch head. This option tells git to fetch all tags (and their
+ associated objects).
++
+The 'git fetch' command is often supplied with a default set of branch
+heads to fetch, but using this option tells 'git fetch' to ignore those
+defaults.
++
+This option is merely a shorthand for writing the refspec
+`refs/tags/\*:refs/tags/\*'; that is,
++
+ git fetch origin --tags
+ git fetch origin --tags frotz
++
+are equivalent to:
++
+ git fetch origin 'refs/tags/*:refs/tags/*'
+ git fetch origin frotz 'refs/tags/*:refs/tags/*'
++
+The default behavior for a remote may be specified with
+the remote.<name>.tagopt setting. See linkgit:git-config[1].
--recurse-submodules[=yes|on-demand|no]::
This option controls if and under what conditions new commits of
--
1.7.6.409.ge7a85
^ permalink raw reply related
* Re: [PATCH 1/3] unpack-trees: print "Aborting" to stderr
From: Michael J Gruber @ 2011-09-22 5:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Joshua Jensen
In-Reply-To: <7v39fp1pvd.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 22.09.2011 00:40:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Forgot to update a test or two that this breaks?
>
> In the meantime I've squashed this in.
Yikes. Sorry and thanks!
>
> t/t7607-merge-overwrite.sh | 1 +
> t/t7609-merge-co-error-msgs.sh | 5 +++++
> 2 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/t/t7607-merge-overwrite.sh b/t/t7607-merge-overwrite.sh
> index 72a8731..aa74184 100755
> --- a/t/t7607-merge-overwrite.sh
> +++ b/t/t7607-merge-overwrite.sh
> @@ -107,6 +107,7 @@ error: The following untracked working tree files would be overwritten by merge:
> sub
> sub2
> Please move or remove them before you can merge.
> +Aborting
> EOF
>
> test_expect_success 'will not overwrite untracked file in leading path' '
> diff --git a/t/t7609-merge-co-error-msgs.sh b/t/t7609-merge-co-error-msgs.sh
> index c994836..0e4a682 100755
> --- a/t/t7609-merge-co-error-msgs.sh
> +++ b/t/t7609-merge-co-error-msgs.sh
> @@ -32,6 +32,7 @@ error: The following untracked working tree files would be overwritten by merge:
> three
> two
> Please move or remove them before you can merge.
> +Aborting
> EOF
>
> test_expect_success 'untracked files overwritten by merge (fast and non-fast forward)' '
> @@ -56,6 +57,7 @@ Please, commit your changes or stash them before you can merge.
> error: The following untracked working tree files would be overwritten by merge:
> five
> Please move or remove them before you can merge.
> +Aborting
> EOF
>
> test_expect_success 'untracked files or local changes ovewritten by merge' '
> @@ -71,6 +73,7 @@ error: Your local changes to the following files would be overwritten by checkou
> rep/one
> rep/two
> Please, commit your changes or stash them before you can switch branches.
> +Aborting
> EOF
>
> test_expect_success 'cannot switch branches because of local changes' '
> @@ -92,6 +95,7 @@ error: Your local changes to the following files would be overwritten by checkou
> rep/one
> rep/two
> Please, commit your changes or stash them before you can switch branches.
> +Aborting
> EOF
>
> test_expect_success 'not uptodate file porcelain checkout error' '
> @@ -105,6 +109,7 @@ error: Updating the following directories would lose untracked files in it:
> rep
> rep2
>
> +Aborting
> EOF
>
> test_expect_success 'not_uptodate_dir porcelain checkout error' '
^ permalink raw reply
* What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Junio C Hamano @ 2011-09-22 5:04 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
Here are the repositories that have my integration branches:
With maint, master, next, pu and todo:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
With only maint and master:
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
url = https://github.com/gitster/git
Without kernel.org working, this feature-freeze rc cycle is not really
working smoothly. I could take things slowly just like our previous
maintainer declared to do for his other project, but I probably will end
up releasing the 1.7.7 final by the end of this week without kernel.org.
--------------------------------------------------
[New Topics]
* bw/grep-no-index-no-exclude (2011-09-15) 2 commits
- grep --no-index: don't use git standard exclusions
- grep: do not use --index in the short usage output
* jc/namespace-doc-with-old-asciidoc (2011-09-16) 1 commit
- Documentation/gitnamespaces.txt: cater to older asciidoc
* jc/want-commit (2011-09-15) 1 commit
- Allow git merge ":/<pattern>"
* jc/ls-remote-short-help (2011-09-16) 1 commit
- ls-remote: a lone "-h" is asking for help
* jc/maint-bundle-too-quiet (2011-09-19) 1 commit
- Teach progress eye-candy to fetch_refs_from_bundle()
* jk/filter-branch-require-clean-work-tree (2011-09-15) 1 commit
- filter-branch: use require_clean_work_tree
* jn/gitweb-highlite-sanitise (2011-09-16) 1 commit
- gitweb: Strip non-printable characters from syntax highlighter output
* mh/check-ref-format-3 (2011-09-16) 22 commits
- add_ref(): verify that the refname is formatted correctly
- resolve_ref(): expand documentation
- resolve_ref(): also treat a too-long SHA1 as invalid
- resolve_ref(): emit warnings for improperly-formatted references
- resolve_ref(): verify that the input refname has the right format
- remote: avoid passing NULL to read_ref()
- remote: use xstrdup() instead of strdup()
- resolve_ref(): do not follow incorrectly-formatted symbolic refs
- resolve_ref(): extract a function get_packed_ref()
- resolve_ref(): turn buffer into a proper string as soon as possible
- resolve_ref(): only follow a symlink that contains a valid, normalized refname
- resolve_ref(): use prefixcmp()
- resolve_ref(): explicitly fail if a symlink is not readable
- Change check_refname_format() to reject unnormalized refnames
- Inline function refname_format_print()
- Make collapse_slashes() allocate memory for its result
- Do not allow ".lock" at the end of any refname component
- Refactor check_refname_format()
- Change check_ref_format() to take a flags argument
- Change bad_ref_char() to return a boolean value
- git check-ref-format: add options --allow-onelevel and --refspec-pattern
- t1402: add some more tests
* cn/eradicate-working-copy (2011-09-21) 2 commits
- patch-id.c: use strbuf instead of a fixed buffer
- Remove 'working copy' from the documentation and C code
* js/bisect-no-checkout (2011-09-21) 1 commit
(merged to 'next' on 2011-09-21 at e94ad3e)
+ bisect: fix exiting when checkout failed in bisect_start()
* mg/maint-doc-sparse-checkout (2011-09-21) 3 commits
(merged to 'next' on 2011-09-21 at f316dec)
+ git-read-tree.txt: correct sparse-checkout and skip-worktree description
+ git-read-tree.txt: language and typography fixes
+ unpack-trees: print "Aborting" to stderr
* ms/patch-id-with-overlong-line (2011-09-21) 1 commit
- patch-id.c: use strbuf instead of a fixed buffer
* sn/doc-update-index-assume-unchanged (2011-09-21) 1 commit
(merged to 'next' on 2011-09-21 at 325e796)
+ Documentation/git-update-index: refer to 'ls-files'
* jc/request-pull-show-head-4 (2011-09-21) 7 commits
- request-pull: use the branch description
- request-pull: state what commit to expect
- request-pull: modernize style
- branch: teach --edit-description option
- format-patch: use branch description in cover letter
- branch: add read_branch_desc() helper function
- Merge branch 'bk/ancestry-path' into jc/branch-desc
(this branch uses bk/ancestry-path.)
--------------------------------------------------
[Graduated to "master"]
* ph/format-patch-no-color (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 20283e8)
+ format-patch: ignore ui.color
A fix for the recent regression.
--------------------------------------------------
[Stalled]
* jc/signed-push (2011-09-12) 7 commits
- push -s: support pre-receive-signature hook
- push -s: receiving end
- push -s: send signed push certificate
- push -s: skeleton
- Split GPG interface into its own helper library
- rename "match_refs()" to "match_push_refs()"
- send-pack: typofix error message
(this branch uses jc/run-receive-hook-cleanup; is tangled with jc/signed-push-3.)
This was the v2 that updated notes tree on the receiving end.
* jc/signed-push-3 (2011-09-12) 4 commits
. push -s: signed push
- Split GPG interface into its own helper library
- rename "match_refs()" to "match_push_refs()"
- send-pack: typofix error message
(this branch uses jc/run-receive-hook-cleanup; is tangled with jc/signed-push.)
This is the third edition, that moves the preparation of the notes tree to
the sending end.
* jk/add-i-hunk-filter (2011-07-27) 5 commits
(merged to 'next' on 2011-08-11 at 8ff9a56)
+ add--interactive: add option to autosplit hunks
+ add--interactive: allow negatation of hunk filters
+ add--interactive: allow hunk filtering on command line
+ add--interactive: factor out regex error handling
+ add--interactive: refactor patch mode argument processing
Will be dropped.
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
* jk/generation-numbers (2011-09-11) 8 commits
- metadata-cache.c: make two functions static
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
Perhaps 281eee4 (revision: keep track of the end-user input from the
command line, 2011-08-25) in bk/ancestry-path would help.
* po/cygwin-backslash (2011-08-05) 2 commits
- On Cygwin support both UNIX and DOS style path-names
- git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
Incomplete with respect to backslash processing in prefix_filename(), and
also loses the ability to escape glob specials. Perhaps drop?
--------------------------------------------------
[Cooking]
* jm/mergetool-pathspec (2011-09-16) 2 commits
- mergetool: no longer need to save standard input
- mergetool: Use args as pathspec to unmerged files
* nd/maint-autofix-tag-in-head (2011-09-18) 4 commits
- Accept tags in HEAD or MERGE_HEAD
- merge: remove global variable head[]
- merge: use return value of resolve_ref() to determine if HEAD is invalid
- merge: keep stash[] a local variable
* jk/maint-fetch-submodule-check-fix (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 3c73b8c)
+ fetch: avoid quadratic loop checking for updated submodules
(this branch is used by jk/argv-array.)
This probably can wait, as long as the other half of the regression fix
is in the upcoming release.
* bc/attr-ignore-case (2011-09-14) 5 commits
- attr: read core.attributesfile from git_default_core_config
- attr.c: respect core.ignorecase when matching attribute patterns
- builtin/mv.c: plug miniscule memory leak
- cleanup: use internal memory allocation wrapper functions everywhere
- attr.c: avoid inappropriate access to strbuf "buf" member
* jc/maint-fsck-fwrite-size-check (2011-09-11) 1 commit
(merged to 'next' on 2011-09-16 at 2258f11)
+ fsck: do not abort upon finding an empty blob
* jk/argv-array (2011-09-14) 7 commits
(merged to 'next' on 2011-09-16 at 90feab4)
+ run_hook: use argv_array API
+ checkout: use argv_array API
+ bisect: use argv_array API
+ quote: provide sq_dequote_to_argv_array
+ refactor argv_array into generic code
+ quote.h: fix bogus comment
+ add sha1_array API docs
(this branch uses jk/maint-fetch-submodule-check-fix.)
* js/cred-macos-x-keychain-2 (2011-09-14) 1 commit
- contrib: add a pair of credential helpers for Mac OS X's keychain
(this branch is tangled with jk/http-auth-keyring.)
Welcome addition to build our confidence in the jk/http-auth-keyring topic.
* rj/maint-t9159-svn-rev-notation (2011-09-21) 1 commit
- t9159-*.sh: skip for mergeinfo test for svn <= 1.4
* tr/doc-note-rewrite (2011-09-13) 1 commit
(merged to 'next' on 2011-09-16 at 5fe813a)
+ Documentation: basic configuration of notes.rewriteRef
Updated to a safer wording.
* jk/default-attr (2011-09-12) 1 commit
- attr: map builtin userdiff drivers to well-known extensions
Will be re-rolled after 1.7.7 final.
* hl/iso8601-more-zone-formats (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 270f5c7)
+ date.c: Support iso8601 timezone formats
* jc/run-receive-hook-cleanup (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 68dd431)
+ refactor run_receive_hook()
(this branch is used by jc/signed-push and jc/signed-push-3.)
Just to make it easier to run a hook that reads from its standard input.
* jk/for-each-ref (2011-09-08) 5 commits
(merged to 'next' on 2011-09-14 at 36ed515)
+ for-each-ref: add split message parts to %(contents:*).
+ for-each-ref: handle multiline subjects like --pretty
+ for-each-ref: refactor subject and body placeholder parsing
+ t6300: add more body-parsing tests
+ t7004: factor out gpg setup
* wh/normalize-alt-odb-path (2011-09-07) 1 commit
(merged to 'next' on 2011-09-14 at 96f722b)
+ sha1_file: normalize alt_odb path before comparing and storing
* fk/use-kwset-pickaxe-grep-f (2011-09-11) 2 commits
(merged to 'next' on 2011-09-14 at 436d858)
+ obstack.c: Fix some sparse warnings
+ sparse: Fix an "Using plain integer as NULL pointer" warning
In general we would prefer to see these fixed at the upstream first, but
we have essentially forked from them at their last GPLv2 versions...
* jc/make-static (2011-09-14) 4 commits
(merged to 'next' on 2011-09-14 at c5943ff)
+ exec_cmd.c: prepare_git_cmd() is sometimes used
+ environment.c: have_git_dir() has users on Cygwin
(merged to 'next' on 2011-09-11 at 2acb0af)
+ vcs-svn: remove unused functions and make some static
+ make-static: master
(this branch is tangled with jc/reflog-walk-use-only-nsha1.)
With a few fix-ups; probably needs to be ejected after 1.7.7 happens.
* rj/quietly-create-dep-dir (2011-09-11) 1 commit
(merged to 'next' on 2011-09-12 at 93d1c6b)
+ Makefile: Make dependency directory creation less noisy
* mz/remote-rename (2011-09-11) 4 commits
- remote: only update remote-tracking branch if updating refspec
- remote rename: warn when refspec was not updated
- remote: "rename o foo" should not rename ref "origin/bar"
- remote: write correct fetch spec when renaming remote 'remote'
* cb/common-prefix-unification (2011-09-12) 3 commits
(merged to 'next' on 2011-09-14 at 24f571f)
+ rename pathspec_prefix() to common_prefix() and move to dir.[ch]
+ consolidate pathspec_prefix and common_prefix
+ remove prefix argument from pathspec_prefix
* cb/send-email-help (2011-09-12) 1 commit
(merged to 'next' on 2011-09-14 at ae71999)
+ send-email: add option -h
A separate set of patches to remove the hidden fully-spelled "help" from
other commands would be nice to have as companion patches as well.
* jc/fetch-pack-fsck-objects (2011-09-04) 3 commits
(merged to 'next' on 2011-09-12 at a031347)
+ test: fetch/receive with fsckobjects
+ transfer.fsckobjects: unify fetch/receive.fsckobjects
+ fetch.fsckobjects: verify downloaded objects
We had an option to verify the sent objects before accepting a push but
lacked the corresponding option when fetching. In the light of the recent
k.org incident, a change like this would be a good addition.
* jc/fetch-verify (2011-09-01) 3 commits
(merged to 'next' on 2011-09-12 at 3f491ab)
+ fetch: verify we have everything we need before updating our ref
+ rev-list --verify-object
+ list-objects: pass callback data to show_objects()
(this branch uses jc/traverse-commit-list; is tangled with jc/receive-verify.)
During a fetch, we verify that the pack stream is self consistent,
but did not verify that the refs that are updated are consistent with
objects contained in the packstream, and this adds such a check.
* jc/receive-verify (2011-09-09) 6 commits
(merged to 'next' on 2011-09-12 at 856de78)
+ receive-pack: check connectivity before concluding "git push"
+ check_everything_connected(): libify
+ check_everything_connected(): refactor to use an iterator
+ fetch: verify we have everything we need before updating our ref
+ rev-list --verify-object
+ list-objects: pass callback data to show_objects()
(this branch uses jc/traverse-commit-list; is tangled with jc/fetch-verify.)
While accepting a push, we verify that the pack stream is self consistent,
but did not verify that the refs the push updates are consistent with
objects contained in the packstream, and this adds such a check.
* jn/maint-http-error-message (2011-09-06) 2 commits
(merged to 'next' on 2011-09-12 at a843f03)
+ http: avoid empty error messages for some curl errors
+ http: remove extra newline in error message
* bk/ancestry-path (2011-09-15) 4 commits
(merged to 'next' on 2011-09-15 at aa64d04)
+ t6019: avoid refname collision on case-insensitive systems
(merged to 'next' on 2011-09-02 at d05ba5d)
+ revision: do not include sibling history in --ancestry-path output
+ revision: keep track of the end-user input from the command line
+ rev-list: Demonstrate breakage with --ancestry-path --all
(this branch is used by jc/request-pull-show-head-4.)
* mg/branch-list (2011-09-13) 7 commits
(merged to 'next' on 2011-09-14 at 6610a2e)
+ t3200: clean up checks for file existence
(merged to 'next' on 2011-09-11 at 20a9cdb)
+ branch: -v does not automatically imply --list
(merged to 'next' on 2011-09-02 at b818eae)
+ branch: allow pattern arguments
+ branch: introduce --list option
+ git-branch: introduce missing long forms for the options
+ git-tag: introduce long forms for the options
+ t6040: test branch -vv
* mm/rebase-i-exec-edit (2011-08-26) 2 commits
(merged to 'next' on 2011-09-02 at e75b1b9)
+ rebase -i: notice and warn if "exec $cmd" modifies the index or the working tree
+ rebase -i: clean error message for --continue after failed exec
* hv/submodule-merge-search (2011-08-26) 5 commits
- submodule: Search for merges only at end of recursive merge
- allow multiple calls to submodule merge search for the same path
- submodule: Demonstrate known breakage during recursive merge
- push: Don't push a repository with unpushed submodules
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
(this branch is tangled with fg/submodule-auto-push.)
The second from the bottom one needs to be replaced with a properly
written commit log message.
* mm/mediawiki-as-a-remote (2011-09-01) 2 commits
(merged to 'next' on 2011-09-12 at 163c6a5)
+ git-remote-mediawiki: allow push to set MediaWiki metadata
+ Add a remote helper to interact with mediawiki (fetch & push)
Fun.
* bc/unstash-clean-crufts (2011-08-27) 4 commits
(merged to 'next' on 2011-09-02 at 7bfd66f)
+ git-stash: remove untracked/ignored directories when stashed
+ t/t3905: add missing '&&' linkage
+ git-stash.sh: fix typo in error message
+ t/t3905: use the name 'actual' for test output, swap arguments to test_cmp
* da/make-auto-header-dependencies (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at e04a4af)
+ Makefile: Improve compiler header dependency check
(this branch uses fk/make-auto-header-dependencies.)
* gb/am-hg-patch (2011-08-29) 1 commit
(merged to 'next' on 2011-09-02 at 3edfe4c)
+ am: preliminary support for hg patches
* jc/diff-index-unpack (2011-08-29) 3 commits
(merged to 'next' on 2011-09-02 at 4206bd9)
+ diff-index: pass pathspec down to unpack-trees machinery
+ unpack-trees: allow pruning with pathspec
+ traverse_trees(): allow pruning with pathspec
* nm/grep-object-sha1-lock (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at 336f57d)
+ grep: Fix race condition in delta_base_cache
* tr/mergetool-valgrind (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at f5f2c61)
+ Symlink mergetools scriptlets into valgrind wrappers
* fg/submodule-auto-push (2011-09-11) 2 commits
(merged to 'next' on 2011-09-11 at 3fc86f7)
+ submodule.c: make two functions static
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
(this branch is tangled with hv/submodule-merge-search.)
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* jc/traverse-commit-list (2011-08-22) 3 commits
(merged to 'next' on 2011-08-24 at df50dd7)
+ revision.c: update show_object_with_name() without using malloc()
+ revision.c: add show_object_with_name() helper function
+ rev-list: fix finish_object() call
(this branch is used by jc/fetch-verify and jc/receive-verify.)
* fk/make-auto-header-dependencies (2011-08-18) 1 commit
(merged to 'next' on 2011-08-24 at 3da2c25)
+ Makefile: Use computed header dependencies if the compiler supports it
(this branch is used by da/make-auto-header-dependencies.)
* mh/iterate-refs (2011-09-11) 7 commits
- refs.c: make create_cached_refs() static
- Retain caches of submodule refs
- Store the submodule name in struct cached_refs
- Allocate cached_refs objects dynamically
- Change the signature of read_packed_refs()
- Access reference caches only through new function get_cached_refs()
- Extract a function clear_cached_refs()
I did not see anything fundamentally wrong with this series, but it was
unclear what the benefit of these changes are. If the series were to read
parts of the ref hierarchy (like refs/heads/) lazily, the story would
have been different, though.
* hv/submodule-update-none (2011-08-11) 2 commits
(merged to 'next' on 2011-08-24 at 5302fc1)
+ add update 'none' flag to disable update of submodule by default
+ submodule: move update configuration variable further up
* jc/lookup-object-hash (2011-08-11) 6 commits
(merged to 'next' on 2011-08-24 at 5825411)
+ object hash: replace linear probing with 4-way cuckoo hashing
+ object hash: we know the table size is a power of two
+ object hash: next_size() helper for readability
+ pack-objects --count-only
+ object.c: remove duplicated code for object hashing
+ object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload. Will keep it in 'next' at least for one cycle.
* fg/submodule-git-file-git-dir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-23 at 762194e)
+ Move git-dir for submodules
+ rev-parse: add option --resolve-git-dir <path>
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage outweighs any benefit for having this new
feature. Will keep it in 'next' at least for one cycle.
* jk/http-auth-keyring (2011-09-16) 21 commits
(merged to 'next' on 2011-09-16 at b4195eb)
+ check_expirations: don't copy over same element
+ t0300: add missing EOF terminator for <<
(merged to 'next' on 2011-09-14 at 589c7c9)
+ credential-store: use a better storage format
+ t0300: make alternate username tests more robust
+ t0300: make askpass tests a little more robust
+ credential-cache: fix expiration calculation corner cases
+ docs: minor tweaks to credentials API
(merged to 'next' on 2011-09-11 at 491ce6a)
+ credentials: make credential_fill_gently() static
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
(this branch is tangled with js/cred-macos-x-keychain and js/cred-macos-x-keychain-2.)
* rr/revert-cherry-pick-continue (2011-09-11) 19 commits
(merged to 'next' on 2011-09-11 at 7d78054)
+ builtin/revert.c: make commit_list_append() static
(merged to 'next' on 2011-08-24 at 712c115)
+ revert: Propagate errors upwards from do_pick_commit
+ revert: Introduce --continue to continue the operation
+ revert: Don't implicitly stomp pending sequencer operation
+ revert: Remove sequencer state when no commits are pending
+ reset: Make reset remove the sequencer state
+ revert: Introduce --reset to remove sequencer state
+ revert: Make pick_commits functionally act on a commit list
+ revert: Save command-line options for continuing operation
+ revert: Save data for continuing after conflict resolution
+ revert: Don't create invalid replay_opts in parse_args
+ revert: Separate cmdline parsing from functional code
+ revert: Introduce struct to keep command-line options
+ revert: Eliminate global "commit" variable
+ revert: Rename no_replay to record_origin
+ revert: Don't check lone argument in get_encoding
+ revert: Simplify and inline add_message_to_msg
+ config: Introduce functions to write non-standard file
+ advice: Introduce error_resolve_conflict
--------------------------------------------------
[Discarded]
* mh/check-ref-format (2011-09-11) 8 commits
. Add tools to avoid the use of unnormalized refnames.
. Do not allow ".lock" at the end of any refname component
. Add a library function normalize_refname()
. Change check_ref_format() to take a flags argument
. fixup asciidoc formatting
. git check-ref-format: add options --allow-onelevel and --refspec-pattern
. Change bad_ref_char() to return a boolean value
. t1402: add some more tests
Rerolled
* jk/pager-with-alias (2011-08-19) 1 commit
. support pager.* for aliases
* cb/maint-quiet-push (2011-09-05) 4 commits
. t5541: avoid TAP test miscounting
. push: old receive-pack does not understand --quiet
. fix push --quiet via http
. tests for push --quiet
Dropped for rerolling after 1.7.7 cycle.
* js/cred-macos-x-keychain (2011-09-11) 15 commits
(merged to 'next' on 2011-09-12 at 8d17f94)
+ contrib: add a credential helper for Mac OS X's keychain
(merged to 'next' on 2011-09-11 at 491ce6a)
+ credentials: make credential_fill_gently() static
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
(this branch is tangled with jk/http-auth-keyring and js/cred-macos-x-keychain-2.)
Reverted out of 'next'.
* jc/reflog-walk-use-only-nsha1 (2011-09-13) 4 commits
. (baloon) teach reflog-walk to look at only new-sha1 field
+ environment.c: have_git_dir() has users on Cygwin
(merged to 'next' on 2011-09-11 at 2acb0af)
+ vcs-svn: remove unused functions and make some static
+ make-static: master
(this branch is tangled with jc/make-static.)
* hw/maint-abspath-cwd-limit (2011-09-21) 3 commits
(merged to 'next' on 2011-09-21 at 210cf9a)
+ Revert 622fea4 (abspath.c: increase array size of cwd variable)
(merged to 'next' on 2011-09-19 at 7d5e921)
+ abspath.c: increase array size of cwd variable to PATH_MAX
+ path.c: increase array size of cwd variable to PATH_MAX
Reverted out of 'next'.
* jc/request-pull-show-head (2011-09-13) 2 commits
(merged to 'next' on 2011-09-13 at c82fb3a)
+ Revert "State what commit to expect in request-pull"
(merged to 'next' on 2011-09-12 at c1c7b73)
+ State what commit to expect in request-pull
Reverted out of 'next'.
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Junio C Hamano @ 2011-09-22 4:28 UTC (permalink / raw)
To: Michael Witten; +Cc: Andrew Ardill, Anatol Pomozov, git, computerdruid
In-Reply-To: <CAMOZ1BtPJ_Ddxo1UG2cxJMnGv9y8sR0rAyk3d_5JEz4kLsUQJQ@mail.gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> On Thu, Sep 22, 2011 at 03:13, Andrew Ardill <andrew.ardill@gmail.com> wrote:
>>
>> Maybe:
>>
>> Note that if this option is specified, then only tags
>> are fetched. No other refs, such as a remote tracking
>> branch, will be updated, even if it has been updated
>> on the remote end.
>>
>> extra info on how this option is merely a short-hand for writing the
>> refspec `refs/tags/*:refs/tags/* could go here
>
> Junio just explained why your description is inadequate and confusing.
> ...
> If I were a newbie and were to read the text that I just proferred as
> a clarification of --tags, then I would next look up just WTF a
> refspec is, and then a branch, and then...
I do agree with you that it is a futile exercise to sweep fundamental
concepts under the rug, fearing that they are too detailed and too hard
for the casual readers. By understanding how simple the fundamental
concepts and rules are, readers can have a coherent and clear mental model
of the world and synthesize these fundamental rules to understand more
complex operations the Porcelain commands offer to help every day tasks.
I however do not think, and I certainly did not mean, that the description
of "--tags" option is necessarily the place we should bombard a new user
with the term refspec and "refs/tags/*:refs/tags/*" syntax.
I expect the readers to, and I hope the documentation to help them to,
understand the following three basic facts and rules before diving into
descriptions of individual options, such as the paragraph we are
discussing:
* "git fetch" command serves two purposes:
(1) It transfers objects the repository the command is invoked in does
not have from the remote repository. The objects transferred are the
commits that are necessary to complete the ancestry chain of _some_
history, and data (i.e. trees and blobs) associated to use these
commits.
(2) It optionally can update the local refs (e.g. branches and tags)
with copies of the refs taken from the remote repository.
* In the above, the user needs to tell the command two things. One is
"where the remote repository is". The other is "what refs to fetch and
(optionally) how to store them". The latter "what to fetch" also
determines what that "_some_ history" above is (i.e. everything
reachable from the refs that are fetched).
* "What to fetch and how to store" have a default, recorded in the
repository configuration file, that is used when the user does not give
that information to the command from the command line. If the user does
give that information from the command line, that default is not used
at all. IOW, the command line overrides the default.
With that understanding, the _only_ thing that "--tags" description needs
to talk about is that it is an explicit way to give that "what to fetch
and how to store" information from the command line. It instructs the
command to fetch all the tags from the remote repository and store them
locally.
If the logic flow of the document presents the list of options before
helping the readers understand the above basic facts and rules, then I
think _that_ is the problem with the document we need to be addressing,
not the description of an individual option such as "--tags".
^ permalink raw reply
* [PATCH v2] Docs: Clarify the --tags option of `git fetch'
From: Michael Witten @ 2011-09-22 4:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Anatol Pomozov, Drew Northup, Andrew Ardill, Daniel Johnson, git
In-Reply-To: <7vsjnpz0ng.fsf@alter.siamese.dyndns.org>
On Wed, 21 Sep 2011 21:00:51 -0700, Junio C Hamano wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> That is,
>>
>> git fetch origin frotz --tags
>>
>> is equivalent to:
>>
>> git fetch origin frotz 'refs/tags/*:refs/tags/*'
>
> No matter what you do, please do not introduce a bad example that violates
> the usual command line syntax convention to have subcommand (e.g. fetch),
> options meant for the subcommand (e.g. --tags) and then other arguments.
Too bad; I think it really supplements the description well.
In any case:
* The example has been changed as per your wish.
* `short-hand' has been changed to `shorthand'.
* Trailing whitespace has been removed from a line.
8<-----------8<-----------8<-----------8<-----------8<-----------8<-----------
See the discussion starting here:
[PATCH] Clarify that '--tags' fetches tags only
Message-ID: <1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com>
http://thread.gmane.org/gmane.comp.version-control.git/180636
Suggested-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
Documentation/fetch-options.txt | 21 ++++++++++++++++++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 39d326a..da594bd 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -61,9 +61,24 @@ ifndef::git-pull[]
objects reachable from the branch heads that are being
tracked will not be fetched by this mechanism. This
flag lets all tags and their associated objects be
- downloaded. The default behavior for a remote may be
- specified with the remote.<name>.tagopt setting. See
- linkgit:git-config[1].
+ downloaded.
++
+This option is merely a shorthand for writing the
+refspec `refs/tags/\*:refs/tags/\*'; consequently,
+using this option overrides any default refspec that
+would be used if no refspec were provided on the
+command line. That is,
++
+ git fetch origin --tags
+ git fetch origin --tags frotz
++
+are equivalent to:
++
+ git fetch origin 'refs/tags/*:refs/tags/*'
+ git fetch origin 'refs/tags/*:refs/tags/*' frotz
++
+The default behavior for a remote may be specified with
+the remote.<name>.tagopt setting. See linkgit:git-config[1].
--recurse-submodules[=yes|on-demand|no]::
This option controls if and under what conditions new commits of
--
1.7.6.409.ge7a85
^ permalink raw reply related
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Junio C Hamano @ 2011-09-22 4:00 UTC (permalink / raw)
To: Michael Witten; +Cc: Anatol Pomozov, git, computerdruid
In-Reply-To: <CAMOZ1Bvxc+vcofb_KyeLS7Gy=KOtX1SKv72cXA2NtwgYCWA31A@mail.gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> That is,
>
> git fetch origin frotz --tags
>
> is equivalent to:
>
> git fetch origin frotz 'refs/tags/*:refs/tags/*'
No matter what you do, please do not introduce a bad example that violates
the usual command line syntax convention to have subcommand (e.g. fetch),
options meant for the subcommand (e.g. --tags) and then other arguments.
^ permalink raw reply
* Re: [PATCH] Docs: Clarify the --tags option of `git fetch'
From: Michael Witten @ 2011-09-22 3:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Anatol Pomozov, Drew Northup, Andrew Ardill, Daniel Johnson, git
In-Reply-To: <58d5d7abced4468ea7587a8aeddfb5ed-mfwitten@gmail.com>
On Thu, Sep 22, 2011 at 03:39, Michael Witten <mfwitten@gmail.com> wrote:
> ...
> +This option is merely a short-hand for writing the
> ...
Junio, make that `shorthand', if you please.
^ permalink raw reply
* [PATCH] Docs: Clarify the --tags option of `git fetch'
From: Michael Witten @ 2011-09-22 3:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Anatol Pomozov, Drew Northup, Andrew Ardill, Daniel Johnson, git
In-Reply-To: <CAMOZ1BtPJ_Ddxo1UG2cxJMnGv9y8sR0rAyk3d_5JEz4kLsUQJQ@mail.gmail.com>
See the discussion starting here:
[PATCH] Clarify that '--tags' fetches tags only
Message-ID: <1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com>
http://thread.gmane.org/gmane.comp.version-control.git/180636
Suggested-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
Documentation/fetch-options.txt | 21 ++++++++++++++++++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 39d326a..fb743fa 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -61,9 +61,24 @@ ifndef::git-pull[]
objects reachable from the branch heads that are being
tracked will not be fetched by this mechanism. This
flag lets all tags and their associated objects be
- downloaded. The default behavior for a remote may be
- specified with the remote.<name>.tagopt setting. See
- linkgit:git-config[1].
+ downloaded.
++
+This option is merely a short-hand for writing the
+refspec `refs/tags/\*:refs/tags/\*'; consequently,
+using this option overrides any default refspec that
+would be used if no refspec were provided on the
+command line. That is,
++
+ git fetch origin --tags
+ git fetch origin frotz --tags bar
++
+are equivalent to:
++
+ git fetch origin 'refs/tags/*:refs/tags/*'
+ git fetch origin frotz 'refs/tags/*:refs/tags/*' bar
++
+The default behavior for a remote may be specified with
+the remote.<name>.tagopt setting. See linkgit:git-config[1].
--recurse-submodules[=yes|on-demand|no]::
This option controls if and under what conditions new commits of
--
1.7.6.409.ge7a85
^ permalink raw reply related
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Michael Witten @ 2011-09-22 3:24 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Junio C Hamano, Anatol Pomozov, git, computerdruid
In-Reply-To: <CAH5451nb=DTed2kAVNQmFBbGFJ9zvQAtBE+VCzKqZfGMgYpx5w@mail.gmail.com>
On Thu, Sep 22, 2011 at 03:13, Andrew Ardill <andrew.ardill@gmail.com> wrote:
> On 22 September 2011 12:07, Michael Witten <mfwitten@gmail.com> wrote:
>> On Thu, Sep 22, 2011 at 02:01, Michael Witten <mfwitten@gmail.com> wrote:
>>> On Thu, Sep 22, 2011 at 00:49, Junio C Hamano <gitster@pobox.com> wrote:
>>>> --tags is merely a short-hand for "refs/tags/*:refs/tags/*")
>>>> explicitly from the command line
>>>
>>> [Disclaimer: I don't know the code or the semantics]
>>>
>>> Why not just use that explanation?
>>>
>>> This option is merely a short-hand for writing
>>> the refspec `refs/tags/*:refs/tags/*'; consequently,
>>> using this option overrides any default refspec that
>>> would be used if no refspec were provided on the
>>> command line. That is,
>>>
>>> git fetch --tags origin frotz
>>>
>>> is equivalent to:
>>>
>>> git fetch origin frotz 'refs/tags/*:refs/tags/*'
>>>
>>> In fact, if the command line parsing performed by `git fetch'
>>> is reasonably intelligent, then it might be worthwhile
>>> to relocate `--tags' in the example:
>>>
>>> That is,
>>>
>>> git fetch origin frotz --tags
>>>
>>> is equivalent to:
>>>
>>> git fetch origin frotz 'refs/tags/*:refs/tags/*'
>>>
>>
>> Maybe this is less confusing for the example:
>>
>> That is,
>>
>> git fetch origin --tags
>> git fetch origin frotz --tags bar
>>
>> are equivalent to:
>>
>> git fetch origin 'refs/tags/*:refs/tags/*'
>> git fetch origin frotz 'refs/tags/*:refs/tags/*' bar
>
> This will only help people who understand that tags are just refs
> stored in refs/tags, and who understand the 'ref:ref' syntax. I think
> it is a good example to have, but people can understand the process
> and results of 'pulling/fetching a tag' without necessarily needing to
> know that tags are stored somewhere, or knowing the exact fetch
> mechanism. If these need to be documented, it should be in the
> appropriate place (which I don't think is here).
>
> I think we are skirting around the real issue, and that is that
> pulling tags will often grab objects that are *meant* to be on a
> remote branch (from the user's perspective) but that appear to be
> hanging because the remote branch ref was not updated at the same
> time. Perhaps an example or explanation of why this is the case would
> be more useful?
>
> Maybe:
>
> Note that if this option is specified, then only tags
> are fetched. No other refs, such as a remote tracking
> branch, will be updated, even if it has been updated
> on the remote end.
>
> extra info on how this option is merely a short-hand for writing the
> refspec `refs/tags/*:refs/tags/* could go here
Junio just explained why your description is inadequate and confusing.
There's so much confusion around git exactly because people are always
trying to hide just WTF is going on (especially by using TERRIBLE
terms like `branch'; see my numerous discussions).
If I were a newbie and were to read the text that I just proferred as
a clarification of --tags, then I would next look up just WTF a
refspec is, and then a branch, and then...
You see? That's exactly how it should work. People should be given
descriptions that arm them with the terms necessary to look up more
information. We need to stop writing documentation for that
hypothetical idiot who doesn't know his ass from his own face. We need
to cater to those people who intend to read documentation for the
purpose of understanding the system---not for the purpose of gettin'
shit dun with any half-baked notion that is good enough for the most
simplistic situation.
I'm sending in a patch presently.
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Andrew Ardill @ 2011-09-22 3:13 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Anatol Pomozov, git, computerdruid
In-Reply-To: <CAMOZ1Bt6gGVd6QuRZduZ4mJ=eoZ9d7xK-WfwZ3G-+oswT0RN_Q@mail.gmail.com>
On 22 September 2011 12:07, Michael Witten <mfwitten@gmail.com> wrote:
> On Thu, Sep 22, 2011 at 02:01, Michael Witten <mfwitten@gmail.com> wrote:
>> On Thu, Sep 22, 2011 at 00:49, Junio C Hamano <gitster@pobox.com> wrote:
>>> --tags is merely a short-hand for "refs/tags/*:refs/tags/*")
>>> explicitly from the command line
>>
>> [Disclaimer: I don't know the code or the semantics]
>>
>> Why not just use that explanation?
>>
>> This option is merely a short-hand for writing
>> the refspec `refs/tags/*:refs/tags/*'; consequently,
>> using this option overrides any default refspec that
>> would be used if no refspec were provided on the
>> command line. That is,
>>
>> git fetch --tags origin frotz
>>
>> is equivalent to:
>>
>> git fetch origin frotz 'refs/tags/*:refs/tags/*'
>>
>> In fact, if the command line parsing performed by `git fetch'
>> is reasonably intelligent, then it might be worthwhile
>> to relocate `--tags' in the example:
>>
>> That is,
>>
>> git fetch origin frotz --tags
>>
>> is equivalent to:
>>
>> git fetch origin frotz 'refs/tags/*:refs/tags/*'
>>
>
> Maybe this is less confusing for the example:
>
> That is,
>
> git fetch origin --tags
> git fetch origin frotz --tags bar
>
> are equivalent to:
>
> git fetch origin 'refs/tags/*:refs/tags/*'
> git fetch origin frotz 'refs/tags/*:refs/tags/*' bar
This will only help people who understand that tags are just refs
stored in refs/tags, and who understand the 'ref:ref' syntax. I think
it is a good example to have, but people can understand the process
and results of 'pulling/fetching a tag' without necessarily needing to
know that tags are stored somewhere, or knowing the exact fetch
mechanism. If these need to be documented, it should be in the
appropriate place (which I don't think is here).
I think we are skirting around the real issue, and that is that
pulling tags will often grab objects that are *meant* to be on a
remote branch (from the user's perspective) but that appear to be
hanging because the remote branch ref was not updated at the same
time. Perhaps an example or explanation of why this is the case would
be more useful?
Maybe:
Note that if this option is specified, then only tags
are fetched. No other refs, such as a remote tracking
branch, will be updated, even if it has been updated
on the remote end.
extra info on how this option is merely a short-hand for writing the
refspec `refs/tags/*:refs/tags/* could go here
Regards,
Andrew
^ permalink raw reply
* [PATCH v3] Configurable hyperlinking in gitk
From: Jeff Epler @ 2011-09-22 2:15 UTC (permalink / raw)
To: git; +Cc: Marc Branchaud, Chris Packham, Jakub Narebski, Junio C Hamano
In-Reply-To: <20110922013101.GB26880@unpythonic.net>
Many projects use project-specific notations in changelogs to refer
to bug trackers and the like. One example is the "Closes: #12345"
notation used in Debian.
Make gitk configurable so that arbitrary strings can be turned into
clickable links that are opened in a web browser.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
---
Since the previous patch, I
* Renamed configuration variables to get rid of the "gitk" prefix
to encourage other git-related programs to adopt the same
functionality.
* Renamed configuration variables from cryptic ".re", ".sub" to less
cryptic ".regexp" and "subst"
* Changed the example RE to be an ERE (no \d or \M)
* Documented that these are POSIX EREs; hopefully that's OK. I see
in CodingGuidelines that in git itself "a subset of BREs" are used,
so maybe even this is too much power. And hopefully tcl's
re_syntax really is close enough to an ERE superset that this isn't
a terrible lie about the initial implementation either.
* Added a Signed-Off-By, since I've had a number of positive feedbacks
and the only problems I've heard of (since patch v2) are the ones
related to 'eval' in git-web--browse.
In v2 of the patch, I had fixed a problem with %-signs in URLs and
changed the documentation example.
Documentation/config.txt | 30 +++++++++++++++++-
gitk-git/gitk | 75 +++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 102 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ae9913b..ffc9ccf 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1064,6 +1064,10 @@ All gitcvs variables except for 'gitcvs.usecrlfattr' and
is one of "ext" and "pserver") to make them apply only for the given
access method.
+gitk.browser::
+ Specify the browser that will be used to open links generated by
+ 'linkify' configuration options.
+
grep.lineNumber::
If set to true, enable '-n' option by default.
@@ -1317,6 +1321,28 @@ interactive.singlekey::
setting is silently ignored if portable keystroke input
is not available.
+linkify.<name>.regexp::
+ Specify a regular expression in the POSIX Extended Regular Expression
+ syntax defining a class of strings to automatically convert to
+ hyperlinks. This regular expression many not span multiple lines.
+ You must also specify 'linkify.<name>.subst'.
+
+linkify.<name>.subst::
+ Specify a substitution that results in the target URL for the
+ related regular expression. Back-references like '\1' refer
+ to capturing groups in the associated regular expression.
+ You must also specify 'linkify.<name>.regexp'.
++
+For example, to automatically link from Debian-style "Closes: #nnnn"
+message to the Debian BTS,
++
+--------
+ git config linkify.debian-bts.regexp '#([1-9][0-9]*)'
+ git config linkify.debian-bts.subst 'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=\1'
+--------
++
+Currently, only linkgit:gitk[1] converts strings to links in this fashion.
+
log.abbrevCommit::
If true, makes linkgit:git-log[1], linkgit:git-show[1], and
linkgit:git-whatchanged[1] assume `\--abbrev-commit`. You may
@@ -1870,5 +1896,5 @@ user.signingkey::
web.browser::
Specify a web browser that may be used by some commands.
- Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
- may use it.
+ Currently only linkgit:git-instaweb[1], linkgit:gitk[1],
+ and linkgit:git-help[1] may use it.
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 4cde0c4..9db5525 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -6684,7 +6684,7 @@ proc commit_descriptor {p} {
# append some text to the ctext widget, and make any SHA1 ID
# that we know about be a clickable link.
proc appendwithlinks {text tags} {
- global ctext linknum curview
+ global ctext linknum curview linkmakers
set start [$ctext index "end - 1c"]
$ctext insert end $text $tags
@@ -6699,6 +6699,30 @@ proc appendwithlinks {text tags} {
setlink $linkid link$linknum
incr linknum
}
+
+ if {$linkmakers == {}} return
+
+ set link_re {}
+ foreach {re rep} $linkmakers { lappend link_re $re }
+ set link_re "([join $link_re {)|(}])"
+
+ set ee 0
+ while {[regexp -indices -start $ee -- $link_re $text l]} {
+ set s [lindex $l 0]
+ set e [lindex $l 1]
+ set linktext [string range $text $s $e]
+ incr e
+ set ee $e
+
+ foreach {re rep} $linkmakers {
+ if {![regsub $re $linktext $rep linkurl]} continue
+ $ctext tag delete link$linknum
+ $ctext tag add link$linknum "$start + $s c" "$start + $e c"
+ seturllink $linkurl link$linknum
+ incr linknum
+ break
+ }
+ }
}
proc setlink {id lk} {
@@ -6726,6 +6750,53 @@ proc setlink {id lk} {
}
}
+proc get_link_config {} {
+ if {[catch {exec git config -z --get-regexp {^linkify\.}} linkers]} {
+ return {}
+ }
+
+ set linktypes [list]
+ foreach item [split $linkers "\0"] {
+ if {$item == ""} continue
+ if {![regexp {linkify\.(\S+)\.(regexp|subst)\s(.*)} $item _ k t v]} {
+ continue
+ }
+ set linkconfig($t,$k) $v
+ if {$t == "regexp"} { lappend linktypes $k }
+ }
+
+ set linkmakers [list]
+ foreach k $linktypes {
+ if {![info exists linkconfig(subst,$k)]} {
+ puts stderr "Warning: link `$k' is missing a substitution string"
+ } elseif {[catch {regexp -inline -- $linkconfig(regexp,$k) ""} err]} {
+ puts stderr "Warning: link `$k': $err"
+ } else {
+ lappend linkmakers $linkconfig(regexp,$k) $linkconfig(subst,$k)
+ }
+ unset linkconfig(regexp,$k)
+ unset -nocomplain linkconfig(subst,$k)
+ }
+ foreach k [array names linkconfig] {
+ regexp "subst,(.*)" $k _ k
+ puts stderr "Warning: link `$k' is missing a regular expression"
+ }
+ set linkmakers
+}
+
+proc openlink {url} {
+ exec git web--browse --config=gitk.browser $url &
+}
+
+proc seturllink {url lk} {
+ set qurl [string map {% %%} $url]
+ global ctext
+ $ctext tag conf $lk -foreground blue -underline 1
+ $ctext tag bind $lk <1> [list openlink $qurl]
+ $ctext tag bind $lk <Enter> {linkcursor %W 1}
+ $ctext tag bind $lk <Leave> {linkcursor %W -1}
+}
+
proc appendshortlink {id {pre {}} {post {}}} {
global ctext linknum
@@ -11693,6 +11764,8 @@ if {[tk windowingsystem] eq "win32"} {
focus -force .
}
+set linkmakers [get_link_config]
+
getcommits {}
# Local variables:
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH] abspath: increase array size of cwd variable to PATH_MAX
From: wanghui @ 2011-09-22 2:09 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, git
In-Reply-To: <4E791A40.6040102@ramsay1.demon.co.uk>
Ramsay Jones wrote:
> Junio C Hamano wrote:
>
>> Wang Hui <Hui.Wang@windriver.com> writes:
>>
>>
>>> diff --git a/abspath.c b/abspath.c
>>> index f04ac18..2ce1db9 100644
>>> --- a/abspath.c
>>> +++ b/abspath.c
>>> @@ -24,7 +24,7 @@ int is_directory(const char *path)
>>> const char *real_path(const char *path)
>>> {
>>> static char bufs[2][PATH_MAX + 1], *buf = bufs[0], *next_buf = bufs[1];
>>> - char cwd[1024] = "";
>>> + char cwd[PATH_MAX] = "";
>>>
>> Thanks.
>>
>> This does not make things worse but in the longer term we should move away
>> from using PATH_MAX in general.
>>
>
> Hmm, the subject line says "... increase array size ...", but that is not
> necessarily what this patch is doing! :-D
>
> Yes, on some platforms PATH_MAX will be larger than 1024 (e.g. 4096 on Linux),
> but that is not even true of all POSIX systems. POSIX defines the *minimum*
> value of PATH_MAX that systems must support (as #define _POSIX_PATH_MAX) of 255.
> [it also requires that POSIX conforming applications must not *require* a value
> larger than 255].
>
> However, we don't have to look too far to find systems with much smaller values.
> On Cygwin, for example:
>
> $ cat -n junk.c
> 1 #include <stdio.h>
> 2 #include <limits.h>
> 3
> 4 int main(int argc, char *argv[])
> 5 {
> 6 printf("PATH_MAX is %d\n", PATH_MAX);
> 7 return 0;
> 8 }
> $ gcc -o junk junk.c
> $ ./junk
> $ PATH_MAX is 260
> $
>
> On MinGW the answer is 259.
>
> So, I certainly agree that moving away from PATH_MAX is a good idea, but I'm
> not sure I agree that this patch "does not make things worse" ... (I haven't
> given it *any* thought!).
>
Hi Ramsay,
Do you mean the PATH_MAX of a system should not be the limitation for
the git. That is to say, the git can handle the path which has name
longer than PATH_MAX? If it is, my patch is not needed here. :-)
> [Also, note commits f66cf96, fd55a19, 620e2bb, etc...]
>
> ATB,
> Ramsay Jones
>
>
>
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Michael Witten @ 2011-09-22 2:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anatol Pomozov, git, computerdruid
In-Reply-To: <CAMOZ1Bvxc+vcofb_KyeLS7Gy=KOtX1SKv72cXA2NtwgYCWA31A@mail.gmail.com>
On Thu, Sep 22, 2011 at 02:01, Michael Witten <mfwitten@gmail.com> wrote:
> On Thu, Sep 22, 2011 at 00:49, Junio C Hamano <gitster@pobox.com> wrote:
>> --tags is merely a short-hand for "refs/tags/*:refs/tags/*")
>> explicitly from the command line
>
> [Disclaimer: I don't know the code or the semantics]
>
> Why not just use that explanation?
>
> This option is merely a short-hand for writing
> the refspec `refs/tags/*:refs/tags/*'; consequently,
> using this option overrides any default refspec that
> would be used if no refspec were provided on the
> command line. That is,
>
> git fetch --tags origin frotz
>
> is equivalent to:
>
> git fetch origin frotz 'refs/tags/*:refs/tags/*'
>
> In fact, if the command line parsing performed by `git fetch'
> is reasonably intelligent, then it might be worthwhile
> to relocate `--tags' in the example:
>
> That is,
>
> git fetch origin frotz --tags
>
> is equivalent to:
>
> git fetch origin frotz 'refs/tags/*:refs/tags/*'
>
Maybe this is less confusing for the example:
That is,
git fetch origin --tags
git fetch origin frotz --tags bar
are equivalent to:
git fetch origin 'refs/tags/*:refs/tags/*'
git fetch origin frotz 'refs/tags/*:refs/tags/*' bar
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Michael Witten @ 2011-09-22 2:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anatol Pomozov, git, computerdruid
In-Reply-To: <7vwrd1z9it.fsf@alter.siamese.dyndns.org>
On Thu, Sep 22, 2011 at 00:49, Junio C Hamano <gitster@pobox.com> wrote:
> --tags is merely a short-hand for "refs/tags/*:refs/tags/*")
> explicitly from the command line
[Disclaimer: I don't know the code or the semantics]
Why not just use that explanation?
This option is merely a short-hand for writing
the refspec `refs/tags/*:refs/tags/*'; consequently,
using this option overrides any default refspec that
would be used if no refspec were provided on the
command line. That is,
git fetch --tags origin frotz
is equivalent to:
git fetch origin frotz 'refs/tags/*:refs/tags/*'
In fact, if the command line parsing performed by `git fetch'
is reasonably intelligent, then it might be worthwhile
to relocate `--tags' in the example:
That is,
git fetch origin frotz --tags
is equivalent to:
git fetch origin frotz 'refs/tags/*:refs/tags/*'
^ permalink raw reply
* Re: [RFC/PATCH] Configurable hyperlinking in gitk
From: Jeff Epler @ 2011-09-22 1:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Chris Packham, git
In-Reply-To: <m3hb49sn26.fsf@localhost.localdomain>
On Sun, Sep 18, 2011 at 11:50:30AM -0700, Jakub Narebski wrote:
> Perhaps more descriptive name, i.e.
>
> linkify.<name>.regexp
> linkify.<name>.subst
>
> would be better?
>
> I guess that regexp is an extended regular expression, isn't it?
If "regexp" is clearer than "re" then I have no quarrel with changing
it. The typical user won't be typing these over and over, so the value
of brevity is limited.
As written, it's whatever is accepted by tcl's regular expression
matcher, which is described in re_syntax(n), installed as
re_syntax(3tcl) on debian-derived systems. A one-sentence summary of a
TCL "ARE" is "basically EREs with some significant extensions".
It is probably possible to write expressions that are going to work the
same in tcl, perl, and posix regular expressions, but to some extent the
user who writes a complex expression and then tries to use it with both
gitk and a future gitweb will simply be permitted to keep both pieces
when it breaks.
Is it unnecessarily complicated to design
linkify.<name>.(regexp|subst)
*AND*
gitk.linkify.<name>.(regexp|subst)
in from the start? This way the hypothetical power user can write a
different version of the expression for gitk and future gitweb if it is
required by RE dialect differences.
Jeff
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Daniel Johnson @ 2011-09-22 1:14 UTC (permalink / raw)
To: Anatol Pomozov; +Cc: git, gitster
In-Reply-To: <1316649176-32352-1-git-send-email-anatol.pomozov@gmail.com>
On Wednesday, September 21, 2011 04:52:56 PM Anatol Pomozov wrote:
> @@ -63,7 +63,8 @@ ifndef::git-pull[]
> flag lets all tags and their associated objects be
> downloaded. The default behavior for a remote may be
> specified with the remote.<name>.tagopt setting. See
> - linkgit:git-config[1].
> + linkgit:git-config[1]. Note that if this option is specified
> + then only tags are fetched, refs under refs/heads/* stay unchanged.
I like this clarification. It would be better placed before the note about the
tagopt setting, as it clarifies the statement before that ("This flag lets all
tags and their associated objects be downloaded.")
In fact, the optimal solution might be to rework that sentence with the
clarification from yours, so something like "This flag lets all tags and their
associated objects be downloaded instead of"...
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Junio C Hamano @ 2011-09-22 0:49 UTC (permalink / raw)
To: Michael Witten; +Cc: Anatol Pomozov, git, computerdruid
In-Reply-To: <CAMOZ1BuSd52woX0utOQ84gbCzBkZg3ATKnE+7G_BrD5_hUQSiQ@mail.gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> On Wed, Sep 21, 2011 at 23:52, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
>> + linkgit:git-config[1]. Note that if this option is specified
>> + then only tags are fetched, refs under refs/heads/* stay unchanged.
>
> Note that if this option is specified, then only tags
> are fetched; refs under refs/heads/* are not changed.
Can we improve the wording without singling out refs/heads/* specifically?
I think the updated wording is not desirable for two reasons.
For one thing, for the most newbies, I think refs/remotes/origin/* (not
refs/heads/*) would be the hierarchy that they may expect to get updated
and surprised.
When you give --tags (or any other refspec for that matter; --tags is
merely a short-hand for "refs/tags/*:refs/tags/*") explicitly from the
command line, you are overriding the refspecs configured for the remote,
and all the refs that are _not_ covered by the refspec you gave from the
command line will stay unchanged, not just refs/heads/* but refs under
other hierarchies (like refs/remotes/* and refs/notes/*).
Once the reader understands that the command line _overrides_ the
configured fetch refspecs, everything else should fall naturally into
place without further explanation. For example,
$ git pull origin frotz
would internally invoke "git fetch origin another_branch", and it would
not update any refs for the _same exact reason_ [*1*]. You are giving a
refspec from the command line (in this case, "grab refs/heads/frotz, but
do not store it anywhere"), and it overrides the usual fetch refspec that
may update "+refs/heads/*:refs/remotes/origin/*" (grab all refs at the
origin under refs/heads/ hierarchy, and store in refs/remotes/origin).
[Footnote]
*1* The merging of the result would update the current branch but that is
a natural consequence of "a pull integrates by running either a merge or a
rebase after running a fetch".
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Michael Witten @ 2011-09-22 0:13 UTC (permalink / raw)
To: Anatol Pomozov; +Cc: git, gitster, computerdruid
In-Reply-To: <1316649176-32352-1-git-send-email-anatol.pomozov@gmail.com>
On Wed, Sep 21, 2011 at 23:52, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
> + linkgit:git-config[1]. Note that if this option is specified
> + then only tags are fetched, refs under refs/heads/* stay unchanged.
Note that if this option is specified, then only tags
are fetched; refs under refs/heads/* are not changed.
^ 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