Getting started contributing.

Getting started contributing.

[adamfraser]

Hi, 
I would like to start contributing to git and am looking for a small project
idea to get started with. On the  Small Project Ideas wiki
<https://git.wiki.kernel.org/index.php/SmallProjectsIdeas>   site there is a
suggestion for adding a 'git rebase --status' command that sounds like it
would be good for someone who has little knowledge of the code base. Is this
project still wanted? Aside from that, I've done a little searching and
haven't been able to find an official bug tracker for git is there somewhere
I can find some bugs to help fix?
Apologies if this isn't the correct place to be posting.
Thanks
Adam Fraser



--
View this message in context: http://git.661346.n2.nabble.com/Getting-started-contributing-tp7576834.html
Sent from the git mailing list archive at Nabble.com.

Re: Getting started contributing.

[Junio C Hamano]

adamfraser <adamfraser0@gmail.com> writes:

> I would like to start contributing to git and am looking for a small project
> idea to get started with. On the  Small Project Ideas wiki
> <https://git.wiki.kernel.org/index.php/SmallProjectsIdeas>   site there is a
> suggestion for adding a 'git rebase --status' command that sounds like it
> would be good for someone who has little knowledge of the code base.

I think the two patches Duy just posted tonight overlap with that
topic, and I suspect it would give the end users a better experience
to put the information in "git status" output rather than a separate
"git rebase" subcommand.  Perhaps you can work with him to see what
other things his patch may have missed can be improved?

Re: Getting started contributing.

[Junio C Hamano]

adamfraser <adamfraser0@gmail.com> writes:

> I've done a little searching and
> haven't been able to find an official bug tracker for git is there somewhere
> I can find some bugs to help fix?

You came to the right place.  A new bug or regression is reported to
this list, and it often is fixed (or often diagnosed as pebcak)
fairly quickly by list regulars.  Nobody maintains a bugzilla that
is not maintained and is full of stale/invalid bug reports.

The best contribution a new person can make is to use the software
regularly and find issues.  It is very hard to find real bugs that
can easily be fixed by somebody totally new to the codebase in Git
these days.

On the other hand, there probably still are many loose ends.  When a
command is supposed to take only two arguments because taking more
than three does not make any sense, for example, it has not been
unusual for us to document the two-argument form of the command,
reject if the user gives only one argument with an error message,
but we simply ignore the third argument if the user mistakenly runs
the command with three arguments, instead of erroring out (i.e. the
code does not bother to help insane or too inexperienced users).
That kind of things are hard to find by users experienced with Git
exactly because they know running such a command with three or more
arguments is nonsense, and they do not even try to make such a
mistake.  Still, it would be very nice to find and fix such issues.

Thanks.

Re: Getting started contributing.

[Duy Nguyen]

On Sun, Feb 3, 2013 at 2:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
> On the other hand, there probably still are many loose ends.

