* whitespace-stripping
From: J. Bruce Fields @ 2007-09-16 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The following patches fix one (probably rare) bug in
git apply --whitespace=strip
and then teach it to also complain about initial consecutive spaces that
could be tabs.
The latter is the standard for the kernel, but may not be appropriate
for other projects. I'd like to make the whitespace code handle the
kernel style completely first, then consider configuration to handle
other styles if people complain. But maybe the change of behavior would
be an unpleasant surprise for someone with apply.whitespace=strip and a
project that always uses spaces for indents.
--b.
^ permalink raw reply
* Re: metastore
From: david @ 2007-09-16 22:37 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Junio C Hamano, Johannes Schindelin, martin f krafft, git,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <Pine.LNX.4.64.0709161715090.5298@iabervon.org>
On Sun, 16 Sep 2007, Daniel Barkalow wrote:
> On Sun, 16 Sep 2007, david@lang.hm wrote:
>
>> On Sun, 16 Sep 2007, Daniel Barkalow wrote:
>>
>>>> I however think your idea to have extra "permission information
>>>> file" is very interesting. What would be more palatable, than
>>>> mucking with the core level git, would be to have an external
>>>> command that takes two tree object names that tells it what the
>>>> old and new trees our work tree is switching between, and have
>>>> that command to:
>>>>
>>>> - inspect the diff-tree output to find out what were checked
>>>> out and might need their permission information tweaked;
>>>>
>>>> - inspect the differences between the "permission information
>>>> file" in these trees to find out what were _not_ checked out,
>>>> but still need their permission information tweaked.
>>>>
>>>> - tweak whatever external information you are interested in
>>>> expressing in your "permission information file" in the work
>>>> tree for the paths it discovered in the above two steps.
>>>> This step may involve actions specific to projects and call
>>>> hook scripts with <path, info from "permission information
>>>> file" for that path> tuples to carry out the actual tweaking.
>>>
>>> Why not have the command also responsible for creating the files that need
>>> to be created (calling back into git to read their contents)? That way,
>>> there's no window where they've been created without their metadata, and
>>> there's more that the core git doesn't have to worry about.
>>
>> my initial thoughts were to have git do all it's normal work and hook into git
>> at the point where it's writing the file out (where today it chooses between
>> writing the data to a file on disk, pipeing to stdout, or pipeing to a pager)
>> by adding the option to pipe into a different program that would deal with the
>> permission stuff. this program would only have to write the file and set the
>> permissions, it wouldn't have to know anything about git other then where to
>> find the permissions it needs to know.
>>
>> it sounds like you are suggesting that the hook be much earlier in the
>> process, and instead of one copy of git running and calling many copies of the
>> writing program, you would have one copy of the writing program that would
>> call many copies of git.
>
> A lot of the git commands are actually currently shell scripts that call
> back to git, so that's not too different. The reason to have a single copy
> of the writing program is that it would be able to get the whole set of
> differences that need to be handled, and first pick out the metadata file,
> process it to figure out the writing instructions once, figure out the
> changes in the writing instructions, and figure out the changes in the
> content, and decide what to do.
I'm still a little unclear on how much work this program would then have
to do. it's problably my lack of understanding that's makeing this sound
much scarier.
>>> I could see the program getting the index, the target tree, and the
>>> directory to put files in, and being told to do the whole 2-way merge
>>> (except, perhaps, updating the index to match the tree, which git could do
>>> afterwards). As far as git would be concerned, it would mostly be like a
>>> bare repository.
>>
>> if this functionality does shift to earlier in the process, how much of the
>> git logic needs to be duplicated in this program?
>>
>> if this program needs to do the merge, won't it have to duplicate the merge
>> logic, including the .gitattributes checking for custom merge calls?
>
> This is two-way merge, not three-way merge. The basic concept is that
> you're in state A, and you want to be in state B. Rather than writing out
> all of state B, you write out all of state B that's different from state
> A. Think of taking a diff of two big trees and then applying it as a
> patch, instead of copying the new tree onto the old tree; the benefit is
> that stuff that doesn't change doesn't get rewritten, and the diff is
> blazingly fast, given how we store our information.
so what would this program be given?
it sounds like it would be called once for the entire tree checkout
would it be handed just the start and end commits and query git for
everything else it needs?
it sounds like there is more then this, you refer to git fully crafting
the new index.
so would this program be accessing an old and new index and do the
comparison between the two?
or would git feed it a list of what's changed and then have it query git
to find the details of the changes.
> 3-way merge will be handled by git, and not in a live /etc directory
> anyway (that is, you'd want to fix up the metadata files as plain text
> files, not as metadata bits on a checked out directory; otherwise, you'll
> be trying to put conflict markers in mode bits, and that's clearly not
> what you want).
right, we don't want conflict markers on mode bits or other ACL type
things, that way lies madness ;)
>> I have been thinking primarily in terms of doing a complete checkout,
>> overwriting all files, and secondarily how do do a checkout of just a few
>> files, but again where all files selected overwrite the existing files.
>>
>> I wasn't thinking of the fact that git optimizes the checkout and avoids
>> writing a file that didn't change.
>>
>> this changes things slightly
>>
>> prior to this I was thinking that the permission file needed to be handled
>> differently becouse writing it out needed to avoid doing any circular
>> refrences where you would need to check the contents of it to write it out.
>>
>> it now appears as if what really needs to happen is that if the permission
>> file changes a different program needs to be called when it's written out then
>> when the other files are written out. by itself this isn't hard as
>> .gitattributes can have a special entry for this filename and that entry can
>> specify a different program, and that program fixes all the permissions
>> (and/or detects that they can't be fixed due to user/filesystem limits,
>> records the error, checks if the repository is set appropriately, and screams
>> to the user if it isn't)
>
> While we're at it, you probably don't even want to write the permission
> file to the live filesystem. It's just one more thing that could leak
> information, and changes to the permissions of files that you record by
> committing the live filesystem would presumably be done by changing the
> permissions of files in the filesystem, not by changing the text file.
the permissions and ACL's can be queried directly from the filesystem, so
I don't see any security problems with writing the permission file to the
filesystem.
changing the permissions would be done by changing the files themselves
(when you are running as root on a filesystem that supports the changes,
otherwise it would need to fall back to writing the file and getting the
changes there, but that should be able to be a local config option)
I don't like the idea of having a file that doesn't appear on the local
filesystem at any point, it just makes troubleshooting too hard.
> (Of course, you could check out the same commits as ordinary source, with
> developer-owned 644 files and a 644 "permissions" file, and there you'd
> have the permissions file appear in the work tree, and you could edit it
> and check it in in a totally mundane way.)
right, and the same thing if the filesystem doesn't support something in
the permission file.
>> it would be a nice optimization to this permission checkout for it to compare
>> the old and the new permissions so that it only tries to change the
>> permissions where it needs to, but is that really nessasary? the program can
>> look at the permissions of the existing files to see what they are and decide
>> if it needs to change them (this would tromp on local changes that aren't
>> checked in. how big of a problem is this?) my initial reaction is that having
>> to know the two commits and do the comparison between them is adding a lot of
>> logic and git interaction that I'd rather avoid if I could.
>
> You probably want to be able to keep local uncommitted changes. People
> like to be able to have things slightly different in their particular
> deployment from the way things are in the repository, for stuff that only
> applies to one system and isn't "how it should be".
if so this means that the permission changing program definantly needs to
operate on the diff of the permisison file, not on the absolute file. this
complicates things slightly, but it shouldn't be too bad.
changing topic slightly.
I know git has pre-commit hooks, but I've never needed to use them.
at what point can you hook in?
can you define a hook that runs when you do a git-add? or only when you do
a git-commit?
the reason I'm asking is to try and figure out when and how to create the
permissions file. when I was thinking in terms of dealing with the
permissions as a single bog block it wasn't that bad to say that at
git-commit time you have to scan every file and check it's permissions to
record them into the file, but with the push for the optimizations that
you're talking about this is no longer reasonable and it really should be
done when the file is added to the index.
on a related note, if this is implemented as a per-write hook then it
makes a lot of sense to have the permission file be per-directory, but if
we do a per-checkout hook like you are suggesting then the permission file
may make more sense as a single file in the top-level directory.
thoughts?
David Lang
^ permalink raw reply
* Re: metastore
From: Junio C Hamano @ 2007-09-16 22:11 UTC (permalink / raw)
To: david
Cc: Johannes Schindelin, Daniel Barkalow, martin f krafft, git,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <Pine.LNX.4.64.0709161245490.24221@asgard.lang.hm>
david@lang.hm writes:
>> I'd rather not implement it at such a low level where a true
>> "checkout" happens. For one thing, I am afraid that the special
>> casing will affect the normal codepath too much and would make
>> it into a maintenance nightmare.
>
> as I understand it, at this point you already choose between three
> options.
>
> 1. write to a file (and set the write bit if needed)
> 2. write to stdout
> 3. write to a pager program
>
> I am suggesting adding
> ...
> or am I missing something major here?
I do not think we are choosing any option in the codepath at
all.
What I mean by the normal "checkout" is what checkout_entry in
entry.c does. There is no other option than (1) above. I would
want to see an extremely good justification if you need to touch
that codepath to implement this fringe use case.
I do not think there is nothing that writes file contents to
stdout/pager other than "git cat-file" or "git show"; I do not
think they are what you have in mind when talking about managing
the files under /etc. So unfortunately I do not understand the
rest of the discussion you made in your message.
^ permalink raw reply
* Re: metastore
From: Daniel Barkalow @ 2007-09-16 22:02 UTC (permalink / raw)
To: david
Cc: Junio C Hamano, Johannes Schindelin, martin f krafft, git,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <Pine.LNX.4.64.0709161346150.24221@asgard.lang.hm>
On Sun, 16 Sep 2007, david@lang.hm wrote:
> On Sun, 16 Sep 2007, Daniel Barkalow wrote:
>
> > > I however think your idea to have extra "permission information
> > > file" is very interesting. What would be more palatable, than
> > > mucking with the core level git, would be to have an external
> > > command that takes two tree object names that tells it what the
> > > old and new trees our work tree is switching between, and have
> > > that command to:
> > >
> > > - inspect the diff-tree output to find out what were checked
> > > out and might need their permission information tweaked;
> > >
> > > - inspect the differences between the "permission information
> > > file" in these trees to find out what were _not_ checked out,
> > > but still need their permission information tweaked.
> > >
> > > - tweak whatever external information you are interested in
> > > expressing in your "permission information file" in the work
> > > tree for the paths it discovered in the above two steps.
> > > This step may involve actions specific to projects and call
> > > hook scripts with <path, info from "permission information
> > > file" for that path> tuples to carry out the actual tweaking.
> >
> > Why not have the command also responsible for creating the files that need
> > to be created (calling back into git to read their contents)? That way,
> > there's no window where they've been created without their metadata, and
> > there's more that the core git doesn't have to worry about.
>
> my initial thoughts were to have git do all it's normal work and hook into git
> at the point where it's writing the file out (where today it chooses between
> writing the data to a file on disk, pipeing to stdout, or pipeing to a pager)
> by adding the option to pipe into a different program that would deal with the
> permission stuff. this program would only have to write the file and set the
> permissions, it wouldn't have to know anything about git other then where to
> find the permissions it needs to know.
>
> it sounds like you are suggesting that the hook be much earlier in the
> process, and instead of one copy of git running and calling many copies of the
> writing program, you would have one copy of the writing program that would
> call many copies of git.
A lot of the git commands are actually currently shell scripts that call
back to git, so that's not too different. The reason to have a single copy
of the writing program is that it would be able to get the whole set of
differences that need to be handled, and first pick out the metadata file,
process it to figure out the writing instructions once, figure out the
changes in the writing instructions, and figure out the changes in the
content, and decide what to do.
> > I could see the program getting the index, the target tree, and the
> > directory to put files in, and being told to do the whole 2-way merge
> > (except, perhaps, updating the index to match the tree, which git could do
> > afterwards). As far as git would be concerned, it would mostly be like a
> > bare repository.
>
> if this functionality does shift to earlier in the process, how much of the
> git logic needs to be duplicated in this program?
>
> if this program needs to do the merge, won't it have to duplicate the merge
> logic, including the .gitattributes checking for custom merge calls?
This is two-way merge, not three-way merge. The basic concept is that
you're in state A, and you want to be in state B. Rather than writing out
all of state B, you write out all of state B that's different from state
A. Think of taking a diff of two big trees and then applying it as a
patch, instead of copying the new tree onto the old tree; the benefit is
that stuff that doesn't change doesn't get rewritten, and the diff is
blazingly fast, given how we store our information.
3-way merge will be handled by git, and not in a live /etc directory
anyway (that is, you'd want to fix up the metadata files as plain text
files, not as metadata bits on a checked out directory; otherwise, you'll
be trying to put conflict markers in mode bits, and that's clearly not
what you want).
> I have been thinking primarily in terms of doing a complete checkout,
> overwriting all files, and secondarily how do do a checkout of just a few
> files, but again where all files selected overwrite the existing files.
>
> I wasn't thinking of the fact that git optimizes the checkout and avoids
> writing a file that didn't change.
>
> this changes things slightly
>
> prior to this I was thinking that the permission file needed to be handled
> differently becouse writing it out needed to avoid doing any circular
> refrences where you would need to check the contents of it to write it out.
>
> it now appears as if what really needs to happen is that if the permission
> file changes a different program needs to be called when it's written out then
> when the other files are written out. by itself this isn't hard as
> .gitattributes can have a special entry for this filename and that entry can
> specify a different program, and that program fixes all the permissions
> (and/or detects that they can't be fixed due to user/filesystem limits,
> records the error, checks if the repository is set appropriately, and screams
> to the user if it isn't)
While we're at it, you probably don't even want to write the permission
file to the live filesystem. It's just one more thing that could leak
information, and changes to the permissions of files that you record by
committing the live filesystem would presumably be done by changing the
permissions of files in the filesystem, not by changing the text file.
(Of course, you could check out the same commits as ordinary source, with
developer-owned 644 files and a 644 "permissions" file, and there you'd
have the permissions file appear in the work tree, and you could edit it
and check it in in a totally mundane way.)
> it would be a nice optimization to this permission checkout for it to compare
> the old and the new permissions so that it only tries to change the
> permissions where it needs to, but is that really nessasary? the program can
> look at the permissions of the existing files to see what they are and decide
> if it needs to change them (this would tromp on local changes that aren't
> checked in. how big of a problem is this?) my initial reaction is that having
> to know the two commits and do the comparison between them is adding a lot of
> logic and git interaction that I'd rather avoid if I could.
You probably want to be able to keep local uncommitted changes. People
like to be able to have things slightly different in their particular
deployment from the way things are in the repository, for stuff that only
applies to one system and isn't "how it should be".
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: metastore
From: david @ 2007-09-16 21:53 UTC (permalink / raw)
To: Junio C Hamano
Cc: Daniel Barkalow, Johannes Schindelin, martin f krafft, git,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <7vbqc25mgi.fsf@gitster.siamese.dyndns.org>
On Sun, 16 Sep 2007, Junio C Hamano wrote:
> david@lang.hm writes:
>
>> my initial thoughts were to have git do all it's normal work and hook
>> into git at the point where it's writing the file out (where today it
>> chooses between writing the data to a file on disk, pipeing to stdout,
>> or pipeing to a pager) by adding the option to pipe into a different
>> program that would deal with the permission stuff. this program would
>> only have to write the file and set the permissions, it wouldn't have
>> to know anything about git other then where to find the permissions it
>> needs to know.
>>
>> it sounds like you are suggesting that the hook be much earlier in the
>> process,...
>
> Well, you misread me or what I said was confusing or both. I
> was suggesting totally opposite. Let git do all its normal
> work, and then call your hook to munge the work tree in any way
> you want.
so you are saying, have git write everything out as-is and then call a
program afterwords to do things? essentially a post-checkout hook?
such a hook is useful in many situations, and would allow for the workflow
where you have /etc, /etc.git, and write scripts to move things back and
forth between them.
so I do think that this is a capability that would be useful to git
overall.
however, for the specific use-case of maintaining /etc I don't think that
it's as good as having a hook at write time.
David Lang
^ permalink raw reply
* Re: metastore
From: david @ 2007-09-16 21:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Daniel Barkalow, martin f krafft, git,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <7vwsur590q.fsf@gitster.siamese.dyndns.org>
some of this duplicates thoughts from other messages in this thread.
apologies for the duplication, but I want to be clear the response to
Junio's concerns here as well
On Sun, 16 Sep 2007, Junio C Hamano wrote:
> david@lang.hm writes:
>
>> git has pre-commit hooks that could be used to gather the permission
>> information and store it into a file.
>>
>> git now has the ability to define cusom merge strategies for specific
>> file types, which could be used to handle merges for the permission
>> files.
>> ...
>> There are some significant advantages of having the permission store
>> be just a text file.
>>
>> 1. it doesn't require a special API to a new datastore in git
>>
>> 2. when working in an environment that doesn't allow for implementing the
>> permissions (either a filesystem that can't store the permissions or
>> when not working as root so that you can't set the ownership) the file
>> can just be written and then edited with normal tools.
>>
>> 3. normal merge tools do a reasonable job of merging them.
>>
>> however to do this git would need to gain the ability to say 'this
>> filename is special, it must be checked out before any other file is
>> checked out' (either on a per-directory or per-repository level)
>
> I'd rather not implement it at such a low level where a true
> "checkout" happens. For one thing, I am afraid that the special
> casing will affect the normal codepath too much and would make
> it into a maintenance nightmare.
as I understand it, at this point you already choose between three
options.
1. write to a file (and set the write bit if needed)
2. write to stdout
3. write to a pager program
I am suggesting adding
4. write to a .gitattributes defined program and pass it some parameters.
(and only if the .gitattributes tell you to)
this should be a very small change to the codepath
or am I missing something major here?
if this program can get the contents of the permission file out of the
index, then the requirement I listed before to make sure the permission
file gets written before anything else goes away, and the only requirement
left is the ability to specify a different write method
> But more importantly, if you
> are switching between commits (this includes switching branches,
> checking out a different commit to a detached HEAD, or
> pulling/merging updates your HEAD and updates your work tree),
> and the contents of a path does not change between the original
> commit and the switched-to commit, you may still have to
> "checkout" the external information for that path if your
> "permission information file" are different between these two
> commits. To the underlying checkout aka "two tree merge"
> operation, that kind of change is invisible and it should stay
> so for performance reasons, not to harm the normal operation.
I had not thought of this condition.
however, I think this may be easier then you are thinking
we have two conditions.
1. the permission file hasn't changed.
Solution: do nothing
2. the permission file has changed
Solution: set all the permissions to match the new file
this could be done by useing .gitattributes to specify a different program
for checking out the permission file, and that program goes through the
file and sets the permssions on everything. yes this is a bit inefficiant
compared to diffing the two permission files and only touching the files
that have changed, but is the efficiancy at this point that critical? if
so then instead of feeding the program the contents of the new file you
could feed it the diff between the old and the new file.
in theory you could do this for any file, and it would be a win for some
files (a large file that has a few changes to it would possibly be more
efficiant to modify in place then to re-write), but I'm not sure the
results would be worth the complications. if .gitattributes gains the
ability to specify the program to be used to write the file, it could also
gain the ability to specify feeding that file the diff instead of the full
contents.
the one drawback to just setting all the permissions is that this will
overrule any local changes to files that weren't otherwise modified. how
big of a problem is this?
> IOW, I do not want the core level to even know about the
> existence of "permission information file", even the code that
> implements it is well isolated, ifdefed out or made conditional
> based on some config variable.
nobody is suggesting anything that wouldn't be at least conditional based
on some config variable.
> I however think your idea to have extra "permission information
> file" is very interesting. What would be more palatable, than
> mucking with the core level git, would be to have an external
> command that takes two tree object names that tells it what the
> old and new trees our work tree is switching between, and have
> that command to:
>
> - inspect the diff-tree output to find out what were checked
> out and might need their permission information tweaked;
>
> - inspect the differences between the "permission information
> file" in these trees to find out what were _not_ checked out,
> but still need their permission information tweaked.
>
> - tweak whatever external information you are interested in
> expressing in your "permission information file" in the work
> tree for the paths it discovered in the above two steps.
> This step may involve actions specific to projects and call
> hook scripts with <path, info from "permission information
> file" for that path> tuples to carry out the actual tweaking.
this is an area I wasn't aware of, but it doesn't seem that difficult to
do. the issue (as I address above) is if this needs to be done as a diff
or if it can be done simply by setting all the permissions according to
the new file.
> If we go that route, I am not deeply opposed to add code to
> Porcelains to call that new command after they "checkout" a new
> commit at the very end of their processing (namely, git-commit,
> git-merge, git-am, and git-rebase).
this is saying you want a wrapper around git instead of a hook in git.
> Yes, I am very well aware that somebody already mentioned "there
> is a window between the true checkout and permission tweaking".
> If you need to touch the core level in order to close that
> window, I am not interested.
no matter how small the change? (see the above comments) If so this
converstion isn't worth continuing, if you are just concerned about
maintainability and are willing to consider small changes that won't cause
big maintinance problems then we can continue to discuss if the changes I
am suggesting are small enough. the need to be able to close the
vunerability window is a showstopper to many uses.
>> The ability to handle /etc comes up every few months. it's got to be
>> the most common unimplemented request git has seen.
>
> Asking a pony for many times does not necessary make it the
> right for you to have the pony. The sane way to implement this
> is in your Makefile, as Randal and other people with more
> experience have already pointed out, and I happen to agree with
> them.
you don't always have a makefile. if other tools that you use make
modifications to the files in the locations where they reside, having to
pull those changes back before you can do a checking is a complication as
well
> My gut feeling is that the approach to use an external hook that
> reads your "permission information file" could be done with
> negligible impact to the normal operation of git. I suspect
> that the "new command" I suggested above that would run after
> "checkout" actions would perform what people need to do in their
> Makefiles' "install" rules (if they have the work tree vs target
> tree distinction), or "post-checkout" rules (if they want to use
> the work tree in-place), and not having to write/reinvent a
> Makefile target for this in every project would hopefully make
> it easier to use. That is the only reason I am writing this
> message on this topic.
but you are not willing to allow the hook to be created, you are saying
that there would need to be an external wrapper instead.
at this point it appears that having a hook to be able to specify external
programs at a point where you are already deciding between different
options would be sufficiant.
>> so would changes like this be acceptable?
>
> That is a different question. Is having an extention to help
> people who want to manage perm bits a worthy goal? Perhaps, but
> it depends. Is it worthy enough goal to complicate the really
> core parts of the code and add huge maintenance burden?
> Absolutely not. Can it be made in such a way that it does not
> have much impact to the core parts? We need to see how it is
> done.
this is why I was asking about this approach. do changes like this seem
small enough to be worth the effort of coding and submitting?
David Lang
^ permalink raw reply
* Re: metastore
From: Daniel Barkalow @ 2007-09-16 21:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: david, Johannes Schindelin, martin f krafft, git,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <7vbqc25mgi.fsf@gitster.siamese.dyndns.org>
On Sun, 16 Sep 2007, Junio C Hamano wrote:
> david@lang.hm writes:
>
> > my initial thoughts were to have git do all it's normal work and hook
> > into git at the point where it's writing the file out (where today it
> > chooses between writing the data to a file on disk, pipeing to stdout,
> > or pipeing to a pager) by adding the option to pipe into a different
> > program that would deal with the permission stuff. this program would
> > only have to write the file and set the permissions, it wouldn't have
> > to know anything about git other then where to find the permissions it
> > needs to know.
> >
> > it sounds like you are suggesting that the hook be much earlier in the
> > process,...
>
> Well, you misread me or what I said was confusing or both. I
> was suggesting totally opposite. Let git do all its normal
> work, and then call your hook to munge the work tree in any way
> you want.
I think he was replying to me, not you. I was suggesting that git stop at
the index, and let him take care of deciding how the index relates to the
work tree. That is, he'd get called instead of check_updates() in
unpack-trees. (And we might have to funnel more code paths through this
function, so that checkout-index does what read-tree -m would do, wrt
changes to the filesystem).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch
From: Jon Smirl @ 2007-09-16 21:41 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20070915232252.GA25507@diana.vm.bytemark.co.uk>
On 9/15/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-09-14 12:18:17 -0400, Jon Smirl wrote:
> > Another way to handle this would be to eliminate the ability of
> > pop/push to reorder and extend sink/float to handle unapplied
> > patches.
>
> I think that I'd like the latter without the former -- that is,
> teaching sink/float how to handle unapplied patches, and leaving
> push/pop as is. That'll let you do what you tried to do in the first
> place, and will leave us with a more redundant command set, but I
> don't think that's bad.
The stack model may be too simplistic. My current patches involve four
groups, there is ordering in the group but the groups can be applied
independently. Patches could be marked as depending on another
patch/group. You could then mark patches applied/unapplied and stg
would sort out the order. Allowing group names would make this easier.
The mm kernel has 1,500 patches. It must be a pain trying to keep
these in a linear order.
The git diff output format could be extended with
Depends-on/Group-name lines. That would let Andrew import the
dependencies.
> Another idea that's been kicked around is to have a general reorder
> command, that spawns an editor and lets you move around (and delete)
> patch names until you're satisfied. (This too would be implemented in
> terms of push and pop of single patches.)
>
> --
> Karl Hasselström, kha@treskal.com
> www.treskal.com/kalle
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: RFC: German translation vocabulary
From: David Kastrup @ 2007-09-16 21:37 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87y7f6fjjl.fsf@mid.deneb.enyo.de>
Florian Weimer <fw@deneb.enyo.de> writes:
>> commit [noun]
>> commit [verb]
>
> "Sammlung" and "sammeln".
Doesn't fit because "sammeln" is what you do _before_ committing.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: RFC: German translation vocabulary
From: David Kastrup @ 2007-09-16 21:36 UTC (permalink / raw)
To: Simon Richter; +Cc: Christian Stimming, git
In-Reply-To: <46ED8789.4010208@hogyros.de>
Simon Richter <Simon.Richter@hogyros.de> writes:
> Hallo,
>
> Christian Stimming wrote:
>
>> repository - Projektarchiv
>
> Just "Archiv" would be fine as well in most places, I think.
Agreed.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: RFC: German translation vocabulary
From: David Kastrup @ 2007-09-16 21:34 UTC (permalink / raw)
To: Alexander Wuerstlein; +Cc: git
In-Reply-To: <20070916172341.GA17021@cip.informatik.uni-erlangen.de>
Alexander Wuerstlein <snalwuer@cip.informatik.uni-erlangen.de> writes:
> On 070916 14:46, Christian Stimming <stimming@tuhh.de> wrote:
>> msgid "commit [noun]"
>> msgstr "?bertragung (Sendung?, ?bergabe?, Einspielung?, Ablagevorgang?)"
>
> "Vorgang"? (think Beamtendeutsch)
Buchung, Einbuchung, Verbuchung, Registrierung?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: metastore
From: Junio C Hamano @ 2007-09-16 21:28 UTC (permalink / raw)
To: david
Cc: Daniel Barkalow, Johannes Schindelin, martin f krafft, git,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <Pine.LNX.4.64.0709161346150.24221@asgard.lang.hm>
david@lang.hm writes:
> my initial thoughts were to have git do all it's normal work and hook
> into git at the point where it's writing the file out (where today it
> chooses between writing the data to a file on disk, pipeing to stdout,
> or pipeing to a pager) by adding the option to pipe into a different
> program that would deal with the permission stuff. this program would
> only have to write the file and set the permissions, it wouldn't have
> to know anything about git other then where to find the permissions it
> needs to know.
>
> it sounds like you are suggesting that the hook be much earlier in the
> process,...
Well, you misread me or what I said was confusing or both. I
was suggesting totally opposite. Let git do all its normal
work, and then call your hook to munge the work tree in any way
you want.
^ permalink raw reply
* Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch
From: David Kågedal @ 2007-09-16 21:20 UTC (permalink / raw)
To: git
In-Reply-To: <20070915232252.GA25507@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> Another idea that's been kicked around is to have a general reorder
> command, that spawns an editor and lets you move around (and delete)
> patch names until you're satisfied. (This too would be implemented in
> terms of push and pop of single patches.)
This of course sounds very much like "git rebase -i", but the
semantics would maybe not be identical.
One feature from rebase I'd like to see if this was implemented is the
"squash" option to join two patches. But it would probably be called
"fold" to keep with stgit terminology.
Another way of doing this editing is to do it interactively,
interacting with the patches directly using a UI, such as an Emacs
editing mode, or a custom text or graphical UI. As you might guess,
I've been thinking a little of an Emacs interface, but nothing has
been written yet.
--
David Kågedal
^ permalink raw reply
* Re: metastore
From: david @ 2007-09-16 21:12 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Junio C Hamano, Johannes Schindelin, martin f krafft, git,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <Pine.LNX.4.64.0709161054380.5298@iabervon.org>
On Sun, 16 Sep 2007, Daniel Barkalow wrote:
>> I however think your idea to have extra "permission information
>> file" is very interesting. What would be more palatable, than
>> mucking with the core level git, would be to have an external
>> command that takes two tree object names that tells it what the
>> old and new trees our work tree is switching between, and have
>> that command to:
>>
>> - inspect the diff-tree output to find out what were checked
>> out and might need their permission information tweaked;
>>
>> - inspect the differences between the "permission information
>> file" in these trees to find out what were _not_ checked out,
>> but still need their permission information tweaked.
>>
>> - tweak whatever external information you are interested in
>> expressing in your "permission information file" in the work
>> tree for the paths it discovered in the above two steps.
>> This step may involve actions specific to projects and call
>> hook scripts with <path, info from "permission information
>> file" for that path> tuples to carry out the actual tweaking.
>
> Why not have the command also responsible for creating the files that need
> to be created (calling back into git to read their contents)? That way,
> there's no window where they've been created without their metadata, and
> there's more that the core git doesn't have to worry about.
my initial thoughts were to have git do all it's normal work and hook into
git at the point where it's writing the file out (where today it chooses
between writing the data to a file on disk, pipeing to stdout, or pipeing
to a pager) by adding the option to pipe into a different program that
would deal with the permission stuff. this program would only have to
write the file and set the permissions, it wouldn't have to know anything
about git other then where to find the permissions it needs to know.
it sounds like you are suggesting that the hook be much earlier in the
process, and instead of one copy of git running and calling many copies of
the writing program, you would have one copy of the writing program that
would call many copies of git.
I'll admit that my initial reaction is that it's probably a lot more
expensive to do all the calls into git. git just has a lot more complex
things to do.
> I could see the program getting the index, the target tree, and the
> directory to put files in, and being told to do the whole 2-way merge
> (except, perhaps, updating the index to match the tree, which git could do
> afterwards). As far as git would be concerned, it would mostly be like a
> bare repository.
if this functionality does shift to earlier in the process, how much of
the git logic needs to be duplicated in this program?
if this program needs to do the merge, won't it have to duplicate the
merge logic, including the .gitattributes checking for custom merge calls?
I have been thinking primarily in terms of doing a complete checkout,
overwriting all files, and secondarily how do do a checkout of just a few
files, but again where all files selected overwrite the existing files.
I wasn't thinking of the fact that git optimizes the checkout and avoids
writing a file that didn't change.
this changes things slightly
prior to this I was thinking that the permission file needed to be handled
differently becouse writing it out needed to avoid doing any circular
refrences where you would need to check the contents of it to write it
out.
it now appears as if what really needs to happen is that if the permission
file changes a different program needs to be called when it's written out
then when the other files are written out. by itself this isn't hard as
.gitattributes can have a special entry for this filename and that entry
can specify a different program, and that program fixes all the
permissions (and/or detects that they can't be fixed due to
user/filesystem limits, records the error, checks if the repository is set
appropriately, and screams to the user if it isn't)
it would be a nice optimization to this permission checkout for it to
compare the old and the new permissions so that it only tries to change
the permissions where it needs to, but is that really nessasary? the
program can look at the permissions of the existing files to see what they
are and decide if it needs to change them (this would tromp on local
changes that aren't checked in. how big of a problem is this?) my initial
reaction is that having to know the two commits and do the comparison
between them is adding a lot of logic and git interaction that I'd rather
avoid if I could.
David Lang
^ permalink raw reply
* Re: [PATCH] New strbuf APIs: splice and attach.
From: Pierre Habouzit @ 2007-09-16 20:51 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <874phugy6h.fsf@mid.deneb.enyo.de>
[-- Attachment #1: Type: text/plain, Size: 560 bytes --]
On Sun, Sep 16, 2007 at 08:20:06PM +0000, Florian Weimer wrote:
> * Pierre Habouzit:
>
> > +void strbuf_grow(struct strbuf *sb, size_t extra)
> > +{
> > if (sb->len + extra + 1 <= sb->len)
> > die("you want to use way too much memory");
>
> By the way, this comparison is always false because sb->len is signed.
News to me. Actually it's not, it's a size_t :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: metastore (was: Track /etc directory using Git)
From: david @ 2007-09-16 20:36 UTC (permalink / raw)
To: Jan Hudec
Cc: Johannes Schindelin, Daniel Barkalow, martin f krafft, git,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <20070916155913.GB30476@efreet.light.src>
On Sun, 16 Sep 2007, Jan Hudec wrote:
> On Sat, Sep 15, 2007 at 18:30:53 -0700, david@lang.hm wrote:
>> 1. whatever is trying to write the files with the correct permissions
>> needs to be able to query the permission store before files are
>> written. This needs to either be an API call into git to retreive the
>> information for any file when it's written, or the ability to define a
>> specific file to be checked out first so that it can be used for
>> everything else.
>
> You seem to be forgetting about the index. Git never writes trees directly to
> filesystem, but always with intermediate step in the index. So the API
> actually exists -- simply read from the index.
Ok, this sounds promising.
looking into one approach here.
assume for the moment that at write time an external program gets called.
this program reads the file contents from stdin and gets it's other
information from git as command line parameters
parameters I can think it would need are
path to write the file to
length of file
name of the permission file
id of the commit this is part of (possibly)
how does this program access the contents of the permission file in the
index?
David Lang
^ permalink raw reply
* Re: RFC: German translation vocabulary
From: Florian Weimer @ 2007-09-16 20:21 UTC (permalink / raw)
To: git
In-Reply-To: <200709161438.37733.stimming@tuhh.de>
* Christian Stimming:
> repository - Projektarchiv
"Projekt" or "Archiv" should suffice.
> revision - Version
"Versionsangabe", probably. I think "revision" is most used as a
short form of "revision specifier".
> staging area - Bereitstellung
"Index"?
> branch [noun] - Zweig
> branch [verb] - verzweigen
Or "abzweigen", if it's used transitive.
> [commit] message - Meldung (Nachricht?; Source Safe: Kommentar)
I came up with David's "Beschreibung" independently. It fits better
to "Sammlung" below than "Zusammenfassung", IMHO.
> For some of them you can see alternatives considered in the glossary [1], but
> overall the above ones were rather easy. Now for the difficult ones:
>
> commit [noun]
> commit [verb]
"Sammlung" and "sammeln".
> checkout [noun]
> checkout [verb]
How's a checkout different from a working copy?
But to be honest, I wouldn't translate "repository" and "commit", at
least if they are used as nouns.
^ permalink raw reply
* Re: metastore
From: david @ 2007-09-16 20:19 UTC (permalink / raw)
To: David Kastrup
Cc: Junio C Hamano, Johannes Schindelin, Daniel Barkalow,
martin f krafft, git, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz, David Härdeman
In-Reply-To: <85zlzn812s.fsf@lola.goethe.zz>
On Sun, 16 Sep 2007, David Kastrup wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Yes, I am very well aware that somebody already mentioned "there
>> is a window between the true checkout and permission tweaking".
>> If you need to touch the core level in order to close that
>> window, I am not interested.
>
> Doing this atomically involves creating the file in question by
> specifying the permissions on the creat system call already, and
> possibly wrap seteuid calls and similar around it for getting the
> right file/ownership.
>
> However, it is not really necessary to do this atomically: instead one
> can rather create the file using safe permissions (600) at first, then
> do fchown and fchmod (or chown/chmod) at some point in time afterwards
> as required.
the problem with this in /etc is if you do the wrong file as 600 you can
cause lots of nasty problems to the system during the window. for some
files/directories you will want to write the file to a temp name and then
move the file atomicly to the final location.
git itself shouldn't need to worry about this, the external write routine
I'm talking about is the correct place for this (at least until all the
bugs get worked out and everyone is comfortable that everything is good,
and doesn't impact the core git code badly)
David Lang
^ permalink raw reply
* Re: [PATCH] New strbuf APIs: splice and attach.
From: Florian Weimer @ 2007-09-16 20:20 UTC (permalink / raw)
To: git
In-Reply-To: <20070916172233.8B8AD1835F@madism.org>
* Pierre Habouzit:
> +void strbuf_grow(struct strbuf *sb, size_t extra)
> +{
> if (sb->len + extra + 1 <= sb->len)
> die("you want to use way too much memory");
By the way, this comparison is always false because sb->len is signed.
^ permalink raw reply
* Re: RFC: German translation vocabulary
From: Simon Richter @ 2007-09-16 19:44 UTC (permalink / raw)
To: Christian Stimming, git
In-Reply-To: <200709161438.37733.stimming@tuhh.de>
Hallo,
Christian Stimming wrote:
> repository - Projektarchiv
Just "Archiv" would be fine as well in most places, I think.
> revision - Version
> staging area - Bereitstellung
The Windows world uses this word as a translation for "deployment", i.e.
making binaries available to end users.
Maybe "Vorbereitung" would be better here.
> commit [noun]
> commit [verb]
"einspielen"? Problem is that this cannot be properly turned into a noun.
> checkout [noun]
> checkout [verb]
"Erstellung einer Arbeitskopie" (gets less awkward when you make proper
sentences from it).
Simon
^ permalink raw reply
* RFC: Italian translation vocabulary
From: Michele Ballabio @ 2007-09-16 20:11 UTC (permalink / raw)
To: git
In-Reply-To: <200709161438.37733.stimming@tuhh.de>
[Thank you, Christian. I'll use your mail as a template for the
Italian speakers, as most issues apply here as well. For those
interested, s/German/Italian/ :). Appended there's a draft of the
Italian glossary.]
On Sunday 16 September 2007, Christian Stimming wrote:
> Dear all,
>
> as git-gui has now picked up the i18n features and the initial German
> translation has been included as well, it is about time to discuss and
> finalize the actual translation wordings of git terminology in German.
>
> In particular, for all keywords of git and git-gui one needs to find
> corresponding keywords in German, which will then be used consistently
> throughout all of git-gui translations. Those keywords and (for some of them)
> their english definition are contained in the "glossary" file, see [1]. I
> would like to invite all German-speaking readers here to review the German
> keyword translations that have been chosen in the glossary, and I'll denote
> the most important ones below for immediate feedback.
>
> (I'll mostly stick to an english discussion so that other languages can use
> this as a model on how to discuss this, if they want to.)
>
> One word on the intended audience for the translated git-gui: The translated
> form of git-gui is *not for you* :-). In other words, it is not intended for
> those who are reading this list and, by doing so, are completely familiar
> with all the English terminology of git. Instead, the translation is intended
> for German developers who know *some* English, but feel much more comfortable
> with a fully German development environment and probably wouldn't touch an
> english-language git-gui anyway. Hence, the translation should try really
> hard to find German words wherever possible.
>
> Also, other version control systems have worked on their German translation as
> well. If you want to check the wordings that have been chosen there, I'd
> recommend looking into their translations [2].
>
> I'll list the most important glossary terms here, starting with the easier
> ones:
These are the terms currently used in it.po:
repository - archivio, repository
revision - revisione
staging area - area di preparazione
branch [noun] - ramo
branch [verb] - creare ramo (well, git-gui never uses "branch" as a verb,
actually)
working copy, working tree - directory di lavoro (git-gui uses the espression
"working directory")
[commit] message - messaggio
fetch - recuperare, prelevare
Note: in it.po, "repository" is sometimes left untranslated and sometimes
traslated as "archivio". Also, git-gui uses the term "database" too.
Should it be translated in the same way? Currently is left unchanged. We
probably should use the same term throughout all the translation. The
same applies to "fetch"; which one is better: "recuperare" or "prelevare"
(we currently use both)?
> For some of them you can see alternatives considered in the glossary [1], but
> overall the above ones were rather easy. Now for the difficult ones:
>
> commit [noun]
> commit [verb]
> checkout [noun]
> checkout [verb]
These are currently left untranslated in it.po. "commit [verb]" becomes
"effettuare un commit". Other SCM suggest "depositare" or "inviare". If we
translate "repository" with "archivio" we may as well translate
"commit [verb]" with "archiviare".
> I'm still rather unsure what to do about them. One problem here is that both
> words are used in several different meanings all at once. For example,
> the "commit [noun]" is used interchangeably with "revision". I'm actually
> inclined to translate it with "Version" for exactly that reason. And
> then "checkout": The noun is probably used interchangeably with "working
> copy". Hence, it could be translated as such. OTOH the verb means "to update
> the working copy", and it could be translated as such instead of one single
> word. This would leave only "commit [verb]" as the last tricky issue for
> which a single-word translation must be found. "übertragen" is my current
> favorite but I'm absolutely open for further proposals here.
Following these advices, "commit [noun]" will be "revisione",
"checkout [noun]" "revisione attiva", and "checkout [verb]"
"attivare revisione".
> As you can see in the glossary file, I'm still unhappy with the translations
> for those, but anyway here's the current status (not taking into account the
> discussion of the previous paragraph so far):
I've highlighted like *this* the terms currently used in it.po:
msgid "checkout [noun]"
msgstr "*checkout*, revisione attiva, prelievo (TortoiseCVS)?"
msgid "checkout [verb]"
msgstr "effettuare un checkout, attivare revisione, prelevare (TortoiseCVS),
ritirare (TSVN)?"
msgid "commit [noun]"
msgstr "*commit*, revisione, deposito (TortoiseCVS), invio (TSVN)?"
msgid "commit [verb]"
msgstr "*effettuare un commit*, archiviare, depositare (nel server),
fare un deposito (TortoiseCVS), inviare (TSVN)?"
Then, I think there are some problems regarding English terms
vs Git terms vs Italian terms.
E.g. these are the current translations:
reset - *ripristinare*, *annullare* (reset is used as a Git term,
but with different meanings)
revert - *annullare* (Git term)
undo - *annullare* (English term)
I.e. there's an overlap: the same Italian word is used in three
different contexts (and two of them with different Git commands).
We should try to have an 1:1 relationship here. Or, at least,
more different terms in Italian than in Gittish :)
> [1]
See below an Italian glossary proposal.
> [2]
* http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/Languages/Tortoise_it.po
(username=guest, password empty)
* http://tortoisecvs.cvs.sourceforge.net/tortoisecvs/po/TortoiseCVS/it_IT.po?view=markup
* http://rapidsvn.tigris.org/svn/rapidsvn/trunk/src/locale/it_IT/rapidsvn.po
(username=guest, password empty)
---
# Translation of git-gui glossary to Italian
# Copyright (C) 2007 Shawn Pearce, et al.
# This file is distributed under the same license as the git package.
# Christian Stimming <stimming@tuhh.de>, 2007
#
msgid ""
msgstr ""
"Project-Id-Version: git-gui glossary\n"
"PO-Revision-Date: 2007-07-29 16:24+0200\n"
"Last-Translator: Michele Ballabio <barra_cuda@katamail.com>\n"
"Language-Team: Italian \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#. "English Definition (Dear translator: This file will never be visible to the user! It should only serve as a tool for you, the translator. Nothing more.)"
msgid ""
"English Term (Dear translator: This file will never be visible to the user!)"
msgstr ""
"Traduzione italiana.\n"
"Altri SCM in italiano:\n"
" http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/Languages/Tortoise_it.po (username=guest, password empty),\n"
" http://tortoisecvs.cvs.sourceforge.net/tortoisecvs/po/TortoiseCVS/it_IT.po?view=markup ,\n"
" http://rapidsvn.tigris.org/svn/rapidsvn/trunk/src/locale/it_IT/rapidsvn.po (username=guest, password empty)"
"Le traduzioni evidenziate con '*' sono quelle correntemente utilizzate."
#. ""
msgid "amend"
msgstr "correggere, correzione"
#. ""
msgid "annotate"
msgstr "annotare, annotazione"
#. "A 'branch' is an active line of development."
msgid "branch [noun]"
msgstr "*ramo*, diramazione, ramificazione"
#. ""
msgid "branch [verb]"
msgstr "creare ramo, ramificare, diramare"
#. ""
msgid "checkout [noun]"
msgstr "*checkout*, revisione attiva, prelievo (TortoiseCVS)?"
#. "The action of updating the working tree to a revision which was stored in the object database."
msgid "checkout [verb]"
msgstr "effettuare un checkout, attivare revisione, prelevare (TortoiseCVS), ritirare (TSVN)?"
#. "A single point in the git history."
msgid "commit [noun]"
msgstr "*commit*, revisione, deposito (TortoiseCVS), invio (TSVN)?"
#. "The action of storing a new snapshot of the project's state in the git history."
msgid "commit [verb]"
msgstr "*effettuare un commit*, archiviare, depositare (nel server), fare un deposito (TortoiseCVS), inviare (TSVN)?"
#. ""
msgid "diff [noun]"
msgstr "*differenza*, confronto, comparazione, raffronto"
#. ""
msgid "diff [verb]"
msgstr "confronta, mostra le differenze"
#. "A fast-forward is a special type of merge where you have a revision and you are merging another branch's changes that happen to be a descendant of what you have."
msgid "fast forward merge"
msgstr "*fusione in 'fast-forward'*, fusione in avanti veloce"
#. "Fetching a branch means to get the branch's head from a remote repository, to find out which objects are missing from the local object database, and to get them, too."
msgid "fetch"
msgstr "*recuperare*, *prelevare*, prendere da, recuperare (TSVN)"
#. "A collection of files. The index is a stored version of your working tree."
msgid "index (in git-gui: staging area)"
msgstr "*indice*"
#. "A successful merge results in the creation of a new commit representing the result of the merge."
msgid "merge [noun]"
msgstr "*fusione*, unione"
#. "To bring the contents of another branch into the current branch."
msgid "merge [verb]"
msgstr "*effettuare la fusione*, unire, fondere, eseguire la fusione"
#. ""
msgid "message"
msgstr "*messaggio*, commento"
#. "Pulling a branch means to fetch it and merge it."
msgid "pull"
msgstr "prendi (recupera) e fondi (unisci)? (in pratica una traduzione di fetch + merge)"
#. "Pushing a branch means to get the branch's head ref from a remote repository, and ... (well, can someone please explain it for mere mortals?)"
msgid "push"
msgstr "*propaga*"
#. ""
msgid "redo"
msgstr "*ripeti*, rifai"
#. "A collection of refs (?) together with an object database containing all objects which are reachable from the refs... (oops, you've lost me here. Again, please an explanation for mere mortals?)"
msgid "repository"
msgstr "*archivio*, *repository*, database? deposito (rapidsvn)?"
#. ""
msgid "reset"
msgstr "*ripristinare*, *(annullare)*, azzerare, ripristinare"
#. ""
msgid "revert"
msgstr "*annullare*, inverti (rapidsvn), ritorna allo stato precedente, annulla le modifiche della revisione"
#. "A particular state of files and directories which was stored in the object database."
msgid "revision"
msgstr "*revisione* (TortoiseSVN)"
#. ""
msgid "sign off"
msgstr "*sign off*, firma"
#. ""
msgid "staging area"
msgstr "*area di preparazione*, zona di preparazione, modifiche in preparazione? modifiche in allestimento?"
#. ""
msgid "status"
msgstr "stato"
#. "A ref pointing to a tag or commit object"
msgid "tag [noun]"
msgstr "*etichetta*, etichettatura (TortoiseCVS)"
#. ""
msgid "tag [verb]"
msgstr "etichettare"
#. "A regular git branch that is used to follow changes from another repository."
msgid "tracking branch"
msgstr "*ramo in 'tracking'*, ramo inseguitore? ramo di {inseguimento,allineamento,rilevamento,puntamento}?"
#. ""
msgid "undo"
msgstr "*annulla*"
#. ""
msgid "update"
msgstr "*aggiornamento*, *aggiornare*"
#. ""
msgid "verify"
msgstr "*verifica*, *verificare*"
#. "The tree of actual checked out files."
msgid "working copy, working tree"
msgstr "*directory di lavoro*, copia di lavoro"
^ permalink raw reply
* Re: metastore (was: Track /etc directory using Git)
From: david @ 2007-09-16 19:43 UTC (permalink / raw)
To: Jan Hudec
Cc: martin f krafft, git, Johannes Schindelin, Daniel Barkalow,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <20070916155147.GA30476@efreet.light.src>
On Sun, 16 Sep 2007, Jan Hudec wrote:
> On Sun, Sep 16, 2007 at 08:14:11 +0200, martin f krafft wrote:
>> also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.09.16.0014 +0200]:
>>> While at it, you should invent a fallback what to do when the
>>> owner is not present on the system you check out on. And
>>> a fallback when checking out on a filesystem that does not support
>>> owners.
>>
>> Like rsync, git would use numerical UIDs (which are always present)
>> by default, but could be told to try to map account names.
>>
>> If the filesystem does not support owners, chown() would not exist.
>> I actually tend to think of things the other way around: instead of
>> a fallback when chown() does not work (what would such a fallback be
>> other than not chown()ing?), it would only try chown() if such
>> functionality existed.
>
> There's a problem. You need to know that the functionality is missing and not
> try to read attributes back, but instead consider them unchanged. Nothing
> that can't be taken care of, but it needs to be handled carefuly.
but this can be handled by a local config option. yes, you have to be
careful, but it'snot that hard.
David Lang
^ permalink raw reply
* Re: [PATCH 11/12] documentation: replace Discussion section by link to user-manual chapter
From: Andreas Ericsson @ 2007-09-16 19:38 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20070916015606.GA5118@fieldses.org>
J. Bruce Fields wrote:
> On Sun, Sep 09, 2007 at 11:01:57PM +0200, Andreas Ericsson wrote:
>> J. Bruce Fields wrote:
>>> +
>>> +A git project normally consists of a working directory with a ".git"
>>> +subdirectory at the top level. The .git directory contains, among other
>>> +things, a compressed object database representing the complete history
>>> +of the project, a set of pointers into that history ("refs")
>> ... into that history ("refs" - branches and tags)
>
> I slept on it and took another look, and decided you were right; this is
> what I have there now:
>
> A git project normally consists of a working directory with a ".git"
> subdirectory at the top level. The .git directory contains, among
> other things, a compressed object database representing the complete
> history of the project, an "index" file which links that history to
> the current contents of the working tree, and named pointers into that
> history such as tags and branch heads.
>
Looks good. Thanks :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Rewrite convert_to_{git,working_tree} to use strbuf's.
From: Linus Torvalds @ 2007-09-16 18:27 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20070916172233.90C9E1835B@madism.org>
On Sun, 16 Sep 2007, Pierre Habouzit wrote:
..
> 7 files changed, 240 insertions(+), 317 deletions(-)
I like how all these patches seem to be removing more lines than
they add.
The end result looks good from a visual standpoint too.
So:
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
for the whole series.
Linus
^ permalink raw reply
* Re: Blaming diffs
From: Frank Lichtenheld @ 2007-09-16 17:05 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20070916163829.GA6679@glandium.org>
On Sun, Sep 16, 2007 at 06:38:29PM +0200, Mike Hommey wrote:
> It seems to me there is no tool to "blame diffs", i.e. something to know
> what commit(s) is(are) responsible for a set of changes.
>
> For example, the following script tries to get the set of commits
> involved in the changes between $A and $B. Note it only works for text
> additions.
>
> git diff --unified=0 $A $B | awk 'BEGIN { FS="(^(--- a/|+++ b/)|^@@ -[0-9,]+ \\+| @@)" } /^---/ || ( /^+++ b\/(.*)/ && file=="" ) { file = $2 } /^@@/ {split($2, a, /,/); a[2] = a[2] ? a[2] + a[1] - 1 : a[1]; print "git blame -l -L " a[1] "," a[2], "'$A..$B'", file }' | sh | cut -f 1 -d " " | sort -u
>
> Has anyone tried to work on something similar yet ?
>
> If not, as git users, what kind of output would you expect from such a
> tool, and where do you think this should lie (extension to git diff, or
> separate tool) ?
What do you use for $A and $B? commits? What is the difference between
your script and "git log --pretty=format:%H $A..$B"
then?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox