Hi everyone,
I haven't got any news from you regarding my last mail (see below).
Do you think that you could take a little of your time to answer
some of my questions?
Regards,
Arthur
Le 24/04/2014 11:14, adaussy a écrit :
Hi everyone,
In my previous mail I mentioned that I am working on the
.gitattribute files support (currently, only the "ident" attribute
[2]). I have based my work on the review 1614 [1].
First, I'm trying to understand how to properly access to
attributes from the .gitattributes files. From what I tested on
native cgit, the attributes should be parsed from the repository
content and from the current working tree content. This is the
workflow I have guessed for cgit using git check-attr command. The
following pseudo code demonstrate my understanding of how cgit
looks for attributes for specific path.
For a checkin action:
For each folder in hierarchy
Look in the current folder for .gitattributes file in the
working directory
If file exist : Parse the attributes and
complete current attributes list with matching rules (do not
override existing attributes)
Else if .gitattribute file exists in the
index: Parse the attributes and complete current attributes list
with matching rules (do not override existing attributes)[*]
Look into $Git_Folder/info/attributes file
If file exist: Parse the attributes and
override existing attributes and complete with others [**]
Else nothing
For a checkout action:
For each folder in hierarchy
Look in the current folder for .gitattributes file in the
index
If .gitattribute file exists: Parse the
attributes and complete current attributes list with matching
rules (do not override existing attributes)
Else If .gitattribute file exist in the
working directory : Parse the attributes and complete current
attributes list with matching rules (do not override existing
attributes)
Look into $Git_Folder/info/attributes file
If file exist: Parse the attributes and
override existing attributes and complete with others
Else nothing
Here are the main differences with JGit implementation:
1. I did not find a way to get attributes from a file which is
not present in the working directory (for example deleted by user)
with jgit whereas cgit is able to do so.
2. jgit does not use the index as fallback when the
.gitattributes file is not present in the working directory. [*]
3. $Git_Folder/info/attributes does not override the
attributes define by the .gitattributes. [**]
If you agree that this is the intended behaviour would you mind if
a rework the review 1614 [1] to:
* Add the capability to DirCacheIterator to parse attributes.
This way I would be able to use this iterator as fallback when no
.gitattributes file is present in the working directory.
* Change the precedence of $Git_Folder/info/attributes. The
attributes contained by this file should override any other
attributes.
Is it something that sounds reasonable to you?
Secondly, I'm trying to implements the "ident" attribute with the
following use case:
I have a test repository with a file (ident.txt) containing an
$Id$ pattern. On checkout, the file has to be modified to get a
file in the working directory with $Id:Blob_name$ instead of $Id$.
The inverse has to be done on checkin, i.e., $Id:Blob_Name$ has to
converted to $Id$.
Following the principles of the classes AutoCRLFInputStream and
AutoCRLFOutputStream, I started by implementing an InputStream
that converts $Id:Blob_Name$ to $Id$ on the fly on checkin and an
OutputStream that converts $Id$ to $Id:Blob_Name$ on the fly on
checkout (both streams are able to detect binary files). My
concern is where should I plug those streams in. My first guesses
are:
* On checkout, I’m thinking about the method
DirCacheCheckout#checkoutEntry(Repository, File, DirCacheEntry,
ObjectReader). However from there it's seems quite hard to get
access to attributes (more on this below).
* On checkin, I’m thinking about the method
WorkingTreeIterator#filterClean(InputStream) but still, I'm not
really sure if it is the right place to do such a thing.
Do you think these are the correct locations where I should plug
the new Input/Output streams?
Regarding the method DirCacheCheckout#checkoutEntry, I want to
create a TreeWalk that matches the entry path and get attributes
from it. But I am wondering if creating a TreeWalk for each file I
want to checkout is efficient. Do you have a any idea about that?
The input/output streams are unit tested and work properly. I plug
them into the location I mentioned above and it seems to work
well. Before going any further and mix it with the attributes I
would like to be sure I am heading to the right direction.
Thanks for your help,
Regards,
Arthur Daussy
[1] https://git.eclipse.org/r/#/c/1614/
[2]
https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_description
Le 16/04/2014 08:42, adaussy a écrit :
Great!
First I am going to work on the "ident"[1] attribute since it
seems easier to implement. If the implementation is validated by
the JGit team, I will start working on the "eol"[2] attribute.
Regards,
[1] https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_tt_ident_tt
[2] https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_tt_eol_tt
Le 15/04/2014 12:34, Gunnar
Wagenknecht a écrit :
Hi!
Yes, please do! It should provide full parsing support
for reading Git attributes either from a .gitattributes file
or from the .git storage area. However, it does not do
anything with the obtained information yet. I left that open
to follow up changes.
-Gunnar
Hi Gunnar,
I have rebased this review on my workspace. There are
few trivial conflicts to resolve.
Do you think I can use this review as starting point
for my work on the support of the EOL attribute?
Regards,
Arthur
Le 15/04/2014 10:11,
Gunnar Wagenknecht a écrit :
Hi Arthur,
I think the review needs to be rebased. It
stalled due to missing review activity. I
hesitated committing this one myself without more
feedback from the heavy core JGit committers.
-Gunnar
Hi
everyone,
I would
like to help with the implementation of
the support of the .gitattributes files.
The review https://git.eclipse.org/r/#/c/1614/ seems
to already provide support for the parsing
but looks like to be in a stale state
since last july. How can I help to move
forward with this review?
Once this
review is merged, I plan to work on the
support of the EOL attribute.
Best
regards,
--
Arthur Daussy
Obeo
_______________________________________________
jgit-dev mailing list
jgit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jgit-dev
_______________________________________________
jgit-dev mailing list
jgit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jgit-dev
|
