git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: Sangeeta NB <sangunb09@gmail.com>, phillip.wood@dunelm.org.uk
Cc: git@vger.kernel.org
Subject: Re: [Outreachy] Introduction
Date: Fri, 9 Oct 2020 19:29:13 +0100	[thread overview]
Message-ID: <7d691f37-b8b7-510d-ba46-51a4a7587226@gmail.com> (raw)
In-Reply-To: <CAHjREB59HjZAs98wMPtMANcHUaXGou7CYg9vAacc3m4uz1yUug@mail.gmail.com>

Hi Sangeeta

On 09/10/2020 08:41, Sangeeta NB wrote:
> Thanks for the explanation, Philips. I think there's a long road ahead
> to understand how everything is implemented and put together.
> 
> Coming to the microproject, it was said that there is an inconsistency
> in --dirty behavior shown by `git diff` and `git describe --dirty` for
> submodule state when the files are untracked.

I struggled to find the mircoprojects page - I must have missed the link 
on the outreachy site. In case anyone else is struggling to find it here 
is the project

     Unify the meaning of -dirty between diff and describe

     git diff reports a submodule directory, whose tracked
     contents match the commit at the HEAD in the submodule, as
     -dirty when there is an untracked file in the submodule
     directory. This is inconsistent with what git describe
     --dirty says when run in the submodule directory in that
     state. [1]

    [1] https://lore.kernel.org/git/xmqqo8m1k542.fsf@gitster.c.googlers.com/

>  From what I understood by looking at the code, the diff files states
> that we should ignore untracked submodule states. So is it that I have
> to make changes in the way git describe is implemented by ignoring the
> changes in the untracked submodule?

As I understand it if a submodule contains any untracked files (i.e. a 
file that has not been added with `git add` and is not ignored by any 
.gitignore or .git/info/exclude entries) then running `git diff` in the 
superproject will report that the submodule is dirty - there will be a 
line something like "+Subproject commit abcdef-dirty". However if we run 
`git describe --dirty` in the submodule directory then it will not 
append "-dirty" to it's output unless there are changes to tracked files.

> Also, I wasn't able to look for this inconsistency in my local
> machine. Any pointers on how to reproduce this might be helpful.

I'd start my trying to build git and running t4027-diff-submodule.sh.
If you look at the start of the test 'git diff HEAD with dirty submodule 
(untracked)' in t/t4027-diff-submodule.sh it sets up a submodule with an 
untracked file. If you add "test_pause &&" after the diff command in 
that test it will start a shell in the test directory and you can run 
`git diff HEAD` yourself  to see the output and also `git -C sub diff 
HEAD` which will run diff in the submodule directory. The latter command 
should show that there are no changes in the tracked files of the 
submodule. Just exit the shell to get the test to continue. (you can see 
in builtin/describe.c that when it is run with `--dirty` it runs `git 
diff-index HEAD` to determine if a repository is dirty). To change the 
output of diff I would look for the string "Subproject commit" in diff.c 
to find the code that adds '-dirty' and try working backwards from 
there. Let me know if you get stuck - it took we a while to work 
backwards to find where we check if the submodule is dirty.

Best Wishes

Phillip


> Thanks and regards,
> 
> Sangeeta
> 
> On Thu, Oct 8, 2020 at 2:37 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
>>
>> Hi Sangeeta
>>
>> On 07/10/2020 21:10, Sangeeta NB wrote:
>>> Hello everyone,
>>
>> Welcome to the list
>>
>>> My name is Sangeeta and I’m one of the Outreachy applicants.  I would
>>> like to work on the microproject "Unify the meaning of dirty between
>>> diff and describe".
>>>
>>> While looking at the files for `describe` and `diff` commands I found
>>> that the `describe.c`  is present in builtin[1] folder whereas diff.c
>>> is found in the root[2] folder as well as builtin[3] folder. I could
>>> not find any implementation of --dirty in the diff.c present in
>>> builtin[3] folder. So is it that I have to compare the implementation
>>> of describe.c[1] and diff.c(of root folder)?
>>>
>>> Also, I was curious to know why is there a builtin folder when many
>>> commands described in that are described again in the root folder?
>>
>> The files in the root directory are (mostly) library code that ends up
>> in libgit.a. The builtin directory contains the individual git commands
>> that form the git binary that is linked with libgit.a. builtin/diff.c
>> contains cmd_diff() which will be called when the user runs `git diff`.
>> That function parses the command line options and sets up the necessary
>> data to pass to the diff implementation in /diff.c. The diff and log
>> family of commands are a bit different to most of the other commands in
>> that the option parsing is mostly done by calling setup_revisions() in
>> /revision.c rather than using the option parsing library routines in
>> /parse-options.c directly. I think the `--dirty` option for diff ends up
>> being handled by handle_ignore_submodules_arg() in submodule.c, I'll
>> leave it to you to see where that is called from (you can use `git grep`).
>>
>> I'm going to be off line for the rest of today, hopefully someone else
>> will be able to help if you get stuck or I'll try and answer any other
>> questions tomorrow.
>>
>> Best Wishes
>>
>> Phillip
>>
>>> Looking forward to working with you all.
>>>
>>> Sangeeta
>>> [1] https://github.com/git/git/blob/master/builtin/describe.c
>>> [2] https://github.com/git/git/blob/master/builtin/diff.c
>>> [3] https://github.com/git/git/blob/master/diff.c
>>>

  reply	other threads:[~2020-10-09 18:29 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 20:10 [Outreachy] Introduction Sangeeta NB
2020-10-08  9:07 ` Phillip Wood
2020-10-09  7:41   ` Sangeeta NB
2020-10-09 18:29     ` Phillip Wood [this message]
2020-10-11 11:30       ` Sangeeta NB
2020-10-12 10:18         ` Phillip Wood
2020-10-12 11:22         ` Kaartic Sivaraam
2020-10-12 15:57         ` Junio C Hamano
2020-10-14 15:52           ` Sangeeta NB
2020-10-15  9:23             ` Phillip Wood
2020-10-15  9:26               ` [PATCH] fixup! diff: do not show submodule with untracked files as "-dirty" Phillip Wood
2020-10-15 10:18               ` [Outreachy] Introduction Sangeeta NB
2020-10-15 13:39                 ` Phillip Wood
2020-10-15 13:57                   ` Sangeeta NB
2020-10-15 14:45                     ` Phillip Wood
2020-10-16  5:27                       ` Sangeeta NB
2020-10-16 13:26                         ` Phillip Wood
  -- strict thread matches above, loose matches on Subject: below --
2020-10-10 11:48 Charvi Mendiratta
2020-10-11  8:09 ` Christian Couder
     [not found]   ` <CAPSFM5cXN57z56Cvq-NX1H4raS7d8=qXEFDQqpypJfoYzbxcyA@mail.gmail.com>
2020-10-15 18:56     ` Charvi Mendiratta
2020-10-15 19:16       ` Junio C Hamano
2020-10-17  8:09         ` Charvi Mendiratta
2020-10-16  8:28 Zodwa Phakathi
2020-10-16  8:46 ` Christian Couder
     [not found]   ` <CAGdqGXrLN2W_CgqfmfkCSu_hmZ9Ze8A1N9n08bgPRPApSMraSQ@mail.gmail.com>
2020-10-16 10:02     ` Christian Couder
2020-10-16 22:09 Joey S
2020-10-16 23:08 ` Jonathan Nieder
2020-10-17  0:42   ` Joey S

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7d691f37-b8b7-510d-ba46-51a4a7587226@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=sangunb09@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).