Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes
On 10/11/2012 07:55 AM, Johannes Sixt wrote: Am 10/10/2012 21:44, schrieb Junio C Hamano: Johannes Sixt j.s...@viscovery.net writes: Is there already an established definition which the correct .gitattributes are? No, and it is deliberately kept vague while waiting for us to come up with a clear definition of what is correct. ... Very often, people retroactively define attributes to correct earlier mistakes. Absolutely. I have Windows resource files that are Shift-JIS encoded checked in long ago, and I want to retoactively declare them with encoding=Shift-JIS because I prefer to see Japanese script in gitk rather than gibberish. Maybe I'm being too much of a purist, but I don't think that git should retroactively reinterpret history on its own initiative in a way that might not be correct (e.g., maybe your encoding changed from ASCII to Shift-JIS sometime in the past). It would be more appropriate for this to happen only if explicitly requested by the user. For example, why don't you override the incorrect historical attributes via .git/info/attributes? 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
Re: [PATCH v2 0/7] Tying loose ends on grep-pcre
On 10/10/2012 06:52 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: The last one teaches git log family to honor the grep.* configuration variables, e.g. grep.patterntype, so that you can say git -c grep.patterntype=perl log --grep='(?:pcre)'. Maybe this has been discussed already, but it seems to me that adding a persistent setting that affects how git log --grep interprets the pattern argument could break some scripts that assume that the old interpretation is always used. Shouldn't this at least be documented as a backwards incompatibility? If somebody scripts around log with hardcoded query --grep=... strings, they can force a particular variant from such a command line at the same time. But as always, responsibility of doing so is on the person who writes such a script; log being a Porcelain, we value ease-of-use in interactive case more than cast-in-stone interface stability like we do for plumbing commands. And that is exactly why the series avoids changing the behaviour for the rev-list plumbing. OK, you've convinced me. Thanks. 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
Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes
On Thu, Oct 11, 2012 at 2:04 PM, Michael Haggerty mhag...@alum.mit.edu wrote: Maybe I'm being too much of a purist, but I don't think that git should retroactively reinterpret history on its own initiative in a way that might not be correct (e.g., maybe your encoding changed from ASCII to Shift-JIS sometime in the past). It would be more appropriate for this to happen only if explicitly requested by the user. For example, why don't you override the incorrect historical attributes via .git/info/attributes? I think git-notes is a more appropriate place to correct these things. If the incorrect commits are pruned, their notes can also be pruned. No poluttion in $GIT_DIR/info/attr.. And i'm your side, no checking worktree without user's permission. -- Duy -- 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
[BUG] git commit after cherry-pick -n conflict clobbers .git/COMMIT_EDITMSG
(only tested with 1.7.10.x for now) ~/softs/linux$ echo foo .git/COMMIT_EDITMSG ~/softs/linux$ git cherry-pick -n b55f3d92cd error: could not apply b55f3d9... Linux 2.6.32.26 hint: after resolving the conflicts, mark the corrected paths hint: with 'git add paths' or 'git rm paths' ~/softs/linux$ cat .git/COMMIT_EDITMSG foo So far, so good. But then git commit brings me the message from the cherry-picked commit plus the list of conflicted files, and I can verify that it is now the contents of .git/COMMIT_EDITMSG. Surely the fact I passed -n should prevent cloberring the message, even in the event of a conflict. I suppose that would imply not creating .git/MERGE_MSG in that case, but just removing it still causes .git/COMMIT_EDITMSG to be clobbered, this time with nothing but the git status-derived comments. -- Yann Dirson - Bertin Technologies -- 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: rebase fails mid way through due to locally modified file?
skillz...@gmail.com: I frequently see rebase fail after applying several commits because git thinks there are local changes. What operating system are you running on? I have seen simlar issues on Windows, which has a case-insensitive file system, in repositories where file names have either changed just the casing of their names, or there has been several files where the only difference in names were only character casing. -- \\// Peter - http://www.softwolves.pp.se/ -- 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: push.default documented in man git-push?
On Fri, Oct 05, 2012 at 01:03:28PM -0700, Junio C Hamano wrote:
OK. I think I was surprised that some messages were controlled by
advice.* but gave no hints about that and I found that out by other
means. I'll check all the advice messages.
It's about the commands, not the documents. For example I had no idea
I could set advice.statusHints to turn off some advice. git status
does not say that those messages can be turned off.
OK, the messages are supposed to advise how to turn them off, so we
would want some code updates in that case.
Something like this? It turns out none of the advice messages says
anything about advice.*.
This patch makes many output more verbose/annoying, (which is good,
more motivation to turn advice off). On the other hand, if a user sees
a message telling her/him to turn advice.statusHints off, (s)he may
miss other helpful advice as it turns the whole set off. I don't know
if that is good or bad for newbies.
Tests are broken due to output changes. Will fix it if it may have a
chance of entering git.git.
There are two advise() calls in sequencer.c that we may want to
trigger with a new advice config, by the way.
-- 8 --
diff --git a/advice.c b/advice.c
index edfbd4a..5b78c01 100644
--- a/advice.c
+++ b/advice.c
@@ -70,7 +70,8 @@ int error_resolve_conflict(const char *me)
advise(_(Fix them up in the work tree,\n
and then use 'git add/rm file' as\n
appropriate to mark resolution and make a commit,\n
-or use 'git commit -a'.));
+or use 'git commit -a'.\n
+Set advice.resolveConflict to false to turn off this
message.));
return -1;
}
@@ -89,7 +90,9 @@ void detach_advice(const char *new_name)
state without impacting any branches by performing another
checkout.\n\n
If you want to create a new branch to retain commits you create, you
may\n
do so (now or later) by using -b with the checkout command again.
Example:\n\n
- git checkout -b new_branch_name\n\n;
+ git checkout -b new_branch_name\n
+ Set either advice.detachedHead to false to turn off this message\n\n
+;
fprintf(stderr, fmt, new_name);
}
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 781295b..a805961 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -699,7 +699,9 @@ static void suggest_reattach(struct commit *commit, struct
rev_info *revs)
_(
If you want to keep them by creating a new branch,
this may be a good time\nto do so with:\n\n
-git branch new_branch_name %s\n\n),
+git branch new_branch_name %s\n
+ Set either advice.detachedHead to false
+to turn off this message\n\n),
sha1_to_hex(commit-object.sha1));
}
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..5a4d85f 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -50,7 +50,8 @@ N_(Your name and email address were configured automatically
based\n
\n
After doing this, you may fix the identity used for this commit with:\n
\n
-git commit --amend --reset-author\n);
+git commit --amend --reset-author\n
+Set either advice.implicitIdentity to false to turn off this message\n);
static const char empty_amend_advice[] =
N_(You asked to amend the most recent commit, but doing so would make\n
diff --git a/builtin/merge.c b/builtin/merge.c
index 0ec8f0d..754f51e 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1227,14 +1227,18 @@ int cmd_merge(int argc, const char **argv, const char
*prefix)
*/
if (advice_resolve_conflict)
die(_(You have not concluded your merge (MERGE_HEAD
exists).\n
- Please, commit your changes before you can
merge.));
+ Please, commit your changes before you can
merge.\n
+ Set advice.resolveConflict to false
+ to turn off this message\n));
else
die(_(You have not concluded your merge (MERGE_HEAD
exists).));
}
if (file_exists(git_path(CHERRY_PICK_HEAD))) {
if (advice_resolve_conflict)
die(_(You have not concluded your cherry-pick
(CHERRY_PICK_HEAD exists).\n
- Please, commit your changes before you can
merge.));
+ Please, commit your changes before you can
merge.\n
+ Set advice.resolveConflict to false
+ to turn off this message\n));
else
die(_(You have not concluded your cherry-pick
(CHERRY_PICK_HEAD exists).));
}
diff --git a/builtin/push.c b/builtin/push.c
Re: [PATCH 1/3] quote: let caller reset buffer for quote_path_relative()
On Thu, Oct 11, 2012 at 4:13 AM, Junio C Hamano gits...@pobox.com wrote: This sounds a lot stronger than let to me. All existing callers that assumed that buf to be emptied by the function now has to clear it. quote: stop resetting output buffer of quote_path_relative() may better describe what this really does. How should this interact with the logic in the called function that used to say if we ended up returning an empty string because the path is the same as the base, we should give ./ back, and what should the return value of this function be? ... So what does it mean to have an existing string in the output buffer when calling the function? Is it supposed to be a path to a directory, or just a general uninterpreted string (e.g. a message)? I prefer the KISS principle in this case: do not interpret existing string. -- Duy -- 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: push.default documented in man git-push?
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Fri, Oct 05, 2012 at 01:03:28PM -0700, Junio C Hamano wrote: OK, the messages are supposed to advise how to turn them off, so we would want some code updates in that case. Something like this? It turns out none of the advice messages says anything about advice.*. Personally, I'm fine with the current situation. Advanced users can read the documentation, and for others, the messages are usually more helpful than annoying. This patch makes many output more verbose/annoying, For example, it makes the output of git status look like: # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # Set advice.statusHints to false to turn off this message # # modified: foo.txt # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # Set advice.statusHints to false to turn off this message # # modified: foo.txt # # Untracked files: # (use git add file... to include in what will be committed) # Set advice.statusHints to false to turn off this message # # bar.txt I think it's going really too far in verbosity, the actual information is hidden by the advices. (which is good, more motivation to turn advice off). I disagree. Having advices turned on doesn't harm anyone. I don't remember anyone complaining about the verbosity of Git's advices. I've seen *many* more people complaining about the user-unfriendliness of Git. I'm fine with very verbose (and scary) messages when the user did something wrong (for example, the advice.implicitIdentity is something you should never see if you configured Git properly before commiting). But the user should not feel blamed for using the default configuration of advice messages. The tripple repetition in git status shown above really sounds like hey, dumb user, why did you not set advice.statusHints already, and is doubly scary for newbies, because they are not told how to set the variable, nor what a config variable is to Git. I understand the motivation of making the advice.* section of man git-config more easily discoverable, but then picking a reasonable subset of the advice messages (e.g. places that are already verbose anyway, and not places that total beginners would see on a daily basis like git status) would be much better than targetting exhaustivity IMHO. @@ -89,7 +90,9 @@ void detach_advice(const char *new_name) state without impacting any branches by performing another checkout.\n\n If you want to create a new branch to retain commits you create, you may\n do so (now or later) by using -b with the checkout command again. Example:\n\n - git checkout -b new_branch_name\n\n; + git checkout -b new_branch_name\n + Set either advice.detachedHead to false to turn off this message\n\n ^^ Wrong cut-and paste from ... either XXX or YYY ...? (repeated several times below). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: push.default documented in man git-push?
On Thu, Oct 11, 2012 at 9:18 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: For example, it makes the output of git status look like: # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # Set advice.statusHints to false to turn off this message # # modified: foo.txt # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # Set advice.statusHints to false to turn off this message # # modified: foo.txt # # Untracked files: # (use git add file... to include in what will be committed) # Set advice.statusHints to false to turn off this message # # bar.txt And two more lines on my output: no changes added to commit (use git add and/or git commit -a) Set advice.statusHints to false to turn off this message I think it's going really too far in verbosity, the actual information is hidden by the advices. We could make it only one extra line in this case by prepending hint: before the advice and say you could turn the hints off by setting advice.statusHints at the end. Not applicable in general though. (which is good, more motivation to turn advice off). I disagree. Having advices turned on doesn't harm anyone. I don't remember anyone complaining about the verbosity of Git's advices. I've seen *many* more people complaining about the user-unfriendliness of Git. git status is actually quite verbose, but the advice only plays a part of it. So, not an actual complaint from me about the advice alone. - git checkout -b new_branch_name\n\n; + git checkout -b new_branch_name\n + Set either advice.detachedHead to false to turn off this message\n\n ^^ Wrong cut-and paste from ... either XXX or YYY ...? (repeated several times below). CutPaste mistake. -- Duy -- 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: rm and add, but not rename, of identical files
On Wed, 2012-10-10 at 14:47 -0700, Junio C Hamano wrote: Drew Northup drew.nort...@maine.edu writes: # Untracked files: # (use git add file... to include in what will be committed) # # rc.d/rc2.d/S08iptables # rc.d/rc3.d/S08iptables # rc.d/rc4.d/S08iptables ... no changes added to commit (use git add and/or git commit -a) It detects the changes as renames however―which in this case isn't appropriate: [root@drew-northup ~]# etckeeper vcs status # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # renamed:rc.d/rc2.d/K92iptables - rc.d/rc2.d/S08iptables # renamed:rc.d/rc3.d/K92iptables - rc.d/rc3.d/S08iptables # renamed:rc.d/rc4.d/K92iptables - rc.d/rc4.d/S08iptables #... Given that all of these six files have the same contents, I actually am slightly impressed how well Git matched them up ;-). But more seriously, why do you have rc.d/rc2.d/S08iptables untracked in the working tree but in the index to be committed? Missing steps in the mail body: etckeeper vcs add File etckeeper vcs rm File commands. I pared it back to the absolute minimum. Is that what you're asking about? -- -Drew Northup As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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
filter-branch IO optimization
Hi folks, for certain projects, I need to regularily run filter-branch on quite large repos (10k commits), and that needs to be run multiple times, which takes several hours, so I'm looking for optimizations. The main goal of this filtering is splitting out many modules from a large upstream repo into their own downstream repos. This process should be fully deterministic (IOW: running it twice at the same input, should produce exactly same output, so commit IDs stay the same after subsequent runs) My current approach is most likely yet a bit too naive: #1: forkoff new branch from current upstream #2: run a tree-filter which: * removes all files not belonging to the wanted module * move the module directory under another subdir (./addons/) * fix author/comitter name/email if empty (because otherwise fails) * fix charater sets and indentions of source files #3: loop through `git filter-branch --prune-empty` to get rid of empty merge nodes (which otherwise remain really a lot), until branch remains unchanged #4: run plain rebase onto initial commit to linearize the history All that is done is on per-module basis (for now only about 10, but soon can become much more). One thing I haven't tried yet is using the -d option to move the .git-rewrite dir to an tmpfs (have to clarify some operating considerations first) ;-o The next step I have in mind is using --subdirectory-filter, but open questsions are: * does it suffer from the same problems w/ empty username/email like --tree-filter ? ** if yes: what can I do about it (have an additional pass for fixing that before running the --tree-filter ? * can I somehow teach the --subdirectory filter to place the result under some somedir instead of directly to root ? * can I use --tree-filter in combination with --subdireectory-filter ? which one is executed first ? thanks -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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 v2 2/2] grep: stop looking at random places for .gitattributes
Johannes Sixt j.s...@viscovery.net writes: I saw EINVAL errors when 'git grep pattern rev' was run on Windows. The reason is that the code attempted to access rev:dir/.gitattributes in the worktree, which is an invalid path on Windows due to the colon. The lack of this warning indicates that the attempts to access these files are eliminated. It means that whenever we ask for attributes for a tracked file that is inside a directory whose name contains a colon, we would get the same error on Windows, no? Perhaps Windows may not let you create such a directory in the first place, but you may still get a repository of a cross platform project that contains such a path. What I am wondering is if we should do something similar to 8e950da (attr: failure to open a .gitattributes file is OK with ENOTDIR, 2012-09-13), at least on Windows, for EINVAL. -- 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 v4 00/12] Wildmatch v4
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Thu, Oct 11, 2012 at 11:33 AM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: Really small updates. I did not want to resend it this soon but this may fix the compile errors for Junio. t3070 seems to break TAP, *** prove *** t3070-wildmatch.sh .. Failed 1/151 subtests Test Summary Report --- t3070-wildmatch.sh (Wstat: 0 Tests: 150 Failed: 0) Parse errors: Tests out of sequence. Found (76) but expected (75) Tests out of sequence. Found (77) but expected (76) Tests out of sequence. Found (78) but expected (77) Tests out of sequence. Found (79) but expected (78) Tests out of sequence. Found (80) but expected (79) Displayed the first 5 of 77 TAP syntax errors. This probably is due to this part of the output: ok 72 - wildmatch 1 1 [ab] [\[:]ab] ok 73 - wildmatch 1 1 ?a?b \??\?b ok 74 - wildmatch 1 1 abc ^G^Hok 75 - wildmatch 0 0 foo ok 76 - wildmatch 1 0 foo/bar/baz/to **/t[o] ok 77 - wildmatch 1 1 a1B [[:alpha:]][[:digit:]][[:upper:]] It seems to prove fine here with perl 5.12.3, Test-Harness-3.230, bash-4.0_p38. What version do you use? I seem to have Perl 5.10.1, Test::Harness 3.17, Dash 0.5.5.1. But as you can see above, what is _fed_ to the Perl-side is broken (notice the concatenation at the end of ok 74), so I do not think versions of Perl-side matters. I suspect that this is the immediate culprit: match 1 1 'abc' '\a\b\c' The symptom looks like that somebody is interpreting \a as BEL, \b as backspace, etc. when showing the ok ... line, no? -- 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: push.default documented in man git-push?
Matthieu Moy matthieu@grenoble-inp.fr writes: Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Fri, Oct 05, 2012 at 01:03:28PM -0700, Junio C Hamano wrote: OK, the messages are supposed to advise how to turn them off, so we would want some code updates in that case. Something like this? It turns out none of the advice messages says anything about advice.*. Personally, I'm fine with the current situation. Advanced users can read the documentation, and for others, the messages are usually more helpful than annoying. OK, you convinced me. I disagree. Having advices turned on doesn't harm anyone. I don't remember anyone complaining about the verbosity of Git's advices. I've seen *many* more people complaining about the user-unfriendliness of Git. I'm fine with very verbose (and scary) messages when the user did something wrong (for example, the advice.implicitIdentity is something you should never see if you configured Git properly before commiting). But the user should not feel blamed for using the default configuration of advice messages. The tripple repetition in git status shown above really sounds like hey, dumb user, why did you not set advice.statusHints already, and is doubly scary for newbies, because they are not told how to set the variable, nor what a config variable is to Git. Let's let the list of advice.* messages in Documentation/config.txt do their job. Nguyen, thanks for taking a look. I do agree the extra here is how to rob helpful hints from yourself before you learn them seems to do more harm than good. -- 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/3] quote: let caller reset buffer for quote_path_relative()
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Thu, Oct 11, 2012 at 4:13 AM, Junio C Hamano gits...@pobox.com wrote: This sounds a lot stronger than let to me. All existing callers that assumed that buf to be emptied by the function now has to clear it. quote: stop resetting output buffer of quote_path_relative() may better describe what this really does. How should this interact with the logic in the called function that used to say if we ended up returning an empty string because the path is the same as the base, we should give ./ back, and what should the return value of this function be? ... So what does it mean to have an existing string in the output buffer when calling the function? Is it supposed to be a path to a directory, or just a general uninterpreted string (e.g. a message)? I prefer the KISS principle in this case: do not interpret existing string. Sorry, I do not quite understand what you mean. The original function is about turning one path into a path that is relative to the other path (e.g. make the result usable for chdir() when your cwd() is the other path to name that path), and because you do not want to end up with an empty path, it adds ./ to the result when the two paths are equal. That is simple and stupid, in the sense that you can explain in simple terms what it does even to a stupid person and make him understand. If a patch changes one aspect of the implementation of the function, but keeps other parts intact without thinking the ramifications of doing so through, and ends up giving the end result unnecessarily complex semantics, the _patch_ might be simple and stupid, but the end result is no longer simple. That is why I asked what it means to append and asked you to write it down for people who may need to decide if this function is an appropriate thing to call for their new code in the future. You didn't answer that question, so I have to ask again. What is the existing string this function appends its result to? - If it is a leading path (in other words, you are transplanting a hierarchy to somewhere else --- see and (re)read But if the caller did this instead part from the message you are responding to), because you do not want to end up with an empty path, it adds ./ to the result when the two paths are equal does not make sense at all. - If it is a message that describes the resulting relative path (the use case above that transplant example in the same message), it needs to add ./ to the result, but the logic to determine it now needs to take the length of what was in the buffer when the function was called into account. - Is there a third possibility? Whatever your answer is, please make sure the next person who wants to call this function from his code does not have to ask Why does it append ./ when out-len is zero? Shouldn't the condition be when *rel is an empty string? 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
Re: How can I tell if anything was fetched?
Phil Lawrence prlawre...@gmail.com writes:
One approach might be to first generate a state-of-the-repo SHA1:
# http://stackoverflow.com/a/7350019/834039
# http://git-scm.com/book/ch9-2.html
{
git rev-list --objects --all
git rev-list --objects -g --no-walk --all
git rev-list --objects --no-walk \
$(git fsck --unreachable |
grep '^unreachable commit' |
cut -d' ' -f3)
} | sort | uniq | git hash-object -w --stdin
I think you'd only need to record the state of all refs (eg. the output
of `git for-each-ref') to reliably detect any changes.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
--
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: rm and add, but not rename, of identical files
Drew Northup drew.nort...@maine.edu writes: On Wed, 2012-10-10 at 14:47 -0700, Junio C Hamano wrote: Drew Northup drew.nort...@maine.edu writes: # Untracked files: # (use git add file... to include in what will be committed) # # rc.d/rc2.d/S08iptables # rc.d/rc3.d/S08iptables # rc.d/rc4.d/S08iptables ... no changes added to commit (use git add and/or git commit -a) It detects the changes as renames however―which in this case isn't appropriate: [root@drew-northup ~]# etckeeper vcs status # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # renamed:rc.d/rc2.d/K92iptables - rc.d/rc2.d/S08iptables # renamed:rc.d/rc3.d/K92iptables - rc.d/rc3.d/S08iptables # renamed:rc.d/rc4.d/K92iptables - rc.d/rc4.d/S08iptables #... Given that all of these six files have the same contents, I actually am slightly impressed how well Git matched them up ;-). But more seriously, why do you have rc.d/rc2.d/S08iptables untracked in the working tree but in the index to be committed? Missing steps in the mail body: etckeeper vcs add File etckeeper vcs rm File commands. I pared it back to the absolute minimum. Is that what you're asking about? Yes. Without the add step, detecting the K92iptables that has been moved to an untracked S08iptables as rename looked like a magic (read: bug) to me, and that was why I asked. Aren't K92iptables and S08iptables the same script with case $1 in start) ... start thing ...;; stop) ... stop thing ...;; esac in it? On Debian, these S/K files appear directly under /etc without intermediate rc.d level, and they are symbolic links to real files in /etc/init.d/, so extrapolating from that knowledge and with a bit of imagination that some systems might keep copies of these files instead of linking to the same thing, I would actually find it desireable to call the move from K92iptables to S08iptables a rename, rather than reporting a removal and a addition of unrelated files. -- 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: [BUG] git commit after cherry-pick -n conflict clobbers .git/COMMIT_EDITMSG
Yann Dirson dir...@bertin.fr writes: (only tested with 1.7.10.x for now) ~/softs/linux$ echo foo .git/COMMIT_EDITMSG Why are you mucking with such an internal implementation detail in the first place? ~/softs/linux$ git cherry-pick -n b55f3d92cd error: could not apply b55f3d9... Linux 2.6.32.26 hint: after resolving the conflicts, mark the corrected paths hint: with 'git add paths' or 'git rm paths' ~/softs/linux$ cat .git/COMMIT_EDITMSG foo So far, so good. But then git commit brings me the message from the cherry-picked commit plus the list of conflicted files, and I can verify that it is now the contents of .git/COMMIT_EDITMSG. You verified that what is now in .git/COMMIT_EDITMSG? The commit log message for you to edit to record the result of the cherry-pick? If that is the case, what is the problem? If anything you had in .git/COMMIT_EDITMSG before you started 'cherry-pick -n', edit further to adjust, and then 'commit' sequence were to appear in the editor to edit the commit log, it would be a bug, I would think. -- 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 v4 00/12] Wildmatch v4
Junio C Hamano gits...@pobox.com writes:
This probably is due to this part of the output:
ok 72 - wildmatch 1 1 [ab] [\[:]ab]
ok 73 - wildmatch 1 1 ?a?b \??\?b
ok 74 - wildmatch 1 1 abc ^G^Hok 75 - wildmatch 0 0 foo
ok 76 - wildmatch 1 0 foo/bar/baz/to **/t[o]
ok 77 - wildmatch 1 1 a1B [[:alpha:]][[:digit:]][[:upper:]]
...
I suspect that this is the immediate culprit:
match 1 1 'abc' '\a\b\c'
The symptom looks like that somebody is interpreting \a as BEL, \b
as backspace, etc. when showing the ok ... line, no?
Ahh, it must be this bits from t/test-lib.sh
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git i/t/test-lib.sh w/t/test-lib.sh
index 514282c..489bc80 100644
--- i/t/test-lib.sh
+++ w/t/test-lib.sh
@@ -230,7 +230,7 @@ else
say_color() {
test -z $1 test -n $quiet return
shift
- echo $*
+ printf %s\n $*
}
fi
--
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 v2 0/8] Create single PDF for all HTML files
Hi, here is my reworked patch series for creating a single PDF for all git documentation files. Thanks to Junio Hamano, Philip Oakley and Jeff King for your comments! In general, the following problems had to be fixed in doc files in order to create HTML by using asciidoc and afterwards create a nice looking PDF using wkhtmltopdf: - Wrong sectioning syntax (e.g. === instead of ---) - Left-over shell scripting commands (in some release notes files) - Over-long lines which caused very wide right margins in the resulting PDF - Wrong formatting for email quotes, quoted script code, tables Also some of the headlines in the documents where changed or even created initially in order to give a more consistent structure in the resulting PDF. If you want to have a quick look on the resulting PDF just clone https://github.com/tacker66/git-docpdf.git. This repo contains a current version of user.manual.pdf and git-doc.pdf --- 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 v2 1/8] Split over-long synopsis in git-fetch-pack.txt into several lines
From 27b3105a374158fb8cb008c808a1ef94487a48f7 Mon Sep 17 00:00:00 2001 From: Thomas Ackermann th.ac...@arcor.de Date: Thu, 4 Oct 2012 19:11:43 +0200 Subject: [PATCH] Split over-long synopsis in git-fetch-pack.txt into several lines Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/git-fetch-pack.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index 474fa30..12cd8a2 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -9,7 +9,10 @@ git-fetch-pack - Receive missing objects from another repository SYNOPSIS [verse] -'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=git-upload-pack] [--depth=n] [--no-progress] [-v] [host:]directory [refs...] +'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] + [--upload-pack=git-upload-pack] + [--depth=n] [--no-progress] + [-v] [host:]directory [refs...] DESCRIPTION --- -- 1.7.11.msysgit.1 --- 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 v2 2/8] Shorten two over-long lines in git-bisect-lk2009.txt by removing some white-space
From e7c97695b676e1ebe66491b3ed256051b9a3b4f1 Mon Sep 17 00:00:00 2001 From: Thomas Ackermann th.ac...@arcor.de Date: Thu, 4 Oct 2012 19:11:43 +0200 Subject: [PATCH] Shorten two over-long lines in git-bisect-lk2009.txt by removing some white-space Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/git-bisect-lk2009.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt index 8a2ba37..80745d7 100644 --- a/Documentation/git-bisect-lk2009.txt +++ b/Documentation/git-bisect-lk2009.txt @@ -257,7 +257,7 @@ Date: Sat May 3 11:59:44 2008 -0700 Linux 2.6.26-rc1 -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile - At this point we can see what the commit does, check it out (if it's @@ -331,7 +331,7 @@ Date: Sat May 3 11:59:44 2008 -0700 Linux 2.6.26-rc1 -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile bisect run success - -- 1.7.11.msysgit.1 --- 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 v2 3/8] Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
From af1f0dc8e02ef178fc89f5fa3893a997a4a9b2eb Mon Sep 17 00:00:00 2001 From: Thomas Ackermann th.ac...@arcor.de Date: Tue, 9 Oct 2012 20:19:34 +0200 Subject: [PATCH] Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/technical/send-pack-pipeline.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/send-pack-pipeline.txt b/Documentation/technical/send-pack-pipeline.txt index 681efe4..9b5a0bc 100644 --- a/Documentation/technical/send-pack-pipeline.txt +++ b/Documentation/technical/send-pack-pipeline.txt @@ -1,5 +1,5 @@ -git-send-pack -= +Git-send-pack internals +=== Overall operation - -- 1.7.11.msysgit.1 --- 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 v2 4/8] Prerequisites for creating nice html for all files in Documentation/technical
From 23b5272cbb27dca7e292f33c79cf3d8e21298b78 Mon Sep 17 00:00:00 2001 From: Thomas Ackermann th.ac...@arcor.de Date: Sat, 29 Sep 2012 10:00:00 +0200 Subject: [PATCH] Prerequisites for creating nice html for all files in Documentation/technical - fix wrong asciidoc sectioning markup in index-format.txt, pack-format.txt and pack-protocol.txt - split an over-long line in pack-protocol.txt into several lines - add a markup box for definition part in shallow.txt - fix table markup in trivial-merge.txt Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/technical/index-format.txt | 2 +- Documentation/technical/pack-format.txt | 8 +++ Documentation/technical/pack-protocol.txt | 7 +++--- Documentation/technical/shallow.txt | 8 ++- Documentation/technical/trivial-merge.txt | 36 +++ 5 files changed, 34 insertions(+), 27 deletions(-) diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index 9d25b30..57d6f91 100644 --- a/Documentation/technical/index-format.txt +++ b/Documentation/technical/index-format.txt @@ -1,7 +1,7 @@ GIT index format -= The git index file has the following format +== The git index file has the following format All binary numbers are in network byte order. Version 2 is described here unless stated otherwise. diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt index 1803e64..a7871fb 100644 --- a/Documentation/technical/pack-format.txt +++ b/Documentation/technical/pack-format.txt @@ -1,7 +1,7 @@ GIT pack format === -= pack-*.pack files have the following format: +== pack-*.pack files have the following format: - A header appears at the beginning and consists of the following: @@ -34,7 +34,7 @@ GIT pack format - The trailer records 20-byte SHA1 checksum of all of the above. -= Original (version 1) pack-*.idx files have the following format: +== Original (version 1) pack-*.idx files have the following format: - The header consists of 256 4-byte network byte order integers. N-th entry of this table records the number of @@ -123,8 +123,8 @@ Pack file entry: + -= Version 2 pack-*.idx files support packs larger than 4 GiB, and - have some other reorganizations. They have the format: +== Version 2 pack-*.idx files support packs larger than 4 GiB, and + have some other reorganizations. They have the format: - A 4-byte magic number '\377tOc' which is an unreasonable fanout[0] value. diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index d51e20f..25e1fbe 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -117,7 +117,7 @@ A few things to remember here: - The repository path is always quoted with single quotes. Fetching Data From a Server -=== +--- When one Git repository wants to get data that a second repository has, the first can 'fetch' from the second. This operation determines @@ -134,7 +134,8 @@ with the object name that each reference currently points to. $ echo -e -n 0039git-upload-pack /schacon/gitbook.git\0host=example.com\0 | nc -v example.com 9418 - 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag + 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack +side-band side-band-64k ofs-delta shallow no-progress include-tag 00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration 003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master 003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9 @@ -421,7 +422,7 @@ entire packfile without multiplexing. Pushing Data To a Server - + Pushing data to a server will invoke the 'receive-pack' process on the server, which will allow the client to tell it which references it should diff --git a/Documentation/technical/shallow.txt b/Documentation/technical/shallow.txt index 559263a..0502a54 100644 --- a/Documentation/technical/shallow.txt +++ b/Documentation/technical/shallow.txt @@ -1,6 +1,12 @@ -Def.: Shallow commits do have parents, but not in the shallow +Shallow commits +=== + +.Definition +* +Shallow commits do have parents, but not in the shallow repo, and therefore grafts are introduced pretending that these commits have no parents. +* The basic idea is to write the SHA1s of shallow commits into $GIT_DIR/shallow, and handle its contents like the contents diff --git a/Documentation/technical/trivial-merge.txt b/Documentation/technical/trivial-merge.txt index 24c8410..c79d4a7 100644 ---
[Patch v2 6/8] Prerequisites for creating nice html for all files in Documentation/RelNotes
From cd7a26f5e7ba8cc42bf81e1b78f800460510b71f Mon Sep 17 00:00:00 2001 From: Thomas Ackermann th.ac...@arcor.de Date: Sat, 29 Sep 2012 11:00:00 +0200 Subject: [PATCH] Prerequisites for creating nice html for all files in Documentation/RelNotes - remove left-over shell-script fragments from some files Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/RelNotes/1.5.2.1.txt | 6 -- Documentation/RelNotes/1.6.0.2.txt | 6 -- Documentation/RelNotes/1.6.1.3.txt | 4 Documentation/RelNotes/1.6.1.4.txt | 3 --- Documentation/RelNotes/1.6.1.txt | 6 -- 5 files changed, 25 deletions(-) diff --git a/Documentation/RelNotes/1.5.2.1.txt b/Documentation/RelNotes/1.5.2.1.txt index ebf20e2..d41984d 100644 --- a/Documentation/RelNotes/1.5.2.1.txt +++ b/Documentation/RelNotes/1.5.2.1.txt @@ -45,9 +45,3 @@ Fixes since v1.5.2 - git-fastimport --import-marks was broken; fixed. - A lot of documentation updates, clarifications and fixes. - --- -exec /var/tmp/1 -O=v1.5.2-65-g996e2d6 -echo O=`git describe refs/heads/maint` -git shortlog --no-merges $O..refs/heads/maint diff --git a/Documentation/RelNotes/1.6.0.2.txt b/Documentation/RelNotes/1.6.0.2.txt index e1e24b3..7d8fb85 100644 --- a/Documentation/RelNotes/1.6.0.2.txt +++ b/Documentation/RelNotes/1.6.0.2.txt @@ -79,9 +79,3 @@ Fixes since v1.6.0.1 packfile. Also contains many documentation updates. - --- -exec /var/tmp/1 -O=v1.6.0.1-78-g3632cfc -echo O=$(git describe maint) -git shortlog --no-merges $O..maint diff --git a/Documentation/RelNotes/1.6.1.3.txt b/Documentation/RelNotes/1.6.1.3.txt index 6f0bde1..cd08d81 100644 --- a/Documentation/RelNotes/1.6.1.3.txt +++ b/Documentation/RelNotes/1.6.1.3.txt @@ -26,7 +26,3 @@ Fixes since v1.6.1.2 * RPM binary package installed the html manpages in a wrong place. Also includes minor documentation fixes and updates. - - --- -git shortlog --no-merges v1.6.1.2-33-gc789350.. diff --git a/Documentation/RelNotes/1.6.1.4.txt b/Documentation/RelNotes/1.6.1.4.txt index 0ce6316..ccbad79 100644 --- a/Documentation/RelNotes/1.6.1.4.txt +++ b/Documentation/RelNotes/1.6.1.4.txt @@ -39,6 +39,3 @@ Fixes since v1.6.1.3 This fix was first merged to 1.6.2.3. Also includes minor documentation fixes and updates. - --- -git shortlog --no-merges v1.6.1.3.. diff --git a/Documentation/RelNotes/1.6.1.txt b/Documentation/RelNotes/1.6.1.txt index adb7cca..7b152a6 100644 --- a/Documentation/RelNotes/1.6.1.txt +++ b/Documentation/RelNotes/1.6.1.txt @@ -278,9 +278,3 @@ release, unless otherwise noted. * gitweb did not mark non-ASCII characters imported from external HTML fragments correctly. - --- -exec /var/tmp/1 -O=v1.6.1-rc3-74-gf66bc5f -echo O=$(git describe master) -git shortlog --no-merges $O..master ^maint -- 1.7.11.msysgit.1 --- 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 v2 7/8] Create pdf from all html files
From 31f86526e0a0bd00be57db3275c860913f668fb8 Mon Sep 17 00:00:00 2001 From: Thomas Ackermann th.ac...@arcor.de Date: Mon, 1 Oct 2012 20:06:48 +0200 Subject: [PATCH] Create pdf from all html files - use wkhtmltopdf (patched QT version) to combine all html files into a single pdf file git-doc.pdf - insert page breaks to separate major sections Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/.gitignore | 1 + Documentation/footerend.txt | 4 Documentation/footerstart.txt | 7 ++ Documentation/makedocpdf.sh | 53 +++ Documentation/pagebreak.txt | 1 + 5 files changed, 66 insertions(+) create mode 100644 Documentation/footerend.txt create mode 100644 Documentation/footerstart.txt create mode 100755 Documentation/makedocpdf.sh create mode 100644 Documentation/pagebreak.txt diff --git a/Documentation/.gitignore b/Documentation/.gitignore index d62aebd..fba4730 100644 --- a/Documentation/.gitignore +++ b/Documentation/.gitignore @@ -10,3 +10,4 @@ howto-index.txt doc.dep cmds-*.txt manpage-base-url.xsl +docfiles.txt diff --git a/Documentation/footerend.txt b/Documentation/footerend.txt new file mode 100644 index 000..ed16923 --- /dev/null +++ b/Documentation/footerend.txt @@ -0,0 +1,4 @@ +/td + /tr +/table +/body/html diff --git a/Documentation/footerstart.txt b/Documentation/footerstart.txt new file mode 100644 index 000..a2746ef --- /dev/null +++ b/Documentation/footerstart.txt @@ -0,0 +1,7 @@ +html +head/head +body style=border:0; margin: 0; onload=subst() +table style=border-top: 1px solid black; width: 100% + tr +td class=section/td +td style=text-align:center diff --git a/Documentation/makedocpdf.sh b/Documentation/makedocpdf.sh new file mode 100755 index 000..5f1a2c1 --- /dev/null +++ b/Documentation/makedocpdf.sh @@ -0,0 +1,53 @@ +#!/bin/sh + +rm -f git-doc.pdf + +cat pagebreak.txt pagebreak.html + +cat /dev/null docfiles.txt + +ls gittutorial.htmldocfiles.txt +ls gittutorial-2.html docfiles.txt +ls everyday.html docfiles.txt +ls gitworkflows.html docfiles.txt + +ls pagebreak.html docfiles.txt +ls git.htmldocfiles.txt +ls git-a*.html docfiles.txt +ls git-bisect.html docfiles.txt +ls git-b[j-z]*.htmldocfiles.txt +ls git-[c-s]*.html docfiles.txt +ls git-ta*.htmldocfiles.txt +ls gitk.html docfiles.txt +ls git-[u-z]*.html docfiles.txt + +ls pagebreak.html docfiles.txt +ls gita*.html docfiles.txt +ls git-bisect-lk2009.html docfiles.txt +ls git[cdghimnr]*.html docfiles.txt +ls git-tools.html docfiles.txt +ls gitweb*.htmldocfiles.txt + +ls pagebreak.html docfiles.txt +ls howto-index.htmldocfiles.txt +ls howto/*.htmldocfiles.txt + +ls pagebreak.html docfiles.txt +ls technical/[b-z]*.html docfiles.txt + +ls pagebreak.html docfiles.txt +ls technical/api-index.htmldocfiles.txt +ls technical/api-[a-h]*.html docfiles.txt +ls technical/api-in-*.html docfiles.txt +ls technical/api-[j-z]*.html docfiles.txt + +ls pagebreak.html docfiles.txt +ls RelNotes/*.html docfiles.txt + +cat /dev/null footer.html + +cat footerstart.txtfooter.html +cat ../GIT-VERSION-FILEfooter.html +cat footerend.txt footer.html + +cat docfiles.txt | xargs cat | wkhtmltopdf --book --footer-html footer.html --disable-external-links - git-doc.pdf diff --git a/Documentation/pagebreak.txt b/Documentation/pagebreak.txt new file mode 100644 index 000..fdaffd1 --- /dev/null +++ b/Documentation/pagebreak.txt @@ -0,0 +1 @@ +/p style=page-break-after: always -- 1.7.11.msysgit.1 --- 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 v2 8/8] Wire everything into Makefile and Documentation/Makefile
From ac7de86bd58c5849c12e2b05e7b7f68704d9093e Mon Sep 17 00:00:00 2001 From: Thomas Ackermann th.ac...@arcor.de Date: Wed, 10 Oct 2012 19:30:55 +0200 Subject: [PATCH] Wire everything into Makefile and Documentation/Makefile - target html creates html for all files in Documentation/howto and Documentation/technical - new target relnoteshtml creates html for all release notes - new target fullpdf creates git-doc.pdf and uses targets html, relnoteshtml and pdf - html does not use relnoteshtml Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/Makefile | 43 +-- Makefile | 9 + 2 files changed, 50 insertions(+), 2 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 267dfe1..6710325 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -15,6 +15,9 @@ MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT)) DOC_HTML=$(MAN_HTML) +RELNOTES_TXT = $(wildcard RelNotes/*.txt) +RELNOTES_HTML= $(patsubst %.txt,%.html,$(RELNOTES_TXT)) + ARTICLES = howto-index ARTICLES += everyday ARTICLES += git-tools @@ -24,8 +27,30 @@ SP_ARTICLES = user-manual SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request +SP_ARTICLES += howto/use-git-daemon +SP_ARTICLES += howto/update-hook-example +SP_ARTICLES += howto/setup-git-server-over-http +SP_ARTICLES += howto/separating-topic-branches +SP_ARTICLES += howto/revert-a-faulty-merge +SP_ARTICLES += howto/recover-corrupted-blob-object +SP_ARTICLES += howto/rebuild-from-update-hook +SP_ARTICLES += howto/rebuild-from-update-hook +SP_ARTICLES += howto/rebase-from-internal-branch +SP_ARTICLES += howto/maintain-git API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) SP_ARTICLES += $(API_DOCS) + +TECH_DOCS += technical/index-format +TECH_DOCS += technical/pack-format +TECH_DOCS += technical/pack-heuristics +TECH_DOCS += technical/pack-protocol +TECH_DOCS += technical/protocol-capabilities +TECH_DOCS += technical/protocol-common +TECH_DOCS += technical/racy-git +TECH_DOCS += technical/send-pack-pipeline +TECH_DOCS += technical/shallow +TECH_DOCS += technical/trivial-merge +SP_ARTICLES += $(TECH_DOCS) SP_ARTICLES += technical/api-index DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES)) @@ -156,6 +181,8 @@ all: html man html: $(DOC_HTML) +relnoteshtml: $(RELNOTES_HTML) + $(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7): asciidoc.conf man: man1 man5 man7 @@ -167,6 +194,9 @@ info: git.info gitman.info pdf: user-manual.pdf +fullpdf: pdf relnoteshtml html + ./makedocpdf.sh + install: install-man install-man: man @@ -191,6 +221,10 @@ install-pdf: pdf $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir) $(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir) +install-fullpdf: fullpdf install-pdf + $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir) + $(INSTALL) -m 644 git-doc.pdf $(DESTDIR)$(pdfdir) + install-html: html '$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir) @@ -230,8 +264,10 @@ clean: $(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 $(RM) *.texi *.texi+ *.texi++ git.info gitman.info $(RM) *.pdf + $(RM) docfiles.txt + $(RM) RelNotes/*.html $(RM) howto-index.txt howto/*.html doc.dep - $(RM) technical/api-*.html technical/api-index.txt + $(RM) technical/*.html technical/api-index.txt $(RM) $(cmds_txt) *.made $(RM) manpage-base-url.xsl @@ -241,6 +277,9 @@ $(MAN_HTML): %.html : %.txt $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $ \ mv $@+ $@ +$(RELNOTES_HTML): %.html : %.txt + $(QUIET_ASCIIDOC)$(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 $*.txt + manpage-base-url.xsl: manpage-base-url.xsl.in sed s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)| $ $@ @@ -264,7 +303,7 @@ technical/api-index.txt: technical/api-index-skel.txt \ $(QUIET_GEN)cd technical '$(SHELL_PATH_SQ)' ./api-index.sh technical/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../ -$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt +$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : %.txt $(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt diff --git a/Makefile b/Makefile index 8413606..0392782 100644 --- a/Makefile +++ b/Makefile @@ -2479,12 +2479,18 @@ man: html: $(MAKE) -C Documentation html +relnoteshtml: + $(MAKE) -C Documentation relnoteshtml + info: $(MAKE) -C Documentation info pdf: $(MAKE) -C Documentation pdf +fullpdf: + $(MAKE) -C Documentation fullpdf + XGETTEXT_FLAGS = \ --force-po \ --add-comments \ @@ -2796,6 +2802,9 @@ install-info: install-pdf:
RE: A basic question
Drew, Thanks for responding to my email! Yes, I did read most of the Book, although I admit that I skimmed over some of the more technical parts. There is still a key part of how git is used in a commercial environment which I don't understand. When we release a new version of our product, it is comprised of over a hundred files. Some of these files have not changed for years, and some have been revised/fixed/updated quite recently. But what is key is that all of these components have passed a review and testing process. A very important piece of information is what revision of each file made it into the release. I know that git takes snapshots of the repository as changes are made and that it is possible to reconstruct the file set at any point in time. But unless rules or conventions are established, at any time the repository can contain files which are in the process of being modified and thus have not passed the testing process. For the purpose of planning a release, we're interested only in the most recently tested and approved files. For the sake of argument, I'll assume that a committing a change implies that the file has passed the testing process. So my questions are: 1) Does git have a built-in way to get a list of all of the most recently committed files only at a given point in time, thus automatically recording the revisions of all of the component files of a release? This implies that for files which are being modified or which have been staged but not committed, that git would go back to find the predecessor file which had been committed. 2) Does git have a way of creating and exporting a list of the most recently committed files only? 3) If the answer to the above questions is No, then what is the normal way for a programming shop which is using git to extract/assemble the list of approved files for building a release? Thank you. Jim Vahl -Original Message- From: Drew Northup [mailto:drew.nort...@maine.edu] Sent: Wednesday, October 10, 2012 12:37 PM To: Jim Vahl Cc: git@vger.kernel.org; 'Skot Davis' Subject: Re: A basic question On Wed, 2012-10-10 at 11:03 -0700, Jim Vahl wrote: All, Our company is researching version control software, something which we have not used previously. I have a very basic question about git which I have not been able to answer from reading. As I understand it, a git repository can be a mixture of files which are under development, staged or committed. If we make a new build of our product we will obviously only want to include the committed (tested) files. The question is this: what is the usual procedure to retrieve a set of committed files only from the repository to place into a distribution or ready to build folder. The same question goes for tagging a release: how does the user get the tag to reference the committed files only and not the most recent files which may be under development or undergoing testing. Thanks, Jim Vahl Jim, Have you looked at http://git-scm.com/book yet? It sounds to me like you have some misconceptions about how Git works. (If so, did it leave you more or less confused?) -- -Drew Northup As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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: git 1.8.0.rc0.18.gf84667d trouble with git commit -p file
Conrad Irwin conrad.ir...@gmail.com writes: -i:: --include:: - Before making a commit out of staged contents so far, - stage the contents of paths given on the command line - as well. This is usually not what you want unless you - are concluding a conflicted merge. + In addition to the paths specified on the command line, + include the current contents of the index in the commit. commit is about committing what is in the index. include has always meant in addition, include the contents of listed paths in the resulting commit. The updated text looks totally the other way around. -o:: --only:: - Make a commit only from the paths specified on the - command line, disregarding any contents that have been - staged so far. This is the default mode of operation of - 'git commit' if any paths are given on the command line, - in which case this option can be omitted. - If this option is specified together with '--amend', then - no paths need to be specified, which can be used to amend - the last commit without committing changes that have - already been staged. + Only commit changes to the paths specified on the command line, + do not include the current contents of the index. This is + the default mode of operation when paths are specified. + If this option is specified with --amend it can be used + to reword the last commit without changing its contents. + This mode cannot be used with --patch or --interactive. The new text on this one does look cleaner and easier to read, at least to me, but do not include the current contents sounds as if you are recording a tree that only has Makefile and losing all the other files when you say git commit Makefile. Disregard what has been added to the index since HEAD, and only commit changes to the given paths. might be an improvement, but I dunno. -- 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: How can I tell if anything was fetched?
I think you'd only need to record the state of all refs (eg. the output of `git for-each-ref') to reliably detect any changes. I would just record the output of `git ls-remote . | sort -u` somewhere and compare it next time (maybe you even wanna grep for the desired ref namespaces). cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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: filter-branch IO optimization
Am 11.10.2012 17:39, schrieb Enrico Weigelt: The main goal of this filtering is splitting out many modules from a large upstream repo into their own downstream repos. ... The next step I have in mind is using --subdirectory-filter, but open questsions are: * does it suffer from the same problems w/ empty username/email like --tree-filter ? I think so. ** if yes: what can I do about it (have an additional pass for fixing that before running the --tree-filter ? Use --env-filter. * can I somehow teach the --subdirectory filter to place the result under some somedir instead of directly to root ? No, but see the last example in the man page. * can I use --tree-filter in combination with --subdireectory-filter ? which one is executed first ? Yes. --subdirectory-filter applies first. -- Hannes -- 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: A basic question
The way you typically work with git (and with most other version control systems) is that you have a fast changing trunk (in git often called the master), where development is done. Once you want to release you create a release branch off the trunk, and in that branch you do regression testing and stability testing, and once you are convinced that stability has been achieved, you make your release. In parallel, and without in any way influencing your release branch, your programmers happily commit to the trunk. See e.g. the following excellent description of some workflow models: http://nvie.com/posts/a-successful-git-branching-model/ Regards, Dov On Thu, Oct 11, 2012 at 7:38 PM, Jim Vahl j...@wmdb.com wrote: Drew, Thanks for responding to my email! Yes, I did read most of the Book, although I admit that I skimmed over some of the more technical parts. There is still a key part of how git is used in a commercial environment which I don't understand. When we release a new version of our product, it is comprised of over a hundred files. Some of these files have not changed for years, and some have been revised/fixed/updated quite recently. But what is key is that all of these components have passed a review and testing process. A very important piece of information is what revision of each file made it into the release. I know that git takes snapshots of the repository as changes are made and that it is possible to reconstruct the file set at any point in time. But unless rules or conventions are established, at any time the repository can contain files which are in the process of being modified and thus have not passed the testing process. For the purpose of planning a release, we're interested only in the most recently tested and approved files. For the sake of argument, I'll assume that a committing a change implies that the file has passed the testing process. So my questions are: 1) Does git have a built-in way to get a list of all of the most recently committed files only at a given point in time, thus automatically recording the revisions of all of the component files of a release? This implies that for files which are being modified or which have been staged but not committed, that git would go back to find the predecessor file which had been committed. 2) Does git have a way of creating and exporting a list of the most recently committed files only? 3) If the answer to the above questions is No, then what is the normal way for a programming shop which is using git to extract/assemble the list of approved files for building a release? Thank you. Jim Vahl -Original Message- From: Drew Northup [mailto:drew.nort...@maine.edu] Sent: Wednesday, October 10, 2012 12:37 PM To: Jim Vahl Cc: git@vger.kernel.org; 'Skot Davis' Subject: Re: A basic question On Wed, 2012-10-10 at 11:03 -0700, Jim Vahl wrote: All, Our company is researching version control software, something which we have not used previously. I have a very basic question about git which I have not been able to answer from reading. As I understand it, a git repository can be a mixture of files which are under development, staged or committed. If we make a new build of our product we will obviously only want to include the committed (tested) files. The question is this: what is the usual procedure to retrieve a set of committed files only from the repository to place into a distribution or ready to build folder. The same question goes for tagging a release: how does the user get the tag to reference the committed files only and not the most recent files which may be under development or undergoing testing. Thanks, Jim Vahl Jim, Have you looked at http://git-scm.com/book yet? It sounds to me like you have some misconceptions about how Git works. (If so, did it leave you more or less confused?) -- -Drew Northup As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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: A basic question
1) Does git have a built-in way to get a list of all of the most recently committed files only at a given point in time, thus automatically recording the revisions of all of the component files of a release? There is no concept of per-file revisions in git. But you can check which ones are changed in multiple ways, eg: * per commit, commit-range or per-branch level - see git-log manpage * between arbitratry commints - see git-diff manpage This implies that for files which are being modified or which have been staged but not committed, that git would go back to find the predecessor file which had been committed. Forget about the staging issue (index) at this point - it's just existing in the _local_ clone (eg of some individual developer), for your usecase you're only interested in what's actually committed to certain branch(es). cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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 v2 5/8] Prerequisites for creating nice html for all files in Documentation/howto
Thomas Ackermann th.acke...@arcor.de writes:
From 2b9538990e30ae097c8e3d8b6891c9de31cf Mon Sep 17 00:00:00 2001
From: Thomas Ackermann th.ac...@arcor.de
Date: Sat, 29 Sep 2012 17:28:54 +0200
Subject: [PATCH] Prerequisites for creating nice html for all files in
Documentation/howto
These four lines are not needed; please remove them from all the patches.
@@ -149,13 +152,13 @@ then
info Found matching head pattern: '$head_pattern'
for group_pattern in $group_patterns; do
- for groupname in $groups; do
- info Checking group: '$groupname' against pattern: '$group_pattern'
- matchlen=$(expr $groupname : $group_pattern)
- if test $matchlen = ${#groupname}
- then
- grant Allowing group: '$groupname' with pattern: '$group_pattern'
- fi
+ for groupname in $groups; do
+ info Checking group: '$groupname' against pattern:
'$group_pattern'
+ matchlen=$(expr $groupname : $group_pattern)
+ if test $matchlen = ${#groupname}
+ then
+ grant Allowing group: '$groupname' with pattern:
'$group_pattern'
+ fi
done
done
The inner done does not seem to align with the for ...; do it
corresponds to, does 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 v2 2/8] Shorten two over-long lines in git-bisect-lk2009.txt by removing some white-space
Thomas Ackermann th.acke...@arcor.de writes: @@ -331,7 +331,7 @@ Date: Sat May 3 11:59:44 2008 -0700 Linux 2.6.26-rc1 -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile bisect run success - If you are redoing this as more like a printed book for easier reading, it might make more sense to shorten it like this: :100644 100644 5cf82581... 4492984e... M Makefile -- 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
[ANNOUNCE] Git v1.8.0-rc2
A release candidate Git v1.8.0-rc2 is now available for testing at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 6c8076b3bcf08ffc53a64bbfb0fa69f82096f711 git-1.8.0.rc2.tar.gz 86aca88717928d9d3a38c47a315d2c57402747ca git-htmldocs-1.8.0.rc2.tar.gz f4023824ee6b3ad561dba5dbdfe6e07532904a27 git-manpages-1.8.0.rc2.tar.gz Also the following public repositories all have a copy of the v1.8.0-rc2 tag and the master branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Things seem to have calmed down and hopefully we can have the final 1.8.0 without regression soon. Changes since v1.8.0-rc1 are as follows: Ben Walton (1): tests: cp -a is a GNUism Jonathan Nieder (2): git svn: work around SVN 1.7 mishandling of svn:special changes svn test: escape peg revision separator using empty peg rev Junio C Hamano (2): gitcli: parse-options lets you omit tail of long options Git 1.8.0-rc2 Nguyễn Thái Ngọc Duy (2): gitignore.txt: suggestions how to get literal # or ! at the beginning attr: a note about the order of .gitattributes lookup Ramkumar Ramachandra (1): Git url doc: mark ftp/ftps as read-only and deprecate them Ramsay Allan Jones (1): MALLOC_CHECK: Allow checking to be disabled from config.mak Simon Ruderich (1): l10n: de.po: fix a few minor typos Øyvind A. Holm (1): configure.ac: Add missing comma to CC_LD_DYNPATH -- 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: filter-branch IO optimization
Enrico Weigelt enrico.weig...@vnc.biz writes:
for certain projects, I need to regularily run filter-branch on quite
large repos (10k commits), and that needs to be run multiple times,
which takes several hours, so I'm looking for optimizations.
[...]
#2: run a tree-filter which:
* removes all files not belonging to the wanted module
* move the module directory under another subdir (./addons/)
* fix author/comitter name/email if empty (because otherwise fails)
The usual advice is use an index-filter instead. It's *much* faster
than a tree filter. However:
* fix charater sets and indentions of source files
That last step is rather crazy. At the very least you will want to only
operate on files that were changed since the parent commit, so as to
avoid scanning the whole tree. If you do this right, it should also fit
into an index-filter.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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: [BUG] git commit after cherry-pick -n conflict clobbers .git/COMMIT_EDITMSG
~/softs/linux$ echo foo .git/COMMIT_EDITMSG Why are you mucking with such an internal implementation detail in the first place? I only tried to make it terse for the bugreport, I hit this while I was resolving conflicts during a merge. I aknowledge that using cherry-pick -n to bring some contents to resolve a conflict is not really nominal - my use case involves re-merging an updated upstream branch, and bringing in fixups to the original merge. ~/softs/linux$ git cherry-pick -n b55f3d92cd error: could not apply b55f3d9... Linux 2.6.32.26 hint: after resolving the conflicts, mark the corrected paths hint: with 'git add ' or 'git rm ' ~/softs/linux$ cat .git/COMMIT_EDITMSG foo So far, so good. But then git commit brings me the message from the cherry-picked commit plus the list of conflicted files, and I can verify that it is now the contents of .git/COMMIT_EDITMSG. You verified that what is now in .git/COMMIT_EDITMSG? The commit log message for you to edit to record the result of the cherry-pick? Precisely If that is the case, what is the problem? I used -n precisely because I did not want to make a standalone commit, and the message from the cherry-picked source has no value to me. If it had, I would instead have used cherry-pick without -n, and amended the commit afterwards. In the general case, I only ever use -n when I'm squashing changes and similar tasks. Are there use cases out there, where it makes sense to keep that source message, when we don't want the commit to be created right away ? If anything you had in .git/COMMIT_EDITMSG before you started 'cherry-pick -n', edit further to adjust, and then 'commit' sequence were to appear in the editor to edit the commit log, it would be a bug, I would think. Well, seems to depend on use case - I find it a bug when the merge message, notably containing the list of conflicting files, gets clobbered. Also, I have not checked how git gui reacts, but I would assume that when carefully and iteratively composing a commit message from there, which is IIRC managed using .git/COMMIT_EDITMSG, it would not be desired to get this content clobbered the same way. To me it looks like the problem is that the commit message in preparation is not considered precious information, when there are at least some cases where it indeed should be. I'm not sure however how that should be done: * suddenly claiming it is precious (and require some form of -f to clobber it) when it was mostly not is likely to break a number of use cases * looking at the context (are we resolving a merge or similar ?) to consider it precious is likely to miss some cases * declaring a new official location (or API/command ?) to store considered-precious message being composed may bring its own lot of semantic difficulties -- 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: build deps
On Mon, Oct 8, 2012 at 7:52 PM, Andrew Wong andrew.k...@gmail.com wrote: On 10/08/12 17:36, Thiago Farina wrote: OK, after running ./configure I tried the make command again. CC credential-store.o /bin/sh: clang: not found make: *** [credential-store.o] Error 127 $ which clang /home/tfarina/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang $ clang --version clang version 3.2 (trunk 163674) Target: x86_64-unknown-linux-gnu Thread model: posix Looks like something went wrong with make setting PATH. I wonder if the + sign in your path is somehow messing things up. Would be something that could be fixed in git? Are you trying to compile specifically with clang? Nope, it just happen that I switched to clang because I use it to compile chromium and I need it to use the chrome_plugin[1]. If not, maybe try unsetting the CC env var, and run configure again? Just setting CC to gcc works for me. But still, I'd like to be able to build with clang (may be as you noted is just something with the + in my PATH). [1] http://git.chromium.org/gitweb/?p=chromium.git;a=tree;f=tools/clang/plugins;h=8e79d8f35d5ccfee82b6ab8f27ea8b5d820c772d;hb=HEAD -- 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] gitweb.cgi: fix comitter_tz typo in feed
gitweb's feeds sometimes contained committer timestamps in the wrong timezone
due to a misspelling.
Signed-off-by: Dylan Simon dy...@dylex.net
---
gitweb/gitweb.perl |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7f8c187..10ed9e5 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -8028,7 +8028,7 @@ sub git_feed {
%latest_commit = %{$commitlist[0]};
my $latest_epoch = $latest_commit{'committer_epoch'};
exit_if_unmodified_since($latest_epoch);
- %latest_date = parse_date($latest_epoch,
$latest_commit{'comitter_tz'});
+ %latest_date = parse_date($latest_epoch,
$latest_commit{'committer_tz'});
}
print $cgi-header(
-type = $content_type,
--
1.7.10.3
--
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
[minor] two tests broken when run with a --root directory that's a symlink
These issues are minor, I noticed it because I test with /dev/shm/git
as the --root, which on Debian is symlinked to /run/..
$ rm -rf /tmp/{foo,bar}
$ mkdir /tmp/target; ln -s /tmp/target /tmp/link
$ prove ./t4035-diff-quiet.sh ./t9903-bash-prompt.sh :: --root=/tmp/target
./t4035-diff-quiet.sh ... ok
./t9903-bash-prompt.sh .. ok
All tests successful.
Files=2, Tests=64, 1 wallclock secs ( 0.04 usr 0.00 sys + 0.07
cusr 0.06 csys = 0.17 CPU)
Result: PASS
$ prove ./t4035-diff-quiet.sh ./t9903-bash-prompt.sh :: --root=/tmp/link
./t4035-diff-quiet.sh ... Dubious, test returned 1 (wstat 256, 0x100)
Failed 3/20 subtests
./t9903-bash-prompt.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 6/44 subtests
Everything else in the test suite passes with a --root that's a symlink.
--
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] bash prompt: fix tests when run with a symlink --root
Some __gitdir() tests fail when they're run with a --root directory which is a symlink, because they use $TRASH_DIRECTORY to construct the expected absolute paths. Use the path got from 'pwd -P' instead throughout the test script. Signed-off-by: SZEDER Gábor sze...@ira.uka.de --- t/t9903-bash-prompt.sh | 34 ++ 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh index f17c1f8b..7a7b198f 100755 --- a/t/t9903-bash-prompt.sh +++ b/t/t9903-bash-prompt.sh @@ -11,6 +11,8 @@ test_description='test git-specific bash prompt functions' actual=$TRASH_DIRECTORY/actual +TRASH_ROOT=$(pwd -P) + test_expect_success 'setup for prompt tests' ' mkdir -p subdir/subsubdir git init otherrepo @@ -32,9 +34,9 @@ test_expect_success 'setup for prompt tests' ' ' test_expect_success 'gitdir - from command line (through $__git_dir)' ' - echo $TRASH_DIRECTORY/otherrepo/.git expected + echo $TRASH_ROOT/otherrepo/.git expected ( - __git_dir=$TRASH_DIRECTORY/otherrepo/.git + __git_dir=$TRASH_ROOT/otherrepo/.git __gitdir $actual ) test_cmp expected $actual @@ -59,7 +61,7 @@ test_expect_success 'gitdir - .git directory in cwd' ' ' test_expect_success 'gitdir - .git directory in parent' ' - echo $TRASH_DIRECTORY/.git expected + echo $TRASH_ROOT/.git expected ( cd subdir/subsubdir __gitdir $actual @@ -77,7 +79,7 @@ test_expect_success 'gitdir - cwd is a .git directory' ' ' test_expect_success 'gitdir - parent is a .git directory' ' - echo $TRASH_DIRECTORY/.git expected + echo $TRASH_ROOT/.git expected ( cd .git/refs/heads __gitdir $actual @@ -86,9 +88,9 @@ test_expect_success 'gitdir - parent is a .git directory' ' ' test_expect_success 'gitdir - $GIT_DIR set while .git directory in cwd' ' - echo $TRASH_DIRECTORY/otherrepo/.git expected + echo $TRASH_ROOT/otherrepo/.git expected ( - GIT_DIR=$TRASH_DIRECTORY/otherrepo/.git + GIT_DIR=$TRASH_ROOT/otherrepo/.git export GIT_DIR __gitdir $actual ) @@ -96,9 +98,9 @@ test_expect_success 'gitdir - $GIT_DIR set while .git directory in cwd' ' ' test_expect_success 'gitdir - $GIT_DIR set while .git directory in parent' ' - echo $TRASH_DIRECTORY/otherrepo/.git expected + echo $TRASH_ROOT/otherrepo/.git expected ( - GIT_DIR=$TRASH_DIRECTORY/otherrepo/.git + GIT_DIR=$TRASH_ROOT/otherrepo/.git export GIT_DIR cd subdir __gitdir $actual @@ -108,15 +110,15 @@ test_expect_success 'gitdir - $GIT_DIR set while .git directory in parent' ' test_expect_success 'gitdir - non-existing $GIT_DIR' ' ( - GIT_DIR=$TRASH_DIRECTORY/non-existing + GIT_DIR=$TRASH_ROOT/non-existing export GIT_DIR test_must_fail __gitdir ) ' test_expect_success 'gitdir - gitfile in cwd' ' - echo $TRASH_DIRECTORY/otherrepo/.git expected - echo gitdir: $TRASH_DIRECTORY/otherrepo/.git subdir/.git + echo $TRASH_ROOT/otherrepo/.git expected + echo gitdir: $TRASH_ROOT/otherrepo/.git subdir/.git test_when_finished rm -f subdir/.git ( cd subdir @@ -126,8 +128,8 @@ test_expect_success 'gitdir - gitfile in cwd' ' ' test_expect_success 'gitdir - gitfile in parent' ' - echo $TRASH_DIRECTORY/otherrepo/.git expected - echo gitdir: $TRASH_DIRECTORY/otherrepo/.git subdir/.git + echo $TRASH_ROOT/otherrepo/.git expected + echo gitdir: $TRASH_ROOT/otherrepo/.git subdir/.git test_when_finished rm -f subdir/.git ( cd subdir/subsubdir @@ -137,7 +139,7 @@ test_expect_success 'gitdir - gitfile in parent' ' ' test_expect_success SYMLINKS 'gitdir - resulting path avoids symlinks' ' - echo $TRASH_DIRECTORY/otherrepo/.git expected + echo $TRASH_ROOT/otherrepo/.git expected mkdir otherrepo/dir test_when_finished rm -rf otherrepo/dir ln -s otherrepo/dir link @@ -152,7 +154,7 @@ test_expect_success SYMLINKS 'gitdir - resulting path avoids symlinks' ' test_expect_success 'gitdir - not a git repository' ' ( cd subdir/subsubdir - GIT_CEILING_DIRECTORIES=$TRASH_DIRECTORY + GIT_CEILING_DIRECTORIES=$TRASH_ROOT export GIT_CEILING_DIRECTORIES test_must_fail __gitdir ) @@ -250,7 +252,7 @@ echo edit $(git log -1 --format=%h) $1 EOF test_when_finished rm -f fake_editor.sh chmod a+x fake_editor.sh - test_set_editor $TRASH_DIRECTORY/fake_editor.sh +
Re: [PATCH] git-cvsimport: support local timezone
On 10/11/2012 10:48 PM, Chris Rorvick wrote: CVS patches are unconditionally imported with a UTC timezone. Allow the local timezone by adding -l to the command line or specifying cvsimport.l in the config. This could be made the default behavior, as setting TZ=UTC in the environment before doing the import is equivalent to the current behavior. But since a new default may be an unwelcome surprise to some, make this new behavior available os an option. According to rcsfile(7), all times in RCS/CVS files are recorded in UTC. So why do you need this feature? 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
Re: [minor] two tests broken when run with a --root directory that's a symlink
On 10/11/2012 11:55 PM, Ævar Arnfjörð Bjarmason wrote:
These issues are minor, I noticed it because I test with /dev/shm/git
as the --root, which on Debian is symlinked to /run/..
$ rm -rf /tmp/{foo,bar}
$ mkdir /tmp/target; ln -s /tmp/target /tmp/link
$ prove ./t4035-diff-quiet.sh ./t9903-bash-prompt.sh :: --root=/tmp/target
./t4035-diff-quiet.sh ... ok
./t9903-bash-prompt.sh .. ok
All tests successful.
Files=2, Tests=64, 1 wallclock secs ( 0.04 usr 0.00 sys + 0.07
cusr 0.06 csys = 0.17 CPU)
Result: PASS
$ prove ./t4035-diff-quiet.sh ./t9903-bash-prompt.sh :: --root=/tmp/link
./t4035-diff-quiet.sh ... Dubious, test returned 1 (wstat 256, 0x100)
Failed 3/20 subtests
./t9903-bash-prompt.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 6/44 subtests
Everything else in the test suite passes with a --root that's a symlink.
I ran into the same problem a while ago, and submitted a patch series
that fixes t4035 (whose problems are related to GIT_CEILING_DIRECTORIES):
http://thread.gmane.org/gmane.comp.version-control.git/206633
Junio didn't like the approach so much and I haven't yet had time to
submit a revised version.
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
Re: [minor] two tests broken when run with a --root directory that's a symlink
Michael Haggerty mhag...@alum.mit.edu writes: I ran into the same problem a while ago, and submitted a patch series that fixes t4035 (whose problems are related to GIT_CEILING_DIRECTORIES): http://thread.gmane.org/gmane.comp.version-control.git/206633 Junio didn't like the approach so much and I haven't yet had time to submit a revised version. I like the approach of comparing each element of CEILING and the directory not before but after resolving any symlinks in them. My comments was only about the implementation that seemed to make the API layering boundary more complex than necessary. -- 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 v4 00/12] Wildmatch v4
Junio C Hamano gits...@pobox.com writes:
Ahh, it must be this bits from t/test-lib.sh
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git i/t/test-lib.sh w/t/test-lib.sh
index 514282c..489bc80 100644
--- i/t/test-lib.sh
+++ w/t/test-lib.sh
@@ -230,7 +230,7 @@ else
say_color() {
test -z $1 test -n $quiet return
shift
- echo $*
+ printf %s\n $*
}
fi
I'll queue this fix separately before your series on 'pu'.
-- 8 --
Subject: [PATCH] test-lib: Fix say_color () not to interpret \a\b\c in the
message
When running with color disabled (e.g. under prove to produce TAP
output), say_color() helper function is defined to use echo to show
the message. With a message that ends with \c, echo is allowed to
interpret it as Do not end the line with LF.
Use printf %s\n to emit the message literally.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index c0d04c4..280b3aa 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -169,7 +169,7 @@ else
say_color() {
test -z $1 test -n $quiet return
shift
- echo $*
+ printf %s\n $*
}
fi
--
1.8.0.rc1.82.ga68bb49
--
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] git-cvsimport: support local timezone
On Thu, Oct 11, 2012 at 5:43 PM, Michael Haggerty mhag...@alum.mit.edu wrote: On 10/11/2012 10:48 PM, Chris Rorvick wrote: CVS patches are unconditionally imported with a UTC timezone. Allow the local timezone by adding -l to the command line or specifying cvsimport.l in the config. This could be made the default behavior, as setting TZ=UTC in the environment before doing the import is equivalent to the current behavior. But since a new default may be an unwelcome surprise to some, make this new behavior available os an option. According to rcsfile(7), all times in RCS/CVS files are recorded in UTC. So why do you need this feature? Michael Hi Michael, Precisely because of this limitation. RCS files are not as expressive as a Git commit so I need a way to fill in the blanks. This is analogous to the cvs-authors file. The RCS files in a CVS repository say the author of my commits is crorvick but that is neither my name nor email. cvsimport allows me to overcome this limitation by specifying a mapping from author username to full name and email. Likewise, just because the RCS file has a UTC timestamp does not mean the commit originated in Greenwich, UK. Git includes the timezone offset in its timestamps, so it is reasonable to allow me to specify what is appropriate. This is not a big deal for a one-time import as a simple filter-branch run can fix this pretty quickly. But this feature would be nice when running cvsimport incrementally. Thanks! Chris Rorvick -- 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: A basic question
On Thu, Oct 11, 2012 at 11:08 PM, Jim Vahl j...@wmdb.com wrote: Drew, Thanks for responding to my email! Yes, I did read most of the Book, although I admit that I skimmed over some of the more technical parts. There is still a key part of how git is used in a commercial environment which I don't understand. When we release a new version of our product, it is comprised of over a hundred files. Some of these files have not changed for years, and some have been revised/fixed/updated quite recently. But what is key is that all of these components have passed a review and testing process. A very important piece of information is what revision of each file made it into the release. I'm afraid I don't have anything to add to what was already said but I can't resist asking: are you coming from clearcase? -- 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: build deps
On 10/11/12 16:54, Thiago Farina wrote: Just setting CC to gcc works for me. But still, I'd like to be able to build with clang (may be as you noted is just something with the + in my PATH). Oh, I just realized you were using sudo. The PATH environment was probably not inherited when you use sudo to run make. So the subsequent shells statred by make' were not able to find clang. -- 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: A basic question
On Thu, Oct 11, 2012 at 10:38 AM, Jim Vahl j...@wmdb.com wrote: 1) Does git have a built-in way to get a list of all of the most recently committed files only at a given point in time, thus automatically recording the revisions of all of the component files of a release? This implies that for files which are being modified or which have been staged but not committed, that git would go back to find the predecessor file which had been committed. I feel like I'm missing the point of your questions. Why do you think your central repository would contain anything that hadn't been committed? -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- 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: build deps
On Thu, Oct 11, 2012 at 10:06 PM, Andrew Wong andrew.kw.w.li...@gmail.com wrote: On 10/11/12 16:54, Thiago Farina wrote: Just setting CC to gcc works for me. But still, I'd like to be able to build with clang (may be as you noted is just something with the + in my PATH). Oh, I just realized you were using sudo. The PATH environment was probably not inherited when you use sudo to run make. So the subsequent shells statred by make' were not able to find clang. Interesting, thank you for your observation. This worked for me now: $ git clone https://github.com/gitster/git $ cd git $ make configure $ ./configure $ make $ ./git version git version 1.8.0.rc2 clang reported this: combine-diff.c:1006:19: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] prefix = COLONS + offset; ~~~^~~~ combine-diff.c:1006:19: note: use array indexing to silence this warning prefix = COLONS + offset; ^ [ ] 1 warning generated. grep.c:451:16: warning: comparison of unsigned enum expression 0 is always false [-Wtautological-compare] if (p-field 0 || GREP_HEADER_FIELD_MAX = p-field) ^ ~ 1 warning generated. -- 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
