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 als
-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
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. Perhap
'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 gi
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 m
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
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
ebase` 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 pu
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
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 Do
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 co
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
>>>
>
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
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
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
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, a
so 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.versio
7; 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
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 b
t 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
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):
>>
>&
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
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 ]
A
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 c
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
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 S
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.
>> Com
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
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
> 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),
&
> 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
y 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
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
> 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 "
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
_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
uot; 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
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
tions 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
k.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
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 option
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
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
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
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 6b9bc79b698d4c9e1a0f74c37887caf2
45 matches
Mail list logo
