Plan to implement the project.
Objective:
Teach git stash to handle unmerged index entries.
Description:
When the index is unmerged, git stash refuses to do anything. That is
unnecessary, though, as it could easily craft e.g. an octopus merge of
the various stages. A subsequent git stash apply ca
Just had a small discussion on irc about solving
https://git.github.io/SoC-2019-Ideas/#teach-git-stash-to-handle-unmerged-index-entries
the discussion:
https://colabti.org/irclogger/irclogger_log/git-devel?date=2019-04-09
Below are two approaches for solving this problem:
Approach 1) The suggeste
Reference:
https://git.github.io/SoC-2019-Ideas/#teach-git-stash-to-handle-unmerged-index-entries
"When the index is unmerged, git stash refuses to do anything. That is
unnecessary, though, as it could easily craft e.g. an octopus merge of
the various stages. A subsequent git stash apply can dete
while understanding add_index_entry_with_check()
i got to do_invalidate_path().
the commit hash for do_invalidate_path() function is
`749864627c2d3c33bbc56d7ba0b5542af698cc40`
in the commit message it is explained that, cache-tree is used to
store object names of index file objects and it is kept
On Mon, Apr 8, 2019 at 4:02 PM Duy Nguyen wrote:
>
> Sometimes when I don't understand what some code does, I look at "git
> log --patch". In this case, there a big explanation in ad3762042a
> (read-cache: fix directory/file conflict handling in
> read_index_unmerged(), 2018-07-31) that might help
On Mon, Apr 8, 2019 at 12:09 AM Thomas Gummerer wrote:
>
> On 04/07, Kapil Jain wrote:
> >
> > what is the use of ce_stage macro ?
> > tells about stage of an index entry.
> > if ce_stage says, stage #0 i.e staging area, then that index entry is
> > in stag
below is my understanding from reading the parts of code as suggested on IRC.
what is the use of ce_stage macro ?
tells about stage of an index entry.
if ce_stage says, stage #0 i.e staging area, then that index entry is
in staging area
and nothing needs to be done.
else a temporary index entry is
Signed-off-by: Kapil Jain
---
In read-cache, the read_index_from() function had a TODO task,
this patch completes that. There are some other functions in the same file
where this exact TODO needs to be done, will proceed to do them once this patch
is accepted.
running test gave 256 not okays
On Sat, Apr 6, 2019 at 5:49 PM Duy Nguyen wrote:
>
> On Sat, Apr 6, 2019 at 7:14 PM Kapil Jain wrote:
> > > In some cases, it will be simple. For example, if you have a look at
> > > repo_read_index(), it already knows what repo it handles, so you can
> > > just
On Sat, Apr 6, 2019 at 5:33 PM Duy Nguyen wrote:
>
> trace2 API can already take 'struct repository' (the_repository is a
> pointer to 'struct repository'). I'm pretty sure the purpose is to
> _not_ pass the_repository (because it implies the default repo, which
> is not always true). Which means
i found some TODO tasks inside `read-cache.c` in `read_index_from()`
function. which says:
/*
* TODO trace2: replace "the_repository" with the actual repo instance
that is associated with the given "istate".
*/
this same TODO occurs at 4 other places in the same file.
Will it be ok, if i complet
Reference:
https://git.github.io/SoC-2019-Ideas/#unify-ref-filter-formats-with-other---pretty-formats
I have spent some time with both pretty.* and ref-filter.*
First off, we are aiming to reuse ref-filter, so avoiding any sort of
re-implementation is recommended.
Now, coming to pretty.* and re
On Mon, Apr 1, 2019 at 12:19 AM Thomas Gummerer wrote:
>
> If you look at what userformat_find_requirements() does, calls
> strbuf_expand(), which in turn calls userformat_want_item(), which
> fills the 'userformat_want' struct based on the strbuf that has been
> passed.
>
> Now if we look at the
On Fri, Mar 29, 2019 at 7:23 PM Kapil Jain wrote:
>
> On Thu, Mar 28, 2019 at 11:14 PM Olga Telezhnaya
> wrote:
> >
> > Unfortunately, I can't consult you properly about structure of
> > pretty.c. I guess that would be your first task of the internship to
&
On Sat, Mar 30, 2019 at 10:48 PM Philip Oakley wrote:
>
> * Developers rarely want to write documentation (it's too obvious to them)
> -- Our code base has become larger than the average brain-full, maybe
> that (developer education) also could also benefit from some further
> structural documenta
On Thu, Mar 28, 2019 at 11:14 PM Olga Telezhnaya
wrote:
>
> Unfortunately, I can't consult you properly about structure of
> pretty.c. I guess that would be your first task of the internship to
> dive into it and think how to improve it. By the way, you could try to
> make more detailed documentat
On Fri, Mar 29, 2019 at 3:00 AM Thomas Gummerer wrote:
>
>
> I had previously mentioned that this project was attempted already in
> my email at [*1*]. Did you take a look at the thread I linked to
> there, and the regex used? I still feel like that previous experience
> is something you could l
> On Tue, Mar 26, 2019 at 2:48 AM Olga Telezhnaya
> wrote:
>> Kapil Jain wrote:
> > Now, the verify_ref_format function can be used inside
> > get_commit_format function, hence reusing logic.
> > Is this a correct example to work on, for this project ?
>
>
Hi,
Below are some two queries concerning
https://git.github.io/SoC-2019-Ideas/#unify-ref-filter-formats-with-other---pretty-formats
Q1)
In pretty.h & pretty.c:
void get_commit_format(const char *arg, struct rev_info *);
This function Parses given arguments from "arg", checks it for
correctness
On Sun, Mar 24, 2019 at 2:49 PM Christian Couder
wrote:
>
> The test_language_driver() function used to test the regexps is
> ...
> GIT_TEST_CMP which is usually either "diff -u" or "diff -c".
Thanks.
please provide some insights on the regex mentioned below:
+
+PATTERNS("shell",
+ /* Function
Signed-off-by: Kapil Jain
---
The test passes now, but imo the regex is not working,
because the output of git diff with shell regex remains same
as earlier it was without shell regex.
without shell regex the output was shown as:
-$TEST_DIRECTORY
+$TEST_DIR
with shell regex the output should
On Sun, Mar 24, 2019 at 1:34 AM Christian Couder
wrote:
>
> To save some work by people who could help you, it might be a good
> idea to show the output of the failing test, for example the output of
> `./t4034-diff-words.sh -i -v` or `./t4034-diff-words.sh -i -v -x`.
Looks like i just needed to
Signed-off-by: Kapil Jain
---
The test written does not pass, imo there's some problem with the regex part.
please let me know about the fault.
t/t4034-diff-words.sh | 2 ++
t/t4034/shell/expect | 6 ++
t/t4034/shell/post| 1 +
t/t4034/shell/pre | 1 +
userdiff.c
Hi,
for the microproject: creating diff function support for different languages.
i wrote one for shell script, have tested it outside of git and it works fine.
query regarding accommodating the pattern in:
1) userdiff.c, it uses - #define PATTERNS(name, pattern, word_regex),
for defining pattern
On Fri, Mar 8, 2019 at 11:13 PM Jonathan Tan wrote:
> This is indeed a nice feature to have, and thanks for details of how
> this would be accomplished.
>
> One issue is that when cloning a repository, we do not download many
> files - we only download one dynamically generated packfile containing
Objective: Allow pause and resume functionality while cloning repositories.
Below is a rough idea on how this may be achieved.
1) Create a repository_name.json file.
2) repository_name.json will be an index file containing list of all
the files in the repository with default status being "False".
26 matches
Mail list logo
