Re: [RFC] git subcommand to check if branch is up-to-date with upstream
On Monday 25 July 2016 11:03 PM, Jakub Narębski wrote: > W dniu 2016-07-25 o 18:58, Junio C Hamano pisze: >> Sidhant Sharma writes: >> >>> I was wondering if it would be a good idea to have a command to check if a >>> push or pull is required. Perhaps it can also suggest if changes are >>> fast-forward or the branches (local and remote) have diverged. >> Doesn't "branch -v" give that information these days? You'd need to >> "fetch" first to get the up-to-date worldview before running it, of >> course. > You need "branch -v -v". For current branch, you can simply run "git > checkout". > All this is the information for end user, not scripts. > > $ git branch -v -v > * gitweb-docs 4ebf58d [origin/master: ahead 1] gitweb(1): Document query > parameters > master08bb350 [origin/master] Sixth batch of topics for 2.10 > > $ git checkout > Your branch is ahead of 'origin/master' by 1 commit. > (use "git push" to publish your local commits) > Nice, didn't know that one. Thanks for the tip. Regards, Sidhant Sharma -- 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
[RFC] git subcommand to check if branch is up-to-date with upstream
Hi, I was wondering if it would be a good idea to have a command to check if a push or pull is required. Perhaps it can also suggest if changes are fast-forward or the branches (local and remote) have diverged. The reason I feel the need of such a command is when I need to check if my branch is up-to-date with the remote, and when I need to know if my local has diverged. Currently I use a script based on this stackoverflow answer[1] Not an extremely useful tool, but I thought it'll be good to have it. Warm regards, Sidhant Sharma [1] http://stackoverflow.com/a/3278427/5211579 -- 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 mascot
Hi, When thinking of a mascot for Git, the image of a cherry tree pops up in my head. I'd think of a simple and elegant caricature of a tall tree (just like git histories tend to get long) with a couple of branches and some cherries (think cherry-pick) hanging around in the lush green crown. Perhaps wearing green gloves and hands on waist, with big dark eyes and a smile. IMHO, it might be a good idea to let the mascot have a simple and minimal design instead of intricate detailing as it would be both easier remember and easier for production. Also, I'm not a _very_ good sketch artist, but I think I can make some basic sketches for this one. Regards, Sidhant -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
log --pretty accepts incomplete pre-defined formats
Hi, Recently while playing around with git log, I realized that it is possible to pass incomplete (pre-defined) format names. For example, it is possible to use `git log --pretty=one` instead of oneline and it would still output the logs in oneline formatting. Same goes for other formats such as 'raw', 'short' and others. I looked at the code and it seems that it is intentionally kept so. It this so? I'm curious to know the reason behind keeping this so. Thanks and regards, Sidhant Sharma -- 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: Signed-off-by vs Reviewed-by
Hi, On Thursday 31 March 2016 08:05 PM, Miklos Vajna wrote: > Hi, > > On Thu, Mar 31, 2016 at 07:54:47PM +0530, Pranit Bauva > wrote: >> Are you suggesting to use a different email address for commiting, >> signing off and reviewing? > Let's say project A has a workflow where patch authors and maintainers > add a "Signed-off-by: A B " line. This is well-supported > by git, various commands have a -s option to add that line. > > However, if project B has a workflow where patch authors add no such > line, and reviewers add a "Reviewed-by: A B " line, then > you have to add that line manually when you do a review. When making the string configurable, would it be a good idea to support more than one sign-off strings? For instance, often patches here in Git have both a Signed-Off and a Reviewed-by line. What would you suggest for such a case? Regards, Sidhant -- 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
[RFC/GSOC] Git Beginner | Warnings for potentially destructive commands (v2)
Updated the warning messages, and added warnings for two more commands
(`checkout --` and `stash clear`). The list is now:
$ git rebase
$ git reset --hard
$ git clean -f
$ git gc --prune=now --aggressive
$ git push -f
$ git push remote [+/:]
$ git branch -D
$ git checkout [-p] [] --
$ git stash clear
Looking forward to your comments.
Thanks and regards,
Sidhant Sharma
---
$ ggit rebase
[WARNING] You are about to rebase your commits in $TOPIC_BRANCH onto the
$BASE_BRANCH, which will essentially replay the work done in $TOPIC_BRANCH
since last merge onto $BASE_BRANCH.
For instance, assume the following history exists and the current branch is
master:
o---o---A---B master
\
X---Y topic
After rebasing, the history would be:
o---o---A---B master
\
X'---Y' topic
where X' and Y' are the commits making changes identical to those made by X and
Y respectively.
Rebasing is not usually problematic except in cases when you are rebasing
commits that exist outside your repository (such as on a remote or on someone
else's computer).
$ ggit reset --hard
Resetting to
[WARNING] You are about to hard reset the current HEAD ($CURRENT_BRANCH) to a
previous commit in history, possibly in another branch. This will discard all
changes make thereafter.
For instance, assume the following history exists and the current branch is
master:
o---o---A---B---C---D---E master
After resetting 3 commits:
o---o---A---B master
The commits C, D and E and the changes made by them will be lost.
Note that if you make commits on top of B, you would have rewritten the history
and would have trouble restoring it easily.
You can undo this action by resetting the HEAD to the last commit you were on,
which can be seen by running `git reflog`. The first entry (HEAD{1}) points to
the current HEAD location, second entry (HEAD{1}) points to the last position of
your HEAD and so on.
If you want to reset while retaining the changes made since, use --soft instead
of --hard. This will reset without discarding the changes made in the previous
commits.
$ ggit push --force
Pushing changes to $REMOTE/$BRANCH
[WARNING] You are about to purge commits from the $REMOTE/$BRANCH branch and
overwrite it's history to match yours.
For instance, assume the following history exists where 'origin' is a configured
remote and the current branch is master:
o---o---o---A---B origin/master
\
X---Y---Z your master
After force push:
o---o---o---X---Y---Z origin/master and your master
Commit A and B will be gone. If other people have worked on top of A or B then
they won't be able to merge their changes easily.
To revert this, you would have to force push from a computer that has not yet
pulled the changes you pushed and still has commits A and B as they were in
origin/master previously.
$ ggit push : ( ggit push --delete )
Pushing changes to $REMOTE/$BRANCH
[WARNING] You are about delete a remote branch, which will result in the loss
of commits made on that branch. This may cause a problem if other people are
working on the branch you are deleting, as they would not be able to push or
merge their changes easily.
You can undo this by pushing the same branch to the remote with upstream flag,
that is, by running:
`$ ggit push -u $REMOTE $BRANCH`
This will work unless you have deleted the branch locally as well. In that case,
you need to restore it first.
$ ggit push +
( or ggit push +: )
Pushing changes to $REMOTE/$BRANCH
[WARNING] You are attempting to push changes from $BASE_BRANCH to $TARGET_BRANCH
while allowing non-fast-forward updates. This can leave unreferenced commits
dangling in the origin repository.
For instance, assume the following history exists where 'origin' is a configured
remote and the current branch is master:
o---o---A---B origin/master
\
X---Y---Z your master
State after forced push:
o---o---A---B(unnamed branch)
\
X---Y---Z origin/master and your master
Commits A and B would no longer belong to a branch with a symbolic name, and so
would be unreachable. Also, people who have based their work on A or B would
have to either merge or rebase after you have pushed.
If you wish to keep both the changesets (A,B and X,Y,Z), you may want to use
`merge` or `rebase`.
$ ggit branch -D
( or ggit branch -d -f )
Deleting branch $TARGET_BRANCH
[WARNING] You are about to force delete the $TARGET_BRANCH branch. This will
cause git to delete the branch even if it has not been merged, which may result
in loss of commits. Unless you are confident the branch has been merged, use
`-d` or `--delete` without `--force` which will warn you if the branch has not
been merged.
You can restore a forcefully deleted branch by running:
`$ git branch `
where is the name of the branch you wish to restore
Re: [RFC/GSOC] Git Beginner | Warnings for potentially destructive commands
On Friday 25 March 2016 11:08 PM, Junio C Hamano wrote: > Sidhant Sharma writes: > >> $ ggit rebase >> >> [WARNING] You are about to rebase your commits in onto the >> $BASE_BRANCH, which will essentially replay the work done in $TOPIC_BRANCH >> since last merge onto $BASE_BRANCH. >> For instance, >> Current state: >> >> o---o---A---B $BASE_BRANCH >> \ >> X---Y $TOPIC_BRANCH >> >> State after rebasing: >> >> o---o---A---B---X'---Y' $BASE_BRANCH >> \ >> X---Y $TOPIC_BRANCH >> >> where X' and Y' are the commits making changes identical to those made by X >> and >> Y respectively. > The topology may be correct, but the branch labels are both wrong, > no? The tip of the base branch will stay at B, and the tip of the > topic will point at Y'. Thanks for pointing that out, will correct that. >> Rebasing is not usually problematic except in cases when you are rebasing >> commits that do not exist in your repository. > This cannot be correct, as you fundamentally cannot work on (not > limited to rebasing) commits that do not exist in your repository. > Actually I meant to refer to the commits that exist outside the local repo (eg. on the remote), like it says in the 'The Perils of Rebasing' section of the Git Branching and Rebasing documentation [1]. I'll rephrase it to make it clearer. >> $ ggit reset --hard >> >> Resetting to >> [WARNING] You are about to hard reset the current HEAD (master) by >> commit(s). > If I were on B and did "git reset --hard Y", i.e. > > o---o---A---B $CURRENT_BRANCH > \ >X---Y $CURRENT_BRANCH_AFTER_RESETTING > > does the phrasing "about to reset by commit(s):" make any sense? > >> This will take you back to commit , and discard all >> changes make thereafter. For instance, >> Current state: >> >> o---o---A---B---C---D---E $CURRENT_BRANCH >> >> After resetting 3 commits: >> >> o---o---A---B $CURRENT_BRANCH > The above two examples make me wonder if these should be static > text. "ggit rebase" and "ggit reset" have full information of the > concrete branch names, commit object names and the actual topology > of the history, so it should be able to give a description more > tailored to the user's situation. Instead of giving a fictional > drawing with "For instance, Current state:", it should be able to > draw the actual before-and-after picture based on where the end-user > actually is. I see _some_ attempts (e.g. with "", mention of > "(master)" and $BASE_BRANCH, you may have meant that they will be > replaced with actual values), but I suspect that telling some truth > (i.e. use of the real branch names) while showing pictures that do > not match the reality (i.e. if the topology and the description are > done as fixed text) would only confuse the users. On Sunday 27 March 2016 01:06 PM, Jacob Keller wrote: > On Sat, Mar 26, 2016 at 8:12 AM, Matthieu Moy > wrote: >> Jacob Keller writes: >> >>> If possible, I would suggest aiming for generating the actual topology >>> that the user is seeing, customized so that it gives relevenat >>> information, rather than static examples. >> Using the real topology in a useful way is actually pretty hard. It's >> quite easy to throw the output of "git log --graph --oneline ..." to the >> user, but as soon as the rebase deals with more than a handfull of >> commits, we'd want to simplify the history to show something >> understandable to the user (which by definition should be a beginner if >> he uses ggit), like replacing long sequences of commits with "..." or >> so. That is hard to get right. >> > Yes, in which case we should go Junio's route of not using anything > from the real topology. > I now understand why using the actual names with a hypothetical topology would only confuse the user. I'll update the diagrams with hypothetical names. Also, other than these commands, what others should I include in the list? I think we may also have warnings for the following: * git checkout -- * git rm --cached * git stash drop [] * git stash clear * All plumbing commands? Comments? Thanks and regards, Sidhant Sharma [1]: https://git-scm.com/book/en/v2/Git-Branching-Rebasing#The-Perils-of-Rebasing -- 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
[RFC/GSOC] Git Beginner | Warnings for potentially destructive commands
Hi,
I made an attempt at writing warning messages for the commands the beginners
will be warned against, and would like to request your comments and feedback
on them. I tried to keep them simple, beginner friendly and educative of the
outcome of those commands.
I'd also like to ask if `git rebase` should be kept in the
list as it may not be bad in most cases, though I prepared a
message for that anyway.
Thanks and regards,
Sidhant Sharma
The current list of graylisted commands is as follows:
$ git rebase
$ git reset --hard
$ git clean -f
$ git gc --prune=now --aggressive
$ git push -f
$ git push remote [+/:]
$ git branch -D
Warning messages:
$ ggit rebase
[WARNING] You are about to rebase your commits in onto the
$BASE_BRANCH, which will essentially replay the work done in $TOPIC_BRANCH
since last merge onto $BASE_BRANCH.
For instance,
Current state:
o---o---A---B $BASE_BRANCH
\
X---Y $TOPIC_BRANCH
State after rebasing:
o---o---A---B---X'---Y' $BASE_BRANCH
\
X---Y $TOPIC_BRANCH
where X' and Y' are the commits making changes identical to those made by X and
Y respectively.
Rebasing is not usually problematic except in cases when you are rebasing
commits that do not exist in your repository.
$ ggit reset --hard
Resetting to
[WARNING] You are about to hard reset the current HEAD (master) by
commit(s).
This will take you back to commit , and discard all
changes make thereafter. For instance,
Current state:
o---o---A---B---C---D---E $CURRENT_BRANCH
After resetting 3 commits:
o---o---A---B $CURRENT_BRANCH
The commits C, D and E and the changes made by them will be lost.
Note that if you make commits on top of B, you would have rewritten the history
and would have trouble restoring it easily.
You can undo this action by resetting the HEAD to the last commit you were on,
which can be seen by running `git reflog`. The first entry (HEAD{1}) points to
the current HEAD location, second entry (HEAD{1}) points to the last position of
your HEAD and so on.
If you want to reset while retaining the changes made since, use --soft instead
of --hard. This will reset without discarding the changes made in the previous
commits.
$ ggit push --force
Pushing changes to $REMOTE/$BRANCH
[WARNING] You are about to purge commits from the master branch.
For instance,
Current state:
o---o---o---A---B master on $ORIGIN_URL
\
X---Y---Z your master
State after forced push:
o---o---o---X---Y---Z master on $ORIGIN_URL and your master
Commit A and B will be gone. If other people have worked on top of A or B then
they won't be able to merge their changes easily.
$ ggit push : ( ggit push --delete )
Pushing changes to $REMOTE/$BRANCH
[WARNING] You are about delete a remote branch, which will result in the loss
of commits made on that branch. This may cause a problem if other people are
working on the branch you are deleting, as they would not be able to push or
merge their changes easily.
You can undo this by pushing the same branch to the remote with upstream flag,
that is, by running:
`$ ggit push -u $REMOTE $BRANCH`
This will work unless you have deleted the branch locally as well. In that case,
you need to restore it first.
$ ggit push +
( ggit push +: )
Pushing changes to $REMOTE/$BRANCH
[WARNING] You are attempting to push changes from $BASE_BRANCH to $TARGET_BRANCH
while allowing non-fast-forward updates. This can leave unreferenced commits
dangling in the origin repository.
For instance,
Current state:
o---o---A---B $REMOTE/$TARGET_BRANCH
\
X---Y---Z your $BASE_BRANCH
State after forced push:
o---o---A---B(unnamed branch)
\
X---Y---Z $REMOTE/$TARGET_BRANCH and your $BASE_BRANCH
Commits A and B would no longer belong to a branch with a symbolic name, and so
would be unreachable. Also, people who have based their work on A or B would
have to either merge or rebase after you have pushed.
If you wish to keep both the changesets (A,B and X,Y,Z), you may want to use
`merge` or `rebase`.
$ ggit branch -D
( ggit branch -d -f )
Deleting branch $TARGET_BRANCH
[WARNING] You are about to force delete the $TARGET_BRANCH branch. This will
cause git to delete the branch even if it has not been merged, which may result
in loss of commits. Unless you are confident the branch has been merged, use
`-d` or `--delete` without `--force` which will warn you if the branch has not
been merged.
You can restore a forcefully deleted branch by running:
`$ git branch `
where is the name of the branch you wish to restore and is
the last commit made to the branch you want to restore. You can find this
information by running `git reflog`.
To undo deletion of this branch, you can run:
`$ ggit branch $TARGET_BRANCH $LAST_COMMIT_SHA`
$ ggit clean -f []
Cleaning $PATH
[WARNING] You are about to clean $PATH,
Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner
Updated examples with better description for force push and reset HEAD, as suggested by Lars [11]. Thanks and regards, Sidhant Sharma [11]: http://thread.gmane.org/gmane.comp.version-control.git/289365/focus=289495 --- 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 Git model. A few examples to illustrate the working of the wrapper are: $ ggit add --all Staging all changes and untracked files. Use ` [g]git commit` to commit the changes. $ ggit commit -m “Second commit”
Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner
On Tuesday 22 March 2016 02:08 PM, Lars Schneider wrote: > 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 comma
Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner
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 Git model. A few examples to illustrate the working of the wrapper are: $ ggit add --all Staging all changes and untracked files. Use ` [g]git commit` to commit the changes. $ ggit commit -m “Second commit” Commi
Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner
On Monday 21 March 2016 01:59 PM, Matthieu Moy wrote: > Sidhant Sharma writes: > >> On Monday 21 March 2016 12:22 AM, Matthieu Moy wrote: >> >>> Note that it implies writting an almost full-blown option parser to >>> recognize commands like >>> >>> ggit --work-tree git --namespace reset --git-dir --hard git log >>> >>> (just looking for "git", "reset" and "--hard" in the command-line would >>> not work here). >> Could you please elaborate on the above command, I'm unable to >> understand its syntax. I thought all git commands follow the >> `git command ` syntax, so using simple string >> manipulations and regexes would work. Am I missing something? > The full syntax is > > git [global options] [options and arguments for a command] > > For example: > > git -p log => -p is the option for "git" itself, which means "paginate" > git log -p => -p is the option for "git log", which means "patch" > > Options can have stuck or non-stuck form, for example > > git --work-tree=foo <=> git --work-tree foo > > git --work-tree git --namespace reset --git-dir --hard git log > <=> > git --work-tree=git --namespace=reset --git-dir=--hard git log > > (This is probably a stupid command to type, but it's legal) > > The later is source of issues for a parser since you can't just iterate > through argv[] and search for problematic commands/options, since you > have to distinguish options themselves (--work-tree above) and option > arguments (foo above). Thanks for the explanation; I knew of the global options but didn't know that the last command would be syntactically legal. For commands like such iterating over argv[] wouldn't work (not in all cases). Though a beginner may not enter commands of this sort, I agree we shouldn't rely on that. If it were only for stuck commands, regexes would've worked. I can now see why a parser would be needed here, which can recognize global options and the above command syntax. But for this example, > In my example above, I played with global options (before "git" in the > command-line), but I could also have done that with per-command options > taking arguments, like > > git push --repo --force > > Here, --force is the name of the repo (again, probably a stupid name, > but why not), not the --force option. would the parser also be required to understand all options and arguments for all git commands? Although --force could not be a branch name (git denies it), but it may not be so for other commands. >> I wasn't sure if we are allowed to code before the actual coding period >> begins >> so I kept it that way. I'll update it now. > You're not "forced" to, but you can write code whenever you like. We've > already seen code written before the application! > Nice! I too would like to get started early :) -- 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: [GSOC/RFC] GSoC Proposal Draft | Git Beginner
On Monday 21 March 2016 12:22 AM, Matthieu Moy wrote: > Sidhant Sharma writes: > >> A wrapper is to be implemented around (currently called 'ggit'), which will >> provide the following user interface: >> `ggit ` > There's actually already a tool doing this: > > https://people.gnome.org/~newren/eg/ > > I'm Cc-ing the author. > > I heard good feedback about the tool in the early days of Git, when git > itself was rather clearly not ready for bare mortals. The tool seems > abandonned since 2013 (last release), my guess is that git became usable > enough and eg is not needed as much as it was. For example, eg defaulted > to push.default=tracking before we did the change to push.default=simple > in git. Nice! I'll take a look at its source and see how it works. > > I think the "wrapper" approach is sound. It avoids touching git itself > and breaking things that depend on git (for example, adding > core.denyHardReset to let "git reset --hard" error out would be > unacceptable because it would mean that any script using "git reset > --hard" would break when a user has the option set in ~/.gitconfig). > > Note that it implies writting an almost full-blown option parser to > recognize commands like > > ggit --work-tree git --namespace reset --git-dir --hard git log > > (just looking for "git", "reset" and "--hard" in the command-line would > not work here). Could you please elaborate on the above command, I'm unable to understand its syntax. I thought all git commands follow the `git command ` syntax, so using simple string manipulations and regexes would work. Am I missing something? >> 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'. >> >> 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. >> 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. > I'm not 100% convinced that this is a good idea: it'd be tempting for > the user to run a command just to know what it does. Perhaps it's better > to let the user run "git -h" instead. But it could indeed help > for commands doing very different things depending on the options, like > > $ git checkout foo > Checks-out branch foo > $ git checkout -b bar > Creating a new branch bar and checking it out > $ git checkout HEAD -- . > Reverting directory . to its last commited state Yes, I did consider that and came up with this: I thought we can have an option like --intro or --doc that will just print the intro snippet for the command without actually running. Though "git -h" is an option, I wasn't inclined towards it as I think sometimes the output from -h may not make sense to a new user. Plus, -h only gives an elaborate list of syntax and options/arguments but not say what the command does. > ... > > (I think a list of examples would be an important addition to your > proposal to clarify the plans) Will do that. >> The descripti
[GSOC/RFC] GSoC Proposal Draft | Git Beginner
Hi, I have drafted my proposal for the project 'Git Beginner', and would like to request your suggestions on improving it. I'm also reading up the Git documentation and the Git ProBook (again) to make notes for the beginner documentation. Would be great to hear your comments on it. 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. 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. Developed a robust Plugin framework for Android for a startup. Learning Linux kernel programming via the Eudyptula Challenge. Developed natural language processor for sarcasm detection in tweets. Developed gesture detection module as a college minor project. Active Firefox Add-ons Editor at AMO (addons mozilla org). 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 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'. 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. 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 Git model. Timeline Community Bonding Period Week 1 : Discuss the flow of course with the mentor. Discuss adequate data structures and search techniques to be used. Week 2-3 : Discuss over an extensive list of commands that should be classified as destructive. Discuss appropriate short descriptions for commands. Week 4 : Discuss code structure, tests, optimization for least overhead and other details. Coding Starts Week 1-2 : Submit code for a basic wrapper that will warn for a subset of the potentially destructive command, and continue if the command is safe. and this is stored as per to provide backwar
Re: [RFC/GSoC] Introduction
On Sunday 20 March 2016 09:38 PM, Lars Schneider wrote: > On 20 Mar 2016, at 16:51, Sidhant Sharma wrote: > >> On Sunday 20 March 2016 09:09 PM, Lars Schneider wrote: >>> Hi Sidhant, >>> >>> that sounds about right to me. In what language do you plan to implement >>> the >>> wrapper? >> I'm comfortable in programming with C, so I think I can use that. Otherwise, >> I'm also comfortable with python and familiar with bash, if they are >> required. >> Would C be the right choice though? >> Also, I've made a draft proposal for the project and uploaded to the GSoC >> application site. Should I send it to the list as well for RFC? > Although I like Python a lot, I don't think it would be a good choice. AFAIK > Git > core does not depend on Python and therefore you can't really expect a Python > interpreter in every Git environment (e.g. it is not part of Git for Windows). > > The wrapper could certainly be implemented in C, although I don't know if > this > would make things harder then they need to be. My initial thought was to use a > scripting language that is known to be shipped with Git (Bash or Perl). I > think Perl might even have an advantage as it offers very good regex/string > processing functions (disclaimer: I am no Perl expert at all...). Okay, I'll get started with Perl right away, shouldn't take long. > Please post your draft proposal as plain text RFC to the list. > > Thanks, > Lars > > >> Thanks, >> Sidhant Sharma >>> Best, >>> Lars >>> >>> On 17 Mar 2016, at 15:52, Sidhant Sharma wrote: >>> >>>> Hi, >>>> >>>> So to sum up, the list of tasks for the project would be: >>>> 1. A wrapper is to be implemented around (called 'ggit') that will scan the >>>> arguments for potentially destructive commands. When none are found, all >>>> the >>>> arguments will simply be passed through to git. >>>> 2. If such a command is found, 'ggit' will: >>>> a. Show what the command is actually going to do. >>>> b. Ask the user if they are sure they want to execute it. >>>> Eg. "You are about to do X which will permanently destroy Y. Do you want >>>> to >>>> continue?" >>>> 3. For all commands that are entered, 'ggit' will also show a brief >>>> summary of >>>> the command what it will do when executed, explaining it's intended usage. >>>> >>>> Is the list correct, or did I miss something? >>>> >>>> >>>> Thanks and regards, >>>> Sidhant Sharma -- 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/GSoC] Introduction
On Sunday 20 March 2016 09:09 PM, Lars Schneider wrote: > Hi Sidhant, > > that sounds about right to me. In what language do you plan to implement the > wrapper? I'm comfortable in programming with C, so I think I can use that. Otherwise, I'm also comfortable with python and familiar with bash, if they are required. Would C be the right choice though? Also, I've made a draft proposal for the project and uploaded to the GSoC application site. Should I send it to the list as well for RFC? Thanks, Sidhant Sharma > Best, > Lars > > On 17 Mar 2016, at 15:52, Sidhant Sharma wrote: > >> Hi, >> >> So to sum up, the list of tasks for the project would be: >> 1. A wrapper is to be implemented around (called 'ggit') that will scan the >> arguments for potentially destructive commands. When none are found, all the >> arguments will simply be passed through to git. >> 2. If such a command is found, 'ggit' will: >>a. Show what the command is actually going to do. >>b. Ask the user if they are sure they want to execute it. >> Eg. "You are about to do X which will permanently destroy Y. Do you want to >> continue?" >> 3. For all commands that are entered, 'ggit' will also show a brief summary >> of >> the command what it will do when executed, explaining it's intended usage. >> >> Is the list correct, or did I miss something? >> >> >> Thanks and regards, >> Sidhant Sharma -- 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/GSoC] pull: implement --[no-]autostash for usage when rebasing
On Saturday 19 March 2016 07:38 PM, Chirayu Desai wrote: > Hello everyone, > > I want to participate in GSoC, and this is my microproject to get familiar > with git development. > > I am a first year student, enrolled in the Computer Engineering program at > Silver Oak College of Engineering and Technology, Ahmedabad, India. > I have worked on open source software in the past, and have used git quite > a bit during that time. I'll include more details in my proposal, which > I'll send here when done. > I understand that this might be a bit late to get started, and I'll try my > best to get this patch in a good state and get the proposal ready ASAP. > > As for the change, I spent a lot more time trying to get the test right > than doing the actual change, most of it trying to get familiar with the > test framework and figuring out what to use. It didn't take much time > though, overall. > > I'm adding a few inline comments as I have a few questions. Hi, Thanks for the patch. I believe there already is work in progress on this (See [1] and [2]). You may want to try another microproject. It may also be a good idea to mention which GSoC project idea you would like to work on, as there already may be other proposals on their way. Thanks and regards, Sidhant Sharma [1] http://thread.gmane.org/gmane.comp.version-control.git/287568/focus=287569 [2] http://thread.gmane.org/gmane.comp.version-control.git/289127/focus=289222 -- 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/GSoC] Introduction
Hi, So to sum up, the list of tasks for the project would be: 1. A wrapper is to be implemented around (called 'ggit') that will scan the arguments for potentially destructive commands. When none are found, all the arguments will simply be passed through to git. 2. If such a command is found, 'ggit' will: a. Show what the command is actually going to do. b. Ask the user if they are sure they want to execute it. Eg. "You are about to do X which will permanently destroy Y. Do you want to continue?" 3. For all commands that are entered, 'ggit' will also show a brief summary of the command what it will do when executed, explaining it's intended usage. Is the list correct, or did I miss something? Thanks and regards, Sidhant Sharma -- 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/GSoC] Introduction
On Monday 14 March 2016 11:44 AM, Jacob Keller wrote: > On Sun, Mar 13, 2016 at 10:25 PM, Sidhant Sharma > wrote: >> On Monday 14 March 2016 04:58 AM, Jacob Keller wrote: >>> >>> If I recall correctly, a configuration setting was previously >>> discussed but mostly discarded as a solution since any changes had >>> better not impact any current scripts. Having to add "--no-beginner" >>> for all of them seems unacceptable. Especially since many scripts may >>> do potentially dangerous operations in a safe or useful way. >>> >> I agree that adding `--no-beginner` to all such commands wouldn't be right. >> In >> that case, can we have the flag between git and the command? Such as >> `git --no-beginner reset --hard`. If present, the flag can then be removed >> from >> the argument list and the rest of the command executed as is without warning. >> Would that a better option? >> >> >> Thanks and regards, >> Sidhant Sharma >> > No, the whole problem with "--no-beginner" is that scripts must either > check the configuration variable or add the flag. Since, by definition > exactly zero scripts do that today, then every script must either (a) > be re-written, (b) accept that some behavior will not work as > expected. > > Most (robust) scripts will already check for aliases, and if not, the > user should expect that doing weird things to their environment in > this way would cause things to break. > > I don't think we can create a design where scripts must be re-written > to protect themselves or accept misbehaving in those ways. > > If we had a clear (used) delineation between porcelain and plumbing > commands, we could have all the porcelain commands accept an argument > but not plumbing. Except that (a) all plumbing commands can be called > from the path relatively easily so a user might still want protection > on those too and (b) we don't actually have an enforced > plumbing/porcelain distinction. While we document one, several scripts > exist in the wild which violate this and which we may want to support. > > I think that we could go this route, but we'd have to be willing to > accept (a) or (b), above as costs to this route. Personally I prefer > the wrapper approach since it neatly bypasses all of this behavior and > seems easier to implement. It's major downside is telling beginners > to use "ggit" or similar, which is a big deal. Thanks for elaborating on that. I now understand why the configuration option approach is not fit. The 'ggit' wrapper does sound more apt for this. I do realize telling the beginners to use 'ggit' instead of just 'git' is a shortcoming of this approach, but perhaps it's worth it if it makes Git easier to use and understand for beginners. Lars' suggestion of short instructions would be really nice for helping beginners form a mental picture of git workflow, and might be worth the trade-off. Thanks and regards, Sidhant Sharma -- 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/GSoC] Introduction
On Monday 14 March 2016 01:46 PM, Lars Schneider wrote: > On 14 Mar 2016, at 07:57, Junio C Hamano wrote: > >> If "ggit" is made too limited, there is an issue. Beginners may at >> some point need to transition to the real thing to fully exploit the >> power of Git, and they may need to unlearn "ggit" and learn Git. > I think a "ggit" wrapper should not introduce any new commands or new > parameters. Everything should be passed unmodified to Git. The wrapper > would only add additional warnings such as "You are about to do X which > will permanently destroy Y. Do you want to continue?". Therefore > a transition from "ggit" to "git" would not require any learning effort. > > Maybe "ggit" could also be interpreted as "guided Git" (sounds more > friendly than "guarded Git"). I have the impression that many Git > beginners make mistakes because they don't have a mental model of Git, > yet. A "guided" Git version could explain the commands a bit more > detailed as they use Git (e.g. with ASCII graph examples). I know > that's what man pages are for but I've encountered many users > (especially on Windows) that are not aware of man pages. I too think that the wrapper should only pass on commands to git if they aren't potentially destructive, and not itself introduce new commands, unless there is a need (I doubt if there will be). > >> This approach, if it wants to become successful in helping users, >> would take quite a lot of thinking and work to avoid omitting too >> much to necessitate users to migrate to Git. But I can very well >> imagine that a new "Cogito 2" project (I am not saying that the UI >> Cogito tried to achieve were superiour or anything of that sort--I >> just needed a name, and picked one name that came to my mind) may >> get done by those who interact rarely with the core Git community >> and may live as one of many independent and viable third-party >> projects you find on GitHub. >> >> There however are two questions I do not offhand have good answers >> to: (1) if that kind of effort is of suitable size for GSoC, and (2) >> if it is suitable to be supported by the Git project proper. > Good questions. I have no previous experience with GSoC Git projects > and therefore I am not qualified for an answer. However, my gut feeling > would be that a proof of concept implementation of a "ggit" wrapper > that does not add any new commands and only adds warnings for destructive > commands could be in the GSoC scope. However, Sidhant must be aware of > the fact that this is a controversial topic and therefore any future work > on this topic might be never merged into Git. > > I also thought about (2). The obvious advantage of having something like > "ggit" as part of Git core is that it would be shipped with the standard > Git distribution. That would especially help beginners. However, > maintenance is a very strong counter argument. Maybe "ggit" could > start as a separate project and if it picks up then Git core can still > decide to merge it? > I understand that this endeavour may or may not be merged into the official Git distribution (though I'd really like it to :)), but I still wish to attempt this. I'm also eager to continue work on this even after GSoC is over, so maintenance shouldn't be an issue ;) Thanks and regards, Sidhant Sharma -- 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/GSoC] Introduction
On Monday 14 March 2016 02:49 AM, Kevin Daudt wrote: > On Mon, Mar 14, 2016 at 12:03:33AM +0530, Sidhant Sharma wrote: >> Other than this, I also tried to expand the list of potentially destructive >> commands and updated the list as follows (additions in brackets): >> >> * git rebase [ git pull --rebase ] >> * git reset --hard >> * git clean -f >> * git gc --prune=now --aggressive >> * git push -f [ git push :, git push + ] >> * [ git branch -D ] >> >> Are these additions appropriate? What other commands should be included? >> > git checkout [ref] is destructive too if it would overwrite an > uncomitted change. Thanks, I'll add that one too. Also, should git checkout -- be added, since it'll discard all uncommitted changes? Regards, Sidhant Sharma -- 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/GSoC] Introduction
On Monday 14 March 2016 04:58 AM, Jacob Keller wrote: > On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma > wrote: >> Coincidentally, my approach too is a wrapper around git as you suggest. >> The approach is simple and straight forward, but I wasn't sure if it would be >> accepted on the list, mainly because it may not look consistent with the >> current >> interface `git command [options]`. Perhaps a configuration like >> `core.beginnerMode` [4] might be apt? By default, it can be false, making git >> behave normally. When set, a safety-check can be run before the command is >> executed to ensure it's not potentially destructive. Very much like a wrapper >> but on the inside. There can be an option like `--no-beginner` to override >> this configuration from the command-line. I was wondering if there should be >> command-specific options as well, such as `beginner.allowForcePush`, >> `beginner.allowRebase` etc. for a finer control over what commands git would >> warn >> the user about. By default, all are set to false, and warning is shown when >> any >> of them is encountered. Another configuration that may be considered is >> `beginner.strict`, which when set would just print the warning and die, >> instead >> of giving the user an option to continue (though I'm a little unsure whether >> this one would be a good idea). >> One thing that bothers me about this approach is that unlike the explicit >> 'ggit' >> wrapper, an internal wrapper would add (unnecessary?) overhead for most >> commands, >> thus impacting the performance. Will that be an issue? >> > If I recall correctly, a configuration setting was previously > discussed but mostly discarded as a solution since any changes had > better not impact any current scripts. Having to add "--no-beginner" > for all of them seems unacceptable. Especially since many scripts may > do potentially dangerous operations in a safe or useful way. > I agree that adding `--no-beginner` to all such commands wouldn't be right. In that case, can we have the flag between git and the command? Such as `git --no-beginner reset --hard`. If present, the flag can then be removed from the argument list and the rest of the command executed as is without warning. Would that a better option? Thanks and regards, Sidhant Sharma -- 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/GSoC] Introduction
On Sunday 13 March 2016 09:20 PM, Lars Schneider wrote: > Hi Sidhant, > > thanks for your interest in the 'Git Beginner' mode topic. I completely > understand your motivation for the topic as your Git learning experience > matches mine. However, please be aware that this is no easy project. The > final implementation might be easy but it will require hard work to come > up with a design for the beginner mode that the list considers to accept. > That being said, I am eager to learn about your ideas on the topic :-) Hi, I understand that this project will require much effort to find an acceptable solution and I'm prepared for it. I'm very excited to take this one up :) > Based on my previous discussions with Junio [3] I think on of the most > important aspects is to ensure that Git does not become harder to use. > I thought a while about this requirement and I wonder if a wrapper called > 'ggit' (guarded Git) could be a solution. The wrapper would pass all > command line arguments to 'git' and check for potentially destructive > commands. If such a command is detected then the user would see a warning. > If the command is not destructive then 'ggit' would print a short instruction > how to "undo" it. The ordinary Git user would not be affected at all by the > wrapper. A novice Git user who is unsure about his/her command line > usage could use `ggit` as a safety net. > > I am curious about your opinions on this kind of approach. I wonder if > people would actually use such a wrapper. Coincidentally, my approach too is a wrapper around git as you suggest. The approach is simple and straight forward, but I wasn't sure if it would be accepted on the list, mainly because it may not look consistent with the current interface `git command [options]`. Perhaps a configuration like `core.beginnerMode` [4] might be apt? By default, it can be false, making git behave normally. When set, a safety-check can be run before the command is executed to ensure it's not potentially destructive. Very much like a wrapper but on the inside. There can be an option like `--no-beginner` to override this configuration from the command-line. I was wondering if there should be command-specific options as well, such as `beginner.allowForcePush`, `beginner.allowRebase` etc. for a finer control over what commands git would warn the user about. By default, all are set to false, and warning is shown when any of them is encountered. Another configuration that may be considered is `beginner.strict`, which when set would just print the warning and die, instead of giving the user an option to continue (though I'm a little unsure whether this one would be a good idea). One thing that bothers me about this approach is that unlike the explicit 'ggit' wrapper, an internal wrapper would add (unnecessary?) overhead for most commands, thus impacting the performance. Will that be an issue? Along with this, the idea of showing a short instruction for undoing commands sounds very nice as it'll help beginners to understand and use git better. I'm eager to know your opinions on this approach :) Other than this, I also tried to expand the list of potentially destructive commands and updated the list as follows (additions in brackets): * git rebase [ git pull --rebase ] * git reset --hard * git clean -f * git gc --prune=now --aggressive * git push -f [ git push :, git push + ] * [ git branch -D ] Are these additions appropriate? What other commands should be included? Thanks and regards, Sidhant Sharma [4]: http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286663 -- 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
[RFC/GSoC] Introduction
Hi everyone! I am Sidhant Sharma, from Delhi, India. I'm a third year Software Engineering student at Delhi Technological University. I am looking to contribute to Git via GSoC 2016. I have also worked on one of the microprojects [1]. I've been using git for nearly two years now, and continue to be surprised by the vast number of features this powerful DVCS possesses. I want to contribute to Git because it has become a daily-use tool for me and it feels exciting to be a part of the community that makes effective collaborative development possible. I would like to work on the project titled 'Git Beginner mode', and have been reading up the discussions that took place regarding this [2]. The reason I wish to take this project in particular is that when I initially started out with Git, and was still discovering how things really worked, I sometimes felt the need for some sort of safety-latch to keep me from making destructive and/or irreversible changes. So, this project gives me the opportunity to implement something on these lines for the future beginners. I believe a lot of discussion on the idea is due. I'm reading up on the commands that were mentioned on the project page to better understand what the project entails, and trying to design a solution for this, without making git harder to use or getting in the user's learning. I would really appreciate your comments, suggestions and critique on this. Thanks and regards, Sidhant Sharma [1]: http://thread.gmane.org/gmane.comp.version-control.git/288035 [2]: http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286613 -- 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: More configuration options for some commonly used command-line options
Sidhant Sharma wrote: > Hi, > > Regarding the GSoC Microproject 'Add configuration options for some commonly > used command-line options', currently the list [1] mentions only > `git commit -v`. Can the following also be candidates for configurations? > * git log -p > * git remote -v > * git branch -v > > > Regards, > Sidhant Sharma [:tk] > > > [1]: https://git.github.io/SoC-2016-Microprojects/ Perhaps they can be added as Microprojects for the next GSoC. Comments? Regards, Sidhant Sharma -- 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
More configuration options for some commonly used command-line options
Hi, Regarding the GSoC Microproject 'Add configuration options for some commonly used command-line options', currently the list [1] mentions only `git commit -v`. Can the following also be candidates for configurations? * git log -p * git remote -v * git branch -v Regards, Sidhant Sharma [:tk] [1]: https://git.github.io/SoC-2016-Microprojects/ -- 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] stripspace: add --line-count flag
On Saturday 05 March 2016 12:19 AM, Junio C Hamano wrote: > Sidhant Sharma writes: > >> This is my first attempt at the small project listed here: >> https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#implement_.27--count-lines.27_in_.27git_stripspace.27. >> Comments? > Isn't that page somewhat stale? > > http://git.661346.n2.nabble.com/PATCH-0-3-stripspace-Implement-and-use-count-lines-option-tt7641360.html#none Oh, I should've checked first. My bad, I was just looking to get familiar with the codebase. Thanks Sidhant Sharma [:tk] -- 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] stripspace: add --line-count flag
> builtin/stripspace.c | 22 +- > git-rebase--interactive.sh | 6 +++--- > 2 files changed, 24 insertions(+), 4 deletions(-) > This is my first attempt at the small project listed here: https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#implement_.27--count-lines.27_in_.27git_stripspace.27. With this, --line-count can be used with stripspace, instead of having to pipe its output to `wc -l` in git-rebase--interactive.sh. I went with --line-count and not --count-lines since its short form (-c) is already in use, and I think -l is more apt for this. Comments? Thanks and regards, Sidhant Sharma [:tk] -- 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] stripspace: add --line-count flag
When used, this flag outputs number of lines after stripspace has removed
trailing whitespace.
With `--line-count`, git-rebase--interactive.sh need not rely on `wc -l` for
line
count.
Signed-off-by: Sidhant Sharma [:tk]
---
This the first version of the patch for the small project listed here:
https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#implement_.27--count-lines.27_in_.27git_stripspace.27
builtin/stripspace.c | 22 +-
git-rebase--interactive.sh | 6 +++---
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/builtin/stripspace.c b/builtin/stripspace.c
index 15e716e..e08da03 100644
--- a/builtin/stripspace.c
+++ b/builtin/stripspace.c
@@ -13,22 +13,38 @@ static void comment_lines(struct strbuf *buf)
free(msg);
}
+static void count_lines(struct strbuf *buf)
+{
+ size_t len = 0;
+ int i;
+
+ for (i = 0; i < buf->len; i++)
+ if (buf->buf[i] == '\n')
+ len++;
+
+ sprintf(buf->buf, "%zu", len);
+ buf->len = strlen(buf->buf);
+}
+
static const char * const stripspace_usage[] = {
N_("git stripspace [-s | --strip-comments]"),
N_("git stripspace [-c | --comment-lines]"),
+ N_("git stripspace [-l | --line-count]"),
NULL
};
enum stripspace_mode {
STRIP_DEFAULT = 0,
STRIP_COMMENTS,
- COMMENT_LINES
+ COMMENT_LINES,
+ LINE_COUNT
};
int cmd_stripspace(int argc, const char **argv, const char *prefix)
{
struct strbuf buf = STRBUF_INIT;
enum stripspace_mode mode = STRIP_DEFAULT;
+ int count = 0;
const struct option options[] = {
OPT_CMDMODE('s', "strip-comments", &mode,
@@ -37,6 +53,7 @@ int cmd_stripspace(int argc, const char **argv, const char
*prefix)
OPT_CMDMODE('c', "comment-lines", &mode,
N_("prepend comment character and space to each
line"),
COMMENT_LINES),
+ OPT_BOOL('l', "line-count", &count, N_("count number of
lines")),
OPT_END()
};
@@ -55,6 +72,9 @@ int cmd_stripspace(int argc, const char **argv, const char
*prefix)
else
comment_lines(&buf);
+ if (count)
+ count_lines(&buf);
+
write_or_die(1, buf.buf, buf.len);
strbuf_release(&buf);
return 0;
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c0cfe88..e8bef37 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -120,9 +120,9 @@ mark_action_done () {
sed -e 1q < "$todo" >> "$done"
sed -e 1d < "$todo" >> "$todo".new
mv -f "$todo".new "$todo"
- new_count=$(git stripspace --strip-comments <"$done" | wc -l)
+ new_count=$(git stripspace --strip-comments --line-count <"$done")
echo $new_count >"$msgnum"
- total=$(($new_count + $(git stripspace --strip-comments <"$todo" | wc
-l)))
+ total=$(($new_count + $(git stripspace --strip-comments --line-count
<"$todo")))
echo $total >"$end"
if test "$last_count" != "$new_count"
then
@@ -1251,7 +1251,7 @@ test -s "$todo" || echo noop >> "$todo"
test -n "$autosquash" && rearrange_squash "$todo"
test -n "$cmd" && add_exec_commands "$todo"
-todocount=$(git stripspace --strip-comments <"$todo" | wc -l)
+todocount=$(git stripspace --strip-comments --line-count <"$todo")
todocount=${todocount##* }
cat >>"$todo" <http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] builtin/receive-pack.c: use parse_options API
> On Wed, Mar 2, 2016 at 3:21 AM, Sidhant Sharma [:tk]
> wrote:
>> + struct option options[] = {
>> + OPT__QUIET(&quiet, N_("quiet")),
>> + OPT_HIDDEN_BOOL(0, "stateless-rpc", &stateless_rpc, NULL),
>> + OPT_HIDDEN_BOOL(0, "advertise-refs", &advertise_refs, NULL),
>> + OPT_HIDDEN_BOOL(0, "reject-thin-pack-for-testing",
>> &reject_thin, NULL),
>> + OPT_END()
>> + };
> If the patch is already final, don't bother. If not, I think I prefer
> to keep all these options visible (except the "...-for-testing"). This
> command is never executed directly by mere mortals. The ones that run
> it need to know all about these hidden tricks because they're
> implementing new transports.
>
> Another side note. I'm not so sure if we should N_() and _() strings
> in this command (same reasoning, the command's user is very likely
> developers, not true users). But it does not harm to i18n-ize the
> command either. Slightly more work for translators, of course.
I can make a patch with the changes, but I think the patch has been finalized.
Should I make one?
Regards,
Sidhant Sharma [:tk]
--
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] builtin/receive-pack.c: use parse_options API
> Matthieu Moy writes: > >> "Sidhant Sharma [:tk]" writes: >> >>> Make receive-pack use the parse_options API, >>> bringing it more in line with send-pack and push. >> Thanks. This version looks good to me. > I'll queue this with your "Reviewed-by:" to 'pu', just as a > Microproject reward ;-). Given that the program will never see an > interactive use from a command line, however, I am not sure if it is > worth actually merging it down thru 'next' to 'master'. > > Thanks. Thanks for accepting my patch :) Now that this one is complete, I was wondering what should I do next. Is there a list of more such microproject-like projects? I'd be very excited to contribute more patches. Thanks and regards, Sidhant Sharma [:tk] -- 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] builtin/receive-pack.c: use parse_options API
> Starting from here, the patch is a bit painful to read because the diff > heuristics grouped hunks in a strange way. You may try "git format-patch > --patience" or --minimal or --histogram to see if it gives a better > result. The final commit would be the same, but it may make review > easier. I tried using the other algorithms, but results were same for all. Regards, Sidhant Sharma [:tk] -- 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] builtin/receive-pack.c: use parse_options API
Make receive-pack use the parse_options API,
bringing it more in line with send-pack and push.
Helped-by: Matthieu Moy
Signed-off-by: Sidhant Sharma [:tk]
---
Link to previous version: $gmane/288035
builtin/receive-pack.c | 53 +++---
1 file changed, 20 insertions(+), 33 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index c8e32b2..220a899 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -21,7 +21,10 @@
#include "sigchain.h"
#include "fsck.h"
-static const char receive_pack_usage[] = "git receive-pack ";
+static const char * const receive_pack_usage[] = {
+ N_("git receive-pack "),
+ NULL
+};
enum deny_action {
DENY_UNCONFIGURED,
@@ -49,7 +52,7 @@ static int quiet;
static int prefer_ofs_delta = 1;
static int auto_update_server_info;
static int auto_gc = 1;
-static int fix_thin = 1;
+static int reject_thin;
static int stateless_rpc;
static const char *service_dir;
static const char *head_name;
@@ -1548,7 +1551,7 @@ static const char *unpack(int err_fd, struct shallow_info
*si)
if (fsck_objects)
argv_array_pushf(&child.args, "--strict%s",
fsck_msg_types.buf);
- if (fix_thin)
+ if (!reject_thin)
argv_array_push(&child.args, "--fix-thin");
child.out = -1;
child.err = err_fd;
@@ -1707,45 +1710,29 @@ static int delete_only(struct command *commands)
int cmd_receive_pack(int argc, const char **argv, const char *prefix)
{
int advertise_refs = 0;
- int i;
struct command *commands;
struct sha1_array shallow = SHA1_ARRAY_INIT;
struct sha1_array ref = SHA1_ARRAY_INIT;
struct shallow_info si;
+ struct option options[] = {
+ OPT__QUIET(&quiet, N_("quiet")),
+ OPT_HIDDEN_BOOL(0, "stateless-rpc", &stateless_rpc, NULL),
+ OPT_HIDDEN_BOOL(0, "advertise-refs", &advertise_refs, NULL),
+ OPT_HIDDEN_BOOL(0, "reject-thin-pack-for-testing",
&reject_thin, NULL),
+ OPT_END()
+ };
+
packet_trace_identity("receive-pack");
- argv++;
- for (i = 1; i < argc; i++) {
- const char *arg = *argv++;
+ argc = parse_options(argc, argv, prefix, options, receive_pack_usage,
0);
- if (*arg == '-') {
- if (!strcmp(arg, "--quiet")) {
- quiet = 1;
- continue;
- }
+ if (argc > 1)
+ usage_msg_opt(_("Too many arguments."), receive_pack_usage,
options);
+ if (argc == 0)
+ usage_msg_opt(_("You must specify a directory."),
receive_pack_usage, options);
- if (!strcmp(arg, "--advertise-refs")) {
- advertise_refs = 1;
- continue;
- }
- if (!strcmp(arg, "--stateless-rpc")) {
- stateless_rpc = 1;
- continue;
- }
- if (!strcmp(arg, "--reject-thin-pack-for-testing")) {
- fix_thin = 0;
- continue;
- }
-
- usage(receive_pack_usage);
- }
- if (service_dir)
- usage(receive_pack_usage);
- service_dir = arg;
- }
- if (!service_dir)
- usage(receive_pack_usage);
+ service_dir = argv[0];
setup_path();
--
2.7.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] builtin/receive-pack.c: use parse_options API
> Hi,
>
> Thanks for your patch.
>
> "Sidhant Sharma [:tk]" writes:
>
>> This patch makes receive-pack use the parse_options API,
> We usually avoid saying "this patch" and use imperative tone: talk to
> your patch and give it orders like "Make receive-pack use the
> parse_options API ...". Or just skip that part which is already in the
> title.
>
>> @@ -45,12 +48,12 @@ static int unpack_limit = 100;
>> static int report_status;
>> static int use_sideband;
>> static int use_atomic;
>> -static int quiet;
>> +static int quiet = 0;
> static int are already initialized to 0, you don't need this explicit "=
> 0". In the codebase of Git, we prever omiting the initialization.
>
>> +struct option options[] = {
>> +OPT__QUIET(&quiet, N_("quiet")),
>> +OPT_HIDDEN_BOOL(0, "stateless-rpc", &stateless_rpc, NULL),
>> +OPT_HIDDEN_BOOL(0, "advertise-refs", &advertise_refs, NULL),
>> +/* Hidden OPT_BOOL option */
>> +{
>> +OPTION_SET_INT, 0, "reject-thin-pack-for-testing",
>> &fix_thin, NULL,
>> +NULL, PARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, 0,
>> +},
> After seeing the patch, I think the code would be clearer by using
> something like
>
> OPT_HIDDEN_BOOL(0, "reject-thin-pack-for-testing", &reject_thin, NULL)
>
> and then use !reject_thin where the patch was using fix_thin. Turns 5
> lines into one here, and you just pay a ! later in terms of readability.
OK, will correct the above points.
>> packet_trace_identity("receive-pack");
>>
>> -argv++;
>> -for (i = 1; i < argc; i++) {
>> -const char *arg = *argv++;
>> +argc = parse_options(argc, argv, prefix, options, receive_pack_usage,
>> 0);
>>
>> -if (*arg == '-') {
>> -if (!strcmp(arg, "--quiet")) {
>> -quiet = 1;
>> -continue;
>> -}
>> +if (argc > 1)
>> +usage_msg_opt(_("Too many arguments."), receive_pack_usage,
>> options);
>> +if (argc == 0)
>> +usage_msg_opt(_("You must specify a directory."),
>> receive_pack_usage, options);
> Before that, the loop was ensuring that service_dir was assigned once
> and only once, and now you check that you have one non-option arg and
> assign it unconditionally:
>
>> +service_dir = argv[0];
> ... so isn't this "if" dead code:
>
>> if (!service_dir)
>> -usage(receive_pack_usage);
>> +usage_with_options(receive_pack_usage, options);
> ?
>
>
Yes, I just realized that is dead code (sorry). Removing the 'if' statement
would correct that? Also, is the unconditional assignment to service_dir
correct in this case, or should some other test condition be added?
Another thing I'd like to ask is when I prepare the next patch, should it be
sent as reply in this thread, or as a new thread?
Thanks and regards,
Sidhant Sharma [:tk]
--
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] builtin/receive-pack.c: use parse_options API
This patch makes receive-pack use the parse_options API,
bringing it more in line with send-pack and push.
Helped-by: Matthieu Moy
Signed-off-by: Sidhant Sharma [:tk]
---
builtin/receive-pack.c | 55 ++
1 file changed, 24 insertions(+), 31 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index c8e32b2..fe9a594 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -21,7 +21,10 @@
#include "sigchain.h"
#include "fsck.h"
-static const char receive_pack_usage[] = "git receive-pack ";
+static const char * const receive_pack_usage[] = {
+ N_("git receive-pack "),
+ NULL
+};
enum deny_action {
DENY_UNCONFIGURED,
@@ -45,12 +48,12 @@ static int unpack_limit = 100;
static int report_status;
static int use_sideband;
static int use_atomic;
-static int quiet;
+static int quiet = 0;
static int prefer_ofs_delta = 1;
static int auto_update_server_info;
static int auto_gc = 1;
static int fix_thin = 1;
-static int stateless_rpc;
+static int stateless_rpc = 0;
static const char *service_dir;
static const char *head_name;
static void *head_name_to_free;
@@ -1707,45 +1710,35 @@ static int delete_only(struct command *commands)
int cmd_receive_pack(int argc, const char **argv, const char *prefix)
{
int advertise_refs = 0;
- int i;
struct command *commands;
struct sha1_array shallow = SHA1_ARRAY_INIT;
struct sha1_array ref = SHA1_ARRAY_INIT;
struct shallow_info si;
+ struct option options[] = {
+ OPT__QUIET(&quiet, N_("quiet")),
+ OPT_HIDDEN_BOOL(0, "stateless-rpc", &stateless_rpc, NULL),
+ OPT_HIDDEN_BOOL(0, "advertise-refs", &advertise_refs, NULL),
+ /* Hidden OPT_BOOL option */
+ {
+ OPTION_SET_INT, 0, "reject-thin-pack-for-testing",
&fix_thin, NULL,
+ NULL, PARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, 0,
+ },
+ OPT_END()
+ };
packet_trace_identity("receive-pack");
- argv++;
- for (i = 1; i < argc; i++) {
- const char *arg = *argv++;
+ argc = parse_options(argc, argv, prefix, options, receive_pack_usage,
0);
- if (*arg == '-') {
- if (!strcmp(arg, "--quiet")) {
- quiet = 1;
- continue;
- }
+ if (argc > 1)
+ usage_msg_opt(_("Too many arguments."), receive_pack_usage,
options);
+ if (argc == 0)
+ usage_msg_opt(_("You must specify a directory."),
receive_pack_usage, options);
- if (!strcmp(arg, "--advertise-refs")) {
- advertise_refs = 1;
- continue;
- }
- if (!strcmp(arg, "--stateless-rpc")) {
- stateless_rpc = 1;
- continue;
- }
- if (!strcmp(arg, "--reject-thin-pack-for-testing")) {
- fix_thin = 0;
- continue;
- }
+ service_dir = argv[0];
- usage(receive_pack_usage);
- }
- if (service_dir)
- usage(receive_pack_usage);
- service_dir = arg;
- }
if (!service_dir)
- usage(receive_pack_usage);
+ usage_with_options(receive_pack_usage, options);
setup_path();
--
2.6.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: GSoC 2016 Microproject
> If you use PARSE_OPT_HIDDEN, I think you don't need to specify a message. > Otherwise, the documentation only has value if it contains more than just the > option name, but that is the hard part if you're not familiar with the code. > The best place to find documentation is in the history (git blame the file > and see if the commit message introducing the option enlightens you). But > that's why I said this didn't have to be part of the microproject: writting > good doc requires a good understanding of the whole thing ... I used OPT_HIDDEN_BOOL for all except for reject-thin-pack-for-testing, where I used PARSE_OPT_HIDDEN. I ran the test locally and also on Travis, and the all tests passed. How do I proceed now? Thanks and regards, Sidhant Sharma [:tk] -- 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: GSoC 2016 Microproject
>> First, I'm not quite sure what to put in the help message for the >> options (--quiet, --stateless-rpc, --advertise-refs and >> --reject-thin-pack-for-testing). > They are currently undocumented. We sometimes have explicitly > undocumented options (PARSE_OPT_HIDDEN) when they are used only > internally to avoid polluting the end-user's UI. > > In this case, the command is anyway not meant for end-users so I think > it would make sense to document them, but not necessarily within the the > microproject. So what may I put in the message parameter? I was thinking perhaps the option itself, without hyphens. Would that be correct? > >> Second, regarding the reject-thin-pack-for-testing option, currently >> when the option is entered, `fix_thin` is unset >> (https://github.com/git/git/blob/master/builtin/receive-pack.c#L1736). >> But using `OPT_BOOL(...)` for the same, the variable would instead be >> set when the option is given. I think one solution can be to invert >> `fix_thin` after calling `parse_options`. Am I going right so far? >> Suggestions and corrections welcome. > Or use OPT_SET_INT(..., 0) on a variable initialized to 1. Okay, will do that. >> Should I make a patch for this and submit it for discussion on the mailing >> list? > On this list, it is indeed often more efficient to say "here's what I'm > done. Any comments?" than "here's what I'm about to do". > I'm really sorry, I'm not very familiar with mailing list etiquettes. I'll keep that in mind :) Thanks and regards, Sidhant Sharma [:tk] -- 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: GSoC 2016 Microproject
Hi, Should I make a patch for this and submit it for discussion on the mailing list? Regards, Sidhant Sharma [:tk] -- 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: GSoC 2016 Microproject
Hi, > I didn't see anything going on for this one, but you may want to > double-check with the ml's archives. > I checked the archives and there doesn't seem to be any active work on this. I made the required changes and ran the test suite. Though all the tests pass, there still are two queries I have. First, I'm not quite sure what to put in the help message for the options (--quiet, --stateless-rpc, --advertise-refs and --reject-thin-pack-for-testing). Second, regarding the reject-thin-pack-for-testing option, currently when the option is entered, `fix_thin` is unset (https://github.com/git/git/blob/master/builtin/receive-pack.c#L1736). But using `OPT_BOOL(...)` for the same, the variable would instead be set when the option is given. I think one solution can be to invert `fix_thin` after calling `parse_options`. Am I going right so far? Suggestions and corrections welcome. Regards, Sidhant Sharma [:tk] -- 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: GSoC 2016 Microproject
> There's already work in progress on this project, see the mailing list > the last few days. > Okay, in that case, I'd like to try is the one titled "Make upload-pack and receive-pack use the parse-options api". In that, I can take up the `builtin/receive-pack.c` file. Would that be okay? Thanks again. Regards, Sidhant Sharma [:tk] -- 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
GSoC 2016 Microproject
Hi everyone,
I'm Sidhant Sharma. I'm looking to participate in GSoC 2016 (and contribute
to Git in general as well). I read up the pages relating to participation
in GSoC and selected the microproject "Add configuration options for some
commonly used command-line options". I have some queries regarding this
though:
1. I believe the option can be added by a reassignment of the `verbose`
variable in `parse_and_validate_options` function inside the
`builtin/commit.c`. It can be a logical OR between the `verbose` (which was
parsed by the argument parser) and the value obtained by using
`git_config_get_bool("command.verbose", &opt_verbose)`. Am I thinking on
the right lines?
2. Should I also add an option to override the configuration for verbose?
3. The microproject title suggests there can more such options, so are
there more to be added?
Thanks in advance.
Regards
Sidhant Sharma [:tk]
--
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] worktree: usage: denote as optional with 'add'
Although 1eb07d8 (worktree: add: auto-vivify new branch when
is omitted, 2015-07-06) updated the documentation when
became optional, it neglected to update the in-code
usage message. Fix this oversight.
Reported-by: ch3co...@gmail.com
Signed-off-by: Sidhant Sharma
---
builtin/worktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 71bb770..33d2d37 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -10,7 +10,7 @@
#include "refs.h"
static const char * const worktree_usage[] = {
- N_("git worktree add [] "),
+ N_("git worktree add [] []"),
N_("git worktree prune []"),
NULL
};
--
2.6.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
[PATCH] Fix worktree usage message
Mark optional in worktree command line usage to maintain consistency
with man pages.
Reported-by: ch3co...@gmail.com
Signed-off-by: Sidhant Sharma
---
It was reported here: http://marc.info/?l=git&m=144514145804787&w=2
builtin/worktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 71bb770..33d2d37 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -10,7 +10,7 @@
#include "refs.h"
static const char * const worktree_usage[] = {
- N_("git worktree add [] "),
+ N_("git worktree add [] []"),
N_("git worktree prune []"),
NULL
};
--
2.6.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
[PATCH] Fix worktree usage message
Mark as optional in worktree command line usage.
Hi, just starting out with development for Git. Found this one super easy to
fix,
so made a patch :)
---
builtin/worktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 71bb770..33d2d37 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -10,7 +10,7 @@
#include "refs.h"
static const char * const worktree_usage[] = {
- N_("git worktree add [] "),
+ N_("git worktree add [] []"),
N_("git worktree prune []"),
NULL
};
--
2.6.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
[PATCH] Fix missing brackets in worktree usage
H, I'm just starting out with development for Git. Found this super easy to fix,
so here is a patch :)
Sidhant Sharma (1):
builtin/worktree.c: Fix usage message
builtin/worktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.6.2
>From 6b9bc79b698d4c9e1a0f74c37887caf2a05f9978 Mon Sep 17 00:00:00 2001
From: Sidhant Sharma
Date: Sun, 18 Oct 2015 13:29:02 +0530
Subject: [PATCH] builtin/worktree.c: Fix usage message
Mark as optional in worktree command line usage.
Signed-off-by: Sidhant Sharma
---
builtin/worktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 71bb770..33d2d37 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -10,7 +10,7 @@
#include "refs.h"
static const char * const worktree_usage[] = {
- N_("git worktree add [] "),
+ N_("git worktree add [] []"),
N_("git worktree prune []"),
NULL
};
--
2.6.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