A few other things

 - Mark more strings for translation (not as easy as it sounds, some
strings can't be translated)
 - Color more in the output where it makes sense
 - Stop/Warn the user from updating HEAD (e.g. checkout another
branch) while in the middle of a rebase (some makes sense, most is by
mistake)

PS. You are welcome to improve my two patches Junio mentioned. I don't
think it overlaps much with "git rebase --status" though. Printing the
remaining steps, or what patch being applied is not going to be done
by "git status".
-- 
Duy

Re: Getting started contributing.

[Philip Oakley]

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Sunday, February 03, 2013 7:49 AM
> adamfraser <adamfraser0@gmail.com> writes:
>
>> I've done a little searching and
>> haven't been able to find an official bug tracker for git is there 
>> somewhere
>> I can find some bugs to help fix?
>
> You came to the right place.  A new bug or regression is reported to
> this list, and it often is fixed (or often diagnosed as pebcak)
> fairly quickly by list regulars.  Nobody maintains a bugzilla that
> is not maintained and is full of stale/invalid bug reports.
>
> The best contribution a new person can make is to use the software
> regularly and find issues.  It is very hard to find real bugs that
> can easily be fixed by somebody totally new to the codebase in Git
> these days.
>
> On the other hand, there probably still are many loose ends.  When a
> command is supposed to take only two arguments because taking more
> than three does not make any sense, for example, it has not been
> unusual for us to document the two-argument form of the command,
> reject if the user gives only one argument with an error message,
> but we simply ignore the third argument if the user mistakenly runs
> the command with three arguments, instead of erroring out (i.e. the
> code does not bother to help insane or too inexperienced users).
> That kind of things are hard to find by users experienced with Git
> exactly because they know running such a command with three or more
> arguments is nonsense, and they do not even try to make such a
> mistake.  Still, it would be very nice to find and fix such issues.
>
A review of the git-user list 
https://groups.google.com/forum/?fromgroups#!forum/git-users is one 
place to discover some of the user issues and thinking about how to 
address them. Or resurrect issues from this Git list. E.g. There are a 
number of sub-module improvements available there.

If you have any Windows experience the MSysGit team 
https://github.com/msysgit/msysgit is always looking for help on some of 
the compatibility issues, e.g. where the Linux optimisations conflict 
with the Windows approaches.

Another area is picking out documentation issues you have seen and 
submitting patches for them, whether in the command man pages or in the 
guides. On my 'todo' list is to make the `help` command actually list 
the "Help me" (i.e. guides and articles) pages, not just the command man 
pages.

I also had -
* Bulk move detection (when folk change/move upper level directory 
names).
* add a .gitnevermerge option to stop private files you don't want in 
'master' (or any other branch) to be merged

Philip

Re: Getting started contributing.

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> On Sun, Feb 3, 2013 at 2:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> On the other hand, there probably still are many loose ends.
>
> A few other things
>
>  - Mark more strings for translation (not as easy as it sounds, some
> strings can't be translated)

True, but not a good advice for somebody new, exactly for the reason
you stated, i.e. some strings must not be translated.

>  - Color more in the output where it makes sense

Eeek.

>  - Stop/Warn the user from updating HEAD (e.g. checkout another
> branch) while in the middle of a rebase (some makes sense, most is by
> mistake)

Perhaps, but again probably not for somebody new who hasn't mastered
various workflows and understood why it may make sense to allow it.

Re: Getting started contributing.

[adamfraser]

Thanks for all of the replies. I'll have a look into the suggestions and try
to find somewhere I can help out. :)



--
View this message in context: http://git.661346.n2.nabble.com/Getting-started-contributing-tp7576834p7576901.html
Sent from the git mailing list archive at Nabble.com.

Re: Getting started contributing.

[Matthieu Moy]

adamfraser <adamfraser0@gmail.com> writes:

> Hi, 
> I would like to start contributing to git and am looking for a small project
> idea to get started with. On the  Small Project Ideas wiki
> <https://git.wiki.kernel.org/index.php/SmallProjectsIdeas>

Just to make it clear: this page is not "the official TODO-list for
Git", but a list where we (essentially me) can throw ideas of things to
be implemented.

As you did, the first thing to do is to discuss ideas on the list, to
make sure they are actually wanted.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Getting started contributing.

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> adamfraser <adamfraser0@gmail.com> writes:
>
>> I would like to start contributing to git and am looking for a small project
>> idea to get started with. On the  Small Project Ideas wiki
>> <https://git.wiki.kernel.org/index.php/SmallProjectsIdeas>   site there is a
>> suggestion for adding a 'git rebase --status' command that sounds like it
>> would be good for someone who has little knowledge of the code base.
>
> I think the two patches Duy just posted tonight overlap with that
> topic, and I suspect it would give the end users a better experience
> to put the information in "git status" output rather than a separate
> "git rebase" subcommand.

(I'm the one who wrote the idea on the wiki)

"git status" already shows a lot of valuable information about rebase,
but my idea was that there's still room for a much more verbose command
(hence too verbose to appear in the output of "git branch" or "git
status"), saying eg.

* Which patch is being applied (we can imagine giving just the subject
  line by default, but showing the complete patch with an additional
  --patch option). I often miss that when trying to understand the
  origin of a conflict. I can manually look at file
  .git/rebase-merge/patch (I seem to remember a patch that shows the
  path to this file when rebase stops, but I can't find it anymore), but
  a nice porcelain would be nice.

* What's still on the todo-list

Also, perhaps this could gather the advices "(run git rebase <something>
to <do something>)" currently in the output of "git status", and "git
status may just say "(run git rebase --status for more information)"
instead of 2 or 3 lines of advices.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/