Re: [cosmetic bug?] needlessly(?) executable files
On Mon, 2015-02-23 at 09:21 +0100, Dennis Kaarsemaker wrote: It used to be for a brief period in history, between daa22c6f8d (2.1.0) and 1f32ecf (2.2.2). Ah thanks,... I have 2.1.4 which explains this :) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
[PATCH] submodule: Improve documentation of update subcommand
The documentation of 'git submodule update' has several problems: 1) It mentions that value 'none' of submodule.$name.update can be overridden by --checkout, but other combinations of configuration values and command line options are not mentioned. 2) The documentation of submodule.$name.update is scattered across three places, which is confusing. 3) The documentation of submodule.$name.update in gitmodules.txt is incorrect, because the code always uses the value from .git/config and never from .gitmodules. 4) Documentation of --force was incomplete, because it is only effective in case of checkout method of update. Fix all these problems by documenting submodule.*.update in git-submodule.txt and make everybody else refer to it. Helped-by: Junio C Hamano gits...@pobox.com Helped-by: Jens Lehmann jens.lehm...@web.de Signed-off-by: Michal Sojka sojk...@fel.cvut.cz --- Documentation/config.txt| 15 ++ Documentation/git-submodule.txt | 66 - Documentation/gitmodules.txt| 21 ++--- 3 files changed, 65 insertions(+), 37 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index ae6791d..fb2ae37 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2411,12 +2411,17 @@ status.submodulesummary:: submodule.name.path:: submodule.name.url:: + The path within this project and URL for a submodule. These + variables are initially populated by 'git submodule init'; + edit them to override the URL and other values found in the + `.gitmodules` file. See linkgit:git-submodule[1] and + linkgit:gitmodules[5] for details. + submodule.name.update:: - The path within this project, URL, and the updating strategy - for a submodule. These variables are initially populated - by 'git submodule init'; edit them to override the - URL and other values found in the `.gitmodules` file. See - linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. + The default updating strategy for a submodule. This variable + is populated by `git submodule init` from the + linkgit:gitmodules[5] file. See description of 'update' + command in linkgit:git-submodule[1]. submodule.name.branch:: The remote branch name for a submodule, used by `git submodule diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 8e6af65..067d616 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -154,27 +154,51 @@ If `--force` is specified, the submodule's work tree will be removed even if it contains local modifications. update:: - Update the registered submodules, i.e. clone missing submodules and - checkout the commit specified in the index of the containing repository. - This will make the submodules HEAD be detached unless `--rebase` or - `--merge` is specified or the key `submodule.$name.update` is set to - `rebase`, `merge` or `none`. `none` can be overridden by specifying - `--checkout`. Setting the key `submodule.$name.update` to `!command` - will cause `command` to be run. `command` can be any arbitrary shell - command that takes a single argument, namely the sha1 to update to. + +-- +Update the registered submodules to match what the superproject +expects by cloning missing submodules and updating the working tree of +the submodules. The updating can be done in several ways depending +on command line options and the value of `submodule.name.update` +configuration variable. Supported update methods are: + + checkout;; the commit recorded in the superproject will be + checked out in the submodule on a detached HEAD. This is + done when `--checkout` option is given, or no option is + given, and `submodule.name.update` is unset, or if it is + set to 'checkout'. ++ +If `--force` is specified, the submodule will be checked out (using +`git checkout --force` if appropriate), even if the commit specified +in the index of the containing repository already matches the commit +checked out in the submodule. + + rebase;; the current branch of the submodule will be rebased + onto the commit recoded in the superproject. This is done + when `--rebase` option is given, or no option is given, and + `submodule.name.update` is set to 'rebase'. + + merge;; the commit recorded in the superproject will be merged + into the current branch in the submodule. This is done + when `--merge` option is given, or no option is given, and + `submodule.name.update` is set to 'merge'. + + custom command;; arbitrary shell command that takes a single + argument (the sha1 of the commit recorded in the + superproject) is executed. This is done when no option is + given, and
[PATCH] checkout: --to requires directory
--to requires a directory, not a file. Say so in the usage string. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- builtin/checkout.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/checkout.c b/builtin/checkout.c index 8b2bf20..8cdcd07 100644 --- a/builtin/checkout.c +++ b/builtin/checkout.c @@ -1341,7 +1341,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix) N_(do not limit pathspecs to sparse entries only)), OPT_HIDDEN_BOOL(0, guess, dwim_new_local_branch, N_(second guess 'git checkout no-such-branch')), - OPT_FILENAME(0, to, opts.new_worktree, + OPT_STRING(0, to, opts.new_worktree, N_(dir), N_(check a branch out in a separate working directory)), OPT_BOOL(0, ignore-other-worktrees, opts.ignore_other_worktrees, N_(do not check if another worktree is holding the given ref)), -- 2.3.0.296.g32c87e1 -- 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] sequencer: preserve commit messages
sequencer calls commit with default options, which implies --cleanup=default unless the user specified something else in their config. This leads to cherry-picked commits getting a cleaned up commit message, which is usually not an intended side-effect. Make the sequencer use --cleanup=verbatim so that it preserves commit messages independent of the defaults and user config for commit. Reported-by: Christoph Anton Mitterer cales...@scientia.net Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Notes: All tests run fine with this changed behavior. I don't know whether this may have any side-effects on other (untested) uses of the sequencer. sequencer.c | 1 + t/t3511-cherry-pick-x.sh | 28 2 files changed, 29 insertions(+) diff --git a/sequencer.c b/sequencer.c index 77a1266..35fe9d9 100644 --- a/sequencer.c +++ b/sequencer.c @@ -377,6 +377,7 @@ static int run_git_commit(const char *defmsg, struct replay_opts *opts, argv_array_init(array); argv_array_push(array, commit); argv_array_push(array, -n); + argv_array_push(array, --cleanup=verbatim); if (opts-gpg_sign) argv_array_pushf(array, -S%s, opts-gpg_sign); diff --git a/t/t3511-cherry-pick-x.sh b/t/t3511-cherry-pick-x.sh index f977279..b7dff09 100755 --- a/t/t3511-cherry-pick-x.sh +++ b/t/t3511-cherry-pick-x.sh @@ -36,6 +36,20 @@ mesg_with_cherry_footer=$mesg_with_footer_sob (cherry picked from commit da39a3ee5e6b4b0d3255bfef95601890afd80709) Tested-by: C.U. Thor cut...@example.com +mesg_unclean=$mesg_one_line + + +leading empty lines + + +consecutive empty lines + +# hash tag comment + +trailing empty lines + + + test_expect_success setup ' git config advice.detachedhead false @@ -53,6 +67,10 @@ test_expect_success setup ' test_commit $mesg_with_footer_sob foo b mesg-with-footer-sob git reset --hard initial test_commit $mesg_with_cherry_footer foo b mesg-with-cherry-footer + git reset --hard initial + test_config commit.cleanup verbatim + test_commit $mesg_unclean foo b mesg-unclean + test_unconfig commit.cleanup pristine_detach initial test_commit conflicting unrelated ' @@ -216,4 +234,14 @@ test_expect_success 'cherry-pick -x -s treats (cherry picked from... line as p test_cmp expect actual ' +test_expect_success 'cherry-pick preserves commit message' ' + pristine_detach initial + printf $mesg_unclean expect + git log -1 --pretty=format:%B mesg-unclean actual + test_cmp expect actual + git cherry-pick mesg-unclean + git log -1 --pretty=format:%B actual + test_cmp expect actual +' + test_done -- 2.3.0.296.g32c87e1 -- 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] submodule: Improve documentation of update subcommand
On Sat, Feb 21 2015, Junio C Hamano wrote: Michal Sojka sojk...@fel.cvut.cz writes: update:: +Update the registered submodules to match what the superproject +expects by cloning missing submodules and updating the working +tree of the submodules. The updating can be done in several +ways depending on command line options and the value of +`submodule.name.update` in .git/config: No quoting around .git/config? There is not quoting in the rest of the file as well. Actually, it is probably better not to spell out that path. ... and the value of the `...` configuration variable would be better. Yes, I changed it to this. See the followup mail. When running add, allow adding an otherwise ignored submodule path. When running deinit the submodule work trees will be removed even if they contain local changes. -When running update, throw away local changes in submodules when -switching to a different commit; and always run a checkout operation -in the submodule, even if the commit listed in the index of the -containing repository matches the commit checked out in the submodule. +When running update and the checkout method is used, throw away +local changes in submodules when switching to a different +commit; and always run a checkout operation in the submodule, +even if the commit listed in the index of the containing +repository matches the commit checked out in the submodule. This makes a reader wonder what --force would do when --merge or --rebase is given from the command line (or specifiedy in the configuration). The original (unfortunately) did not have that problem because it did not single out the --checkout mode. I changed that to (only effective with the checkout method). The use of the phrase the checkout method is iffy, as nobody defines what it is (I just said --checkout mode to mean the same thing, but I do not think anybody defines it). See below. I defined it in gitmodules.txt as you suggest as well as in the description of update command in git-submodule.txt. Thanks. -Michal -- 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: What's cooking in git.git (Feb 2015, #06; Sun, 22)
Junio C Hamano venit, vidit, dixit 22.02.2015 22:41: [Stalled] * nd/list-files (2015-02-09) 21 commits . t3080: tests for git-list-files . list-files: -M aka diff-cached . list-files -F: show submodules with the new indicator '' . list-files: add -F/--classify . list-files: show directories as well as files . list-files: do not show duplicate cached entries . list-files: sort output and remove duplicates . list-files: add -t back . list-files: add -1 short for --no-column . list-files: add -R/--recursive short for --max-depth=-1 . list-files: -u does not imply showing stages . list-files: make alias 'ls' default to 'list-files' . list-files: a user friendly version of ls-files and more . ls-files: support --max-depth . ls-files: add --column . ls-files: add --color to highlight file names . ls-files: buffer full item in strbuf before printing . ls_colors.c: highlight submodules like directories . ls_colors.c: add a function to color a file name . ls_colors.c: parse color.ls.* from config file . ls_colors.c: add $LS_COLORS parsing code A new git list-files Porcelain command, ls-files with bells and whistles. No comments? No reviews? No interests? I like the result a lot (I admit - I like colors in terminals). Since the aim is a user facing command I'm wondering whether the status symbols really should be those from ls-files or rather those from status -s (and diff --name-files). (Yes, that would require two chars.) status, status -s and the like are in an ordinary user's tool box. ls-files isn't, at least not with -t, which we even mark as deprecated. That makes me wonder, though, how difficult it would be to wt_status_collect_unchanged() and to leverage the status machinery rather than ls-files. Michael -- 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] checkout: --to requires directory
On Mon, Feb 23, 2015 at 03:16:59PM +0100, Michael J Gruber wrote: --to requires a directory, not a file. Say so in the usage string. Sounds like a good goal, but... - OPT_FILENAME(0, to, opts.new_worktree, + OPT_STRING(0, to, opts.new_worktree, N_(dir), N_(check a branch out in a separate working directory)), OPT_FILENAME also calls fix_filename(), which munges the filename so that relative paths given by the user will work, even though git has chdir'd to the root of the working tree. So you need to handle that somewhere. I think it might be less painful to teach OPT_FILENAME to be more flexible in the usage message it prints. -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
zip files created with git archive flags text files as binaries
I'm using git on windows 7. $ git --version git version 1.9.4.msysgit.0 Some days ago I uploaded a latex package to CTAN (www.ctan.org). I created the zip-file with git archive --format=zip --prefix=citeall/ --output=zip/citeall_2015-02-20.zip HEAD The zip contained four text files and a pdf. The CTAN maintainers informed me that all files in the zip are flagged as binaries and this makes it difficult for them to process them further (they want to correct line feeds of the text files: http://mirror.ctan.org/tex-archive/help/ctan/CTAN-upload-addendum.html#crlf) unzip -Z reports for my zip: $ unzip -Z citeall_2015_02_20.zip Archive: citeall_2015_02_20.zip Zip file size: 105509 bytes, number of entries: 6 drwx--- 0.0 fat0 bx stor 15-Feb-20 17:07 citeall/ -rw 0.0 fat 458 bx defN 15-Feb-20 17:07 citeall/README -rw 0.0 fat 102244 bx defN 15-Feb-20 17:07 citeall/citeall.pdf -rw 0.0 fat 3431 bx defN 15-Feb-20 17:07 citeall/citeall.sty -rw 0.0 fat 3971 bx defN 15-Feb-20 17:07 citeall/citeall.tex -rw 0.0 fat 557 bx defN 15-Feb-20 17:07 citeall/examples-citeall.bib 6 files, 110661 bytes uncompressed, 104669 bytes compressed: 5.4% The problem are all the bx entries. When I zip all the files with the standard windows zip-tool I get this: $ unzip -Z citeall-win.zip Archive: citeall-win.zip Zip file size: 105275 bytes, number of entries: 5 -rw 2.0 fat 102244 b- defN 15-Feb-20 17:07 citeall/citeall.pdf -rw 2.0 fat 3431 t- defN 15-Feb-20 17:07 citeall/citeall.sty -rw 2.0 fat 3971 t- defN 15-Feb-20 17:07 citeall/citeall.tex -rw 2.0 fat 557 t- defN 15-Feb-20 17:07 citeall/examples-citeall.bib -rw 2.0 fat 458 t- defN 15-Feb-20 17:07 citeall/README 5 files, 110661 bytes uncompressed, 104675 bytes compressed: 5.4% Here the text files have a correct t flag. I don't know if it the problem exists also with zips created with git archive on non-windows OS. Would it be possible to correct the zip-backend so that it flags text files correctly? Or alternativly could one configure git archive to use another zip programm? (I tried to sent this already some hours ago, but the message seems to be lost ...) -- Ulrike Fischer http://www.troubleshooting-tex.de/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: git blame swallows up lines in case of mixed line endings
It's not that I want to use CR as line ending. We just had to process a repository where it was the case. We use git blame as an automatic processing step in a bigger system. So if a line does not exist for git blame but it does exist for other parts of the system (which read the same file) we run into consistency problems. -Ursprüngliche Nachricht- Von: Torsten Bögershausen [mailto:tbo...@web.de] Gesendet: Samstag, 21. Februar 2015 14:46 An: Sokolov, Konstantin (ext); 'git@vger.kernel.org' Betreff: Re: git blame swallows up lines in case of mixed line endings On 2015-02-19 14.48, Sokolov, Konstantin (ext) wrote: Hi Folks, I encounter unexpected behavior in the following case: file content: line1CRLF line2CR line3CRLF line4 This is what I get as console output (on Windows): git blame -s file.txt 7db36436 1) line1 line3436 2) line2 7db36436 3) line4 This is the real content: git blame -s file.txt blame.txt blame.txt opened in Notepad++: 7db36436 1) line1 CRLF 7db36436 2) line2 CR line3 CRLF 7db36436 3) line4 LF Admittedly, very stupid editors, such as Windows Notepad, cannot handle mixed line endings as well. But is this also the way git blame should behave? Kind regards Konstantin Git (and other tools) do not handle a single CR as a line ending. A line ending in Git is either CRLF or LF. A mixed line ending in Git sense is a mixture between CRLF and LF, but not a lone CR. (And in this sense it is the expected behavior) Are you sure you want to use it, or is it a typo ? -- 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
URGENT DELIVERY
-- Hi , I’m pleased to send this mail regarding your products below : -Shoes 300 UNITS -Poloshirts 700 UNITS Please can you send me your offer included express delivery to UK. PS: To celebrate my foundation's party this week Best regards) MR. Yaya Toure https://twitter.com/toure_yaya42 Manchester City Football club Sports Section¨ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] branch: name detached HEAD analogous to status
On 15-02-22 02:21 PM, Junio C Hamano wrote: Michael J Gruber g...@drmicha.warpmail.net writes: git status carefully names a detached HEAD at resp. from a rev or ref depending on whether the detached HEAD has moved since. git branch always uses from, which can be confusing, because a status-aware user would interpret this as moved detached HEAD. Make git branch use the same logic and wording. Yeah, otherwise the user would wonder why sometimes the object name after that from matches git rev-parse HEAD and sometimes does not. In order to make sure that it will be easy for us to maintain that these two commands will keep using the same logic and wording after this fix is applied, should this patch do a bit more? Or is it worth doing that for such a small piece of code to be shared? The following is a tangent and I do not think it is likely we would do anything about it, but I wonder what value we give the end users by showing the from information, both in status and branch in the first place. When I am on a detached HEAD, I'd be doing one of these three things: (1) I am on some kind of sequencing machinery (e.g. rebase -i, cherry-pick A..B, or bisect). It does not matter to me at all if I am at the same commit at which I started the sequenced operations or the sequencing machinery has moved me one or more commits along its planned course of action, or where the original point the sequencing machinery detached the HEAD at. I suspect that I would not use git status or git branch in this mode anyway. (2) I am sight-seeing, starting with e.g. git checkout v2.0.0, and moving around with git checkout $some_other_commit. I'd always see that I am at the commit I last checked out, so the distinctions would not be even shown to me. (3) I am experimenting to fix or enhance an existing thing that is meant to eventually hit a concrete branch, but I do not know if the experiment would pan out. git checkout $topic~$n would be to start from near the tip of that $topic ($n may often be 0 but not always) and then I would git commit my experiments. When I assess my progress, I'd be interested in what I have that is not in $topic and vice versa since I started that experiment, so I find it very useful, because I often work on HEADs detached from remote branches (git checkout origin/foo). If I'm sight-seeing, I like the reminder of which remote branch I checked out, especially because I often have several working tress going at the same time. I also often make trivial changes, like typo fixes, on such detached HEADs, and here too I appreciate the reminder of which remote branch I should push HEAD to. 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
Internationalization and yes/no prompts
Hi, I just fell in a little trap, in which you may find interest. I'm using git on the command line (on an Elementary OS system : Linux 3.2.0-76-generic #111-Ubuntu SMP Tue Jan 13 22:16:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux). git version : 2.3.0 My system is configured in french. That's said : I run a git clean -i, and select option 4 (ask each). (By the fact, messages are translated, but options of the 'interactive' menu aren't) So I get, for each file, the question : /Supprimer //premier_fichier ? [Remove first_file ?]/ Natural answer to this question is 'Oui' [Yes], so I type 'o', rather than 'y'. Once finished, I see no file has been removed (since 'o' has been considered as 'different than yes') Whereas it's not an end-of-the-world thing*, it's annoying as at first sight I didn't understand why it has 'not worked'. I thought of a few possibilities (some easy to implement, others more complex; some are stricter for the user) : - explicitly put y/n in the message. Translaters should be warned to let y/n, - only allow y and n answers (and variants : yes, no), and reject everything else with a message - use as 'n', but echoes a message : 'Answer considered as /no/' - accept answers depending on the language used to echo the prompt (y/n for english, o/n for french, j/n for german, ...) What do you think about that ? * but just imagine how worst it could be if you're configured in a language where 'No' is said using a word beginning by 'Y'... Cheers, Pierre-Olivier Vares -- 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] checkout: --to requires directory
Jeff King venit, vidit, dixit 23.02.2015 15:42: On Mon, Feb 23, 2015 at 03:16:59PM +0100, Michael J Gruber wrote: --to requires a directory, not a file. Say so in the usage string. Sounds like a good goal, but... -OPT_FILENAME(0, to, opts.new_worktree, +OPT_STRING(0, to, opts.new_worktree, N_(dir), N_(check a branch out in a separate working directory)), OPT_FILENAME also calls fix_filename(), which munges the filename so that relative paths given by the user will work, even though git has chdir'd to the root of the working tree. Ooops, I wasn't aware of that. We do use OPT_STRING in quite a few places for directories, though. So you need to handle that somewhere. I think it might be less painful to teach OPT_FILENAME to be more flexible in the usage message it prints. We have at least path, template-dir dir which can benefit from that. After Junio's call, I'm trying to look a bit at list-files and multiple workdirs. I guess I should collect those bits. BTW: multiple workdirs commit messages and doc talk about a hard link named link in worktrees/id/, but I don't get any from checkout --to. Instead, and in addition to the expected gitdir, I get a file gitfile whose content is a relative path (*not* prefixed with gitdir: ), probably to the worktree .git gitfile (relative from the base worktree). But gitdir points to the same, using (i.e. it contains) an absolute path. I can't quite make sense of this. Maybe the doc is behind? But still. gitdir and gitfile pointing to the same file. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] branch: name detached HEAD analogous to status
On 15-02-22 12:38 PM, Michael J Gruber wrote: git status carefully names a detached HEAD at resp. from a rev or ref depending on whether the detached HEAD has moved since. git branch always uses from, which can be confusing, because a status-aware user would interpret this as moved detached HEAD. Make git branch use the same logic and wording. Except that the wording in git branch is more correct, especially if the detached HEAD contains new commits. In other words, at is only correct if the detached HEAD matches the ref. If the HEAD has other commits, it is no longer at that ref but instead it has grown from it. But even if the detached HEAD matches the ref, saying it came from that ref (with 0 extra commits) is still better than saying detached-HEAD-with-extra-commits is at the ref. 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
Re: [RFH] GSoC 2015 application
On Mon, Feb 23, 2015 at 09:02:58AM +0100, Matthieu Moy wrote: That content was cut-and-pasted into Google's application interface. Matthieu, as backup admin you should have access to tweak that if there are typos, etc (and I will probably not be available to apply fixes from now until the deadline, so please do so if you see anything). I do have access to the text here: http://www.google-melange.com/gsoc/org/survey_response/show/google/gsoc2015/git but I did not find an edit button. I can edit http://www.google-melange.com/gsoc/org/profile/edit/google/gsoc2015/git OTOH. I think it's just because the application period has ended, so our answers to the questions are frozen. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] branch: name detached HEAD analogous to status
Marc Branchaud venit, vidit, dixit 23.02.2015 16:12: On 15-02-22 12:38 PM, Michael J Gruber wrote: git status carefully names a detached HEAD at resp. from a rev or ref depending on whether the detached HEAD has moved since. git branch always uses from, which can be confusing, because a status-aware user would interpret this as moved detached HEAD. Make git branch use the same logic and wording. Except that the wording in git branch is more correct, especially if the detached HEAD contains new commits. In other words, at is only correct if the detached HEAD matches the ref. If the HEAD has other commits, it is no longer at that ref but instead it has grown from it. Sure, but that's exactly what git status does. Haven't you tried out? And it's exactly what I suggest for git branch. It conveys more information. But even if the detached HEAD matches the ref, saying it came from that ref (with 0 extra commits) is still better than saying detached-HEAD-with-extra-commits is at the ref. Why? Both are true. at conveys the additional information that HEAD is still at the that rev. Michael -- 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: Identifying user who ran “git reset” command
On Fri, Feb 20, 2015 at 10:16:18PM -0700, Technext wrote: Thanks Junio for the prompt reply! :) Yes, that's exactly how i would like things to be. I'll definitely try to push this thing and see if this flow can be implemented. However, can you please guide me whether there's any way i could have figured out about the git reset command that the developer executed on his local? (my first query) git reset . is just a local working tree operation, which does not leave something behind, just like when the user would do any other file operations and comitted that. This created a so called evil merge, which are not easy to detect (see [1] for some possible solutions) Also, am i right in thinking that a check cannot be implemented using hooks or any other similar way? (my second query) Because an evil merge is hard to detect, it's even harder to do it automated in a script. Human review works much better for this (when merging in the changes from the developer). [1]: https://stackoverflow.com/a/27744011/20261 -- 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 0/4] OPT_{FILENAME,PATH}
Here's a mini-war on file-type arguments being specified as OPT_STRING (in order to repent for doing so myself). 1/4 introduces OPT_PATH which is like OPT_FILENAME, but takes an additional argument which names the option argument. 2/4 converts OPT_STRING to OPT_FILENAME where it makes sense 3/4 converts OPT_STRING to OPT_PATH where it makes sense 4/4 converts OPT_FILENAME to OPT_PATH for checkout --to 1/4, 2/4 should apply on top of origin/next independently. 3/4 needs 1/4. 4/4 needs 1/4 and is on top of nd/multiple-worktrees. Michael J Gruber (4): parse-options: introduce OPT_PATH option-strings: use OPT_FILENAME option-strings: use OPT_PATH checkout: --to requires directory Documentation/technical/api-parse-options.txt | 5 + archive.c | 2 +- builtin/archive.c | 2 +- builtin/blame.c | 4 ++-- builtin/checkout.c| 2 +- builtin/clone.c | 4 ++-- builtin/config.c | 2 +- builtin/fast-export.c | 4 ++-- builtin/hash-object.c | 2 +- builtin/init-db.c | 4 ++-- builtin/ls-files.c| 2 +- parse-options.h | 2 ++ 12 files changed, 21 insertions(+), 14 deletions(-) -- 2.3.0.296.g32c87e1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] option-strings: use OPT_FILENAME
Some commands use OPT_STRING to specify a file argument. Let them use
OPT_FILENAME so that they can profit from path prefixing.
This excludes low-level commands like the credential helpers.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
This could be before 1/4 but seemed more logical here.
archive.c | 2 +-
builtin/archive.c | 2 +-
builtin/blame.c | 4 ++--
builtin/config.c | 2 +-
builtin/fast-export.c | 4 ++--
builtin/hash-object.c | 2 +-
builtin/ls-files.c| 2 +-
7 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/archive.c b/archive.c
index 94a9981..b4da255 100644
--- a/archive.c
+++ b/archive.c
@@ -419,7 +419,7 @@ static int parse_archive_args(int argc, const char **argv,
OPT_STRING(0, format, format, N_(fmt), N_(archive
format)),
OPT_STRING(0, prefix, base, N_(prefix),
N_(prepend prefix to each pathname in the archive)),
- OPT_STRING('o', output, output, N_(file),
+ OPT_FILENAME('o', output, output,
N_(write the archive to this file)),
OPT_BOOL(0, worktree-attributes, worktree_attributes,
N_(read .gitattributes in working directory)),
diff --git a/builtin/archive.c b/builtin/archive.c
index a1e3b94..9c96681 100644
--- a/builtin/archive.c
+++ b/builtin/archive.c
@@ -85,7 +85,7 @@ int cmd_archive(int argc, const char **argv, const char
*prefix)
const char *output = NULL;
const char *remote = NULL;
struct option local_opts[] = {
- OPT_STRING('o', output, output, N_(file),
+ OPT_FILENAME('o', output, output,
N_(write the archive to this file)),
OPT_STRING(0, remote, remote, N_(repo),
N_(retrieve the archive from remote repository
repo)),
diff --git a/builtin/blame.c b/builtin/blame.c
index 303e217..9b14c7c 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2514,8 +2514,8 @@ int cmd_blame(int argc, const char **argv, const char
*prefix)
OPT_BIT('e', show-email, output_option, N_(Show author
email instead of name (Default: off)), OUTPUT_SHOW_EMAIL),
OPT_BIT('w', NULL, xdl_opts, N_(Ignore whitespace
differences), XDF_IGNORE_WHITESPACE),
OPT_BIT(0, minimal, xdl_opts, N_(Spend extra cycles to find
better match), XDF_NEED_MINIMAL),
- OPT_STRING('S', NULL, revs_file, N_(file), N_(Use revisions
from file instead of calling git-rev-list)),
- OPT_STRING(0, contents, contents_from, N_(file), N_(Use
file's contents as the final image)),
+ OPT_FILENAME('S', NULL, revs_file, N_(Use revisions from
file instead of calling git-rev-list)),
+ OPT_FILENAME(0, contents, contents_from, N_(Use file's
contents as the final image)),
{ OPTION_CALLBACK, 'C', NULL, opt, N_(score), N_(Find line
copies within and across files), PARSE_OPT_OPTARG, blame_copy_callback },
{ OPTION_CALLBACK, 'M', NULL, opt, N_(score), N_(Find line
movements within and across files), PARSE_OPT_OPTARG, blame_move_callback },
OPT_STRING_LIST('L', NULL, range_list, N_(n,m), N_(Process
only line range n,m, counting from 1)),
diff --git a/builtin/config.c b/builtin/config.c
index 8cc2604..b80922c 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -54,7 +54,7 @@ static struct option builtin_config_options[] = {
OPT_BOOL(0, global, use_global_config, N_(use global config file)),
OPT_BOOL(0, system, use_system_config, N_(use system config file)),
OPT_BOOL(0, local, use_local_config, N_(use repository config
file)),
- OPT_STRING('f', file, given_config_source.file, N_(file), N_(use
given config file)),
+ OPT_FILENAME('f', file, given_config_source.file, N_(use given
config file)),
OPT_STRING(0, blob, given_config_source.blob, N_(blob-id),
N_(read config from given blob object)),
OPT_GROUP(N_(Action)),
OPT_BIT(0, get, actions, N_(get value: name [value-regex]),
ACTION_GET),
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index b8182c2..44f2600 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -983,9 +983,9 @@ int cmd_fast_export(int argc, const char **argv, const char
*prefix)
OPT_CALLBACK(0, tag-of-filtered-object,
tag_of_filtered_mode, N_(mode),
N_(select handling of tags that tag filtered
objects),
parse_opt_tag_of_filtered_mode),
- OPT_STRING(0, export-marks, export_filename, N_(file),
+ OPT_FILENAME(0, export-marks, export_filename,
N_(Dump marks to this file)),
- OPT_STRING(0, import-marks, import_filename, N_(file),
+ OPT_FILENAME(0, import-marks, import_filename,
N_(Import marks from
Salvaging borked project history
Hello everyone, Here's the situation: Back in 2012, we cloned a MIPS repo, which was itself a clone of a 3.4.2 kernel with ~40 MIPS-specific patches applied. Then the devs started pushing patches; and once in a while, the maintainer would sync with the mainline kernel. I don't know what tool he used to sync, but he discarded the original patches doing so, and git blame now shows him as the author of every mainline change since the clone. Now that we are moving to a more recent kernel, I'm trying to fix this situation, i.e. I'd like kernel code to have proper attribution in git blame, while keeping intact the information for internal commits. While I'm at it, I want to minimize history by ignoring patches that are now irrelevant: 1) we don't support MIPS anymore, I want to ignore any internal change we made in the arch/mips directory 2) for some reason, there was a large amount of create/delete churn in arch/arm/configs; so I want to ignore our changes, and I'll commit an acceptable config when the process is complete. 3) ignore some internal platform-specific patches (NB: All these ignores are for internal patches, not mainline patches) Sooo, using git log and grep, I came up with a list of ~300 patches I'd like to apply on top of the latest 3.14 kernel. For testing purposes, I used git format-patch on the oldest of my 300 patches. I then made a shiny new clone of linux-stable.git, and tried using git am to apply that patch to the tip of linux-stable, expecting having to solve a few dozens conflicts, and move on (hoping to automate it at some point). But 'git am' just gave up. Small sample of errors: error: patch failed: drivers/block/Kconfig:411 error: drivers/block/Kconfig: patch does not apply error: drivers/tty/serial/8250/8250.c: does not exist in index error: patch failed: drivers/tty/serial/8250/8250_early.c:121 error: drivers/tty/serial/8250/8250_early.c: patch does not apply error: patch failed: drivers/video/Kconfig:101 error: drivers/video/Kconfig: patch does not apply ... Patch failed at 0001 Commit for supporting Sigma Designs' SoCs. The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run git am --continue. If you prefer to skip this patch, run git am --skip instead. To restore the original branch and stop patching, run git am --abort. How do I resolve this problem. I suppose I am doing this the wrong way. What is the correct way to do it? (I'm using git 2.3) Should I use git am -3 in the original repo? Regards. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] option-strings: use OPT_FILENAME
On Mon, Feb 23, 2015 at 05:17:44PM +0100, Michael J Gruber wrote:
diff --git a/archive.c b/archive.c
index 94a9981..b4da255 100644
--- a/archive.c
+++ b/archive.c
@@ -419,7 +419,7 @@ static int parse_archive_args(int argc, const char **argv,
OPT_STRING(0, format, format, N_(fmt), N_(archive
format)),
OPT_STRING(0, prefix, base, N_(prefix),
N_(prepend prefix to each pathname in the archive)),
- OPT_STRING('o', output, output, N_(file),
+ OPT_FILENAME('o', output, output,
N_(write the archive to this file)),
OPT_BOOL(0, worktree-attributes, worktree_attributes,
N_(read .gitattributes in working directory)),
This one is rather tricky...if you look down a few lines, you will see
that we just die() when the option is specified. The point is that
--output is not supposed to make it down to this level (it gets
intercepted by cmd_archive first), and we would not want to respect it
for a remote invocation (ditto for --exec and --remote options).
It's a little weird that we have it here at all (after all, if we
omitted it, we would _also_ complain here). But I guess the -h text is
generated by this parse_options invocation. That seems to be confirmed
by the commit messages of 4fac1d3a98 and 52e7787609.
So I think your change has literally no impact; we do not care about
prefixing or not here, and the help text remains the same (because it
already said file). I am not sure which is better from a readability
standpoint. On the one hand, it is clear that we should match the option
in cmd_archive, since we are printing the help for it here. But we would
never want to act in any way on the filename-properties of this string
(e.g., if we ever started looking at the filesystem as part of
fix_filename(), this would leak information if a malicious client sent
--output=foo to a git-upload-archive server). That's probably a rather
unlikely scenario, though.
diff --git a/builtin/archive.c b/builtin/archive.c
index a1e3b94..9c96681 100644
--- a/builtin/archive.c
+++ b/builtin/archive.c
@@ -85,7 +85,7 @@ int cmd_archive(int argc, const char **argv, const char
*prefix)
const char *output = NULL;
const char *remote = NULL;
struct option local_opts[] = {
- OPT_STRING('o', output, output, N_(file),
+ OPT_FILENAME('o', output, output,
N_(write the archive to this file)),
OPT_STRING(0, remote, remote, N_(repo),
N_(retrieve the archive from remote repository
repo)),
So this one is the flip-side of the parse_archive_args() change above.
Any changes to the help-string here will _not_ get shown (we use
PARSE_OPT_KEEP_ALL, which implies PARSE_OPT_NO_INTERNAL_HELP, and the
-h gets passed down to parse_archive_args parser).
But it should be changing the behavior of -o to properly handle
relative paths, which is a good thing. Except it doesn't. :)
The entry in git.c:commands for cmd_archive does not mention
RUN_SETUP, so we will not have actually chdir'd here. It already works
fine.
I do not think using OPT_FILENAME here is _hurting_ anything, though.
The prefix variable will always be NULL, and therefore fix_filename()
will be a noop. And the code is hopefully more obvious as a result. So
I'd be OK with this change, even though it technically does nothing.
diff --git a/builtin/blame.c b/builtin/blame.c
index 303e217..9b14c7c 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2514,8 +2514,8 @@ int cmd_blame(int argc, const char **argv, const char
*prefix)
OPT_BIT('e', show-email, output_option, N_(Show author
email instead of name (Default: off)), OUTPUT_SHOW_EMAIL),
OPT_BIT('w', NULL, xdl_opts, N_(Ignore whitespace
differences), XDF_IGNORE_WHITESPACE),
OPT_BIT(0, minimal, xdl_opts, N_(Spend extra cycles to find
better match), XDF_NEED_MINIMAL),
- OPT_STRING('S', NULL, revs_file, N_(file), N_(Use revisions
from file instead of calling git-rev-list)),
- OPT_STRING(0, contents, contents_from, N_(file), N_(Use
file's contents as the final image)),
+ OPT_FILENAME('S', NULL, revs_file, N_(Use revisions from
file instead of calling git-rev-list)),
+ OPT_FILENAME(0, contents, contents_from, N_(Use file's
contents as the final image)),
These ones _are_ actually doing something, and it seems like a strict
improvement. E.g.:
cd t
git blame --contents=test-lib.sh test-lib.sh
does not work without your patch.
diff --git a/builtin/config.c b/builtin/config.c
index 8cc2604..b80922c 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -54,7 +54,7 @@ static struct option builtin_config_options[] = {
OPT_BOOL(0, global, use_global_config, N_(use global config file)),
OPT_BOOL(0, system, use_system_config, N_(use system config file)),
[PATCH 4/4] checkout: --to requires directory
--to requires a directory, not a file. Say so in the usage string. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- I did not spot any other misuses of OPT_FILENAME (for non-files). builtin/checkout.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/checkout.c b/builtin/checkout.c index 8b2bf20..4256560 100644 --- a/builtin/checkout.c +++ b/builtin/checkout.c @@ -1341,7 +1341,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix) N_(do not limit pathspecs to sparse entries only)), OPT_HIDDEN_BOOL(0, guess, dwim_new_local_branch, N_(second guess 'git checkout no-such-branch')), - OPT_FILENAME(0, to, opts.new_worktree, + OPT_PATH(0, to, opts.new_worktree, N_(dir), N_(check a branch out in a separate working directory)), OPT_BOOL(0, ignore-other-worktrees, opts.ignore_other_worktrees, N_(do not check if another worktree is holding the given ref)), -- 2.3.0.296.g32c87e1 -- 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/4] parse-options: introduce OPT_PATH
Many options are paths, but not files. Introduce OPT_PATH which does
the same path processing as OPT_FILENAME but allows to name the argument.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Documentation/technical/api-parse-options.txt | 5 +
parse-options.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/Documentation/technical/api-parse-options.txt
b/Documentation/technical/api-parse-options.txt
index 1f2db31..109903c 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -187,6 +187,11 @@ There are some macros to easily define options:
The filename will be prefixed by passing the filename along with
the prefix argument of `parse_options()` to `prefix_filename()`.
+`OPT_PATH(short, long, var, arg_str, description)`::
+ Introduce an option with a path argument named arg_str.
+ The filename will be prefixed by passing the filename along with
+ the prefix argument of `parse_options()` to `prefix_filename()`.
+
`OPT_ARGUMENT(long, description)`::
Introduce a long-option argument that will be kept in `argv[]`.
diff --git a/parse-options.h b/parse-options.h
index 7940bc7..5127a5d 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -149,6 +149,8 @@ struct option {
PARSE_OPT_NOARG | PARSE_OPT_NONEG, (f) }
#define OPT_FILENAME(s, l, v, h){ OPTION_FILENAME, (s), (l), (v), \
N_(file), (h) }
+#define OPT_PATH(s, l, v, a, h){ OPTION_FILENAME, (s), (l), (v), \
+ (a), (h) }
#define OPT_COLOR_FLAG(s, l, v, h) \
{ OPTION_CALLBACK, (s), (l), (v), N_(when), (h), PARSE_OPT_OPTARG, \
parse_opt_color_flag_cb, (intptr_t)always }
--
2.3.0.296.g32c87e1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] branch: name detached HEAD analogous to status
On 15-02-23 11:24 AM, Michael J Gruber wrote: Marc Branchaud venit, vidit, dixit 23.02.2015 16:12: On 15-02-22 12:38 PM, Michael J Gruber wrote: git status carefully names a detached HEAD at resp. from a rev or ref depending on whether the detached HEAD has moved since. git branch always uses from, which can be confusing, because a status-aware user would interpret this as moved detached HEAD. Make git branch use the same logic and wording. Except that the wording in git branch is more correct, especially if the detached HEAD contains new commits. In other words, at is only correct if the detached HEAD matches the ref. If the HEAD has other commits, it is no longer at that ref but instead it has grown from it. Sure, but that's exactly what git status does. Haven't you tried out? And it's exactly what I suggest for git branch. It conveys more information. Oops, right. Sorry, I got blinded by the various detached at examples in your patch's 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 3/4] option-strings: use OPT_PATH
Some commands use OPT_STRING to specify a path type argument. Let them
use OPT_PATH so that they can profit from path prefixing.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
builtin/clone.c | 4 ++--
builtin/init-db.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index a9af3f2..15941c5 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -80,7 +80,7 @@ static struct option builtin_clone_options[] = {
N_(initialize submodules in the clone)),
OPT_BOOL(0, recurse-submodules, option_recursive,
N_(initialize submodules in the clone)),
- OPT_STRING(0, template, option_template, N_(template-directory),
+ OPT_PATH(0, template, option_template, N_(template-directory),
N_(directory from which templates will be used)),
OPT_CALLBACK(0 , reference, option_reference, N_(repo),
N_(reference repository), opt_parse_reference),
@@ -94,7 +94,7 @@ static struct option builtin_clone_options[] = {
N_(create a shallow clone of that depth)),
OPT_BOOL(0, single-branch, option_single_branch,
N_(clone only one branch, HEAD or --branch)),
- OPT_STRING(0, separate-git-dir, real_git_dir, N_(gitdir),
+ OPT_PATH(0, separate-git-dir, real_git_dir, N_(gitdir),
N_(separate git dir from working tree)),
OPT_STRING_LIST('c', config, option_config, N_(key=value),
N_(set config inside the new repository)),
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 6b7fa5f..262c9ae 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -477,7 +477,7 @@ int cmd_init_db(int argc, const char **argv, const char
*prefix)
const char *template_dir = NULL;
unsigned int flags = 0;
const struct option init_db_options[] = {
- OPT_STRING(0, template, template_dir,
N_(template-directory),
+ OPT_PATH(0, template, template_dir, N_(template-directory),
N_(directory from which templates will be
used)),
OPT_SET_INT(0, bare, is_bare_repository_cfg,
N_(create a bare repository), 1),
@@ -486,7 +486,7 @@ int cmd_init_db(int argc, const char **argv, const char
*prefix)
N_(specify that the git repository is to be shared
amongst several users),
PARSE_OPT_OPTARG | PARSE_OPT_NONEG, shared_callback, 0},
OPT_BIT('q', quiet, flags, N_(be quiet), INIT_DB_QUIET),
- OPT_STRING(0, separate-git-dir, real_git_dir, N_(gitdir),
+ OPT_PATH(0, separate-git-dir, real_git_dir, N_(gitdir),
N_(separate git dir from working tree)),
OPT_END()
};
--
2.3.0.296.g32c87e1
--
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
git bash with rsync
Hi, this is a comment to enhance the git distribution under Window$. It would be a nice feature to add rsync to git bash distribution for Window$. In order to be able to show how powerful is GNU tools, to those how still works under M$ OS, or those that are forced to. As far as I know, adding rsync is very tiny (both work and space), as ssh is all ready in the git bash package. Many thanks (especially for the git project). Sebastien. -- 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/4] option-strings: use OPT_PATH
On Mon, Feb 23, 2015 at 01:07:13PM -0800, Junio C Hamano wrote: - OPT_STRING(0, template, option_template, N_(template-directory), + OPT_PATH(0, template, option_template, N_(template-directory), N_(directory from which templates will be used)), OPT_CALLBACK(0 , reference, option_reference, N_(repo), N_(reference repository), opt_parse_reference), I'm not sure if this one is doing anything. Clone cannot use SETUP_GIT for obvious reasons, so we should have a NULL prefix here. But that also means we should be doing the right thing already. I somehow thought that OPT_FILENAME already used expand_user_path() but apparently it does not. It may want to. And then this change will start to matter, as a good enhancement. Of course, if OPT_PATH() is introduced in such a way that the program that uses the API can ask for existing and/or directory, git clone --template=existing-file $URL git clone --template=no-such-directory $URL can be diagnosed as an error without the program having to code very much. So, I agree that this change does not do anything in the current codebase, but it goes in a right direction. Oh, I agree that annotating the option with more meaning is not a bad thing. It may help readability, and as you note, we may grow new features on those annotations over time. I mostly just got tired of writing things along those lines by the time I finished with the OPT_FILENAME patch (I guess OPT_PATH is the one more likely to grow new features, though). The one exception here is the thing I mentioned in parse_archive_args: that one can be controlled by a remote caller and we would not want to leak any information about which files exist, where the user's home directory is, etc. -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: Identifying user who ran git reset command
On 23 Feb 2015, Kevin Daudt wrote: On Fri, Feb 20, 2015 at 10:16:18PM -0700, Technext wrote: Thanks Junio for the prompt reply! :) Yes, that's exactly how i would like things to be. I'll definitely try to push this thing and see if this flow can be implemented. However, can you please guide me whether there's any way i could have figured out about the git reset command that the developer executed on his local? (my first query) git reset . is just a local working tree operation, which does not leave something behind, just like when the user would do any other file operations and comitted that. This created a so called evil merge, which are not easy to detect (see [1] for some possible solutions) Also, am i right in thinking that a check cannot be implemented using hooks or any other similar way? (my second query) Because an evil merge is hard to detect, it's even harder to do it automated in a script. Human review works much better for this (when merging in the changes from the developer). The only effective way I have found to deal with this is to have an implemented policy of making sure that developers only push changes to topic branches and have an approver handle the merge. This will not eliminate the evil merge or reset, but at least you get a second set of eyes on it. With that said, the oops merge or reset is different, which an accidental operation. I know it is off-topic, but there is an approach used by other systems (some code-management, some not) that implement per-command policies. Something like a client-side hook or config-like access control list may be useful: like a hooks/pre-execute (invoked possibly as high up as in run_argv() after handle_options()) that gets passed argv, and is able to accept/decline the command, might catch accidents. Granted this slows things down a whole lot, but places that use (I didn't say need) command-level restrictions, often are willing to accept performance degradation and the resulting grumbling that comes with it. And you've probably had this discussion before, so I sincerely apologize in advance for bringing it up. Cheers, Randall -- Brief whoami: NonStopUNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In real life, I talk too much. -- 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: [cosmetic bug?] needlessly(?) executable files
Dennis Kaarsemaker den...@kaarsemaker.net writes: On zo, 2015-02-22 at 10:44 -0800, Junio C Hamano wrote: Christoph Anton Mitterer cales...@scientia.net writes: Just a question about files like: .git/config .git/hooks/*.sample Is there any reason that these are created executable? Especially the config file? In a new repository I just did git init, I see this: $ rm -fr stupid $ umask 0027 $ git init stupid $ ls -l stupid/.git/config | sed -e 's/ .*//' -rw-r- So no, config is not created executable. It used to be for a brief period in history, between daa22c6f8d (2.1.0) and 1f32ecf (2.2.2). Ahh, yes, I think we fixed that bug not too long ago. Thanks for reminding me. -- 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/4] parse-options: introduce OPT_PATH
Michael J Gruber g...@drmicha.warpmail.net writes:
Many options are paths, but not files. Introduce OPT_PATH which does
the same path processing as OPT_FILENAME but allows to name the argument.
...
diff --git a/parse-options.h b/parse-options.h
index 7940bc7..5127a5d 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -149,6 +149,8 @@ struct option {
PARSE_OPT_NOARG | PARSE_OPT_NONEG, (f) }
#define OPT_FILENAME(s, l, v, h){ OPTION_FILENAME, (s), (l), (v), \
N_(file), (h) }
+#define OPT_PATH(s, l, v, a, h){ OPTION_FILENAME, (s), (l), (v), \
+(a), (h) }
I am somewhat disappointed to see this implementation.
- I expected that OPT_FILENAME will be re-implemented in terms of
OPT_PATH(), as a thin wrapper.
- As the original complaint was checkout --to requires a
directory, and a file would not work, I expected this to give
the programmer finer controls, such as:
- The name must refer to an existing entity on the filesystem,
or an existing entity on the filesystem must not exist, or
anything is fine (tristate).
- The name refers to a diretory, or the name refers to a regular
file, or the name refers to a symbolic link, or anything goes.
That is merely somewhat, as the latter _can_ be coded (e.g. if you
care that the given path already exists as a directory, stat() it
and see if it is, or if you want that the given path does not exist
yet, stat() it to make sure you get ENOENT) after the option is
parsed by the program that uses the parser.
But the infrastructure to allow the latter would free you from
having to say N_(file) or N_(directory); if a parameter can
refer to either a file or a directory, the parse-options library
could give you N_(file or directory) because you are already
telling what kind(s) of paths are allowed.
#define OPT_COLOR_FLAG(s, l, v, h) \
{ OPTION_CALLBACK, (s), (l), (v), N_(when), (h), PARSE_OPT_OPTARG, \
parse_opt_color_flag_cb, (intptr_t)always }
--
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: Salvaging borked project history
Mason slash@free.fr writes: But 'git am' just gave up. Small sample of errors: error: patch failed: drivers/block/Kconfig:411 error: drivers/block/Kconfig: patch does not apply error: drivers/tty/serial/8250/8250.c: does not exist in index error: patch failed: drivers/tty/serial/8250/8250_early.c:121 error: drivers/tty/serial/8250/8250_early.c: patch does not apply error: patch failed: drivers/video/Kconfig:101 error: drivers/video/Kconfig: patch does not apply ... Patch failed at 0001 Commit for supporting Sigma Designs' SoCs. The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run git am --continue. If you prefer to skip this patch, run git am --skip instead. To restore the original branch and stop patching, run git am --abort. How do I resolve this problem. You look at .git/rebase-apply/patch and drivers/block/Kconfig in your editor, and edit the former to make it apply (i.e. adjust the common context lines that begin with SP and preimage lines that begin with '-' to match what you see in the drivers/block/Kconfig where the change wants to go). You do so for all the other files. And then run git am again without any argument, until the patch applies. One way to edit .git/rebase-apply/patch and make it apply that is often necessary when you are applying to codebase that is way more ahead than where you took the original patches is to hand-edit the working tree files (e.g. drivers/block/Kconfig) that the patch wants to touch and change it in the way the patch wants to, while viewing the original .git/rebase-apply/patch in your pager (you do not directly edit this original patch---you only use it as a guide to discern what the patch wants to do). Once the working tree files are in a state that the patch would have wanted to make if it were taken based on the new codebase, overwrite .git/rebase-apply/patch with the output from git diff HEAD. After that (i.e. you have edited .git/rebase-apply/patch, with the help with your editor, the working tree files and git diff), do git reset --hard. Which brings you to the same state just after git am gave up and you correctly edited .git/rebase-apply/patch: to make it apply. So you run git am again without any argument. This time the patch would apply and continue. But I personally think git am -3 may be easier to handle. -- 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: What's cooking in git.git (Feb 2015, #06; Sun, 22)
Michael J Gruber g...@drmicha.warpmail.net writes: status, status -s and the like are in an ordinary user's tool box. ls-files isn't, at least not with -t, which we even mark as deprecated. That makes me wonder, though, how difficult it would be to wt_status_collect_unchanged() and to leverage the status machinery rather than ls-files. Good point. wt-status feels like a much better infrastructure to build on than ls-files -t, which should die ;-). Especially if the command is interested in showing the state of the working tree files relative to the tree of HEAD, as ls-files is purely between the index and the working tree. -- 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: zip files created with git archive flags text files as binaries
Am 23.02.2015 um 14:58 schrieb Ulrike Fischer: I'm using git on windows 7. $ git --version git version 1.9.4.msysgit.0 Git's code for ZIP file creation hasn't changed since then. Some days ago I uploaded a latex package to CTAN (www.ctan.org). I created the zip-file with git archive --format=zip --prefix=citeall/ --output=zip/citeall_2015-02-20.zip HEAD The zip contained four text files and a pdf. The CTAN maintainers informed me that all files in the zip are flagged as binaries and this makes it difficult for them to process them further (they want to correct line feeds of the text files: http://mirror.ctan.org/tex-archive/help/ctan/CTAN-upload-addendum.html#crlf) I wouldn't have expected that this ZIP file attribute is actually used in the wild. unzip -Z reports for my zip: $ unzip -Z citeall_2015_02_20.zip Archive: citeall_2015_02_20.zip Zip file size: 105509 bytes, number of entries: 6 drwx--- 0.0 fat0 bx stor 15-Feb-20 17:07 citeall/ -rw 0.0 fat 458 bx defN 15-Feb-20 17:07 citeall/README -rw 0.0 fat 102244 bx defN 15-Feb-20 17:07 citeall/citeall.pdf -rw 0.0 fat 3431 bx defN 15-Feb-20 17:07 citeall/citeall.sty -rw 0.0 fat 3971 bx defN 15-Feb-20 17:07 citeall/citeall.tex -rw 0.0 fat 557 bx defN 15-Feb-20 17:07 citeall/examples-citeall.bib 6 files, 110661 bytes uncompressed, 104669 bytes compressed: 5.4% The problem are all the bx entries. The x is due to the extra mtime header and unrelated to your issue. b (binary) is set unconditionally to ensure that line endings are kept intact by unpackers on all platforms. fat is used as lowest common denominator for regular files and directories; unx is used for symbolic links. When I zip all the files with the standard windows zip-tool I get this: $ unzip -Z citeall-win.zip Archive: citeall-win.zip Zip file size: 105275 bytes, number of entries: 5 -rw 2.0 fat 102244 b- defN 15-Feb-20 17:07 citeall/citeall.pdf -rw 2.0 fat 3431 t- defN 15-Feb-20 17:07 citeall/citeall.sty -rw 2.0 fat 3971 t- defN 15-Feb-20 17:07 citeall/citeall.tex -rw 2.0 fat 557 t- defN 15-Feb-20 17:07 citeall/examples-citeall.bib -rw 2.0 fat 458 t- defN 15-Feb-20 17:07 citeall/README 5 files, 110661 bytes uncompressed, 104675 bytes compressed: 5.4% Here the text files have a correct t flag. I don't know if it the problem exists also with zips created with git archive on non-windows OS. Yes, git archive creates the same ZIP files everywhere. Would it be possible to correct the zip-backend so that it flags text files correctly? Or alternativly could one configure git archive to use another zip programm? We would have to detect the line ending format (DOS, Unix, Macintosh, etc.) of each file, then set the attribute t (text) and the host system. The detection would slow down archive creation a bit and the resulting files would be different, of course, so this feature should only be enabled by a new command line option. I'll take a look. René -- 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] sha1_name: use strlcpy() to copy strings
On Sun, Feb 22, 2015 at 11:33:16PM +0100, René Scharfe wrote: Am 22.02.2015 um 21:00 schrieb Junio C Hamano: René Scharfe l@web.de writes: Use strlcpy() instead of calling strncpy() and then setting the last byte of the target buffer to NUL explicitly. This shortens and simplifies the code a bit. Thanks. It makes me wonder if the longer term direction should be not to use a bound buffer for oc-path, though. That's a good idea in general, but a bit more involved since we'd need to introduce a cleanup function that releases the memory allocated by the new version of get_sha1_with_context() first and call it from the appropriate places. Would that be a good micro-project for GSoC or is it too simple? Yeah, avoiding resource ownership questions was one of the reasons I went with the static buffer in the first place. But I would love to see it go away. Not only does it potentially truncate paths, but I recall there was some complication with the size of struct object_context (I couldn't find the details in a cursory search, but basically it was not reasonable to have a big array of them). Could we perhaps make this more like sha1_object_info_extended, where the caller asks for fields by filling in pointers, and the object_context itself can be discarded without leaking resources? Like: struct strbuf path = STRBUF_INIT; struct object_context oc = OBJECT_CONTEXT_INIT; oc.path = path; get_sha1_with_context(sha1, oc); ... use path directly ... strbuf_release(path); Then callers who do not care about the path do not have to even know the feature exists (and it opens us up to adding new string-like context fields in the future if we need to). -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: git blame swallows up lines in case of mixed line endings
Torsten Bögershausen tbo...@web.de writes: On 2015-02-19 14.48, Sokolov, Konstantin (ext) wrote: I encounter unexpected behavior in the following case: file content: line1CRLF line2CR line3CRLF line4 You can mark a file as CRLF terminated via attributes system and have Git convert them to use LF as end-of-line when file contents are stored in Git (LF as end-of-line is the representation git blame uses internally). Konstantin said on Windows, and I guessed initially that the lines are marked as such, but after looking at the blame.txt output I am not sure. That means the contents of the lines are: First Line: line1 Second Line: line2 + CR + line3 Third Line: line4 or if CRLF conversion is not specified in Konstantin's repository: First Line: line1 + CR Second Line: line2 + CR + CR + line3 + CR Third Line: line4 + CR Either way, that makes the observed behavior totally expected and understandable. This is what I get as console output (on Windows): git blame -s file.txt 7db36436 1) line1 line3436 2) line2 7db36436 3) line4 As printing CR moves the cursor to the beginning of line on many terminals, it is understandable to see the above output. After printing the first line, it will show 7db36436 2) line2 and then go back to the leftmost column and then overwrite 7db3... with line3. Even though we have an option to mark CR alone as the end of line marker, because the blamed content can go through the textconv filter, it may be possible to define a textconv filter for the path via the attribute system and convert such mixed line endings contents to a series of LF-terminated lines. That would split the second line in the original input into two lines and may produce desired result. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] option-strings: use OPT_FILENAME
Michael J Gruber g...@drmicha.warpmail.net writes: Some commands use OPT_STRING to specify a file argument. Let them use OPT_FILENAME so that they can profit from path prefixing. If the existing code that takes string actually already works correctly, they must be doing the necessary prefixing on their own, but I do not see in this patch a hunk that removes such a custom prefixing. Puzzled... It may be that some of them do not work correctly from subdirectory and this change fixes bugs, but are all of them like that, or is this patch fixing some of them while breaking some others? archive.c | 2 +- builtin/archive.c | 2 +- builtin/blame.c | 4 ++-- builtin/config.c | 2 +- builtin/fast-export.c | 4 ++-- builtin/hash-object.c | 2 +- builtin/ls-files.c| 2 +- 7 files changed, 9 insertions(+), 9 deletions(-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] t/diff-lib: check exact object names in compare_diff_raw
Am 16.02.2015 um 00:43 schrieb Junio C Hamano:
The sanitize helper wanted to strip the similarity and
dissimilarity scores when making comparison, but it was
stripping away the object names as well.
While we do not want to require the exact object names the tests
expect to be maintained, as it would be seen as an extra burden,
this would have prevented us catching a silly bug such as showing
non 0{40} object name on the preimage side of an addition or on the
postimage side of a deletion, because all [0-9a-f]{40} strings were
considered equally OK.
In the longer term, when a test only wants to see the status of the
change without having to worry about object names, it should be
rewritten not to inspect the raw format.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/diff-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/diff-lib.sh b/t/diff-lib.sh
index 75a35fc..c211dc4 100644
--- a/t/diff-lib.sh
+++ b/t/diff-lib.sh
@@ -1,6 +1,6 @@
:
-sanitize_diff_raw='/^:/s/ '$_x40' '$_x40' \([A-Z]\)[0-9]*/ X X
\1# /'
+sanitize_diff_raw='/^:/s/ '\($_x40\)' '\($_x40\)' \([A-Z]\)[0-9]*
/ \1 \2 \3# /'
compare_diff_raw () {
# When heuristics are improved, the score numbers would change.
# Ignore them while comparing.
This reveals a minor bug in test_ln_s_add:
8
Subject: [PATCH] test_ln_s_add: refresh stat info of fake symbolic links
We have a helper function test_ln_s_add that inserts a symbolic link
into the index even if the file system does not support symbolic links.
There is a small flaw in the emulation path: the added entry does not
pick up stat information of the fake symbolic link from the file system,
as a consequence, the index is not exactly the same as for the regular
path (where symbolic links are available). To fix this, just call
git update-index again.
This flaw was revealed by the earlier change that tightened
compare_diff_raw(), because a test case in t4008 depends on the
correctly updated index.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
t/test-lib-functions.sh | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index cb132cf..bd1069b 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -749,7 +749,9 @@ test_ln_s_add () {
else
printf '%s' $1 $2
ln_s_obj=$(git hash-object -w $2)
- git update-index --add --cacheinfo 12 $ln_s_obj $2
+ git update-index --add --cacheinfo 12 $ln_s_obj $2
+ # pick up stat info from the file
+ git update-index $2
fi
}
--
2.3.0.rc0.21.g454f6cd
--
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: Advice on edits to git-rebase man page
On Wed, Feb 18, 2015 at 10:59 AM, Matthew Brett matthew.br...@gmail.com wrote: On Thu, Feb 5, 2015 at 10:58 AM, Junio C Hamano gits...@pobox.com wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: NAME git-rebase - Forward-port local commits to the updated upstream head = Quite technical already. Very much true, and I would say the description is technically correct in the sense that it is not wrong per-se. There are a few points that this fails to state and some that this overspecifies. - Rebase is about changing the base of an existing branch, but the description does not even mention the word branch [*1*]. - There is nothing forward about it. I often see myself applying (tentatively) incoming patches on top of whatever commit I happen to have checked out, review it and then rebasing it to apply to older maintenance track if the topic is about fixing an old bug. - There is no point stressing local commits; all the operations you do to munge commits are local. Perhaps something like this instead? git-rebase - Rebuild a branch on top of a different commit DESCRIPTION If branch is specified, git rebase will perform an automatic git checkout branch before doing anything else. Otherwise it remains on the current branch. = Ouch, do we really want to start a documentation like this? No. We should say what the command does and what the command is for in more general terms first and then describe how arguments can be used to affect it. So, the DESCRIPTION part can definitely be improved IMHO. Your notation graft-point, exclude-from and include-from may be an improvement already. graft-point, exclude-from and include-from aren't technically wrong per-se, but I do not think bulk-replacing the words currently used in the manual page with these is an improvement at all, unless the mental picture the explanation draws is also updated to match these new words. reBASE is about changing the base of the affected branch, and the mental picture the current documentation draws is there is a plant, from which you cut a branch, scion. Then you graft the scion onto understock. It calls the original tree (that the branch being transplanted is part of) the old-base, and the understock (that the scion is going to be grafted onto) the new-base. The word graft in graft point may better convey that we are doing a transplanting than the current wording, but the word point makes it unclear to the readers if it refers to the point where the scion was cut from or where it is going to transplanted to, I am afraid. Thanks for the detailed feedback, sorry to be slow to reply. For 'graft-point' - I agree that it is not immediately clear whether this is the start of the commits that will be moved or the place that they will be moved to. newbase and oldbase are really not too bad in the current docs. After all, the command is called reBASE. On the other hand, the term 'graft' gives the impression of moving part of a tree from one origin (base) to another, which I think is correct, whereas the 'base' terminology doesn't allow an obvious name for the 'shoot' or 'scion'. For example, I don't think there is such a term in the current docs, other than 'set of commits'. Also exclude-from and include-from is probably too operational, and describing the command with only these two words would miss the point that the command is about transplanting a branch. It is true that in order to transplant a branch, you first need to figure out the set of commits whose effects are to be replayed, you would need exclude-from..include-from range computation, but it is an lower-level implemention detail. First - the current docs have upstream for exclude-from and branch for include-from. I find both of these confusing and hard to read: * upstream - it isn't part of the semantics of rebase that the exclude point should be something upstream, that is only one of the common uses. I think this is related to the point you made about forward in the one-line description. * branch - too generic - does not convey the point that this is the included end point of the selected history. Second - I don't understand why the actual use of upstream and branch for selecting commits is a lower-level implementation detail. Is there some higher-level explanation for how these parameters select revisions? Perhaps this email was not well-directed, or there is not much appetite for a git-rebase rewrite at the moment. In any case, I'll unsubscribe for now, but if you think I can help, please do email me. Cheers, Matthew -- 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] sequencer: preserve commit messages
Michael J Gruber g...@drmicha.warpmail.net writes: sequencer calls commit with default options, which implies --cleanup=default unless the user specified something else in their config. This leads to cherry-picked commits getting a cleaned up commit message, which is usually not an intended side-effect. Make the sequencer use --cleanup=verbatim so that it preserves commit messages independent of the defaults and user config for commit. Hmm, wouldn't it introduce a grave regression for users who explicitly ask to clean crufty messages up (by setting their own commit.cleanup configuration) if you unconditionally force --cleanup=verbatim here? Reported-by: Christoph Anton Mitterer cales...@scientia.net Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Notes: All tests run fine with this changed behavior. I don't know whether this may have any side-effects on other (untested) uses of the sequencer. sequencer.c | 1 + t/t3511-cherry-pick-x.sh | 28 2 files changed, 29 insertions(+) diff --git a/sequencer.c b/sequencer.c index 77a1266..35fe9d9 100644 --- a/sequencer.c +++ b/sequencer.c @@ -377,6 +377,7 @@ static int run_git_commit(const char *defmsg, struct replay_opts *opts, argv_array_init(array); argv_array_push(array, commit); argv_array_push(array, -n); + argv_array_push(array, --cleanup=verbatim); if (opts-gpg_sign) argv_array_pushf(array, -S%s, opts-gpg_sign); diff --git a/t/t3511-cherry-pick-x.sh b/t/t3511-cherry-pick-x.sh index f977279..b7dff09 100755 --- a/t/t3511-cherry-pick-x.sh +++ b/t/t3511-cherry-pick-x.sh @@ -36,6 +36,20 @@ mesg_with_cherry_footer=$mesg_with_footer_sob (cherry picked from commit da39a3ee5e6b4b0d3255bfef95601890afd80709) Tested-by: C.U. Thor cut...@example.com +mesg_unclean=$mesg_one_line + + +leading empty lines + + +consecutive empty lines + +# hash tag comment + +trailing empty lines + + + test_expect_success setup ' git config advice.detachedhead false @@ -53,6 +67,10 @@ test_expect_success setup ' test_commit $mesg_with_footer_sob foo b mesg-with-footer-sob git reset --hard initial test_commit $mesg_with_cherry_footer foo b mesg-with-cherry-footer + git reset --hard initial + test_config commit.cleanup verbatim + test_commit $mesg_unclean foo b mesg-unclean + test_unconfig commit.cleanup pristine_detach initial test_commit conflicting unrelated ' @@ -216,4 +234,14 @@ test_expect_success 'cherry-pick -x -s treats (cherry picked from... line as p test_cmp expect actual ' +test_expect_success 'cherry-pick preserves commit message' ' + pristine_detach initial + printf $mesg_unclean expect + git log -1 --pretty=format:%B mesg-unclean actual + test_cmp expect actual + git cherry-pick mesg-unclean + git log -1 --pretty=format:%B actual + test_cmp expect actual +' + test_done -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: git blame swallows up lines in case of mixed line endings
Thank you for going into the matter. I was not aware of the textconv filter.
This is definitely a decent solution. But what exactly do you mean by Even
though we have an option to mark CR alone as the end of line marker? Is
there really such an option in Git or did you mean that it's possible in
general (by changing the implementation)?
Kind Regards
Konstantin
-Ursprüngliche Nachricht-
Von: Junio C Hamano [mailto:gits...@pobox.com]
Gesendet: Montag, 23. Februar 2015 19:45
An: Torsten Bögershausen
Cc: Sokolov, Konstantin (ext); 'git@vger.kernel.org'
Betreff: Re: git blame swallows up lines in case of mixed line endings
Torsten Bögershausen tbo...@web.de writes:
On 2015-02-19 14.48, Sokolov, Konstantin (ext) wrote:
I encounter unexpected behavior in the following case:
file content:
line1CRLF
line2CR
line3CRLF
line4
You can mark a file as CRLF terminated via attributes system and have Git
convert them to use LF as end-of-line when file contents are stored in Git
(LF as end-of-line is the representation git blame uses internally).
Konstantin said on Windows, and I guessed initially that the lines are marked
as such, but after looking at the blame.txt output I am not sure.
That means the contents of the lines are:
First Line: line1
Second Line: line2 + CR + line3
Third Line: line4
or if CRLF conversion is not specified in Konstantin's repository:
First Line: line1 + CR
Second Line: line2 + CR + CR + line3 + CR
Third Line: line4 + CR
Either way, that makes the observed behavior totally expected and
understandable.
This is what I get as console output (on Windows):
git blame -s file.txt
7db36436 1) line1
line3436 2) line2
7db36436 3) line4
As printing CR moves the cursor to the beginning of line on many terminals, it
is understandable to see the above output. After printing the first line, it
will show
7db36436 2) line2
and then go back to the leftmost column and then overwrite 7db3...
with line3.
Even though we have an option to mark CR alone as the end of line marker,
because the blamed content can go through the textconv filter, it may be
possible to define a textconv filter for the path via the attribute system and
convert such mixed line endings
contents to a series of LF-terminated lines. That would split the second
line in the original input into two lines and may produce desired result.
N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: [PATCH 5/6] t/diff-lib: check exact object names in compare_diff_raw
Johannes Sixt j...@kdbg.org writes:
diff --git a/t/diff-lib.sh b/t/diff-lib.sh
index 75a35fc..c211dc4 100644
--- a/t/diff-lib.sh
+++ b/t/diff-lib.sh
@@ -1,6 +1,6 @@
:
-sanitize_diff_raw='/^:/s/ '$_x40' '$_x40' \([A-Z]\)[0-9]* / X X
\1# /'
+sanitize_diff_raw='/^:/s/ '\($_x40\)' '\($_x40\)' \([A-Z]\)[0-9]*
/ \1 \2 \3# /'
compare_diff_raw () {
# When heuristics are improved, the score numbers would change.
# Ignore them while comparing.
This reveals a minor bug in test_ln_s_add:
Thanks for catching it before it hits 'master'.
--
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/4] option-strings: use OPT_PATH
On Mon, Feb 23, 2015 at 05:17:45PM +0100, Michael J Gruber wrote:
diff --git a/builtin/clone.c b/builtin/clone.c
index a9af3f2..15941c5 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -80,7 +80,7 @@ static struct option builtin_clone_options[] = {
N_(initialize submodules in the clone)),
OPT_BOOL(0, recurse-submodules, option_recursive,
N_(initialize submodules in the clone)),
- OPT_STRING(0, template, option_template, N_(template-directory),
+ OPT_PATH(0, template, option_template, N_(template-directory),
N_(directory from which templates will be used)),
OPT_CALLBACK(0 , reference, option_reference, N_(repo),
N_(reference repository), opt_parse_reference),
I'm not sure if this one is doing anything. Clone cannot use SETUP_GIT
for obvious reasons, so we should have a NULL prefix here. But that also
means we should be doing the right thing already.
I think the same goes for the rest of the instances in this patch.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] submodule: Improve documentation of update subcommand
Junio C Hamano gits...@pobox.com writes: +Update the registered submodules to match what the superproject +expects by cloning missing submodules and updating the working tree of +the submodules. The updating can be done in several ways depending +on command line options and the value of `submodule.name.update` +configuration variable. Supported update methods are: If you read the description of --remote (sorry, I didn't notice it until I formatted the result of this patch and tried to read the whole thing), we already use update procedure to mean these modes of updates collectively. Either use update procedures here (and everywhere else in this patch where it is called update method), or adjust the existing update procedure to update method. Either way is fine, but because update procedure is not wrong per-se, I think it would be better to use that phrasing that may already be familiar with the git submodule users. Addendum. Your update to config.txt calls it updating strategy. That also needs to be unified to clarify that we are talking about the same thing in these places to the readers. 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: AW: git blame swallows up lines in case of mixed line endings
Sokolov, Konstantin (ext) konstantin.sokolov@siemens.com writes: Thank you for going into the matter. I was not aware of the textconv filter. This is definitely a decent solution. But what exactly do you mean by Even though we have an option to mark CR alone as the end of line marker? s/have/do not have/; sorry for a false hope ;-) -- 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: What's cooking in git.git (Feb 2015, #06; Sun, 22)
On Mon, Feb 23, 2015 at 11:00:21AM -0800, Junio C Hamano wrote:
Michael J Gruber g...@drmicha.warpmail.net writes:
status, status -s and the like are in an ordinary user's tool box.
ls-files isn't, at least not with -t, which we even mark as deprecated.
That makes me wonder, though, how difficult it would be to
wt_status_collect_unchanged() and to leverage the status machinery
rather than ls-files.
Good point. wt-status feels like a much better infrastructure to
build on than ls-files -t, which should die ;-). Especially if
the command is interested in showing the state of the working tree
files relative to the tree of HEAD, as ls-files is purely between
the index and the working tree.
I had to look up -t, having never used it myself. ;)
What I noticed in the manpage was rather gross:
-t
This feature is semi-deprecated. For scripting purpose,
git-status(1)--porcelain
and git-diff-files(1)--name-status are almost always superior
alternatives, and
users should look at git-status(1)--short or git-diff(1)--name-status
for more
user-friendly alternatives.
It looks like asciidoc sucks up the space between a linkgit macro and
the next word. I can fix it with {nbsp}, but I'm not sure if there's a
better way.
It's also rather hard to read the commands as intended with the (1)
stuck there. I'm tempted to just make this `git status --porcelain` and
drop the link entirely, but I guess it is helping people who read the
HTML version.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] option-strings: use OPT_FILENAME
Junio C Hamano gits...@pobox.com writes: Michael J Gruber g...@drmicha.warpmail.net writes: Some commands use OPT_STRING to specify a file argument. Let them use OPT_FILENAME so that they can profit from path prefixing. If the existing code that takes string actually already works correctly, they must be doing the necessary prefixing on their own, but I do not see in this patch a hunk that removes such a custom prefixing. Puzzled... It may be that some of them do not work correctly from subdirectory and this change fixes bugs, but are all of them like that, or is this patch fixing some of them while breaking some others? Ahh, I see Peff already went over the changes in the patch and sifted them into good, questionable and bad bins. Thanks; I'll shut up and await for a reroll ;-) -- 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/4] parse-options: introduce OPT_PATH
From: Michael J Gruber g...@drmicha.warpmail.net
Many options are paths, but not files. Introduce OPT_PATH which does
the same path processing as OPT_FILENAME but allows to name the
argument.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Documentation/technical/api-parse-options.txt | 5 +
parse-options.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/Documentation/technical/api-parse-options.txt
b/Documentation/technical/api-parse-options.txt
index 1f2db31..109903c 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -187,6 +187,11 @@ There are some macros to easily define options:
The filename will be prefixed by passing the filename along with
the prefix argument of `parse_options()` to `prefix_filename()`.
+`OPT_PATH(short, long, var, arg_str, description)`::
+ Introduce an option with a path argument named arg_str.
+ The filename will be prefixed by passing the filename along with
I couldn't understand this. Should it be s/filename/pathname/ ? Or am I
way off topic.
+ the prefix argument of `parse_options()` to `prefix_filename()`.
+
`OPT_ARGUMENT(long, description)`::
Introduce a long-option argument that will be kept in `argv[]`.
diff --git a/parse-options.h b/parse-options.h
index 7940bc7..5127a5d 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -149,6 +149,8 @@ struct option {
PARSE_OPT_NOARG | PARSE_OPT_NONEG, (f) }
#define OPT_FILENAME(s, l, v, h){ OPTION_FILENAME, (s), (l), (v),
\
N_(file), (h) }
+#define OPT_PATH(s, l, v, a, h){ OPTION_FILENAME, (s), (l), (v),
\
+(a), (h) }
#define OPT_COLOR_FLAG(s, l, v, h) \
{ OPTION_CALLBACK, (s), (l), (v), N_(when), (h), PARSE_OPT_OPTARG,
\
parse_opt_color_flag_cb, (intptr_t)always }
--
2.3.0.296.g32c87e1
--
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
Re: Git Scaling: What factors most affect Git performance for a large repo?
On Fri, 2015-02-20 at 12:59 -0800, Junio C Hamano wrote: David Turner dtur...@twopensource.com writes: On Fri, 2015-02-20 at 06:38 +0700, Duy Nguyen wrote: * 'git push'? This one is not affected by how deep your repo's history is, or how wide your tree is, so should be quick.. Ah the number of refs may affect both git-push and git-pull. I think Stefan knows better than I in this area. I can tell you that this is a bit of a problem for us at Twitter. We have over 100k refs, which adds ~20MiB of downstream traffic to every push. I added a hack to improve this locally inside Twitter: The client sends a bloom filter of shas that it believes that the server knows about; the server sends only the sha of master and any refs that are not in the bloom filter. The client uses its local version of the servers' refs as if they had just been sent Interesting. Care to extend the discussion to improve the protocol exchange, which starts at $gmane/263932 [*1*], where I list the known issues around the current protocol (and a possible way to correct them in footnotes)? At Twitter, we changed to an entirely different clone strategy for our largest repo: instead of using git clone, we use bittorrent (on a tarball of the repo). For git pull, we maintain a journal of all pushes ever made to the server (data and ref updates); each client keeps track of their location in that journal. So now pull does not require any computation on the server; the client just requests the segment of the journal that they don't have. Then the client replays the journal. This scheme isn't perfect: clients end up with data about even transitory and long-dead branches, and there is presently no way to redact data (although that would be possible to add). And of course shallow and sparse clones are impossible. But it works quite well for Twitter's needs. As I understand it, the hope is to implement redaction and then submit patches upstream. I say we, but I personally did not do any of the above work. Because I haven't looked into most of these issues personally, I'm reluctant to say too much on protocol improvements. I would want to better understand the constraints. I do think there is value in having a diversity of possible protocols to handle different use cases. As repositories grow, traditional full-repo clones become less viable. Network transfer and client-side performance both suffer. In a repo the size of (say) WebKit, the traditional model works. In a repo the size of Facebook's monorepo, it starts to break down. So Facebook does entirely shallow clones (using hg, but the problems are similar in git). Commands like log and blame instead call out to a server to gather history data. At Google, whose repo is I think two or three orders of magnitude larger than WebKit, all local copies are both shallow and sparse; there is also support for sparse commits -- so that a commit that affects (say) ten thousand files across the entire tree can be kept to a reasonable size. end digression Twitter's journal scheme explains why I implemented bloom filter pushes -- the number of refs does not significantly affect pull performance, but pushes still go through the normal git machinery, so we wanted an optimization to reduce latency there. -- 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] submodule: Improve documentation of update subcommand
Michal Sojka sojk...@fel.cvut.cz writes: The documentation of 'git submodule update' has several problems: Thanks, this round looks much better. diff --git a/Documentation/config.txt b/Documentation/config.txt index ae6791d..fb2ae37 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2411,12 +2411,17 @@ status.submodulesummary:: submodule.name.path:: submodule.name.url:: + The path within this project and URL for a submodule. These + variables are initially populated by 'git submodule init'; + edit them to override the URL and other values found in the + `.gitmodules` file. See linkgit:git-submodule[1] and + linkgit:gitmodules[5] for details. + The sentence edit them to override talks about other values, which in the original wanted to cover not just path but update as well. By splitting 'update' into its own entry, edit them to override is lost from 'update'. But stepping back a bit, edit them to override applies to all configuration variables. The user edits the configuration file to customize things. I wonder if we even need to say this for .path and url in the first place? Note: not a request to remove it because I hinted so, but a request for comments and discussion, as I do not have a firm opinion. submodule.name.update:: - The path within this project, URL, and the updating strategy - for a submodule. These variables are initially populated - by 'git submodule init'; edit them to override the - URL and other values found in the `.gitmodules` file. See - linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. + The default updating strategy for a submodule. This variable + is populated by `git submodule init` from the + linkgit:gitmodules[5] file. See description of 'update' + command in linkgit:git-submodule[1]. diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 8e6af65..067d616 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -154,27 +154,51 @@ If `--force` is specified, the submodule's work tree will be removed even if it contains local modifications. update:: - Update the registered submodules, i.e. clone missing submodules and - checkout the commit specified in the index of the containing repository. - This will make the submodules HEAD be detached unless `--rebase` or - `--merge` is specified or the key `submodule.$name.update` is set to - `rebase`, `merge` or `none`. `none` can be overridden by specifying - `--checkout`. Setting the key `submodule.$name.update` to `!command` - will cause `command` to be run. `command` can be any arbitrary shell - command that takes a single argument, namely the sha1 to update to. + +-- +Update the registered submodules to match what the superproject +expects by cloning missing submodules and updating the working tree of +the submodules. The updating can be done in several ways depending +on command line options and the value of `submodule.name.update` +configuration variable. Supported update methods are: If you read the description of --remote (sorry, I didn't notice it until I formatted the result of this patch and tried to read the whole thing), we already use update procedure to mean these modes of updates collectively. Either use update procedures here (and everywhere else in this patch where it is called update method), or adjust the existing update procedure to update method. Either way is fine, but because update procedure is not wrong per-se, I think it would be better to use that phrasing that may already be familiar with the git submodule users. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: Remove tcl-format flag from a message that shouldn't have it
2015-02-16 16:27 GMT-07:00 Alex Henrie alexhenri...@gmail.com: 2015-02-09 14:55 GMT-07:00 Junio C Hamano gits...@pobox.com: Alex Henrie alexhenri...@gmail.com writes: This is just a friendly reminder that this patch has been sitting in the mailing list archives for a couple of weeks, and it has not yet been accepted or commented on. I think that is because the message was not sent to the right people, and also because the patch was made against a wrong project ;-). I'll forward it to the gitk maintainer after digging it out of the archive and tweaking it. Thanks. Paul, comments? Another week and still no comments on either this patch or the gitk Catalan translation patch. Is Paul Mackerras still actively involved in the project? -Alex Another week and still no response. If Paul is no longer maintaining gitk, another maintainer should be appointed. -Alex -- 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
sparse checkout syntax does not work in git version 1.9.5.msysgit.0
The platform is Windows server 2008 Git version is 1.9.5.msysgit.0 I have a repository and I want EVERYTHING in the repository to be checked out into the workspace EXCEPT one directory. I have a machine with git version 1.7.8.msysgit.0 and the following syntax in .git/info/sparse-checkout file works fine: /* !engine/testdata/scenarios This syntax does not seem to work with 1.9.5.msysgit.0 version. I have tried to alter the syntax based on some suggestions on the internet, but none of the combinations work. Git still attempts to checkout the directory that I do not want. Does anyone know what syntax works for version 1.9.5.msysgit.0 ? Thanks. -- View this message in context: http://git.661346.n2.nabble.com/sparse-checkout-syntax-does-not-work-in-git-version-1-9-5-msysgit-0-tp7625887.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: [RFH] GSoC 2015 application
Jeff King p...@peff.net writes: So that being said, I did complete the application. We can still withdraw if we want before students start applying, or we can put a disclaimer on the ideas page. I'm in favor of the disclaimer, but I won't fight if other people think it's better to just withdraw. That content was cut-and-pasted into Google's application interface. Matthieu, as backup admin you should have access to tweak that if there are typos, etc (and I will probably not be available to apply fixes from now until the deadline, so please do so if you see anything). I do have access to the text here: http://www.google-melange.com/gsoc/org/survey_response/show/google/gsoc2015/git but I did not find an edit button. I can edit http://www.google-melange.com/gsoc/org/profile/edit/google/gsoc2015/git OTOH. -- 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: [cosmetic bug?] needlessly(?) executable files
On zo, 2015-02-22 at 10:44 -0800, Junio C Hamano wrote: Christoph Anton Mitterer cales...@scientia.net writes: Just a question about files like: .git/config .git/hooks/*.sample Is there any reason that these are created executable? Especially the config file? In a new repository I just did git init, I see this: $ rm -fr stupid $ umask 0027 $ git init stupid $ ls -l stupid/.git/config | sed -e 's/ .*//' -rw-r- So no, config is not created executable. It used to be for a brief period in history, between daa22c6f8d (2.1.0) and 1f32ecf (2.2.2). -- Dennis Kaarsemaker http://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
Re: [RFC/PATCH] branch: name detached HEAD analogous to status
Junio C Hamano venit, vidit, dixit 22.02.2015 20:21: Michael J Gruber g...@drmicha.warpmail.net writes: git status carefully names a detached HEAD at resp. from a rev or ref depending on whether the detached HEAD has moved since. git branch always uses from, which can be confusing, because a status-aware user would interpret this as moved detached HEAD. Make git branch use the same logic and wording. Yeah, otherwise the user would wonder why sometimes the object name after that from matches git rev-parse HEAD and sometimes does not. In order to make sure that it will be easy for us to maintain that these two commands will keep using the same logic and wording after this fix is applied, should this patch do a bit more? Or is it worth doing that for such a small piece of code to be shared? Yes, I guess I meant RFD when I meant RFC. If that consistency is deemed worthwhile it should at least be guaranteed by the tests, which the test amendments somehow do, but better by a shared code in wt-status.c. That could possibly be reused by the decorate code - which is how I came about this: In order to decide about consistent HEAD decorations I checked what we have and got confused by status vs. branch. The following is a tangent and I do not think it is likely we would do anything about it, but I wonder what value we give the end users by showing the from information, both in status and branch in the first place. When I am on a detached HEAD, I'd be doing one of these three things: (1) I am on some kind of sequencing machinery (e.g. rebase -i, cherry-pick A..B, or bisect). It does not matter to me at all if I am at the same commit at which I started the sequenced operations or the sequencing machinery has moved me one or more commits along its planned course of action, or where the original point the sequencing machinery detached the HEAD at. I suspect that I would not use git status or git branch in this mode anyway. (2) I am sight-seeing, starting with e.g. git checkout v2.0.0, and moving around with git checkout $some_other_commit. I'd always see that I am at the commit I last checked out, so the distinctions would not be even shown to me. (3) I am experimenting to fix or enhance an existing thing that is meant to eventually hit a concrete branch, but I do not know if the experiment would pan out. git checkout $topic~$n would be to start from near the tip of that $topic ($n may often be 0 but not always) and then I would git commit my experiments. When I assess my progress, I'd be interested in what I have that is not in $topic and vice versa since I started that experiment, so $ git log ...$topic $ git show-branch HEAD $topic would be a lot more useful than having to learn where did I detach from either status or branch and then do something about that the abbreviated object name (like feeding it to describe or log). Of course, the decision to make the point the HEAD was originally detached at is not an issue this patch introduces, but it makes me wonder if that existing at vs from logic is an overall win or a loss. Not for you nor anyone who routinely detaches heads :) Despite HEAD reflog and delayed pruning and all that, detached HEAD is a state the average user may feel slightly uncomfortable with, and may not even have gotten into on purpose. git checkout tag and git checkout remotebranch are very easy ways to get there, even git checkout HEAD^1 and such when mistaking checkout for reset. Therefore, I think about that at/from as information (or rather: quick guesstimate) on two things: - How did I get there? (For this it might be better to say 'at/from HEAD^1' which was sha1 rather than resolving that to a sha1 only. I dunno. Detached heads move so easily...) - Has something (that could get lost) happened since? We take a quick and overly cautious approach to answering the 2nd question, of course. Maybe a git head command would be really a better place for all that information: git head master or HEAD (on branch resp. detached state) git head -v master at... or HEAD at ..., detached from/at... git head -l list of sha1s of childless prunable commits from HEAD's reflog git head -d|--detach alias for git checkout -detach HEAD (just brainstorming) Michael -- 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] checkout: --to requires directory
On Mon, Feb 23, 2015 at 9:16 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: --to requires a directory, not a file. Say so in the usage string. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- builtin/checkout.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/checkout.c b/builtin/checkout.c index 8b2bf20..8cdcd07 100644 --- a/builtin/checkout.c +++ b/builtin/checkout.c @@ -1341,7 +1341,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix) N_(do not limit pathspecs to sparse entries only)), OPT_HIDDEN_BOOL(0, guess, dwim_new_local_branch, N_(second guess 'git checkout no-such-branch')), - OPT_FILENAME(0, to, opts.new_worktree, + OPT_STRING(0, to, opts.new_worktree, N_(dir), Nack. OPT_FILENAME has hidden magic, see fix_filename(). If you want to change the text, you'll have to fall back to using OPTION_FILENAME directly. N_(check a branch out in a separate working directory)), OPT_BOOL(0, ignore-other-worktrees, opts.ignore_other_worktrees, N_(do not check if another worktree is holding the given ref)), -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/3] protocol v2
On Mon, Feb 23, 2015 at 8:02 PM, Duy Nguyen pclo...@gmail.com wrote: On Tue, Feb 24, 2015 at 10:12 AM, Stefan Beller sbel...@google.com wrote: One of the biggest problems of a new protocol would be deployment as the users probably would not care too deeply. It should just work in the sense that the user should not even sense that the protocol changed. Agreed. To do so we need to make sure the protocol is backwards compatible and works if an old client talks to a new server as well as the other way round. It's very hard to keep backward compatibility if you want to stop the initial ref adverstisement, costly when there are lots of refs. But we can let both protocols run in parallel, with the old one advertise the presence of the new one. That's what I actually meant, to have different versions out there, but maybe having the version as of now as the least common denominator such that it always works (albeit inefficient for many refs). Then the client could switch to new protocol gradually. This way new protocol could forget about backward compatibility. See http://thread.gmane.org/gmane.comp.version-control.git/215054/focus=244325 -- Duy I would add that upload-pack also advertises about the availability of upload-pack2 and the client may set the remote.*.useUploadPack2 to either yes or auto so next time upload-pack2 will be used. I had a similar thought, though I would not just restrict it to v2 this time, but I'd aim to make it possible to plug whatever protocol you want to. (Comparable to the SSL or ssh, it will always work, but as a proficient user you can spend lot's of time tweaking what you actually want, looking at tradeoffs of efficiency, security, convenience). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/3] protocol v2
On Mon, Feb 23, 2015 at 8:02 PM, Duy Nguyen pclo...@gmail.com wrote: It's very hard to keep backward compatibility if you want to stop the initial ref adverstisement, costly when there are lots of refs. But we can let both protocols run in parallel, with the old one advertise the presence of the new one. Then the client could switch to new protocol gradually. This way new protocol could forget about backward compatibility. See http://thread.gmane.org/gmane.comp.version-control.git/215054/focus=244325 Yes, the whole thread is worth a read, but the approach suggested by that article $gmane/244325 is very good for its simplicity. The server end programs, upload-pack and receive-pack, need to only learn to advertise the availability of upload-pack-v2 and receive-pack-v2 services and the client side programs, fetch-pack and push-pack, need to only notice the advertisement and record the availability of v2 counterparts for the current remote *and* continue the exchange in v1 protocol. That way, there is very little risk for breaking anything. And the programs for new protocol exchange do not have to worry about having to talk with older counterparts and downgrading the protocol inline at all. As long as we learn from our past mistakes and make sure that the very initial exchange will be kept short (one of the items in the list of limitations, $gmane/264000), future servers and clients can upgrade the protocol they talk inline by probing capabilities, just like the current protocol allows them to choose extensions. The biggest issue in the current protocol is not who speaks first (that is merely one aspect) but what is spoken first, iow, one side blinly gives a large message as the first thing, which cannot be squelched by capability exchange. So if we are going to discuss a new protocol, I'd prefer to see the discussion without worrying too much about how to inter-operate with the current vintage of Git. It is no longer an interesting problem, as we know how to solve it with minimum risk. Instead, I'd like to see us design the new protocol in such a way that it is in-line upgradable without repeating our past mistakes. I am *not* convinced that we want multiple suite of protocols that must be chosen from to suit the use pattern, as mentioned somewhere upthread, by the way. 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
[RFC/PATCH 0/3] protocol v2
Inspired by a discusson on the scaling of git in the last days, I thought about starting the adventure to teach git a new transport protocol. One of the biggest problems of a new protocol would be deployment as the users probably would not care too deeply. It should just work in the sense that the user should not even sense that the protocol changed. To do so we need to make sure the protocol is backwards compatible and works if and old client talks to a new server as well as the other way round. A later incarnation of the patch series will eventually add the possibility to add new versions of the transport protocols easily without harming the user. For now in the first revision of the series it just documents an approach of how I'd start this problem of compatibility issues. I realize this will be a bigger change to git, so I'd rather just make a small step now. The actual discussion on how to do the next protocol(s) may be started on the gitmerge conference? (bloomfilter! client speaks first!, rsyncing the refs changes!) Any thoughts on how to make it easy to teach git new protocols are very welcome. Thanks, Stefan Stefan Beller (3): Document protocol capabilities extension receive-pack: add advertisement of different protocol options receive-pack: enable protocol v2 Documentation/technical/protocol-capabilities.txt | 11 +++ builtin/receive-pack.c| 7 +++ 2 files changed, 18 insertions(+) -- 2.3.0.81.gc37f363 -- 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/3] Document protocol capabilities extension
In the future we may want to have multiple different versions for the transport protocol each optimized for a certain aspect of the transport such as latency, bandwidth, CPU load etc. To make this future proof document a possible way how to advertise the versions such that the client can store it and use try to use such advertised protocols later if the clients supports them. Signed-off-by: Stefan Beller sbel...@google.com --- Documentation/technical/protocol-capabilities.txt | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index 4f8a7bf..6829668 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -268,3 +268,14 @@ to accept a signed push certificate, and asks the nonce to be included in the push certificate. A send-pack client MUST NOT send a push-cert packet unless the receive-pack server advertises this capability. + +versions + + +If the server supports more than the standard protocol, this capability +advertises the additional versions. It is a comma separated list of +the names of extensions for the binaries (i.e. v2 would result in +the assumption that git-receive-pack-v2 as well as git-upload-pack-v2 +is available). The items are desired in desceding order by the server, +i.e. the server would like the client to use the first advertised +version most. -- 2.3.0.81.gc37f363 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] receive-pack: add advertisement of different protocol options
Signed-off-by: Stefan Beller sbel...@google.com
---
builtin/receive-pack.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index e0ce78e..a077b1d 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -71,6 +71,8 @@ static long nonce_stamp_slop;
static unsigned long nonce_stamp_slop_limit;
static struct ref_transaction *transaction;
+static const char *advertised_versions = NULL;
+
static enum deny_action parse_deny_action(const char *var, const char *value)
{
if (value) {
@@ -168,6 +170,9 @@ static int receive_pack_config(const char *var, const char
*value, void *cb)
return 0;
}
+ if (strcmp(var, receive.advertisedversions) == 0)
+ return git_config_string(advertised_versions, var, value);
+
return git_default_config(var, value, cb);
}
@@ -189,6 +194,8 @@ static void show_ref(const char *path, const unsigned char
*sha1)
strbuf_addstr(cap, ofs-delta);
if (push_cert_nonce)
strbuf_addf(cap, push-cert=%s, push_cert_nonce);
+ if (advertise_versions)
+ strbuf_addstr(cap, versions=%s, advertise_versions);
strbuf_addf(cap, agent=%s, git_user_agent_sanitized());
packet_write(1, %s %s%c%s\n,
sha1_to_hex(sha1), path, 0, cap.buf);
--
2.3.0.81.gc37f363
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] receive-pack: enable protocol v2
This string would tell the client that git-receive-packv2 as well as
git-receive-pack would be supported.
Signed-off-by: Stefan Beller sbel...@google.com
---
builtin/receive-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index a077b1d..dcb231b 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -71,7 +71,7 @@ static long nonce_stamp_slop;
static unsigned long nonce_stamp_slop_limit;
static struct ref_transaction *transaction;
-static const char *advertised_versions = NULL;
+static const char *advertised_versions = v2,;
static enum deny_action parse_deny_action(const char *var, const char *value)
{
--
2.3.0.81.gc37f363
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/3] protocol v2
On Tue, Feb 24, 2015 at 10:12 AM, Stefan Beller sbel...@google.com wrote: One of the biggest problems of a new protocol would be deployment as the users probably would not care too deeply. It should just work in the sense that the user should not even sense that the protocol changed. Agreed. To do so we need to make sure the protocol is backwards compatible and works if an old client talks to a new server as well as the other way round. It's very hard to keep backward compatibility if you want to stop the initial ref adverstisement, costly when there are lots of refs. But we can let both protocols run in parallel, with the old one advertise the presence of the new one. Then the client could switch to new protocol gradually. This way new protocol could forget about backward compatibility. See http://thread.gmane.org/gmane.comp.version-control.git/215054/focus=244325 -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
