[PATCH] Documentation/config.txt: change pull.rebase description in favor of safer 'preserve' option.
Previous description implicitly favored 'true' value for pull.rebase and pull.branch.rebase options, when for some workflows 'preserve' is the right choice, and for others it hardly makes any difference. Therefore, 'preserve' should be preferred in general, unless the user knows exactly what she is doing. Signed-off-by: Sergey Organov sorga...@gmail.com --- Documentation/config.txt | 26 -- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index c55c22a..30f28d9 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -772,14 +772,13 @@ branch.name.mergeoptions:: supported. branch.name.rebase:: - When true, rebase the branch name on top of the fetched branch, - instead of merging the default branch from the default remote when - git pull is run. See pull.rebase for doing this in a non - branch-specific manner. + When `preserve` or `true`, rebase the branch name on top of the + fetched branch, instead of merging the default branch from the + default remote when 'git pull' is run. See pull.rebase for + doing this in a non branch-specific manner. + - When preserve, also pass `--preserve-merges` along to 'git rebase' - so that locally committed merge commits will not be flattened - by running 'git pull'. + When `true`, do not pass `--preserve-merges` to 'git rebase', so + that local merge commits will be flattened by running 'git pull'. + *NOTE*: this is a possibly dangerous operation; do *not* use it unless you understand the implications (see linkgit:git-rebase[1] @@ -1948,14 +1947,13 @@ pull.ff:: command line). pull.rebase:: - When true, rebase branches on top of the fetched branch, instead - of merging the default branch from the default remote when git - pull is run. See branch.name.rebase for setting this on a - per-branch basis. + When `preserve` or `true`, rebase branches on top of the + fetched branch, instead of merging the default branch from the + default remote when 'git pull' is run. See + branch.name.rebase for setting this on a per-branch basis. + - When preserve, also pass `--preserve-merges` along to 'git rebase' - so that locally committed merge commits will not be flattened - by running 'git pull'. + When `true`, do not pass `--preserve-merges` to 'git rebase', so + that local merge commits will be flattened by running 'git pull'. + *NOTE*: this is a possibly dangerous operation; do *not* use it unless you understand the implications (see linkgit:git-rebase[1] -- 1.9.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
[PATCH] cache.h: add missing NORETURN on git_die_config*()
Commit 3a2a9527 (config: add `git_die_config()` to the config-set API, 01-08-2014) added git_die_config() and git_die_config_linenr() functions, but forgot to include the NORETURN attribute in their declarations. Sparse complains like so: SP config.c config.c:1567:6: error: symbol 'git_die_config_linenr' redeclared \ with different type (originally declared at cache.h:1419) \ - different modifiers config.c:1579:6: error: symbol 'git_die_config' redeclared with \ different type (originally declared at cache.h:1418) \ - different modifiers Suppress the sparse errors by adding NORETURN to the function declarations in the cache.h header file. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Tanay, If you need to re-roll the patches in the 'ta/config-set-1' branch, could you please squash this into the relevant patch. Thanks! At present there are no callers outside of config.c (but that will change right!;-), but since three of the four call sights for these functions appear _before_ the definitions, only a single call could possibly benefit from the NORETURN (line 1585). HTH ATB, Ramsay Jones cache.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cache.h b/cache.h index 9faea51..d82a5c3 100644 --- a/cache.h +++ b/cache.h @@ -1415,8 +1415,8 @@ extern int git_config_get_bool(const char *key, int *dest); extern int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest); extern int git_config_get_maybe_bool(const char *key, int *dest); extern int git_config_get_pathname(const char *key, const char **dest); -extern void git_die_config(const char *key); -extern void git_die_config_linenr(const char *key, const char *filename, int linenr); +extern NORETURN void git_die_config(const char *key); +extern NORETURN void git_die_config_linenr(const char *key, const char *filename, int linenr); extern int committer_ident_sufficiently_given(void); extern int author_ident_sufficiently_given(void); -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cache.h: add missing NORETURN on git_die_config*()
On 8/5/2014 7:27 PM, Ramsay Jones wrote: Commit 3a2a9527 (config: add `git_die_config()` to the config-set API, 01-08-2014) added git_die_config() and git_die_config_linenr() functions, but forgot to include the NORETURN attribute in their declarations. Sparse complains like so: SP config.c config.c:1567:6: error: symbol 'git_die_config_linenr' redeclared \ with different type (originally declared at cache.h:1419) \ - different modifiers config.c:1579:6: error: symbol 'git_die_config' redeclared with \ different type (originally declared at cache.h:1418) \ - different modifiers Suppress the sparse errors by adding NORETURN to the function declarations in the cache.h header file. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Tanay, If you need to re-roll the patches in the 'ta/config-set-1' branch, could you please squash this into the relevant patch. Thanks! Sorry, my bad. I will squash it in the relevant patch for my next re roll. Thanks, Tanay Abhra. -- 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 v7 5/8] config: add `git_die_config()` to the config-set API
On 8/5/2014 1:34 AM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com writes:
I was aping the old git_config() system, it also does exactly what you
described
above. for example, builtin/gc.c line 91,
if (!strcmp(var, gc.pruneexpire)) {
if (value strcmp(value, now)) {
unsigned long now = approxidate(now);
if (approxidate(value) = now)
return error(_(Invalid %s: '%s'), var, value);
}
would print,
error: Invalid gc.pruneexpire: 'value'
fatal: bad config variable 'gc.pruneexpire' at file line 15 in
.git/config
It's good to do at least as well as the old system, but I agree with
Junio that it's suboptimal.
Having a single API call to replace
error('%s' must be between 1 and 3);
git_config_die(key);
with stg like:
git_config_die(key, '%s' must be between 1 and 3);
Matthieu, I have finished the new version, but instead of flooding the mailing
list with
a series again, I wanted to confirm if the new git_config_die() is alright.
NORETURN __attribute__((format(printf, 2, 3)))
void git_die_config(const char *key, const char *err, ...)
{
const struct string_list *values;
struct key_value_info *kv_info;
if (err) {
va_list params;
va_start(params, err);
vreportf(error: , err, params);
va_end(params);
}
values = git_config_get_value_multi(key);
kv_info = values-items[values-nr - 1].util;
git_die_config_linenr(key, kv_info-filename, kv_info-linenr);
}
Currently works like the old git_config() error reporting path. If err is set
to NULL,
it would print no error message and just the die message. If given something
like,
git_config_die(key, value '%s' is not allowed, value);
it would print,
error: value '3' is not allowed
fatal: bad config variable 'core.frotz' at file line 15 in .git/config
Cheers,
Tanay Abhra.
in Junio's example would allow git_config_die to format the error
message the way it likes (i.e. it can be the same as before when you
introduce it, and improve afterwards).
I've never been disturbed by the quality of Git's error messages wrt
config files (it's not a compiler!), so having good quality messages is
not a high priority IMHO, but having a good API that as a side effect
can produce good error messages is important. If changing the error
messages requires rewritting all callers later, then we've missed the
point doing the refactoring now.
--
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 v7 5/8] config: add `git_die_config()` to the config-set API
Tanay Abhra tanay...@gmail.com writes:
Matthieu, I have finished the new version, but instead of flooding the
mailing list with
a series again, I wanted to confirm if the new git_config_die() is alright.
NORETURN __attribute__((format(printf, 2, 3)))
void git_die_config(const char *key, const char *err, ...)
{
const struct string_list *values;
struct key_value_info *kv_info;
if (err) {
va_list params;
va_start(params, err);
vreportf(error: , err, params);
va_end(params);
}
values = git_config_get_value_multi(key);
kv_info = values-items[values-nr - 1].util;
git_die_config_linenr(key, kv_info-filename, kv_info-linenr);
}
Currently works like the old git_config() error reporting path. If err is set
to NULL,
it would print no error message and just the die message. If given something
like,
git_config_die(key, value '%s' is not allowed, value);
it would print,
error: value '3' is not allowed
fatal: bad config variable 'core.frotz' at file line 15 in .git/config
That seems to be a good step forward.
I think we would also want to improve the error message, but that
shouldn't block your series from inclusion: we can do that later without
API change.
--
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: [PATCH v3 1/3] lockfile.c: remove PATH_MAX limitation (except in resolve_symlink)
On 08/04/2014 03:13 AM, Duy Nguyen wrote: On Sun, Aug 3, 2014 at 1:13 AM, Torsten Bögershausen tbo...@web.de wrote: [...] My first impression reading this patch was to rename clear_filename() into free_and_clear_filename() or better free_filename(), but I never pressed the send button ;-) Reading the discussion above makes me wonder if lk-filename may be replaced by a strbuf some day, and in this case clear_filename() will become reset_filenmae() ? I didn't realize Mike is making a lot more changes in lockfile.c, part of that is converting lk-filename to use strbuf [1]. Perhaps I should just withdraw this series, wait until Mike's series is merged, then redo 3/3 on top. Or Mike could just take 3/3 in as part of his series. [1] http://thread.gmane.org/gmane.comp.version-control.git/246222/focus=246232 I've neglected my patch series for ages (sorry!) The last round of review pointed out a couple of places where lock_file objects were still being left in undefined states, and since then it also bit-rotted. Over the past few days I re-rolled the patch series and fixed some more code paths. I still want to check it over before submitting it to the list, but if you are interested the current version is here [1]. Duy, I'll try to look at your patches, but probably won't get to it until next week when I return from vacation. Michael [1] https://github.com/mhagger/git branch lock-correctness -- Michael Haggerty mhag...@alum.mit.edu -- 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: [ANNOUNCE] Git v2.1.0-rc1
Ramsay Jones ram...@ramsay1.demon.co.uk writes: On 04/08/14 23:31, Junio C Hamano wrote: * The leaf function to check validity of a refname format has been micro-optimized, using SSE2 instructions when available. A few breakages during its development have been caught and fixed already but there might remain some more still; please test and report if you find any. This has been removed. Thanks for a reminder. Will drop. -- 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 v7 5/8] config: add `git_die_config()` to the config-set API
Matthieu Moy matthieu@grenoble-inp.fr writes: Tanay Abhra tanay...@gmail.com writes: Currently works like the old git_config() error reporting path. If err is set to NULL, it would print no error message and just the die message. If given something like, git_config_die(key, value '%s' is not allowed, value); it would print, error: value '3' is not allowed fatal: bad config variable 'core.frotz' at file line 15 in .git/config That seems to be a good step forward. I think we would also want to improve the error message, but that shouldn't block your series from inclusion: we can do that later without API change. Yup, I agree with your assessment. Thank you, both, for good polishing. -- 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] Release notes grammatical fixes.
Signed-off-by: Marc Branchaud marcn...@xiplink.com --- (Note that I did not reflow lines to keep them a specific length.) Documentation/RelNotes/2.1.0.txt | 108 +++ 1 file changed, 53 insertions(+), 55 deletions(-) diff --git a/Documentation/RelNotes/2.1.0.txt b/Documentation/RelNotes/2.1.0.txt index 5cfb0ab..4fd153e 100644 --- a/Documentation/RelNotes/2.1.0.txt +++ b/Documentation/RelNotes/2.1.0.txt @@ -12,7 +12,7 @@ Backward compatibility notes $ git config core.pager less -S to restore the traditional behaviour. It is expected that people - find output from the most subcommands easier to read with the new + find output from most subcommands easier to read with the new default, except for blame which tends to produce really long lines. To override the new default only for git blame, you can do this: @@ -31,7 +31,7 @@ UI, Workflows Features default value FRSX when we spawn less as the pager. S (chop long lines instead of wrapping) has been removed from this default set of options, because it is more or less a personal taste thing, - as opposed to others that have good justifications (i.e. R is + as opposed to the others that have good justifications (i.e. R is very much justified because many kinds of output we produce are colored and FX is justified because output we produce is often shorter than a page). @@ -39,47 +39,47 @@ UI, Workflows Features * The logic and data used to compute the display width needed for UTF-8 strings have been updated to match Unicode 7.0 better. - * HTTP-based transports learned to propagate the error messages from - the webserver better to the client coming over the HTTP transport. + * HTTP-based transports learned to better propagate the error messages from + the webserver to the client coming over the HTTP transport. * The completion script for bash (in contrib/) has been updated to - handle aliases that define complex sequence of commands better. + better handle aliases that define a complex sequence of commands. - * The core.preloadindex configuration variable is by default - enabled, allowing modern platforms to take advantage of the - multiple cores they have. + * The core.preloadindex configuration variable is enabled by default, + allowing modern platforms to take advantage of their + multiple cores. * git clone applies the if cloning from a local disk, physically - copy repository using hardlinks, unless otherwise told not to with - --no-local optimization when url.*.insteadOf mechanism rewrites a - git clone $URL that refers to a repository over the network to a + copy the repository using hardlinks, unless otherwise told not to with + --no-local optimization when the url.*.insteadOf mechanism rewrites a + remote-repository git clone $URL into a clone from a local disk. - * git commit --date=date option learned to read from more + * git commit --date=date option learned more timestamp formats, including --date=now. * The `core.commentChar` configuration variable is used to specify a - custom comment character other than the default # to be used in - the commit log editor. This can be set to `auto` to attempt to - choose a different character that does not conflict with what - already starts a line in the message being edited for cases like + custom comment character (other than the default #) for + the commit message editor. This can be set to `auto` to attempt to + choose a different character that does not conflict with any that + already starts a line in the message being edited, for cases like git commit --amend. - * git format-patch learned --signature-file=file to take the mail - signature from. + * git format-patch learned --signature-file=file to add the contents + of a file as a signature to the mail message it produces. - * git grep learned grep.fullname configuration variable to force - --full-name to be default. This may cause regressions on - scripted users that do not expect this new behaviour. + * git grep learned the grep.fullname configuration variable to force + --full-name to be the default. This may cause regressions for + scripted users who do not expect this new behaviour. * git imap-send learned to ask the credential helper for auth material. - * git log and friends now understand the value auto set to the + * git log and friends now understand the value auto for the log.decorate configuration variable to enable the --decorate option automatically when the output is sent to tty. - * git merge without argument, even when there is an upstream + * git merge without an argument, even when there is an upstream defined for the current branch, refused to run until merge.defaultToUpstream is set to true. Flip the default of that configuration variable to true. @@ -87,22 +87,20 @@ UI, Workflows Features * git mergetool
Re: [ANNOUNCE] Git v2.1.0-rc1
On 14-08-04 06:31 PM, Junio C Hamano wrote: * git grep learned grep.fullname configuration variable to force --full-name to be default. This may cause regressions on scripted users that do not expect this new behaviour. Should this be noted in the backward compatibility notes? M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] l10n: de.po: translate 38 new messages
Translate 38 new messages came from git.pot update in fe05e19 (l10n: git.pot: v2.1.0 round 1 (38 new, 9 removed)). Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 131 ++- 1 file changed, 62 insertions(+), 69 deletions(-) diff --git a/po/de.po b/po/de.po index b8fb23f..ffc556c 100644 --- a/po/de.po +++ b/po/de.po @@ -21,20 +21,18 @@ msgstr #, c-format msgid hint: %.*s\n msgstr Hinweis: %.*s\n #: advice.c:88 -#, fuzzy msgid Fix them up in the work tree, and then use 'git add/rm file'\n as appropriate to mark resolution and make a commit, or use\n 'git commit -a'. msgstr -Korrigieren Sie dies im Arbeitsverzeichnis,\n -und benutzen Sie dann 'git add/rm Datei'\n -um die Aufl??sung entsprechend zu markieren und zu committen,\n -oder benutzen Sie 'git commit -a'. +Korrigieren Sie dies im Arbeitsverzeichnis, und benutzen Sie\n +dann 'git add/rm Datei' um die Aufl??sung entsprechend zu markieren\n +und zu committen, oder benutzen Sie 'git commit -a'. #: archive.c:10 msgid git archive [options] tree-ish [path...] msgstr git archive [Optionen] Commit-Referenz [Pfad...] @@ -467,15 +465,15 @@ msgstr %s #: diff.c:2934 #, c-format msgid external diff died, stopping at %s -msgstr +msgstr externes Diff-Programm unerwartet beendet, angehalten bei %s #: diff.c:3329 msgid --follow requires exactly one pathspec -msgstr +msgstr --follow erfordert genau eine Pfadspezifikation #: diff.c:3492 #, c-format msgid Failed to parse --dirstat/-X option parameter:\n @@ -1139,13 +1137,12 @@ msgstr Ihre lokalen ??nderungen w??rden von \revert\ ??berschrieben werden. msgid Commit your changes or stash them to proceed. msgstr Tragen Sie Ihre ??nderungen ein oder benutzen Sie \stash\ um fortzufahren. #: sequencer.c:250 -#, fuzzy msgid Failed to lock HEAD during fast_forward_to -msgstr Fehler beim Sperren der Referenz zur Aktualisierung. +msgstr Fehler beim Sperren von HEAD w??hrend fast_forward_to #. TRANSLATORS: %s will be revert or cherry-pick #: sequencer.c:293 #, c-format msgid %s: Unable to write new index file @@ -2737,13 +2734,12 @@ msgstr Verarbeitet nur Zeilen im Bereich n,m, gez??hlt von 1 #. output. For C locale, 4 years, 11 months ago, which #. takes 22 places, is the longest among various forms of #. relative timestamps, but your language may need more or #. fewer display columns. #: builtin/blame.c:2599 -#, fuzzy msgid 4 years, 11 months ago -msgstr %s, und %lu Monat +msgstr vor 4 Jahren, und 11 Monaten #: builtin/branch.c:24 msgid git branch [options] [-r | -a] [--merged | --no-merged] msgstr git branch [Optionen] [-r | -a] [--merged | --no-merged] @@ -4247,13 +4243,13 @@ msgstr Ung??ltiger Commit: %s #: builtin/commit.c:585 msgid malformed --author parameter msgstr Fehlerhafter --author Parameter #: builtin/commit.c:592 -#, fuzzy, c-format +#, c-format msgid invalid date format: %s -msgstr Ung??ltiger Commit: %s +msgstr Ung??ltiges Datumsformat: %s #: builtin/commit.c:609 #, c-format msgid Malformed ident string: '%s' msgstr Fehlerhafter Ident-String: '%s' @@ -4261,10 +4257,12 @@ msgstr Fehlerhafter Ident-String: '%s' #: builtin/commit.c:642 msgid unable to select a comment character that is not used\n in the current commit message msgstr +Konnte kein Kommentar-Zeichen ausw??hlen, das nicht in\n +der aktuellen Commit-Beschreibung verwendet wird. #: builtin/commit.c:679 builtin/commit.c:712 builtin/commit.c:1086 #, c-format msgid could not lookup commit %s msgstr Konnte Commit %s nicht nachschlagen @@ -4352,23 +4350,23 @@ msgstr mit '%c' beginnen, werden beibehalten; wenn Sie m??chten, k??nnen Sie diese entfernen.\n Eine leere Beschreibung bricht den Commit ab.\n #: builtin/commit.c:855 -#, fuzzy, c-format +#, c-format msgid %sAuthor:%.*s %.*s -msgstr %sAutor:%s +msgstr %sAutor: %.*s %.*s #: builtin/commit.c:863 -#, fuzzy, c-format +#, c-format msgid %sDate: %s -msgstr %sAutor:%s +msgstr %sDatum:%s #: builtin/commit.c:870 -#, fuzzy, c-format +#, c-format msgid %sCommitter: %.*s %.*s -msgstr %sCommit-Ersteller: %s +msgstr %sCommit-Ersteller: %.*s %.*s #: builtin/commit.c:888 msgid Cannot read index msgstr Kann Staging-Area nicht lesen @@ -5079,15 +5077,15 @@ msgstr Benutzt die \done\-Funktion um den Strom abzuschlie??en msgid Skip output of blob data msgstr ??berspringt Ausgabe von Blob-Daten #: builtin/fast-export.c:720 msgid refspec -msgstr +msgstr Refspec #: builtin/fast-export.c:721 msgid Apply refspec to exported refs -msgstr +msgstr Wendet Refspec auf exportierte Referenzen an #: builtin/fetch.c:20 msgid git fetch [options] [repository [refspec...]] msgstr git fetch [Optionen] [Repository [Refspec...]] @@ -5178,15 +5176,15 @@ msgstr Standard-Modus f??r Rekursion msgid accept refs that update .git/shallow msgstr akzeptiert Referenzen die .git/shallow aktualisieren
Re: [PATCH v2 1/1] doc: format-patch: don't use origin as a branch name
Philip Oakley philipoak...@iee.org writes: From: Junio C Hamano gits...@pobox.com ... Nowhere I am assuming that the reader is creating paches based on wherever someone else had got to. Sorry, but I have no idea what you are complaining about. I think we are talking at cross purposes. My starting point is that (the examples says that) the reader wants to create a patch series for a local branch, relative to their some name branch which they branched from... Perhaps what you are missing is that the 'origin' in that example is not their some name branch. It is how we used to spell what we call 'refs/remotes/origin/HEAD' these days, a copy of their upstream repository's primary branch. (e.g. the example, relative to Git, could have been from branched from (e.g. the example, relative to Git, could have been from a 'pu' picked up a couple of days earlier, when they'd have said 'git format-patch pu' ;-). Again, if that were a 'pu' picked up a few days earlier, it would not be 'pu', but be 'origin/pu'. The primary reason why 'origin' in the example should be replaced with 'origin/master' is because that is the literal adjustment from the pre-separate-remote world order to today's world order. I was trying to avoid a literal adjustment to what I'd perceived as a presumed workflow. These are examples, showing uses of commands in some hopefully common scenarios. I am not exactly sure what you are aiming at, but if you are trying to strip context and/or background from them and trying to limit them purely to If you do X, Y happens, the resulting description would lack clues that readers rely on in order to choose the usage pattern of the command that is suitable for their situation, which I do not think is a good change to make. The readers would be helped more with You are in state A and want to achieve B. If you do X starting from state A, Y happens, which helps you achieve B., and that is what examples are about. Now, these where you are and what you want to do may not be explicitly spelled out to avoid redundancy, and it may be an improvement to enhance the scenario without making them too narrow. But that would be a separate change, and renaming 'origin' (whose modern equivalent is 'origin/master' in the context of these examples) to 'master' alone would not do any such enhancement. The local branch 'origin' (more specifically, 'refs/heads/origin') used to be what we used to keep track of 'master' of the upstream, which we use 'refs/remotes/origin/master' these days. Side note: DWIMming origin to remotes/origin/HEAD to remotes/origin/master was invented to keep supporting this 'origin' keeps track of the default upstream convention when we transitioned from the old world order to separate-remote layout. And the reason why 'origin' should not be replaced with 'master' is because your 'master' may already have patches from the topic you are working on, i.e. in your current branch, that the upstream does not yet have. So this a 'develop on master' view, rather than a 'develop on feature branches' approach? Which could explain the misunderstanding. The new work on the feature branches may be merged in 'master' without ever intending to push 'master' out. The development is still done on the topic branches that are merged to your local 'master', perhaps for testing purposes and most likely to personally use it before the upstream picks them up. I suspect your misunderstanding is primarily coming from that you may have forgotten, or you may be too new to know, that 'origin' in the example, 'refs/heads/origin', used to be how we tracked the primary branch of the other side back in the era when these examples were written, and refs/remotes/origin/master is used for the same tracking these 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: [ANNOUNCE] Git v2.1.0-rc1
Marc Branchaud marcn...@xiplink.com writes: On 14-08-04 06:31 PM, Junio C Hamano wrote: * git grep learned grep.fullname configuration variable to force --full-name to be default. This may cause regressions on scripted users that do not expect this new behaviour. Should this be noted in the backward compatibility notes? I debated it myself, but decided that it was minor enough (in the sense that it is obvious when it breaks and it also is obvious how to adjust the script in a way that is also compatible with older versions of Git). Thanks for a careful reading. -- 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] Release notes grammatical fixes.
Marc Branchaud marcn...@xiplink.com writes: Signed-off-by: Marc Branchaud marcn...@xiplink.com diff --git a/Documentation/RelNotes/2.1.0.txt b/Documentation/RelNotes/2.1.0.txt Many are indeed grammatical errors, and many others make the result easier to read, even if the original weren't incorrect per-se. @@ -87,22 +87,20 @@ UI, Workflows Features * git mergetool learned to drive the vimdiff3 backend. * mergetool.prompt used to default to 'true', always asking do you - really want to run the tool on this path?. Among the two - purposes this prompt serves, ignore the use case to confirm that - the user wants to view particular path with the named tool, and - redefine the meaning of the prompt only to confirm the choice of - the tool made by the autodetection (for those who configured the - tool explicitly, the prompt shown for the latter purpose is - simply annoying). - - Strictly speaking, this is a backward incompatible change and the + really want to run the tool on this path?. The default has been + changed to 'false'. However, the prompt will still appear if + mergetool used its autodetection system to guess which tool to use. + Users who explicitly specify or configure a tool will no longer see + the prompt by default. + + Strictly speaking, this is a backward incompatible change and users need to explicitly set the variable to 'true' if they want - to resurrect the now-ignored use case. + to resurrect the old behaviour. I however think you are losing information here. It is unclear in the rewritten one why you would ever want the old behaviour, i.e. what you may be missing by following along with this change. 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: [PATCH] pack-bitmap: do not use gcc packed attribute
On Mon, Aug 4, 2014 at 9:19 PM, Karsten Blees karsten.bl...@gmail.com wrote: This raises the question why we read via mmap at all The first version of the pack bitmap format I wrote for GitHub was 50% faster to load than this one because it was designed to be mmapable. Eventually we moved to the JGit-compatible bitmap format (because I get paid a lot of money to do as I'm told -- not because of some inherent benefit of the JGit format), which needs to be read sequentially, but I never bothered to change the mmap reading code. I believe your patch makes a lot of sense -- at this point we could as well remove the mmaping altogether and read the file sequentially. Cheers, vmg -- 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] Release notes grammatical fixes.
Junio C Hamano gits...@pobox.com writes: Marc Branchaud marcn...@xiplink.com writes: ... @@ -87,22 +87,20 @@ UI, Workflows Features * git mergetool learned to drive the vimdiff3 backend. * mergetool.prompt used to default to 'true', always asking do you - really want to run the tool on this path?. Among the two - purposes this prompt serves, ignore the use case to confirm that - the user wants to view particular path with the named tool, and - redefine the meaning of the prompt only to confirm the choice of - the tool made by the autodetection (for those who configured the - tool explicitly, the prompt shown for the latter purpose is - simply annoying). - - Strictly speaking, this is a backward incompatible change and the + really want to run the tool on this path?. The default has been + changed to 'false'. However, the prompt will still appear if + mergetool used its autodetection system to guess which tool to use. + Users who explicitly specify or configure a tool will no longer see + the prompt by default. + + Strictly speaking, this is a backward incompatible change and users need to explicitly set the variable to 'true' if they want - to resurrect the now-ignored use case. + to resurrect the old behaviour. I however think you are losing information here. It is unclear in the rewritten one why you would ever want the old behaviour, i.e. what you may be missing by following along with this change. Perhaps this on top of yoru patch? Documentation/RelNotes/2.1.0.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes/2.1.0.txt b/Documentation/RelNotes/2.1.0.txt index 4fd153e..1b16b12 100644 --- a/Documentation/RelNotes/2.1.0.txt +++ b/Documentation/RelNotes/2.1.0.txt @@ -95,7 +95,7 @@ UI, Workflows Features Strictly speaking, this is a backward incompatible change and users need to explicitly set the variable to 'true' if they want - to resurrect the old behaviour. + to be prompted to confirm running the tool on each path. * git replace learned the --edit subcommand to create a replacement by editing an existing object. -- 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] pack-bitmap: do not use gcc packed attribute
On Mon, Aug 04, 2014 at 09:19:46PM +0200, Karsten Blees wrote: Hmm, I wonder if it wouldn't be simpler to read / write the desired on-disk structure directly, without copying to a uchar[6] first. Probably. My initial attempt was to keep together the read/write logic about which sizes each item is, but I think the result ended up unnecessarily verbose and harder to follow. Here's what I came up with (just a sketch, commit message is lacky and the helper functions deserve a better place / name): I like it. Want to clean it up and submit in place of mine? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: struct hashmap_entry packing
On Mon, Aug 04, 2014 at 09:20:02PM +0200, Karsten Blees wrote: I don't see any reason to avoid the packed attribute, if it helps us. As you noted, anything using __attribute__ probably supports it, and if not, we can conditionally #define PACKED_STRUCT or something, like we do for NORETURN. Since it's purely an optimization, if another compiler doesn't use it, no big deal. That being said, I don't know if those padding bytes are actually causing a measurable slowdown. It may not even be worth the trouble. Its not about performance (or correctness, in case of platforms that don't support unaligned read), just about saving memory (e.g. mapping int to int requires 24 bytes per entry, vs. 16 with packed structs). The biggest things we might map are probably one entry per-object. So in a repository like linux.git, we're talking about 32MB in the worst case. That's not nothing, but it's also not the end of the world. I'd be more concerned with how that trashes the cache (and consequently causes slowdown) than somebody running out of memory. So my general opinion is that if it's easy to get the space back, great. But if it creates a maintenance hassle, it's not worth the effort. That said, I really don't think it would be much maintenance hassle to mark the hashmap_entry as packed, and compilers can either handle it or not. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Feature request] git add -i should have option for showing more context
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, In git add -i when staging the modifications piecemail by patching there should be a command for showing more context. It can be sometimes difficult to determine whether any hunk should be staged without refering to more source code. As a command I mean a choice in the following list: Stage this hunk [y,n,q,a,d,/,e,?]? ? y - stage this hunk n - do not stage this hunk q - quit; do not stage this hunk nor any of the remaining ones a - stage this hunk and all later hunks in the file d - do not stage this hunk nor any of the later hunks in the file g - select a hunk to go to / - search for a hunk matching the given regex j - leave this hunk undecided, see next undecided hunk J - leave this hunk undecided, see next hunk k - leave this hunk undecided, see previous undecided hunk K - leave this hunk undecided, see previous hunk s - split the current hunk into smaller hunks e - manually edit the current hunk ? - print help - -- Pozdrawiam, Mateusz Jończyk AEI, Informatyka, Semestr 3 Magisterskich, BDiIS -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: My public key: 0x2C64C488 on hkp://pool.sks-keyservers.net iQEcBAEBAgAGBQJT4SKmAAoJELLT9LcsZMSI+WMH/1DoOuBFsDLjDF9zMFmeGbGf bYDEgpMgCWVHT+v9YMoY41ZMLOABni+7E4yvym/x5mO00Q4LPsXfDTNeHC7LEcgJ uDLS9Lx3A3eXoqZFsIsXKY6+SHr8RU8UJRdppVakMq2novitzJrAjt3HZUO5ai8n bmWIF3HBNZcKHfVQSGuBCNB1ZWxlKv7gRPl/RFeCv+Z9kiYKUO/TXMEya3mxXFd3 3u7XEJw5G4KyN7ySVH6kRKcCIp6L0cRhKtyuFILs7EMO5e59HYr2JKpParnc0CXd gU1rVCwYW2GL6cDekabWoffxuKSCTg74IeI5Gu0oTyYeK3N93yPJudGgTLMqHGM= =Kl4N -END PGP SIGNATURE- -- 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: Everyday contents (was Re: What's cooking in git.git (Jul 2014, #04; Tue, 22))
Continued: this message covers the last part.
| Repository Administration[[Repository Administration]]
| --
|
| A repository administrator uses the following tools to set up
| and maintain access to the repository by developers.
|
| * linkgit:git-daemon[1] to allow anonymous download from
| repository.
|
| * linkgit:git-shell[1] can be used as a 'restricted login shell'
| for shared central repository users.
|
| link:howto/update-hook-example.html[update hook howto] has a good
| example of managing a shared central repository.
This part is fairly stale. We only talk about allowing anonymous
fetching via git-daemon and pushing via git-over-ssh. The readers
would want to be aware that they can set up their hosts for fetching
and pushing via git-over-http aka Smart http, and browsing via
gitweb. We should definitely at least mention these, and we may
even want to describe them at the same level of detail as the
existing examples.
I wonder if we also want to mention (but not describe, just make the
readers aware of) widely deployed hosting/browsing solutions such as
gitolite, gerrit code review, and cgit.
Do tasks that are described here have impact on the use of these
third-party tools? For example, I understand gitolite does not
require one UNIX user per biological human user, but the vanilla
push-over-ssh described in these examples does. I guess the burden
of telling the users to unlearn everything you read about setting
up the vanilla git-over-ssh when you use gitolite falls on gitolite
doc, so in that sense we shouldn't have to worry about doing any of
that here.
| Examples
|
| We assume the following in /etc/services::
| +
|
| $ grep 9418 /etc/services
| git 9418/tcp# Git Version Control System
|
OK.
| Run git-daemon to serve /pub/scm from inetd.::
| +
|
| $ grep git /etc/inetd.conf
| git stream tcp nowait nobody \
| /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
|
| +
| The actual configuration line should be on one line.
OK.
| Run git-daemon to serve /pub/scm from xinetd.::
| +
|
| $ cat /etc/xinetd.d/git-daemon
| # default: off
| # description: The Git server offers access to Git repositories
| service git
| {
| disable = no
| type= UNLISTED
| port= 9418
| socket_type = stream
| wait= no
| user= nobody
| server = /usr/bin/git-daemon
| server_args = --inetd --export-all --base-path=/pub/scm
| log_on_failure += USERID
| }
|
| +
| Check your xinetd(8) documentation and setup, this is from a Fedora system.
| Others might be different.
OK, but which vintage of Fedora? ;-)
| Give push/pull only access to developers.::
This entry may mislead the readers if the access this section
talks about is to the git-daemon we just set up in the above. We
should clarify that this is about git-over-ssh access, i.e. the
users will be doing this:
$ git push/pull host.xz:/pub/scm/project
or
$ git push/pull ssh://host.xz/pub/scm/project
or somesuch.
| +
|
| $ grep git /etc/passwd 1
| alice:x:1000:1000::/home/alice:/usr/bin/git-shell
| bob:x:1001:1001::/home/bob:/usr/bin/git-shell
| cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
| david:x:1003:1003::/home/david:/usr/bin/git-shell
| $ grep git /etc/shells 2
| /usr/bin/git-shell
|
| +
| 1 log-in shell is set to /usr/bin/git-shell, which does not
| allow anything but `git push` and `git pull`. The users should
| get an ssh access to the machine.
| 2 in many distributions /etc/shells needs to list what is used
| as the login shell.
One possible mis-interpretation of 1 is Thanks to these git-shell
entries, the users will get `push/pull` accesses to the box; they
separately need ssh access to the box (to do something more than
that, if desired).
In reality, this configuration _requires_ them to have an ssh access
to the box and these entries restricts them to only run push/pull
against the host. We may want to rephrase to clarify.
| CVS-style shared repository.::
| +
|
| $ grep git /etc/group 1
| git:x:9418:alice,bob,cindy,david
| $ cd /home/devo.git
| $ ls -l 2
| lrwxrwxrwx 1 david git17 Dec 4 22:40 HEAD - refs/heads/master
| drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches
| -rw-rw-r-- 1 david git84 Dec 4 22:40 config
| -rw-rw-r-- 1 david git58 Dec 4 22:40 description
| drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks
| -rw-rw-r-- 1 david git 37504 Dec 4 22:40 index
| drwxrwsr-x 2 david git 4096 Dec 4 22:40 info
| drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects
| drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs
| drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes
| $ ls -l hooks/update 3
|
Re: [PATCH v3] imap-send doc: omit confusing to use imap-send modifier
brian m. carlson sand...@crustytoothpaste.net writes: It wouldn't make sense for these configuration variables to be required for Git in general to function. 'Required' in this context means required for git imap-send to work. Noticed while trying to figure out what the sentence describing imap.tunnel meant. [jn: expanded to also simplify explanation of imap.folder and imap.host in the same way] Signed-off-by: brian m. carlson sand...@crustytoothpaste.net Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- Thanks, both. Will queue and squash the required. otherwise. fix in. Documentation/git-imap-send.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt index 875d283..d3b465d 100644 --- a/Documentation/git-imap-send.txt +++ b/Documentation/git-imap-send.txt @@ -38,17 +38,17 @@ Variables imap.folder:: The folder to drop the mails into, which is typically the Drafts folder. For example: INBOX.Drafts, INBOX/Drafts or - [Gmail]/Drafts. Required to use imap-send. + [Gmail]/Drafts. Required. imap.tunnel:: Command used to setup a tunnel to the IMAP server through which commands will be piped instead of using a direct network connection - to the server. Required when imap.host is not set to use imap-send. + to the server. Required when imap.host is not set. imap.host:: A URL identifying the server. Use a `imap://` prefix for non-secure connections and a `imaps://` prefix for secure connections. - Ignored when imap.tunnel is set, but required to use imap-send + Ignored when imap.tunnel is set, but required. otherwise. imap.user:: -- 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] rebase: introduce rebase.preserve configuration option
There are several ways to configure Git to preserve merges.
There is pull.rebase=preserve for all branches and
branch.name.rebase=preserve for individual branches.
However, there is no configuration option to preserve merges
for all branches when running git-rebase.
This patch introduces a new configuration variable
rebase.preserve. If set to true, --preserve-merges option
will be enabled in git-rebase by default.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
Documentation/config.txt | 3 +++
git-rebase.sh | 1 +
t/t3409-rebase-preserve-merges.sh | 20
3 files changed, 24 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c08286e..4166be0 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2031,6 +2031,9 @@ rebase.autostash::
successful rebase might result in non-trivial conflicts.
Defaults to false.
+rebase.preserve::
+ If set to true enable '--preserve-merges' option by default.
+
receive.autogc::
By default, git-receive-pack will run git-gc --auto after
receiving data from git-push and updating refs. You can stop
diff --git a/git-rebase.sh b/git-rebase.sh
index 47ca3b9..e0b3e05 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -83,6 +83,7 @@ state_dir=
# One of {'', continue, skip, abort}, as parsed from command line
action=
preserve_merges=
+test $(git config --bool rebase.preserve) = true preserve_merges=t
interactive_rebase=implied
autosquash=
keep_empty=
test $(git config --bool rebase.autosquash) = true autosquash=t
diff --git a/t/t3409-rebase-preserve-merges.sh
b/t/t3409-rebase-preserve-merges.sh
index 8c251c5..3a02240 100755
--- a/t/t3409-rebase-preserve-merges.sh
+++ b/t/t3409-rebase-preserve-merges.sh
@@ -76,6 +76,16 @@ test_expect_success 'setup for merge-preserving rebase' \
git merge --no-ff topic2
)
+ git clone ./. clone5
+ (
+ cd clone5
+ git checkout -b topic2 origin/topic
+ echo Sixth A
+ git commit -a -m Modify A3
+ git checkout -b topic origin/topic
+ git merge --no-ff topic2
+ )
+
git checkout topic
echo Fourth B
git commit -a -m Modify B2
@@ -119,4 +129,14 @@ test_expect_success 'rebase -p ignores merge.log config' '
)
'
+test_expect_success 'config rebase.preserve preserves no-ff merges' '
+ (
+ cd clone5
+ git fetch
+ git -c rebase.preserve=true rebase origin/topic
+ test 3 = $(git rev-list --all --pretty=oneline | grep Modify A | wc
-l)
+ test 1 = $(git rev-list --all --pretty=oneline | grep Merge branch |
wc -l)
+ )
+'
+
test_done
--
2.1.0.rc1.205.gf9880d1
--
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: Everyday contents (was Re: What's cooking in git.git (Jul 2014, #04; Tue, 22))
From: Junio C Hamano gits...@pobox.com Continued: this message covers the last part. | Repository Administration[[Repository Administration]] | -- | | A repository administrator uses the following tools to set up | and maintain access to the repository by developers. ... Thanks for this final part. I'd just updated the original patch and split it into three steps: 1. update the everday text in it's current place, 2. tweak the Makefile for the Obsolete_Html list ready for next patch 3. swap over to the giteveryday file nameing and fix the linked docs. I'll add in your guidance on the last part to my patch 1. Many thanks. -- Philip -- 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
Pluggable backends for refs,wip
List, Michael, Please see https://github.com/rsahlberg/git/tree/backend-struct-db-2 for an example of a pluggable backend for refs storage. This series contain changes to make it possible to add new backends for handling/storage of refs and implements one new backend : refs-be-be.c . This new backend offloads the actual refs handling to a small database daemon with which ita talks via a very simple rpc protocol. That daemon in turn then connects to the datastore and read/writes the values to it. By having an always running database daemon it will allow faster startup of the git commands since they will now only need to connect to a domain socket instead of having to traverse a potentially very large number of files during the build ref cache phase. Another nice feature is that it can allow running one single database daemon and use it to host the refs for multiple independent git repositoris (by using the new repository name config to distinguish between them). It can not yet apply to origin/* since it is based on some small series that have yet not arrived there and is still a wip. But if you want to test/look at what we could be doing one day, please feel free to clone this repo. FAQ: Q: This sound cool. How do I test this? A: 1, Clone https://github.com/rsahlberg/git/tree/backend-struct-db-2 and build git. 2, gcc refsd-tdb.c -o refsd-tdb -l tdb 3, ./refsd-tdb /tmp/refsd.socket /tmp /tmp/refsd.log 4, git clone --db-repo-name=ROCKet --db-socket=/tmp/refsd.socket some-repo foo ./foo should now contain a git repository that store its refs in a separate database. (teh databases are store under /tmp so don't use this for anything important because bad things happens to things stored under /tmp) regards ronnie sahlberg -- 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: Pluggable backends for refs,wip
Personally (a user of, not a maintainer of, git) I really want some alternative backends. In particular I'm after something like Fossil's use of SQLite3; I want a SQLite3 backend for several reasons, not the least of which is the power of SQL for looking at history. I'm not sure that I necessarily want a daemon/background process. I get the appeal (add inotify and bingo, very fast git status, always), but it seems likely to add obnoxious failure modes. As to a SQLite3-type backend, I am of two minds: either add it as a bolt-on to the builtin backend, or add it as a first-class backend that replaces the builtin one. The former is nice because the SQLite3 DB becomes more of a cache/index and query engine than a store, and can be used without migrating any repos, but the latter is also nice because SQLite3 provides strong ACID transactional semantics on local filesystems. Nico -- -- 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] Release notes grammatical fixes.
On 14-08-05 02:43 PM, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Marc Branchaud marcn...@xiplink.com writes: ... @@ -87,22 +87,20 @@ UI, Workflows Features * git mergetool learned to drive the vimdiff3 backend. * mergetool.prompt used to default to 'true', always asking do you - really want to run the tool on this path?. Among the two - purposes this prompt serves, ignore the use case to confirm that - the user wants to view particular path with the named tool, and - redefine the meaning of the prompt only to confirm the choice of - the tool made by the autodetection (for those who configured the - tool explicitly, the prompt shown for the latter purpose is - simply annoying). - - Strictly speaking, this is a backward incompatible change and the + really want to run the tool on this path?. The default has been + changed to 'false'. However, the prompt will still appear if + mergetool used its autodetection system to guess which tool to use. + Users who explicitly specify or configure a tool will no longer see + the prompt by default. + + Strictly speaking, this is a backward incompatible change and users need to explicitly set the variable to 'true' if they want - to resurrect the now-ignored use case. + to resurrect the old behaviour. I however think you are losing information here. It is unclear in the rewritten one why you would ever want the old behaviour, i.e. what you may be missing by following along with this change. Perhaps this on top of yoru patch? Yes, I think that's good, thanks. M. Documentation/RelNotes/2.1.0.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes/2.1.0.txt b/Documentation/RelNotes/2.1.0.txt index 4fd153e..1b16b12 100644 --- a/Documentation/RelNotes/2.1.0.txt +++ b/Documentation/RelNotes/2.1.0.txt @@ -95,7 +95,7 @@ UI, Workflows Features Strictly speaking, this is a backward incompatible change and users need to explicitly set the variable to 'true' if they want - to resurrect the old behaviour. + to be prompted to confirm running the tool on each path. * git replace learned the --edit subcommand to create a replacement by editing an existing object. -- 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/7] Documentation: git-init: typographical fixes
Linus Arver linusar...@gmail.com writes: Signed-off-by: Linus Arver linusar...@gmail.com --- Documentation/git-init.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index afd721e..5ed5859 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -43,7 +43,7 @@ OPTIONS -q:: --quiet:: -Only print error and warning messages, all other output will be suppressed. +Only print error and warning messages; all other output will be suppressed. OK. --bare:: @@ -97,7 +97,7 @@ is given: create a repo that is readable and writable to the current user and group, but inaccessible to others. -By default, the configuration flag receive.denyNonFastForwards is enabled +By default, the configuration flag 'receive.denyNonFastForwards' is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it. If you are going to quote something that the user should literally use, it is probably better to use `backticks` so that the quoted contents will be typeset in monospaced typewriter-font. @@ -113,7 +113,7 @@ TEMPLATE DIRECTORY The template directory contains files and directories that will be copied to the `$GIT_DIR` after it is created. -The template directory used will (in order): +The template directory used will be (in order): - The argument given with the `--template` option. OK. 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: [PATCH 3/7] Documentation: git-init: template directory: reword
Linus Arver linusar...@gmail.com writes: Signed-off-by: Linus Arver linusar...@gmail.com --- This seems to reword and also reformat at the same time, but was the latter change (i.e. to unindent the bulletted items and to remove blank lines between items) necessary? Documentation/git-init.txt | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index 45501d0..f21b85b 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -113,22 +113,18 @@ line, the command is run inside the directory (possibly after creating it). -- - TEMPLATE DIRECTORY -- The template directory contains files and directories that will be copied to the `$GIT_DIR` after it is created. -The template directory used will be (in order): - - - The argument given with the `--template` option. - - - The contents of the `$GIT_TEMPLATE_DIR` environment variable. - - - The `init.templatedir` configuration variable. +The template directory will be one of the following (in order): - - The default template directory: `/usr/share/git-core/templates`. +- the argument given with the `--template` option; +- the contents of the `$GIT_TEMPLATE_DIR` environment variable; +- the `init.templatedir` configuration variable; or +- the default template directory: `/usr/share/git-core/templates`. The default template directory includes some directory structure, some suggested exclude patterns, and copies of sample hook 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: [PATCH 4/7] Documentation: git-init: --separate-git-dir: clarify
Linus Arver linusar...@gmail.com writes: Signed-off-by: Linus Arver linusar...@gmail.com --- You would need to work on your justification skills ;-) in the log message. What does this change clarify and in what way? Documentation/git-init.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index f21b85b..bf0a7ae 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -57,12 +57,12 @@ DIRECTORY section below.) --separate-git-dir=git dir:: -Instead of initializing the repository where it is supposed to be, -place a filesytem-agnostic Git symbolic link there, pointing to the -specified path, and initialize a Git repository at the path. The -result is Git repository can be separated from working tree. If this -is reinitialization, the repository will be moved to the specified -path. +Separate the Git repository from your working tree. Instead of initializing the +repository as a directory to either `$GIT_DIR` or `./.git/`, create a text file +there containing the path to the actual repository. This file acts as +filesystem-agnostic Git symbolic link to the repository. ++ +If this is reinitialization, the repository will be moved to the specified path. --shared[=(false|true|umask|group|all|world|everybody|0xxx)]:: -- 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 7/7] Documentation: git-init: flesh out example
Linus Arver linusar...@gmail.com writes: Signed-off-by: Linus Arver linusar...@gmail.com --- Documentation/git-init.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index b94d165..16e9f9c 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -138,10 +138,12 @@ Start a new Git repository for an existing code base:: $ cd /path/to/my/codebase $ git init 1 $ git add . 2 +$ git commit3 I agree it is a good discipline to make the initial pristine import immediately after git add . without doing anything else. Perhaps the description below wants to make it more explicit? + -1 prepare /path/to/my/codebase/.git directory -2 add all existing file to the index +1 Create a /path/to/my/codebase/.git directory. +2 Add all existing files to the index. +3 Create the first root-commit. GIT --- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pluggable backends for refs,wip
On Tue, Aug 5, 2014 at 2:56 PM, Nico Williams n...@cryptonector.com wrote: Personally (a user of, not a maintainer of, git) I really want some alternative backends. In particular I'm after something like Fossil's use of SQLite3; I want a SQLite3 backend for several reasons, not the least of which is the power of SQL for looking at history. I'm not sure that I necessarily want a daemon/background process. I get the appeal (add inotify and bingo, very fast git status, always), but it seems likely to add obnoxious failure modes. As to a SQLite3-type backend, I am of two minds: either add it as a bolt-on to the builtin backend, or add it as a first-class backend that replaces the builtin one. The former is nice because the SQLite3 DB becomes more of a cache/index and query engine than a store, and can be used without migrating any repos, but the latter is also nice because SQLite3 provides strong ACID transactional semantics on local filesystems. This will allow you to do either or both, depending on what you want. I am adding one new first-class backend to talk to a separate daemon : refs-be-db.c which then talks to a separate daemon refsd-tdb.c refsd-tdb.c is 7 RPCs and ~500 lines of code for a naive implementation for a standalone separate daemon implementation. If you rather want want a new first-class backend builtin to git itself instead of as a separate daemon, then that will be possible too. It just means that you will have to base the work on refs-be-db.c which is a much larger and complex code base than refsd-tdb.c. But yeah, once this work is finished, you will be able to build new first-class ref backends if you so wish. Please see refs-be-db.c that is the file and the methods you will need to implement in order to have a first-class SQL* backend. regards ronnie sahlberg -- 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: Pluggable backends for refs,wip
Excellent. 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: [PATCH] Documentation/config.txt: change pull.rebase description in favor of safer 'preserve' option.
Sergey Organov sorga...@gmail.com writes: Previous description implicitly favored 'true' value for pull.rebase and pull.branch.rebase options, I do not share that impression. It is true that 'true' is described first before 'preserve', which can be argued that it is being implicitly favoured, but we have to pick one over the other when describing two things, so I do not see it as a strong preference. when for some workflows 'preserve' is the right choice, and for others it hardly makes any difference. Therefore, 'preserve' should be preferred in general, unless the user knows exactly what she is doing. I doubt we saw any such conclusion in the recent thread that discussed this, other than your repeating that statement---and I've learned to tell repeated voices and chorus apart over time ;-). One approach is more suitable for some workflows while being inappropriate for others and that goes for both variants. A downside of flattening is that it gives a wrong result when the user wants to keep merges. Two downsides of preserving are that it gives a wrong result when the user wants to flatten, and it tends to be slower. During that discussion, you seemed to assume that those who want a flattened end result would never merge locally; I do not think that is true. Having your own merges on a branch that you would want to rebase to flatten is not unusual. You may employ a workflow to build on separate topic branches while developing, merge the topics among them that are ready into your local 'master' to be used personally, and after using it from your local 'master' for a while to make sure it is solid, you may decide to make it final by publishing it to the outside world, and at that point you would want to flatten the history on top of the latest upstream before pushing. That's not anything advanced that takes the user knows exactly what she is doing. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rebase: introduce rebase.preserve configuration option
Ralf Thielow ralf.thie...@gmail.com writes: There are several ways to configure Git to preserve merges. There is pull.rebase=preserve for all branches and branch.name.rebase=preserve for individual branches. However, there is no configuration option to preserve merges for all branches when running git-rebase. How should this interact with pull.rebase? Specifically, what should happen with these settings? [rebase] preserve = true [pull] rebase = true Historically, the variable was a way to tell 'pull' to use 'rebase' to integrate (if true) or use 'merge' to integrate (if false), and then the third value that is clearly not 'false' was added to say How should the underlying 'rebase' integrate the local and the remote histories?. In that light, one can argue 'git pull' with the above two should run 'rebase --preserve'. In other words, rebase.preserve tells us When 'rebase' is told to run, it should do the 'preserving' variant. But then when somebody sets pull.rebase to true, expecting that 'true' does not just mean Yup, please use rebase, I do not like merges, but means Use rebase without preserve, it would be hard to debug if the behaviour of 'git pull' is affected by a separate variable rebase.preserve that may be defined in a far-away place in the configuration file. I dunno. This kind of complications is one reason why I wouldn't encourage adding these configurations to affect the behaviours of commands. -- 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] convert: Stream from fd to required clean filter instead of mmap
I'll address the comments about style in a revised patch. On Aug 4, 2014, at 9:03 PM, Junio C Hamano gits...@pobox.com wrote: +return apply_filter(path, 0, 0, -1, 0, ca.drv-clean); What's the significance of -1 here? Does somebody in the callchain from apply_filter() check if fd 0 and act differently (not a complaint nor rhetoric question)? The decision in apply_filter() to return before the real work is taken on the first 0. Any value for fd would be ok. The -1 is only a reminder that the fd is invalid. Steffen -- 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] convert: Stream from fd to required clean filter instead of mmap
On Aug 6, 2014, at 6:22 AM, Steffen Prohaska proha...@zib.de wrote: On Aug 4, 2014, at 9:03 PM, Junio C Hamano gits...@pobox.com wrote: + return apply_filter(path, 0, 0, -1, 0, ca.drv-clean); What's the significance of -1 here? Does somebody in the callchain from apply_filter() check if fd 0 and act differently (not a complaint nor rhetoric question)? The decision in apply_filter() to return before the real work is taken on the first 0. Hmm..., actually it's the last 0 that matters. If no destination buffer is given, apply_filter() returns whether it would filter or not. Any value for fd would be ok. The -1 is only a reminder that the fd is invalid. Steffen -- 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/7] Documentation: git-init: typographical fixes
On Tue, Aug 05, 2014 at 03:06:00PM -0700, Junio C Hamano wrote: Linus Arver linusar...@gmail.com writes: Signed-off-by: Linus Arver linusar...@gmail.com --- Documentation/git-init.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index afd721e..5ed5859 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -43,7 +43,7 @@ OPTIONS -q:: --quiet:: -Only print error and warning messages, all other output will be suppressed. +Only print error and warning messages; all other output will be suppressed. OK. --bare:: @@ -97,7 +97,7 @@ is given: create a repo that is readable and writable to the current user and group, but inaccessible to others. -By default, the configuration flag receive.denyNonFastForwards is enabled +By default, the configuration flag 'receive.denyNonFastForwards' is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it. If you are going to quote something that the user should literally use, it is probably better to use `backticks` so that the quoted contents will be typeset in monospaced typewriter-font. OK, that is simple to change. @@ -113,7 +113,7 @@ TEMPLATE DIRECTORY The template directory contains files and directories that will be copied to the `$GIT_DIR` after it is created. -The template directory used will (in order): +The template directory used will be (in order): - The argument given with the `--template` option. OK. 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: [PATCH 3/7] Documentation: git-init: template directory: reword
On Tue, Aug 05, 2014 at 03:10:30PM -0700, Junio C Hamano wrote: Linus Arver linusar...@gmail.com writes: Signed-off-by: Linus Arver linusar...@gmail.com --- This seems to reword and also reformat at the same time, but was the latter change (i.e. to unindent the bulletted items and to remove blank lines between items) necessary? No, the unindenting/removal of blank lines is a non-grammar change and is not necessary, as it doesn't have any effect on the actual output (html/txt/manpage). I can either keep the same coding style with the rewording, or chop this into two commits, one for the rewording and another for reformatting. Which one do you suggest? Documentation/git-init.txt | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index 45501d0..f21b85b 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -113,22 +113,18 @@ line, the command is run inside the directory (possibly after creating it). -- - TEMPLATE DIRECTORY -- The template directory contains files and directories that will be copied to the `$GIT_DIR` after it is created. -The template directory used will be (in order): - - - The argument given with the `--template` option. - - - The contents of the `$GIT_TEMPLATE_DIR` environment variable. - - - The `init.templatedir` configuration variable. +The template directory will be one of the following (in order): - - The default template directory: `/usr/share/git-core/templates`. +- the argument given with the `--template` option; +- the contents of the `$GIT_TEMPLATE_DIR` environment variable; +- the `init.templatedir` configuration variable; or +- the default template directory: `/usr/share/git-core/templates`. The default template directory includes some directory structure, some suggested exclude patterns, and copies of sample hook 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: [PATCH 4/7] Documentation: git-init: --separate-git-dir: clarify
On Tue, Aug 05, 2014 at 03:12:21PM -0700, Junio C Hamano wrote: Linus Arver linusar...@gmail.com writes: Signed-off-by: Linus Arver linusar...@gmail.com --- You would need to work on your justification skills ;-) in the log message. What does this change clarify and in what way? Oops, sorry. I guess I should have written some more information in the commit message, something like this: Use shorter sentences to describe what actually happens. We describe what the term Git symbolic link actually means. Also, we separate out the description of the behavioral change upon reinitialization into its own paragraph. Documentation/git-init.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index f21b85b..bf0a7ae 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -57,12 +57,12 @@ DIRECTORY section below.) --separate-git-dir=git dir:: -Instead of initializing the repository where it is supposed to be, -place a filesytem-agnostic Git symbolic link there, pointing to the -specified path, and initialize a Git repository at the path. The -result is Git repository can be separated from working tree. If this -is reinitialization, the repository will be moved to the specified -path. +Separate the Git repository from your working tree. Instead of initializing the +repository as a directory to either `$GIT_DIR` or `./.git/`, create a text file +there containing the path to the actual repository. This file acts as +filesystem-agnostic Git symbolic link to the repository. ++ +If this is reinitialization, the repository will be moved to the specified path. --shared[=(false|true|umask|group|all|world|everybody|0xxx)]:: -- 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/2] convert: Refactor would_convert_to_git() to single arg 'path'
It is only the path that matters in the decision whether to filter or
not. Clarify this by making path the single argument of
would_convert_to_git().
Signed-off-by: Steffen Prohaska proha...@zib.de
---
convert.h | 5 ++---
sha1_file.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/convert.h b/convert.h
index 0c2143c..c638b33 100644
--- a/convert.h
+++ b/convert.h
@@ -40,10 +40,9 @@ extern int convert_to_working_tree(const char *path, const
char *src,
size_t len, struct strbuf *dst);
extern int renormalize_buffer(const char *path, const char *src, size_t len,
struct strbuf *dst);
-static inline int would_convert_to_git(const char *path, const char *src,
- size_t len, enum safe_crlf checksafe)
+static inline int would_convert_to_git(const char *path)
{
- return convert_to_git(path, src, len, NULL, checksafe);
+ return convert_to_git(path, NULL, 0, NULL, 0);
}
/*
diff --git a/sha1_file.c b/sha1_file.c
index 3f70b1d..00c07f2 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -3144,7 +3144,7 @@ int index_fd(unsigned char *sha1, int fd, struct stat *st,
if (!S_ISREG(st-st_mode))
ret = index_pipe(sha1, fd, type, path, flags);
else if (size = big_file_threshold || type != OBJ_BLOB ||
-(path would_convert_to_git(path, NULL, 0, 0)))
+(path would_convert_to_git(path)))
ret = index_core(sha1, fd, size, type, path, flags);
else
ret = index_stream(sha1, fd, size, type, path, flags);
--
2.1.0.rc1.6.gb569bd8
--
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/2] Stream fd to clean filter
The main difference to the previous version is that I've split off the refactoring into a separate commit. The rest is polishing the style. Steffen Prohaska (2): convert: Refactor would_convert_to_git() to single arg 'path' convert: Stream from fd to required clean filter instead of mmap convert.c | 60 - convert.h | 10 +--- sha1_file.c | 29 -- t/t0021-conversion.sh | 68 +++ 4 files changed, 151 insertions(+), 16 deletions(-) -- 2.1.0.rc1.6.gb569bd8 -- 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/2] convert: Stream from fd to required clean filter instead of mmap
The data is streamed to the filter process anyway. Better avoid mapping
the file if possible. This is especially useful if a clean filter
reduces the size, for example if it computes a sha1 for binary data,
like git media. The file size that the previous implementation could
handle was limited by the available address space; large files for
example could not be handled with (32-bit) msysgit. The new
implementation can filter files of any size as long as the filter output
is small enough.
The new code path is only taken if the filter is required. The filter
consumes data directly from the fd. The original data is not available
to git, so it must fail if the filter fails.
The test that exercises required filters is modified to verify that the
data actually has been modified on its way from the file system to the
object store.
The expectation on the process size is tested using /usr/bin/time. An
alternative would have been tcsh, which could be used to print memory
information as follows:
tcsh -c 'set time=(0 %M); cmd'
Although the logic could perhaps be simplified with tcsh, I chose to use
'time' to avoid a dependency on tcsh.
Signed-off-by: Steffen Prohaska proha...@zib.de
---
convert.c | 60 -
convert.h | 5
sha1_file.c | 27 +++-
t/t0021-conversion.sh | 68 +++
4 files changed, 148 insertions(+), 12 deletions(-)
diff --git a/convert.c b/convert.c
index cb5fbb4..463f6de 100644
--- a/convert.c
+++ b/convert.c
@@ -312,11 +312,12 @@ static int crlf_to_worktree(const char *path, const char
*src, size_t len,
struct filter_params {
const char *src;
unsigned long size;
+ int fd;
const char *cmd;
const char *path;
};
-static int filter_buffer(int in, int out, void *data)
+static int filter_buffer_or_fd(int in, int out, void *data)
{
/*
* Spawn cmd and feed the buffer contents through its stdin.
@@ -325,6 +326,7 @@ static int filter_buffer(int in, int out, void *data)
struct filter_params *params = (struct filter_params *)data;
int write_err, status;
const char *argv[] = { NULL, NULL };
+ int fd;
/* apply % substitution to cmd */
struct strbuf cmd = STRBUF_INIT;
@@ -355,7 +357,17 @@ static int filter_buffer(int in, int out, void *data)
sigchain_push(SIGPIPE, SIG_IGN);
- write_err = (write_in_full(child_process.in, params-src, params-size)
0);
+ if (params-src) {
+ write_err = (write_in_full(child_process.in, params-src,
params-size) 0);
+ } else {
+ /* dup(), because copy_fd() closes the input fd. */
+ fd = dup(params-fd);
+ if (fd 0)
+ write_err = error(failed to dup file descriptor.);
+ else
+ write_err = copy_fd(fd, child_process.in);
+ }
+
if (close(child_process.in))
write_err = 1;
if (write_err)
@@ -371,7 +383,7 @@ static int filter_buffer(int in, int out, void *data)
return (write_err || status);
}
-static int apply_filter(const char *path, const char *src, size_t len,
+static int apply_filter(const char *path, const char *src, size_t len, int fd,
struct strbuf *dst, const char *cmd)
{
/*
@@ -392,11 +404,12 @@ static int apply_filter(const char *path, const char
*src, size_t len,
return 1;
memset(async, 0, sizeof(async));
- async.proc = filter_buffer;
+ async.proc = filter_buffer_or_fd;
async.data = params;
async.out = -1;
params.src = src;
params.size = len;
+ params.fd = fd;
params.cmd = cmd;
params.path = path;
@@ -747,6 +760,24 @@ static void convert_attrs(struct conv_attrs *ca, const
char *path)
}
}
+int would_convert_to_git_filter_fd(const char *path)
+{
+ struct conv_attrs ca;
+
+ convert_attrs(ca, path);
+ if (!ca.drv)
+ return 0;
+
+ /* Apply a filter to an fd only if the filter is required to succeed.
+* We must die if the filter fails, because the original data before
+* filtering is not available.
+*/
+ if (!ca.drv-required)
+ return 0;
+
+ return apply_filter(path, NULL, 0, -1, NULL, ca.drv-clean);
+}
+
int convert_to_git(const char *path, const char *src, size_t len,
struct strbuf *dst, enum safe_crlf checksafe)
{
@@ -761,7 +792,7 @@ int convert_to_git(const char *path, const char *src,
size_t len,
required = ca.drv-required;
}
- ret |= apply_filter(path, src, len, dst, filter);
+ ret |= apply_filter(path, src, len, -1, dst, filter);
if (!ret required)
die(%s: clean filter '%s' failed, path, ca.drv-name);
@@ -778,6 +809,23 @@ int convert_to_git(const char *path,
Re: [PATCH 7/7] Documentation: git-init: flesh out example
On Tue, Aug 05, 2014 at 03:14:48PM -0700, Junio C Hamano wrote: Linus Arver linusar...@gmail.com writes: Signed-off-by: Linus Arver linusar...@gmail.com --- Documentation/git-init.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index b94d165..16e9f9c 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -138,10 +138,12 @@ Start a new Git repository for an existing code base:: $ cd /path/to/my/codebase $ git init 1 $ git add . 2 +$ git commit3 I agree it is a good discipline to make the initial pristine import immediately after git add . without doing anything else. Perhaps the description below wants to make it more explicit? I could add a comment like the following: For new repositories, creating a commit immediately after git add . is good practice as it will cleanly separate any preexisting work (done under some other VCS, for example) from any new work done with git. Does this make sense? I am not sure how explicit you want it to be, or whether I captured what you wanted to be explained. Actually, I would like to know if anything is special about the root-commit (I only know it is written as such, with a hyphen, because that is what you get from git's output message). I am not sure if this root-commit idea is explained in detail in git's other documentation. + -1 prepare /path/to/my/codebase/.git directory -2 add all existing file to the index +1 Create a /path/to/my/codebase/.git directory. +2 Add all existing files to the index. +3 Create the first root-commit. GIT --- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
