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
|