Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with spaces with TortoiseGitMerge
David Aguilar writes: > On Fri, Feb 1, 2013 at 12:16 PM, Sven Strickroth > wrote: >> TortoiseMerge caused to whole >> argument instead of just the file name to be quoted > > s/caused to whole/caused the whole/ > > I think this commit message is very nice. Is it too late to replace > the current patch with this one? Haven't merged it to 'next'; I will replace with this, with a bit of retitling to make it shorter. commit 81ed7b9581f7eafb334824264abb492d85a5ffb8 Author: Sven Strickroth Date: Fri Feb 1 21:16:30 2013 +0100 mergetools: teach tortoisemerge to handle filenames with SP correctly TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths with spaces in them by using -option "$FILE" (not -option:"$FILE", which does not work for such paths) syntax. This change was necessary because of MSYS path mangling [1], the ":" after the "base" etc. arguments to TortoiseMerge caused the whole argument instead of just the file name to be quoted in case of file names with spaces. So TortoiseMerge was passed "-base:new file.txt" instead of -base:"new file.txt" (including the quotes). To work around this, TortoiseGitMerge does not require the ":" after the arguments anymore which fixes handling file names with spaces [2] (as written above). [1] http://www.mingw.org/wiki/Posix_path_conversion [2] https://github.com/msysgit/msysgit/issues/57 Signed-off-by: Sven Strickroth Reported-by: Sebastian Schuberth Signed-off-by: Junio C Hamano -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with spaces with TortoiseGitMerge
On Fri, Feb 1, 2013 at 12:16 PM, Sven Strickroth wrote: > TortoiseMerge caused to whole > argument instead of just the file name to be quoted s/caused to whole/caused the whole/ I think this commit message is very nice. Is it too late to replace the current patch with this one? -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk-git/.gitignore: add rule for gitk-wish
Jonathan Nieder writes: > Looks like this was fixed in the week since last pull. > > http://thread.gmane.org/gmane.comp.version-control.git/214312 > > Paul, would it be safe for Junio to pull again? Thanks. I think I pulled a few days ago, and the result should have already been propagated out. commit 9a6c84e6e9078b0ef4fd2c50b200e8552a28c6fa Merge: 070c57d a8b38d9 Author: Junio C Hamano Date: Wed Jan 30 13:52:44 2013 -0800 Merge git://ozlabs.org/~paulus/gitk * git://ozlabs.org/~paulus/gitk: gitk: Ignore gitk-wish buildproduct -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH resend] Makefile: explicitly set target name for autogenerated dependencies
On Fri, Feb 01, 2013 at 02:45:19PM -0800, Jonathan Nieder wrote: > After a change in a header file, object files in a subdirectory are > not automatically rebuilt by "make": > > $ touch cache.h > $ make builtin/add.o > $ > > Luckily we can prevent trouble by explicitly supplying the name of the > target to ccache and gcc, using the -MQ option. Do so. Thanks, I missed the original thread last year, but this does look like the same problem. The fixed version of ccache is a few years old, but the OP did mention RHEL5, so that makes sense. > missing_dep_dirs := $(filter-out $(wildcard $(dep_dirs)),$(dep_dirs)) > dep_file = $(dir $@).depend/$(notdir $@).d > -dep_args = -MF $(dep_file) -MMD -MP > +dep_args = -MF $(dep_file) -MQ $@ -MMD -MP This looks like a nice simple solution. The only downside would be if -MQ is not supported by some gcc versions (in which case we would do better to improve the "can we use computed dependencies" check, and punish people on old ccache, not people on old gcc who otherwise could work without -MQ). As far as I can tell, though, -MQ came along with the other dependency generation options in 2001: http://gcc.gnu.org/news/dependencies.html which means it's not a problem to rely on. So the patch looks good to me. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Files excluded but not ignored
On 31/01/2013 3:17 AM, Junio C Hamano wrote: Jason Wenger writes: Trying to start up discussion of whether there would be merit to a "half- ignored" state -- Files which are excluded from tracking, but which still show in git status, and which are removed by git clean. I see no merit for "ignored and never to be tracked, but are still shown loudly in the untracked list" myself. Use cases for "ignored and never to be tracked, but not expendable" class were mentioned often in the past, though. A new state seems over the top. Jason, would adding a parameter to "git status" telling it to ignore all .gitignores give you what you need? Regards, Ben -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk-git/.gitignore: add rule for gitk-wish
Hi Ram, Ramkumar Ramachandra wrote: > 8f26aa4 (Makefile: remove tracking of TCLTK_PATH, 2012-12-18) removed > "/gitk-git/gitk-wish" from the toplevel .gitignore, with the intent of > moving it to gitk-git/.gitignore in a later patch. This was never > realized. > > Signed-off-by: Ramkumar Ramachandra > --- > Minor patch, so I didn't bother sending it through Paul. All gitk patches go through Paul's repo. I keep forgetting the address, so I look it up each time. $ git log -1 --oneline gitk-git/ 9a6c84e Merge git://ozlabs.org/~paulus/gitk Looks like this was fixed in the week since last pull. http://thread.gmane.org/gmane.comp.version-control.git/214312 Paul, would it be safe for Junio to pull again? Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH resend] Makefile: explicitly set target name for autogenerated dependencies
Date: Fri, 18 Nov 2011 17:23:24 -0600 "gcc -MF depfile -MMD -MP -c -o path/to/file.o" produces a makefile snippet named "depfile" describing what files are needed to build the target given by "-o". When ccache versions before v3.0pre0~187 (Fix handling of the -MD and -MDD options, 2009-11-01) run, they execute gcc -MF depfile -MMD -MP -E instead to get the final content for hashing. Notice that the "-c -o" combination is replaced by "-E". The result is a target name without a leading path. Thus when building git with such versions of ccache with COMPUTE_HEADER_DEPENDENCIES enabled, the generated makefile snippets define dependencies for the wrong target: $ make builtin/add.o GIT_VERSION = 1.7.8.rc3 * new build flags or prefix CC builtin/add.o $ head -1 builtin/.depend/add.o.d add.o: builtin/add.c cache.h git-compat-util.h compat/bswap.h strbuf.h \ After a change in a header file, object files in a subdirectory are not automatically rebuilt by "make": $ touch cache.h $ make builtin/add.o $ Luckily we can prevent trouble by explicitly supplying the name of the target to ccache and gcc, using the -MQ option. Do so. Reported-and-tested-by: Nguyễn Thái Ngọc Duy Reported-by: : 허종만 Signed-off-by: Jonathan Nieder --- Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 731b6a8..5a2e02d 100644 --- a/Makefile +++ b/Makefile @@ -973,7 +973,8 @@ endif ifeq ($(COMPUTE_HEADER_DEPENDENCIES),auto) dep_check = $(shell $(CC) $(ALL_CFLAGS) \ - -c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null 2>&1; \ + -c -MF /dev/null -MQ /dev/null -MMD -MP \ + -x c /dev/null -o /dev/null 2>&1; \ echo $$?) ifeq ($(dep_check),0) override COMPUTE_HEADER_DEPENDENCIES = yes @@ -1843,7 +1844,7 @@ $(dep_dirs): missing_dep_dirs := $(filter-out $(wildcard $(dep_dirs)),$(dep_dirs)) dep_file = $(dir $@).depend/$(notdir $@).d -dep_args = -MF $(dep_file) -MMD -MP +dep_args = -MF $(dep_file) -MQ $@ -MMD -MP ifdef CHECK_HEADER_DEPENDENCIES $(error cannot compute header dependencies outside a normal build. \ Please unset CHECK_HEADER_DEPENDENCIES and try again) -- 1.8.1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: Re: Re: Segmentation fault with latest git (070c57df)
Jongman Heo wrote: >> But it doesn't stimulate any prerequisites in make, which is weird. >> What's in builtin/.depend/fetch.o.d? [...] > please see below~. > > $ cat builtin/.depend/fetch.o.d > fetch.o: builtin/fetch.c cache.h git-compat-util.h compat/bswap.h \ That's the problem. See the following thread: http://thread.gmane.org/gmane.comp.version-control.git/185625/focus=185680 Currently when COMPUTE_HEADER_DEPENDENCIES=auto git tests for dependency generation support by checking the output and exit status from the following command: $(CC) $(ALL_CFLAGS) -c -MF /dev/null -MMD -MP \ -x c /dev/null -o /dev/null 2>&1 Perhaps this can be improved? Even something as simple as a ccache version test could presumably help a lot. Hope that helps, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rename {git- => git}remote-helpers.txt
Jeff King writes: > On Fri, Feb 01, 2013 at 10:52:52AM -0800, Junio C Hamano wrote: > >> > 4. Replace the rename "gitfoo" above with a "see git-foo..." pointer. >> > Users of "git help foo" would not ever see this, but people who >> > have trained their fingers to type "man gitfoo" would, along with >> > anybody following an outdated HTML link. >> > >> > 5. Update internal references to "linkgit:gitfoo" to point to >> > "git-foo". >> > >> > Hmm. That really does not seem so bad. The biggest downside is the >> > people who have to see the redirect made in step 4. >> >> Yeah, I see that a show-stopper in the whole sequence. >> >> This is one of the "if we had perfect knowledge we would have >> designed it this way, and we could still migrate our current system >> to that ideal, but it is dubious the difference between the current >> system and the ideal will outweigh the cost of migration" moment, >> isn't it? > > Yeah, perhaps. I did the patch series just to see what the effort would > be like. But at this point I am fine if we drop it (it sounded like > Jonathan was in favor of this direction, so maybe he wants to make a > final argument). OK. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Feb 2013, #01; Fri, 1)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 sometime in the middle of this month.
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
--
[Graduated to "master"]
* as/test-cleanup (2013-01-24) 1 commit
(merged to 'next' on 2013-01-28 at cc1147d)
+ t7102 (reset): don't hardcode SHA-1 in expected outputs
* bc/git-p4-for-python-2.4 (2013-01-30) 3 commits
(merged to 'next' on 2013-01-31 at 1096db1)
+ INSTALL: git-p4 does not support Python 3
(merged to 'next' on 2013-01-30 at 5d81ed2)
+ git-p4.py: support Python 2.4
+ git-p4.py: support Python 2.5
With small updates to remove dependency on newer features of
Python, keep git-p4 usable with older Python.
* jc/do-not-let-random-file-interfere-with-completion-tests (2013-01-24) 1
commit
(merged to 'next' on 2013-01-28 at df27f53)
+ t9902: protect test from stray build artifacts
Scripts to test bash completion was inherently flaky as it was
affected by whatever random things the user may have on $PATH.
* jc/no-git-config-in-clone (2013-01-11) 1 commit
(merged to 'next' on 2013-01-15 at feeffe1)
+ clone: do not export and unexport GIT_CONFIG
We stopped paying attention to $GIT_CONFIG environment that points
at a single configuration file from any command other than "git config"
quite a while ago, but "git clone" internally set, exported, and
then unexported the variable during its operation unnecessarily.
* jk/cvsimport-does-not-work-with-cvsps3 (2013-01-24) 1 commit
(merged to 'next' on 2013-01-28 at fef4eb2)
+ git-cvsimport.txt: cvsps-2 is deprecated
Warn people that other tools are more recommendable over
cvsimport+cvsps2 combo when doing a one-shot import, and cvsimport
will not work with cvsps3.
* jk/gc-auto-after-fetch (2013-01-26) 1 commit
(merged to 'next' on 2013-01-30 at 472d07b)
+ Merge branch 'jk/maint-gc-auto-after-fetch' into jk/gc-auto-after-fetch
(this branch uses jk/maint-gc-auto-after-fetch.)
This is to resolve merge conflicts early for the same topic to
recent codebase.
* jk/maint-gc-auto-after-fetch (2013-01-26) 2 commits
+ fetch-pack: avoid repeatedly re-scanning pack directory
+ fetch: run gc --auto after fetching
(this branch is used by jk/gc-auto-after-fetch.)
Help "fetch only" repositories that do not trigger "gc --auto"
often enough.
* jn/do-not-drop-username-when-reading-from-etc-mailname (2013-01-25) 1 commit
(merged to 'next' on 2013-01-28 at e0a8222)
+ ident: do not drop username when reading from /etc/mailname
We used to stuff "user@" and then append what we read from
/etc/mailname to come up with a default e-mail ident, but a bug
lost the "user@" part. This is to fix it.
* nd/edit-branch-desc-while-detached (2013-01-30) 1 commit
(merged to 'next' on 2013-01-30 at 69307d6)
+ branch: no detached HEAD check when editing another branch's description
(this branch is used by nd/branch-error-cases.)
Attempt to "branch --edit-description" an existing branch, while
being on a detached HEAD, errored out.
* nd/fetch-depth-is-broken (2013-01-11) 3 commits
(merged to 'next' on 2013-01-15 at 70a5ca7)
+ fetch: elaborate --depth action
+ upload-pack: fix off-by-one depth calculation in shallow clone
+ fetch: add --unshallow for turning shallow repo into complete one
"git fetch --depth" was broken in at least three ways. The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.
--
[New Topics]
* ft/transport-report-segv (2013-01-31) 1 commit
- push: fix segfault when HEAD points nowhere
A failure to push due to non-ff while on an unborn branch
dereferenced a NULL pointer while showing an error message.
Will merge to 'next'.
* sb/gpg-i18n (2013-01-31) 1 commit
- gpg: allow translation of more error messages
Will merge to 'next'.
* sb/gpg-plug-fd-leak (2013-01-31) 1 commit
- gpg: close stderr once finished with it in verify_signed_buffer()
Will merge to 'next'.
* sb/run-command-fd-error-reporting (2013-01-31) 1 commit
- run-command: be more informative about what failed
Will merge to 'next' after spelling stdout, etc. out.
* jk/remote-helpers-doc (2013-01-31) 2 commits
- [SQUASH] simplify maintenance of redirection pages
- Rename {git- => git}remote-helpers.txt
"git help remote-helpers" did not work; 'remote-helpers' is not
a subcommand name but a concept, so its documentation should have
been in gitremote-helpers, not git-remote-helpers.
Will merge to 'next' after squashing the fix in.
* sp/smart-http-content-type-chec
Re: [PATCH] rebase --preserve-merges keeps empty merge commits
Martin von Zweigbergk wrote: > I'm working on a re-roll of > http://thread.gmane.org/gmane.comp.version-control.git/205796 > > and finally got around to including test cases for what you fixed in > this patch. I want to make sure I'm testing what you fixed here. See > questions below. Thanks for that. I should have done this myself. > On Sat, Jan 12, 2013 at 12:46 PM, Phil Hord wrote: >> Since 90e1818f9a (git-rebase: add keep_empty flag, 2012-04-20) >> 'git rebase --preserve-merges' fails to preserve empty merge commits >> unless --keep-empty is also specified. Merge commits should be >> preserved in order to preserve the structure of the rebased graph, >> even if the merge commit does not introduce changes to the parent. >> >> Teach rebase not to drop merge commits only because they are empty. > Consider a history like > > # a---b---c > # \ \ > # d---l > #\ > # e > # \ > # C > > where 'l' is tree-same with 'd' and 'C' introduces the same change as 'c'. > > My test case runs 'git rebase -p e l' and expects the result to look like > > # a---b---c > # \ \ > # d \ > #\ \ > # e---l > This is probably right, but it is not exactly the case that caused my itch. I think my branch looked like this: # a---b---c # \ # d---f #\ \ # e---g # \ # l where g is tree-same with f. That is, e merged with f, but all of e's changes were dropped in the merge. So when I ran 'git rebase -p c l', I expected to end up with this: # a---b---c # \ # d---f #\ \ # e---g # \ # l But instead, I got an error because git-rebase--interactive.sh decided that g was empty, so it dropped it by commenting it out of the todo list: pick d pick e pick f #pick g pick l At the end of this attempt, I got some odd error about a cherry-pick have incorrect parameters or somesuch. I bisected the problem to a commit that clued me in to one of my commits being silently dropped. And that is specifically what I fixed. This happened only because 'is_empty_commit' checks for tree-sameness with the first parent; it does not consider whether there are multiple parents. Perhaps it should. >> A special case which is not handled by this change is for a merge commit >> whose parents are now the same commit because all the previous different >> parents have been dropped as a result of this rebase or some previous >> operation. > And for this case, the test case runs 'git rebase -p C l'. Is that > what you meant here? > > Before your patch, git would just say "Nothing to do" Huh. That is worse than I thought. > and after your > patch, we get > > # a---b---c > # \ \ > # d \ > #\ \ > # e \ > # \ \ > # C---l > > As you say, your patch doesn't try to handle this case, but at least > the new behavior seems better. I think we would ideally want the > recreated 'l' to have only 'C' as parent in this case. Does that make > sense? This is not what I meant, but it is a very interesting corner case. I am not sure I have a solid opinion on what the result should be here. I feel like it should look the same as you show here, since neither 'c' nor 'C' is a candidate for collapsing during this rebase. But I may be missing some subtlety here. Here is the corner case I was thinking of. I did not test this to see if this will happen, but I conceived that it might. Suppose you have this tree where # a---b---c # \ # d---g---l #\ / # C where 'C' introduced the same changes as 'c'. When I execute 'git rebase -p l c', I expect that I will end up with this: # a---b---c---d--- # \ \ # ---g---l That is, 'C' gets skipped because it introduces the same changes already seen in 'c'. So 'g' now has two parents: 'd' and 'C^'. But 'C^' is 'd', so 'g' now has two parents, both of whom are 'd'. I think it should collapse to this instead: # a---b---c---d---g---l I don't think this occurs because of my patch, and I am not sure it occurs at all. It is something that I considered when I was thinking of failure scenarios for my patch. I expect it also may happen if 'C' is an already-empty commit, or if it is made empty after conflict resolution involving the user. I mentioned it because I thought my patch _could_ address this if my is_merge_commit test would also consider whether the parents are distinct from each other or not. I hope this is clear, but please let me know if I made it too confusing. Phil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with spaces with TortoiseGitMerge
TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
with spaces in them by using -option "$FILE" (not -option:"$FILE",
which does not work for such paths) syntax.
This change was necessary because of MSYS path mangling [1], the ":"
after the "base" etc. arguments to TortoiseMerge caused to whole
argument instead of just the file name to be quoted in case of file
names with spaces. So TortoiseMerge was passed
"-base:new file.txt"
instead of
-base:"new file.txt"
(including the quotes). To work around this, TortoiseGitMerge does not
require the ":" after the arguments anymore which fixes handling file
names with spaces [2] (as written above).
[1] http://www.mingw.org/wiki/Posix_path_conversion
[2] https://github.com/msysgit/msysgit/issues/57
Signed-off-by: Sven Strickroth
Reported-by: Sebastian Schuberth
---
mergetools/tortoisemerge | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/mergetools/tortoisemerge b/mergetools/tortoisemerge
index 8476afa..3b89f1c 100644
--- a/mergetools/tortoisemerge
+++ b/mergetools/tortoisemerge
@@ -6,9 +6,17 @@ merge_cmd () {
if $base_present
then
touch "$BACKUP"
- "$merge_tool_path" \
- -base:"$BASE" -mine:"$LOCAL" \
- -theirs:"$REMOTE" -merged:"$MERGED"
+ basename="$(basename "$merge_tool_path" .exe)"
+ if test "$basename" = "tortoisegitmerge"
+ then
+ "$merge_tool_path" \
+ -base "$BASE" -mine "$LOCAL" \
+ -theirs "$REMOTE" -merged "$MERGED"
+ else
+ "$merge_tool_path" \
+ -base:"$BASE" -mine:"$LOCAL" \
+ -theirs:"$REMOTE" -merged:"$MERGED"
+ fi
check_unchanged
else
echo "$merge_tool_path cannot be used without a base" 1>&2
--
1.8.1.msysgit.1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATH/RFC] Revert "compat: add strtok_r()"
Hi Erik,
Erik Faye-Lund wrote:
> This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc.
>
> commit 28c5d9e ("vcs-svn: drop string_pool") previously removed
> the only call-site for strtok_r. So let's get rid of the compat
> implementation as well.
Yes, good idea. Sorry I didn't take care of this at the time.
> Conflicts:
> Makefile
> config.mak.in
> configure.ac
Since the conflicts were straightforward, I'd drop this or replace it
with a quick description of any surprising choices made in resolving
them.
Thanks. With the fixup from your reply squashed in,
Reviewed-by: Jonathan Nieder
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with
Am 01.02.2013 21:15 schrieb Junio C Hamano: >> TortoiseGitMerge is an improved version of TortoiseMerge specifically >> for use with Git on Windows. Due to MSYS path mangling [1], the ":" >> after the "base" etc. arguments to TortoiseMerge caused to whole >> argument instead of just the file name to be quoted in case of file >> names with spaces. So TortoiseMerge was passed >> >> "-base:new file.txt" >> >> instead of >> >> -base:"new file.txt" >> >> (including the quotes). To work around this, TortoiseGitMerge does not >> require the ":" after the arguments anymore which fixes handling file >> names with spaces. >> >> [1] http://www.mingw.org/wiki/Posix_path_conversion > > Sven? I just mailed a new patch. Thanks to Sebastian for pointing this out! @Junio: Feel free to optimize the commit message. -- Best regards, Sven Strickroth PGP key id F5A9D4C4 @ any key-server -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with
Am 01.02.2013 21:07 schrieb Sebastian Schuberth: > mergetools: Teach tortoisemerge about TortoiseGitMerge This subject doesn't make any sense if we don't combine the two patches. -- Best regards, Sven Strickroth PGP key id F5A9D4C4 @ any key-server -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
> > Presumably the first "The" should be dropped from either the link or > the surrounding text. > > Doubled 'The'. > You are right. I missed that; sorry. > > Isn't the old title more informative? > Yes; but every other link just uses the shorter version "Everyday Git". --- Thomas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
Jonathan Nieder writes: > Thomas Ackermann wrote: > >> --- a/Documentation/git.txt >> +++ b/Documentation/git.txt >> @@ -23,7 +23,7 @@ and full access to internals. >> >> See linkgit:gittutorial[7] to get started, then see >> link:everyday.html[Everyday Git] for a useful minimum set of >> -commands. The link:user-manual.html[Git User's Manual] has a more >> +commands. The link:user-manual.html[The Git User's Manual] has a more >> in-depth introduction. > > In the rendered version, this looks like: > > The The Git User's Manual[1] has a more in-depth introduction. > > Presumably the first "The" should be dropped from either the link or > the surrounding text. >... Thanks for a review; I'll drop this from today's integration cycle. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] fixup! fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
Jonathan Nieder writes: >> diff --git a/Documentation/git-rev-parse.txt >> b/Documentation/git-rev-parse.txt >> index c743469..14386ed 100644 >> --- a/Documentation/git-rev-parse.txt >> +++ b/Documentation/git-rev-parse.txt >> @@ -187,9 +187,9 @@ print a message to stderr and exit with nonzero status. >> Flags and parameters to be parsed. >> >> --resolve-git-dir :: >> -Check if is a valid git-dir or a git-file pointing to a valid >> -git-dir. If is a valid git-dir the resolved path to git-dir will >> -be printed. >> +Check if is a valid `$GIT_DIR` or a gitfile pointing to a valid >> +`$GIT_DIR`. If is a valid `$GIT_DIR` the resolved path to >> `$GIT_DIR` >> +will be printed. > > Hm, I don't find the old or the new version very easy to understand. Perhaps > the > idea is something like this? > > Check if is a valid git repository (.git or .git > directory) or "gitdir:" file. If is a "gitdir:" file > then the resolved path to the corresponding real git repository > will be printed. Yeah, sounds much better. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with
Sebastian Schuberth writes: > The commit message still does not mention MSYS path mangling at all, > which probably is why the reasoning of this patch was not yet fully > understood. Ahh, you are very right. I didn't realize that was what this funny "with colon, with SP" business was about. > I'd recommend something like the following: > > mergetools: Teach tortoisemerge about TortoiseGitMerge > > TortoiseGitMerge is an improved version of TortoiseMerge specifically > for use with Git on Windows. Due to MSYS path mangling [1], the ":" > after the "base" etc. arguments to TortoiseMerge caused to whole > argument instead of just the file name to be quoted in case of file > names with spaces. So TortoiseMerge was passed > > "-base:new file.txt" > > instead of > > -base:"new file.txt" > > (including the quotes). To work around this, TortoiseGitMerge does not > require the ":" after the arguments anymore which fixes handling file > names with spaces. > > [1] http://www.mingw.org/wiki/Posix_path_conversion Sven? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with
On Fri, Feb 1, 2013 at 8:33 PM, Sven Strickroth wrote: > TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths > with spaces in them by using -option "$FILE" (not -option:"$FILE", > which does not work for such paths) syntax. Both do not have a fully > posix compatible cli parameter parser, however, TortoiseGitMerge was > modified in order to handle filenames with spaces correctly. The > "-key value" form was choosen because this way no escaping for > quotes within quotes is necessary; see > https://github.com/msysgit/msysgit/issues/57 The commit message still does not mention MSYS path mangling at all, which probably is why the reasoning of this patch was not yet fully understood. I'd recommend something like the following: mergetools: Teach tortoisemerge about TortoiseGitMerge TortoiseGitMerge is an improved version of TortoiseMerge specifically for use with Git on Windows. Due to MSYS path mangling [1], the ":" after the "base" etc. arguments to TortoiseMerge caused to whole argument instead of just the file name to be quoted in case of file names with spaces. So TortoiseMerge was passed "-base:new file.txt" instead of -base:"new file.txt" (including the quotes). To work around this, TortoiseGitMerge does not require the ":" after the arguments anymore which fixes handling file names with spaces. [1] http://www.mingw.org/wiki/Posix_path_conversion -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
Thomas Ackermann wrote: > --- a/Documentation/git.txt > +++ b/Documentation/git.txt > @@ -23,7 +23,7 @@ and full access to internals. > > See linkgit:gittutorial[7] to get started, then see > link:everyday.html[Everyday Git] for a useful minimum set of > -commands. The link:user-manual.html[Git User's Manual] has a more > +commands. The link:user-manual.html[The Git User's Manual] has a more > in-depth introduction. In the rendered version, this looks like: The The Git User's Manual[1] has a more in-depth introduction. Presumably the first "The" should be dropped from either the link or the surrounding text. [...] > --- a/Documentation/gitcore-tutorial.txt > +++ b/Documentation/gitcore-tutorial.txt > @@ -17,7 +17,7 @@ work with a Git repository. > > If you just need to use Git as a revision control system you may prefer > to start with "A Tutorial Introduction to Git" (linkgit:gittutorial[7]) or > -link:user-manual.html[the Git User Manual]. > +link:user-manual.html[The Git User's Manual]. This comes out as ... you may prefer to start with "A Tutorial Instruction to Git" (gittutorial(7)) or The Git User's Manual[1]. The capital 'T' in "The" looks a bit strange, but a lowercase 't' in the corresponding footnote would also look strange. We can't have everything, I guess. A possible fix would be to drop the "The" from the link. The way you have it here also seems fine. [...] > --- a/Documentation/gittutorial-2.txt > +++ b/Documentation/gittutorial-2.txt > @@ -406,7 +406,7 @@ pages for any of the git commands; one good place to > start would be > with the commands mentioned in link:everyday.html[Everyday Git]. You > should be able to find any unknown jargon in linkgit:gitglossary[7]. > > -The link:user-manual.html[Git User's Manual] provides a more > +The link:user-manual.html[The Git User's Manual] provides a more > comprehensive introduction to Git. Doubled 'The'. [...] > --- a/Documentation/gittutorial.txt > +++ b/Documentation/gittutorial.txt > @@ -656,7 +656,7 @@ digressions that may be interesting at this point are: >* linkgit:gitworkflows[7]: Gives an overview of recommended > workflows. > > - * link:everyday.html[Everyday Git with 20 Commands Or So] > + * link:everyday.html[Everyday Git] Isn't the old title more informative? Thanks and hope that helps, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] Add a description for 'gitfile' to glossary
Junio C Hamano wrote: > How about saying something like this here in the glossary: > > A plain file `.git` at the root of a working tree that > points at the directory that is the real repository. > > And then as a separate patch, in gitrepository-layout.txt (eek---see > the other thread), we can do something like this: > > Documentation/gitrepository-layout.txt | 24 ++-- > 1 file changed, 18 insertions(+), 6 deletions(-) Looks correct and very readable. Thanks. Jonathan (patch left unsnipped for reference) > diff --git a/Documentation/gitrepository-layout.txt > b/Documentation/gitrepository-layout.txt > index 9f62886..473c6a0 100644 > --- a/Documentation/gitrepository-layout.txt > +++ b/Documentation/gitrepository-layout.txt > @@ -12,12 +12,24 @@ $GIT_DIR/* > DESCRIPTION > --- > > -You may find these things in your git repository (`.git` > -directory for a repository associated with your working tree, or > -`.git` directory for a public 'bare' repository. It is > -also possible to have a working tree where `.git` is a plain > -ASCII file containing `gitdir: `, i.e. the path to the > -real git repository). > +A Git repository comes in two different flavours: > + > + * a `.git` directory at the root of the working tree; > + > + * a `.git` directory that is a 'bare' repository > + (i.e. without its own working tree), that is typically used for > + exchanging histories with others by pushing into it and fetching > + from it. > + > +*Note*: Also you can have a plain text file `.git` at the root of > +your working tree, containing `gitdir: ` to point at the real > +directory that has the repository. This mechanism is often used for > +a working tree of a submodule checkout, to allow you in the > +containing superproject to `git checkout` a branch that does not > +have the submodule. The `checkout` has to remove the entire > +submodule working tree, without losing the submodule repository. > + > +These things may exist in a Git repository. > > objects:: > Object store associated with this repository. Usually > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] fixup! fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
Hi, Thomas Ackermann wrote: > Found by Junio: > Change git-dir to $GIT_DIR and git-file to gitfile. > > Signed-off-by: Thomas Ackermann > --- > Documentation/git-rev-parse.txt | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt > index c743469..14386ed 100644 > --- a/Documentation/git-rev-parse.txt > +++ b/Documentation/git-rev-parse.txt > @@ -187,9 +187,9 @@ print a message to stderr and exit with nonzero status. > Flags and parameters to be parsed. > > --resolve-git-dir :: > - Check if is a valid git-dir or a git-file pointing to a valid > - git-dir. If is a valid git-dir the resolved path to git-dir will > - be printed. > + Check if is a valid `$GIT_DIR` or a gitfile pointing to a valid > + `$GIT_DIR`. If is a valid `$GIT_DIR` the resolved path to > `$GIT_DIR` > + will be printed. Hm, I don't find the old or the new version very easy to understand. Perhaps the idea is something like this? Check if is a valid git repository (.git or .git directory) or "gitdir:" file. If is a "gitdir:" file then the resolved path to the corresponding real git repository will be printed. Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
On Fri, Feb 01, 2013 at 02:38:51PM -0500, Jeff King wrote: > Junio, do you want to apply the patch below? I guess it conflicts with > John's gitremote-helper.txt tweak, though. Argh, it would help if I actually ran "git commit", and/or looked at what I was sending out. Here it is with the actual change. -- >8 -- Subject: [PATCH] Documentation/Makefile: clean up MAN*_TXT lists We keep a list of the various files that end up as man1, man5, etc. Let's break these single-line lists into sorted multi-line lists, which makes diffs that touch them much easier to read. Reviewed-by: Jonathan Nieder Signed-off-by: Jeff King --- Documentation/Makefile | 38 +- 1 file changed, 29 insertions(+), 9 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 971977b..5d22e0e 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -1,13 +1,33 @@ MAN7_TXT += gitcredentials.txt -MAN1_TXT= \ - $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ - $(wildcard git-*.txt)) \ - gitk.txt gitweb.txt git.txt -MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \ - gitrepository-layout.txt gitweb.conf.txt -MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \ - gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \ - gitdiffcore.txt gitnamespaces.txt gitrevisions.txt gitworkflows.txt +# Guard against environment variables +MAN1_TXT = +MAN5_TXT = +MAN7_TXT = + +MAN1_TXT += $(filter-out \ + $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ + $(wildcard git-*.txt)) +MAN1_TXT += git.txt +MAN1_TXT += gitk.txt +MAN1_TXT += gitweb.txt + +MAN5_TXT += gitattributes.txt +MAN5_TXT += githooks.txt +MAN5_TXT += gitignore.txt +MAN5_TXT += gitmodules.txt +MAN5_TXT += gitrepository-layout.txt +MAN5_TXT += gitweb.conf.txt + +MAN7_TXT += gitcli.txt +MAN7_TXT += gitcore-tutorial.txt MAN7_TXT += gitcredentials.txt +MAN7_TXT += gitcvs-migration.txt +MAN7_TXT += gitdiffcore.txt +MAN7_TXT += gitglossary.txt +MAN7_TXT += gitnamespaces.txt +MAN7_TXT += gitrevisions.txt +MAN7_TXT += gittutorial-2.txt +MAN7_TXT += gittutorial.txt +MAN7_TXT += gitworkflows.txt MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT) MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT)) -- 1.8.1.2.11.g1a2f572 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
On Fri, Feb 01, 2013 at 11:20:10AM -0800, Jonathan Nieder wrote: > Jeff King wrote: > > > We keep a list of the various files that end up as man1, > > man5, etc. Let's break these single-line lists into sorted > > multi-line lists, which makes diffs that touch them much > > easier to read. > > Independentally of the rest of the series, I think this is a good > cleanup. Yeah, I'd agree. > > --- a/Documentation/Makefile > > +++ b/Documentation/Makefile > > @@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt > > -MAN1_TXT= \ > > - $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ > > - $(wildcard git-*.txt)) \ > > - gitk.txt gitweb.txt git.txt > > +MAN1_TXT += git.txt > > +MAN1_TXT += gitk.txt > > +MAN1_TXT += gitweb.txt > > + > > If the user happens to have MAN[157]_TXT set in the environment, this > would be affected by that. How about: > > # Guard against environment variables > MAN1_TXT = > MAN5_TXT = > MAN7_TXT = > > MAN1_TXT += ... > ... > > ? Sure, not that likely, but no reason not to be careful. I notice the rest of the file uses the: FOO = first FOO += second ... pattern, though I prefer the style you showed myself. Junio, do you want to apply the patch below? I guess it conflicts with John's gitremote-helper.txt tweak, though. -- >8 -- Subject: [PATCH] Documentation/Makefile: clean up MAN*_TXT lists We keep a list of the various files that end up as man1, man5, etc. Let's break these single-line lists into sorted multi-line lists, which makes diffs that touch them much easier to read. Reviewed-by: Jonathan Nieder Signed-off-by: Jeff King --- Documentation/Makefile | 33 - 1 file changed, 24 insertions(+), 9 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 971977b..8e7939f 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt -MAN1_TXT= \ - $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ - $(wildcard git-*.txt)) \ - gitk.txt gitweb.txt git.txt -MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \ - gitrepository-layout.txt gitweb.conf.txt -MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \ - gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \ - gitdiffcore.txt gitnamespaces.txt gitrevisions.txt gitworkflows.txt +MAN1_TXT += $(filter-out \ + $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ + $(wildcard git-*.txt)) +MAN1_TXT += git.txt +MAN1_TXT += gitk.txt +MAN1_TXT += gitweb.txt + +MAN5_TXT += gitattributes.txt +MAN5_TXT += githooks.txt +MAN5_TXT += gitignore.txt +MAN5_TXT += gitmodules.txt +MAN5_TXT += gitrepository-layout.txt +MAN5_TXT += gitweb.conf.txt + +MAN7_TXT += gitcli.txt +MAN7_TXT += gitcore-tutorial.txt MAN7_TXT += gitcredentials.txt +MAN7_TXT += gitcvs-migration.txt +MAN7_TXT += gitdiffcore.txt +MAN7_TXT += gitglossary.txt +MAN7_TXT += gitnamespaces.txt +MAN7_TXT += gitrevisions.txt +MAN7_TXT += gittutorial-2.txt +MAN7_TXT += gittutorial.txt +MAN7_TXT += gitworkflows.txt MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT) MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT)) -- 1.8.1.2.11.g1a2f572 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
Jonathan Nieder writes: >> --- a/Documentation/Makefile >> +++ b/Documentation/Makefile >> @@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt >> -MAN1_TXT= \ >> -$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ >> -$(wildcard git-*.txt)) \ >> -gitk.txt gitweb.txt git.txt >> +MAN1_TXT += git.txt >> +MAN1_TXT += gitk.txt >> +MAN1_TXT += gitweb.txt >> + > > If the user happens to have MAN[157]_TXT set in the environment, this > would be affected by that. How about: > > # Guard against environment variables > MAN1_TXT = > MAN5_TXT = > MAN7_TXT = > > MAN1_TXT += ... > ... > > With that change, > Reviewed-by: Jonathan Nieder Sounds sensible. Let's go in that direction. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mergetools: Enable tortoisemerge to handle filenames with
spaces with TortoiseGitMerge
TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
with spaces in them by using -option "$FILE" (not -option:"$FILE",
which does not work for such paths) syntax. Both do not have a fully
posix compatible cli parameter parser, however, TortoiseGitMerge was
modified in order to handle filenames with spaces correctly. The
"-key value" form was choosen because this way no escaping for
quotes within quotes is necessary; see
https://github.com/msysgit/msysgit/issues/57
Signed-off-by: Sven Strickroth
Reported-by: Sebastian Schuberth
---
mergetools/tortoisemerge | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/mergetools/tortoisemerge b/mergetools/tortoisemerge
index 8476afa..3b89f1c 100644
--- a/mergetools/tortoisemerge
+++ b/mergetools/tortoisemerge
@@ -6,9 +6,17 @@ merge_cmd () {
if $base_present
then
touch "$BACKUP"
- "$merge_tool_path" \
- -base:"$BASE" -mine:"$LOCAL" \
- -theirs:"$REMOTE" -merged:"$MERGED"
+ basename="$(basename "$merge_tool_path" .exe)"
+ if test "$basename" = "tortoisegitmerge"
+ then
+ "$merge_tool_path" \
+ -base "$BASE" -mine "$LOCAL" \
+ -theirs "$REMOTE" -merged "$MERGED"
+ else
+ "$merge_tool_path" \
+ -base:"$BASE" -mine:"$LOCAL" \
+ -theirs:"$REMOTE" -merged:"$MERGED"
+ fi
check_unchanged
else
echo "$merge_tool_path cannot be used without a base" 1>&2
--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] Add a description for 'gitfile' to glossary
Junio C Hamano writes: > Thomas Ackermann writes: > >> Signed-off-by: Thomas Ackermann >> --- >> Documentation/glossary-content.txt | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/Documentation/glossary-content.txt >> b/Documentation/glossary-content.txt >> index 7c15bc0..ddf2f66 100644 >> --- a/Documentation/glossary-content.txt >> +++ b/Documentation/glossary-content.txt >> @@ -149,6 +149,9 @@ to point at the new commit. >> [[def_git_archive]]Git archive:: >> Synonym for <> (for arch people). >> >> +[[def_gitfile]]gitfile:: >> +A `.git` file which points to a `$GIT_DIR` (used for Git submodules). >> + > > It is more like 'used by' ;-) People are free to write their > Porcelain system that uses this mechanism. The series merged at e2e2def (Merge branch 'lh/git-file', 2008-05-05) added a mention of this to repository-layout and the readers can see how it is interpreted by Git, but I doubt that anything explains why you may want to use it in the documentation. How about saying something like this here in the glossary: A plain file `.git` at the root of a working tree that points at the directory that is the real repository. And then as a separate patch, in gitrepository-layout.txt (eek---see the other thread), we can do something like this: Documentation/gitrepository-layout.txt | 24 ++-- 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt index 9f62886..473c6a0 100644 --- a/Documentation/gitrepository-layout.txt +++ b/Documentation/gitrepository-layout.txt @@ -12,12 +12,24 @@ $GIT_DIR/* DESCRIPTION --- -You may find these things in your git repository (`.git` -directory for a repository associated with your working tree, or -`.git` directory for a public 'bare' repository. It is -also possible to have a working tree where `.git` is a plain -ASCII file containing `gitdir: `, i.e. the path to the -real git repository). +A Git repository comes in two different flavours: + + * a `.git` directory at the root of the working tree; + + * a `.git` directory that is a 'bare' repository + (i.e. without its own working tree), that is typically used for + exchanging histories with others by pushing into it and fetching + from it. + +*Note*: Also you can have a plain text file `.git` at the root of +your working tree, containing `gitdir: ` to point at the real +directory that has the repository. This mechanism is often used for +a working tree of a submodule checkout, to allow you in the +containing superproject to `git checkout` a branch that does not +have the submodule. The `checkout` has to remove the entire +submodule working tree, without losing the submodule repository. + +These things may exist in a Git repository. objects:: Object store associated with this repository. Usually -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] docs: convert "concept" manpages to git-*
Jeff King wrote: > Let's just call everything git-*, which is simpler. This > patch renames the documentation files, updates the Makefile > to find them, and updates internal linkgit references to the > pages. It updates builtin/help.c so that users of "git help > foo" will not even notice the difference. > > Users of external html links, or users who have trained > their fingers to type "man gitfoo" will notice the missing > pages. This patch does not install a "this page has moved" > placeholder, but that can easily be done on top. Thanks for writing this. I think this one should wait until someone (perhaps me) takes care of the redirects. Ideally in addition to simple "this place has moved" HTML placeholders and manpages using the .so macro, a makefile target to generate redirect directives for your apache configuration might make sense. In the meantime, having "man gitrepository-layout" is not the worst wart in the world. Cheers, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
Jeff King wrote: > We keep a list of the various files that end up as man1, > man5, etc. Let's break these single-line lists into sorted > multi-line lists, which makes diffs that touch them much > easier to read. Independentally of the rest of the series, I think this is a good cleanup. > --- a/Documentation/Makefile > +++ b/Documentation/Makefile > @@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt > -MAN1_TXT= \ > - $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ > - $(wildcard git-*.txt)) \ > - gitk.txt gitweb.txt git.txt > +MAN1_TXT += git.txt > +MAN1_TXT += gitk.txt > +MAN1_TXT += gitweb.txt > + If the user happens to have MAN[157]_TXT set in the environment, this would be affected by that. How about: # Guard against environment variables MAN1_TXT = MAN5_TXT = MAN7_TXT = MAN1_TXT += ... ... ? With that change, Reviewed-by: Jonathan Nieder -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rebase --preserve-merges keeps empty merge commits
I'm working on a re-roll of http://thread.gmane.org/gmane.comp.version-control.git/205796 and finally got around to including test cases for what you fixed in this patch. I want to make sure I'm testing what you fixed here. See questions below. On Sat, Jan 12, 2013 at 12:46 PM, Phil Hord wrote: > Since 90e1818f9a (git-rebase: add keep_empty flag, 2012-04-20) > 'git rebase --preserve-merges' fails to preserve empty merge commits > unless --keep-empty is also specified. Merge commits should be > preserved in order to preserve the structure of the rebased graph, > even if the merge commit does not introduce changes to the parent. > > Teach rebase not to drop merge commits only because they are empty. Consider a history like # a---b---c # \ \ # d---l #\ # e # \ # C where 'l' is tree-same with 'd' and 'C' introduces the same change as 'c'. My test case runs 'git rebase -p e l' and expects the result to look like # a---b---c # \ \ # d \ #\ \ # e---l > A special case which is not handled by this change is for a merge commit > whose parents are now the same commit because all the previous different > parents have been dropped as a result of this rebase or some previous > operation. And for this case, the test case runs 'git rebase -p C l'. Is that what you meant here? Before your patch, git would just say "Nothing to do" and after your patch, we get # a---b---c # \ \ # d \ #\ \ # e \ # \ \ # C---l As you say, your patch doesn't try to handle this case, but at least the new behavior seems better. I think we would ideally want the recreated 'l' to have only 'C' as parent in this case. Does that make sense? Martin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rename {git- => git}remote-helpers.txt
On Fri, Feb 01, 2013 at 10:52:52AM -0800, Junio C Hamano wrote: > > 4. Replace the rename "gitfoo" above with a "see git-foo..." pointer. > > Users of "git help foo" would not ever see this, but people who > > have trained their fingers to type "man gitfoo" would, along with > > anybody following an outdated HTML link. > > > > 5. Update internal references to "linkgit:gitfoo" to point to > > "git-foo". > > > > Hmm. That really does not seem so bad. The biggest downside is the > > people who have to see the redirect made in step 4. > > Yeah, I see that a show-stopper in the whole sequence. > > This is one of the "if we had perfect knowledge we would have > designed it this way, and we could still migrate our current system > to that ideal, but it is dubious the difference between the current > system and the ideal will outweigh the cost of migration" moment, > isn't it? Yeah, perhaps. I did the patch series just to see what the effort would be like. But at this point I am fine if we drop it (it sounded like Jonathan was in favor of this direction, so maybe he wants to make a final argument). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Verify Content-Type from smart HTTP servers
On Fri, Feb 01, 2013 at 10:09:26AM -0800, Junio C Hamano wrote:
> > so I do not think the patch makes anything worse. However, should we
> > take this opportunity to make the "did we get a smart response" test
> > more robust? That is, should we actually be checking the content-type
> > in the outer conditional, and going down the smart code-path if it is
> > application/x-%s-advertisement, and otherwise treating the result as
> > dumb?
>
> Does the outer caller that switches between dumb and smart actually
> know what service type it is requesting (I am not familiar with the
> callchain involved)? Even if it doesn't, it may still make sense.
I was specifically thinking of this (on top of your patch):
diff --git a/remote-curl.c b/remote-curl.c
index e6f3b63..63680a8 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -134,14 +134,12 @@ static struct discovery* discover_refs(const char
*service)
last->buf_alloc = strbuf_detach(&buffer, &last->len);
last->buf = last->buf_alloc;
- if (maybe_smart && 5 <= last->len && last->buf[4] == '#') {
+ strbuf_addf(&exp, "application/x-%s-advertisement", service);
+ if (maybe_smart && !strbuf_cmp(&exp, &type)) {
/*
* smart HTTP response; validate that the service
* pkt-line matches our request.
*/
- strbuf_addf(&exp, "application/x-%s-advertisement", service);
- if (strbuf_cmp(&exp, &type))
- die("invalid content-type %s", type.buf);
if (packet_get_line(&buffer, &last->buf, &last->len) <= 0)
die("%s has invalid packet header", refs_url);
if (buffer.len && buffer.buf[buffer.len - 1] == '\n')
To just follow the dumb path if we don't get the content-type we expect.
We may want to keep the '#' format check in addition (packet_get_line
will check it and die, anyway, but we may want to drop back to
considering it dumb, just to protect against a badly configured dumb
server which uses our mime type, but I do not think it likely).
> > As a side note, should we (can we) care about the content-type for dumb
> > http? It should probably be text/plain or application/octet-stream, but
> > I would not be surprised if we get a variety of random junk in the real
> > world, though.
>
> The design objective of dumb http protocol was to allow working with
> any dumb bit transfer thing, so I'd prefer to keep it lenient and
> allow application/x-git-loose-object-file and somesuch.
Yeah, I do not think it really buys us anything in practice, and we have
no way of knowing what kind of crap is in the wild. Not worth it.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rename {git- => git}remote-helpers.txt
Jeff King writes: > Right. So we have some that must be "gitfoo", and others that do not > care. If we turned "githooks" into "git-hooks" and removed the "is it a > command?" magic from "git help", then "git help hooks" would still find > hooks. And likewise, "git help gitignore" would still find "gitignore". > But you could no longer say "git help ignore" to find "gitignore". Which I think is a good thing ;-) > Which personally I am OK with. It is not a sensible thing to ask for; > the concept is not "ignore", but rather "the gitignore file". Yes, exactly. > 4. Replace the rename "gitfoo" above with a "see git-foo..." pointer. > Users of "git help foo" would not ever see this, but people who > have trained their fingers to type "man gitfoo" would, along with > anybody following an outdated HTML link. > > 5. Update internal references to "linkgit:gitfoo" to point to > "git-foo". > > Hmm. That really does not seem so bad. The biggest downside is the > people who have to see the redirect made in step 4. Yeah, I see that a show-stopper in the whole sequence. This is one of the "if we had perfect knowledge we would have designed it this way, and we could still migrate our current system to that ideal, but it is dubious the difference between the current system and the ideal will outweigh the cost of migration" moment, isn't it? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] fixup! Documentation: avoid poor-man's small caps
Thomas Ackermann writes: > Signed-off-by: Thomas Ackermann > --- I think this deserves to be a separate patch in the series, that says "StGit is the right spelling of the system, not StGIT", referring to https://gna.org/projects/stgit/ or somewhere, in the log message. Will massage the above in; no need to resend. Thanks. > Documentation/git-tools.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt > index 338986a..ad8b823 100644 > --- a/Documentation/git-tools.txt > +++ b/Documentation/git-tools.txt > @@ -29,7 +29,7 @@ Alternative/Augmentative Porcelains > - *pg* (http://www.spearce.org/category/projects/scm/pg/) > > pg is a shell script wrapper around Git to help the user manage a set of > - patches to files. pg is somewhat like quilt or StGIT, but it does have a > + patches to files. pg is somewhat like quilt or StGit, but it does have a > slightly different feature set. > > > @@ -60,7 +60,7 @@ History Viewers > > - *qgit* (http://digilander.libero.it/mcostalba/) > > - QGit is a git/StGIT GUI viewer built on Qt/C++. QGit could be used > + QGit is a git/StGit GUI viewer built on Qt/C++. QGit could be used > to browse history and directory tree, view annotated files, commit > changes cherry picking single files or applying patches. > Currently it is the fastest and most feature rich among the Git -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
Thomas Ackermann writes: > Signed-off-by: Thomas Ackermann > --- > Documentation/git.txt | 2 +- > Documentation/gitcore-tutorial.txt | 6 +++--- > Documentation/gittutorial-2.txt| 2 +- > Documentation/gittutorial.txt | 2 +- > 4 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/Documentation/git.txt b/Documentation/git.txt > index c431ba2..c5f6845 100644 > --- a/Documentation/git.txt > +++ b/Documentation/git.txt > @@ -23,7 +23,7 @@ and full access to internals. > > See linkgit:gittutorial[7] to get started, then see > link:everyday.html[Everyday Git] for a useful minimum set of > -commands. The link:user-manual.html[Git User's Manual] has a more > +commands. The link:user-manual.html[The Git User's Manual] has a more > in-depth introduction. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] l10n: de.po: translate "revision" consistently as "Revision"
In the current German translation, the word "revision" was translated as both "Version" (translation of "commit") and "Revision". Since a revision in Git is not necessarily a commit, we should not translate it with the same word in order to give the user an idea that it's not necessarily the same. After this commit, "revision" is consistently translated as "Revision". Signed-off-by: Ralf Thielow --- This replaces a patch [1] earlier sent to the list. I've also updated the glossary [2] of the German translation. [1] http://article.gmane.org/gmane.comp.version-control.git/214852 [2] https://github.com/ralfth/git-po-de/wiki/Glossary po/de.po | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/po/de.po b/po/de.po index ed8330a..0a94b4b 100644 --- a/po/de.po +++ b/po/de.po @@ -4438,7 +4438,7 @@ msgid "" msgstr "" "Kein externes Projektarchiv angegeben. Bitte geben Sie entweder eine URL\n" "oder den Namen des externen Archivs an, von welchem neue\n" -"Versionen angefordert werden sollen." +"Revisionen angefordert werden sollen." #: builtin/fetch.c:932 msgid "You need to specify a tag name." @@ -4623,7 +4623,7 @@ msgstr "" #: builtin/grep.c:22 msgid "git grep [options] [-e] [...] [[--] ...]" -msgstr "git grep [Optionen] [-e] [...] [[--] ...]" +msgstr "git grep [Optionen] [-e] [...] [[--] ...]" #: builtin/grep.c:217 #, c-format @@ -5501,7 +5501,7 @@ msgstr "ungültiges in-reply-to: %s" #: builtin/log.c:913 msgid "git format-patch [options] [ | ]" -msgstr "git format-patch [Optionen] [ | ]" +msgstr "git format-patch [Optionen] [ | ]" #: builtin/log.c:958 msgid "Two output directories?" @@ -6193,7 +6193,7 @@ msgstr "findet Vorfahren für eine einzelne n-Wege-Zusammenführung" #: builtin/merge-base.c:100 msgid "list revs not reachable from others" -msgstr "listet Revisionen auf, die nicht durch Andere erreichbar sind" +msgstr "listet Versionen auf, die nicht durch Andere erreichbar sind" #: builtin/merge-base.c:102 msgid "is the first one ancestor of the other?" @@ -7952,7 +7952,7 @@ msgstr "'%s' Zurücksetzung ist in einem bloßen Projektarchiv nicht erlaubt" #: builtin/reset.c:333 #, c-format msgid "Could not reset index file to revision '%s'." -msgstr "Konnte Bereitstellungsdatei nicht zu Version '%s' zurücksetzen." +msgstr "Konnte Bereitstellungsdatei nicht zu Revision '%s' zurücksetzen." #: builtin/reset.c:339 msgid "Unstaged changes after reset:" @@ -9053,7 +9053,7 @@ msgstr "nicht erkannte Option: '$arg'" #: git-bisect.sh:99 #, sh-format msgid "'$arg' does not appear to be a valid revision" -msgstr "'$arg' scheint keine gültige Version zu sein" +msgstr "'$arg' scheint keine gültige Revision zu sein" #: git-bisect.sh:117 msgid "Bad HEAD - I need a HEAD" @@ -9116,7 +9116,7 @@ msgid "" "You need to give me at least one good and one bad revisions.\n" "(You can use \"git bisect bad\" and \"git bisect good\" for that.)" msgstr "" -"Sie müssen mindestens eine korrekte und eine fehlerhafte Version angeben.\n" +"Sie müssen mindestens eine korrekte und eine fehlerhafte Revision angeben.\n" "(Sie können dafür \"git bisect bad\" und \"git bisect good\" benutzen.)" #: git-bisect.sh:292 @@ -9126,7 +9126,7 @@ msgid "" "(You can use \"git bisect bad\" and \"git bisect good\" for that.)" msgstr "" "Sie müssen mit \"git bisect start\" beginnen.\n" -"Danach müssen Sie mindestens eine korrekte und eine fehlerhafte Version " +"Danach müssen Sie mindestens eine korrekte und eine fehlerhafte Revision " "angeben.\n" "(Sie können dafür \"git bisect bad\" und \"git bisect good\" benutzen.)" @@ -9650,7 +9650,7 @@ msgstr "" #: git-submodule.sh:662 #, sh-format msgid "Unable to find current revision in submodule path '$sm_path'" -msgstr "Konnte aktuelle Version in Unterprojekt-Pfad '$sm_path' nicht finden" +msgstr "Konnte aktuelle Revision in Unterprojekt-Pfad '$sm_path' nicht finden" #: git-submodule.sh:671 git-submodule.sh:695 #, sh-format -- 1.8.1.2.623.g7d3a2ef -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] Add a description for 'gitfile' to glossary
Thomas Ackermann writes: > Signed-off-by: Thomas Ackermann > --- > Documentation/glossary-content.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/glossary-content.txt > b/Documentation/glossary-content.txt > index 7c15bc0..ddf2f66 100644 > --- a/Documentation/glossary-content.txt > +++ b/Documentation/glossary-content.txt > @@ -149,6 +149,9 @@ to point at the new commit. > [[def_git_archive]]Git archive:: > Synonym for <> (for arch people). > > +[[def_gitfile]]gitfile:: > + A `.git` file which points to a `$GIT_DIR` (used for Git submodules). > + It is more like 'used by' ;-) People are free to write their Porcelain system that uses this mechanism. > [[def_grafts]]grafts:: > Grafts enables two otherwise different lines of development to be joined > together by recording fake ancestry information for commits. This way -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Aw: Re: Aw: Re: [PATCH v3 3/6] Change 'git' to 'Git' whenever the whole system is referred to #2
Thomas Ackermann writes: > > >> I think we have waited long enough and as far as I recall we didn't >> see any reports of misconversion or forgotten conversion, so I'll >> squash the fixes parked on the topic branch, whose tip is at >> bfb8e1eb6375afb (fixup! Change 'git' to 'Git' whenever the whole >> system is referred to #4, 2013-01-22), and merge the result to >> 'next' sometime tomorrow. > > Here are my final fixups on top of bfb8e1eb6375afb: > I morphed the remarks from Junio and David into patch form and > also did the reverse check for wrong usage of 'Git' instead of 'git'. > While doing the later I also noticed some small glitches and fixed them. > Squash at your will. Thanks. > [PATCH 1/6] fixup! fixup! Change 'git' to 'Git' whenever the whole system is > referred to #2 > [PATCH 2/6] fixup! fixup! fixup! Change 'git' to 'Git' whenever the whole > system is referred to #1 > [PATCH 3/6] fixup! Documentation: avoid poor-man's small caps > [PATCH 4/6] Fix places where 'Git' should be 'git > [PATCH 5/6] Add a description for 'gitfile' to glossary > [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a > quoting error -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
Signed-off-by: Thomas Ackermann --- Documentation/git.txt | 2 +- Documentation/gitcore-tutorial.txt | 6 +++--- Documentation/gittutorial-2.txt| 2 +- Documentation/gittutorial.txt | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/git.txt b/Documentation/git.txt index c431ba2..c5f6845 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -23,7 +23,7 @@ and full access to internals. See linkgit:gittutorial[7] to get started, then see link:everyday.html[Everyday Git] for a useful minimum set of -commands. The link:user-manual.html[Git User's Manual] has a more +commands. The link:user-manual.html[The Git User's Manual] has a more in-depth introduction. After you mastered the basic concepts, you can come back to this diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 59c1c17..88e9839 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -17,7 +17,7 @@ work with a Git repository. If you just need to use Git as a revision control system you may prefer to start with "A Tutorial Introduction to Git" (linkgit:gittutorial[7]) or -link:user-manual.html[the Git User Manual]. +link:user-manual.html[The Git User's Manual]. However, an understanding of these low-level tools can be helpful if you want to understand Git's internals. @@ -568,8 +568,8 @@ can explore on your own. [NOTE] Most likely, you are not directly using the core -Git Plumbing commands, but using Porcelain such as 'git add', `git-rm' -and `git-commit'. +Git Plumbing commands, but using Porcelain such as 'git add', 'git rm' +and 'git commit'. Tagging a version diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt index 94c906e..2db4ea3 100644 --- a/Documentation/gittutorial-2.txt +++ b/Documentation/gittutorial-2.txt @@ -406,7 +406,7 @@ pages for any of the git commands; one good place to start would be with the commands mentioned in link:everyday.html[Everyday Git]. You should be able to find any unknown jargon in linkgit:gitglossary[7]. -The link:user-manual.html[Git User's Manual] provides a more +The link:user-manual.html[The Git User's Manual] provides a more comprehensive introduction to Git. linkgit:gitcvs-migration[7] explains how to diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index 8262196..e63fd9f 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -656,7 +656,7 @@ digressions that may be interesting at this point are: * linkgit:gitworkflows[7]: Gives an overview of recommended workflows. - * link:everyday.html[Everyday Git with 20 Commands Or So] + * link:everyday.html[Everyday Git] * linkgit:gitcvs-migration[7]: Git for CVS users. -- 1.8.0.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] Add a description for 'gitfile' to glossary
Signed-off-by: Thomas Ackermann --- Documentation/glossary-content.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 7c15bc0..ddf2f66 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -149,6 +149,9 @@ to point at the new commit. [[def_git_archive]]Git archive:: Synonym for <> (for arch people). +[[def_gitfile]]gitfile:: + A `.git` file which points to a `$GIT_DIR` (used for Git submodules). + [[def_grafts]]grafts:: Grafts enables two otherwise different lines of development to be joined together by recording fake ancestry information for commits. This way -- 1.8.0.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] Fix places where 'Git' should be 'git
Signed-off-by: Thomas Ackermann --- Documentation/git-p4.txt| 4 ++-- Documentation/git-remote-fd.txt | 2 +- Documentation/gittutorial.txt | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt index 1d1b020..3417cb3 100644 --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -334,11 +334,11 @@ configuration file. This allows future 'git p4 submit' commands to work properly; the submit command looks only at the variable and does not have a command-line option. -The full syntax for a p4 view is documented in 'p4 help views'. 'Git p4' +The full syntax for a p4 view is documented in 'p4 help views'. 'git p4' knows only a subset of the view syntax. It understands multi-line mappings, overlays with '+', exclusions with '-' and double-quotes around whitespace. Of the possible wildcards, 'git p4' only handles -'...', and only when it is at the end of the path. 'Git p4' will complain +'...', and only when it is at the end of the path. 'git p4' will complain if it encounters an unhandled wildcard. Bugs in the implementation of overlap mappings exist. If multiple depot diff --git a/Documentation/git-remote-fd.txt b/Documentation/git-remote-fd.txt index 9bfe12c..933c2ad 100644 --- a/Documentation/git-remote-fd.txt +++ b/Documentation/git-remote-fd.txt @@ -12,7 +12,7 @@ SYNOPSIS DESCRIPTION --- This helper uses specified file descriptors to connect to a remote Git server. -This is not meant for end users but for programs and scripts calling Git +This is not meant for end users but for programs and scripts calling git fetch, push or archive. If only is given, it is assumed to be a bidirectional socket connected diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index 6091988..8262196 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -462,7 +462,7 @@ Exploring history Git history is represented as a series of interrelated commits. We have already seen that the 'git log' command can list those commits. -Note that first line of each Git log entry also gives a name for the +Note that first line of each git log entry also gives a name for the commit: - -- 1.8.0.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Verify Content-Type from smart HTTP servers
Jeff King writes:
> Should this be "From:" Shawn? The tone of the message and the S-O-B
> order makes it look like it.
Yes. I should have left that line when edited the format-patch
output in my MUA to say I was resending something that vger rejected
and people did not see after tweaking the patch to slip their taboo
list.
>> @@ -133,16 +135,19 @@ static struct discovery* discover_refs(const char
>> *service)
>> last->buf = last->buf_alloc;
>>
>> if (maybe_smart && 5 <= last->len && last->buf[4] == '#') {
>> -/* smart HTTP response; validate that the service
>> +/*
>> + * smart HTTP response; validate that the service
>> * pkt-line matches our request.
>> */
>> -struct strbuf exp = STRBUF_INIT;
>> -
>> +strbuf_addf(&exp, "application/x-%s-advertisement", service);
>> +if (strbuf_cmp(&exp, &type))
>> +die("invalid content-type %s", type.buf);
>
> Hmm. I wondered if it is possible for a non-smart server to send us down
> this code path, which would now complain of the bogus content-type.
> Something like an info/refs file with:
>
> # 1
> # the comment above is meaningless, but puts a "#" at position 4.
>
> But I note that we would already die in the next line:
>
>> if (packet_get_line(&buffer, &last->buf, &last->len) <= 0)
>> die("%s has invalid packet header", refs_url);
>
> so I do not think the patch makes anything worse. However, should we
> take this opportunity to make the "did we get a smart response" test
> more robust? That is, should we actually be checking the content-type
> in the outer conditional, and going down the smart code-path if it is
> application/x-%s-advertisement, and otherwise treating the result as
> dumb?
Does the outer caller that switches between dumb and smart actually
know what service type it is requesting (I am not familiar with the
callchain involved)? Even if it doesn't, it may still make sense.
> As a side note, should we (can we) care about the content-type for dumb
> http? It should probably be text/plain or application/octet-stream, but
> I would not be surprised if we get a variety of random junk in the real
> world, though.
The design objective of dumb http protocol was to allow working with
any dumb bit transfer thing, so I'd prefer to keep it lenient and
allow application/x-git-loose-object-file and somesuch.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] fixup! Documentation: avoid poor-man's small caps
Signed-off-by: Thomas Ackermann --- Documentation/git-tools.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt index 338986a..ad8b823 100644 --- a/Documentation/git-tools.txt +++ b/Documentation/git-tools.txt @@ -29,7 +29,7 @@ Alternative/Augmentative Porcelains - *pg* (http://www.spearce.org/category/projects/scm/pg/) pg is a shell script wrapper around Git to help the user manage a set of - patches to files. pg is somewhat like quilt or StGIT, but it does have a + patches to files. pg is somewhat like quilt or StGit, but it does have a slightly different feature set. @@ -60,7 +60,7 @@ History Viewers - *qgit* (http://digilander.libero.it/mcostalba/) - QGit is a git/StGIT GUI viewer built on Qt/C++. QGit could be used + QGit is a git/StGit GUI viewer built on Qt/C++. QGit could be used to browse history and directory tree, view annotated files, commit changes cherry picking single files or applying patches. Currently it is the fastest and most feature rich among the Git -- 1.8.0.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] fixup! fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
Found by Junio: Change git-dir to $GIT_DIR and git-file to gitfile. Signed-off-by: Thomas Ackermann --- Documentation/git-rev-parse.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index c743469..14386ed 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -187,9 +187,9 @@ print a message to stderr and exit with nonzero status. Flags and parameters to be parsed. --resolve-git-dir :: - Check if is a valid git-dir or a git-file pointing to a valid - git-dir. If is a valid git-dir the resolved path to git-dir will - be printed. + Check if is a valid `$GIT_DIR` or a gitfile pointing to a valid + `$GIT_DIR`. If is a valid `$GIT_DIR` the resolved path to `$GIT_DIR` + will be printed. include::revisions.txt[] -- 1.8.0.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #2
Found by David and Junio: Inconsistent quoting within config.txt should be fixed in a separate patch. Signed-off-by: Thomas Ackermann --- Documentation/config.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 3652ee0..1bfbc7a 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1773,7 +1773,7 @@ pull.twohead:: The default merge strategy to use when pulling a single branch. push.default:: - Defines the action Git push should take if no refspec is given + Defines the action `git push` should take if no refspec is given on the command line, no refspec is configured in the remote, and no refspec is implied by any of the options given on the command line. Possible values are: -- 1.8.0.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: Aw: Re: [PATCH v3 3/6] Change 'git' to 'Git' whenever the whole system is referred to #2
> > I think we have waited long enough and as far as I recall we didn't > see any reports of misconversion or forgotten conversion, so I'll > squash the fixes parked on the topic branch, whose tip is at > bfb8e1eb6375afb (fixup! Change 'git' to 'Git' whenever the whole > system is referred to #4, 2013-01-22), and merge the result to > 'next' sometime tomorrow. > Here are my final fixups on top of bfb8e1eb6375afb: I morphed the remarks from Junio and David into patch form and also did the reverse check for wrong usage of 'Git' instead of 'git'. While doing the later I also noticed some small glitches and fixed them. Squash at your will. [PATCH 1/6] fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #2 [PATCH 2/6] fixup! fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #1 [PATCH 3/6] fixup! Documentation: avoid poor-man's small caps [PATCH 4/6] Fix places where 'Git' should be 'git [PATCH 5/6] Add a description for 'gitfile' to glossary [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error --- Thomas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
bin4LBRs7J_4W.bin Description: iso-8859-1
Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
On Fri, Feb 01, 2013 at 09:39:39AM +0100, Michael Haggerty wrote: > On 01/30/2013 09:31 PM, John Keeping wrote: > > On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote: > >> [...] maybe we should establish a small Python library of > >> compatibility utilities (like a small "six"). [...] > >> But I haven't had time to think of where to put such a library, how to > >> install it, etc. > > > > If we want to go that route, I think restructuring the > > "git_remote_helpers" directory and re-using its infrastructure for > > installing the "Git Python modules" would be the way to go. The > > directory structure would become something like this: > > > > git/ > > `-- python/ > > |-- Makefile# existing file pulled out of git_remote_helpers > > |-- < some new utility library > > > |-- git_remote_helpers > > | |-- __init__.py > > | |-- git > > | | |-- __init__.py > > | | |-- exporter.py > > | | |-- git.py > > | | |-- importer.py > > | | |-- non_local.py > > | | `-- repo.py > > | `-- util.py > > |-- setup.cfg # existing file pulled out of git_remote_helpers > > `-- setup.py# existing file pulled out of git_remote_helpers > > > > > > It looks like the GitPython project[1] as already taken the "git" module > > name, so perhaps we should use "git_core" if we do introduce a new > > module. > > > > [1] http://pypi.python.org/pypi/GitPython > > This sounds reasonable. But not all Python code will go under the > "python" subdirectory, right? For example, I am working on a Python > script that fits thematically under contrib/hooks. I was thinking of it as analagous with the "perl" directory that currently exists. So the "python" directory will contain library code but scripts can live wherever is most appropriate. One way of looking at it is: could the user want to have this installed for all available versions of Python? For a script, the answer is "no" because they will call it and it will just run. For libraries, you want them to be available with whatever Python interpreter you happen to be running (assuming that it is a version supported by the library). > OTOH (I'm thinking aloud here) it is probably a bad idea for a hook > script to depend on a Python module that is part of git itself. Doing > so would make the hook script depend on a particular version of git (or > at least a version with a compatible Python module). But users might be > reluctant to upgrade git just to install a hook script. I don't think such a dependency is a bad idea in the longer term. If a "Git Python library" is developed, then at some point most people who have Git installed will have some version of that library - it becomes a case of perhaps wanting to limit yourself to some subset of the library rather than just not using it. In fact, git_remote_helpers has been available since Git 1.7.0 and contains a lot of functionality that is more generic than its name suggests. John -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: Re: Re: Segmentation fault with latest git (070c57df)
>> [...] >> Finished prerequisites of target file `builtin/fetch.o'. >> Prerequisite `builtin/fetch.c' is older than target `builtin/fetch.o'. >> Prerequisite `GIT-CFLAGS' is older than target `builtin/fetch.o'. >> No need to remake target `builtin/fetch.o'. > >But it doesn't stimulate any prerequisites in make, which is weird. >What's in builtin/.depend/fetch.o.d? > >-Peff Hi, please see below~. $ cat builtin/.depend/fetch.o.d fetch.o: builtin/fetch.c cache.h git-compat-util.h compat/bswap.h \ strbuf.h hash.h advice.h gettext.h convert.h refs.h commit.h object.h \ tree.h decorate.h builtin.h cache.h commit.h notes.h string-list.h \ string-list.h remote.h transport.h remote.h run-command.h \ parse-options.h sigchain.h submodule.h connected.h argv-array.h cache.h: git-compat-util.h: compat/bswap.h: strbuf.h: hash.h: advice.h: gettext.h: convert.h: refs.h: commit.h: object.h: tree.h: decorate.h: builtin.h: cache.h: commit.h: notes.h: string-list.h: string-list.h: remote.h: transport.h: remote.h: run-command.h: parse-options.h: sigchain.h: submodule.h: connected.h: argv-array.h:
Re: Re: Re: Segmentation fault with latest git (070c57df)
On Fri, Feb 01, 2013 at 10:30:24AM +, Jongman Heo wrote: > Short answer; > > * Version of make is 3.81 on both machines > * builtin/fetch.o is not rebuilt (see entire log below) > * git works fine with "make all install COMPUTE_HEADER_DEPENDENCIES=no" OK, that gets us closer. It's definitely a problem with the automatic header dependencies, then. > [...make debug output...] > Reading makefile `builtin/.depend/fetch.o.d' (search path) (no ~ expansion)... So we definitely have the dep file... > [...] > Finished prerequisites of target file `builtin/fetch.o'. > Prerequisite `builtin/fetch.c' is older than target `builtin/fetch.o'. > Prerequisite `GIT-CFLAGS' is older than target `builtin/fetch.o'. > No need to remake target `builtin/fetch.o'. But it doesn't stimulate any prerequisites in make, which is weird. What's in builtin/.depend/fetch.o.d? -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] introduce a commit metapack
On Thu, Jan 31, 2013 at 06:06:56PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Wed, Jan 30, 2013 at 09:16:29PM +0700, Duy Nguyen wrote:
> > Perhaps we could store abbrev sha-1 instead of full sha-1. Nice
> > space/time trade-off.
>
> Following the on-disk format experiment yesterday, I changed the
> format to:
>
> - a list a _short_ SHA-1 of cached commits
> - a list of cache entries, each (5 uint32_t) consists of:
>- uint32_t for the index in .idx sha-1 table to get full SHA-1 of
> the commit
>- uint32_t for timestamp
>- uint32_t for tree, 1st and 2nd parents for the index in .idx
> table
BTW, I needed the minor fixups below to silence some warnings from your
patch. Here are the cold and warm cache timings I got, as compared to
stock git and my implementation:
Pack | Cold Revs | Warm Revs
---+--+
stock | 12.54| 4.14
me | 4.76 (-62%) | 0.66 (-84%)
duy | 4.36 (-65%) | 0.55 (-86%)
Not surprising; yours is just a bit faster in terms of CPU, and even
gains a little more in the cold cache case. Nice. Of course that is just
gravy on top of the smaller disk usage, too. :)
---
diff --git a/commit-metapack.c b/commit-metapack.c
index c984b8e..78fd961 100644
--- a/commit-metapack.c
+++ b/commit-metapack.c
@@ -106,7 +106,7 @@ int commit_metapack(unsigned char *sha1,
for (p = commit_metapacks; p; p = p->next) {
struct commit_entry *data;
uint32_t p1, p2;
- unsigned lo, hi, mi;
+ unsigned lo, hi;
int pos;
/* sha1_entry_pos does not work with abbreviated sha-1 */
@@ -161,7 +161,7 @@ static void get_commits(struct metapack_writer *mw,
struct write_cb *write_cb = (struct write_cb *)data;
enum object_type type = sha1_object_info(sha1, NULL);
struct commit *c;
- int p1, p2;
+ int p1 = -1, p2 = -1;
if (type != OBJ_COMMIT)
return;
diff --git a/commit.c b/commit.c
index b326201..5b776f8 100644
--- a/commit.c
+++ b/commit.c
@@ -309,7 +309,7 @@ static int parse_commit_metapack(struct commit *item)
static int parse_commit_metapack(struct commit *item)
{
- unsigned char *tree, *p1, *p2;
+ const unsigned char *tree, *p1, *p2;
uint32_t ts;
if (commit_metapack(item->object.sha1, &ts, &tree, &p1, &p2) < 0)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATH/RFC] Revert "compat: add strtok_r()"
On Fri, Feb 1, 2013 at 11:33 AM, Erik Faye-Lund wrote:
> This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc.
>
> commit 28c5d9e ("vcs-svn: drop string_pool") previously removed
> the only call-site for strtok_r. So let's get rid of the compat
> implementation as well.
>
> Conflicts:
> Makefile
> config.mak.in
> configure.ac
> ---
>
> I just noticed that we have an unused compat-implementation of strtok_r,
> so here's a patch to get rid of it.
>
Ugh, I forgot this part:
diff --git a/config.mak.uname b/config.mak.uname
index bea34f0..7f3018f 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -321,7 +321,6 @@ ifeq ($(uname_S),Windows)
NO_UNSETENV = YesPlease
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
- NO_STRTOK_R = YesPlease
NO_FNMATCH = YesPlease
NO_MEMMEM = YesPlease
# NEEDS_LIBICONV = YesPlease
@@ -476,7 +475,6 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_UNSETENV = YesPlease
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
- NO_STRTOK_R = YesPlease
NO_FNMATCH = YesPlease
NO_MEMMEM = YesPlease
NEEDS_LIBICONV = YesPlease
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATH/RFC] Revert "compat: add strtok_r()"
This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc.
commit 28c5d9e ("vcs-svn: drop string_pool") previously removed
the only call-site for strtok_r. So let's get rid of the compat
implementation as well.
Conflicts:
Makefile
config.mak.in
configure.ac
---
I just noticed that we have an unused compat-implementation of strtok_r,
so here's a patch to get rid of it.
Makefile | 6 --
compat/strtok_r.c | 61 ---
configure.ac | 6 --
git-compat-util.h | 5 -
4 files changed, 78 deletions(-)
delete mode 100644 compat/strtok_r.c
diff --git a/Makefile b/Makefile
index 1b30d7b..6d16a52 100644
--- a/Makefile
+++ b/Makefile
@@ -98,8 +98,6 @@ all::
#
# Define NO_MKSTEMPS if you don't have mkstemps in the C library.
#
-# Define NO_STRTOK_R if you don't have strtok_r in the C library.
-#
# Define NO_FNMATCH if you don't have fnmatch in the C library.
#
# Define NO_FNMATCH_CASEFOLD if your fnmatch function doesn't have the
@@ -1202,10 +1200,6 @@ endif
ifdef NO_STRTOULL
COMPAT_CFLAGS += -DNO_STRTOULL
endif
-ifdef NO_STRTOK_R
- COMPAT_CFLAGS += -DNO_STRTOK_R
- COMPAT_OBJS += compat/strtok_r.o
-endif
ifdef NO_FNMATCH
COMPAT_CFLAGS += -Icompat/fnmatch
COMPAT_CFLAGS += -DNO_FNMATCH
diff --git a/compat/strtok_r.c b/compat/strtok_r.c
deleted file mode 100644
index 7b5d568..000
--- a/compat/strtok_r.c
+++ /dev/null
@@ -1,61 +0,0 @@
-/* Reentrant string tokenizer. Generic version.
- Copyright (C) 1991,1996-1999,2001,2004 Free Software Foundation, Inc.
- This file is part of the GNU C Library.
-
- The GNU C Library is free software; you can redistribute it and/or
- modify it under the terms of the GNU Lesser General Public
- License as published by the Free Software Foundation; either
- version 2.1 of the License, or (at your option) any later version.
-
- The GNU C Library is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public
- License along with the GNU C Library; if not, write to the Free
- Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
- 02111-1307 USA. */
-
-#include "../git-compat-util.h"
-
-/* Parse S into tokens separated by characters in DELIM.
- If S is NULL, the saved pointer in SAVE_PTR is used as
- the next starting point. For example:
- char s[] = "-abc-=-def";
- char *sp;
- x = strtok_r(s, "-", &sp); // x = "abc", sp = "=-def"
- x = strtok_r(NULL, "-=", &sp); // x = "def", sp = NULL
- x = strtok_r(NULL, "=", &sp); // x = NULL
- // s = "abc\0-def\0"
-*/
-char *
-gitstrtok_r (char *s, const char *delim, char **save_ptr)
-{
- char *token;
-
- if (s == NULL)
-s = *save_ptr;
-
- /* Scan leading delimiters. */
- s += strspn (s, delim);
- if (*s == '\0')
-{
- *save_ptr = s;
- return NULL;
-}
-
- /* Find the end of the token. */
- token = s;
- s = strpbrk (token, delim);
- if (s == NULL)
-/* This token finishes the string. */
-*save_ptr = token + strlen (token);
- else
-{
- /* Terminate the token and make *SAVE_PTR point past it. */
- *s = '\0';
- *save_ptr = s + 1;
-}
- return token;
-}
diff --git a/configure.ac b/configure.ac
index 1991258..f3462d9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -901,12 +901,6 @@ GIT_CHECK_FUNC(strcasestr,
[NO_STRCASESTR=YesPlease])
GIT_CONF_SUBST([NO_STRCASESTR])
#
-# Define NO_STRTOK_R if you don't have strtok_r
-GIT_CHECK_FUNC(strtok_r,
-[NO_STRTOK_R=],
-[NO_STRTOK_R=YesPlease])
-GIT_CONF_SUBST([NO_STRTOK_R])
-#
# Define NO_FNMATCH if you don't have fnmatch
GIT_CHECK_FUNC(fnmatch,
[NO_FNMATCH=],
diff --git a/git-compat-util.h b/git-compat-util.h
index e5a4b74..89a44ab 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -408,11 +408,6 @@ extern uintmax_t gitstrtoumax(const char *, char **, int);
extern intmax_t gitstrtoimax(const char *, char **, int);
#endif
-#ifdef NO_STRTOK_R
-#define strtok_r gitstrtok_r
-extern char *gitstrtok_r(char *s, const char *delim, char **save_ptr);
-#endif
-
#ifdef NO_HSTRERROR
#define hstrerror githstrerror
extern const char *githstrerror(int herror);
--
1.8.0.msysgit.0.3.gd0186ec
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] introduce a commit metapack
On Thu, Jan 31, 2013 at 06:06:56PM +0700, Nguyen Thai Ngoc Duy wrote: > On Wed, Jan 30, 2013 at 09:16:29PM +0700, Duy Nguyen wrote: > > Perhaps we could store abbrev sha-1 instead of full sha-1. Nice > > space/time trade-off. > > Following the on-disk format experiment yesterday, I changed the > format to: > > - a list a _short_ SHA-1 of cached commits > - a list of cache entries, each (5 uint32_t) consists of: >- uint32_t for the index in .idx sha-1 table to get full SHA-1 of > the commit >- uint32_t for timestamp >- uint32_t for tree, 1st and 2nd parents for the index in .idx > table Thanks for working on this, as it was the next step I was going to take. :) The short-sha1 is a clever idea. Looks like it saves us on the order of 4MB for linux-2.6 (versus the full 20-byte sha1). Not as big as the savings we get from dropping the other 3 sha1's to uint32_t, but still not bad. I guess the next steps in iterating on this would be: 1. splitting out the refactoring here into separate patches 2. squashing the cleaned-up bits into my patch 4/6 3. deciding whether this should go into a separate file or as part of index v3. Your offsets depend on the .idx file having a sorted sha1 list. That is not likely to change, but it would still be nice to make sure they cannot get out of sync. I'm still curious what the performance impact is for mmap-ing N versus N+8MB. > The length of SHA-1 is chosen to be able to unambiguously identify any > cached commits. Full SHA-1 check is done after to catch false > positives. Just to be clear, these false positives come because the abbreviation is unambiguous within the packfile, but we might be looking for a commit that is not even in our pack, right? -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] introduce a commit metapack
On Wed, Jan 30, 2013 at 08:56:07PM +0700, Nguyen Thai Ngoc Duy wrote: > Another point, but not really important at this stage, I think we have > memory leak somewhere (lookup_commit??). It used up to 800 MB RES on > linux-2.6.git while generating the cache. We generate (and then leak!) the linked list in commit_metapack_write. That may be the culprit. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: Segmentation fault with latest git (070c57df)
On Fri, Feb 01, 2013 at 09:14:41AM +, Jongman Heo wrote: > I can reproduce the issue in my machine (RedHat Enterprise 5, x86 PAE) as > follows. Great, thanks for taking the time to reproduce. > But in my different machine (Fedora 16 x86) I can't reproduce. That makes me wonder if it is related to the gcc or make version. I couldn't reproduce the problem on my gcc-4.1 system, though. My make is: $ make --version GNU Make 3.81 [...] > $ git reset --hard v1.8.1 # back to v1.8.1 > $ make clean > $ make all install # this git works fine After this step, what does builtin/.depend/fetch.o.d contain? It should show a dependency of builtin/fetch.o on string-list (among other things). > $ git pull # top commit 9a6c84e6, "Merge > git://ozlabs.org/~paulus/gitk" > $ make all install Can you try running "make -d builtin/fetch.o" here instead of "make all install"? Can you confirm that it reads builtin/.depend/fetch.o, and that fetch.o gets rebuilt (you should even be able to see the list of "newer than" dependencies in the debug output)? Another thing to double-check: does it work if you instead run make all install COMPUTE_HEADER_DEPENDENCIES=no ? -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] introduce a commit metapack
On Thu, Jan 31, 2013 at 09:03:26AM -0800, Shawn O. Pearce wrote: > > Of course, it is more convenient to store this kind of things in a > > separate file while experimenting and improving the mechanism, but I > > do not think we want to see each packfile in a repository comes with > > 47 auxiliary files with different suffixes 5 years down the road. > > Agggh. > > Right now we are in the middle of refactoring the JGit reachability > bitmap implementation to store it into a separate file and get it out > of the .idx file. This work is nearly completed. So this thread is > great timing. :-) > > I think Junio is right about not wanting 47 different tiny auxiliary > files for a single pack. We are unlikely to create that many, but > right now there are proposals floating around for at least 2 new > auxiliary files (commit cache and reachability bitmaps). So its not > impossible that another will be discovered in the future. Why don't we want 47 files (or even 3)? If it makes the implementation more flexible or simple without sacrificing performance, I don't see a problem. The filesystem is there to organize our data; we do not cram all of our files into one just to save a few inodes. We _do_ cram our data into packfiles and packed-refs when we can save O(n) inodes. But if we are talking about a handful of extra files that we must readdir() over while preparing the objects/pack directory, I don't think that is the same thing. The data dependency issues (can the files get out of sync? How common is it? Can we detect it?) and performance issues are more interesting to me. With respect to the latter, here's specifically what I'm thinking of. Let's imagine we have an extension for reachability bitmaps that takes up an extra 10MB. When we mmap the .idx file, do we always mmap the extra bytes? What's the performance impact of the extra mmap? I recall on some non-Linux systems it can be quite expensive. For most git commands which are not going to do a reachability analysis, this is a loss. I don't know if this is an issue big enough to care about or not. But I think it's worth benchmarking and including in the decision. > Junio may be right about the hole in the index file for git-core. I > haven't checked the JGit implementation, but I suspect it does not > have this hole. IIRC JGit consumes the index sections and then expects > the pack trailer SHA-1 to be present immediately after the last table. > This happens because JGit doesn't use mmap() to load the index, it > streams the file into memory and does some reformatting on the tables > to make search faster. Yeah, looking at the PackIndexV2 implementation, it counts the 64-bit offsets from the first table, calculates the size of the large offset table, reads past it, and then expects the pack checksum. So let's assume we would have to bump to v3 to implement it inside the .idx file. > If we are going to change the index to support extension sections and > I have to modify JGit to grok this new format, it needs to be index v3 > not index v2. If we are making index v3 we should just put index v3 on > the end of the pack file. I'm not sure what you mean by your last sentence here. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] introduce a commit metapack
On Tue, Jan 29, 2013 at 11:17:41PM -0800, Junio C Hamano wrote: > > True, but it is even less headache if the file is totally separate and > > optional. > > Once you start thinking about using an offset to some list of SHA-1, > perhaps? A section inside the same file can never go out of sync. Yes, having a data dependency is important. It is unavoidable to have a dependency on the packfile, though (and that is why the index and the metapacks embed the sha1 of the packfile). If the offsets used are packfile offsets, then that is sufficient. If the offsets are from the index, then yes, putting it in the same file is one way to keep them tied together. Another way is to do the same sha1 verification, except to embed the sha1 of the index in the metapack. So I certainly consider putting the dependency-handling to be a point in favor of the same file, but I'd weight it against other points (headache of bumping index version, performance of both types, etc). > Also a longer-term advantage is that you can teach index-pack to do > this. I think that is roughly the same amount of difficulty to do whether they are in the same file or not. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: Segmentation fault with latest git (070c57df)
Junio C Hamano wrote : > 허종만 writes: >> But usually when I build upstream Linux kernel, I don't do "make >> clean" after git pull.. I didn't expect that I needed "make >> clean" for git build. > > We don't expect anybody need "make clean", either. There is > something wrong in the dependency. Hi all, I can reproduce the issue in my machine (RedHat Enterprise 5, x86 PAE) as follows. But in my different machine (Fedora 16 x86) I can't reproduce. $ git reset --hard v1.8.1 # back to v1.8.1 $ make clean $ make all install # this git works fine $ git pull # top commit 9a6c84e6, "Merge git://ozlabs.org/~paulus/gitk" $ make all install $ git fetch # this git segfaults Segmentation fault So if there is any patch to test, just let me know (but will not available during weekend). Regards, Jongman Heo
Re: [PATCH 0/2] optimizing pack access on "read only" fetch repos
On Thu, Jan 31, 2013 at 08:47:37AM -0800, Shawn O. Pearce wrote: > >> - System resource cost we incur by having to keep 50 file > >>descriptors open and maintaining 50 mmap windows will reduce by > >>50 fold. > > > > I wonder how measurable that is (and if it matters on Linux versus less > > efficient platforms). > > It does matter. We know it has a negative impact on JGit even on Linux > for example. You don't want 300 packs in a repository. 50 might be > tolerable. 300 is not. I'd love to see numbers if you have them. It's not that I don't believe it is slower, but knowing _how much_ is important when thinking about what kind of performance increase we are looking to get (which in turn impacts how much effort to put into the repacking). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/6] commit caching
On Thu, Jan 31, 2013 at 09:14:26AM -0800, Shawn O. Pearce wrote: > On Tue, Jan 29, 2013 at 1:14 AM, Jeff King wrote: > > This is the cleaned-up version of the commit caching patches I mentioned > > here: > > > > http://article.gmane.org/gmane.comp.version-control.git/212329 > ... > > The short of it is that for an extra 31M of disk > > space (~4%), I get a warm-cache speedup for "git rev-list --all" of > > ~4.2s to ~0.66s. > > I have to admit, this is a nice gain. I don't think users often dig > through all commits to the root but I can see how this might improve > git log with a path filter. It doesn't just help digging to the roots. It should speed up most traversals. So merge-bases, --contains, etc, would all be better. I suspect we could also make --topo-order startup a lot faster, too. It also helps "rev-list --objects --all", though obviously not by as large a percentage. And since the main use of that is reachability bitmaps, the improvements aren't as exciting there. > > Coupled with using compression level 0 for trees (which do not compress > > well at all, and yield only a 2% increase in size when left > > uncompressed), my "git rev-list --objects --all" time drops from ~40s to > > ~25s. > > This uhm is nice? > > But consider reachability bitmaps. ~40s to ~80ms. :-) Yeah, yeah. I'm working my way up to it. :) I wanted to see first how good we could get with a more generic approach. I think this work may still have value even with reachability bitmaps, as it will help regular traversals as well as tree access for pathspec limiting. At this point I'm convinced that my 25s is about the best we will do for reachability analysis with a graph traversal. The repeated hashcmps to see that we've visited each node are starting to dominate. So the next obvious step is to try reachability bitmaps. I was hoping to iron out the "pack metadata goes here" issues with the commit cache stuff, though, as the actual cache implementation is quite simple (whereas the bitmap stuff is more on the complex side, but can build on the same metadata base). > Yup. I have also futzed with the one in JGit for quite a while now. I > pull some tricks there like making it a 2 level directory to reduce > the need to find a contiguous array of 8M entries when processing the > Linux kernel, and I try to preallocate the first level table based on > the number of objects in pack-*.idx files. But the bottleneck is > basically the cache lookups and hits, these happen like 100M times on > 2M objects, because its every link in nearly every tree. Right. I tried some multi-level tricks (and even a radix trie), but I couldn't get anything to beat the simple-and-stupid single hash table with linear probing. > If we modified pack-objects' delta compressor for tree objects to only > generate delta instructions at tree record boundaries, a delta-encoded > tree can be processed without inflating the full content of that tree. > Because of the way deltas are created, "most" tree deltas should have > their delta base scanned by the object traversal before the delta is > considered. This means the tree delta just needs to consider the much > smaller records that are inserted into the base. We know these are > different SHA-1s than what was there before, so they are more likely > to be new to the lookup_object table. So sort of a magic shortcut tree diff you get while accessing the object. Neat idea. > So the --objects traversal algorithm can change to get the delta base > SHA-1 and raw tree delta from the pack storage. Perform a > lookup_object on the base to see if it has been scanned. If it has, > just scan the delta insert instructions. If the base has not yet been > scanned, inflate the tree to its normal format and scan the entire > tree. This would not perform well if we hit the deltas before the bases. In general, though, our "use the larger as the base" heuristic should mean that our traversal hits the bases first. > This is an approximation of what Nico and I were talking about doing > for pack v4. But doesn't require a file format change. :-) Yeah. It just needs to be very careful that the deltas it is looking at all fall on record boundaries, since we might get deltas generated by other versions of git. Can we necessarily identify that case for sure, though? I imagine a tree delta like that would look something like: delete bytes 100-120 add 20 bytes at offset 100: \x12\x34\x56... Without looking at the base object, and without knowing whether the delta was generated by our particular implementation, how can we be sure this is a sha1 replacement and not the renaming of part of a file? Or are you proposing some flag in the packfile to indicate "yes, this tree really was delta'd only at record boundaries"? It could be a big win, but it does seem quite complex and error-prone. And it only helps with reachability, not regular traversals, so it's not very generic. Which makes me think the bitmap route is a much
[BUG] git-clone fails due to GnuTLS recv error (-9), then deletes entire local repo
Using Ubuntu Precise 12.04 with git version (1.8.0.3) I discovered a bug whereby git-clone deletes the repository it has just created if there is a GnuTLS error after the final transfer. I switched to building and using the current git head (1.8.1.2.433.g070c57d.dirty) and found the same issue is still present. There are two problems here: 1. At the end of the transfer "GnuTLS recv error (-9): A TLS packet with unexpected length was received" 2. git-clone goes on to resolve deltas *then* deletes the entire repository This is reported as Ubuntu bug #882 at https://bugs.launchpad.net/ubuntu/+bug/882 The following transcript uses git built with one local patch on top of commit 070c57d which fixes the $(INSTALL) file mode issue as per my previous list posting "PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA". GIT_CURL_VERBOSE=1 git clone -v https://git01.codeplex.com/typescript the operation fails after the final git pack-file has been received and the already-created repository is deleted from the file system. ... > POST /typescript/git-upload-pack HTTP/1.1 User-Agent: git/1.8.1.2.433.g9808ce0.dirty Host: git01.codeplex.com Accept-Encoding: gzip Content-Type: application/x-git-upload-pack-request Accept: application/x-git-upload-pack-result Content-Length: 611 * upload completely sent off: 611out of 611 bytes < HTTP/1.1 200 OK < Cache-Control: no-cache, max-age=0, must-revalidate < Pragma: no-cache < Content-Type: application/x-git-upload-pack-result < Expires: Fri, 01 Jan 1980 00:00:00 GMT < Server: Microsoft-IIS/7.5 < X-Powered-By: ASP.NET < Date: Thu, 31 Jan 2013 21:43:55 GMT < Connection: close < remote: Counting objects: 149766, done. remote: Compressing objects: 100% (10580/10580), done. * GnuTLS recv error (-9): A TLS packet with unexpected length was received. * Closing connection #0 remote: Total 149766 (delta 138201), reused 149559 (delta 138077) Receiving objects: 100% (149766/149766), 198.98 MiB | 361 KiB/s, done. error: RPC failed; result=56, HTTP code = 200 Resolving deltas: 100% (138201/138201), done. git exits at this point but it deletes the entire cloned ./typescript directory. So far as I can tell from watching the ./typescript directory from another terminal and also the ethernet interface activity the transfer is complete but GnuTLS is expecting something more from the HTTPS server which isn't forthcoming, leading to the error. The git bug - if this is accepted as a bug - is the deletion of the entire cloned repository. I tried building the git binary and including an additional debug option in "http.c" that allowed me to set the protocol version using an environment option: CURLOPT_SSLVERSION=1 git clone ... where 1 = TLSv1, 2 = SSLv2, 3 = SSLv3. I tried each protocol but the result was the same. I did some experimentation using gnutl-cli-debug but was unable to figure out a way to reproduce the SSL/TLS error without this particular git-clone operation. However, that is a GnuTLS bug, not a git bug. I did try to build the latest gnutls but it needs a very recent version of libnettle which has the "rsa_decrypt_tr" function. I stopped at that point since I don't want to get into dependency and library version issues. Additional research seems to indicate this is a known intentional gnutls behaviour (that has been modified in very recent gnutls that makes use of a very recent libnettle - as mentioned above). The issue is, apparently, the random size padding of packets to prevent communications compromise for stream ciphers. I installed stunnel4 (which depends on openssl rather than gnutls) and created a reverse-proxy (client in stunnel terminology): $ cat /etc/stunnel/rp-codeplex.com.conf client = yes [http] accept = connect = git01.codeplex.com:443 TIMEOUTclose = 0 $ sudo sed -i 's/\(ENABLED\).*/\1=1/' /etc/default/stunnel4 $ sudo service stunnel4 restart $ GIT_CURL_VERBOSE=1 git clone -v http://localhost:/typescript ... > POST http://localhost:/typescript/git-upload-pack HTTP/1.1 User-Agent: git/1.8.1.2.433.g9808ce0.dirty Host: localhost: Accept-Encoding: gzip Proxy-Connection: Keep-Alive Content-Type: application/x-git-upload-pack-request Accept: application/x-git-upload-pack-result Content-Length: 611 * upload completely sent off: 611out of 611 bytes < HTTP/1.1 200 OK < Cache-Control: no-cache, max-age=0, must-revalidate < Pragma: no-cache < Content-Type: application/x-git-upload-pack-result < Expires: Fri, 01 Jan 1980 00:00:00 GMT < Server: Microsoft-IIS/7.5 < X-Powered-By: ASP.NET < Date: Thu, 31 Jan 2013 23:38:19 GMT < Connection: close < remote: Counting objects: 149798, done. remote: Compressing objects: 100% (10612/10612), done. remote: Total 149798 (delta 138221), reused 149558 (delta 138077) * Closing connection #0 Receiving objects: 100% (149798/149798), 198.99 MiB | 640 KiB/s, done. Resolving deltas: 100% (138221/138221), done. Checking out files: 100% (2851/2851), do
Re: [PATCH] Verify Content-Type from smart HTTP servers
On Thu, Jan 31, 2013 at 02:09:40PM -0800, Junio C Hamano wrote:
> Before parsing a suspected smart-HTTP response verify the returned
> Content-Type matches the standard. This protects a client from
> attempting to process a payload that smells like a smart-HTTP
> server response.
>
> JGit has been doing this check on all responses since the dawn of
> time. I mistakenly failed to include it in git-core when smart HTTP
> was introduced. At the time I didn't know how to get the Content-Type
> from libcurl. I punted, meant to circle back and fix this, and just
> plain forgot about it.
>
> Signed-off-by: Shawn Pearce
> Signed-off-by: Junio C Hamano
Should this be "From:" Shawn? The tone of the message and the S-O-B
order makes it look like it.
> @@ -133,16 +135,19 @@ static struct discovery* discover_refs(const char
> *service)
> last->buf = last->buf_alloc;
>
> if (maybe_smart && 5 <= last->len && last->buf[4] == '#') {
> - /* smart HTTP response; validate that the service
> + /*
> + * smart HTTP response; validate that the service
>* pkt-line matches our request.
>*/
> - struct strbuf exp = STRBUF_INIT;
> -
> + strbuf_addf(&exp, "application/x-%s-advertisement", service);
> + if (strbuf_cmp(&exp, &type))
> + die("invalid content-type %s", type.buf);
Hmm. I wondered if it is possible for a non-smart server to send us down
this code path, which would now complain of the bogus content-type.
Something like an info/refs file with:
# 1
# the comment above is meaningless, but puts a "#" at position 4.
But I note that we would already die in the next line:
> if (packet_get_line(&buffer, &last->buf, &last->len) <= 0)
> die("%s has invalid packet header", refs_url);
so I do not think the patch makes anything worse. However, should we
take this opportunity to make the "did we get a smart response" test
more robust? That is, should we actually be checking the content-type
in the outer conditional, and going down the smart code-path if it is
application/x-%s-advertisement, and otherwise treating the result as
dumb?
It's probably not a big deal, as the false positive example above is
quite specific and unlikely, but it just seems cleaner to me.
As a side note, should we (can we) care about the content-type for dumb
http? It should probably be text/plain or application/octet-stream, but
I would not be surprised if we get a variety of random junk in the real
world, though.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
On 01/30/2013 09:31 PM, John Keeping wrote: > On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote: >> [...] maybe we should establish a small Python library of >> compatibility utilities (like a small "six"). [...] >> But I haven't had time to think of where to put such a library, how to >> install it, etc. > > If we want to go that route, I think restructuring the > "git_remote_helpers" directory and re-using its infrastructure for > installing the "Git Python modules" would be the way to go. The > directory structure would become something like this: > > git/ > `-- python/ > |-- Makefile# existing file pulled out of git_remote_helpers > |-- < some new utility library > > |-- git_remote_helpers > | |-- __init__.py > | |-- git > | | |-- __init__.py > | | |-- exporter.py > | | |-- git.py > | | |-- importer.py > | | |-- non_local.py > | | `-- repo.py > | `-- util.py > |-- setup.cfg # existing file pulled out of git_remote_helpers > `-- setup.py# existing file pulled out of git_remote_helpers > > > It looks like the GitPython project[1] as already taken the "git" module > name, so perhaps we should use "git_core" if we do introduce a new > module. > > [1] http://pypi.python.org/pypi/GitPython This sounds reasonable. But not all Python code will go under the "python" subdirectory, right? For example, I am working on a Python script that fits thematically under contrib/hooks. OTOH (I'm thinking aloud here) it is probably a bad idea for a hook script to depend on a Python module that is part of git itself. Doing so would make the hook script depend on a particular version of git (or at least a version with a compatible Python module). But users might be reluctant to upgrade git just to install a hook script. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] docs: convert "concept" manpages to git-*
The manpages for commands have always been spelled
"git-cmd". But "concept" manpages, like "gitrevisions" were
spelled without the dash. This is complex, and does not
actually buy anything. You might think it creates a separate
namespace for concepts and commands, but "git help foo" will
prefer the command form, meaning we must avoid such
conflicts anyway.
Let's just call everything git-*, which is simpler. This
patch renames the documentation files, updates the Makefile
to find them, and updates internal linkgit references to the
pages. It updates builtin/help.c so that users of "git help
foo" will not even notice the difference.
Users of external html links, or users who have trained
their fingers to type "man gitfoo" will notice the missing
pages. This patch does not install a "this page has moved"
placeholder, but that can easily be done on top.
Signed-off-by: Jeff King
---
Documentation/Makefile | 27 +
Documentation/config.txt | 8 ++---
Documentation/diff-options.txt | 4 +--
Documentation/git-cat-file.txt | 2 +-
Documentation/git-check-ref-format.txt | 2 +-
Documentation/git-cherry-pick.txt | 2 +-
Documentation/{gitcli.txt => git-cli.txt} | 8 ++---
Documentation/git-commit.txt | 4 +--
...{gitcore-tutorial.txt => git-core-tutorial.txt} | 20 ++---
Documentation/git-credential-cache.txt | 2 +-
Documentation/git-credential-store.txt | 4 +--
.../{gitcredentials.txt => git-credentials.txt}| 6 ++--
...{gitcvs-migration.txt => git-cvs-migration.txt} | 22 +++---
Documentation/git-cvsimport.txt| 2 +-
Documentation/git-cvsserver.txt| 2 +-
Documentation/git-diff.txt | 6 ++--
.../{gitdiffcore.txt => git-diffcore.txt} | 6 ++--
Documentation/git-fast-import.txt | 2 +-
Documentation/git-format-patch.txt | 2 +-
Documentation/git-gc.txt | 2 +-
.../{gitglossary.txt => git-glossary.txt} | 12
Documentation/{githooks.txt => git-hooks.txt} | 6 ++--
Documentation/git-http-backend.txt | 2 +-
Documentation/git-log.txt | 2 +-
.../{gitnamespaces.txt => git-namespaces.txt} | 6 ++--
Documentation/git-push.txt | 2 +-
Documentation/git-rebase.txt | 4 +--
Documentation/git-receive-pack.txt | 2 +-
Documentation/git-reflog.txt | 2 +-
...sitory-layout.txt => git-repository-layout.txt} | 10 +++
Documentation/git-rev-parse.txt| 2 +-
Documentation/git-revert.txt | 2 +-
.../{gitrevisions.txt => git-revisions.txt}| 6 ++--
Documentation/git-show-branch.txt | 2 +-
Documentation/git-show-ref.txt | 2 +-
Documentation/git-show.txt | 2 +-
.../{gittutorial-2.txt => git-tutorial-2.txt} | 24 +++
.../{gittutorial.txt => git-tutorial.txt} | 24 +++
Documentation/git-update-server-info.txt | 2 +-
Documentation/git-upload-pack.txt | 2 +-
.../{gitworkflows.txt => git-workflows.txt}| 8 ++---
Documentation/git.txt | 35 +++---
Documentation/gitignore.txt| 2 +-
Documentation/gitk.txt | 2 +-
Documentation/gitweb.conf.txt | 2 +-
Documentation/technical/api-credentials.txt| 2 +-
Documentation/user-manual.txt | 14 -
builtin/help.c | 4 +--
48 files changed, 159 insertions(+), 159 deletions(-)
rename Documentation/{gitcli.txt => git-cli.txt} (98%)
rename Documentation/{gitcore-tutorial.txt => git-core-tutorial.txt} (99%)
rename Documentation/{gitcredentials.txt => git-credentials.txt} (98%)
rename Documentation/{gitcvs-migration.txt => git-cvs-migration.txt} (94%)
rename Documentation/{gitdiffcore.txt => git-diffcore.txt} (99%)
rename Documentation/{gitglossary.txt => git-glossary.txt} (61%)
rename Documentation/{githooks.txt => git-hooks.txt} (99%)
rename Documentation/{gitnamespaces.txt => git-namespaces.txt} (97%)
rename Documentation/{gitrepository-layout.txt => git-repository-layout.txt}
(97%)
rename Documentation/{gitrevisions.txt => git-revisions.txt} (88%)
rename Documentation/{gittutorial-2.txt => git-tutorial-2.txt} (96%)
rename Documentation/{gittutorial.txt => git-tutorial.txt} (97%)
rename Documentation/{gitworkflows.txt => git-workflows.txt} (99%)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 8e7939f..552cc37 100644
--- a/Documentation/Makefile
+++ b/Documentation/M
[PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
We keep a list of the various files that end up as man1, man5, etc. Let's break these single-line lists into sorted multi-line lists, which makes diffs that touch them much easier to read. Signed-off-by: Jeff King --- Documentation/Makefile | 33 - 1 file changed, 24 insertions(+), 9 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 971977b..8e7939f 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt -MAN1_TXT= \ - $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ - $(wildcard git-*.txt)) \ - gitk.txt gitweb.txt git.txt -MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \ - gitrepository-layout.txt gitweb.conf.txt -MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \ - gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \ - gitdiffcore.txt gitnamespaces.txt gitrevisions.txt gitworkflows.txt +MAN1_TXT += $(filter-out \ + $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ + $(wildcard git-*.txt)) +MAN1_TXT += git.txt +MAN1_TXT += gitk.txt +MAN1_TXT += gitweb.txt + +MAN5_TXT += gitattributes.txt +MAN5_TXT += githooks.txt +MAN5_TXT += gitignore.txt +MAN5_TXT += gitmodules.txt +MAN5_TXT += gitrepository-layout.txt +MAN5_TXT += gitweb.conf.txt + +MAN7_TXT += gitcli.txt +MAN7_TXT += gitcore-tutorial.txt MAN7_TXT += gitcredentials.txt +MAN7_TXT += gitcvs-migration.txt +MAN7_TXT += gitdiffcore.txt +MAN7_TXT += gitglossary.txt +MAN7_TXT += gitnamespaces.txt +MAN7_TXT += gitrevisions.txt +MAN7_TXT += gittutorial-2.txt +MAN7_TXT += gittutorial.txt +MAN7_TXT += gitworkflows.txt MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT) MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT)) -- 1.8.1.2.11.g1a2f572 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rename {git- => git}remote-helpers.txt
On Fri, Feb 01, 2013 at 02:33:52AM -0500, Jeff King wrote: > I am starting to think it has grown in an unnecessarily complex > direction, and we would be much happier just calling all of the > "concept" documentation "git-". > > The steps I see are: I am still undecided on whether it is a good idea (in some ways, I like that "gitrevisions" signals to the user that it is not a command; but I also recognize that it is more complex for users, and gitremote-helpers looks silly to me). But here is what the patch looks like, for reference. The first one is a cleanup we might want to take anyway, and the second one is the meat. [1/2]: Documentation/Makefile: clean up MAN*_TXT lists [2/2]: docs: convert "concept" manpages to git-* -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
