[PATCH/GSoC] pull: implement --[no-]autostash for usage when rebasing

Since 53c76dc0 pull understands the "rebase.autoStash" configuration option, which was added to rebase in 58794775 This allows usage of the same option when running 'git pull --rebase', passing it on to 'git rebase' Signed-off-by: Chirayu Desai --- D

Re: [PATCH/GSoC] pull: implement --[no-]autostash for usage when rebasing

On Sat, Mar 19, 2016 at 7:28 PM Chirayu Desai wrote: Since 53c76dc0 pull understands the "rebase.autoStash" configuration option, which was added to rebase in 58794775 This allows usage of the same option when running 'git pull --rebase', passing it on to 'git rebase

Re: [PATCH/GSoC] pull: implement --[no-]autostash for usage when rebasing

t/blacklist", and writing another e-mail to this list for discussion, however I felt that it might be a little less to do as a whole for GSoC, so I was trying to pick something else to do alongwith this. I'll make sure I check the existing applications and threads. Thanks, Chirayu Des

Re: "git tag --contains " is too chatty, if is invalid

eans "return an error, but don't show the usage" This sounds good, but also the most intrusive of 3. > I think any one of those would be a good project for somebody looking to > get their feet wet in working on git. I think (2) is the cleanest. > -Peff What would be the best w

[GSoC] Introduction and Project Discussion

k on "Git remote whitelist/blacklist", and if the mentors deem it to not take too much time / not be too hard of a task, I could also try to look at the configuration parser. Thanks, Chirayu Desai [1]: http://git.github.io/SoC-2016-Ideas/ [2]: http://article.gmane.org/gmane.comp.version-

Re: "git tag --contains " is too chatty, if is invalid

ONTAINS and OPT_WITH > 3. teach parse-options to accept some specific non-zero return code that > means "return an error, but don't show the usage" Would be a good general purpose alternative. I need to look at this a bit more, and also get some hints / clari

Re: "git tag --contains " is too chatty, if is invalid

On Sat, Mar 19, 2016 at 11:27 PM, Jeff King wrote: > On Sat, Mar 19, 2016 at 10:19:02PM +0530, Chirayu Desai wrote: > >> > Yeah, I agree that showing the "-h" help is a bit much. >> > This is a side effect of looking up in the commit in the parse-options >&g

[PATCH/GSoC] parse-options: Add a new nousage opt

* To show only error text on an error instead of the full usage * Currently used only by commands with options "--with" or "--contains", such as 'tag', 'branch', 'for-each-ref'. It now prints only $ git tag --contains qq error: malformed object name qq instead of the full usage text after th

Re: "git tag --contains " is too chatty, if is invalid

t; On Sat, Mar 19, 2016 at 11:38:09PM +0530, Chirayu Desai wrote: > >> > You'd teach parse_opt_commits() to store the string _name_ of the >> > argument (e.g., using a string_list rather than a commit_list), and then >> > later resolve those names into commits. >

Re: [PATCH/GSoC] parse-options: Add a new nousage opt

This is being discussed in the "Re: "git tag --contains " is too chatty, if is invalid" thread. $gmane/289312 On Sun, Mar 20, 2016 at 12:16 PM, Chirayu Desai wrote: > * To show only error text on an error instead of the full usage > * Currently used only by command

Re: [PATCH/GSoC] parse-options: Add a new nousage opt

that I use daily. I want to get this change done as well, if that is okay. On Thu, Mar 24, 2016 at 4:01 AM, Jeff King wrote: > On Sun, Mar 20, 2016 at 12:16:45PM +0530, Chirayu Desai wrote: > >> diff --git a/parse-options-cb.c b/parse-options-cb.c >> index 239898d946..ac2ea4d6

Re: "git tag --contains " is too chatty, if is invalid

On Thu, Mar 24, 2016 at 4:11 AM, Jeff King wrote: > On Sun, Mar 20, 2016 at 12:19:46PM +0530, Chirayu Desai wrote: > >> I went for 3, and have sent a patch for that here - [PATCH/GSoC] >> parse-options: Add a new nousage opt >> However, it currently has one bug >>