Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables
Junio,
Thanks for your thoughtful response.
On 02/01/2015 09:18 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> On 01/28/2015 11:33 PM, Junio C Hamano wrote:
>>> + When choosing the variable namespace, do not use variable name for
>>> + specifying possibly unbounded set of things, most notably anything
>>> + an end user can freely come up with (e.g. branch names), but also
>>> + large fixed set defined by the system that can grow over time
>>> + (e.g. what kind of common whitespace problems to notice).
>>
>> I think we can all agree with this rule for "anything an end user can
>> freely come up with". Such sets are truly unbounded.
>>
>> But what is the justification for applying it to "large fixed set
>> defined by the system that can grow over time"?
> [...]
>
> I can see it argued that for things that are completely independent
> (e.g. the consequence of setting fsck.badDate can never be affected
> by how fsck.missingTagger is configured), separate configuration
> variables may not be wrong per-se, but I can see that a set of knobs
> that would have been originally independent, as the operation grow
> richer, gain more semantics to make them related, and at that point,
> I doubt "they are internally independent; expose them as independent
> to the end users" argument would hold water that well.
>
> A good example is "core.whitespace", where you would have started
> with a simple set of booleans ("blank-at-eol" and "space-before-tab"
> are conceptually independent and will stay to be), but once you
> start supporting "indent-with-non-tab" and "tab-in-indent" you
> cannot pretend that they are independent.
>
> And that is the "existing practice" I primarily had in mind. We
> didn't do
>
> whitespace.tabInIndent = true
> whitespace.indentWithNonTab = true
>
> to pretend they are independent and still internally having to make
> sure the consistency of the setting. We structured the syntax for
> ease of the end user (not scripter) to shorter
>
> core.whitespace = tab-in-indent,indent-with-non-tab
>
> as we need the consistency thing either way (and it is easier to see
> the consistency mistakes when they appear next to each other).
>
> And I am happy that we chose wisely in an early version that didn't
> use one-variable-per-knob but used list-of-features-as-value instead.
You make an interesting point: values that start as a list of
independent booleans can grow dependencies over time.
In retrospect, ISTM that a better interface for the indentation-related
"whitespace" settings would have been something like
* "whitespace.indent" -- a single value chosen from "tabs-only |
spaces-only | tabs-when-possible | anything"
* "whitespace.tabwidth" -- an integer value
This would have made the mutual-exclusivity of those choices manifest in
the style of configuration rather than hoping that the user notices that
his settings contradict each other.
Let's dig into this example some more by imagining some other
hypothetical future extensions. Suppose we wanted to support different
whitespace rules for different types of files [1]. For example, I might
never want to forbid "cr-at-eol" everywhere, and might usually like to
uses spaces for my indentation, but for Makefiles need to indent using
tabs. The "type 2" syntax, I think, is pretty straightforward:
[whitespace]
cr-at-eol = error
indent = spaces-only
[whitespace "makefile"]
indent = tabs-only
Our usual rules, "last setting wins" and "foo.*.bar, if present, takes
precedence overrides foo.bar", make it pretty clear how the above should
be interpreted.
What would be the "type 1" syntax for this? Would "cr-at-eol" be
inherited from "core.whitespace" to "core.makefile.whitespace"? If not,
then I have to repeat "cr-at-eol":
[core]
whitespace = cr-at-eol tab-in-indent
[core "makefile"]
whitespace = cr-at-eol indent-with-non-tab
[2]. If values are inherited, then do I also have to countermand
"tab-in-indent" in the "makefile" rule?
[core]
whitespace = cr-at-eol tab-in-indent
[core "makefile"]
whitespace = indent-with-non-tab -tab-in-indent
Or does "indent-with-non-tab" automatically supersede "tab-in-indent",
according to last-setting-wins (an interpretation that starts requiring
the config parser to have domain-specific knowledge)?:
[core]
whitespace = cr-at-eol tab-in-indent
[core "makefile"]
whitespace = indent-with-non-tab
But if that is the case, which setting wins in this scenario?:
[core]
whitespace = cr-at-eol tab-in-indent
[core "makefile"]
whitespace = indent-with-non-tab
# In another config file maybe:
[core]
whitespace = space-before-tab
Does "core.whitespace = space-before-tab" supersede
"core.makefile.whitespace = indent-with-non-tab" here?
No matter which of the "type 1" variants we choose, we would
Re: [RFC PATCH] diff: do not use creation-half of -B as a rename target candidate
A1 = "I am file A." B1 is copied from A1, so B1 = "I am file A." B1 changes to B2 = "I am file B." A1 changes to A2 = "file A is changed a lot, a lot, ..., a lot." At this moment, commit A2 and B2 files. -- View this message in context: http://git.661346.n2.nabble.com/Git-BUG-Please-do-not-use-B-M-in-diff-family-for-now-tp7624794p7624836.html Sent from the git mailing list archive at Nabble.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: Relative paths don't work in .gitignore as would be expected.
On 01.02.2015 14:51, /#!/JoePea wrote: > I have this in my .gitignore: > > ./*.js > > I would expect that to cause git to ignore .js files in the same > folder as .gitignore, but it doesn't do anything. However, this works: > > /*.js > > I'm not sure what this actually means because a leading slash is the > root of some filesystem, That's true, though you'd never (barely?) git version control an entire file system? A trailing "/**" matches everything inside. For example, "abc/**" matches all files inside directory "abc", relative to the location of the .gitignore file, with infinite depth. (from man gitignore, though reading that and not finding a './' it may need improvement -- 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] l10n: gitk/ca.po: add Catalan translation
Signed-off-by: Alex Henrie --- The only difference between version 1 and version 2 of this patch is the correction of trailing whitespace in a single message. Please let me know whether this patch is going to be included in Git 2.3.0. gitk-git/po/ca.po | 1349 + 1 file changed, 1349 insertions(+) create mode 100644 gitk-git/po/ca.po diff --git a/gitk-git/po/ca.po b/gitk-git/po/ca.po new file mode 100644 index 000..a20dd6d --- /dev/null +++ b/gitk-git/po/ca.po @@ -0,0 +1,1349 @@ +# Translation of gitk +# Copyright (C) 2005-2014 Paul Mackerras +# This file is distributed under the same license as the gitk package. +# Alex Henrie , 2015. +# +# +msgid "" +msgstr "" +"Project-Id-Version: gitk\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2015-01-22 00:45-0700\n" +"PO-Revision-Date: 2015-02-01 22:49-0700\n" +"Last-Translator: Alex Henrie \n" +"Language-Team: Catalan\n" +"Language: ca\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=2; plural=(n != 1);\n" +"X-Generator: Poedit 1.7.3\n" + +#: gitk:140 +msgid "Couldn't get list of unmerged files:" +msgstr "No s'ha pogut obtenir la llista de fitxers no fusionats:" + +#: gitk:212 gitk:2381 +msgid "Color words" +msgstr "Colora les paraules" + +#: gitk:217 gitk:2381 gitk:8108 gitk:8141 +msgid "Markup words" +msgstr "Marca les paraules" + +#: gitk:324 +msgid "Error parsing revisions:" +msgstr "Error en analitzar les revisions:" + +#: gitk:380 +msgid "Error executing --argscmd command:" +msgstr "Error en executar l'ordre --argscmd:" + +#: gitk:393 +msgid "No files selected: --merge specified but no files are unmerged." +msgstr "" +"No hi ha fitxers seleccionats: s'ha especificat --merge però cap fitxer està " +"sense fusionar." + +#: gitk:396 +msgid "" +"No files selected: --merge specified but no unmerged files are within file " +"limit." +msgstr "" +"No hi ha fitxers seleccionats: s'ha especificat --merge però cap fitxer " +"sense fusionar està dins del límit de fitxers." + +#: gitk:418 gitk:566 +msgid "Error executing git log:" +msgstr "Error en executar git log:" + +#: gitk:436 gitk:582 +msgid "Reading" +msgstr "Llegint" + +#: gitk:496 gitk:4415 +msgid "Reading commits..." +msgstr "Llegint les revisions..." + +#: gitk:499 gitk:1637 gitk:4418 +msgid "No commits selected" +msgstr "Cap comissió seleccionada" + +#: gitk:1511 +msgid "Can't parse git log output:" +msgstr "No es pot analitzar la sortida del git log:" + +#: gitk:1740 +msgid "No commit information available" +msgstr "Cap informació de comissió disponible" + +#: gitk:1897 +msgid "mc" +msgstr "mc" + +#: gitk:1932 gitk:4208 gitk:9557 gitk:11127 gitk:11406 +msgid "OK" +msgstr "D'acord" + +#: gitk:1934 gitk:4210 gitk:9084 gitk:9163 gitk:9279 gitk:9328 gitk:9559 +#: gitk:11128 gitk:11407 +msgid "Cancel" +msgstr "Cancel·la" + +#: gitk:2069 +msgid "Update" +msgstr "Actualitza" + +#: gitk:2070 +msgid "Reload" +msgstr "Recarrega" + +#: gitk:2071 +msgid "Reread references" +msgstr "Rellegeix les referències" + +#: gitk:2072 +msgid "List references" +msgstr "Llista les referències" + +#: gitk:2074 +msgid "Start git gui" +msgstr "Inicia el git gui" + +#: gitk:2076 +msgid "Quit" +msgstr "Surt" + +#: gitk:2068 +msgid "File" +msgstr "Fitxer" + +#: gitk:2080 +msgid "Preferences" +msgstr "Preferències" + +#: gitk:2079 +msgid "Edit" +msgstr "Edita" + +#: gitk:2084 +msgid "New view..." +msgstr "Vista nova..." + +#: gitk:2085 +msgid "Edit view..." +msgstr "Edita la vista..." + +#: gitk:2086 +msgid "Delete view" +msgstr "Suprimeix vista" + +#: gitk:2088 +msgid "All files" +msgstr "Tots els fitxers" + +#: gitk:2083 gitk:3961 +msgid "View" +msgstr "Vista" + +#: gitk:2093 gitk:2103 gitk:2920 +msgid "About gitk" +msgstr "Quant al gitk" + +#: gitk:2094 gitk:2108 +msgid "Key bindings" +msgstr "Associacions de tecles" + +#: gitk:2092 gitk:2107 +msgid "Help" +msgstr "Ajuda" + +#: gitk:2185 gitk:8540 +msgid "SHA1 ID:" +msgstr "ID SHA1:" + +#: gitk:2229 +msgid "Row" +msgstr "Fila" + +#: gitk:2267 +msgid "Find" +msgstr "Cerca" + +#: gitk:2295 +msgid "commit" +msgstr "comissió" + +#: gitk:2299 gitk:2301 gitk:4576 gitk:4599 gitk:4623 gitk:6643 gitk:6715 +#: gitk:6800 +msgid "containing:" +msgstr "que contingui:" + +#: gitk:2302 gitk:3433 gitk:3438 gitk:4652 +msgid "touching paths:" +msgstr "que toqui els camins:" + +#: gitk:2303 gitk:4666 +msgid "adding/removing string:" +msgstr "que afegeixi/elimini la cadena:" + +#: gitk:2304 gitk:4668 +msgid "changing lines matching:" +msgstr "que tingui línies canviades coincidents amb:" + +#: gitk:2313 gitk:2315 gitk:4655 +msgid "Exact" +msgstr "Exacte" + +#: gitk:2315 gitk:4743 gitk:6611 +msgid "IgnCase" +msgstr "Ignora majúscula i minúscula" + +#: gitk:2315 gitk:4625 gitk:4741 gitk:6607 +msgid "Regexp" +msgstr "Regexp" + +#: gitk:2317 gitk:2318 gitk:4763 gitk:4793 gitk:4800 gitk:6736 gitk:6804 +msgid "All fields" +msgstr "Tots els camps" + +#: gitk:2318 g
Re: [RFC PATCH] diff: do not use creation-half of -B as a rename target candidate
On 01.02.2015 19:18, Junio C Hamano wrote: > When a commit creates new file B by copying the contents of an > existing file A and making a small edit and makes large edit to A, This part is hard to parse "When ... and making a small edit and makes a large edit" So large or small? It's a bit hard to parse and understand when just trying to read the first sentence. IT becomes clear (somewhat) later. -- 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
[RFC PATCH] diff: do not use creation-half of -B as a rename target candidate
When a commit creates new file B by copying the contents of an existing file A and making a small edit and makes large edit to A, "diff -M" would not see any copying or renaming, because the file A appears in both preimage and postimage. The output ends up showing two large patches, one that adds almost the entirety of original A to the newly created file B, and the other that removes almost the entirety of the original contents from A and adds new material to it. "diff -B -M" was invented to allow us notice this case and instead express the change as one patch that copies A to B with small edit, and rewrites A with contents unrelated to its original. The patch expressed this way becomes much easier to read, because the reader can see that most of the contents in B after the change came from the original A (the patch header shows "copy from A" for B), and A was completely rewritten by the patch (the patch body shows everything removed first and then all new material added). However this logic has a bug to incorrectly produce an unapplicable patch in other cases. Starting from existing files A and B, when a commit removes A and makes the resulting B similar to the original contents of A, it incorrectly expressed it as a change that renames A to B and then makes small edits. Such a patch will not apply to the original state the patch was taken from, as B exists there. The root cause of the problem is that after the complete rewrite of B is detected and is internally split into deletion of old B and creation of new B, the rename detection machinery matches the old contents of A (which will go away) with the newly created B, because they are similar. Considering the deletion-half of the change to B as possible rename source (i.e. from which a new file is created) is good, but considering the creation-half as possible rename destination (i.e. the file is created by taking whole contents from elsewhere) is bad---because we know B being a broken filepair means it already existed, and cannot have been newly _created_. For a simple reproduction, go to your copy of the kernel tree and do this: $ git diff -B -M v2.6.13 v2.6.12 -- \ arch/ppc64/kernel/rtas_pci.c arch/ppc64/kernel/pSeries_pci.c >:patch $ git reset --hard $ git checkout v2.6.13 $ git apply --cached --whitespace=nowarn :patch error: arch/ppc64/kernel/pSeries_pci.c: already exists in index In this example, rtas_pci.c and pSeries_pci.c corresponds to files A and B, respectively, in the more general description of the problem given earlier. Signed-off-by: Junio C Hamano --- * Here is what I am at the moment; I cannot quite explain (hence I cannot convince myself) why this is the right solution, but it seems to make the above sample case work without breaking any existing tests. It is possible that the tests that would break without the "&& !p->score" bit are expecting wrong results, but I didn't look at them in detail. diffcore-rename.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/diffcore-rename.c b/diffcore-rename.c index 6c7a72f..f4e8e00 100644 --- a/diffcore-rename.c +++ b/diffcore-rename.c @@ -516,6 +516,8 @@ void diffcore_rename(struct diff_options *options) else if (!DIFF_OPT_TST(options, RENAME_EMPTY) && is_empty_blob_sha1(p->two->sha1)) continue; + else if (p->broken_pair && !p->score) + continue; else locate_rename_dst(p->two, 1); } -- 2.3.0-rc2-165-gbd2cd9b -- 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] t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
"Kyle J. McKay" writes:
>> use 5.008;
>
> So either that needs to change or the code should properly deal with
> the version of Getopt::Long that comes with 5.8.0.
>
> Since it's really not very difficult or invasive to add support for
> the no- variants, here's a patch to do so:
Doesn't that approach add "what does --no-no-chain-rely-to even
mean?" confusion to the resulting system? If that is not the case,
then I am all for it, but otherwise, let's not.
People can easily spell --noxmailer if they want to stay at an older
Getopt::Long, and over time these ancient ones will be upgraded
away.
> -- 8< --
> Subject: [PATCH] git-send-email.perl: support no- prefix with older GetOptions
>
> Only Perl version 5.8.0 or later is required, but that comes with
> an older Getopt::Long (2.32) that does not support the 'no-'
> prefix. Support for that was added in Getopt::Long version 2.33.
>
> Since the help only mentions the 'no-' prefix and not the 'no'
> prefix, add explicit support for the 'no-' prefix when running
> with older GetOptions versions.
>
> Reported-by: Tom G. Christensen
> Signed-off-by: Kyle J. McKay
> ---
> git-send-email.perl | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 3092ab35..a18a7959 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -299,6 +299,7 @@ my $rc = GetOptions("h" => \$help,
> "bcc=s" => \@bcclist,
> "no-bcc" => \$no_bcc,
> "chain-reply-to!" => \$chain_reply_to,
> + "no-chain-reply-to" => sub {$chain_reply_to = 0},
> "smtp-server=s" => \$smtp_server,
> "smtp-server-option=s" => \@smtp_server_options,
> "smtp-server-port=s" => \$smtp_server_port,
> @@ -311,25 +312,34 @@ my $rc = GetOptions("h" => \$help,
> "smtp-domain:s" => \$smtp_domain,
> "identity=s" => \$identity,
> "annotate!" => \$annotate,
> + "no-annotate" => sub {$annotate = 0},
> "compose" => \$compose,
> "quiet" => \$quiet,
> "cc-cmd=s" => \$cc_cmd,
> "suppress-from!" => \$suppress_from,
> + "no-suppress-from" => sub {$suppress_from = 0},
> "suppress-cc=s" => \@suppress_cc,
> "signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
> + "no-signed-off-cc|no-signed-off-by-cc" => sub
> {$signed_off_by_cc = 0},
> "cc-cover|cc-cover!" => \$cover_cc,
> + "no-cc-cover" => sub {$cover_cc = 0},
> "to-cover|to-cover!" => \$cover_to,
> + "no-to-cover" => sub {$cover_to = 0},
> "confirm=s" => \$confirm,
> "dry-run" => \$dry_run,
> "envelope-sender=s" => \$envelope_sender,
> "thread!" => \$thread,
> + "no-thread" => sub {$thread = 0},
> "validate!" => \$validate,
> + "no-validate" => sub {$validate = 0},
> "transfer-encoding=s" => \$target_xfer_encoding,
> "format-patch!" => \$format_patch,
> + "no-format-patch" => sub {$format_patch = 0},
> "8bit-encoding=s" => \$auto_8bit_encoding,
> "compose-encoding=s" => \$compose_encoding,
> "force" => \$force,
> "xmailer!" => \$use_xmailer,
> + "no-xmailer" => sub {$use_xmailer = 0},
>);
>
> usage() if $help;
> --
--
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
Relative paths don't work in .gitignore as would be expected.
I have this in my .gitignore: ./*.js I would expect that to cause git to ignore .js files in the same folder as .gitignore, but it doesn't do anything. However, this works: /*.js I'm not sure what this actually means because a leading slash is the root of some filesystem, and we're not in the root, nor do gitignore files always exist in the root of a git repo. Being able to have ./*.js in .gitignore would make much sense. /#!/JoePea -- 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
RFD: should we do another 2.3-rc for t9001-noxmailer? I'd say not
I was reviewing the recent bugs and fixes for the last time, and was wondering if we want to do 2.3-rc3 with build fix for those with ancient cURL (tc/curl-vernum-output-broken-in-7.11) and workaround for those with Perl with older Getopt::Long (tc/t9001-noxmailer). - The former is not a regression between 2.2 and 2.3 (i.e. 2.2 already had the same use of curl-config output). - The latter, strictly speaking, is a regression in that tests used to pass but tests in 2.3 no longer pass for those with older Getopt::Long. But the latter is about a test script that lacks work-around, and more importantly, everybody has lived with unconditional X-mailer: output, and the minority with ancient Getopt::Long will survive without being to able to give the new --no-xmailer (or --noxmailer) option just fine. So currently I am leaning to keep these two fixes where they are and tag 2.3 final without them in a few days. -- 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 & patch: exit codes from internal commands are handled incorrectly
On Dec 18, 2014, at 2:18 PM, Junio C Hamano wrote:
> Kenneth Lorber writes:
>
>>> Bug: exit codes from (at least) internal commands are handled incorrectly.
>>> E.g. git-merge-file, docs say:
>>> The exit value of this program is negative on error, and the number of
>>> conflicts otherwise. If the merge was clean, the exit value is 0.
>>> But only 8 bits get carried through exit, so 256 conflicts gives
>>> exit(0), which means the merge was clean.
>
> Wouldn't any cmd_foo() that returns negative to main() be buggy?
Yes.
>
> Your change sweeps such problems under the rug, which is not a
> healthy thing to do.
Agreed. (See below.)
>
> Expecting that the exit code can signal small positive integers and
> other generic kinds of failures is a losing proposition. I think it
> is a better fix to update cmd_merge_file() to return 1 (when ret is
> positive), 0 (when ret is zero) or 128 (when ret is negative), or
> something simple like that, and update the documentation to match
> that, without touching git.c::main().
The new patch uses 0, 1, and 2 to match diff(1).
> Among the in-tree users, I notice git-cvsserver.perl is already
> using the command incorrectly. It does this:
>
>my $return = system("git", "merge-file", $file_local, $file_old,
> $file_new);
>$return >>= 8;
>
>cleanupTmpDir();
>
>if ( $return == 0 )
>{
>$log->info("Merged successfully");
>...
>}
>elsif ( $return == 1 )
>{
>$log->info("Merged with conflicts");
>...
>}
>else
>{
>$log->warn("Merge failed");
>next;
>}
>
> which assumes $return == 1 is special "half-good", which is not
> consistent with the documented interface. It will incorrectly
> say "Merge failed" when there are two or more conflicts.
>
> And with such a "1 or 0 or -1" change, you will fix that caller as
> well ;-)
I'll call that a win.
The attached patch covers the following:
- fixes all places where "make test" attempts to call exit() with a value <0 or
>255
- changes git-merge-file.txt to reflect the change in exit codes
- fixes the exit codes for merge-file
- adds a warning (which should probably be changed to something clearer) if
git.c:run_builtin() is going to cause an out-of-bounds exit
- fixes a typo in t7007-show.sh
- replaces return(0) with exit(0) in test-parse-options.c
The diff is cut against 15598cf41beed0d86cd2ac443e0f69c5a3b40321 (2.3.0-rc2)
Thanks,
Keni
d2.ship
Description: Binary data
Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables
Jeff King writes: > From the user's perspective, I don't see how the implied relationships > are significantly different. In type 1, they are placed inside a single > value and in type 2, they are not. Both are a form of grouping. > > Moreover, I am not even sure that the syntax is an important element in > communicating semantic relationships. I think we are in agreement and I do not see how you can draw different conclusions. The above argument refutes the point Michael made a big deal out of, which was that "these are individual and independent bools in the implementation detail of the code, expose that as such to the end users." I do not buy that point, i.e. it is not a good argument to favor style 2 over style 1, which was the primary thing I wanted to illustrate in the message you are responding to. > 1. I'm a user who has set my preferred core.whitespace in my > ~/.gitconfig. A particular project I am working on uses an > alternate tabwidth. How do I set that in the repo config without > repeating my defaults? Isn't it cumulative? At least it should be (but I wouldn't be too surprised if the recent config reader caching broke it). > 2. I'm writing a hook whose behavior depends on the whitespace > settings. How do I ask git whether blank-at-eol is enabled? If that becomes an issue, "git config" would have to learn about them, just like it knows about how to do --color depending on the tty-ness of the output. > 3. I'm a user who wants to set whitespace config. I prefer using "git > config" to editing the file manually. How do I turn off > blank-at-eol without disrupting my existing settings? See above 1. >> I see Peff cites "pager.", but I think it was something that we >> would rather shouldn't have done, similar to "alias.". They >> are bad precedents we shouldn't encourage new things to mimic. >> >> But that is not from "one-variable-with-list-is-better" (it is not >> better for these "independent" ones) but is purely from the syntax >> point of view. > > Yeah, I'd agree that the problem there is orthogonal to the type 1/2 > thing above. I don't think it has been a big deal in practice, just > because people with good taste do not name their commands with uppercase > anyway. > > I'd be happy to transition to pager.*.enabled, etc, if we care. I have no strong opinion. It was primarily meant to illustrate why pager. and alias. were bad precedents that should not be used to support design of future things. -- 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] CodingGuidelines: describe naming rules for configuration variables
On Sun, Feb 01, 2015 at 12:18:34PM -0800, Junio C Hamano wrote: > I can see it argued that for things that are completely independent > (e.g. the consequence of setting fsck.badDate can never be affected > by how fsck.missingTagger is configured), separate configuration > variables may not be wrong per-se, but I can see that a set of knobs > that would have been originally independent, as the operation grow > richer, gain more semantics to make them related, and at that point, > I doubt "they are internally independent; expose them as independent > to the end users" argument would hold water that well. I'm not sure I buy this argument. There are two syntaxes being discussed here. Let's look at each. Let's call this "type 1": [core] foo = bar -moof xyzzy=whatever We have a single variable, but the value of that variable is essentially a list of sub-variables. The sub-variables are either booleans (like "bar" or "-moof") or possibly have values of their own (with an "="). The sub-variables are tied together logically by being part of a single "core.foo". Presumably the user can infer some relationship between them through this. Type 2 is more like: [foo] bar = true moof = false xyzzy = whatever So we still have our same set of sub-variables, except now each is a first-class config variable. They are tied together logically by being part of a single section (I called it "foo" here, which drops the "core"; but clearly we could give it whatever descriptive name we wanted). >From the user's perspective, I don't see how the implied relationships are significantly different. In type 1, they are placed inside a single value and in type 2, they are not. Both are a form of grouping. Moreover, I am not even sure that the syntax is an important element in communicating semantic relationships. In these examples, are "bar" and "moof" dependent? Clearly they are _related_ by our grouping. But does one depend on the other? Similarly, with the existing core.whitespace, what tells you which of the sub-variables are related. The "blank-at-eol" and "space-before-tab" variables are both whitespace-related, but do not depend on each other at all. But "indent-with-non-tab" and "tab-in-indent" are. Yet those two pairs are represented the same way syntactically. I don't think you can infer semantic independence from syntax. It's simply too blunt an instrument (and as you noted, it may even change over time). > We structured the syntax for ease of the end user (not scripter) to > shorter > > core.whitespace = tab-in-indent,indent-with-non-tab > > as we need the consistency thing either way (and it is easier to see > the consistency mistakes when they appear next to each other). I agree that this provides a slight advantage to "type 1", because it requires syntactically that the definitions are near each other (whereas with split variables, they can literally be in different files). And if everything else were equal, that would be enough. But I think "type 1" has a lot of other disadvantages. For example: 1. I'm a user who has set my preferred core.whitespace in my ~/.gitconfig. A particular project I am working on uses an alternate tabwidth. How do I set that in the repo config without repeating my defaults? 2. I'm writing a hook whose behavior depends on the whitespace settings. How do I ask git whether blank-at-eol is enabled? 3. I'm a user who wants to set whitespace config. I prefer using "git config" to editing the file manually. How do I turn off blank-at-eol without disrupting my existing settings? An astute reader will notice that case (1) is a double-edged sword. If your defaults have "blank-at-eol" and you want to set "indent-with-non-tab" in the repo, that's fine. If the default is "tab-in-indent" and you want to set "indent-with-non-tab", then those are in conflict (i.e., this is the exact thing you were complaining about above). But is it such a bad thing to have them in conflict? Can't we define a set of rules that does what people expects? For example, by the "last one wins" principle, any time we see "whitespace.tab-in-indent", it clears the setting of "whitespace.indent-with-non-tab", and vice versa. This isn't represented syntactically in the config file, but it is an easy rule, does what people would want, and can be documented in config.txt (which is where we have to talk about such semantic conflicts anyway). By the way, this is the exact case I am concerned about for fsck.*. Our use case at GitHub would be something like: a. We set up sane defaults for fsck.* in /etc/gitconfig b. User complains that we will not accept their push, which contains objects with malformed committers. c. Support investigates, determines that the malformed objects are part of a well-established history, and that they are OK to enter. d. We relax fsck.committerIdent in that repo's $GIT_DIR/config file. Copy-and-pasting the rest of the rule
[PATCH 2/2] sha1_file: fix iterating loose alternate objects
The string in 'base' contains a path suffix to a specific object; when
its value is used, the suffix must either be filled (as in
stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or cleared
(as in prepare_packed_git) to avoid junk at the end. loose_from_alt_odb
(introduced in 660c889e46d185dc98ba78963528826728b0a55d) did neither and
treated 'base' as a complete path to the "base" object directory,
instead of a pointer to the "base" of the full path string.
The trailing path after 'base' is still initialized to NUL, hiding the
bug in some common cases. Additionally the descendent
for_each_file_in_obj_subdir function swallows ENOENT, so an error only
shows if the alternate's path was last filled with a valid object
(where statting /path/to/existing/00/0bjectfile/00 fails).
Signed-off-by: Jonathon Mah
---
sha1_file.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 30995e6..fcb1c4b 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -3396,9 +3396,13 @@ static int loose_from_alt_odb(struct
alternate_object_database *alt,
void *vdata)
{
struct loose_alt_odb_data *data = vdata;
- return for_each_loose_file_in_objdir(alt->base,
-data->cb, NULL, NULL,
-data->data);
+ int r;
+ alt->name[-1] = 0;
+ r = for_each_loose_file_in_objdir(alt->base,
+ data->cb, NULL, NULL,
+ data->data);
+ alt->name[-1] = '/';
+ return r;
}
int for_each_loose_object(each_loose_object_fn cb, void *data)
--
2.3.0.rc2.2.g184f7a0
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] t5710-info-alternate: demonstrate bug in unpacked pruning
Signed-off-by: Jonathon Mah
---
t/t5710-info-alternate.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5710-info-alternate.sh b/t/t5710-info-alternate.sh
index 5a6e49d..d82844a 100755
--- a/t/t5710-info-alternate.sh
+++ b/t/t5710-info-alternate.sh
@@ -18,6 +18,7 @@ reachable_via() {
test_valid_repo() {
git fsck --full > fsck.log &&
+ git prune &&
test_line_count = 0 fsck.log
}
@@ -47,8 +48,7 @@ test_expect_success 'preparing third repository' \
'git clone -l -s B C && cd C &&
echo "Goodbye, cruel world" > file3 &&
git add file3 &&
-git commit -m "one more" file3 &&
-git repack -a -d -l &&
+git commit -m "one more without packing" file3 &&
git prune'
cd "$base_dir"
--
2.3.0.rc2.2.g184f7a0
--
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] CodingGuidelines: describe naming rules for configuration variables
Michael Haggerty writes:
> On 01/28/2015 11:33 PM, Junio C Hamano wrote:
>> + When choosing the variable namespace, do not use variable name for
>> + specifying possibly unbounded set of things, most notably anything
>> + an end user can freely come up with (e.g. branch names), but also
>> + large fixed set defined by the system that can grow over time
>> + (e.g. what kind of common whitespace problems to notice).
>
> I think we can all agree with this rule for "anything an end user can
> freely come up with". Such sets are truly unbounded.
>
> But what is the justification for applying it to "large fixed set
> defined by the system that can grow over time"? Any set of items that
> needs to be programmed one by one is not unbounded in the same sense. It
> is true that it can grow over time, but there is a practical limit on
> how many such options we would ever implement, and at any given time the
> set has a well-defined, finite number of members.
>
> I suppose that this is a reaction to Johannes's proposal [1] to add
> configuration settings like
>
> git config fsck.badDate ignore
Not really.
This started after I looked at the add.ignore-errors issue discussed
and I was trying to codify existing practices by running greps,
blames and logs on 'master' to see what potential pitfalls are, and
what good existing practices to follow suit we already had.
The fsck changes were not in my mind at all.
I can see it argued that for things that are completely independent
(e.g. the consequence of setting fsck.badDate can never be affected
by how fsck.missingTagger is configured), separate configuration
variables may not be wrong per-se, but I can see that a set of knobs
that would have been originally independent, as the operation grow
richer, gain more semantics to make them related, and at that point,
I doubt "they are internally independent; expose them as independent
to the end users" argument would hold water that well.
A good example is "core.whitespace", where you would have started
with a simple set of booleans ("blank-at-eol" and "space-before-tab"
are conceptually independent and will stay to be), but once you
start supporting "indent-with-non-tab" and "tab-in-indent" you
cannot pretend that they are independent.
And that is the "existing practice" I primarily had in mind. We
didn't do
whitespace.tabInIndent = true
whitespace.indentWithNonTab = true
to pretend they are independent and still internally having to make
sure the consistency of the setting. We structured the syntax for
ease of the end user (not scripter) to shorter
core.whitespace = tab-in-indent,indent-with-non-tab
as we need the consistency thing either way (and it is easier to see
the consistency mistakes when they appear next to each other).
And I am happy that we chose wisely in an early version that didn't
use one-variable-per-knob but used list-of-features-as-value instead.
> [2] which you didn't like [3] but I did [4]. (Did you miss [4], in which
> I think I made some good arguments for Johannes's proposal? I don't
> think you responded to it.)
I saw it, found it as an argument between "not good" and "weak" (see
above), kept in my mailbox while trying to decide if it was worth
responding, and then forgot about it after I got busy dealing with
other topics that have more relevance to the upcoming release ;-)
> I think it would be more productive to finish the concrete discussion
> about the "fsck" proposal,...
Surely.
(0) fsck.bad-date is out.
(1) fsck.badDate is OK. I expect there is very high chance for
them to stay independent forever.
(2) fsck.ignore = bad-date,... is still my preference, only if it
aligns with existing core.whitespace precedence that allows
users to leverage the familiarity.
I see Peff cites "pager.", but I think it was something that we
would rather shouldn't have done, similar to "alias.". They
are bad precedents we shouldn't encourage new things to mimic.
But that is not from "one-variable-with-list-is-better" (it is not
better for these "independent" ones) but is purely from the syntax
point of view. There is no good reason to force case insensitivity
to the command names used as the key in these cases, but we do
because we made them the last-level variable names, and we have to
avoid hyphens in the command names while at it if we want to be
consistent (and the consistency was the point of the original
add.ignore-errors discussion that started all this, after all).
If they were
pager.diff.enable = true
alias.co.command = checkout
the world would have been a lot better place.
--
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 to rebase one branch of the merge commit?
On zo, 2015-02-01 at 19:42 +0100, Hans Ginzel wrote: > Hello! > > Suppose following git history: > > A–M–C > / > B > > How to achieve this with commits metadata preserving? > > A–M'–C' > / > B' > > I did > > git checkout B > git add something_not_in_other_commits > git commit --amend > > So I have B'. How to continue, please? My git version is 1.7.1 (Centos 6.5). Assuming you have a branch pointing to C and no uncommitted changes: 1) git checkout branch-that-points-to-c 2) git rev-parse branch-that-point-to-c 3) git reset --hard A 4) git merge B' 5) git cherry-pick sha1-that-was-the-output-of-step-2 -- Dennis Kaarsemaker www.kaarsemaker.net -- 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
How to rebase one branch of the merge commit?
Hello! Suppose following git history: A–M–C / B How to achieve this with commits metadata preserving? A–M'–C' / B' I did git checkout B git add something_not_in_other_commits git commit --amend So I have B'. How to continue, please? My git version is 1.7.1 (Centos 6.5). Regards Hans -- 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] CodingGuidelines: describe naming rules for configuration variables
On Sun, Feb 01, 2015 at 06:12:38AM +0100, Michael Haggerty wrote: > > + When choosing the variable namespace, do not use variable name for > > + specifying possibly unbounded set of things, most notably anything > > + an end user can freely come up with (e.g. branch names), but also > > + large fixed set defined by the system that can grow over time > > + (e.g. what kind of common whitespace problems to notice). > > I think we can all agree with this rule for "anything an end user can > freely come up with". Such sets are truly unbounded. > > But what is the justification for applying it to "large fixed set > defined by the system that can grow over time"? Any set of items that > needs to be programmed one by one is not unbounded in the same sense. It > is true that it can grow over time, but there is a practical limit on > how many such options we would ever implement, and at any given time the > set has a well-defined, finite number of members. I had the same reaction on reading this. We should be striving to break config options down as much as possible to single scalar values, because that is the only format that is understood systematically by the config code. If a config option's value is a list, then we have to come up with an ad-hoc syntax for the list, which we parse in the config callback. And that leaves users of "git config" to reinvent that parsing themselves when they want to do simple things like "remove item B from the list". I think the examples you gave over on the fsck thread all make the same point. > > + [...] Use > > + subsection names or variable values, like existing variables > > + branch..description and core.whitespace do, instead. > > But there is also a precedent for the opposite approach: "advice.*". The pager.*, color.* (and color.$program.*) examples come to mind. For example, we did not add: [core] usePagerFor = log, diff, -status but instead: [pager] log = true diff = true status = false Not only is the latter easier to manipulate and examine with the existing config tools, I think it is more flexible in the long run. We later extended the syntax to allow: [pager] log = diff-highlight | less which would have been even more awkward in the "userPagerFor" format (you could use "log=...", of course, but now you need to get into whitespace quoting and other complexities, all of which are handled already by the config code in the latter case). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
You will upload it till Sunday evening, February 1
Dear Authors of Invited Papers in Dubai (UAE), Due to the great success of the WSEAS.org upcoming conferences in Dubai, UAE, Febr 22-24, '15, www.wseas.org, we can accept your INVITED paper provided that you will upload it till Sunday evening, February 1 We remind you that as invited author, you will enjoy not only the usual publication in our Books and CD-ROMS (indexed by ISI, SCOPUS etc...), but also you will publish the extended version of your paper(s) in our 33 ISI/SCI/SCOPUS Indexed Journals. Our invited authors are explicitly marked in the program as invited authors and the presentation of their papers lasts twice as long as the regular paper. Upload your invited paper by selecting the conference that applies the most to your field (please, include the phrase "Invited-by-Rena- git@vger.kernel.org " in the Web Form, in the Field: Comments) Best Regards Rena N. Politi Conferences & Publishing Services of WSEAS -- 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: Importing from RTC to GIT
Its the more or less the same response as I wrote in the stackoverflow thread. To begin with, we run into the same issue... We also wanted to keep our history and didnt found anything. So we started to create a python script, which automates the process to migrate RTC SCM Stream by Stream to GIT. The script(s) can be found here: https://github.com/WtfJoke/rtc2git It doesnt work with git fast import, though. But its a possible way to migrate your components. You can read how it works on the stackoverflow-post or in the project description. The script is not finished yet, but in a good state. With that I was able to migrate some components sucesfully already (the rtc commands take some time for completion, therefore it takes quite a lot of time to migrate stuff). -- View this message in context: http://git.661346.n2.nabble.com/Importing-from-RTC-to-GIT-tp7617984p7624818.html Sent from the git mailing list archive at Nabble.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
