* Re: Fwd: possible Improving diff algoritm
From: Morten Welinder @ 2012-12-13 1:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kevin, git
In-Reply-To: <7vpq2f2az4.fsf@alter.siamese.dyndns.org>
>> Is there a reason why picking among the choices in a sliding window
>> must be contents neutral?
>
> Sorry, you might be getting at something interesting but I do not
> understand the question. I have no idea what you mean by "contents
> neutral".
I was merely asking if an algorithm to pick between the
2+ choices was allowed to look at the contents of the
lines.
I.e., an algorithm would look at the C comment
example and determine that the choice starting containing
a full inserted comment is preferable over the one that
appears to close one comment and open a new.
And the in inserted-function case it would prefer the one
where the matching { and } are in correct order.
Morten
^ permalink raw reply
* Re: [PATCH v2] index-format.txt: be more liberal on what can represent invalid cache tree
From: Junio C Hamano @ 2012-12-13 1:55 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1355361287-10875-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> How would that work with existing versions? If you write -2 in
> cache-tree, the next time 1.8.0 updates cache tree it writes -1 back.
> That loses whatever information you attach to -2. A new cache-tree
> extension is probably better.
You can easily imagine a definition like this:
- If non-negative, the entry is valid and it is the number of index
entries that are covered by this subtree;
- If -1, the cached-tree does not know the object name of the tree
object, and nothing else is known. The caller needs to walk the
index to skip the entries that could have been covered by this
subtree, if the cached tree information were valid;
- If less than -1, the cached-tree does not know the object name of
the tree object, but we know the number of index entries that are
covered by this subtree. The caller, instead of walking the index,
can subtract the count from -1 and skip that many entries to find
the index entry after the part that is inside this directory.
Newer Git may write -201 and newer Git may be able to take advantage
of the new information encoded there, saving 200 calls to
prefixcmp(), while given the same index, older Git will operate just
as correctly as before. An older Git may write that part of the
cache-tree back with -1, defeating the optimization when a newer Git
reads it back, but by definition the older Git does not know what to
write to help that optimization that did not exist when it was done,
and writing -1 will not confuse the newer Git.
^ permalink raw reply
* [PATCH v3 2/2] cache-tree: remove dead i-t-a code in verify_cache()
From: Nguyễn Thái Ngọc Duy @ 2012-12-13 1:39 UTC (permalink / raw)
To: git
Cc: Jeff King, Junio C Hamano, Jonathon Mah,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1355362747-13474-1-git-send-email-pclouds@gmail.com>
This code is added in 331fcb5 (git add --intent-to-add: do not let an
empty blob be committed by accident - 2008-11-28) to forbid committing
when i-t-a entries are present. When we allow that, we forgot to
remove this unreachable code.
Noticed-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
cache-tree.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/cache-tree.c b/cache-tree.c
index 1fbc81a..3e79e27 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -166,12 +166,8 @@ static int verify_cache(struct cache_entry **cache,
fprintf(stderr, "...\n");
break;
}
- if (ce_stage(ce))
- fprintf(stderr, "%s: unmerged (%s)\n",
- ce->name, sha1_to_hex(ce->sha1));
- else
- fprintf(stderr, "%s: not added yet\n",
- ce->name);
+ fprintf(stderr, "%s: unmerged (%s)\n",
+ ce->name, sha1_to_hex(ce->sha1));
}
}
if (funny)
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCH v3 1/2] cache-tree: invalidate i-t-a paths after generating trees
From: Nguyễn Thái Ngọc Duy @ 2012-12-13 1:39 UTC (permalink / raw)
To: git
Cc: Jeff King, Junio C Hamano, Jonathon Mah,
Nguyễn Thái Ngọc Duy
In-Reply-To: <7vip89bz4v.fsf@alter.siamese.dyndns.org>
Intent-to-add entries used to forbid writing trees so it was not a
problem. After commit 3f6d56d (commit: ignore intent-to-add entries
instead of refusing - 2012-02-07), we can generate trees from an index
with i-t-a entries.
However, the commit forgets to invalidate all paths leading to i-t-a
entries. With fully valid cache-tree (e.g. after commit or
write-tree), diff operations may prefer cache-tree to index and not
see i-t-a entries in the index, because cache-tree does not have them.
Reported-by: Jonathon Mah <me@JonathonMah.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
This version ensures that entry_count can only be >= -1 after
update_one returns. Not ideal but good enough.
cache-tree.c | 40 ++++++++++++++++++++++++++++++++++++----
t/t2203-add-intent.sh | 20 ++++++++++++++++++++
2 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/cache-tree.c b/cache-tree.c
index 28ed657..1fbc81a 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -248,6 +248,7 @@ static int update_one(struct cache_tree *it,
int missing_ok = flags & WRITE_TREE_MISSING_OK;
int dryrun = flags & WRITE_TREE_DRY_RUN;
int i;
+ int to_invalidate = 0;
if (0 <= it->entry_count && has_sha1_file(it->sha1))
return it->entry_count;
@@ -324,7 +325,14 @@ static int update_one(struct cache_tree *it,
if (!sub)
die("cache-tree.c: '%.*s' in '%s' not found",
entlen, path + baselen, path);
- i += sub->cache_tree->entry_count - 1;
+ i--; /* this entry is already counted in "sub" */
+ if (sub->cache_tree->entry_count < 0) {
+ i -= sub->cache_tree->entry_count;
+ sub->cache_tree->entry_count = -1;
+ to_invalidate = 1;
+ }
+ else
+ i += sub->cache_tree->entry_count;
sha1 = sub->cache_tree->sha1;
mode = S_IFDIR;
}
@@ -339,8 +347,23 @@ static int update_one(struct cache_tree *it,
mode, sha1_to_hex(sha1), entlen+baselen, path);
}
- if (ce->ce_flags & (CE_REMOVE | CE_INTENT_TO_ADD))
- continue; /* entry being removed or placeholder */
+ /*
+ * CE_REMOVE entries are removed before the index is
+ * written to disk. Skip them to remain consistent
+ * with the future on-disk index.
+ */
+ if (ce->ce_flags & CE_REMOVE)
+ continue;
+
+ /*
+ * CE_INTENT_TO_ADD entries exist on on-disk index but
+ * they are not part of generated trees. Invalidate up
+ * to root to force cache-tree users to read elsewhere.
+ */
+ if (ce->ce_flags & CE_INTENT_TO_ADD) {
+ to_invalidate = 1;
+ continue;
+ }
strbuf_grow(&buffer, entlen + 100);
strbuf_addf(&buffer, "%o %.*s%c", mode, entlen, path + baselen, '\0');
@@ -360,7 +383,7 @@ static int update_one(struct cache_tree *it,
}
strbuf_release(&buffer);
- it->entry_count = i;
+ it->entry_count = to_invalidate ? -i : i;
#if DEBUG
fprintf(stderr, "cache-tree update-one (%d ent, %d subtree) %s\n",
it->entry_count, it->subtree_nr,
@@ -381,6 +404,15 @@ int cache_tree_update(struct cache_tree *it,
i = update_one(it, cache, entries, "", 0, flags);
if (i < 0)
return i;
+ /*
+ * update_one() uses negative entry_count as a way to mark an
+ * entry invalid _and_ pass the number of entries back to
+ * itself at the parent level. This is for internal use and
+ * should not be leaked out after the top-level update_one
+ * exits.
+ */
+ if (it->entry_count < 0)
+ it->entry_count = -1;
return 0;
}
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index ec35409..2a4a749 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -62,5 +62,25 @@ test_expect_success 'can "commit -a" with an i-t-a entry' '
git commit -a -m all
'
+test_expect_success 'cache-tree invalidates i-t-a paths' '
+ git reset --hard &&
+ mkdir dir &&
+ : >dir/foo &&
+ git add dir/foo &&
+ git commit -m foo &&
+
+ : >dir/bar &&
+ git add -N dir/bar &&
+ git diff --cached --name-only >actual &&
+ echo dir/bar >expect &&
+ test_cmp expect actual &&
+
+ git write-tree >/dev/null &&
+
+ git diff --cached --name-only >actual &&
+ echo dir/bar >expect &&
+ test_cmp expect actual
+'
+
test_done
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCH v2] index-format.txt: be more liberal on what can represent invalid cache tree
From: Nguyễn Thái Ngọc Duy @ 2012-12-13 1:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <7v4njr5eac.fsf@alter.siamese.dyndns.org>
We have been writing -1 as "invalid" since day 1. On that same day we
accept all negative entry counts as "invalid". So in theory all C Git
versions out there would be happy to accept any negative numbers. JGit
seems to do exactly the same.
Correct the document to reflect the fact that -1 is not the only magic
number. At least one implementation, libgit2, is found to treat -1
this way.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
On Thu, Dec 13, 2012 at 1:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> We have been writing -1 as "invalid" since day 1. On that same day we
>> accept all negative entry counts as "invalid". So in theory all C Git
>> versions out there would be happy to accept any negative numbers. JGit
>> seems to do exactly the same.
>
> I am of two minds here.
>
> The existing code is being more lenient than specified when they
> read stuff others wrote, but it still adheres to -1 when writing.
> Allowing random implementations to write random negative values will
> close the door for us to later update the specification to encode
> more informatin about these invalid entries by using negative value
> other than -1 here.
How would that work with existing versions? If you write -2 in
cache-tree, the next time 1.8.0 updates cache tree it writes -1 back.
That loses whatever information you attach to -2. A new cache-tree
extension is probably better.
> I am OK with a reword to say "negative means invalid, and writers
> should write -1 for invalid entries", but without the latter half,
> this change is not justified.
Done.
Documentation/technical/index-format.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt
index 9d25b30..ce28a7a 100644
--- a/Documentation/technical/index-format.txt
+++ b/Documentation/technical/index-format.txt
@@ -161,8 +161,9 @@ GIT index format
this span of index as a tree.
An entry can be in an invalidated state and is represented by having
- -1 in the entry_count field. In this case, there is no object name
- and the next entry starts immediately after the newline.
+ a negative number in the entry_count field. In this case, there is no
+ object name and the next entry starts immediately after the newline.
+ When writing an invalid entry, -1 should always be used as entry_count.
The entries are written out in the top-down, depth-first order. The
first entry represents the root level of the repository, followed by the
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* Re: [PATCH v2] submodule: add 'deinit' command
From: W. Trevor King @ 2012-12-13 0:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jens Lehmann, Michael J Gruber, Phil Hord, Git, Heiko Voigt,
Jeff King, Shawn Pearce, Nahor
In-Reply-To: <7vsj7a268w.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
On Wed, Dec 12, 2012 at 03:35:59PM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
>
> > Should `deinit` remove the submodule checkout, replace it with the
> > original gitlink, and clear the .git/config information then? That
> > would restore the user to the state they'd be in if they were never
> > interested in the submodule.
>
> AFAIU, "restore the user to the state" is the goal. I am not sure
> what you meant by "replace it with the original gitlink", though. A
> checkout with a submodule that the user is not interested in would
> have an empty directory at that path, no?
Ah yes, the gitlink is only in the index. Sorry for the noise.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: directory permissions on AFS
From: Junio C Hamano @ 2012-12-13 0:17 UTC (permalink / raw)
To: Jaime Frey; +Cc: git
In-Reply-To: <0A6FA42F-986D-4C3C-BC50-9A7C0494C703@cs.wisc.edu>
Jaime Frey <jfrey@cs.wisc.edu> writes:
> Stracing git revealed that it successfully recreated the ./objects/fb
> and then failed to chmod() it. It failed because it tried to set the
> S_ISGID bit, which mere mortals cannot do on AFS. Manually recreating
> all of these directories solves the problem.
We fix directory permissions after creating any directory under .git
with the same code, so that in a repository shared by group, new
subdirectories created by a random somebody who belongs to that
group will belong to that group (we also chmod to g+wx in case such
a random somebody has overly strict umask). Instead of running
chown(2) on every new file created by us, we let the filesystem to
take care of it by telling the directories we create that new files
in them should inherit their group ownership.
What we were worried about back when we decided to use S_ISGID was a
scenario like this:
* A repository is shared by group "src".
* A user belongs to the group "src". That group may or may not be
his primary group (i.e. "mkdir foo" done at random place by him
may not belong to the "src" group).
* The user attempts to create a new branch "foo/bar" by pushing
from outside. There is no other branch whose name is
"foo/anything" when this happens.
* An equivalent of "mkdir -p .git/refs/heads/foo" needs to be done
before an equivalent of "echo $sha >.git/refs/heads/foo/bar"
happens to accept this push. We want "foo" and "bar" to belong
to "src" group and they get appropriate permission bits suitable
to be accessed by the members of the "src" group.
The story is the same for loose objects and their fan-out directory.
Storing a commit object fb/012345... may need to create the leading
fan-out ".git/objects/fb" and we want that directory and any future
files created in it to belong to the "src" group.
Any alternative implementation that achieves the same result that
works on AFS can be substituted with the current code, or made
conditionally activated on AFS.
^ permalink raw reply
* Re: Fwd: possible Improving diff algoritm
From: Michael Haggerty @ 2012-12-13 0:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Morten Welinder, Kevin, git
In-Reply-To: <7vpq2f2az4.fsf@alter.siamese.dyndns.org>
On 12/12/2012 10:53 PM, Junio C Hamano wrote:
> Morten Welinder <mwelinder@gmail.com> writes:
>
>> Is there a reason why picking among the choices in a sliding window
>> must be contents neutral?
>
> Sorry, you might be getting at something interesting but I do not
> understand the question. I have no idea what you mean by "contents
> neutral".
>
> Picking between these two choices
>
> /** + /**
> + * Default parent + * Default parent
> + * + *
> + * @var int + * @var int
> + * @access protected + * @access protected
> + * @index + * @index
> + */ + */
> + protected $defaultParent; + protected $defaultParent;
> + +
> + /** /**
>
> would not affect the correctness of the patch. You may pick
> whatever you deem the most desirable, but your answer must be a
> correct patch (the definition of "correct" here is "applying that
> patch to the preimage produces the intended postimage").
>
> And I think if you inserted a block of text B after a context C
> where the tail of B matches the tail of C like the above, you can
> shift what you treat as "inserted" up and still come up with a
> correct patch.
I have the feeling that a few crude heuristics would go a long way
towards improving diffs like this. For example:
* Prefer to have an add/remove block that has balanced begin/end pairs
(where begin/end pairs might be opening and closing parentheses,
brackets, braces, and angle brackets, "/*" and "*/", and perhaps a
couple of other things. For SGML-like text begin and end tags could be
matched up.
It would be possible to read these begin/end pairs from a
filetype-specific table or configuration setting, though this would add
complication and would also make it possible that diffs generated by two
different people are not identical if their configurations differ.
* Prefer to have a block where the first non-blank line of the block and
the first non-blank line after the block are indented by the same amount.
* Prefer to have a block with trailing (as opposed to leading or
embedded) blank lines--the more the better.
The beautiful thing is that even if the heuristics sometimes fail, the
correctness of the patch (in the sense that you have defined) is not
compromised.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* What's cooking in git.git (Dec 2012, #03; Wed, 12)
From: Junio C Hamano @ 2012-12-12 23:58 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
A new maintenance release 1.8.0.2 was tagged with accumulated fixes
we have already been using on the 'master' front for a while. The
tip of the 'master' is a bit beyond 1.8.1-rc1 and many topics are
getting into good shape in 'next', hopefully ready to be merged soon
after the 1.8.1 final.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* sp/shortlog-missing-lf (2012-12-11) 2 commits
(merged to 'next' on 2012-12-11 at 64b8429)
+ strbuf_add_wrapped*(): Remove unused return value
+ shortlog: fix wrapping lines of wraplen
When a line to be wrapped has a solid run of non space characters
whose length exactly is the wrap width, "git shortlog -w" failed to
add a newline after such a line.
Will cook in 'next'.
* ap/log-mailmap (2012-12-11) 6 commits
- [DO NOT MERGE] seems to break t4013 & t4014 among other things
- log: Add --use-mailmap option
- pretty: Use mailmap to display username and email
- mailmap: Add mailmap structure to rev_info and pp
- mailmap: Remove buffer length limit in map_user
- Use split_ident_line to parse author and committer
Clean up various codepaths around mailmap and teach the "log"
machinery to use it.
* jc/fetch-ignore-symref (2012-12-11) 1 commit
- fetch: ignore wildcarded refspecs that update local symbolic refs
Avoid false error from an attempt to update local symbolic ref via
fetch.
* md/gitweb-sort-by-age (2012-12-11) 1 commit
- gitweb: Sort projects with undefined ages last
Will merge to 'next'.
* ss/nedmalloc-compilation (2012-12-11) 1 commit
- nedmalloc: Fix a compile warning (exposed as error) with GCC 4.7.2
Will merge to 'next'.
* wk/submodule-update-remote (2012-12-12) 3 commits
- submodule add: If --branch is given, record it in .gitmodules
- submodule update: add --remote for submodule's upstream changes
- submodule: add get_submodule_config helper funtion
Expecting a re-roll.
--------------------------------------------------
[Graduated to "master"]
* ef/mingw-rmdir (2012-12-10) 1 commit
+ mingw_rmdir: do not prompt for retry when non-empty
MinGW has a workaround when rmdir unnecessarily fails to retry with
a prompt, but the logic was kicking in when the rmdir failed with
ENOTEMPTY, i.e. was expected to fail and there is no point retrying.
* ef/mingw-tty-getpass (2012-12-04) 6 commits
(merged to 'next' on 2012-12-07 at 1737ff1)
+ mingw: get rid of getpass implementation
+ mingw: reuse tty-version of git_terminal_prompt
+ compat/terminal: separate input and output handles
+ compat/terminal: factor out echo-disabling
+ mingw: make fgetc raise SIGINT if apropriate
+ mingw: correct exit-code for SIGALRM's SIG_DFL
Update getpass() emulation for MinGW.
* jc/prompt-command-doc (2012-12-11) 1 commit
- git-prompt.sh: update PROMPT_COMMAND documentation
Recently graduated git-prompt topic to use PROMPT_COMMAND was
confusingly documented. With a quick review, it may be a good
idea to fast-track this to the 'master branch.
--------------------------------------------------
[Stalled]
* fc/remote-bzr (2012-11-28) 10 commits
- (fixup) test-bzr.sh: fix multi-line string assignment
- remote-bzr: detect local repositories
- remote-bzr: add support for older versions of bzr
- remote-bzr: add support to push special modes
- remote-bzr: add support for fecthing special modes
- remote-bzr: add simple tests
- remote-bzr: update working tree
- remote-bzr: add support for remote repositories
- remote-bzr: add support for pushing
- Add new remote-bzr transport helper
New remote helper for bzr (v3). With minor fixes, this may be ready
for 'next'.
* mo/cvs-server-updates (2012-12-09) 18 commits
- t9402: Use TABs for indentation
- t9402: Rename check.cvsCount and check.list
- t9402: Simplify git ls-tree
- t9402: Add missing &&; Code style
- t9402: No space after IO-redirection
- t9402: Dont use test_must_fail cvs
- t9402: improve check_end_tree() and check_end_full_tree()
- t9402: sed -i is not portable
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
Needs review by folks interested in cvsserver.
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
Duy helped to reroll this.
Expecting a re-roll.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Needs review and Ack (or Nack) from people involved in the remote
helper interface for this to move forward.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-11-26) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* jc/maint-fbsd-sh-ifs-workaround (2012-12-10) 1 commit
(merged to 'next' on 2012-12-11 at 6659fdc)
+ sh-setup: work around "unset IFS" bug in some shells
Will cook in 'next'.
* jc/merge-blobs (2012-12-09) 4 commits
- merge-tree: add comments to clarify what these functions are doing
- merge-tree: lose unused "resolve_directories"
- merge-tree: lose unused "flags" from merge_list
- Which merge_file() function do you mean?
A beginning of a new merge strategy based on the disused merge-tree
proof-of-concept code.
* jc/same-encoding (2012-12-10) 1 commit
- format_commit_message(): simplify calls to logmsg_reencode()
Finishing touches to the series to unify "Do we need to reencode
between these two encodings?" logic.
* nd/invalidate-i-t-a-cache-tree (2012-12-09) 1 commit
- cache-tree: invalidate i-t-a paths after generating trees
Writing out a tree object when you still have intent-to-add entries
in the index left an incorrect cache-tree data there.
* jl/submodule-deinit (2012-12-04) 1 commit
(merged to 'next' on 2012-12-07 at ea772f0)
+ submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Will cook in 'next'.
* sl/git-svn-docs (2012-12-05) 4 commits
(merged to 'next' on 2012-12-07 at 5bfbb73)
+ git-svn: Note about tags.
+ git-svn: Expand documentation for --follow-parent
+ git-svn: Recommend use of structure options.
+ git-svn: Document branches with at-sign(@).
Will cook in 'next'.
* pf/editor-ignore-sigint (2012-12-02) 5 commits
(merged to 'next' on 2012-12-07 at 6b04419)
+ launch_editor: propagate signals from editor to git
+ run-command: do not warn about child death from terminal
+ launch_editor: ignore terminal signals while editor has control
+ launch_editor: refactor to use start/finish_command
+ run-command: drop silent_exec_failure arg from wait_or_whine
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Will cook in 'next'.
* bc/append-signed-off-by (2012-11-26) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- format-patch: stricter S-o-b detection
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- sequencer.c: remove broken support for rfc2822 continuation in footer
Expecting a re-roll after a review.
* mh/unify-xml-in-imap-send-and-http-push (2012-12-02) 8 commits
(merged to 'next' on 2012-12-03 at d677090)
+ wrap_in_html(): process message in bulk rather than line-by-line
+ wrap_in_html(): use strbuf_addstr_xml_quoted()
+ imap-send: change msg_data from storing (ptr, len) to storing strbuf
+ imap-send: correctly report errors reading from stdin
+ imap-send: store all_msgs as a strbuf
+ lf_to_crlf(): NUL-terminate msg_data::data
+ xml_entities(): use function strbuf_addstr_xml_quoted()
+ Add new function strbuf_add_xml_quoted()
Update imap-send to reuse xml quoting code from http-push codepath,
clean up some code, and fix a small bug.
Will cook in 'next'.
* jc/doc-maintainer (2012-11-27) 1 commit
- update "howto maintain git"
An early draft that is still incomplete.
* jk/fsck-dot-in-trees (2012-11-28) 2 commits
(merged to 'next' on 2012-11-28 at 519dabc)
+ fsck: warn about ".git" in trees
+ fsck: warn about '.' and '..' in trees
Will cook in 'next'.
* mh/doc-remote-helpers (2012-12-07) 6 commits
(merged to 'next' on 2012-12-07 at 7ac8c25)
+ git-remote-helpers.txt: clarify options & ref list attributes
+ git-remote-helpers.txt: clarify command <-> capability correspondences
+ git-remote-helpers.txt: rearrange description of capabilities
+ git-remote-helpers.txt: minor grammar fix
+ git-remote-helpers.txt: document missing capabilities
+ git-remote-helpers.txt: document invocation before input format
Will merge to 'master'.
* mh/pthreads-autoconf (2012-11-27) 1 commit
(merged to 'next' on 2012-11-28 at 780600e)
+ configure.ac: fix pthreads detection on Mac OS X
Will cook in 'next'.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
(merged to 'next' on 2012-11-28 at 43d51c2)
+ config: exit on error accessing any config file
+ doc: advertise GIT_CONFIG_NOSYSTEM
+ config: treat user and xdg config permission problems as errors
+ config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT.
Will cook in 'next'.
* mh/ceiling (2012-10-29) 8 commits
(merged to 'next' on 2012-11-26 at d1ce76a)
+ string_list_longest_prefix(): remove function
+ setup_git_directory_gently_1(): resolve symlinks in ceiling paths
+ longest_ancestor_length(): require prefix list entries to be normalized
+ longest_ancestor_length(): take a string_list argument for prefixes
+ longest_ancestor_length(): use string_list_split()
+ Introduce new function real_path_if_valid()
+ real_path_internal(): add comment explaining use of cwd
+ Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
Resurrected from Stalled; the earlier performance fear was
unwarranted.
Will cook in 'next'.
* fc/fast-export-fixes (2012-12-03) 15 commits
(merged to 'next' on 2012-12-03 at f9df523)
+ fast-export: make sure updated refs get updated
+ fast-export: don't handle uninteresting refs
+ fast-export: fix comparison in tests
+ fast-export: trivial cleanup
+ remote-testgit: implement the "done" feature manually
+ remote-testgit: report success after an import
+ remote-testgit: exercise more features
+ remote-testgit: cleanup tests
+ remote-testgit: remove irrelevant test
+ remote-testgit: remove non-local functionality
+ Add new simplified git-remote-testgit
+ Rename git-remote-testgit to git-remote-testpy
+ remote-helpers: fix failure message
+ remote-testgit: fix direction of marks
+ fast-export: avoid importing blob marks
Will cook in 'next'.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
(merged to 'next' on 2012-11-26 at 3af69e7)
+ apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Will cook in 'next'.
* nd/pathspec-wildcard (2012-11-26) 4 commits
(merged to 'next' on 2012-12-03 at eca0fcb)
+ tree_entry_interesting: do basedir compare on wildcard patterns when possible
+ pathspec: apply "*.c" optimization from exclude
+ pathspec: do exact comparison on the leading non-wildcard part
+ pathspec: save the non-wildcard length part
Will cook in 'next'.
* nd/wildmatch (2012-11-20) 14 commits
(merged to 'next' on 2012-11-21 at 151288f)
+ test-wildmatch: avoid Windows path mangling
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
Will cook in 'next'.
* cr/push-force-tag-update (2012-12-03) 10 commits
(merged to 'next' on 2012-12-04 at af2e3a9)
+ push: allow already-exists advice to be disabled
+ push: rename config variable for more general use
+ push: cleanup push rules comment
+ push: clarify rejection of update to non-commit-ish
+ push: require force for annotated tags
+ push: require force for refs under refs/tags/
+ push: flag updates that require force
+ push: keep track of "update" state separately
+ push: add advice for rejected tag reference
+ push: return reject reasons as a bitset
Require "-f" for push to update a tag, even if it is a fast-forward.
Will cook in 'next'.
^ permalink raw reply
* Re: Fwd: possible Improving diff algoritm
From: Javier Domingo @ 2012-12-12 23:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrew Ardill, Morten Welinder, Kevin, git
In-Reply-To: <7vobhy25wd.fsf@alter.siamese.dyndns.org>
So, how can it be fixed? or is diff command's problem?
Javier Domingo
2012/12/13 Junio C Hamano <gitster@pobox.com>:
> Javier Domingo <javierdo1@gmail.com> writes:
>
>> I must say it is _quite_ helpfull having the diffs well done (natural
>> diffs as here named), just because when you want to review a patch on
>> the fly, this sort of things are annoying.
>
> I do not think anybody is arguing that it would not help the human
> users to shift the hunk boundaries in the case Kevin's original
> message demonstrated.
>
^ permalink raw reply
* directory permissions on AFS
From: Jaime Frey @ 2012-12-12 23:39 UTC (permalink / raw)
To: git
Hi,
We have a shared bare git repository on AFS, which our developers
pull from and push to from their local repositories. Some developers
access the bare repository directly over AFS and others use ssh.
Every couple of months, all of the two-character directories under
the objects directory disappear. Afterwards, most pushes fail with an
error like this:
error: unable to create temporary sha1 filename ./objects/fb:
Permission denied
Stracing git revealed that it successfully recreated the ./objects/fb
and then failed to chmod() it. It failed because it tried to set the
S_ISGID bit, which mere mortals cannot do on AFS. Manually recreating
all of these directories solves the problem.
I took a quick look at the git source and it appears git always tries
to set the S_ISGID on a new directory if core.sharedrepository is
enabled in the config. I don't know what other effects would result
from setting core.sharedrepository to 0.
Would it be feasible to allow the setting of S_ISGID to disabled,
apart from modifying core.sharedrepository? Possibly a new config
parameter or detecting if the directory is on AFS?
-- Jaime Frey
^ permalink raw reply
* Re: Fwd: possible Improving diff algoritm
From: Junio C Hamano @ 2012-12-12 23:43 UTC (permalink / raw)
To: Javier Domingo; +Cc: Andrew Ardill, Morten Welinder, Kevin, git
In-Reply-To: <CALZVapnzYBhPU1nR=eCSnm73c9-SpHq34DHu7OWCkouCQS0FxQ@mail.gmail.com>
Javier Domingo <javierdo1@gmail.com> writes:
> I must say it is _quite_ helpfull having the diffs well done (natural
> diffs as here named), just because when you want to review a patch on
> the fly, this sort of things are annoying.
I do not think anybody is arguing that it would not help the human
users to shift the hunk boundaries in the case Kevin's original
message demonstrated.
^ permalink raw reply
* Re: [PATCH v2] submodule: add 'deinit' command
From: Junio C Hamano @ 2012-12-12 23:35 UTC (permalink / raw)
To: W. Trevor King
Cc: Jens Lehmann, Michael J Gruber, Phil Hord, Git, Heiko Voigt,
Jeff King, Shawn Pearce, Nahor
In-Reply-To: <20121212230926.GC7729@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> Should `deinit` remove the submodule checkout, replace it with the
> original gitlink, and clear the .git/config information then? That
> would restore the user to the state they'd be in if they were never
> interested in the submodule.
AFAIU, "restore the user to the state" is the goal. I am not sure
what you meant by "replace it with the original gitlink", though. A
checkout with a submodule that the user is not interested in would
have an empty directory at that path, no?
^ permalink raw reply
* Re: Fwd: possible Improving diff algoritm
From: Javier Domingo @ 2012-12-12 23:32 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Junio C Hamano, Morten Welinder, Kevin, git
In-Reply-To: <CAH5451=4dqqMnQa-R6O4ZrHOPSpHU9joWqf2UuOkbLtU9f8bkQ@mail.gmail.com>
I must say it is _quite_ helpfull having the diffs well done (natural
diffs as here named), just because when you want to review a patch on
the fly, this sort of things are annoying.
I just wanted to say my opinion. No idea on how to fix that, nor why
does it happen.
Javier Domingo
2012/12/12 Andrew Ardill <andrew.ardill@gmail.com>:
> On 13 December 2012 08:53, Junio C Hamano <gitster@pobox.com> wrote:
>> The output being "a correct patch" is not the only thing we need to
>> consider, though, as I mentioned in another response to Kevin
>> regarding the "consequences".
>
> The main benefit of picking a more 'natural' diff is a usability one.
> I know that when a chunk begins and ends one line after the logical
> break point (typically with braces in my experience) mentally parsing
> the diff becomes significantly harder. If there was a way to teach git
> where it should try and break out a chunk (potentially per filetype?)
> this is a good thing for readability, and I think would outweigh any
> temporary pain with regards to cached rerere and diff data.
>
> Regards,
>
> Andrew Ardill
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
From: Max Horn @ 2012-12-12 23:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, git
In-Reply-To: <7vwqwm27az.fsf@alter.siamese.dyndns.org>
On 13.12.2012, at 00:13, Junio C Hamano wrote:
> Max Horn <max@quendi.de> writes:
>
>> Of course I can also re-roll, if that is necessary/preferred.
>
> No, you can't. The topic has been cooking in 'next' for some days
> now already.
Ah, right, I somehow missed that :-/. Well, I guess it's at most a tiny minor cleanup anyway and thus not important :-).
Cheers,
Max
^ permalink raw reply
* Re: Weird problem with git-submodule.sh
From: Phil Hord @ 2012-12-12 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefano Lattarini, Marc Branchaud, Git Mailing List
In-Reply-To: <7vehiv3vjm.fsf@alter.siamese.dyndns.org>
On Wed, Dec 12, 2012 at 2:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Phil Hord <phil.hord@gmail.com> writes:
>> [2] https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481
>
> None of the ones listed seems to me a bug. Rather, I see it as a
> sign that the reporter does not know POSIX shell well and only
> learned his/her shell through bash.
You're probably right. I run into enough problems with 'dash' as
/bin/sh that I always have to disable it early after a new install.
In particular, an third-party embedded linux kernel build script fails
in cryptic ways with dash. But it is probably the third-party's poor
understanding of POSIX shell which is to blame.
I think git's 'make test' previously would also fail under dash, but
it seems to be happy with it atm.
Phil
^ permalink raw reply
* Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
From: Junio C Hamano @ 2012-12-12 23:13 UTC (permalink / raw)
To: Max Horn; +Cc: Felipe Contreras, git
In-Reply-To: <A0E9390A-58CE-4E3E-A1A6-2D5CDB62FE06@quendi.de>
Max Horn <max@quendi.de> writes:
> Of course I can also re-roll, if that is necessary/preferred.
No, you can't. The topic has been cooking in 'next' for some days
now already.
^ permalink raw reply
* Re: [PATCH v2] submodule: add 'deinit' command
From: W. Trevor King @ 2012-12-12 23:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jens Lehmann, Michael J Gruber, Phil Hord, Git, Heiko Voigt,
Jeff King, Shawn Pearce, Nahor
In-Reply-To: <7vlid23nnc.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
On Wed, Dec 12, 2012 at 02:34:47PM -0800, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
> > So unless people agree that deinit should also remove the work
> > tree I'll prepare some patches teaching all git commands to
> > consistently ignore deinitialized submodules. Opinions?
>
> While I agree that consistency is good, "deinit" that does not
> remove the working tree of the submodule the user explicitly said he
> no longer wants to have the checkout for is a bug, and I think these
> two are orthogonal issues.
Should `deinit` remove the submodule checkout, replace it with the
original gitlink, and clear the .git/config information then? That
would restore the user to the state they'd be in if they were never
interested in the submodule.
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [BUG] Hardcoded python and install on solaris
From: Junio C Hamano @ 2012-12-12 23:08 UTC (permalink / raw)
To: P Fudd; +Cc: git
In-Reply-To: <1870c3d3587281b436cddb33cca1e822.squirrel@www.pkts.ca>
"P Fudd" <pfudd@mailinator.com> writes:
> When compiling git-1.8.0.2 on a moderately old OpenIndiana machine, I had
> to install a few things (m4, autoconf, coreutils, xz, python).
>
> Even though I started the configuration fresh (make distclean; configure),
> the makefile still wanted to use /usr/bin/python (instead of
> /usr/local/bin/python) and /usr/usb/install (instead of
> /usr/local/bin/install).
You need to specify PYTHON_PATH on the build command line, something
like:
$ make PYTHON_PATH=/usr/local/bin/python
$ make PYTHON_PATH=/usr/local/bin/python install
We don't really rely on configure, and it sometimes is the case
where ./configure output does not know some knobs you can tweak in
the Makefile, but this one is not.
I think you can use --with-python=/usr/local/bin/python when running
the ./configure script. ./configure --help may tell you more about
what you can tweak.
^ permalink raw reply
* Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
From: Max Horn @ 2012-12-12 23:05 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano
In-Reply-To: <CAMP44s1xetknwdOT5EseuASQE_2WFP1e1-Ao2RWYeya+EJ9SfQ@mail.gmail.com>
On 13.12.2012, at 00:00, Felipe Contreras wrote:
[...]
>>>
>>> I find all this text a bit confusing. First argument, second argument,
>>> etc. Personally, I would describe everything in the terms of alias
>>> (1st arg), and URL (2nd arg).
>>
>> Yeah, I also thought about that, but as above, deliberately did not touch it here, but only moved it around. I'll be happy to revisit this on a future date, though.
>
> Oh, in that case it's fine, but I would have named it "move invocation
> before input format", or something that has *move*, or *shuffle*.
Agreed. It explicit says move in the body of the commit message, but not in the summary line.. That would be an improvement, I gueess. Junio, if you want, feel free to reword the summary line of the patch accordingly, e.g. changing it from
git-remote-helpers.txt: document invocation before input format
to something like
git-remote-helpers.txt: move 'invocation' section before 'input format'
Of course I can also re-roll, if that is necessary/preferred.
Cheers,
Max
^ permalink raw reply
* Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
From: Junio C Hamano @ 2012-12-12 23:03 UTC (permalink / raw)
To: Max Horn; +Cc: Felipe Contreras, git
In-Reply-To: <839EECE2-4459-4358-B7E8-5D64374A0540@quendi.de>
Max Horn <max@quendi.de> writes:
> Worth a thought yeah -- but beyond the scope of this patch: I
> merely moved this text around, but did not touch it otherwise.
> ...
> Yeah, I also thought about that, but as above, deliberately did
> not touch it here, but only moved it around. I'll be happy to
> revisit this on a future date, though.
That sounds like a sensible approach. So what's been cooking on
'next' is OK, it seems.
As this is merely a doc update, I may be tempted to merge it down to
the 'master' branch before the next -rc.
Thanks.
^ permalink raw reply
* Re: [PATCH v7 2/3] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-12-12 23:02 UTC (permalink / raw)
To: Phil Hord
Cc: Git, Junio C Hamano, Heiko Voigt, Jeff King, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <CABURp0oLmSjiZAOJxEzwSmL+jimpVj8DcDi-odPTzCpCcyH8yA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4633 bytes --]
On Wed, Dec 12, 2012 at 12:43:23PM -0500, Phil Hord wrote:
> On Tue, Dec 11, 2012 at 1:58 PM, W. Trevor King <wking@tremily.us> wrote:
> > diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> > …
> > +--remote::
> > [snip some --remote documentation]
> > +In order to ensure a current tracking branch state, `update --remote`
> > +fetches the submodule's remote repository before calculating the
> > +SHA-1. This makes `submodule update --remote --merge` similar to
> > +running `git pull` in the submodule. If you don't want to fetch (for
> > +something closer to `git merge`), you should use `submodule update
> > +--remote --no-fetch --merge`.
>
> I assume the same can be said for 'submodue update --remote --rebase',
> right?
Yes.
> I wonder if this can be made merge/rebase-agnostic. Is it still
> true if I word it like this?:
>
> In order to ensure a current tracking branch state, `update --remote`
> fetches the submodule's remote repository before calculating the
> SHA-1. If you don't want to fetch, you should use `submodule update
> --remote --no-fetch`.
Works for me. Will change in v8 (which I'll base on 'master').
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index f969f28..1395079 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -8,7 +8,8 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
> > USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
> > or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
> > or: $dashless [--quiet] init [--] [<path>...]
> > - or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> > + or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> > +ges
>
> I think there's an unintentionally added line here with "ges".
That is embarrassing :p. Will fix in v8.
> > + if test -n "$remote"
> > + then
> > + if test -z "$nofetch"
> > + then
> > + # Fetch remote before determining tracking $sha1
> > + (clear_local_git_env; cd "$sm_path" && git-fetch) ||
>
> You should 'git fetch $remote_name' here, and of course, initialize
> remote_name before this. But how can we know the remote_name in the
> first place? Is it safe to assume the submodule remote names will
> match those in the superproject?
The other git-fetch call from git-submodule.sh is also bare (i.e. no
specified remote). When the remote needs to be specified, other
portions of git-submodule.sh use $(get_default_remote), which is (I
think) what the user should expect. v6 of this series had a
configurable remote name, but Junio wasn't keen on the additional
configuration option. I don't really mind either way.
>
> > + die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
> > + fi
> > + remote_name=$(get_default_remote)
>
> This get_default_remote finds the remote for the remote-tracking
> branch for HEAD in the superproject. It is possible that HEAD !=
> $branch, so we have very few clues to go on here to get a more
> reasonable answer, so I do not have any good suggestions to improve
> this.
For detached HEADs, get_default_remote should fall back to 'origin',
which seems sane. If the user wants a different default, they've
likely checkout out a branch in the submodule, setup that branch's
remote, and will be using --merge or --rebase. If anyone expects
users who will be using detached heads to *want* to specify a
different remote than 'origin', that would be a good argument for
reinstating my submodule.<name>.remote patch from v6.
> > + sha1=$(clear_local_git_env; cd "$sm_path" &&
> > + git rev-parse --verify "${remote_name}/${branch}") ||
>
> This does assume the submodule remote names will match those in the
> superproject. Is this safe?
Another good catch. I should be calling get_default_remote after
cd-ing into the submodule. Will change in v8.
Thanks for the feedback :)
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
From: Felipe Contreras @ 2012-12-12 23:00 UTC (permalink / raw)
To: Max Horn; +Cc: git
In-Reply-To: <839EECE2-4459-4358-B7E8-5D64374A0540@quendi.de>
On Wed, Dec 12, 2012 at 4:58 PM, Max Horn <max@quendi.de> wrote:
>
> On 12.12.2012, at 23:14, Felipe Contreras wrote:
>
>> On Tue, Nov 27, 2012 at 5:03 PM, Max Horn <max@quendi.de> wrote:
>>
>>> index 5ce4cda..9a7e583 100644
>>> --- a/Documentation/git-remote-helpers.txt
>>> +++ b/Documentation/git-remote-helpers.txt
>>> @@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', 'git-remote-https',
>>> 'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
>>> 'fetch', 'option', and 'push'.
>>>
>>> +INVOCATION
>>> +----------
>>> +
>>> +Remote helper programs are invoked with one or (optionally) two
>>> +arguments. The first argument specifies a remote repository as in git;
>>> +it is either the name of a configured remote or a URL. The second
>>> +argument specifies a URL; it is usually of the form
>>> +'<transport>://<address>', but any arbitrary string is possible.
>>> +The 'GIT_DIR' environment variable is set up for the remote helper
>>> +and can be used to determine where to store additional data or from
>>> +which directory to invoke auxiliary git commands.
>>> +
>>> +When git encounters a URL of the form '<transport>://<address>', where
>>> +'<transport>' is a protocol that it cannot handle natively, it
>>> +automatically invokes 'git remote-<transport>' with the full URL as
>>> +the second argument. If such a URL is encountered directly on the
>>> +command line, the first argument is the same as the second, and if it
>>> +is encountered in a configured remote, the first argument is the name
>>> +of that remote.
>>
>> Maybe it's worth mentioning that if the alias of the remote is not
>> specified, the URL is used instead.
>
> Worth a thought yeah -- but beyond the scope of this patch: I merely moved this text around, but did not touch it otherwise.
>
>>
>>> +A URL of the form '<transport>::<address>' explicitly instructs git to
>>> +invoke 'git remote-<transport>' with '<address>' as the second
>>> +argument. If such a URL is encountered directly on the command line,
>>> +the first argument is '<address>', and if it is encountered in a
>>> +configured remote, the first argument is the name of that remote.
>>> +
>>> +Additionally, when a configured remote has 'remote.<name>.vcs' set to
>>> +'<transport>', git explicitly invokes 'git remote-<transport>' with
>>> +'<name>' as the first argument. If set, the second argument is
>>> +'remote.<name>.url'; otherwise, the second argument is omitted.
>>
>> I find all this text a bit confusing. First argument, second argument,
>> etc. Personally, I would describe everything in the terms of alias
>> (1st arg), and URL (2nd arg).
>
> Yeah, I also thought about that, but as above, deliberately did not touch it here, but only moved it around. I'll be happy to revisit this on a future date, though.
Oh, in that case it's fine, but I would have named it "move invocation
before input format", or something that has *move*, or *shuffle*.
--
Felipe Contreras
^ permalink raw reply
* [BUG] Hardcoded python and install on solaris
From: P Fudd @ 2012-12-12 22:34 UTC (permalink / raw)
To: git
Hi;
When compiling git-1.8.0.2 on a moderately old OpenIndiana machine, I had
to install a few things (m4, autoconf, coreutils, xz, python).
Even though I started the configuration fresh (make distclean; configure),
the makefile still wanted to use /usr/bin/python (instead of
/usr/local/bin/python) and /usr/usb/install (instead of
/usr/local/bin/install).
Thanks for a great SCM!
^ permalink raw reply
* Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
From: Max Horn @ 2012-12-12 22:58 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s3vO9b4-XxqatEc2w3KJLqLGgyjPuKpQkAXHQwTJJEQTg@mail.gmail.com>
On 12.12.2012, at 23:14, Felipe Contreras wrote:
> On Tue, Nov 27, 2012 at 5:03 PM, Max Horn <max@quendi.de> wrote:
>
>> index 5ce4cda..9a7e583 100644
>> --- a/Documentation/git-remote-helpers.txt
>> +++ b/Documentation/git-remote-helpers.txt
>> @@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', 'git-remote-https',
>> 'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
>> 'fetch', 'option', and 'push'.
>>
>> +INVOCATION
>> +----------
>> +
>> +Remote helper programs are invoked with one or (optionally) two
>> +arguments. The first argument specifies a remote repository as in git;
>> +it is either the name of a configured remote or a URL. The second
>> +argument specifies a URL; it is usually of the form
>> +'<transport>://<address>', but any arbitrary string is possible.
>> +The 'GIT_DIR' environment variable is set up for the remote helper
>> +and can be used to determine where to store additional data or from
>> +which directory to invoke auxiliary git commands.
>> +
>> +When git encounters a URL of the form '<transport>://<address>', where
>> +'<transport>' is a protocol that it cannot handle natively, it
>> +automatically invokes 'git remote-<transport>' with the full URL as
>> +the second argument. If such a URL is encountered directly on the
>> +command line, the first argument is the same as the second, and if it
>> +is encountered in a configured remote, the first argument is the name
>> +of that remote.
>
> Maybe it's worth mentioning that if the alias of the remote is not
> specified, the URL is used instead.
Worth a thought yeah -- but beyond the scope of this patch: I merely moved this text around, but did not touch it otherwise.
>
>> +A URL of the form '<transport>::<address>' explicitly instructs git to
>> +invoke 'git remote-<transport>' with '<address>' as the second
>> +argument. If such a URL is encountered directly on the command line,
>> +the first argument is '<address>', and if it is encountered in a
>> +configured remote, the first argument is the name of that remote.
>> +
>> +Additionally, when a configured remote has 'remote.<name>.vcs' set to
>> +'<transport>', git explicitly invokes 'git remote-<transport>' with
>> +'<name>' as the first argument. If set, the second argument is
>> +'remote.<name>.url'; otherwise, the second argument is omitted.
>
> I find all this text a bit confusing. First argument, second argument,
> etc. Personally, I would describe everything in the terms of alias
> (1st arg), and URL (2nd arg).
Yeah, I also thought about that, but as above, deliberately did not touch it here, but only moved it around. I'll be happy to revisit this on a future date, though.
Thanks for the feedback,
Max
^ 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