Re: [GSoC14][RFC] Is there any interest in adding a port of checkpatch.pl to contrib/?
On Tue, Mar 18, 2014 at 8:29 PM, Junio C Hamano gits...@pobox.com wrote: I've never said any such thing. I only said I am not enthused against a proposal to add a build target that runs checkpatch or equivalent over *all* existing code, which will invite needless churn (read again the part of the message you quoted before I say I am not enthused). It is a totally separate issue for submitters to make sure they do not introduce *new* problems, and use of checkpatch --no-tree could be one way to do so. Sorry for misrepresenting your opinion. My summarization algorithm sometimes is _very_ lossy :) -- 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
[GSoC14][RFC] Is there any interest in adding a port of checkpatch.pl to contrib/?
It seems to me that the topic of adding the checkpatch.pl script to Git's source tree has cropped up several times in the past, as recently as a couple of days ago: $gmane/243607. It should be noted that its usage for its sake has been discouraged by Junio Hamano in $gmane/205998. Also, its use is somewhat controversial and has led to flames and even a public fork. Despite this, I think that git might benefit from a port of checkpatch.pl. In fact, even Junio had admitted to use part of its features later in $gmane/205998. We could simply use linux's script/checkpatch.pl, but I think a port is needed for these reasons: 1. Git style guidelines are somewhat different and less strict than their Linux equivalents. 2. Several patch threads bounce back and forth because of style fixes. A checkpatch script added as a hook could help reduce these and use more efficiently our time. 3. As far as I can tell, checkpatch needs to be run from the root folder of a linux repository clone. Cloning several hundred MBs for a single perl script looks a little foolish to me. So, is there any interest in adding a port of checkpatch.pl to contrib/? I might work on this as part of GSoC. I still haven't submitted my application about git bisect (life got in the way!), but Michael Heggarty remarked in $gmane/242703 that my original idea had too little meat in it to constitute a good GSoC proposal. Cheers, Jacopo Notarstefano -- 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: An idea for git bisect and a GSoC enquiry
On Mon, Mar 3, 2014 at 7:34 PM, Junio C Hamano gits...@pobox.com wrote: I think you fundamentally cannot use two labels that are merely distinct and bisect correctly. You need to know which ones (i.e. good) are to be excluded and the other (i.e. bad) are to be included when computing the remaining to be tested set of commits. Good point. Yes, this isn't viable. -- 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: fnmatch vs regex
On Wed, Mar 5, 2014 at 8:55 PM, Vincenzo di Cicco enzodici...@gmail.com wrote: Hi there, I'm NaN. Recently I enrolled to this mailing list thanks to the GSoC. I've looked the Ideas Page but -unfortunately- some projects are very difficult for me. Hi Vincenzo! I also got interested in contributing to Git because of GSoC. I encourage you to try doing a microproject: the coding part can be *really* trivial. For example, mine just involved deleting lines (after, of course, explaining why they weren't needed anymore). If you are having trouble following the instructions in Documentation/SubmittingPatches I recommend this video: https://www.youtube.com/watch?v=LLBrBBImJt4. -- 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] branch.c: delete size check of newly tracked branch names
Since commit 6f084a56 the length of a newly tracked branch name is limited to 1009 = 1024 - 7 - 7 - 1 characters, a bound derived by having to store this name in a char[1024] with two strings of length at most 7 and a '\0' character. This is no longer necessary as of commit a9f2c136, which uses a strbuf (documented in Documentation/technical/api-strbuf.txt) to store this value. Remove this unneeded check and thus allow for branch names longer than 1009 characters. Signed-off-by: Jacopo Notarstefano jacopo.notarstef...@gmail.com --- branch.c | 4 1 file changed, 4 deletions(-) diff --git a/branch.c b/branch.c index 723a36b..05feaff 100644 --- a/branch.c +++ b/branch.c @@ -114,10 +114,6 @@ static int setup_tracking(const char *new_ref, const char *orig_ref, struct tracking tracking; int config_flags = quiet ? 0 : BRANCH_CONFIG_VERBOSE; - if (strlen(new_ref) 1024 - 7 - 7 - 1) - return error(_(Tracking not set up: name too long: %s), - new_ref); - memset(tracking, 0, sizeof(tracking)); tracking.spec.dst = (char *)orig_ref; if (for_each_remote(find_tracked_branch, tracking)) -- 1.9.0.138.g2de3478 -- 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: [BUG] Halt during fetch on MacOS
On Sun, Mar 2, 2014 at 3:02 AM, Kyle J. McKay mack...@gmail.com wrote: I can't reproduce, mostly, on Mac OS X 10.5.8 or 10.6.8. What I mean by mostly is that the very first time I ran the test script I got approximately 36 of these errors: fatal: unable to access 'https://android.googlesource.com/platform/external/tinyxml2/': Unknown SSL protocol error in connection to android.googlesource.com:443 The rest of the fetches completed. That was with Git 1.8.5.1. However, I was never able to reproduce those errors again. All the subsequent runs completed all fetches successfully using that same Git version so I also tried Git 1.8.5.2, 1.8.5.5 and Git 1.7.6.1 on the original and another machine. With Git 1.9.0.138.g2de3478 (latest build from source) on Mac OS X 10.9.2 I report similar results. A first run yielded several fatal: unable to access errors, while a second run yielded just one. -- 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] git-bisect.sh: fix a few style issues
Redirection operators should have a space before them, but not after them.
Signed-off-by: Jacopo Notarstefano jacopo.notarstef...@gmail.com
---
git-bisect.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 73b4c14..af4d04c 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -365,7 +365,7 @@ bisect_reset() {
}
case $# in
0) branch=$(cat $GIT_DIR/BISECT_START) ;;
- 1) git rev-parse --quiet --verify $1^{commit} /dev/null || {
+ 1) git rev-parse --quiet --verify $1^{commit} /dev/null || {
invalid=$1
die $(eval_gettext '\$invalid' is not a valid
commit)
}
@@ -458,13 +458,13 @@ exit code \$res from '\$command' is 0 or = 128 2
fi
# We have to use a subshell because bisect_state can exit.
- ( bisect_state $state $GIT_DIR/BISECT_RUN )
+ ( bisect_state $state $GIT_DIR/BISECT_RUN )
res=$?
cat $GIT_DIR/BISECT_RUN
if sane_grep first bad commit could be any of
$GIT_DIR/BISECT_RUN \
-/dev/null
+ /dev/null
then
gettextln bisect run cannot continue any more 2
exit $res
@@ -477,7 +477,7 @@ exit code \$res from '\$command' is 0 or = 128 2
exit $res
fi
- if sane_grep is the first bad commit $GIT_DIR/BISECT_RUN
/dev/null
+ if sane_grep is the first bad commit $GIT_DIR/BISECT_RUN
/dev/null
then
gettextln bisect run success
exit 0;
--
1.9.0.1.g641f09f
--
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] branch.c: change install_branch_config() to use skip_prefix()
The part about this being a GSoC microproject should go below the
three dashes, since it's not information that needs to
be recorded in the codebase.
On Sun, Mar 2, 2014 at 12:52 PM, Guanglin Xu mzguang...@gmail.com wrote:
GSoC2014 Microproject: according to the idea#2 for microprojects, change
install_branch_config() to use skip_prefix() and make it conform to the usage
of previous starts_with().
Signed-off-by: Guanglin Xu mzguang...@gmail.com
---
branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/branch.c b/branch.c
index 723a36b..ca4e824 100644
--- a/branch.c
+++ b/branch.c
@@ -50,7 +50,7 @@ static int should_setup_rebase(const char *origin)
void install_branch_config(int flag, const char *local, const char *origin,
const char *remote)
{
const char *shortname = remote + 11;
- int remote_is_branch = starts_with(remote, refs/heads/);
+ int remote_is_branch = (NULL != skip_prefix(remote ,refs/heads/));
struct strbuf key = STRBUF_INIT;
int rebasing = should_setup_rebase(origin);
--
1.9.0
Hi,
I am Guanglin Xu. I plan to apply for GSoC 2014.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: An idea for git bisect and a GSoC enquiry
I am not sure I understand what you are trying to say. Are you saying that we should stick to good/bad and allow the users use nothing else, because allowing fixed will be confusing? No! Pretty much the opposite of that. My idea (the mark subcommand) is to let people define their own pairs of labels to represent two opposite states of a commit. My point was that, if people choose pairs of words that are not opposites (such as good and fixed) then it's their error, not something that git should attempt to fix or detect. For a young tool or a feature, catering to perfect human perfectly is a good first goal---if it does not work well even for error-free human input, it would be worthless. However, its second goal after achieving that first goal ought to be to help imperfect humans. Loved this. Why do you think there is nothing it can do to help the user? Upon seeing bad, the tool should at least be able to say Excuse me, but you earlier said 'fixed' for one of the commits, so your vocabulary now is limited to 'fixed' and 'broken'. I think it also should be able to add Did you mean to say 'broken'?, or even I'd assume that you meant 'broken' and will continue. I haven't said this, but this is pretty much what I had in mind. Suppose a user wants to find a bugfix between HEAD and HEAD~10, this is what she would do: $ git bisect start $ git bisect mark working HEAD $ git bisect mark broken HEAD~10 [git will now start bisecting as usual. Suppose that she is now at HEAD~5] $ git bisect mark bad - Error: unrecognized label 'bad'. You previously used 'working' and 'fixed' to describe commits in this git bisect session. Please mark commits with one of these labels. I suppose that we could cater a little better to imperfect humans if we had two predefined parallel list of antonyms in which to search for given labels and infer whether they are positive or negative labels, but this is beyond the scope of my proposal. I have always wondered if we can introduce a value neutral synonyms to good and bad. For a bisect session, we care only about two states: still-X and no-longer-X where X may be 'working' for the normal bug-hunting bisection and 'broken' for the fix-hunting one. $ git bisect still-working v1.6.0 $ git bisect no-longer-working v1.8.0 would be a way to find a bug that was introduced during v1.6.0..v1.8.0, while $ git bisect still-broken v1.6.0 $ git bisect no-longer-broken v1.8.0 would be a way to find a fix in the same range. The lowest-level bisection machinery could just _ignore_ anything after still/no-longer and do its thing, [...] This is remarkably similar to my proposal. Using mark, these would be: $ git bisect mark working v1.6.0 $ git bisect mark not-working v1.8.0 and $ git bisect mark broken v1.6.0 $ git bisect mark not-broken v1.8.0 while the end-user facing layer could enforce, once one commit is marked as still-X (or no-longer-X), that nothing other than the same X is used, and issue an error message, perhaps like this: $ git bisect still-broken v1.6.0 $ git bisect still-working v1.8.0 error: You earlier marked v1.6.0 as still-broken and error: are hunting for the first commit that can be marked error: as no-longer-broken. Say either still-broken or error: no-longer-broken, not still-working. and that can be done without having to understand that broken is the opposite of working (of course if we understood that, we could even offer to guess that the user meant no-longer-broken by still-working, but we do not want to go there). Here my proposal differs in that I have no way of knowing which label is good and which label is bad: I blindly accept two distinct labels and bisect with those. I gave an example of this behaviour above. -- 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: An idea for git bisect and a GSoC enquiry
Mh. Haven't thought of that. I have no experience with TK, so I'm having trouble digging up where the good and bad labels in the GUI are generated. I guess that a solution might involve writing a temporary file in $GIT_DIR called something like BISECT_LABELS in which the chosen labels are listed and reused across all tools that require them. (Sorry for sending this email twice, I thought I had sent it to the list as well!) On Wed, Feb 26, 2014 at 8:58 PM, Junio C Hamano gits...@pobox.com wrote: Jacopo Notarstefano jacopo.notarstef...@gmail.com writes: Does this make sense? Did I overlook some details? How does this solve the labels shown in git bisect visualize? -- 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: An idea for git bisect and a GSoC enquiry
On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty mhag...@alum.mit.edu wrote: I don't understand the benefit of adding a new command mark rather than continuing to use good, bad, plus new commands unfixed and fixed. Does this solve any problems? As Matthieu Moy remarked in a previous email, the main reason is extensibility: I prefer having a single command to assign new descriptive labels instead of having to patch git-bisect.sh to create new labels like fixed, unfixed, fast, slow... What happens if the user mixes, say, good and fixed in a single bisect session? I don't think that's an issue. If the user uses the label fixed instead of bad she will have a hard time remembering to use it every time she needs it, and maybe the output of git bisect will look very confusing, but what can git do? This is a semantic user input error, not a syntax one. I think it would be more convenient if git bisect would autodetect whether the history went from good to bad or vice versa. The algorithm could be: 1. Wait until the user has marked one commit bad and one commit good. 2. If a good commit is an ancestor of a bad one, then git bisect should announce I will now look for the first bad commit. If reversed, then announce I will now look for the first good commit. If neither commit is an ancestor of the other, then explain the situation and ask the user to run git bisect find-first-bad or git bisect find-first-good or to mark another commit bad or good. 3. If the user marks another commit, go back to step 2, also doing a consistency check to make sure that all of the ancestry relationships go in a consistent direction. 4. After the direction is clear, the old bisect algorithm can be used (though taking account of the direction). Obviously a lot of the output would have to be adjusted, as would the way that a bisect is visualized. I can't think of any fundamental problems with a scheme like this, and I think it would be easier to use than the unfixed/fixed scheme. But that is only my opinion; other opinions are undoubtedly available :-) I like this idea! It also looks fun to implement. A minor difference is that I'd rather die with an error on point 2) if there's no ancestorship relation between the two commits; if the user is asking for such a thing then she has a fundamental misconception of the state of her repository. By the way, although git bisect fixed/unfixed would be a very useful improvement, and has gone unimplemented for a lamentably long time, my personal feeling is that it has too meat in it to constitute a GSoC project by itself. Oh! Then in fact, as Christian Couder said, this project shouldn't be marked as easy. (Sorry for sending this email twice! I thought I had sent it to the list as well.) On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty mhag...@alum.mit.edu wrote: On 02/26/2014 09:28 AM, Jacopo Notarstefano wrote: my name is Jacopo, a student developer from Italy, and I'm interested in applying to this years' Google Summer of Code. I set my eyes on the project called git-bisect improvements, in particular the subtask about swapping the good and bad labels when looking for a bug-fixing release. Hello and welcome! I have a very simple proposal for that: add a new mark subcommand. Here is an example of how it should work: 1) A developer wants to find in which commit a past regression was fixed. She start bisecting as usual with git bisect start. 2) The current HEAD has the bugfix, so she marks it as fixed with git bisect mark fixed. 3) She knows that HEAD~100 had the regression, so she marks it as unfixed with git bisect mark unfixed. 4) Now that git knows what the two labels are, it starts bisecting as usual. For compatibility with already written scripts, git bisect good and git bisect bad will alias to git bisect mark good and git bisect mark bad respectively. Does this make sense? Did I overlook some details? I don't understand the benefit of adding a new command mark rather than continuing to use good, bad, plus new commands unfixed and fixed. Does this solve any problems? What happens if the user mixes, say, good and fixed in a single bisect session? I think it would be more convenient if git bisect would autodetect whether the history went from good to bad or vice versa. The algorithm could be: 1. Wait until the user has marked one commit bad and one commit good. 2. If a good commit is an ancestor of a bad one, then git bisect should announce I will now look for the first bad commit. If reversed, then announce I will now look for the first good commit. If neither commit is an ancestor of the other, then explain the situation and ask the user to run git bisect find-first-bad or git bisect find-first-good or to mark another commit bad or good. 3. If the user marks another commit, go back to step 2, also doing a consistency check to make sure that all of the ancestry relationships go
Re: An idea for git bisect and a GSoC enquiry
This email was sent privately by Michael to me as a result of my previous error. I'm quoting it in its entirety so that he doesn't have to submit it twice. On Thu, Feb 27, 2014 at 8:32 PM, Michael Haggerty mhag...@alum.mit.edu wrote: Please forgive my typos and brevity; this was typed on a phone. Michael On February 27, 2014 5:16:40 PM CET, Jacopo Notarstefano jacopo.notarstef...@gmail.com wrote: On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty mhag...@alum.mit.edu wrote: What happens if the user mixes, say, good and fixed in a single bisect session? I don't think that's an issue. If the user uses the label fixed instead of bad she will have a hard time remembering to use it every time she needs it, and maybe the output of git bisect will look very confusing, but what can git do? This is a semantic user input error, not a syntax one. - git could emit an error message and refuse to continue - git could interpret the command one way or the other, with or without a warning By my count that gives at least five possibilities. The feature cannot be implemented without choosing one. I think it would be more convenient if git bisect would autodetect whether the history went from good to bad or vice versa. The algorithm could be: 1. Wait until the user has marked one commit bad and one commit good. 2. If a good commit is an ancestor of a bad one, then git bisect should announce I will now look for the first bad commit. If reversed, then announce I will now look for the first good commit. If neither commit is an ancestor of the other, then explain the situation and ask the user to run git bisect find-first-bad or git bisect find-first-good or to mark another commit bad or good. 3. If the user marks another commit, go back to step 2, also doing a consistency check to make sure that all of the ancestry relationships go in a consistent direction. 4. After the direction is clear, the old bisect algorithm can be used (though taking account of the direction). Obviously a lot of the output would have to be adjusted, as would the way that a bisect is visualized. I can't think of any fundamental problems with a scheme like this, and I think it would be easier to use than the unfixed/fixed scheme. But that is only my opinion; other opinions are undoubtedly available :-) I like this idea! It also looks fun to implement. A minor difference is that I'd rather die with an error on point 2) if there's no ancestorship relation between the two commits; if the user is asking for such a thing then she has a fundamental misconception of the state of her repository. That is not correct. If there is a bug on one branch but not another, it is legitimate to ask when the bug was introduced, and git bisect can indeed handle this case today (think about how this could work, and try it!) By the way, although git bisect fixed/unfixed would be a very useful improvement, and has gone unimplemented for a lamentably long time, my personal feeling is that it has too meat in it to constitute a GSoC project by itself. Oh! Then in fact, as Christian Couder said, this project shouldn't be marked as easy. Sorry for the typo; I meant to say too LITTLE meat. -- Michael Haggerty mhag...@alum.mit.edu -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: An idea for git bisect and a GSoC enquiry
- git could emit an error message and refuse to continue - git could interpret the command one way or the other, with or without a warning By my count that gives at least five possibilities. The feature cannot be implemented without choosing one. Let me explain what I meant with an example. 1) The user starts bisecting with bisect start. 2) The user marks HEAD as good with git bisect mark good. 3) The user then marks HEAD~10 as fixed with git bisect mark fixed. 4) Git will then continue bisecting as usual with the labels good and fixed instead of bad and good respectively. This is very confusing, but is a result of a user semantic error, so no warning is emitted. After all, this might have been what the user wanted. That is not correct. If there is a bug on one branch but not another, it is legitimate to ask when the bug was introduced, and git bisect can indeed handle this case today (think about how this could work, and try it!) Interesting. I did not know that. Yes, I see how that might pan out, and why my idea is worse. Sorry for the typo; I meant to say too LITTLE meat. Ok. Not a big issue for me: I might squash another project together in my proposal. I've already seen one that piqued my interest: Unifying git branch -l, git tag -l, and git for-each-ref. (Sorry for sending this email twice! I thought I had sent it to the list as well.) On Thu, Feb 27, 2014 at 8:32 PM, Michael Haggerty mhag...@alum.mit.edu wrote: Please forgive my typos and brevity; this was typed on a phone. Michael On February 27, 2014 5:16:40 PM CET, Jacopo Notarstefano jacopo.notarstef...@gmail.com wrote: On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty mhag...@alum.mit.edu wrote: What happens if the user mixes, say, good and fixed in a single bisect session? I don't think that's an issue. If the user uses the label fixed instead of bad she will have a hard time remembering to use it every time she needs it, and maybe the output of git bisect will look very confusing, but what can git do? This is a semantic user input error, not a syntax one. - git could emit an error message and refuse to continue - git could interpret the command one way or the other, with or without a warning By my count that gives at least five possibilities. The feature cannot be implemented without choosing one. I think it would be more convenient if git bisect would autodetect whether the history went from good to bad or vice versa. The algorithm could be: 1. Wait until the user has marked one commit bad and one commit good. 2. If a good commit is an ancestor of a bad one, then git bisect should announce I will now look for the first bad commit. If reversed, then announce I will now look for the first good commit. If neither commit is an ancestor of the other, then explain the situation and ask the user to run git bisect find-first-bad or git bisect find-first-good or to mark another commit bad or good. 3. If the user marks another commit, go back to step 2, also doing a consistency check to make sure that all of the ancestry relationships go in a consistent direction. 4. After the direction is clear, the old bisect algorithm can be used (though taking account of the direction). Obviously a lot of the output would have to be adjusted, as would the way that a bisect is visualized. I can't think of any fundamental problems with a scheme like this, and I think it would be easier to use than the unfixed/fixed scheme. But that is only my opinion; other opinions are undoubtedly available :-) I like this idea! It also looks fun to implement. A minor difference is that I'd rather die with an error on point 2) if there's no ancestorship relation between the two commits; if the user is asking for such a thing then she has a fundamental misconception of the state of her repository. That is not correct. If there is a bug on one branch but not another, it is legitimate to ask when the bug was introduced, and git bisect can indeed handle this case today (think about how this could work, and try it!) By the way, although git bisect fixed/unfixed would be a very useful improvement, and has gone unimplemented for a lamentably long time, my personal feeling is that it has too meat in it to constitute a GSoC project by itself. Oh! Then in fact, as Christian Couder said, this project shouldn't be marked as easy. Sorry for the typo; I meant to say too LITTLE meat. -- Michael Haggerty mhag...@alum.mit.edu -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] branch.c: delete size check of newly tracked branch names
Since commit 6f084a56 the length of a newly tracked branch name was limited to 1019 = 1024 - 7 - 7 - 1 characters, a bound derived by having to store this name in a char[1024] called key with two strings of length at most 7 and a '\0' character. This was no longer necessary as of commit a9f2c136, which uses a strbuf (documented in Documentation/technical/api-strbuf.txt) to store this value. This patch removes this unneeded check and thus allows for branch names longer than 1019 characters. Signed-off-by: Jacopo Notarstefano jacopo.notarstef...@gmail.com --- Submitted as GSoC microproject #3. branch.c | 4 1 file changed, 4 deletions(-) diff --git a/branch.c b/branch.c index 723a36b..05feaff 100644 --- a/branch.c +++ b/branch.c @@ -114,10 +114,6 @@ static int setup_tracking(const char *new_ref, const char *orig_ref, struct tracking tracking; int config_flags = quiet ? 0 : BRANCH_CONFIG_VERBOSE; - if (strlen(new_ref) 1024 - 7 - 7 - 1) - return error(_(Tracking not set up: name too long: %s), - new_ref); - memset(tracking, 0, sizeof(tracking)); tracking.spec.dst = (char *)orig_ref; if (for_each_remote(find_tracked_branch, tracking)) -- 1.9.0.1.g5abca64 -- 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] branch.c: delete size check of newly tracked branch names
This patch removes this unneeded check and thus allows for branch names longer than 1019 characters. Ach! I amended the commit in my local history to read Remove this unneded check and thus allow for branch names longer than 1019 characters, but for some reason git format-patch -1 --signoff isn't reflecting this change. -- 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] branch.c: delete size check of newly tracked branch names
Nice. new_ref is passed in install_branch_config() in latest code. I guess you already made sure this function did not make any assumption about new_ref's length? The function install_branch_config uses the strbuf, as I wrote in the commit message. The contents of this buffer are then fed to git_config_set, which, after a few more function calls, parses the key with git_config_parse_key. This function does not rely on any assumptions (as far as I can tell!) on the name's length, and allocates enough space for it in https://github.com/git/git/blob/master/config.c#L1462. -- 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
An idea for git bisect and a GSoC enquiry
Hey everyone, my name is Jacopo, a student developer from Italy, and I'm interested in applying to this years' Google Summer of Code. I set my eyes on the project called git-bisect improvements, in particular the subtask about swapping the good and bad labels when looking for a bug-fixing release. I have a very simple proposal for that: add a new mark subcommand. Here is an example of how it should work: 1) A developer wants to find in which commit a past regression was fixed. She start bisecting as usual with git bisect start. 2) The current HEAD has the bugfix, so she marks it as fixed with git bisect mark fixed. 3) She knows that HEAD~100 had the regression, so she marks it as unfixed with git bisect mark unfixed. 4) Now that git knows what the two labels are, it starts bisecting as usual. For compatibility with already written scripts, git bisect good and git bisect bad will alias to git bisect mark good and git bisect mark bad respectively. Does this make sense? Did I overlook some details? There were already several proposals on this topic, among which those listed at https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed. I'm interested in contacting the prospective mentor, Christian Couder, to go over these. What's the proper way to ask for an introduction? I tried asking on IRC, but had no success. Cheers, Jacopo Notarstefano -- 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
