Re: [PATCH v2] unblock and unignore SIGPIPE
Today I learned that software can be constipated. On Thu, Sep 18, 2014 at 12:35 PM, Junio C Hamano gits...@pobox.com wrote: 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 -- 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 13/13] contrib/subtree: Remove --annotate
On Mon, Feb 18, 2013 at 1:39 PM, gree...@obbligato.org wrote: James Nylen jny...@gmail.com writes: - add fancylib as a subtree of myprog - commit to myprog repo: fancylib: don't crash as much - split these commits back out to fancylib main repo, and remove the fancylib: prefix Should this really be a function of git-subtree? It seems like it would fit better in a history-rewriting command. Wouldn't rebase -i or even filter-branch be a better way to do this? I'm not a git guru by any stretch, so I'm sure there are other ways to accommodate the example use case above. I really just want to be able to split and merge repositories while keeping meaningful commit messages with an appropriate level of detail. Can you suggest an alternative workflow? If there's no --annotate I don't see why git-subtree should have the --unannotate functionality. Because they are not inverse operations - they both apply to `git subtree split`. I think that `--annotate` would only be useful as an option to `git subtree merge`. In that case it would be the inverse operation of `git subtree split --unannotate`, and then I would agree that if you remove one, you can/should remove the other. Again, I agree that your example is relevant, maybe even common, but I don't necessarily think git-subtree should be in the business of rewriting commit messages at all. I'm willing to accept that. Junio seemed to be leaning that way too in earlier emails. I'd appreciate more thoughts from you on this. I want to make sure we can support your use case. I currently need to enable `git subtree` manually anyway, since it's not part of the main distribution. So it's not a burden for me to support this feature with a customized script, or learn a new way to do it. Thanks for your consideration of this small and nit-picky issue. -- 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 request
On Mon, Feb 18, 2013 at 1:52 PM, Jay Townsend townsend...@hotmail.com wrote: Hi everyone, Just would like to request a security feature to help secure peoples github accounts more by supporting 2 factor authentication like the yubikey more information can be found from this link www.yubico.com/develop/ and googles 2 factor authentication. Hope it gets implemented as I think it would make a great feature This would most likely be something that users would set up with their SSH client, and GitHub would have to provide support for it on their servers as well. It shouldn't require any changes to git. Here is an example of how this could be done: http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/ I like the idea, and I would probably use it if it were available. Jeff, what do you think? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/13] contrib/subtree: Remove --annotate
On Tue, Feb 5, 2013 at 6:44 AM, gree...@obbligato.org wrote: Junio C Hamano gits...@pobox.com writes: Remove --annotate. This obviates the need for an --unannotate command. We really want a more generalized commit message rewrite mechanism. That may be a good goal as the end result, but wouldn't it be a bit unhelpful to remove these before adding such a more generalized mechanism to replace them? I did think about that. I sent out an e-mail some time ago asking for opinions on this. No one responded. Since this is in contrib/ I feel comfortable getting rid of this option early so that people don't get too attached to it. :) I don't agree that removing `--annotate` obviates the need for `--unannotate`. I responded on 1/17 with what I think is a typical and normal use case for that option: - add fancylib as a subtree of myprog - commit to myprog repo: fancylib: don't crash as much - split these commits back out to fancylib main repo, and remove the fancylib: prefix In my opinion this is a pretty normal workflow. Commits to fancylib in the myprog repo are prefixed with fancylib: , and that prefix becomes redundant and should be removed if those commits are split back out into the fancylib main repo. I also tried to come up with another situation that would justify a more general commit message rewriting facility, and I couldn't think of any other good use cases that don't involve removing a prefix. But that doesn't mean there aren't any. `--unannotate` is a clunky name, but I think this functionality is worth taking another look at. Maybe it could be called `--remove-prefix` ? -- 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] Add --unannotate option to git-subtree
On Mon, Dec 31, 2012 at 8:15 PM, gree...@obbligato.org wrote: James Nylen jny...@gmail.com writes: Rather than adding a marker to each commit when splitting out the commits back to the subproject, --unannotate removes the specified string (or bash glob pattern) from the beginning of the first line of the commit message. This enables the following workflow: I applied the patch to my working copy but it doesn't seem to do what I'd expect. The test script does something like this: - create project A - add file to project A with message subproj: add F1 - add file to project A with message subproj: add F2 - add project A as a subtree of project B under directory subdir - add a file to subdir with message subproj: add F3 - do a split --unannotate=subproj: I expected to see a log with no mention of subproj anywhere. Instead I get: add F3 subproj: add F2 subproj: add F1 Is this as you intend? Is --unannotate only supposed to strip the string for commits added when A was a subtree of B? I guess this behavior makes sense in that the user would want to see the same commits that existed before A became a subproject. -David Wow, I missed a bunch of emails on this. Thanks for applying and for writing tests! This is as intended. You wouldn't want subtree to modify commits that occurred in the full repository for project A. Furthermore, you wouldn't have a subproj: commit in project A's standalone repo since it wasn't a subproject at that time. The --annotate option confused me because it was the reverse of what I wanted. As in your example, a typical use would be 'add a file to subdir with message subproj: add F3 ' to make it clear that you were committing to the subproj part of a larger repository. Then, when splitting back out to subproj's main repository, you'd want to remove the prefix. -- 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/8] Add --unannotate
On Tue, Jan 1, 2013 at 5:31 PM, gree...@obbligato.org wrote: Junio C Hamano gits...@pobox.com writes: David A. Greene gree...@obbligato.org writes: From: James Nylen jny...@gmail.com Teach git-subtree about --unannotate. This option strips a prefix from a commit message when doing a subtree split. Hrm. This looks like a workaround for a short-sighted misdesign of the annotate option that only allowed prefixing a fixed string. I have to wonder if it is better to deprecate --annotate and replace it with a more general commit log rewriting facility that can cover both use cases? That's not a bad idea. I'd have to think a bit about a sensible design. Do you have any ideas, James? I just now saw these emails. I'm having a hard time thinking of any good use case other than: - add fancylib as a subtree of myprog - commit to myprog repo: fancylib: don't crash as much - split these commits back out to fancylib's main repo, and remove the fancylib: prefix You could potentially have something like Don't crash as much (fancylib) but that's awkward. What might you want to do with a pattern-based rewrite that doesn't involve removing a prefix when splitting commits? In fact, I don't see the use of the original --annotate option at all, since it causes more detailed commit messages in the smaller of the two repositories. -- 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: Wrap commit messages on `git commit -m`
On Thu, Nov 1, 2012 at 2:12 PM, Thomas Adam tho...@xteddy.org wrote: Hi, On 1 November 2012 16:07, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, Some of my colleagues are lazy to fire up an editor and write proper commit messages- they often write one-liners using `git commit -m`. However, that line turns out to be longer than 72 characters, and the resulting `git log` output is ugly. So, I was wondering if it would be a good idea to wrap these one-liners to 72 characters automatically. Can't you do this already? From git-log(1): I think he's talking about git-commit wrapping the message as it is being committed, instead of git-log doing the wrapping as it is being displayed. I personally would rather see git-commit refuse to accept messages wider than 72 characters. -- 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: Subtree in Git
On Fri, Oct 26, 2012 at 9:58 AM, David Michael Barr b...@rr-dav.id.au wrote: From a quick survey, it appears there are no more than 55 patches squashed into the submitted patch. As I have an interest in git-subtree for maintaining the out-of-tree version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted to make some sense of the organic growth that happened on GitHub. It doesn't appear that anyone else is willing to do this, so I doubt there will be any duplication of effort. David, I think that would be great. I wish I had time to work on unwrapping the current patch but I don't. I will definitely re-submit my (simple) patch after this is done though. -- 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] Add --unannotate option to git-subtree
On Tue, Oct 9, 2012 at 4:26 PM, James Nylen jny...@gmail.com wrote:
This new option does the reverse of --annotate, which is more useful
when contributing back to a library which is also included in the
repository for a larger project, and perhaps in other situations as
well.
Rather than adding a marker to each commit when splitting out the
commits back to the subproject, --unannotate removes the specified
string (or bash glob pattern) from the beginning of the first line of
the commit message. This enables the following workflow:
- Commit to a library included in a large project, with message:
Library: Make some amazing change
- Use `git-subtree split` to send this change to the library maintainer
- Pass ` --unannotate='Library: ' ` or ` --unannotate='*: ' `
- This will turn the commit message for the library project into:
Make some amazing change
This helps to keep the commit messages meaningful in both the large
project and the library project.
Signed-off-by: James Nylen jny...@gmail.com
---
Has anybody looked at this?
It has been very useful for me.
Let me know if gmail has munged this patch. You can also get at it
like this:
$ git remote add nylen git://github.com/nylen/git.git
$ git fetch nylen
$ git show nylen/subtree-unannotate
---
contrib/subtree/git-subtree.sh | 11 +--
contrib/subtree/git-subtree.txt | 15 +++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 920c664..8d1ed05 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -21,6 +21,7 @@ P,prefix= the name of the subdir to split out
m,message=use the given message as the commit message for the merge
commit
options for 'split'
annotate= add a prefix to commit message of new commits
+unannotate= remove a prefix from new commit messages (supports bash
globbing)
b,branch= create a new branch from the split subtree
ignore-joins ignore prior --rejoin commits
onto= try connecting new tree to an existing one
@@ -43,6 +44,7 @@ onto=
rejoin=
ignore_joins=
annotate=
+unannotate=
squash=
message=
@@ -80,6 +82,8 @@ while [ $# -gt 0 ]; do
-d) debug=1 ;;
--annotate) annotate=$1; shift ;;
--no-annotate) annotate= ;;
+ --unannotate) unannotate=$1; shift ;;
+ --no-unannotate) unannotate= ;;
-b) branch=$1; shift ;;
-P) prefix=$1; shift ;;
-m) message=$1; shift ;;
@@ -310,8 +314,11 @@ copy_commit()
GIT_COMMITTER_NAME \
GIT_COMMITTER_EMAIL \
GIT_COMMITTER_DATE
- (echo -n $annotate; cat ) |
- git commit-tree $2 $3 # reads the rest of stdin
+ (
+ read FIRST_LINE
+ echo $annotate${FIRST_LINE#$unannotate}
+ cat # reads the rest of stdin
+ ) | git commit-tree $2 $3
) || die Can't copy commit $1
}
diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
index 0c44fda..ae420aa 100644
--- a/contrib/subtree/git-subtree.txt
+++ b/contrib/subtree/git-subtree.txt
@@ -198,6 +198,21 @@ OPTIONS FOR split
git subtree tries to make it work anyway, particularly
if you use --rejoin, but it may not always be effective.
+--unannotate=annotation::
+ This option is only valid for the split command.
+
+ When generating synthetic history, try to remove the prefix
+ annotation from each commit message (using bash's strip
+ shortest match from beginning command, which supports
+ globbing). This makes sense if you format library commits
+ like library: Change something or other when you're working
+ in your project's repository, but you want to remove this
+ prefix when pushing back to the library's upstream repository.
+ (In this case --unannotate='*: ' would work well.)
+
+ Like --annotate, you need to use the same annotation
+ whenever you split, or you may run into problems.
+
-b branch::
--branch=branch::
This option is only valid for the split command.
--
1.7.11.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
