Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner
On 21 Mar 2016, at 11:19, Sidhant Sharma wrote: > Hi, > I updated the draft with links, ggit usage examples and some changes to the > timeline. I placed the links with reference here, but in the Google Doc, > they're > inline. > > Thanks and regards, > Sidhant Sharma > > --- > > Implement a beginner mode for Git. > > Abstract > > Git is a very powerful version control system, with an array of features > that lend the user with great capabilities. But it often so happens that some > beginners are overwhelmed by its complexity and are unable to fully understand > and thus, utilize Git. Moreover, often beginners do not fully understand > the command they are using and end up making destructive (and occasionally, > irreversible) changes to the repository. > > The beginner mode will assist such users in using Git by warning them > before making possibly destructive changes. It will also display tips and > short snippets of documentation for better understanding the Git model. > > Google summer of code Idea suggested here: > http://git.github.io/SoC-2016-Ideas/#git-beginner > > About Me > > Name : Sidhant Sharma > Email [1] : Sidhant.Sharma1208 gmail.com > Email [2] : Tigerkid001 gmail.com > College : Delhi Technological University > Studying : Software Engineering > IRC : tk001 (or _tk_) > Phone : 91-9990-606-081 > Country : India > Interests : Computers, Books, Photography > Github : Tigerkid001 > LinkedIn : https://in.linkedin.com/in/sidhantsharma12 > > Technical Experience > > Authored several Mozilla Firefox and Google Chrome extensions: > Firefox: Owl [1], Blink [2], Spoiler Jedi [3] > Chrome: Blink [4] > > Developed a robust Plugin framework for Android [5] for a startup. > Learning Linux kernel programming via the Eudyptula Challenge [6] > (currently level 6). > Developed natural language processor for sarcasm detection [7] in tweets. > Developed hand gesture detection module [8] as a college minor project. > Active Firefox Add-ons Editor at AMO [9]. > Currently working on a restaurant image classification project as second > college > minor project. > > Why I chose Git > > I have been using Git for about two years now, and it has become an > indispensable daily-use tool for me. Getting a chance to participate in GSoC > for the first time under Git is very exciting. It will give me an opportunity > to intimately know the system and a chance to help in making it better and > more > powerful. > > Proposal > > Ideas Page: Git Beginner [10] > > The following tasks summarize the project: > > Implement a wrapper around Git > > A wrapper is to be implemented around (currently called 'ggit'), which will > provide the following user interface: > `ggit ` > For example, `ggit add --all` > The wrapper will assess the arguments passed to it, and if they are detected > to > be safe, it will simply pass them through to 'git'. This approach is > favorable as the existing > users of git will not be affected by the wrapper. > > Warning for potentially destructive commands > > For every command that is entered, the wrapper will assess the subcommand and > its options. In that, it will first check if the subcommand (eg. add, > commit, rebase) is present in a list of predefined 'potentially destructive' > commands. This can be done by searching through a radix tree for the > subcommand. > If found, then the arguments to the subcommand will be checked for specific > flags. The graylisted flags for the destructive commands will be stored as an > array of regular expressions, and the current command's arguments will be > checked against them. If matches are found, a warning is displayed. 'ggit' > for the warning would be > "You are about to do X, which will permanently destroy Y. Are you sure you > wish > to continue? [Y/n] " > If the user enters Y[es], the command will be executed as is (by passing it > unaltered to git). In the case of Y[es], 'ggit' will also give tips for > undoing > the changes made by this command (by referring the user to correct commands > and > reflog), if the command can be undone. In case the command cannot be undone, > 'ggit' will display an additional line in the warning like > "The changes made by this command cannot be undone. Please proceed > cautiously". > In the case of n[o], 'ggit' will exit without executing the command. > > Currently, the list consists of commands like: > > $ git rebase > $ git reset --hard > $ git clean -f > $ git gc --prune=now --aggressive > $ git push -f > $ git push remote [+/:] > $ git branch -D > > The list will be updated after some more discussion on the list. > > Usage tips and documentation > > The wrapper will also be responsible for showing a short description of every > command that is entered through 'ggit'. This shall be done for every command > unconditionally. The description will be derived from the actual > documentation, > but will primarily aim to help the beginner understand the Git workflow and > the >
[PATCH v2] branch -D: allow - as abbreviation of '@{-1}'
Signed-off-by: Elena Petrashen
---
This micro-patch is meant to allow “-“ as a short-hand for
“@{-1} for branch -D (Cf. $gmane/230828):
* based on the discussion on the previous version of the patch,
added the advice on how to restore the deleted branch using
git branch deleted_name sha1 - to ensure safety and
newbie-friendliness
* git branch (-d | -D) is not supposed to accept any other
arguments except for branch name so it makes sense to replace
the argv[i] with @{-1}. We will not lose the opportunity to
use it for something different for other git branch uses if
we will decide it’s required.
* the small expand_dash_shortcut function can be reused to teach
git branch -m or other modifications to allow “-“ as a short-hand
for “@{-1} as well and possibly makes it easy to understand what’s
going on in the code
* if there’s no previous branch in the repository yet, a
specific warning message is given
Thank you! Looking forward to any feedback.
Documentation/git-branch.txt | 2 ++
builtin/branch.c | 26 ++
t/t3200-branch.sh| 16
3 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 4a7037f..42b96ed 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -65,6 +65,8 @@ to happen.
With a `-d` or `-D` option, `` will be deleted. You may
specify more than one branch for deletion. If the branch currently
has a reflog then the reflog will also be deleted.
+The "@{-N}" syntax for the N-th last branch deletes the specified branch.
+You may also specify - which is synonymous with "@{-1}".
Use `-r` together with `-d` to delete remote-tracking branches. Note, that it
only makes sense to delete remote-tracking branches if they no longer exist
diff --git a/builtin/branch.c b/builtin/branch.c
index 7b45b6b..8b33533 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -178,6 +178,15 @@ static void delete_branch_config(const char *branchname)
strbuf_release(&buf);
}
+static int expand_dash_shortcut(const char **argv, int dash_position)
+{
+ if (!strcmp(argv[dash_position], "-")){
+ argv[dash_position] = "@{-1}";
+ return 1;
+ }
+ return 0;
+}
+
static int delete_branches(int argc, const char **argv, int force, int kinds,
int quiet)
{
@@ -187,6 +196,7 @@ static int delete_branches(int argc, const char **argv, int
force, int kinds,
const char *fmt;
int i;
int ret = 0;
+ int dash_shortcut = 0;
int remote_branch = 0;
struct strbuf bname = STRBUF_INIT;
@@ -213,7 +223,8 @@ static int delete_branches(int argc, const char **argv, int
force, int kinds,
for (i = 0; i < argc; i++, strbuf_release(&bname)) {
const char *target;
int flags = 0;
-
+ if (expand_dash_shortcut (argv, i))
+ dash_shortcut = 1;
strbuf_branchname(&bname, argv[i]);
if (kinds == FILTER_REFS_BRANCHES && !strcmp(head, bname.buf)) {
error(_("Cannot delete the branch '%s' "
@@ -231,9 +242,12 @@ static int delete_branches(int argc, const char **argv,
int force, int kinds,
| RESOLVE_REF_ALLOW_BAD_NAME,
sha1, &flags);
if (!target) {
- error(remote_branch
- ? _("remote-tracking branch '%s' not found.")
- : _("branch '%s' not found."), bname.buf);
+ error(dash_shortcut
+ ? _("There is no previous branch that could be"
+ " referred to at the moment.")
+ : remote_branch
+ ? _("remote-tracking branch '%s' not
found.")
+ : _("branch '%s' not found."),
bname.buf);
ret = 1;
continue;
}
@@ -262,6 +276,10 @@ static int delete_branches(int argc, const char **argv,
int force, int kinds,
(flags & REF_ISBROKEN) ? "broken"
: (flags & REF_ISSYMREF) ? target
: find_unique_abbrev(sha1, DEFAULT_ABBREV));
+ if (dash_shortcut == 1)
+ printf( _("\nIf that happened by mistake, you
may want to restore"
+ " it with:\n\ngit branch %s %s\n"), bname.buf,
+ find_unique_abbrev(sha1, DEFAULT_ABBREV));
}
delete_branch_config(bname.buf);
}
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index a897248..535a507 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -403,6 +403
[PATCH v2] bisect--helper: convert a function in shell to C
Convert the code literally without changing its design even though it
seems that its obscure as to the use of comparing revision to different
bisect arguments which seems like a problem in shell because of the way
function arguments are handled.
The argument handling is kind of hard coded right now because it is not
really be meant to be used like this and this is just for testing
purposes whether this new method is as functional as its counter part.
The shell counter part of the method has been retained for historical
purposes.
Signed-off-by: Pranit Bauva
---
builtin/bisect--helper.c | 37 +
git-bisect.sh| 4 ++--
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
index 3324229..6cdae82 100644
--- a/builtin/bisect--helper.c
+++ b/builtin/bisect--helper.c
@@ -2,27 +2,64 @@
#include "cache.h"
#include "parse-options.h"
#include "bisect.h"
+#include "refs.h"
static const char * const git_bisect_helper_usage[] = {
N_("git bisect--helper --next-all [--no-checkout]"),
+ N_("git bisect--helper --check-term-format "),
NULL
};
+static int check_term_format(const char *term, const char *revision, int
flags);
+
+static int check_term_format(const char *term, const char *revision, int flag)
{
+ if (check_refname_format(term, flag))
+ die("'%s' is not a valid term", term);
+
+ if (!strcmp(term, "help") || !strcmp(term, "start") ||
+ !strcmp(term, "skip") || !strcmp(term, "next") ||
+ !strcmp(term, "reset") || !strcmp(term, "visualize") ||
+ !strcmp(term, "replay") || !strcmp(term, "log") ||
+ !strcmp(term, "run"))
+ die("can't use the builtin command '%s' as a term", term);
+
+ if (!strcmp(term, "bad") || !strcmp(term, "new"))
+ if(strcmp(revision, "bad"))
+ die("can't change the meaning of term '%s'", term);
+
+ if (!strcmp(term, "good") || !strcmp(term, "old"))
+ if (strcmp(revision, "good"))
+ die("can't change the meaning of term '%s'", term);
+
+ return 0;
+}
+
int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
{
int next_all = 0;
int no_checkout = 0;
+ const char *term;
struct option options[] = {
OPT_BOOL(0, "next-all", &next_all,
N_("perform 'git bisect next'")),
OPT_BOOL(0, "no-checkout", &no_checkout,
N_("update BISECT_HEAD instead of checking out the
current commit")),
+ OPT_STRING(0, "check-term-format", &term, N_("term"),
+N_("check the format of the ref")),
OPT_END()
};
argc = parse_options(argc, argv, prefix, options,
git_bisect_helper_usage, 0);
+
+ if (term != NULL) {
+ if (argc > 0)
+ return check_term_format(term, argv[0], 0);
+ else
+ die("no revision provided with check_for_term");
+ }
+
if (!next_all)
usage_with_options(git_bisect_helper_usage, options);
diff --git a/git-bisect.sh b/git-bisect.sh
index 5d1cb00..ea237be 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -564,8 +564,8 @@ write_terms () {
then
die "$(gettext "please use two different terms")"
fi
- check_term_format "$TERM_BAD" bad
- check_term_format "$TERM_GOOD" good
+ git bisect--helper --check-term-format="$TERM_BAD" bad
+ git bisect--helper --check-term-format="$TERM_GOOD" good
printf '%s\n%s\n' "$TERM_BAD" "$TERM_GOOD" >"$GIT_DIR/BISECT_TERMS"
}
--
https://github.com/git/git/pull/216
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git and concurrent access to local repository
Hi, I always thought git allows concurrent access to a repository and expected that this also is true when working with local repositories. The only problem I was aware of is that the use of NFS and windows shares might cause problems. However I sometime see the following error messages in our concurrent build process. message 1: Fetching origin error: cannot lock ref 'refs/remotes/origin/branchname Unable to create '/home/workingcopy/.git/refs/remotes/origin/ branchname.lock': File exists. If no other git process is currently running, this probably means a git process crashed in this repository earlier. Make sure no other git process is running and remove the file manually to continue. >From servername:gitrepo ! ccea072...349809e branchname -> origin/branchname (unable to update local ref) error: Could not fetch origin message 2: error: cannot lock ref 'refs/remotes/origin/master': ref refs/remotes/origin/master is at 07cd4a461229f9352d16063ff209e828cba592ea but expected 7c4ddcf998bad94f4f7e8e806baaa475f2069e60 message 3 (on git pull --rebase): Cannot rebase onto multiple branches Does that mean there is an issue inside git's locking or is concurrent access to the same workingcopy not supported at all? I expected the commands would blocking until they can acquire the lock, but It seems like there are other command which are either aborting or not locking at all (git pull -reabase). I think git pull --rebase is just a chain of other git commands where the lock is done on the individual steps. Am I doing something wrong or is it concurrent access just not support this way? Does that mean I have to use my own locks such as putting flock around each call? Best Regards Heiko Böttger -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC_PATCHv4 4/7] submodule init: redirect stdout to stderr
On Tue, Mar 22, 2016 at 3:06 AM, Stefan Beller wrote: > Reroute the output of stdout to stderr as it is just informative > messages, not to be consumed by machines. Just wondering, what's Git's policy on this? This message is neither an error nor a warning, but just purely informational. As such it semantically does not belong to stderr, or? On the other hand I see multiple places in Git's code where printing to stderr is (mis-)used for informational messages, probably to separate output to be consumed by humans from output to be consumed by machines, like you do here. -- Sebastian Schuberth -- 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 00/16] git bisect improvements
On Mon, Mar 21, 2016 at 11:22 PM, Stephan Beyer wrote: > > Also sorry, I am not following the list so I didn't know there was a > GSoC project for bisect. > >> If it is okay with you then can I work more upon these >> patches in my GSoC project. > > I'm totally fine with that, of course. :) You are the Stephan Beyer who did a GSoC project on the sequencer around 2009, right? It's nice to see you back on the list :-) -- 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
