git switch and restore user interface
I think it would be helpful for git switch to print a reminder of the old and new branches. Hi, a couple of suggestions for these experimental new commands. Git switch should print the branch you are leaving: % git switch foo You were previously on branch bar (abcdef). You are now on branch foo (bcdef0). Sometimes I forget what branch I was on before and having it in the terminal history would help a lot. For git restore, it might be worth splitting the command further, into 'safe restore' and 'destructive restore'. The safe command would always stop rather than lose data: % git safe-restore . The following local changes would be overwritten: Fee.c Foe.c Stash them first, or (etc etc). The command that unconditionally overwrites working copy changes should be given a different and more dangerous-sounding name. The reason I suggest this is to make sure of a sensible answer to the newcomer's question: "I just deleted a file by mistake in my working copy, how do I get it back from git?". Too often at the moment the answer is "git checkout ." which while correct is also much too dangerous to be a first resort. There should be an obvious and safe command for restoring missing files without losing local changes. In fact, I'd be quite happy for it to be like git clean, which in the default configuration requires some flag like -f to make it lose any local changes, even though the very purpose of git clean is to delete files. To learn how we protect privacy, please use this link (https://www.qma.com/gdpr.html) to read our Privacy Notice. This email and any files transmitted with it are CONFIDENTIAL and are intended solely for the use of the individual(s) or entity to whom they are addressed. Any unauthorised copying, disclosure or distribution of the material within this email is strictly forbidden. Any views or opinions presented within this email are solely those of the author and do not necessarily represent those of QMA Wadhwani (QMAW) unless otherwise specifically stated. An electronic message is not binding on its sender. Any message referring to a binding agreement must be confirmed in writing and duly signed. If you have received this email in error, please notify the sender immediately and delete the original. Telephone, electronic and other communications and conversations with QMAW and/or its associated persons may be recorded and retained. Please note that your personal information may be stored and processed in any country where we have facilities or in which we engage service providers. If you provide personal information to us by email or otherwise, you consent to the transfer of that information to countries outside of your country of residence and these countries may have different data protection rules than your country.
Re: Git stash behavior
You may want to see this recent thread about a similar feature: <http://thread.gmane.org/gmane.comp.version-control.git/275607> -- Ed Avis -- 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: Feature: git stash pop --always-drop
Junio C Hamano pobox.com> writes: >>Yes, my use case is that I get confused about whether the stash has been >>dropped or not and whether I might have stashed something else in the >>meantime. So for me plain 'git stash drop' feels a bit dangerous. > >Then "git stash apply" followed by "git stash drop" would be a pair >of good workflow elements for you, no? I like ordinary 'git stash pop' when it applies cleanly. Only in the cases where it has conflicts and leaves the stash in place does it get a bit awkward. I manually resolve the conflicts and then 'git stash drop', but that last step is a bit dangerous because it might drop an unrelated stash if I have done some other stashing in the meantime. If 'git stash pop' (and 'apply') would always print the name of the stash, then it would be easy to drop that particular stash afterwards. Running one too many or one too few 'git stash drop' commands would no longer cause problems. Printing the name of the stash would, for me, largely remove the need for an --always-drop option to git stash, which is what I at first suggested. -- Ed Avis -- 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: Feature: git stash pop --always-drop
> Yes, my use case is that I get confused about whether the stash has been dropped or not and whether I might have stashed something else in the meantime. So for me plain 'git stash drop' feels a bit dangerous. Jeff King peff.net> writes: >I also wondered if the "dropped" message is >sufficiently clear to new users. The point of it, I think, is to allow a >final "oops, I didn't mean to do that" moment. But there are no >instructions for how one would re-create the same stash. Right - myself I didn't even realize that recreating the stash was possible (though I was vaguely aware that old stashes float around somewhere until they are garbage collected many months later). git stash is a relatively infrequent operation and quite exotic, so it wouldn't hurt to add lots of chatter to it. >>Another feature I would like to see is a kind of atomic stash apply, >I think that may be a bit harder, as the merge machinery would have to >know how to be atomic. If git merge-recursive had a --dry-run flag that might take care of it. -- Ed Avis -- 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: Feature: git stash pop --always-drop
Jeff King peff.net> writes:
>>An alternative would be for git stash to always print the name of the stash
>>it is applying.
> Applying refs/stash@{0} (31cb86c3d700d241e315d989f460e3e83f84fa19)
Yes, that's the one.
>Or maybe it would be useful to actually show the stash subject,
That could be nice to see, but is not a substitute for the SHA.
If the stash pop failed because of conflicts then it could even print
To drop this stash manually, run 'git stash drop abcde...'
Another feature I would like to see is a kind of atomic stash apply, where
either the whole change can be applied to the working tree without conflicts,
or nothing happens.
--
Ed Avis
--
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: Feature: git stash pop --always-drop
An alternative would be for git stash to always print the name of the stash it is applying. Then you can drop it afterwards by name and be sure you got the right one. Printing the name of the stash sounds like a reasonable bit of chatter to add anyway, do you agree? -- Ed Avis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Feature: git stash pop --always-drop
I would find it useful to ask 'git stash pop' to always drop the stash after applying it to the working tree, even if there were conflicts. (Only if there was some hard error, such as an I/O error updating some of the files, should the stash be left on the stack.) Would a patch for such an --always-drop flag be accepted? -- Ed Avis -- 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
Running pre-commit hook
Currently, git commit --dry-run does not run any hooks, not even pre-commit: % mkdir test % cd test % git init Initialized empty Git repository in /home/eda/test/.git/ % ln -s /bin/false .git/hooks/pre-commit % touch a % git add a % git commit --dry-run -m. a >/dev/null && echo yes yes % git commit -m. a && echo yes (fails) It would sometimes be useful to run the pre-commit hook without committing, for example to get some initial checks done before prompting the user to enter a log message. (git commit itself works this way, of course, but I am thinking of development environments and editors that interface to git.) Is there a way to do a dry run commit that also runs some of the hooks? -- Ed Avis -- 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: Log messages beginning # and git rebase -i
Thank you for looking into this. -- Ed Avis -- 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: Log messages beginning # and git rebase -i
I was considering this case: - git commit -a '-m# characters are now handled OK' - hack, hack - git commit -a '-mWhoops, fixed last commit' - run git-rebase -i - squash the second commit into the first - when prompted for the log message for the combined change, delete the "Whoops, fixed last commit" line but leave the first line That will accidentally lose the first log message, assuming commentChar=#. git-rebase -i should be a bit friendlier and not bring up an editing window where the log message ends up being one of the comments. I suggested it could munge the message with an extra space character, but I agree that is a bit unpleasant. Perhaps better would be % git-rebase -i error: commit abcde has log message beginning with '#', which is the current setting of commentChar. This means that the interactive editing of the log message will not work. Please set commentChar to some other value (such as 'auto') in your git configuration to be able to rebase interactively. The current behaviour is a bit of a trap for the unwary, and anyway it leaves no way to specify keeping the existing log message (which begins #). -- Ed Avis -- 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: Log messages beginning # and git rebase -i
Eric Sunshine sunshineco.com> writes: >>the editing for the >>combined log message treats lines beginning with # as comments. This means >>that if you are not careful the commit message can get lost on rebasing. >> >>I suggest that git rebase should add an extra space at the start >'git rebase --interactive' respects the core.commentChar configuration >variable, which you can set to some value other than '#'. I was thinking of the default configuration. But you are right, this applies to whatever the comment character is - so if commentChar is set to * for example, then log lines beginning with * should get an extra space prepended in git rebase --interactive so that they don't get lost. -- Ed Avis -- 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
Log messages beginning # and git rebase -i
git commit will happily let you specify log messages beginning with #. But then on git rebase -i, when squashing some commits, the editing for the combined log message treats lines beginning with # as comments. This means that if you are not careful the commit message can get lost on rebasing. I suggest that git rebase should add an extra space at the start of existing log message lines which begin with #. That is a bit of a kludge but it is better than losing them because they got mixed up with comments. -- Ed Avis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-checkout.txt: Document "git checkout " better
I guess 'replace' would be a better word than 'restore' for the current behaviour. -- Ed Avis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-checkout.txt: Document
> I agree, the word 'revert' is already taken for the operation of creating a new commit which undoes some earlier commit. So 'revert' cannot be used for the operation of overwriting a working tree file with its contents from the repository. But just because 'revert' is not a good choice, doesn't mean that 'restore' is either. >Git is about "contents", not "files". You modify a file, and >restore its contents to its pristine state. It is not "restore the >file", as Git is not about "files". 'Restore to its pristine state' does convey the flavour of what happens. Plain 'restore' by itself doesn't, really. >I think "overwrite is better" is primarily coming from not thinking >in terms of "Git tracks contents, not files". But 'git checkout .' is primarily an operation on the local filesystem. As far as I know, it does not change the git repository, nor the index, stashes and so on. Its only effect is to create and overwrite local files, much the same as 'tar x'. So the appropriate language to describe it should be based more in common usage rather than git-specific terms - if indeed 'restore' is the git-specific term for replacing a file in the working tree. (In which case why not call the command 'git restore'?) If indeed it did work by tracking contents, there wouldn't be a problem. The old contents of the file could be saved as a stash and then the file's contents replaced with the version from the current commit. % git checkout . The following files have been restored to their pristine state: foo The previous contents have been saved and can be got back with: git stash apply checkout_backup_abcde Then there would be no need for agonizing over the documentation to make it clear that 'git checkout PATH' can be a dangerous operation, because it would no longer be dangerous. -- Ed Avis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-checkout.txt: Document "git checkout " better
'restore' may be more consistent with git's internal terminology. But from an outsider's perspective, 'revert' rather than 'restore' is in my view much clearer and more consistent with other version control systems: for example 'svn revert' is what you use to revert files in the working copy. The original issue was that I naively expected that 'git checkout PATH' would indeed just 'restore' some files, that is, create them when they are missing. Its action is rather more drastic than that. If 'revert' is not a suitable verb because of the existing git-revert, then I suggest that 'overwrite' or 'replace' might better convey the idea of what the command does. -- Ed Avis -- 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: Suggestion: make git checkout safer
I'm not attached to the wording changes posted earlier. As I said, it is only a starting point. I do feel that 'git checkout PATH' is rather a dangerous operation, and moreover a surprisingly dangerous one, since 'git checkout BRANCH' is careful not to lose local changes, as are other common commands like 'git pull'. In the documentation patch I tried to highlight the distinction between the two rather different, and perhaps even Jekyll-and-Hyde-like, modes of this command. But rather than adding heavyhanded and redundant warnings to the documentation it would be better for the command not to be quite so sharp-edged. There is already a --force option for one mode, which could easily be made to apply to the other too (so local changes will not be discarded unless --force is given). Is the only argument against it that 'git checkout is intended to overwrite changes'? That seems a little circular since the question is whether its intended behaviour could change to something a little safer. Surely a sensible Huffman-coding of git commands would give longer and harder-to-type names like 'git checkout --force .' to relatively dangerous operations? Or indeed, split out the two different modes into two separate commands. The job of reverting file contents seems like something for 'git clean'. I've said all I have to say but I would like to ask, in the hope of becoming a better git user: if 'git checkout .' is not a safe way to restore missing files in the working tree, what is the recommended way to do that? Thanks all for your comments and guidance. -- Ed Avis -- 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: Suggestion: make git checkout safer
Torsten Bögershausen web.de> writes: >Do you think you can write a patch to improve the documentation ? Here is my attempt, but it is only a starting point. diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index d263a56..ee25354 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -3,7 +3,7 @@ git-checkout(1) NAME -git-checkout - Checkout a branch or paths to the working tree +git-checkout - Overwrite working tree files with a given branch SYNOPSIS @@ -17,10 +17,11 @@ SYNOPSIS DESCRIPTION --- -Updates files in the working tree to match the version in the index -or the specified tree. If no paths are given, 'git checkout' will -also update `HEAD` to set the specified branch as the current -branch. +Updates, creates, or overwrites files in the working tree to match the +version in the index or the specified tree. If no paths are given, +'git checkout' will also update `HEAD` to set the specified branch as +the current branch, and will keep local changes. If paths are given, +'git checkout' will unconditionally overwrite local changes. 'git checkout' :: To prepare for working on , switch to it by updating @@ -81,21 +82,24 @@ Omitting detaches HEAD at the tip of the current branch. 'git checkout' [-p|--patch] [] [--] ...:: When or `--patch` are given, 'git checkout' does *not* - switch branches. It updates the named paths in the working tree - from the index file or from a named (most often a - commit). In this case, the `-b` and `--track` options are - meaningless and giving either of them results in an error. The -argument can be used to specify a specific tree-ish - (i.e. commit, tag or tree) to update the index for the given - paths before updating the working tree. -+ -The index may contain unmerged entries because of a previous failed merge. -By default, if you try to check out such an entry from the index, the -checkout operation will fail and nothing will be checked out. -Using `-f` will ignore these unmerged entries. The contents from a -specific side of the merge can be checked out of the index by -using `--ours` or `--theirs`. With `-m`, changes made to the working tree -file can be discarded to re-create the original conflicted merge result. + switch branches. It overwrites the named paths in the working + tree from the index file or from a named (most + often a commit). Unlike other modes, local modifications to + the files in the working tree are *not* kept. + +In this case, the `-b` and `--track` options are meaningless + and giving either of them results in an error. The + argument can be used to specify a specific tree-ish (i.e. + commit, tag or tree) to update the index for the given paths + before updating the working tree. + The index may contain + unmerged entries because of a previous failed merge. By + default, if you try to check out such an entry from the index, + the checkout operation will fail and nothing will be checked + out. Using `-f` will ignore these unmerged entries. The + contents from a specific side of the merge can be checked out + of the index by using `--ours` or `--theirs`. With `-m`, + changes made to the working tree file can be discarded to + re-create the original conflicted merge result. OPTIONS --- @@ -110,7 +114,9 @@ OPTIONS local changes. + When checking out paths from the index, do not fail upon unmerged -entries; instead, unmerged entries are ignored. +entries; instead, unmerged entries are ignored. (Note that when +checking out paths, local changes are thrown away whether or not +this flag is given.) --ours:: --theirs:: @@ -481,10 +487,10 @@ $ git checkout hello.c<3> + <1> switch branch -<2> take a file out of another commit -<3> restore hello.c from the index +<2> take a file out of another commit, overwriting any local changes +<3> restore hello.c from the index (would overwrite it if it existed) + -If you want to check out _all_ C source files out of the index, +If you want to revert _all_ C source files out of the index, you can say + @@ -492,7 +498,7 @@ $ git checkout -- '*.c' + Note the quotes around `*.c`. The file `hello.c` will also be -checked out, even though it is no longer in the working tree, +created, even though it is no longer in the working tree, because the file globbing is used to match entries in the index (not in the working tree by the shell).
Re: Suggestion: make git checkout safer
Ed Avis waniasset.com> writes: >Julio H. asked how I had learned to run 'git checkout .'. Sorry it was Torsten B. who asked that. But yes, I think it was just word of mouth. -- Ed Avis -- 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: Suggestion: make git checkout safer
Kevin Daudt ikke.info> writes: >If people execute git checkout . as a habbit >without thinking, they will soon train to do git checkout -f . without >thinking, and then you still have the same problem. I don't quite agree; you only learn to use the -f flag if the plain command doesn't do what you want. With rm, I want to remove that file, dammit! The -f flag is often a necessity to stop the tool getting in my way. But when fixing up a working tree, I rarely want to silently trash any local changes. >I do share your sentiment that it's easy to loose uncomitted changes to >git checkout , but like Jeff said, the entire goal of this command >is to reset specific files from the index or commits. Well that's not quite the flavour given by the documentation, which says >Updates files in the working tree to match... 'Updating' files sounds like a fairly safe thing to do, right? Like 'cvs update' or 'svn update', which don't just overwrite working tree changes. The doc doesn't really make clear that any local changes will be discarded; indeed the only mention of that is -f, --force When switching branches... this is used to throw away local changes. To the casual reader, following 'the exception proves the rule', it appears that local changes are not thrown away except in this case. -- Ed Avis -- 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: Suggestion: make git checkout safer
Stefan Beller google.com> writes: >So in one mode, we do actually warn about contents going missing, and the >other mode is designed to actually make things go missing without any >warning. I think this is a big part of the issue. Two rather different operations are given the name 'checkout', and the safety standards applied to them also differ greatly. The manual page doesn't make it clear that it can be quite a dangerous command to run, even without --force. >If I were to come up with a name for such an action it's >maybe "reset" or "reset-file(s)". Agreed. Or 'git clean' could become more powerful and able to reset file contents as well as deleting untracked files. The name and documentation of 'git clean' already make it clear that it's not something safe to run without thinking first. Julio H. asked how I had learned to run 'git checkout .'. I think it was just word of mouth. I had deleted some files from the working tree and asked a colleague how to restore them from the repository - which is, after all, a bread-and-butter operation for any version control system. What is the correct command to run, then, to safely restore missing files? And yes, it probably would be better to use git's native mechanisms to throw away local changes to a file, rather than the sledgehammer approach of just deleting it and checking it out again. Most of the time I do so. Sometimes when everything is a real mess it is more straighforward to reach for 'rm' - or indeed for the delete option in your IDE or file browser. -- Ed Avis -- 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: Suggestion: make git checkout safer
Jeff King peff.net> writes: >I would say the more "usual" way to use checkout like this >is to give specific paths. I.e., run "git status", say "oh, I need to >restore the contents of 'foo', but not 'bar'", and run "git checkout >foo". That works regardless of the type of change to "foo" and "bar". That seems fine - a specific file is named and you clearly want to alter the contents of that file. By analogy, 'rm foo' will silently delete it, but if you specify a directory to delete recursively you need the -r flag. OK, it's not a perfect analogy because the purpose of rm is to delete data and nothing else ;-). If my personal experience is anything to go by, newcomers may fall into the habit of running 'git checkout .' to restore missing files. In the old days I would often delete a file and then run 'cvs update' or 'svn update' to restore it. That would fetch a fresh copy from the repository, and while it might do some kind of diff/patch operation on modified files, it would not simply throw away local changes. 'git checkout .' seems like the analogous command, but it has much sharper edges. I still think it should be safer by default, but if you decide against that then perhaps you need to create some way to restore missing files and not overwrite others. 'git checkout --no-overwrite'? Then it could even be added to .gitconfig as the default for those who like it. I have to say that as a newcomer to git I do not like the idea of creating a special undo log for git. It would just be yet another concept to learn and another thing to add to the list of 'where is git hiding my data this time?'. And the time when it would be useful - after some bungled operation that lost data - is just the time when the user is already confused and adding another semi-hidden stash of objects to the mix would befuddle them further. If there is to be a backup made of local changes that get lost, and I agree it is a good idea, then it should be something stupid and completely obvious, such as saving the old file as 'foo.before_checkout.1'. -- Ed Avis -- 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: Suggestion: make git checkout safer
I had expected that 'git checkout .' would fix up my working tree to make it match the repository (in this case, the current revision of the master branch). When I originally ran it I had deleted a couple of files from the working tree and wanted to restore them. However, I expected that if doing the checkout operation would lose data currently on disk then git would prompt me first. To compare, 'git pull' will not silently overwrite local changes; it will prompt you to commit or stash them first. 'git checkout .' is a fairly innocuous-looking command; it doesn't contain any --force or --overwrite or other things that would make you think twice before typing it. So I suggest it should be equally safe to run. The user interface might be something like: % git checkout . error: Your local changes to the following files would be overwritten: foo You may want to commit or stash these changes, or delete the files if you don't want them. Use 'git checkout --force' to proceed, throwing away local changes. Aborting If the checkout operation would only involve creating some files on disk which aren't currently there, then it would proceed without prompting. -- Ed Avis -- 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
Suggestion: make git checkout safer
Currently a plain 'git checkout .' will revert any local changes, e.g. % mkdir test % cd test % git init Initialized empty Git repository in /home/eda/test/.git/ % echo hello >foo % git add foo % git commit -m. [master (root-commit) 34f6694] . 1 file changed, 1 insertion(+) create mode 100644 foo % echo goodbye >foo % git checkout . % cat foo hello I suggest this is dangerous and by default 'git checkout' should only alter files which do not have local changes (as would be reported by 'git diff'). Only if --force is given should working tree differences be thrown away. % git --version git version 2.4.0 -- Ed Avis -- 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 show' with multiple revisions
I would like to see the content of a file in multiple revisions. I can get them with 'git show' as follows: % git show REV1:FILE % git show REV2:FILE and so on. But that launches a new process for each revision. Now, there is the option to pass multiple arguments to 'git show': % git show REV1:FILE REV2:FILE This gets both revisions in a single process and so is faster. But it concatenates the content so there isn't a way to separate them out again. Could 'git show' sprout an option to get multiple things programmatically so that they can be separated out again? One way would be to quote or escape the contents somehow so that the result can be parsed: % git show --porcelain REV1:FILE REV2:FILE The question is what format should be used to output many strings to stdout. An alternative would be to specify an output file: % git show --output foo REV1:FILE# writes foo % git show --output foo REV1:FILE --output bar REV2:FILE # writes foo, bar Note that here I am only getting the file content, not log messages or any of the other things which 'git show' can produce. So perhaps what I really want is some kind of 'git cat'. Or is there another more appropriate tool? Thanks, -- Ed Avis -- 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
