Re: [PATCH] contrib/subtree bugfix: Can't `add` annotated tag
On Fri, May 09, 2014 at 05:36:15PM +1000, James Denholm wrote: Junio C Hamano gits...@pobox.com wrote: Would it be sufficient to do git commit-tree $tree $headp -p $rev^0 in that not squashing codepath instead? On line 561, sure. Do you want me to do a re-roll? Sorry to bump, but do you want a reroll on this? --- Regards, James Denholm. -- 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: Should git-remote-hg/bzr be part of the core?
Linus Torvalds wrote: On May 12, 2014 8:35 AM, Felipe Contreras felipe.contre...@gmail.com wrote: This move is already under way, but suddenly Junio changed his mind. That suddenly wouldn't have anything to do with you being an ass and difficult as usual, arguing about everything and just generally being contrary? No, here's where the thread started (A): http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248167 Here I wasn't being an ass: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248186 Here I wasn't being an ass either: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248171 Neither here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248146 Nor here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248195 Nor here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248205 Not an ass here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248213 And not here either: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248236 Then Junio *suddenly* changed his mind (B): http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248242 That is the sequence of mails (A..B) where I responded, and I wasn't an ass in eithe one of those, so whatever made Junio change his mind happened in that interum, and it wasn't me being an ass. I bet you made that statement without even botherting to read the thread. Go on, read the thread, tell where exactly me being an ass made Junio change his mind from A, to B. Nah, you wouldn't do that, backing up your claims take time, and you are not willing to spend time on this issue. Even if you were to try to back up your claim, you couldn't, becasue it's not true. It's much easier to just throw good sounding baseless claims and walk away. Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. You make absolutely everything be this horrible disaster, you redefine words (regression) to be whatever you need/want them to be to be git-remote-hg and git-remote-bzr will likely break in Git v2.0 in certain situations where they wouldn't in v1.9, or v1.8. Call it whatever you want. I call that a regression. Seriously. Don't try to make this about Junio somehow being the problem. So Junio is perfect. Got it. If you don't have the time to actually read the rationale behind Junio's decision, how would you even know he made the right one? You are just blindly assuming he is right, and therefore he is not the problem. What if he was wrong? Nah, that's impossible. Right? -- Felipe Contreras -- 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: Should git-remote-hg/bzr be part of the core?
Felipe Contreras wrote: Linus Torvalds wrote: Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. Here, let me show you. Junio, can you answer these questions? 1) What is missing from git-remote-hg/bzr in order for them to be considered to be merged to the core? 2) If a different maintainer steps up, would you consider reconsider merging them to the core? 3) Is there any chance that in the future you would consider them after they are more mature, and/or perhaps with a different maintainer? Unless Junio changes his mind again, the answers to those questions should be clear already to the people following the discussion (i.e. not you). -- Felipe Contreras -- 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: Should git-remote-hg/bzr be part of the core?
On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Those arguments were discussed at length and I think their weight is on the side of not moving it. But there are two other (in my opinion, stronger) reasons for keeping git-remote-hg out of the core: 1. That subproject has not been maintained to the standards of the Git project; specifically, Git project standards include good commit messages and a willingness to engage with the community on a friendly and constructive way and to welcome feedback. Because of your confrontational and nit-picking style, Felipe, many people who have tried to help you improve your work are rebuffed and end up giving up out of frustration or exhaustion. Because of this, your commits do not benefit from the usual amount of help from the community and therefore their quality is not as high as required for commits to core Git. 2. Moving git-remote-hg into the core would require even *more* of your presence on the Git mailing list. But your very presence is detrimental to the rest of the community. You insult and frustrate people who are trying to help you. You attribute malign motivations to people who are trying to be scrupulously fair. You string out enormous threads of nit-picking, legalistic argumentativeness that have little to do with the real issues at hand. The last big Felipe eruption in the summer of 2013 caused an enormous amount of strife, wasted an inordinate amount of time of other community members, and caused at least one valued contributor to temporarily rage-quit the community. That episode only ended when Junio asked you to leave the community [1], which, thankfully, you did for a while. After you left, the atmosphere of the mailing list soon returned to its usual friendly, collegial, and efficient norm. Recently you returned to the mailing list. In my opinion everybody on the list, including especially Junio, interacted with you in a very polite and businesslike manner. I believe you were given an honest chance at a fresh start in the community. I wish you had taken it. The Git project could really benefit from the help of a skilled and energetic developer like you! But it didn't take long before you started the same theatrics again. And now again, dealing with your caustic attitude is wasting an order of magnitude more time of the other core developers than your contributions could possibly bring in benefits. For me, the conclusion is unfortunate but clear: Felipe Contreras is (by far) a net liability to the Git project. Specifically: * The Git project will progress faster without you because the other contributors will have to waste less time dealing with your antics. * The Git community will grow faster without you, because your presence will not cause existing contributors to withdraw and dissuade new contributors from joining. * The community will be a lot more pleasant without you. Therefore, I am happy that you have apparently decided to split git-remote-hg into a separate project. I wish you success with the project and I see no reason that it shouldn't continue to be successful. But I am glad that I will not have to interact with you anymore. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Given the huge amount of work I've put in these remote helpers, and the fact that Junio said since day 1 he wanted these in the core[5] (and I was operating under that assumption), I think the demotion back to the contrib area (and therefore out-of-tree) should be made carefully, and not from one day to he next as it happened. None of the work was wasted. git-remote-hg can live on. This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you the best in your future endeavors. Michael [1] http://article.gmane.org/gmane.comp.version-control.git/227750 -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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: Should git-remote-hg/bzr be part of the core?
2014-05-12 10:12 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com: Felipe Contreras wrote: Linus Torvalds wrote: Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. Here, let me show you. I suspect Linus had a reason not to include the mailing lists in the first place and make a huge public discussion, but instead wrote to you personally. I guess this is just Linus desire not to waste the time of everybody as he learned that these discussions are fruitless sometimes. Junio C Hamano wrote [in another thread]: I would not mind asking the others, as your discussion tactic seems to be repeated voices start sounding like a chorus, and a chorus is project concensus. Those who are observing from the sideline, please raise your hand if you think the three-line Clarification Felipe gave us is a fair and accurate clarification. Anybody? I also do not mind seeing hands raised of those who do not agree, even though I already know that they would be a silent majority. I think Junio is behaving very professional unlike you, Felipe. This includes being polite and very patient. Also this includes weighting different reasons to make informed rational decisions. Git being a project widely used and people trusting it for their work needs to have high quality and cannot go left today and go right tomorrow, but most of the decisions are done long-term. Felipe, this may be the reason, why you think nothing changes. It's just slower than you'd like, but with more thoughts weighted. Junio, I think you're doing an awesome job in maintaining Git and leading the community. Stefan -- 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: Should git-remote-hg/bzr be part of the core?
Michael, Thank you for writing this, I have to see I agree completely. As a mostly lurker on this list, I tend to skip any thread Felipe is participating in, as it tends to quickly spiral out of control. This is also the main reason for me not to actively participate a bit more, I prefer reasonable discussions over fighting. On ma, 2014-05-12 at 11:42 +0200, Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Those arguments were discussed at length and I think their weight is on the side of not moving it. But there are two other (in my opinion, stronger) reasons for keeping git-remote-hg out of the core: 1. That subproject has not been maintained to the standards of the Git project; specifically, Git project standards include good commit messages and a willingness to engage with the community on a friendly and constructive way and to welcome feedback. Because of your confrontational and nit-picking style, Felipe, many people who have tried to help you improve your work are rebuffed and end up giving up out of frustration or exhaustion. Because of this, your commits do not benefit from the usual amount of help from the community and therefore their quality is not as high as required for commits to core Git. 2. Moving git-remote-hg into the core would require even *more* of your presence on the Git mailing list. But your very presence is detrimental to the rest of the community. You insult and frustrate people who are trying to help you. You attribute malign motivations to people who are trying to be scrupulously fair. You string out enormous threads of nit-picking, legalistic argumentativeness that have little to do with the real issues at hand. The last big Felipe eruption in the summer of 2013 caused an enormous amount of strife, wasted an inordinate amount of time of other community members, and caused at least one valued contributor to temporarily rage-quit the community. That episode only ended when Junio asked you to leave the community [1], which, thankfully, you did for a while. After you left, the atmosphere of the mailing list soon returned to its usual friendly, collegial, and efficient norm. Recently you returned to the mailing list. In my opinion everybody on the list, including especially Junio, interacted with you in a very polite and businesslike manner. I believe you were given an honest chance at a fresh start in the community. I wish you had taken it. The Git project could really benefit from the help of a skilled and energetic developer like you! But it didn't take long before you started the same theatrics again. And now again, dealing with your caustic attitude is wasting an order of magnitude more time of the other core developers than your contributions could possibly bring in benefits. For me, the conclusion is unfortunate but clear: Felipe Contreras is (by far) a net liability to the Git project. Specifically: * The Git project will progress faster without you because the other contributors will have to waste less time dealing with your antics. * The Git community will grow faster without you, because your presence will not cause existing contributors to withdraw and dissuade new contributors from joining. * The community will be a lot more pleasant without you. Therefore, I am happy that you have apparently decided to split git-remote-hg into a separate project. I wish you success with the project and I see no reason that it shouldn't continue to be successful. But I am glad that I will not have to interact with you anymore. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Given the huge amount of work I've put in these remote helpers, and the fact that Junio said since day 1 he wanted these in the core[5] (and I was operating under that assumption), I think the demotion back to the contrib area (and therefore out-of-tree) should be made carefully, and not from one day to he next as it happened. None of the work was wasted. git-remote-hg can live on. This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you the
Re: Watchman support for git
On Mon, May 12, 2014 at 5:56 AM, David Turner dtur...@twopensource.com wrote: So without watchman I got 299.871ms read_index_from:1538 if (verify_hdr(hdr, mmap_size) 0) go 498.205ms cmd_status:1300 refresh_index(the_index, REFRESH_QUIE 796.050ms wt_status_collect:622 wt_status_collect_untracked(s) and with watchman (git status ran several times to make sure it's cached) 301.950ms read_index_from:1538 if (verify_hdr(hdr, mmap_size) 0) go 34.918ms read_fs_cache:347 if (verify_hdr(hdr, mmap_size) 0) go 1564.096ms watchman_load_fs_cache:628 update_fs_cache(istate, result); 161.930ms cmd_status:1300 refresh_index(the_index, REFRESH_QUIE 251.614ms wt_status_collect:622 wt_status_collect_untracked(s) Given the total time of git status without watchman is 1.9s,, update_fs_cache() nearly matches that number alone. All that is spent in the exclude update code in the function, but if you do last_excluding_matching() anyway, why cache it? My numbers are different (for my test repository): --- 30.031ms read_index:1386 r = read_index_from(istate, get_index_ 71.625ms cmd_status:1302 refresh_index(the_index, REFRESH_QUIE 259.712ms wt_status_collect:622 wt_status_collect_untracked(s) 41.110ms read_index:1386 r = read_index_from(istate, get_index_ 9.294ms read_fs_cache:347 if (verify_hdr(hdr, mmap_size) 0) go 0.173ms watchman_load_fs_cache:628 update_fs_cache(istate, result) 41.901ms read_index:1386 r = read_index_from(istate, get_index_ 18.355ms cmd_status:1302 refresh_index(the_index, REFRESH_QUIE 50.911ms wt_status_collect:622 wt_status_collect_untracked(s) --- I think something must be going wrong with update_fs_cache on your machine. I have a few hypotheses: 1. Maybe watchman isn't fully started up when you run your tests. 2. Maybe there is a bug. It's probably me doing something wrong (I ran it more than a couple times so watchman must have loaded the whole thing). I got small numbers in update_fs_cache() now. A bit surprised about wt_status_collect_untracked number. I verified that last_excluding_matching() still runs (on the same number of entries like in no-watchman case). Replacing fs_cache_open() in add_excludes_from_file_to_list() to plain open() does not change the number, so we probably won't need that (unless your worktree is filled with .gitignore, which I doubt it's a norm). My test repo has a couple hundred of them. Maybe that's unusual? A repo with a lot of projects will tend to have lots of gitignore files, because each project will want to maintain them independently. I tried the worst case, every directory had an empty .gitignore. The numbers did not change much. And I found out that because add_excludes.. were called twice, not on every .gitignore because of the condition !(dir-flags DIR_EXCLUDE_CMDL_ONLY). So the number of .gitignore does not matter (yet). This is your quote from above, moved down a bit: update_fs_cache should only have to update based on what it has learned from watchman. So if no .gitignore has been changed, it should not have to do very much work. I could take the fe_excluded check and move it above the last_exclude_matching check in fs_cache_is_excluded; it causes t7300 to fail when run under watchman but presumably that's fixable So you exclude files early and make the real read_directory() pass do pretty much nothing. This is probably not a good idea. Assume that I touch $TOP/.gitignore then do something other than git status (or git add) then I have to pay read_directory() cost. Back to the open vs fs_cache_open and the number of .gitignore files above. I touch $TOP/.gitignore then do git status to make it read all .gitignore files (6k of them) and change between open and fs_cache_open. I think the numbers still do not make any visible difference (~1620-1630ms). -- 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: Should git-remote-hg/bzr be part of the core?
Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. You mention there are good technical arguments against the graduation of the tools. Surely if you have analyzed those arguments enough to form an opinion aligned with Junio's, it should be easy to provide a short summary of those good technical arguments. Can you do that? 1. That subproject has not been maintained to the standards of the Git project; The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. 2. Moving git-remote-hg into the core would require even *more* of your presence on the Git mailing list. That's not true. I sent my patches at my own pace, it doesn't matter if they are in contrib or in the core, I would have kept sending them at the same pace. I have addressed all issues and responded to all questions as if they were already part of the core, which is why they have more quality than other tools already in the core. I only stopped doing that when Junio changed the direction we had since day one. Also a red herring. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Don't be ridiculous. There is no out-of-tree tool that could possibly compete in popularity against core tools. If you think being out-of-tree is not a negative, lets throw out git-archimport, git-quiltimport, git-p4, git-cvs, git-svn. Let us give them an opportunity to shine. You know that those tools do better in the core, and you know git-remote-hg/bzr would do better in the core. Don't act as if you didn't. This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you the best in your future endeavors. Let's see how sincere you are in your sentiment. I'll reply to you personally about the points that I consider to be red herrings and ad hominem attacks so we don't taint the dicussion. If you don't reply I'll know you were not being sincere. Cheers. -- Felipe Contreras -- 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: Should git-remote-hg/bzr be part of the core?
Michael Haggerty mhag...@alum.mit.edu writes: This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, [...] I think that's where you are mistaken. We are not talking about a lack of effort here. It is just not spent conducively. -- David Kastrup -- 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] gitk: Allow displaying time zones from author and commit timestamps
Now gitk can be configured to display author and commit dates in their
original timezone, by putting %z into datetimeformat in ~/.gitk.
Signed-off-by: Anders Kaseorg ande...@mit.edu
---
Re-sending from 2011:
http://thread.gmane.org/gmane.comp.version-control.git/165286/focus=174786
gitk | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 90764e8..b4712cd 100755
--- a/gitk
+++ b/gitk
@@ -11575,7 +11575,29 @@ proc prefsok {} {
proc formatdate {d} {
global datetimeformat
if {$d ne {}} {
- set d [clock format [lindex $d 0] -format $datetimeformat]
+ # If $datetimeformat includes a timezone, display in the
+ # timezone of the argument. Otherwise, display in local time.
+ if {[string match {*%[zZ]*} $datetimeformat]} {
+ if {[catch {set d [clock format [lindex $d 0] -timezone [lindex $d
1] -format $datetimeformat]}]} {
+ # Tcl 8.5 does not support -timezone. Emulate it by
+ # setting TZ (e.g. TZ=-0430+04:30).
+ global env
+ if {[info exists env(TZ)]} {
+ set savedTZ $env(TZ)
+ }
+ set zone [lindex $d 1]
+ set sign [string map {+ - - +} [string index $zone 0]]
+ set env(TZ) $zone$sign[string range $zone 1 2]:[string range
$zone 3 4]
+ set d [clock format [lindex $d 0] -format $datetimeformat]
+ if {[info exists savedTZ]} {
+ set env(TZ) $savedTZ
+ } else {
+ unset env(TZ)
+ }
+ }
+ } else {
+ set d [clock format [lindex $d 0] -format $datetimeformat]
+ }
}
return $d
}
--
2.0.0.rc3
--
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: Should git-remote-hg/bzr be part of the core?
On 05/12/2014 12:37 PM, Felipe Contreras wrote: Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. Actually, I don't have to, not even if you tell me to. And anyway, I think the small technical advantages/disadvantages of the possible different locations for git-remote-hg are dwarfed by the social considerations so I think dwelling on technical considerations would sidetrack this discussion. [...] 1. That subproject has not been maintained to the standards of the Git project; The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. On the contrary. I just called the quality of the subproject into question, and I stated exactly which aspects of its quality I find to be inadequate in the text that you omitted from your response: [...] specifically, Git project standards include good commit messages and a willingness to engage with the community on a friendly and constructive way and to welcome feedback. Because of your confrontational and nit-picking style, Felipe, many people who have tried to help you improve your work are rebuffed and end up giving up out of frustration or exhaustion. Because of this, your commits do not benefit from the usual amount of help from the community and therefore their quality is not as high as required for commits to core Git. Commit quality very definitely includes the quality of log messages and the quality of the discussion on the mailing list that can inform people working on those areas of the code in the future. 2. Moving git-remote-hg into the core would require even *more* of your presence on the Git mailing list. That's not true. I sent my patches at my own pace, it doesn't matter if they are in contrib or in the core, I would have kept sending them at the same pace. I have addressed all issues and responded to all questions as if they were already part of the core, which is why they have more quality than other tools already in the core. I only stopped doing that when Junio changed the direction we had since day one. Also a red herring. OK, maybe you are technically correct there. There is indeed a difference between and =. Let me amend my claim: 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Don't be ridiculous. There is no out-of-tree tool that could possibly compete in popularity against core tools. I never made that claim. I claimed that it was nothing like jail, and I stand by that claim. I also think that the Git community is a place unsuited to someone with your personality, and that you might truly shine more in an independent project. If you think being out-of-tree is not a negative, lets throw out git-archimport, git-quiltimport, git-p4, git-cvs, git-svn. Let us give them an opportunity to shine. In my opinion, the technical issues for moving importers are not overwhelming. Therefore, I don't have a strong opinion about the future of these other tools, because their presence in the Git tree is not coupled to the continued presence of a problematic subproject maintainer. You know that those tools do better in the core, and you know git-remote-hg/bzr would do better in the core. Don't act as if you didn't. I maintain cvs2svn/cvs2git outside of the Git core. In fact, one of cvs2git's competitors, git cvsimport *is* in Git core. Nevertheless, users have no problem finding cvs2git, and I think it's safe to say that its reputation exceeds that of git cvsimport, even though some people accidentally use git cvsimport out of laziness. People who need to do a conversion from A to B only have to Google for A B and they will find the best conversion tools pretty easily. If the tools are packaged for their OS then they are just an apt-get install away from happiness. And given that tools like cvs2git or git-remote-hg, don't even need to be compiled, users can install them pretty easily themselves. This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy
Re: Should git-remote-hg/bzr be part of the core?
Stefan Beller wrote: 2014-05-12 10:12 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com: Felipe Contreras wrote: Linus Torvalds wrote: Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. Here, let me show you. I suspect Linus had a reason not to include the mailing lists in the first place Huh? He did include the mailing lists in the first place[1]. Either something is wrong with the mailing list, or somebody is removing the mails. You can see the full thread in the git-fc mailing list, and there you can see the git ml is included in all the mails, including the one you just sent, where you included the git ml, and it doesn't show in the archives. and make a huge public discussion, but instead wrote to you personally. I guess this is just Linus desire not to waste the time of everybody as he learned that these discussions are fruitless sometimes. Don't you agree that including transparent bridges for Mercurial and Bazaar distributed by default would be benefitial to the project? If a discussion could potentially lead to them being included, I'd say that wouldn't be fruitless, but it's *precisely* what our end users would like us to be discussing right now. Junio C Hamano wrote [in another thread]: I would not mind asking the others, as your discussion tactic seems to be repeated voices start sounding like a chorus, and a chorus is project concensus. Those who are observing from the sideline, please raise your hand if you think the three-line Clarification Felipe gave us is a fair and accurate clarification. Anybody? I also do not mind seeing hands raised of those who do not agree, even though I already know that they would be a silent majority. I think Junio is behaving very professional unlike you, Felipe. This includes being polite and very patient. Also this includes weighting different reasons to make informed rational decisions. Where is he weighting the different reasons? I've asked him multiple times to provide those reasons. He mensions there's one, but he doesn't say which one it is. If I haven't see this reason, how do you know he is weighing different ones? Git being a project widely used and people trusting it for their work needs to have high quality and cannot go left today and go right tomorrow, but most of the decisions are done long-term. Yes. What is right, and what is left in this example? Presumably going right would be to include these tools in the core, but that would imply that he plans to go left in the future. But he hasn't said that. So what makes you think the project would go left in the future? Felipe, this may be the reason, why you think nothing changes. It's just slower than you'd like, but with more thoughts weighted. Really? I'll issue the same challenge I've issued to many people. Name a single important change in Git (was one way before, it's another way now) that has happened in the last 5 years. And by important I mean for starters users noticed it. You won't be able to, because nothing ever changes. Junio, I think you're doing an awesome job in maintaining Git and leading the community. Maintaining, yes, but leading? Leading it where? [1] https://groups.google.com/forum/#!original/git-fc/Clhss-fXS2k/9UtiilJ2WQ4J -- Felipe Contreras -- 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 0/4] remote-hg: more improvements
Nevermind, it'd be more efficient to cover this in the other main thread started by Felipe. You can answer my questions there instead as it'll likely benefit a wider audience. Philippe -- 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: Should git-remote-hg/bzr be part of the core?
Michael Haggerty wrote: On 05/12/2014 12:37 PM, Felipe Contreras wrote: Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. Actually, I don't have to, Then there's no point in reading what else you have to say. Whatever reasons you might have to agree with Junio are known only to you, thus your agreement is opaque and meaningless. The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. On the contrary. I just called the quality of the subproject into question, and I stated exactly which aspects of its quality I find to be inadequate in the text that you omitted from your response: I'll wait until somebody else calls into question the quality. Preferably somebody who backs up his claims with evidence. OK, maybe you are technically correct there. There is indeed a difference between and =. Let me amend my claim: 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. That is another red herring. Moving them back to the contrib/ area which is what Junio proposed would also require my presence on the list. Is that what you want? And there's the transport helper, and bash completion, and the zsh completion. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Don't be ridiculous. There is no out-of-tree tool that could possibly compete in popularity against core tools. I never made that claim. I claimed that it was nothing like jail, and I stand by that claim. In the context of the Git project what is the *worst* thing the maintainer can do to a piece of code but delete it? So I think you are right, the jail analogy is not correct; it's *execution*. You know that those tools do better in the core, and you know git-remote-hg/bzr would do better in the core. Don't act as if you didn't. People who need to do a conversion from A to B only have to Google for A B and they will find the best conversion tools pretty easily. Let's test that hypothesis: Google: how to conver mercurial to git * Convert Mercurial project to Git - Stack Overflow (NOPE) * Converting a Mercurial repository to Git (YEAP: one among many) Oh, but would you look at that: This script will actually be shipping with git at some point, which gives it some credibility in my book. * frej/fast-export · GitHub (NOPE) * Hg-Git Mercurial Plugin (NOPE) * Converting Hg repositories to Git (NOPE) * Converting from Mercurial to Git - Hivelogic (NOPE) * Converting Repositories From Git to Mercurial (NOPE) * hg-fast-export: convert Mercurial repositories (NOPE) * Converting Mercurial (Hg) to Git Repository on Mac (NOPE) * Bitbucket: Converting Hg repositories to Git (NOPE) So pretty much hypoethesis failed. That fact that you would even think people would quickly find about git-remote-hg shows exactly how detached you are from the problem. If the tools are packaged for their OS then they are just an apt-get install away from happiness. Oh, they are packaged already (as part of Git). Moving them out-of-tree will make it much more difficult for users to find them, and install them. It will take time for them to be packaged, if it happens at all. Let's see how sincere you are in your sentiment. I'll reply to you personally about the points that I consider to be red herrings and ad hominem attacks so we don't taint the dicussion. If you don't reply I'll know you were not being sincere. Jumping at your every demand is not a prerequisite for being sincere. I spent a lot of time writing that mail. Not sincere it is then. -- Felipe Contreras-- 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/2] Make it possible to update git_wcwidth()
Torsten Bögershausen: The function git_wcwidth() returns for a given unicode code point the width on the display: -1 for control characters, 0 for combining or other non-visible code points 1 for e.g. ASCII 2 for double-width code points. This all looks sane, but the problem is that this is also context-dependent since there are a lot of characters with ambiguous widths, i.e., characters that are double width for CJK locales (and fonts), but single width for others. This includes Greek and Cyrillic characters, which are encoded using the double-byte parts of the CJK DBCS encodings. I'm not quite sure how much impact this would have on day-to-day Git operation in a CJK locale, however, as I guess they would mostly encounter texts in their own language (which would mostly be double width) or English (which would be unambiguously single width). Anyone on the list running Git in a CJK locale that would like to weigh in here? -- \\// Peter - http://www.softwolves.pp.se/ -- 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: Should git-remote-hg/bzr be part of the core?
Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty mhag...@alum.mit.eduwrote: Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you the best in your future endeavors. I really *love* this paragraph. Felipe, you are a brilliant developer and you put a lot of work trying to improve GIT. Thanks. While I agree with you the this project is managed in a bit conservative way Only a bit? I don't think I've been involed in a more conservative open source project. you should really improve how you communicate with other developers, it's such a pity your contributions are some times not included in git.git just because of your attitude. But that's a theory. You don't *know* that they would have been included had I used a different attitude. In fact, people have contacted me privately saying similar things, and I'll give you the same challenge I gave them. If you think a different attitude would get my patches in, how about *you* write the commit messages and the discussions for one of my stuck patch series. I'll send the mails as if I had written the content. If you are right, the different attitude would make the patches land in no time. I still think it's not right for patches to be rejected simply because of attitude, but I would accept you were right. But I think you already know that won't happen, the patches still won't get in, not because of the attitude, but because of what they are trying to do: change things. So if I *know* certain feature would be useful for Git users, I've listened to all the comments, and addressed all the problems, why would I give up on those patches? Why would I work on something more boring that won't benefit users as much but would have higher chances of getting in? I'm doing this on my own free time, I can choose to do whatever I want, in whatever way I want, so no, I'll keep working on what I think is important. If you really think the patches can be accepted with a different attitude, by all means, let's do the experiment and find out. -- Felipe Contreras -- 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: Should git-remote-hg/bzr be part of the core?
Felipe Contreras felipe.contre...@gmail.com writes: Michael Haggerty wrote: On 05/12/2014 12:37 PM, Felipe Contreras wrote: Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. Actually, I don't have to, Then there's no point in reading what else you have to say. Whatever reasons you might have to agree with Junio are known only to you, thus your agreement is opaque and meaningless. Let me spell it out for you. Michael states I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Since there are arguments for both sides, the decision boils down to a judgment call. Michael states that he condones the choice Junio made, based on the reasoning he gave. Does that mean that he examined the choice with equal detail and remembers every detail? No. In such a decision, both technical expertise as well as trust based on a past record factor in. The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. On the contrary. I just called the quality of the subproject into question, and I stated exactly which aspects of its quality I find to be inadequate in the text that you omitted from your response: I'll wait until somebody else calls into question the quality. Preferably somebody who backs up his claims with evidence. The evidence for the toxicity of dealing with subprojects maintained by you is all over the mailing list. You are obviously blind to it yourself. Feel free to print out a few salient threads where you argue in favor of your points and ask someone you trust about his impression about how you come across. Let's see how sincere you are in your sentiment. I'll reply to you personally about the points that I consider to be red herrings and ad hominem attacks so we don't taint the dicussion. If you don't reply I'll know you were not being sincere. Jumping at your every demand is not a prerequisite for being sincere. I spent a lot of time writing that mail. Not sincere it is then. That kind of exchange is what you should show some of your personal friends and ask them whether it will likely lead to the desired understanding and ultimately reaction in the reader. Because that is what communication is about. Of course, one can try bypassing understanding and directly aim for a particular reaction: that is being manipulative. You are hardly in danger of being manipulative: that would require a basic understanding of people. So all you can really aim for is understanding: presenting your best case. Forget about rhetorics and the like: you suck at them, and a technical audience is easily annoyed by them even when they are employed well. And if a calm presentation does not lead others to the same conclusion that you would draw, deal with the consequences. Throwing tantrums will only bias people against you when you have the next case to present. -- David Kastrup -- 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: Should git-remote-hg/bzr be part of the core?
On 05/12/2014 02:29 PM, Felipe Contreras wrote: Michael Haggerty wrote: [...] 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. That is another red herring. Moving them back to the contrib/ area which is what Junio proposed would also require my presence on the list. Is that what you want? No, actually my preference is that git-remote-hg be separated from the Git project altogether, for the reasons that I stated earlier. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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: Should git-remote-hg/bzr be part of the core?
On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty mhag...@alum.mit.eduwrote: While I agree with you the this project is managed in a bit conservative way Only a bit? I don't think I've been involed in a more conservative open source project. you should really improve how you communicate with other developers, it's such a pity your contributions are some times not included in git.git just because of your attitude. But that's a theory. You don't *know* that they would have been included had I used a different attitude. Well, you could at least try to act and communicate differently. In fact, people have contacted me privately saying similar things, and I'll give you the same challenge I gave them. If you think a different attitude would get my patches in, how about *you* write the commit messages and the discussions for one of my stuck patch series. I'll send the mails as if I had written the content. No, sorry but I'm NOT interested in lying to git community. Ciao, -- Paolo -- 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
Hello
Hello My name is joyJohnson i saw your profile today and became interested in you,i will also like to know you the more,and i want you to send an email to my email address so that i can give you my picture for you to know whom i am.Here is my email address (joyjohnson...@yahoo.com) I believe we can move from here , I am waiting for your mail to my email address above.joy (Remeber the distance or colour does not matter but love matters alot in life) please contact me here (joyjohnson...@yahoo.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
Error using git-remote-hg
Hello,
I have the following error while pushing to an hg repository though the remote
translator:
$ git remote -v
origin hg::ssh://charles...@hg.code.sf.net/u/charlesb05/lapdogapi (push)
origin hg::ssh://charles...@hg.code.sf.net/u/charlesb05/lapdogapi (fetch)
$ git push origin
Password:
searching for changes
no changes found
searching for changes
Traceback (most recent call last):
File /usr/local/bin/git-remote-hg, line 1254, in module
sys.exit(main(sys.argv))
File /usr/local/bin/git-remote-hg, line 1238, in main
do_export(parser)
File /usr/local/bin/git-remote-hg, line 1119, in do_export
if not push(parser.repo, peer, parsed_refs, p_revs):
File /usr/local/bin/git-remote-hg, line 1007, in push
ret = push_unsafe(repo, remote, parsed_refs, p_revs)
File /usr/local/bin/git-remote-hg, line 984, in push_unsafe
cg = repo.getbundle('push', heads=list(p_revs), common=common)
File /usr/local/lib/python2.7/site-packages/mercurial/repoview.py, line
217, in __getattr__
return getattr(self._unfilteredrepo, attr)
AttributeError: 'localrepository' object has no attribute 'getbundle'
I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew.
It used to work before, on this same repository, since then git and hg were
both upgraded.
Thanks for help,
—-
Charles
--
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: Should git-remote-hg/bzr be part of the core?
2014-05-12 15:45 GMT+02:00 Paolo Ciarrocchi paolo.ciarroc...@gmail.com: No, sorry but I'm NOT interested in lying to git community. It's not lying. See the Helped-By: lines in git.git commits. Often the help was formulating a correct and easy-to-understand commit message. -- 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: Should git-remote-hg/bzr be part of the core?
Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty mhag...@alum.mit.eduwrote: While I agree with you the this project is managed in a bit conservative way Only a bit? I don't think I've been involed in a more conservative open source project. you should really improve how you communicate with other developers, it's such a pity your contributions are some times not included in git.git just because of your attitude. But that's a theory. You don't *know* that they would have been included had I used a different attitude. Well, you could at least try to act and communicate differently. I have, it doesn't make a difference. In fact, people have contacted me privately saying similar things, and I'll give you the same challenge I gave them. If you think a different attitude would get my patches in, how about *you* write the commit messages and the discussions for one of my stuck patch series. I'll send the mails as if I had written the content. No, sorry but I'm NOT interested in lying to git community. Yeah, that's what I thought. I know what the result of such experiment would be though. -- Felipe Contreras -- 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: Should git-remote-hg/bzr be part of the core?
Michael Haggerty wrote: On 05/12/2014 02:29 PM, Felipe Contreras wrote: Michael Haggerty wrote: [...] 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. That is another red herring. Moving them back to the contrib/ area which is what Junio proposed would also require my presence on the list. Is that what you want? No, actually my preference is that git-remote-hg be separated from the Git project altogether, for the reasons that I stated earlier. Exactly. So your point 2. is completely irrelevant to the contrb/ vs. core debate. -- Felipe Contreras -- 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, libcurl and GSS-Negotiate
On Sat, 2014-05-10 at 21:01 +, brian m. carlson wrote: On Mon, May 05, 2014 at 12:21:33PM +0200, Ivo Bellin Salarin wrote: Well, I'm on Windows. using `git version 1.9.2.msysgit.0`. You can find all the exchanges, recorded with wireshark, of the following usecases: * git vanilla (not working), * VisualStudio2013 with libgit (working) * curl (--ntlm, working) * curl (--negotiate, not working) Okay, so what it looks like is that for some reason, the server and libcurl refuse to connect with Negotiate authentication. git uses CURLAUTH_ANY, and libcurl picks the best choice: Negotiate. The difference between your setup and mine is that I'm using Negotiate with Kerberos 5, and you're using Negotiate with NTLM. What it looks like is happening is that git is offering Negotiate data, and then your server is responding with a 401 Unauthorized. libgit2 (presumably using WinHTTP) continues in this case, retrying with a longer set of credential containing more data, but git gives up. While libgit2 does use WinHTTP by default on Windows, Visual Studio overrides this and uses their own HTTP transport (which makes the .NET stack to handle it) because of the way the prefer to do things, with just the one persistent connection to TFS. But details aside, the code Visual Studio uses to do authentication has nothing to do with any of the others. cmn -- 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/2] inline constant return from error() function
On Sun, May 11, 2014 at 10:22:03AM -0700, Junio C Hamano wrote: The alternative you mentioned up-thread ... to write out return error(...) as error(...); return -1. In some ways that is more readable, though it is more verbose... has one more downside you did not mention, and the approach to encapsulate it inside error() will not have it: new call-sites to error() do not have to worry about the issue with this approach. Until it breaks, that is. But that goes without saying with the it's something we can count on pre-condition in place ;-). Yeah, I agree with this thinking. I'd rather not do something that impacts each callsite until we have exhausted other options that hide the complexity in the definition. -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] git-add--interactive: Preserve diff heading when splitting hunks
On Sun, May 11, 2014 at 04:09:56PM +, Ævar Arnfjörð Bjarmason wrote:
Change the display of hunks in hunk splitting mode to preserve the diff
heading, which hasn't been done ever since the hunk splitting was
initially added in v1.4.4.2-270-g835b2ae.
Splitting the first hunk of this patch will now result in:
Stage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s
Split into 2 hunks.
@@ -792,7 +792,7 @@ sub hunk_splittable {
[...]
Instead of:
Stage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s
Split into 2 hunks.
@@ -792,7 +792,7 @@
[...]
This makes it easier to use the tool when you're splitting some giant
hunk and can't remember in which function you are anymore.
This makes a lot of sense to me. I did notice two interesting quirks,
one of which might be worth addressing.
One, there is a slightly funny artifact in that the hunk header comes
from the top of the context line, and that top is a different position
for each of the split hunks. So in a file like:
header_A
content
header_B
one
two
three
four
you might have a diff like:
@@ ... @@ header_A
header_B
one
two
+new line 1
three
+new line 2
four
The hunk header for new line 1 is A, because B itself is part of
the context. But the hunk header for new line 2, if it were an
independent hunk, would be B. We print A because we copy it from the
original hunk.
It probably won't matter much in practice (and I can even see an
argument that A is the right answer). And figuring out B here
would be prohibitively difficult, I would think, as it would require
applying the funcname rules internal to git-diff to a hunk that git-diff
itself never actually sees.
Since the output from your patch is strictly better than what we saw
before, I think there is no reason we cannot leave such an improvement
to later (or never).
The diff is somewhat larger than I initially expected because in order
to display the headings in the same color scheme as the output from
git-diff(1) itself I had to split up the code that would previously
color diff output that previously consisted entirely of the fraginfo,
but now consists of the fraginfo and the diff heading (the latter of
which isn't colored).
The func heading is not colored by default, but you can configure it to
be so with color.diff.func. I double-checked the behavior with your
patch: you end up with the uncolored header in the split hunks, because
it is parsed from the uncolored line. Which is not bad, but I think we
can trivially do better, just by adding back in the color as we do with
the fraginfo.
Like:
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index ed1e564..ac5763d 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -29,6 +29,10 @@ my ($fraginfo_color) =
$diff_use_color ? (
$repo-get_color('color.diff.frag', 'cyan'),
) : ();
+my ($funcname_color) =
+ $diff_use_color ? (
+ $repo-get_color('color.diff.func', ''),
+ ) : ();
my ($diff_plain_color) =
$diff_use_color ? (
$repo-get_color('color.diff.plain', ''),
@@ -902,7 +906,7 @@ sub split_hunk {
unshift @{$hunk-{DISPLAY}}, join(
,
$diff_use_color ? colored($fraginfo_color, $fraginfo) :
$fraginfo,
- $heading,
+ $diff_use_color ? colored($funcname_color, $heading) :
$heading,
\n
);
}
I didn't prepare a commit message because I think it should probably
just be squashed in.
-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 1/2] inline constant return from error() function
Hi,
Jeff King wrote:
On Mon, May 05, 2014 at 05:29:38PM -0400, Jeff King wrote:
I cannot think of any other way to make the compiler aware of the
constant value, but perhaps somebody else is more clever than I am.
This came to me in a dream, and seems to work.
Clever. :) Thanks for thinking it up.
[...]
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -331,7 +331,11 @@ extern void warning(const char *err, ...)
__attribute__((format (printf, 1, 2)))
* using the function as usual.
*/
#if defined(__GNUC__) ! defined(__clang__)
-#define error(...) (error(__VA_ARGS__), -1)
+static inline int const_error(void)
+{
+ return -1;
+}
+#define error(...) (error(__VA_ARGS__), const_error())
I wish we could just make error() an inline function that calls some
print_error() helper, but I don't believe all compilers used to build
git are smart enough to inline uses of varargs. So this looks like
the right thing to do.
I kind of wish we weren't in so much of an arms race with static
analyzers. Is there some standard way to submit our code as an idiom
that should continue not to produce warnings to be included in a
testsuite and prevent problems in the future?
Thanks,
Jonathan
--
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/2] Make it possible to update git_wcwidth()
Torsten Bögershausen tbo...@web.de writes:
The function git_wcwidth() returns for a given unicode code point the
width on the display:
-1 for control characters,
0 for combining or other non-visible code points
1 for e.g. ASCII
2 for double-width code points.
This table had been originally been extracted for one Unicode version,
probably 3.2.
Make it possible to update the to a later version of Unicode:
Factor out the table from utf8.c into unicode_width.h and
add the script update_unicode.sh to update the table based on the latest
Unicode specification files.
Thanks to
Peter Krefting pe...@softwolves.pp.se and
Kevin Bracey ke...@bracey.fi
for helping with their Unicode knowledge
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
I would say this is a good idea, but a few nitpicks.
diff --git a/unicode_width.h b/unicode_width.h
new file mode 100644
index 000..4db7803
--- /dev/null
+++ b/unicode_width.h
@@ -0,0 +1,288 @@
Please update the script (and the resulting file) to caution against
misuse/mismanagement of this file by adding a comment to at least
state:
- This is a generated file and you are not supposed to modify it; and
- This is to be included only once from one place in the code and
that is why this does not use the usual #ifndef X/#define X/#endif
double-inclusion guards.
An obvious and viable alternative to the second would be to do the
usual double-inclusion guard. I do not have much preference either
way.
+static const struct interval zero_width[] = {
...
+};
+static const struct interval double_width[] = {
...
+};
diff --git a/update_unicode.sh b/update_unicode.sh
new file mode 100755
index 000..000b937
--- /dev/null
+++ b/update_unicode.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+#See http://www.unicode.org/reports/tr44/
+#
+#Me Enclosing_Mark an enclosing combining mark
+#Mn Nonspacing_Mark a nonspacing combining mark (zero advance width)
+#Cf Format a format control character
Please have a SP after # in these comments to make them readable?
+#
+UNICODEWIDTH_H=../unicode_width.h
+if ! test -d unicode; then
+ mkdir unicode
+fi
Style:
if ! test -d unicode
then
...
fi
+( cd unicode
+ if ! test -f UnicodeData.txt; then
+ wget
http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt
+ fi
+ if ! test -f EastAsianWidth.txt; then
+ wget
http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt
+ fi
+ if ! test -d uniset; then
+ git clone https://github.com/depp/uniset.git
+ fi
+ (
+ cd uniset
+ if ! test -x uniset; then
+ autoreconf -i
+ ./configure --enable-warnings=-Werror CFLAGS='-O0 -ggdb'
What are these -O0 -ggdb about?
+ fi
+ make
+ )
+ echo static const struct interval zero_width[] = { $UNICODEWIDTH_H
+ UNICODE_DIR=. ./uniset/uniset --32 cat:Me,Mn,Cf + U+1160..U+11FF -
U+00AD |
+ grep -v plane $UNICODEWIDTH_H
+ echo }; $UNICODEWIDTH_H
+ echo static const struct interval double_width[] = {
$UNICODEWIDTH_H
+ UNICODE_DIR=. ./uniset/uniset --32 eaw:F,W $UNICODEWIDTH_H
+ echo }; $UNICODEWIDTH_H
+)
@@ -147,7 +90,7 @@ static int git_wcwidth(ucs_char_t ch)
return -1;
/* binary search in table of non-spacing characters */
- if (bisearch(ch, combining, sizeof(combining)
+ if (bisearch(ch, zero_width, sizeof(zero_width)
/ sizeof(struct interval) - 1))
To my eyes, that line looks folded at a funny place. I think it is
more conventional to fold after the operator, i.e.
if (bisearch(ch, zero_width, sizeof(zero_width) /
sizeof(struct interval) - 1))
but
if (bisearch(ch, zero_width,
sizeof(zero_width) / sizeof(struct interval) - 1))
may probably be a lot more logical and readable. Maybe it is just
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: [BUGFIX/RFC] git-show: fix 'git show -s' to not add extra terminator after merge commit
Max Kirillov m...@max630.net writes:
When git show -s is called for merge commit it prints extra newline
between any merge commit and the next one. This looks especially ugly for
--oneline and other single-line formats. Looks very much like a bug.
Yeah, it is not limited to one-line formats. For example:
$ git show -s v2.0.0-rc3^0 v2.0.0-rc3^1
ends with an extra blank line before you see your prompt, but if you
swap the revs:
$ git show -s v2.0.0-rc3^1 v2.0.0-rc3^0
you do not get the extra blank line. Instead, you have an extra
blank in between. And I agree that these extra blank lines look
very much like a bug.
This actually has broken some number of existing tests
(their fix not included), and might break some existing
scripts which already expect this extra newline.
So, is it yet not too late to fix this?
I would prefer to see it fixed eventually.
I haven't checked if the new extra check uses the right condition
yet, but from a cursory look and with a few examples I tried
manually, the version with your change seems to behave a lot more
sensibly.
A good way to double-check may be to see the fixes to the tests to
correct their wrong expectations, and if the updated expectation is
sensible. That way, we will find if the observations we made (your
problem description and my two examples above, and a few examples I
tried manually) covered all what matters, or if there are cases
where they indeed were expecting some sensible results which this
change would break that we missed. Offhand, I doubt we would find
any case where these extra blank lines are sensible expectations,
though.
combine-diff.c | 2 +-
t/t7007-show.sh | 8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 3b92c448..d2924de 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1331,7 +1331,7 @@ void diff_tree_combined(const unsigned char *sha1,
if (show_log_first i == 0) {
show_log(rev);
- if (rev-verbose_header opt-output_format)
+ if (rev-verbose_header opt-output_format
opt-output_format != DIFF_FORMAT_NO_OUTPUT)
Please wrap this long line, perhaps like:
if (rev-verbose_header opt-output_format
opt-output_format != DIFF_FORMAT_NO_OUTPUT)
printf(%s%c, diff_line_prefix(opt),
opt-line_termination);
}
diff --git a/t/t7007-show.sh b/t/t7007-show.sh
index e41fa00..d76c7db 100755
--- a/t/t7007-show.sh
+++ b/t/t7007-show.sh
@@ -25,6 +25,7 @@ test_expect_success 'set up a bit of history' '
git checkout -b side HEAD^^
test_commit side2
test_commit side3
+ test_merge merge main3
'
test_expect_success 'showing two commits' '
@@ -109,8 +110,11 @@ test_expect_success 'showing range' '
'
test_expect_success '-s suppresses diff' '
- echo main3 expect
- git show -s --format=%s main3 actual
+ cat expect -EOF
+ merge
+ main3
+ EOF
Please make it a habit to quote the EOF marker when you are not
placing things that require variable substitutions, to tell the
readers that they can coast their eyes over the here-document
without having to worry about them. For a short here-document
like this, it does not matter, but these things have a habit of
getting imitated without thinking by others, and it is better to be
defensive and consistent. I.e.
cat expect -\EOF
merge
main3
EOF
+ git show -s --format=%s merge main3 actual
test_cmp expect actual
'
--
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/2] Make it possible to update git_wcwidth()
Peter Krefting pe...@softwolves.pp.se writes: Torsten Bögershausen: The function git_wcwidth() returns for a given unicode code point the width on the display: -1 for control characters, 0 for combining or other non-visible code points 1 for e.g. ASCII 2 for double-width code points. This all looks sane, but the problem is that this is also context-dependent since there are a lot of characters with ambiguous widths, i.e., characters that are double width for CJK locales (and fonts), but single width for others. This includes Greek and Cyrillic characters, which are encoded using the double-byte parts of the CJK DBCS encodings. I'm not quite sure how much impact this would have on day-to-day Git operation in a CJK locale, however, as I guess they would mostly encounter texts in their own language (which would mostly be double width) or English (which would be unambiguously single width). Anyone on the list running Git in a CJK locale that would like to weigh in here? The issue does appear in the real life. A solution I've seen used in a terminaul emulator program was to give the user a choice to say I want ambiguous ones to be treated as double (or single). As a J-locale user, I naturally set the configuration to double while using that program (I no longer do). -- 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/2] inline constant return from error() function
On Mon, May 12, 2014 at 11:44:26AM -0700, Jonathan Nieder wrote:
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -331,7 +331,11 @@ extern void warning(const char *err, ...)
__attribute__((format (printf, 1, 2)))
* using the function as usual.
*/
#if defined(__GNUC__) ! defined(__clang__)
-#define error(...) (error(__VA_ARGS__), -1)
+static inline int const_error(void)
+{
+ return -1;
+}
+#define error(...) (error(__VA_ARGS__), const_error())
I wish we could just make error() an inline function that calls some
print_error() helper, but I don't believe all compilers used to build
git are smart enough to inline uses of varargs. So this looks like
the right thing to do.
Not just not all compilers, but not even gcc. If you declare it
always_inline, gcc will even complain you can't do that, it has
varargs.
For my curiosity, is there any compiler which _does_ inline varargs
calls? Clang would be the obvious guess.
I kind of wish we weren't in so much of an arms race with static
analyzers. Is there some standard way to submit our code as an idiom
that should continue not to produce warnings to be included in a
testsuite and prevent problems in the future?
I agree the arms race is frustrating, but I think the compiler is being
completely reasonable in this case. It has flagged code where it knows
a variable may be uninitialized depending on the return value from
error(). The only reason I as a human know it's a false positive is that
I know error() will always return -1. So it's not an idiom here, so much
as letting the compiler know everything we know.
It would just be nice if there was an easier way to do it.
I do think giving the compiler that information is nicer than an
attribute saying trust me, it's initialized. The constant return not
only silences the warnings, but it may actually let the compiler produce
better code (both in these cases, but in the hundreds of other spots
that call error()).
-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: Error using git-remote-hg
I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew. It used to work before, on this same repository, since then git and hg were both upgraded. In short: The remote helper of Git 1.9.3 is not compatible with hg 3.0 You can eiher downgrade hg, or rebuild Git and cherry-pick this commit: commit 58aee0864adeeb5363f2a06728596f9c9315811f Author: Felipe Contreras felipe.contre...@gmail.com Date: Sat May 3 21:16:54 2014 -0500 remote-hg: add support for hg v3.0 HTH /Torsten -- 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
Bug - Git reset --quiet not quiet
Good afternoon, When running this command on Git for Windows (version 1.9.2-preview20140411) git reset --quiet --hard with one file having read/write lock git ask this question : Unlink of file '' failed. Should I try again? (y/n) I will have expected the command --quiet to remove the question and auto-answer no. This broke an automated script we use. Good day Thomas-Louis Laforest, ing. jr, Jr. Eng. Chargé de projet, Project Leader solutions intégrées | integrated solutions T 819 542-5600 x3106 F 819 845-5600 tllafor...@arbault.ca The information contained herein is of private and confidential nature. It can be used only by the above-mentioned recipients. Any other person who would take note of it is advised that it is strictly forbidden for him to reveal the information, to distribute it or to copy it. If this communication were transmitted to you by mistake, warn us immediately by telephone or email, and erase the original, without taking a copy, revealing the content nor taking some measures based on it. Les renseignements contenus dans les présentes sont de nature privée et confidentielle. Ils ne peuvent être utilisés que par le ou les destinataires susmentionnés. Toute autre personne qui en prendrait connaissance est priée de noter qu'il lui est strictement interdit de les divulguer, de les distribuer ou de les copier. Si cette communication vous a été transmise par mégarde, veuillez nous en aviser immédiatement par téléphone ou par courriel, et effacer l'original, sans en tirer de copie, en dévoiler le contenu ni prendre quelque mesure fondée sur celui-ci. -- 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-add--interactive: Preserve diff heading when splitting hunks
On Mon, May 12, 2014 at 8:39 PM, Jeff King p...@peff.net wrote:
On Sun, May 11, 2014 at 04:09:56PM +, Ævar Arnfjörð Bjarmason wrote:
Change the display of hunks in hunk splitting mode to preserve the diff
heading, which hasn't been done ever since the hunk splitting was
initially added in v1.4.4.2-270-g835b2ae.
Splitting the first hunk of this patch will now result in:
Stage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s
Split into 2 hunks.
@@ -792,7 +792,7 @@ sub hunk_splittable {
[...]
Instead of:
Stage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s
Split into 2 hunks.
@@ -792,7 +792,7 @@
[...]
This makes it easier to use the tool when you're splitting some giant
hunk and can't remember in which function you are anymore.
This makes a lot of sense to me. I did notice two interesting quirks,
one of which might be worth addressing.
One, there is a slightly funny artifact in that the hunk header comes
from the top of the context line, and that top is a different position
for each of the split hunks. So in a file like:
header_A
content
header_B
one
two
three
four
you might have a diff like:
@@ ... @@ header_A
header_B
one
two
+new line 1
three
+new line 2
four
The hunk header for new line 1 is A, because B itself is part of
the context. But the hunk header for new line 2, if it were an
independent hunk, would be B. We print A because we copy it from the
original hunk.
It probably won't matter much in practice (and I can even see an
argument that A is the right answer). And figuring out B here
would be prohibitively difficult, I would think, as it would require
applying the funcname rules internal to git-diff to a hunk that git-diff
itself never actually sees.
Since the output from your patch is strictly better than what we saw
before, I think there is no reason we cannot leave such an improvement
to later (or never).
Good suggestion, but tricky as you point out. Another thing I've
wanted many times is to make it smart enough that when you edit code
like:
A()
B();
And change it to:
X();
Y();
The change from A-X and B-Y may be completely unrelated and just
made in code where the author didn't add whitespace between unrelated
statements.
But because you change all the lines the tool can't split them up, it
could try harder and split hunks like that if you add a whitespace
boundary, or just go all the way down to adding/removing individual
lines, so you wouldn't have to fall down to edit mode and do so
manually.
The diff is somewhat larger than I initially expected because in order
to display the headings in the same color scheme as the output from
git-diff(1) itself I had to split up the code that would previously
color diff output that previously consisted entirely of the fraginfo,
but now consists of the fraginfo and the diff heading (the latter of
which isn't colored).
The func heading is not colored by default, but you can configure it to
be so with color.diff.func. I double-checked the behavior with your
patch: you end up with the uncolored header in the split hunks, because
it is parsed from the uncolored line. Which is not bad, but I think we
can trivially do better, just by adding back in the color as we do with
the fraginfo.
Like:
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index ed1e564..ac5763d 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -29,6 +29,10 @@ my ($fraginfo_color) =
$diff_use_color ? (
$repo-get_color('color.diff.frag', 'cyan'),
) : ();
+my ($funcname_color) =
+ $diff_use_color ? (
+ $repo-get_color('color.diff.func', ''),
+ ) : ();
my ($diff_plain_color) =
$diff_use_color ? (
$repo-get_color('color.diff.plain', ''),
@@ -902,7 +906,7 @@ sub split_hunk {
unshift @{$hunk-{DISPLAY}}, join(
,
$diff_use_color ? colored($fraginfo_color, $fraginfo)
: $fraginfo,
- $heading,
+ $diff_use_color ? colored($funcname_color, $heading)
: $heading,
\n
);
}
I didn't prepare a commit message because I think it should probably
just be squashed in.
Well spotted, indeed, that should be squashed in.
On a related note I thought by doing color.ui=auto I was turning on
all the colors, it would be nice if there was a built-in colorscheme
that added more coloring to items like these across our tools, it's
useful to have the hunk headers colored differently so they stand out
more.
--
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: Error using git-remote-hg
Torsten Bögershausen wrote: I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew. It used to work before, on this same repository, since then git and hg were both upgraded. In short: The remote helper of Git 1.9.3 is not compatible with hg 3.0 You can eiher downgrade hg, or rebuild Git and cherry-pick this commit: No need to rebuild Git. You can also use the latest version: https://github.com/felipec/git-remote-hg -- Felipe Contreras-- 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 0/4] remote-hg: more improvements
Philippe Vaucher philippe.vauc...@gmail.com writes: It is *way* beyond the quality of any other tool in 'contrib/' and even some tools in the core, like 'git-request-pull' (which has known bugs), and probably even 'git-pt'. Junio, can you comment on this? I understand this probably doesn't really affect the issue at hand, but it'd help clarify if it's ever possible to move out of contrib/ nowadays. I was originally led to believe that its code quality was good enough, and that was why I merged the bottom three patches of the series even down to 'next' in the first place. But after seeing the Of course response that led to [*1*], which made me recall many patch-review interactions with him, I have started to have doubts. The code quality of Git that many projects have come to trust their code with is much more than just the code at each moment keeps working for the users as long as the original author is around. The maintainer of a port to the platform X may lose access to the platform after switching jobs, the maintainer of a bridge to the foreign system Y may stop needing to talk to the foreign system after completing the switch to Git. Anybody can be hit by a bus, get sick, or simply lose interest in his past creations. By reading git log contrib/remote-helpers and comparing it with the logs for the rest of the system, you would realize that the former would not lead to a quality discussion similar to the one that led to [*2*], which was only possible because the change was adequately described to allow anybody to understand the original issue the change was meant to solve. The commit that made the original change made it easy to ask a critical question: You are improving B but at the same time breaking A. Can we do better to help both A and B? And it allowed us to move forward without having to rob Peter to pay Paul. Granted, these contrib/ patches were applied with the understanding that contrib/ stuff can be substandard, because having anything is often better than having nothing, and you cannot go back in time to update the history to make these commits more useful to others who will come later. But I would be lying if I said that I would expect that things will suddenly improve and that the codebase will be maintained for the long haul in a healthy way the minute we move it out of contrib/ to the core. Especially after seeing [*1*], which is just one of the examples that illustrate that there clearly is no will to explain the changes to help others who come later to help maintaining the code. I'll take good care of the codebase, I've spend the time to make it better, Me, me, me, is not what the open source process is about. [References] *1* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341 *2* http://thread.gmane.org/gmane.comp.version-control.git/248075/focus=248204 -- 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-add--interactive: Preserve diff heading when splitting hunks
On Mon, May 12, 2014 at 09:42:56PM +0200, Ævar Arnfjörð Bjarmason wrote: Good suggestion, but tricky as you point out. Another thing I've wanted many times is to make it smart enough that when you edit code like: A() B(); And change it to: X(); Y(); The change from A-X and B-Y may be completely unrelated and just made in code where the author didn't add whitespace between unrelated statements. But because you change all the lines the tool can't split them up, it could try harder and split hunks like that if you add a whitespace boundary, or just go all the way down to adding/removing individual lines, so you wouldn't have to fall down to edit mode and do so manually. Yeah, I frequently run into this, too, and have just gotten good at editing the patch. :) I think splitting line-by-line, as you suggest, would be more general. However, working within a single cluster of lines is difficult (both line-by-line and in your whitespace example), because you have to correlate removed and added lines. E.g., the diff for your change above might look like: @@ ... @@ context -A(); -B(); +X(); + +Y(); more context We would want to end up with three hunks: -A(); +X(); + -B(); +Y(); but how do we know which preimage lines correspond with which postimage lines? You can probably come up with heuristics for this case (e.g., introduced whitespace gets its own hunk, and then count postimage lines from each end), but there are many harder cases. I didn't prepare a commit message because I think it should probably just be squashed in. Well spotted, indeed, that should be squashed in. If you do (or Junio does), I think the commit message needs a slight update. On a related note I thought by doing color.ui=auto I was turning on all the colors, it would be nice if there was a built-in colorscheme that added more coloring to items like these across our tools, it's useful to have the hunk headers colored differently so they stand out more. I don't set color.diff.func myself, but having just looked at it when playing with your patch, I think it looks nice (I did yellow). I also set color.diff.meta to magenta, which I think makes the hunk header stand out a bit more. So yeah, I'd be fine with proposing changes to the default color scheme, though I do not envy you the inevitable bikeshed war. :) -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, libcurl and GSS-Negotiate
On Sat, May 10, 2014 at 09:01:32PM +, brian m. carlson wrote: What it looks like is happening is that git is offering Negotiate data, and then your server is responding with a 401 Unauthorized. libgit2 (presumably using WinHTTP) continues in this case, retrying with a longer set of credential containing more data, but git gives up. Both responses comply with RFC 2616, by my reading. I guess there are a couple of choices here: * Make your web server happy with the data that it gets passed initially. * Make git understand that it really needs to try again with different credentials in this case (how to do that is unknown). It should be pretty straightforward to loop again; http_request_reauth just needs to turn into a for-loop on getting HTTP_REAUTH, rather than a static two-tries (I even had a patch for this a while ago, but the function has changed a bit in the interim). The tricky part is figuring out when to return HTTP_NOAUTH (do not try again, we failed) versus HTTP_REAUTH (get credentials and try again) in handle_curl_result. Right now the decision is based on did we have a username and password for this request? I'm not clear on what extra bits would be needed to decide to continue in the case you guys are discussing. * Provide some way of forcing git to use a particular authentication protocol. Yeah, we just set CURLAUTH_ANY now, but it would be fairly trivial to add http.authtype and http.proxyauthtype to map to CURLOPT_HTTPAUTH and CURLOPT_PROXYAUTH. -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 0/4] remote-hg: more improvements
Junio C Hamano wrote: Philippe Vaucher philippe.vauc...@gmail.com writes: It is *way* beyond the quality of any other tool in 'contrib/' and even some tools in the core, like 'git-request-pull' (which has known bugs), and probably even 'git-pt'. Junio, can you comment on this? I understand this probably doesn't really affect the issue at hand, but it'd help clarify if it's ever possible to move out of contrib/ nowadays. I was originally led to believe that its code quality was good enough, and that was why I merged the bottom three patches of the series even down to 'next' in the first place. But after seeing the Of course response that led to [*1*], which made me recall many patch-review interactions with him, I have started to have doubts. This is bullshit, and a wrong direction fallacy. Event #1: Junio rejects the graduation http://article.gmane.org/gmane.comp.version-control.git/248263 Event #2: I give up improving remote helpers in git.git http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341 Junio is trying to make you believe that his decision (#1) was caused by something I did (#2). Don't fall into that trap, #2 happened *AFTER* #1, it can't possibly be the cause. But I would be lying if I said that I would expect that things will suddenly improve and that the codebase will be maintained for the long haul in a healthy way the minute we move it out of contrib/ to the core. Especially after seeing [*1*] [1] happened *AFTER* you made that stupid decision. Don't make it look as if your decision was caused by [1], *YOU* caused [1]. If you want to show that the quality of the commit messages or the code caused that decision, show an issue in that respect that happened *BEFORE* your decision. It is very clear what is happening. Junio made a wrong decision based a non-issue, then it became abudantly clear that there was no basis for such decision, this why he never clarified the reasoning behind. Then, *AFTER* I reacted to his decision he grabbed that opportunity to say no, look, this _new_ thing Felipe is doing is the reason. Nice try. If the behavior in [1] is the reason, the solution is easy; I'll revert back to my old behavior where I explained everything in detail, and updated the commit messages if something wasn't clear. I would: 1. Make sure the regression is fixed Git v2.0 2. Send a clarified patch for the hg 3.0 compatibility 3. Look for other important patches that might be missing and provide all the details why they are important 4. Rebase and clean the rest of the patches to make sure nothing is missing This is what I was going to do anyway *BEFORE* you made that decision. And this commitment to quality is what I've been doing since day one. *YOU* changed that by throwing away all my hard work. If the issue was truly the behavior in [1], the outline above should get rid of the (fake) problem you mention. We make a compromise, you ignore this temporary bump (that *you* caused), and I go back to high quality standards (which I was already doing anyway before). The graduation process continues, and *IF* another instance like [1] comes (it won't), then the graduation process is canceled. Ignoring temporary set-backs, finding common ground, and making an agreement on future behavior is in the best interest of our users. Will you do it? *1* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341 -- Felipe Contreras -- 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 0/4] remote-hg: more improvements
Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: ... I was originally led to believe that its code quality was good enough, and that was why I merged the bottom three patches of the series even down to 'next' in the first place. But after seeing the Of course response that led to [*1*], which made me recall many patch-review interactions with him, I have started to have doubts. This is bullshit, and a wrong direction fallacy. Event #1: Junio rejects the graduation http://article.gmane.org/gmane.comp.version-control.git/248263 Event #2: I give up improving remote helpers in git.git http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341 Junio is trying to make you believe that his decision (#1) was caused by something I did (#2). Don't fall into that trap, #2 happened *AFTER* #1, it can't possibly be the cause. I think you misunderstood. I never said that I do not want it to graduate up (out is an option) based on code quality. In fact, I do not think anybody discussed about code quality until this morning. But because I was asked, I thought about it, and then answered honestly. I do not know what a trap you perceive is about, and I am not interested in your responses. -- 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 abuses qt4-ssh-askpass
On Sat, May 10, 2014 at 10:41:28AM +0200, Chris “Kwpolska” Warrick wrote: when I’m using the HTTPS protocol to access repositories, a window from /usr/bin/qt4-ssh-askpass comes up. It asks for my “SSH pass phrase”, twice. Sadly, it’s wrong. The actual things it wants is the username in the first case, and the password used to access the remote repository (eg. my GitHub password) in the second question. This is a bug, and very misleading behavior. If you have GIT_ASKPASS or SSH_ASKPASS set and git needs to prompt for a username or password, it will call that program rather than prompting on the terminal. It does pass a meaningful label to the askpass program, but it sounds like your askpass program does not actually display it. E.g., try setting GIT_TRACE=1. I get: $ GIT_TRACE=1 SSH_ASKPASS=ssh-askpass-fullscreen git fetch trace: built-in: git 'fetch' trace: run_command: 'git-remote-https' 'origin' 'https://github.com/peff/test' trace: run_command: 'ssh-askpass-fullscreen' 'Username for '\''https://github.com'\'': ' trace: run_command: 'ssh-askpass-fullscreen' 'Password for '\''https://p...@github.com'\'': ' and the askpass program shows me those prompts. You may want to file a bug report with qt4-ssh-askpass, as most other askpass programs (including the original ssh-askpass that comes with ssh) respects the prompt arguments. That being said, we may be able to improve git, depending on what you actually wanted to happen. For example, I don't think there is a way to tell git even though I have SSH_ASKPASS set, still prompt me on the terminal. It's been generally assumed that you would only set that variable if you preferred an external prompt to a terminal prompt. You may also want to look into git's credential support (see git help credential), which can let you store the username and password in secure system-provided storage (however from the qt4 above, I guess you might be using KDE, and I do not know of a KDE Wallet helper; there is one for GNOME keyring). -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: What's cooking in git.git (Apr 2014, #08; Fri, 25)
On Fri, May 09, 2014 at 06:53:32PM +0200, Michael Haggerty wrote:
On 04/26/2014 01:19 AM, Jeff King wrote:
On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
[...]
* fc/publish-vs-upstream (2014-04-21) 8 commits
- sha1_name: add support for @{publish} marks
- sha1_name: simplify track finding
- sha1_name: cleanup interpret_branch_name()
- branch: display publish branch
- push: add --set-publish option
- branch: add --set-publish-to option
- Add concept of 'publish' branch
- t5516 (fetch-push): fix test restoration
Add branch@{publish}; it seems that this is somewhat different from
Ram and Peff started working on. There were many discussion
messages going back and forth but it does not appear that the
design issues have been worked out among participants yet.
[...]
As for the patches themselves, I have not reviewed them carefully, and
would prefer not to. As I mentioned before, though, I would prefer the
short @{p} not be taken for @{publish} until it has proven itself.
Is it too late and/or impossible to think of a different name for either
push or publish so that their single-letter abbreviations don't
coincide?
I don't think it is too late, as nothing has even made it to master
(and even once shipped, we can add an alias with a different name,
advertise that, and use its shorthand).
However, I am not sure if that is a good approach. New terms might not
collide in single-letters, but their full names might also not be as
descriptive. We'd have to judge actual proposals to see.
In addition, there was a discussion about having pull as an opposite
of push (which would make it an alias for upstream), that would also
collide. So there is a potential third name to deal with.
-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] git-add--interactive: Preserve diff heading when splitting hunks
Jeff King p...@peff.net writes: One, there is a slightly funny artifact in that the hunk header comes from the top of the context line, and that top is a different position for each of the split hunks. So in a file like: header_A content header_B one two three four you might have a diff like: @@ ... @@ header_A header_B one two +new line 1 three +new line 2 four The hunk header for new line 1 is A, because B itself is part of the context. But the hunk header for new line 2, if it were an independent hunk, would be B. We print A because we copy it from the original hunk. It probably won't matter much in practice (and I can even see an argument that A is the right answer). I tend to agree with both points. And figuring out B here would be prohibitively difficult, I would think, as it would require applying the funcname rules internal to git-diff to a hunk that git-diff itself never actually sees. You can actually apply a split hunk being proposed to a temporary file and then ask git diff about it, so I do not think difficult is too much of an issue, but I doubt we would want to see header_B, exactly because when the user says Split this hunk, s/he is very well aware that the second one is artificial and was split from the original hunk whose header said header_A. Since the output from your patch is strictly better than what we saw before, I think there is no reason we cannot leave such an improvement to later (or never). Yes. -- 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-add--interactive: Preserve diff heading when splitting hunks
On Mon, May 12, 2014 at 02:07:15PM -0700, Junio C Hamano wrote: And figuring out B here would be prohibitively difficult, I would think, as it would require applying the funcname rules internal to git-diff to a hunk that git-diff itself never actually sees. You can actually apply a split hunk being proposed to a temporary file and then ask git diff about it, so I do not think difficult is too much of an issue, True, I didn't think of that. but I doubt we would want to see header_B, exactly because when the user says Split this hunk, s/he is very well aware that the second one is artificial and was split from the original hunk whose header said header_A. Right, that's along the lines of the you could make the argument I was thinking of. Since you are thinking it, too, I'm definitely in favor of stopping at Ævar's patch and seeing if anybody even notices or complains. Thanks. -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 0/4] remote-hg: more improvements
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: ... I was originally led to believe that its code quality was good enough, and that was why I merged the bottom three patches of the series even down to 'next' in the first place. But after seeing the Of course response that led to [*1*], which made me recall many patch-review interactions with him, I have started to have doubts. This is bullshit, and a wrong direction fallacy. Event #1: Junio rejects the graduation http://article.gmane.org/gmane.comp.version-control.git/248263 Event #2: I give up improving remote helpers in git.git http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341 Junio is trying to make you believe that his decision (#1) was caused by something I did (#2). Don't fall into that trap, #2 happened *AFTER* #1, it can't possibly be the cause. I think you misunderstood. I never said that I do not want it to graduate up (out is an option) based on code quality. Fair enough, that was my understanding up until today. But because I was asked, I thought about it, and then answered honestly. I do not know what a trap you perceive is about, and I am not interested in your responses. Philippe Vaucher didn't ask about quality, he asked about moving out of contrib. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] git-show: fix 'git show -s' to not add extra terminator after merge commit
When git show -s is called for merge commit it prints extra newline
after any merge commit and the next one. This looks especially ugly for
--oneline and other single-line formats. Looks very much like a bug.
The code in question exists since commit 3969cf7db1. Probably the
correct condition should be in fact
opt-output_format DIFF_FORMAT_DIFFSTAT.
Test t7007-show.sh is also modified to cover this case.
---
combine-diff.c | 3 ++-
t/t7007-show.sh | 8 ++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 3b92c448..ff6ceaf 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1331,7 +1331,8 @@ void diff_tree_combined(const unsigned char *sha1,
if (show_log_first i == 0) {
show_log(rev);
- if (rev-verbose_header opt-output_format)
+ if (rev-verbose_header opt-output_format
+ opt-output_format != DIFF_FORMAT_NO_OUTPUT)
printf(%s%c, diff_line_prefix(opt),
opt-line_termination);
}
diff --git a/t/t7007-show.sh b/t/t7007-show.sh
index e41fa00..de22812 100755
--- a/t/t7007-show.sh
+++ b/t/t7007-show.sh
@@ -25,6 +25,7 @@ test_expect_success 'set up a bit of history' '
git checkout -b side HEAD^^
test_commit side2
test_commit side3
+ test_merge merge main3
'
test_expect_success 'showing two commits' '
@@ -109,8 +110,11 @@ test_expect_success 'showing range' '
'
test_expect_success '-s suppresses diff' '
- echo main3 expect
- git show -s --format=%s main3 actual
+ cat expect -\EOF
+ merge
+ main3
+ EOF
+ git show -s --format=%s merge main3 actual
test_cmp expect actual
'
--
1.8.5.2.421.g4cdf8d0
--
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/2] fix 'git show -s' to not add extra terminator after merge commit
* fix the CC issues * add fixes for existing tests Max Kirillov (2): git-show: fix 'git show -s' to not add extra terminator after merge commit t: git-show: adapt tests to fixed 'git show' combine-diff.c| 3 ++- t/t1507-rev-parse-upstream.sh | 2 +- t/t7007-show.sh | 8 ++-- t/t7600-merge.sh | 11 +-- 4 files changed, 14 insertions(+), 10 deletions(-) -- 1.8.5.2.421.g4cdf8d0 -- 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/2] t: git-show: adapt tests to fixed 'git show'
'git show' used to print extra newline after merge commit, and it was
recorded so into the test reference data. Now when the behavior is
fixed, the tests should be updated.
Note that '--format=%s' works like '--pretty=tformat:%s'. This
is why non-merging cases pass, like t3505-cherry-pick-empty.sh
for example, though they look very similarly.
---
t/t1507-rev-parse-upstream.sh | 2 +-
t/t7600-merge.sh | 11 +--
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/t/t1507-rev-parse-upstream.sh b/t/t1507-rev-parse-upstream.sh
index 2a19e79..672280b 100755
--- a/t/t1507-rev-parse-upstream.sh
+++ b/t/t1507-rev-parse-upstream.sh
@@ -100,7 +100,7 @@ test_expect_success 'merge my-side@{u} records the correct
name' '
git branch -D new ;# can fail but is ok
git branch -t new my-side@{u}
git merge -s ours new@{u}
- git show -s --pretty=format:%s actual
+ git show -s --pretty=tformat:%s actual
echo Merge remote-tracking branch ${sq}origin/side${sq} expect
test_cmp expect actual
)
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 10aa028..b164621 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -57,11 +57,10 @@ create_merge_msgs () {
git log --no-merges ^HEAD c2 c3
} squash.1-5-9
: msg.nologff
- echo msg.nolognoff
+ : msg.nolognoff
{
echo * tag 'c3':
- echo commit 3
- echo
+ echo commit 3
} msg.log
}
@@ -71,7 +70,7 @@ verify_merge () {
git diff --exit-code
if test -n $3
then
- git show -s --pretty=format:%s HEAD msg.act
+ git show -s --pretty=tformat:%s HEAD msg.act
test_cmp $3 msg.act
fi
}
@@ -620,10 +619,10 @@ test_expect_success 'merge early part of c2' '
git tag c6
git branch -f c5-branch c5
git merge c5-branch~1
- git show -s --pretty=format:%s HEAD actual.branch
+ git show -s --pretty=tformat:%s HEAD actual.branch
git reset --keep HEAD^
git merge c5~1
- git show -s --pretty=format:%s HEAD actual.tag
+ git show -s --pretty=tformat:%s HEAD actual.tag
test_cmp expected.branch actual.branch
test_cmp expected.tag actual.tag
'
--
1.8.5.2.421.g4cdf8d0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] fix 'git show -s' to not add extra terminator after merge commit
Since v1: * add Signed-off-by * remove notion about '--format=%s' - found it in the documentation Since RFC: * fix the CC issues * add fixes for existing tests Max Kirillov (2): git-show: fix 'git show -s' to not add extra terminator after merge commit t: git-show: adapt tests to fixed 'git show' combine-diff.c| 3 ++- t/t1507-rev-parse-upstream.sh | 2 +- t/t7007-show.sh | 8 ++-- t/t7600-merge.sh | 11 +-- 4 files changed, 14 insertions(+), 10 deletions(-) -- 1.8.5.2.421.g4cdf8d0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] git-show: fix 'git show -s' to not add extra terminator after merge commit
When git show -s is called for merge commit it prints extra newline
after any merge commit and the next one. This looks especially ugly for
--oneline and other single-line formats. Looks very much like a bug.
The code in question exists since commit 3969cf7db1. Probably the
correct condition should be in fact
opt-output_format DIFF_FORMAT_DIFFSTAT.
Test t7007-show.sh is also modified to cover this case.
Signed-off-by: Max Kirillov m...@max630.net
---
combine-diff.c | 3 ++-
t/t7007-show.sh | 8 ++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 3b92c448..ff6ceaf 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1331,7 +1331,8 @@ void diff_tree_combined(const unsigned char *sha1,
if (show_log_first i == 0) {
show_log(rev);
- if (rev-verbose_header opt-output_format)
+ if (rev-verbose_header opt-output_format
+ opt-output_format != DIFF_FORMAT_NO_OUTPUT)
printf(%s%c, diff_line_prefix(opt),
opt-line_termination);
}
diff --git a/t/t7007-show.sh b/t/t7007-show.sh
index e41fa00..de22812 100755
--- a/t/t7007-show.sh
+++ b/t/t7007-show.sh
@@ -25,6 +25,7 @@ test_expect_success 'set up a bit of history' '
git checkout -b side HEAD^^
test_commit side2
test_commit side3
+ test_merge merge main3
'
test_expect_success 'showing two commits' '
@@ -109,8 +110,11 @@ test_expect_success 'showing range' '
'
test_expect_success '-s suppresses diff' '
- echo main3 expect
- git show -s --format=%s main3 actual
+ cat expect -\EOF
+ merge
+ main3
+ EOF
+ git show -s --format=%s merge main3 actual
test_cmp expect actual
'
--
1.8.5.2.421.g4cdf8d0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] t: git-show: adapt tests to fixed 'git show'
'git show' used to print extra newline after merge commit, and it was
recorded so into the test reference data. Now when the behavior is
fixed, the tests should be updated.
Signed-off-by: Max Kirillov m...@max630.net
---
t/t1507-rev-parse-upstream.sh | 2 +-
t/t7600-merge.sh | 11 +--
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/t/t1507-rev-parse-upstream.sh b/t/t1507-rev-parse-upstream.sh
index 2a19e79..672280b 100755
--- a/t/t1507-rev-parse-upstream.sh
+++ b/t/t1507-rev-parse-upstream.sh
@@ -100,7 +100,7 @@ test_expect_success 'merge my-side@{u} records the correct
name' '
git branch -D new ;# can fail but is ok
git branch -t new my-side@{u}
git merge -s ours new@{u}
- git show -s --pretty=format:%s actual
+ git show -s --pretty=tformat:%s actual
echo Merge remote-tracking branch ${sq}origin/side${sq} expect
test_cmp expect actual
)
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 10aa028..b164621 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -57,11 +57,10 @@ create_merge_msgs () {
git log --no-merges ^HEAD c2 c3
} squash.1-5-9
: msg.nologff
- echo msg.nolognoff
+ : msg.nolognoff
{
echo * tag 'c3':
- echo commit 3
- echo
+ echo commit 3
} msg.log
}
@@ -71,7 +70,7 @@ verify_merge () {
git diff --exit-code
if test -n $3
then
- git show -s --pretty=format:%s HEAD msg.act
+ git show -s --pretty=tformat:%s HEAD msg.act
test_cmp $3 msg.act
fi
}
@@ -620,10 +619,10 @@ test_expect_success 'merge early part of c2' '
git tag c6
git branch -f c5-branch c5
git merge c5-branch~1
- git show -s --pretty=format:%s HEAD actual.branch
+ git show -s --pretty=tformat:%s HEAD actual.branch
git reset --keep HEAD^
git merge c5~1
- git show -s --pretty=format:%s HEAD actual.tag
+ git show -s --pretty=tformat:%s HEAD actual.tag
test_cmp expected.branch actual.branch
test_cmp expected.tag actual.tag
'
--
1.8.5.2.421.g4cdf8d0
--
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: [BUGFIX/RFC] git-show: fix 'git show -s' to not add extra terminator after merge commit
On Mon, May 12, 2014 at 09:59:39AM -0700, Junio C Hamano wrote: A good way to double-check may be to see the fixes to the tests to correct their wrong expectations, and if the updated expectation is sensible. I have sent the fixes to tests. To me they look sensible. Also fixed the things you pointed out. -- Max -- 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
[BUG] git-gui regression in 2.0rcX within submodule
In 2.0rc2, git-gui is unable to work inside submodules, where 1.9.2 did not show such a problem: yann@home:~$ cd /tmp/ yann@home:tmp$ mkdir foo yann@home:tmp$ cd foo/ yann@home:foo$ git init Initialized empty Git repository in /tmp/foo/.git/ yann@home:foo (master)$ git submodule add git://git.debian.org/git/collab-maint/tulip.git debian Cloning into 'debian'... remote: Counting objects: 317, done. remote: Compressing objects: 100% (199/199), done. remote: Total 317 (delta 184), reused 166 (delta 95) Receiving objects: 100% (317/317), 73.81 KiB | 0 bytes/s, done. Resolving deltas: 100% (184/184), done. Checking connectivity... done. yann@home:foo (master)$ git status On branch master Initial commit Changes to be committed: (use git rm --cached file... to unstage) new file: .gitmodules new file: debian yann@home:foo (master)$ (cd debian/ git gui) [errors out after showing the following error dialog] | No working directory ../../../debian: | | couldn't change working directory | to ../../../debian: no such file or | directory strace shows the failing chdir call is from git-gui itself, after getcwd() told him that it is in the dir that is indeed the workdir already. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag
cmd_add_commit() is passed FETCH_HEAD by cmd_add_repository, which is then rev-parsed into an object ID. However, if the user is fetching a tag rather than a branch HEAD, such as by executing: $ git subtree add -P oldGit https://github.com/git/git.git tags/v1.8.0 The object ID is a tag and is never peeled, and the git commit-tree call (line 561) slaps us in the face because it doesn't handle tag IDs. Because peeling a committish ID doesn't do anything if it's already a commit, fix by peeling[1] the object ID before assigning it to $rev, as per the patch. [*1*]: Via peel_committish(), from git:git-sh-setup.sh, pre-existing dependency of git-subtree. Reported-by: Kevin Cagle kca...@micron.com Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: James Denholm nod.h...@gmail.com --- I felt that defining revp would be a little more self-documenting than using $rev^0. contrib/subtree/git-subtree.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index dc59a91..eefd720 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -557,8 +557,9 @@ cmd_add_commit() commit=$(add_squashed_msg $rev $dir | git commit-tree $tree $headp -p $rev) || exit $? else + revp=$(peel_committish $rev) commit=$(add_msg $dir $headrev $rev | -git commit-tree $tree $headp -p $rev) || exit $? +git commit-tree $tree $headp -p $revp) || exit $? fi git reset $commit || exit $? -- 1.9.2 -- 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 v2 1/2] git-show: fix 'git show -s' to not add extra terminator after merge commit
Am 5/13/2014 1:10, schrieb Max Kirillov: --- a/t/t7007-show.sh +++ b/t/t7007-show.sh @@ -25,6 +25,7 @@ test_expect_success 'set up a bit of history' ' git checkout -b side HEAD^^ test_commit side2 test_commit side3 + test_merge merge main3 ' Broken -chain. -- Hannes -- 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
