* [BUG?] "git submodule foreach" when command is ssh
From: Chris Packham @ 2011-01-05 22:32 UTC (permalink / raw)
To: GIT
Hi All,
I just noticed something odd with "git submodule foreach". I was
running a script to create a backup of each submodule on a server I
have ssh access to. I was surprised to find that git submodule foreach
stopped silently after the first submodule.
A little debugging and I find that
git submodule foreach 'ssh localhost "ls /"' - stops silently after
the first module (note that the command does produce the expected
listing and there is no error about the command failing).
git submodule foreach 'echo foo' - works as expected
Any thoughts as to whats going on?
---
git version 1.7.3.2
^ permalink raw reply
* Re: patch for git-p4
From: Erik Faye-Lund @ 2011-01-05 21:31 UTC (permalink / raw)
To: Andrew Garber; +Cc: git
In-Reply-To: <AANLkTi=sNsDy9oo0iBE-qJwvFSDMFYma3oYhbP1J-th=@mail.gmail.com>
On Wed, Jan 5, 2011 at 2:45 AM, Andrew Garber <andrew@andrewgarber.com> wrote:
> Hi everyone! This is my first post to the git mailing list.
>
Welcome!
> I was reading the git-p4 source and noticed that some of the lines are
> indented using tabs instead of spaces (very bad in Python). Here's a
> patch against tag v1.7.4-rc0 (commit
> 01b97a4cb60723d18b437efdc474503d2a9dd384) of the git source repo.
>
> Thanks!
> Andrew Garber
>
Please read Documentation/SubmittingPatches for the correct procedure
for submitting patches. The two most important things is:
1) We send patches inline instead of attached (git send-email can do
this for you)
2) You need to add a sign-off
As a side-note, your commit message has some broken grammar in it.
"Some the commits", I'm guessing you omitted a "of" there?
We tend not to write commit messages in past tence. E.g "git-p4:
replace tabs with spaces" (notice that I removed a 'd').
^ permalink raw reply
* fast-import --report-fd (Re: fast-import tweaks for remote helpers)
From: Jonathan Nieder @ 2011-01-05 21:20 UTC (permalink / raw)
To: Sam Vilain
Cc: Tomas Carnecky, git, Ramkumar Ramachandra, Sverre Rabbelier,
David Barr, Stephen Bash
In-Reply-To: <20101212171633.GB18847@burratino>
Jonathan Nieder wrote:
> Sam Vilain wrote:
>> What happened to --report-fd ?
>
> The patch still works. The main problem with report-fd is that it
> introduced a synchronization point after every commit: the frontend
> has to read the commit id before fast-import will continue.
Correction: more precisely, that was and is the main problem with
svn-fe's use of bidirectional communication. An application like
Tom's remote helper would probably not suffer so much from it, since
commit ids are just queued up as long as the pipe doesn't fill before
the frontend reads any. It is transactions like
FI> r5 = 734987a9878b97c879c798a897c897ac
FE> cat 734987a9878b97c879c798a897c897ac
FI> 734987a9878b97c879c798a897c897ac commit 448
tree 8d5bcf0f24bdfea1fdab8d39ba3c8ba91a52547c
parent 84279592b8b5816d00300ba5d4412adf05cc80d6
parent 3ca7353cab4ed6c7efac0c8d7477c87112fc7350
author Junio C Hamano <gitster@pobox.com> 1294187068 -0800
committer Junio C Hamano <gitster@pobox.com> 1294187068 -0800
Merge branch 'sr/gitweb-hilite-more' into pu
* sr/gitweb-hilite-more:
gitweb: remove unnecessary test when closing file descriptor
gitweb: add extensions to highlight feature map
FE> cat 8d5bcf0f24bdfea1fdab8d39ba3c8ba91a52547c "main.c"
(i.e., round-trips) that were and are creating overhead in svn-fe.
See [1] if curious about details.
So please don't be dissuaded by the nonsense I sent. :)
[1] http://colabti.org/irclogger/irclogger_log_search/git-devel?search=overhead&action=search
^ permalink raw reply
* Re: concurrent fetches to update same mirror
From: Jeff King @ 2011-01-05 21:13 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Neal Kreitzinger, git
In-Reply-To: <20110105205324.GA7808@sigill.intra.peff.net>
On Wed, Jan 05, 2011 at 03:53:25PM -0500, Jeff King wrote:
> > If both fetch processes try to update the same ref at the same time,
> > one will get the lock and continue, and the other will crash with an
> > error (because the lock was busy). If one is slightly slower than the
> > other, they will probably update the refs twice, with the slower fetch
> > updating what the faster one had just updated. :-)
>
> I assumed it would take the "old" value at the very beginning of the
> fetch (before talking with the remote), and then see that the ref was
> changed under our feet. Or does it simply do it at the end?
Hmm. Weirder even, builtin/fetch.c:s_update_ref takes a "check_old"
flag, and we do always use it for branch updates. But not for tag
updates. I can't think of why. The code blames all the way back to the
original builtin-fetch.
Anyway, when we do check, we check the value from the beginning of the
fetch. So you can get lock conflicts. For example, doing this:
mkdir repo && cd repo && git init
echo contents >foo && git add . && git commit -m one
git update-ref refs/remotes/origin/master refs/heads/master
git remote add origin some-remote-repo-that-takes-a-few-seconds
xterm -e 'git fetch -v; read' & xterm -e 'git fetch -v; read'
I.e., putting some cruft into the ref and then updating it. One fetch
will force-write over the ref properly:
+ ac32203...4e64590 master -> origin/master (forced update)
but the other one will barf on the lock:
error: Ref refs/remotes/origin/master is at 4e6459052ab329914c7712a926773e566b8c821d but expected ac32203727daa3bcb5fc041786aa45adbbe86299
...
! ac32203...4e64590 master -> origin/master (unable to update local ref)
Interestingly, in the case of ref _creation_, not update, like this:
mkdir repo && cd repo && git init
git remote add origin some-remote-repo-that-takes-a-few-seconds
xterm -e 'git fetch -v; read' & xterm -e 'git fetch -v; read'
then both will happily update, the second one overwriting the results of
the first. It seems in the case of locking a ref which previously didn't
exist, we don't enforce that it still doesn't exist.
I wonder if we should, but perhaps there is some corner case I am not
considering. The code is in lock_ref_sha1_basic, but blaming didn't turn
up anything helpful.
-Peff
^ permalink raw reply
* Re: [PATCH] Document escaping of special characters in gitignore files
From: Jakub Narebski @ 2011-01-05 21:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Bruce Korb, git, Andreas Schwab,
Ævar Arnfjörð Bjarmason
In-Reply-To: <7vk4ijccji.fsf@alter.siamese.dyndns.org>
On Wed, 5 Jan 2011, Junio C Hamano wrote:
> Perhaps a single liner comment to describe the three examples immediately
> below "exclude patterns (uncomment them..." is in order in that case,
> something like:
>
> # exclude patterns (object and library, emacs backup, emacs autosave
> # files) -- uncomment if you want to use them
> # *.[oa]
> # *~
Errr... I think that '*~' pattern is generic UNIX backup, like '*.bak'
is for MS-DOS / MS Windows.
http://en.wikipedia.org/wiki/Tilde#Backup_filenames
Backup filenames
The dominant Unix convention for naming backup copies of files is
appending a tilde to the original file name. It originated with the
Emacs text editor[citation needed] and was adopted by many other
editors and some command-line tools.
> # \#*#
Anyway, should I reroll this patch with above addition? Should I add
an explanation why we can use `\#` but need to use "{tilde}#"?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: concurrent fetches to update same mirror
From: Jeff King @ 2011-01-05 20:53 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Neal Kreitzinger, git
In-Reply-To: <AANLkTini61q+NtDr6oytTcfA6QNGN74L60exdLrNmakd@mail.gmail.com>
On Wed, Jan 05, 2011 at 12:51:12PM -0800, Shawn Pearce wrote:
> On Wed, Jan 5, 2011 at 12:47, Jeff King <peff@peff.net> wrote:
> >
> > However, in the default configuration, we fetch using a "+" refspec,
> > which forces update of the ref even in the case of a non-fast-forward. I
> > don't know whether that force also would override any lock-checking.
>
> Nope, it doesn't. We still use locking to update the refs, to ensure
> the update is seen atomically by a reader. The + just means don't
> check that the old value is fully reachable from the new after the
> lock as been taken.
Good, that's what IMHO it _should_ do. :)
> If both fetch processes try to update the same ref at the same time,
> one will get the lock and continue, and the other will crash with an
> error (because the lock was busy). If one is slightly slower than the
> other, they will probably update the refs twice, with the slower fetch
> updating what the faster one had just updated. :-)
I assumed it would take the "old" value at the very beginning of the
fetch (before talking with the remote), and then see that the ref was
changed under our feet. Or does it simply do it at the end?
... goes to read code ...
-Peff
^ permalink raw reply
* Re: concurrent fetches to update same mirror
From: Shawn Pearce @ 2011-01-05 20:51 UTC (permalink / raw)
To: Jeff King; +Cc: Neal Kreitzinger, git
In-Reply-To: <20110105204738.GA7629@sigill.intra.peff.net>
On Wed, Jan 5, 2011 at 12:47, Jeff King <peff@peff.net> wrote:
>
> However, in the default configuration, we fetch using a "+" refspec,
> which forces update of the ref even in the case of a non-fast-forward. I
> don't know whether that force also would override any lock-checking.
Nope, it doesn't. We still use locking to update the refs, to ensure
the update is seen atomically by a reader. The + just means don't
check that the old value is fully reachable from the new after the
lock as been taken.
If both fetch processes try to update the same ref at the same time,
one will get the lock and continue, and the other will crash with an
error (because the lock was busy). If one is slightly slower than the
other, they will probably update the refs twice, with the slower fetch
updating what the faster one had just updated. :-)
--
Shawn.
^ permalink raw reply
* Re: concurrent fetches to update same mirror
From: Jeff King @ 2011-01-05 20:47 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <ig2kjt$f2u$1@dough.gmane.org>
On Wed, Jan 05, 2011 at 02:33:36PM -0600, Neal Kreitzinger wrote:
> If two or more different users perform a git-fetch on the same mirror
> (--mirror) repo concurrently, could that cause corruption? I tried a manual
> test using the git protocol over separate machines and they both thought
> they needed to do the full updates and they both appeared to work. I'm not
> sure if git is serializing this, or if it is possible for concurrent fetches
> to step on each other.
No, it shouldn't cause corruption, but it will cause wasted effort and
it may cause one to report failure. The fetch process gets all of the
objects first, and then updates the ref (so we never have refs that
point to object we didn't get yet). So both of the concurrent fetches
will see that we have a big set of objects to get and will work on
getting them at the same time, after which they will update the refs
appropriately (presumably to the same thing).
I haven't looked specifically at how fetch does locking, but usually the
procedure is to lock the ref, fetch the old value, unlock it, then do
some long-running task (like fetching objects), then lock again, check
that the old value didn't change out from under us, update it, then
unlock. In which case one of the fetches might see "oops, somebody
updated while we were fetching" and complain.
However, in the default configuration, we fetch using a "+" refspec,
which forces update of the ref even in the case of a non-fast-forward. I
don't know whether that force also would override any lock-checking.
-Peff
^ permalink raw reply
* concurrent pulls on the same non-bare repo master branch
From: Neal Kreitzinger @ 2011-01-05 20:38 UTC (permalink / raw)
To: git
If two or more users concurrently perform a git-pull of the master branch on
the same non-bare repo can this cause corruption? I'm not sure if git is
serializing this or if it is possible for concurrent pulls to step on each
other.
v/r,
Neal
^ permalink raw reply
* Re: [PATCH] Document escaping of special characters in gitignore files
From: Junio C Hamano @ 2011-01-05 20:37 UTC (permalink / raw)
To: Bruce Korb
Cc: Jakub Narebski, Junio C Hamano, git, Andreas Schwab,
Ævar Arnfjörð Bjarmason
In-Reply-To: <4D24D0CB.3030004@gmail.com>
Bruce Korb <bruce.korb@gmail.com> writes:
> On 01/05/11 11:27, Jakub Narebski wrote:
>>>> +++ b/templates/info--exclude
>>>> @@ -4,3 +4,4 @@
>>>> # exclude patterns (uncomment them if you want to use them):
>>>> # *.[oa]
>>>> # *~
>>>> +# \#*#
>>>
>>> Do we need this? Without explanation it is somewhat hard to realize that
>>> this last line is also an example of a pattern that excludes any filename
>>> that begins and ends with a pound.
>>
>> Well, perhaps not. Note though that this exclude pattern is actually
>> useful for me, as GNU Emacs uses this convention ("#<filename>#") for
>> auto-save files.
>
> As the source of this thread, I, too, use emacs and it is exactly
> the problem of trying to figure out how to get git to ignore these
> auto save files that got me down this path. It was too hard to figure out.
> So I suggested some doc changes and the addition of the "exclude
> emacs auto save files" pattern to the sample text. People who do not
> use emacs would not understand the \#*# line and folks who do would.
> They see files like that all the time. For the sake of vi users, you
> might want to explain them, but I don't think it is crucial.
> It *is* important to have an example of a needs-to-be-escaped file name.
Perhaps a single liner comment to describe the three examples immediately
below "exclude patterns (uncomment them..." is in order in that case,
something like:
# exclude patterns (object and library, emacs backup, emacs autosave
# files) -- uncomment if you want to use them
# *.[oa]
# *~
# \#*#
^ permalink raw reply
* concurrent fetches to update same mirror
From: Neal Kreitzinger @ 2011-01-05 20:33 UTC (permalink / raw)
To: git
If two or more different users perform a git-fetch on the same mirror
(--mirror) repo concurrently, could that cause corruption? I tried a manual
test using the git protocol over separate machines and they both thought
they needed to do the full updates and they both appeared to work. I'm not
sure if git is serializing this, or if it is possible for concurrent fetches
to step on each other.
v/r,
Neal
^ permalink raw reply
* Re: [PATCH] Document escaping of special characters in gitignore files
From: Bruce Korb @ 2011-01-05 20:12 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, git, Andreas Schwab,
Ævar Arnfjörð Bjarmason
In-Reply-To: <201101052027.24640.jnareb@gmail.com>
On 01/05/11 11:27, Jakub Narebski wrote:
>>> +++ b/templates/info--exclude
>>> @@ -4,3 +4,4 @@
>>> # exclude patterns (uncomment them if you want to use them):
>>> # *.[oa]
>>> # *~
>>> +# \#*#
>>
>> Do we need this? Without explanation it is somewhat hard to realize that
>> this last line is also an example of a pattern that excludes any filename
>> that begins and ends with a pound.
>
> Well, perhaps not. Note though that this exclude pattern is actually
> useful for me, as GNU Emacs uses this convention ("#<filename>#") for
> auto-save files.
As the source of this thread, I, too, use emacs and it is exactly
the problem of trying to figure out how to get git to ignore these
auto save files that got me down this path. It was too hard to figure out.
So I suggested some doc changes and the addition of the "exclude
emacs auto save files" pattern to the sample text. People who do not
use emacs would not understand the \#*# line and folks who do would.
They see files like that all the time. For the sake of vi users, you
might want to explain them, but I don't think it is crucial.
It *is* important to have an example of a needs-to-be-escaped file name.
^ permalink raw reply
* Re: git fails on large repo clone on intermittent, or intermittently-high-latency, connections
From: Jakub Narebski @ 2011-01-05 20:00 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Zenaan Harkness, git
In-Reply-To: <20110105175412.GA21863@burratino>
On Wed, 5 Jan 2011, Jonathan Nieder wrote:
> Jakub Narebski wrote:
> > Zenaan Harkness <zen@freedbms.net> writes:
>
> > > How hard would it be to add a wget-like mode to git, for the initial
> > > repo download?
> >
> > Very hard; tthough "resumable clone" was often requested (25%
> > responders in "Git User's Survey 2010", see [1]), and there was even
> > some discussion about possible implementation, it was not implemented
> > yet, even as proof of concept.
> >
> > The trouble is that packfile is *generated for a client*, and
> > bit-for-bit representation of said pack can vary (e.g. if
> > multithreaded packing is enabled; usually a good idea).
>
> That said, one possible partial solution would be to automate
> generation of a seed bundle for huge repositories (with a script or
> a special parameter to "git gc", maybe) and to document serving such a
> seed bundle over HTTP as part of the standard setup. If this could be
> made simple enough that e.g. all large repos on repo.or.cz had such a
> seed bundle then I would call it a success. :)
I wonder if adding support for per-project _bundle_ link and 'bundle'
action support to gitweb (perhaps only if caching is turned on) would
help there... though I am not sure if doenloading fron gitweb is
resumable.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git repo corruption
From: Jakub Narebski @ 2011-01-05 19:49 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTikxW-kEhCFKBb-rGPM2xZtk7WyomYnFwz_DYV43@mail.gmail.com>
Levend Sayar wrote:
> git ls-files -m | xargs git checkout --
Why not simply "git checkout -- ." or "git checkout HEAD -- ."?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Document escaping of special characters in gitignore files
From: Thomas Rast @ 2011-01-05 19:38 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, git, Bruce Korb, Andreas Schwab,
Ævar Arnfjörð Bjarmason
In-Reply-To: <201101052027.24640.jnareb@gmail.com>
Jakub Narebski wrote:
> Second, http://www.methods.co.nz/asciidoc/userguide.html#_text_formatting
> ("7. Text Formatting", "7.1. Quoted Text") says (emphasizis mine):
>
> Word phrases `enclosed in backtick characters` (grave accents) are also
> rendered in a monospaced font but in this case the enclosed text is
> __rendered literally__ and is not subject to further expansion (see
> inline literal).
>
> So yes, it is safe, and no, `{backslash}#` would not work.
This is correct, but the behaviour you quote was introduced in a minor
release of asciidoc (!!!). From 71c020c5:
Disable asciidoc 8.4.1+ semantics for `{plus}` and friends
asciidoc 8.4.1 changed the semantics of inline backtick quoting so
that they disable parsing of inline constructs, i.e.,
Input: `{plus}`
Pre 8.4.1: +
Post 8.4.1: {plus}
Fix this by defining the asciidoc attribute 'no-inline-literal'
(which, per the 8.4.1 changelog, is the toggle to return to the old
behaviour) when under ASCIIDOC8.
So in fact with current settings in Documentation/Makefile, the brace
escapes *are* expanded even within backticks.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Document escaping of special characters in gitignore files
From: Jakub Narebski @ 2011-01-05 19:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Bruce Korb, Andreas Schwab,
Ævar Arnfjörð Bjarmason
In-Reply-To: <7vwrmjchuu.fsf@alter.siamese.dyndns.org>
On Wed, 5 Jan 2011, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > This patch was originally send 10 Sep 2010, but I guess it was lost
> > because it appeared only deep in thread inside response, and not as
> > well separated patch. I have found about it when I got conflict
> > merging current code.
> >
> > It applies on top of current 'master'.
>
> Thanks. A few questions before applying.
>
> > diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
> > index 7dc2e8b..20abc20 100644
> > --- a/Documentation/gitignore.txt
> > +++ b/Documentation/gitignore.txt
> > @@ -68,6 +68,7 @@ Patterns have the following format:
> > for readability.
> >
> > - A line starting with # serves as a comment.
> > + Use `\#` for a literal # character starting filename.
>
> Is a literal bs safe here? You later use "{backslash}#" in this same
> file, and it might make sense to do so here for the sake of source
> readability, even if a literal bs is safe here---provided that
> "{backslash}#" does not break here, of course.
First, I have checked how it is done in current codebase, and as one
can check, inside backtics escape sequences are written literally, e.g.
`\"`, `\\` in Documentation/config.txt -- notice that those are about
escaping of special characters too.
Second, http://www.methods.co.nz/asciidoc/userguide.html#_text_formatting
("7. Text Formatting", "7.1. Quoted Text") says (emphasizis mine):
Word phrases `enclosed in backtick characters` (grave accents) are also
rendered in a monospaced font but in this case the enclosed text is
__rendered literally__ and is not subject to further expansion (see
inline literal).
So yes, it is safe, and no, `{backslash}#` would not work.
I later use "{backslash}#" because it is inside double quotes, and not
backticks. It is similar to how {caret} is treated inside double or
single quotes.
> > @@ -98,6 +99,12 @@ Patterns have the following format:
> > ...
> > + - You can escape special characters using backslash.
> > + For example, "{backslash}#*" matches files beginning in `#`
> > ...
>
> > diff --git a/templates/info--exclude b/templates/info--exclude
> > index a5196d1..2ebaf0d 100644
> > --- a/templates/info--exclude
> > +++ b/templates/info--exclude
> > @@ -4,3 +4,4 @@
> > # exclude patterns (uncomment them if you want to use them):
> > # *.[oa]
> > # *~
> > +# \#*#
>
> Do we need this? Without explanation it is somewhat hard to realize that
> this last line is also an example of a pattern that excludes any filename
> that begins and ends with a pound.
Well, perhaps not. Note though that this exclude pattern is actually
useful for me, as GNU Emacs uses this convention ("#<filename>#") for
auto-save files. From "(emacs.gz)Auto Save Files":
Auto-saving does not normally save in the files that you visited,
because it can be very undesirable to save a program that is in an
inconsistent state when you have made half of a planned change.
Instead, auto-saving is done in a different file called the "auto-save
file", and the visited file is changed only when you request saving
explicitly (such as with `C-x C-s').
Normally, the auto-save file name is made by appending `#' to the
front and rear of the visited file name. Thus, a buffer visiting file
`foo.c' is auto-saved in a file `#foo.c#'.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: --find-copies-harder finds fewer copies/renames than -C does
From: Junio C Hamano @ 2011-01-05 18:59 UTC (permalink / raw)
To: Stefan Haller; +Cc: git
In-Reply-To: <1jukub7.uehx43wxtij7M%lists@haller-berlin.de>
lists@haller-berlin.de (Stefan Haller) writes:
> The reason for this seems to be the condition
> "num_create * num_src > rename_limit * rename_limit" in diffcore_rename;
> --find-copies-harder exeeds the limit, so it turns off inexact rename
> dectection *completely*, while -C stays well below the limit.
>
> I had expected --find-copies-harder to still do inexact rename detection
> among the changed files in the commit in this case, and turn it off only
> for the unmodified files; I'm not familiar enough with the code to tell
> whether that would be easy to implement though.
>
> Any thoughts?
Two. When you can spend unlimited amount of resources, it would feel more
intuitive if -C -C lifted rename-limit altogether. On the other hand, in
a project where the difference does matter (i.e. you have far too many
candidate sources), it is likely that -C -C without rename limit would run
out of memory and not produce any result, so automatic lifting of rename
limit is unacceptable as the default.
Setting rename-limit to match the size of your environment (perhaps do
this once in the config) would make this a non-issue, so coming up with an
automated way to do so might be an interesting exercise.
^ permalink raw reply
* Re: git repo corruption
From: Levend Sayar @ 2011-01-05 18:58 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <4D24B969.50007@gmail.com>
In fact, let me summarize what I did.
After sysadmin changed permissions, git status gave
Changed but not updated:
modified: bla bla
modified: bla bla
modified: ....
That modifed files are all the files that tracked in fact. So many
files. And git diff gave
diff bla bla
old mode 644
new mode 750
for all files. So only permissions are changed. To revert back I did only
git ls-files -m | xargs git checkout --
And everything is fine.
_lvnd_
(^_^)
On Wed, Jan 5, 2011 at 8:33 PM, Neal Kreitzinger <nkreitzinger@gmail.com> wrote:
> On 1/4/2011 3:10 AM, Levend Sayar wrote:
>>
>> Hi, all.
>>
>> We have a repo on a corporate server. The sysadmin changed access
>> rights of files on our repo by accedant.
>> Some directories have 2750 acces rights before, but he changed as
>>
>> chmod -R 2770 *
>>
>> Now when you make git status, every file that is tracked by git is said as
>>
>> changed but not updated
>>
>> So is there a way to get this back to normal ?
>>
>> TIA
>>
>> _lvnd_
>> (^_^)
>
> If you want to reset the permissions back to exactly what git would do, here
> is the way I did it after hours one night to fix the repo at our shop
> (modify the permissions value to what you want):
>
> Here is the technique I devised to change permissions on a git repo. I
> needed to lock down a repo so only the integration manager has write access.
> This method ensures that git sets the permissions according to gits rules.
> Please let me know if you know of an easier/better way to do this.
>
> Change Permissions on an Existing Git Repo:
>
> Check System for Users who may be using the Repo:
> # w (see who's logged in)
> # ps -A |grep git-menu-scriptname (where scriptname is some unique string
> in the name of the main script your users use to access that repo, if
> applicable)
> # skill -KILL pts/99 (where 99 = the pts/# from w command, log the user
> off)
>
> Change Shared=group to Shared=0644 (change group read+write to group read
> only):
> Create Template for permissions:
> login as fsngit0
> $ cd /path/to/template
> $ cat config
> [core]
> sharedRepository = 0644
>
> Clone repo to set permissions via git:
> $ cd /path/to/repo-parent-dir
> $ git clone --bare --template=/path/to/template file:///path/to/REPO.git
> REPOMOD.git
>
> Compare old and new versions:
> $ diff -r REPO.git REPOMOD.git
> Only in REPO.git: branches (empty, keep the old version)
> diff -r REPO.git/config REPOMOD.git/config (merge the old and new together)
> 1a2
>> sharedrepository = 0644
> 6,7c7
> < denyDeletes = true
> < denyNonFastForwards = true
> ---
>> denyNonFastforwards = true
> Only in REPO.git: description (keep the old version)
> Only in REPO.git: gitk.cache (gitk will recreate this)
> Only in REPO.git: hooks (contains sample scripts only or whatever scripts
> your using, keep the old version)
> Only in REPO.git: info (keep the old version: contains attributes, exclude,
> or whatever you've setup)
> Only in REPO.git/objects: aa (keep new version, loose object have been
> packed)
> Only in REPO.git/objects/pack:
> pack-A5735e9b894dce1498ec1c776dcabc97fd8ceAfc.idx
> diff -r REPO.git/packed-refs REPOMOD.git/packed-refs (keep the new version
> because fresh clone has been optimized)
> 2c2
> < Xa8b7b8c8fd3920b89770f2e8356f4ecb71a58cX refs/heads/master
> ---
>> Ya69744e46276a37932d5f0755a53f76cdf83e0dY refs/heads/master
> Only in REPO.git/refs/heads: master (old version not needed because fresh
> clone has been optimized)
>
> Copy over REPO.git files that the clone didn't replicate, but that you need
> in order to retain all settings:
> $ cp -rv /path/to/REPO.git/info .
> repeat as needed...
>
> change permissions to g-w or whatever your core.sharedRepository new value
> is supposed to be:
> $ chmod -R g-w info
> repeat as needed...
>
> Validate your changes:
> $ diff -r REPO.git REPOMOD.git
> diff -r REPO.git/config REPOMOD.git/config
> 1a2
>> sharedrepository = 0644
> 7c8
> < denyNonFastForwards = true
> ---
>> denyNonFastforwards = true
> Only in REPO.git: gitk.cache
> Only in REPO.git/objects: aa
> Only in REPO.git/objects/pack:
> pack-A5735e9b894dce1498ec1c776dcabc97fd8ceAfc.idx
> diff -r REPO.git/packed-refs REPOMOD.git/packed-refs
> 2c2
> < Xa8b7b8c8fd3920b89770f2e8356f4ecb71a58cX refs/heads/master
> ---
>> Y69744e46276a37932d5f0755a53f76cdf83e0dY refs/heads/master
> Only in REPO.git/refs/heads: master
>
> Backup REPO.git and rename REPOMOD.git to REPO.git:
> $ cp -rvp REPO.git REPO.git-old
> $ diff -r REPO.git REPO.git-old
> $ rm -rf REPO.git
> $ cp -rvp REPOMOD.git REPO.git
> $ diff -r REPO.git REPOMOD.git
> $ diff -r REPO.git REPO.git-old
>
> v/r,
> Neal
>
>
>
^ permalink raw reply
* Re: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false
From: Junio C Hamano @ 2011-01-05 18:51 UTC (permalink / raw)
To: Vallon, Justin
Cc: Jonathan Nieder, Matthieu Moy, Robin H. Johnson,
git@vger.kernel.org
In-Reply-To: <982E526FA742C94E9AC26DA766FD07090A33A5@NYCMBX3.winmail.deshaw.com>
"Vallon, Justin" <Justin.Vallon@deshaw.com> writes:
>>Because POSIX shells are required to mark variables they inherit from the
>>environment with the export attribute, your tests will run with SHELL
>>exported to the environment if your usual shell is bash (i.e. SHELL is
>>already exported to processes it spawns), even if you use another POSIX
>>shell to run your git and tests. That makes the issue doubly harder to
>>notice.
>
> I don't really follow this. The #! line is /bin/sh. The user's $SHELL
> does not come into play. Either SHELL is in /bin/sh's environment and
> it should be cleared in the child, or it isn't and it won't matter.
Read what you are responding to again.
The "doubly harder to notice" is _not_ about gentoo's /bin/sh, but about
the experiment Matthieu did (ask: "what shell spawned t3404 that has the
she-bang /bin/sh?").
If that shell is bash, which automatically marks SHELL with the export
attribute, it places the variable in the environment. t3404 is run under
/bin/sh, which presumably is POSIX and initializes its shell variable SHELL
with what was in the environment, and while doing so, it also marks the
variable with the export attribute. The script does not "unset SHELL" but
merely assigns an empty string to it, which is the value to be exported to
the processes the script runs.
Imagine that whoever was having trouble did not have SHELL exported to the
environment when t3404 is run. The script assigns an empty string to its
shell variable SHELL but nothing marks the variable with the export
attribute, hence the processes the script runs will never see that as the
value of the environment variable (in fact, they wouldn't see SHELL
environment variable at all).
^ permalink raw reply
* Re: [PATCH] Document escaping of special characters in gitignore files
From: Junio C Hamano @ 2011-01-05 18:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Bruce Korb, avarab
In-Reply-To: <1294234732-20094-1-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> This patch was originally send 10 Sep 2010, but I guess it was lost
> because it appeared only deep in thread inside response, and not as
> well separated patch. I have found about it when I got conflict
> merging current code.
>
> It applies on top of current 'master'.
Thanks. A few questions before applying.
> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
> index 7dc2e8b..20abc20 100644
> --- a/Documentation/gitignore.txt
> +++ b/Documentation/gitignore.txt
> @@ -68,6 +68,7 @@ Patterns have the following format:
> for readability.
>
> - A line starting with # serves as a comment.
> + Use `\#` for a literal # character starting filename.
Is a literal bs safe here? You later use "{backslash}#" in this same
file, and it might make sense to do so here for the sake of source
readability, even if a literal bs is safe here---provided that
"{backslash}#" does not break here, of course.
> @@ -98,6 +99,12 @@ Patterns have the following format:
> ...
> + - You can escape special characters using backslash.
> + For example, "{backslash}#*" matches files beginning in `#`
> ...
> diff --git a/templates/info--exclude b/templates/info--exclude
> index a5196d1..2ebaf0d 100644
> --- a/templates/info--exclude
> +++ b/templates/info--exclude
> @@ -4,3 +4,4 @@
> # exclude patterns (uncomment them if you want to use them):
> # *.[oa]
> # *~
> +# \#*#
Do we need this? Without explanation it is somewhat hard to realize that
this last line is also an example of a pattern that excludes any filename
that begins and ends with a pound.
^ permalink raw reply
* Re: git repo corruption
From: Neal Kreitzinger @ 2011-01-05 18:33 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <AANLkTi=TSy1WQZARNQgGfPiV93hQ-xmCTip75JAixgDB@mail.gmail.com>
On 1/4/2011 3:10 AM, Levend Sayar wrote:
> Hi, all.
>
> We have a repo on a corporate server. The sysadmin changed access
> rights of files on our repo by accedant.
> Some directories have 2750 acces rights before, but he changed as
>
> chmod -R 2770 *
>
> Now when you make git status, every file that is tracked by git is said as
>
> changed but not updated
>
> So is there a way to get this back to normal ?
>
> TIA
>
> _lvnd_
> (^_^)
If you want to reset the permissions back to exactly what git would do,
here is the way I did it after hours one night to fix the repo at our
shop (modify the permissions value to what you want):
Here is the technique I devised to change permissions on a git repo. I
needed to lock down a repo so only the integration manager has write
access.
This method ensures that git sets the permissions according to gits rules.
Please let me know if you know of an easier/better way to do this.
Change Permissions on an Existing Git Repo:
Check System for Users who may be using the Repo:
# w (see who's logged in)
# ps -A |grep git-menu-scriptname (where scriptname is some unique string
in the name of the main script your users use to access that repo, if
applicable)
# skill -KILL pts/99 (where 99 = the pts/# from w command, log the user
off)
Change Shared=group to Shared=0644 (change group read+write to group read
only):
Create Template for permissions:
login as fsngit0
$ cd /path/to/template
$ cat config
[core]
sharedRepository = 0644
Clone repo to set permissions via git:
$ cd /path/to/repo-parent-dir
$ git clone --bare --template=/path/to/template file:///path/to/REPO.git
REPOMOD.git
Compare old and new versions:
$ diff -r REPO.git REPOMOD.git
Only in REPO.git: branches (empty, keep the old version)
diff -r REPO.git/config REPOMOD.git/config (merge the old and new together)
1a2
> sharedrepository = 0644
6,7c7
< denyDeletes = true
< denyNonFastForwards = true
---
> denyNonFastforwards = true
Only in REPO.git: description (keep the old version)
Only in REPO.git: gitk.cache (gitk will recreate this)
Only in REPO.git: hooks (contains sample scripts only or whatever scripts
your using, keep the old version)
Only in REPO.git: info (keep the old version: contains attributes,
exclude,
or whatever you've setup)
Only in REPO.git/objects: aa (keep new version, loose object have been
packed)
Only in REPO.git/objects/pack:
pack-A5735e9b894dce1498ec1c776dcabc97fd8ceAfc.idx
diff -r REPO.git/packed-refs REPOMOD.git/packed-refs (keep the new version
because fresh clone has been optimized)
2c2
< Xa8b7b8c8fd3920b89770f2e8356f4ecb71a58cX refs/heads/master
---
> Ya69744e46276a37932d5f0755a53f76cdf83e0dY refs/heads/master
Only in REPO.git/refs/heads: master (old version not needed because fresh
clone has been optimized)
Copy over REPO.git files that the clone didn't replicate, but that you need
in order to retain all settings:
$ cp -rv /path/to/REPO.git/info .
repeat as needed...
change permissions to g-w or whatever your core.sharedRepository new value
is supposed to be:
$ chmod -R g-w info
repeat as needed...
Validate your changes:
$ diff -r REPO.git REPOMOD.git
diff -r REPO.git/config REPOMOD.git/config
1a2
> sharedrepository = 0644
7c8
< denyNonFastForwards = true
---
> denyNonFastforwards = true
Only in REPO.git: gitk.cache
Only in REPO.git/objects: aa
Only in REPO.git/objects/pack:
pack-A5735e9b894dce1498ec1c776dcabc97fd8ceAfc.idx
diff -r REPO.git/packed-refs REPOMOD.git/packed-refs
2c2
< Xa8b7b8c8fd3920b89770f2e8356f4ecb71a58cX refs/heads/master
---
> Y69744e46276a37932d5f0755a53f76cdf83e0dY refs/heads/master
Only in REPO.git/refs/heads: master
Backup REPO.git and rename REPOMOD.git to REPO.git:
$ cp -rvp REPO.git REPO.git-old
$ diff -r REPO.git REPO.git-old
$ rm -rf REPO.git
$ cp -rvp REPOMOD.git REPO.git
$ diff -r REPO.git REPOMOD.git
$ diff -r REPO.git REPO.git-old
v/r,
Neal
^ permalink raw reply
* Re: [minor BUG] cherry-pick -x doesn't work if a conflict occurs
From: Junio C Hamano @ 2011-01-05 18:33 UTC (permalink / raw)
To: Jay Soffian; +Cc: Uwe Kleine-König, Robin Rosenberg, git, Shawn O. Pearce
In-Reply-To: <AANLkTi==nMhcN538ekww3FEYFxhOqDqj4_Z7xg0a0B0Z@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Ah, seems to be a documented short-coming after-all:
>
> http://thread.gmane.org/gmane.comp.version-control.git/61737/focus=61933
Well, it is not.
Shawn might have accepted a documentation patch as such during my absence,
but when I originally wrote the "cherry-picked-from", it was a conscious
design decision not to carry the information forward in a conflicted case,
and the reasoning was exactly what you wrote in your first response.
Because -x has become an optional feature that a user has to explicitly
ask, I however tend to agree with Uwe that it may make sense to throw the
original commit object name in the commit log template these days. That
would allow the user to edit it further and say something like "Originally
done by Foo in commit 1234, forward ported with conflict resolution."
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again)
From: Luke Kenneth Casson Leighton @ 2011-01-05 18:07 UTC (permalink / raw)
To: Thomas Rast; +Cc: Nguyen Thai Ngoc Duy, Git Mailing List, Nicolas Pitre
In-Reply-To: <201101051813.57603.trast@student.ethz.ch>
On Wed, Jan 5, 2011 at 5:13 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Luke Kenneth Casson Leighton wrote:
>> now that of course leaves you with the problem that you now have
>> potentially hundreds if not thousands or tens of thousands of
>> .torrents to deal with, publish, find etc. etc.
>
> Umm, I'm counting 202400 objects in my git.git and 1799525 in a clone
> of linux-2.6.git. So I'm not sure how far you want to split things
> into single transfers, but going all the way down to objects will
> massively hurt performance.
yeah... this is a key reason why i came up with a protocol which
transferred the exact same pack-objects that HTTP and all the other
"point-to-point" git protocols use, to such good effect.
the problem was that i was going to rely on multiple clients being
able to genereate the exact same pack-object, given the exact same
input, and then share that pack-object. ok, that's not the problem,
that was just the plan :)
nicolas kindly pointed out, at some length, that in a distributed
environment, however, that plan was naive, becauuuse whenever you
request a pack-object for use e.g. normally with HTTP or other git
point-to-point protocol, it's generated there-and-then using
heuristics and multi-threading that pretty much guarantees that even
if you were to make the exact same request of exactly the same system,
you'd get *different* pack-objects! not to mention the fact that
different people have the same git objects stored in *different* ways
because the object stores, despite having the same commits in them,
were pulled at different times and end up with a completely different
set of git objects that represent those exact same commits that
everyone else has.
that's all a bit wordy, but you get the idea.
so, nicolas recommended a "simpler" approach, which, well, apologies
nicolas but i didn't really like it - it seemed far too simplistic and
i'm not really one for spending time doing these kinds of
"intermediate baby steps" (wrong choice of words, no offense implied,
but i'm sure you know what i mean). i much prefer to just hit all the
issues head-on, right from the start :)
so, in the intervening time since this was last discussed i've given
the pack-objects-distributing idea some thought (and NO, nicolas, just
to clarify, this is NOT grabbing the git packed objects that are
actually in the .git/objects store, so NO, this does NOT end up
bypassing security by giving people objects that are from another
branch, it really IS getting that lovely varying data which is
heuristic, store and threadnum dependent!).
the plan is to turn that variation in the git pack-objects responses,
across multiple peers, into an *advantage* not a liability. how?
like this:
* a client requiring objects from commit abcd0123 up to commit
efga3456 sends out a DHT broadcast query to all and sundry who have
commits abcd0123 and everything in between up to efga3456.
* those clients that can be bothered to respond, do so [refinements below]
* the requestor selects a few of them, and asks them to create git
pack-objects. this takes time, but that's ok. once created, the size
of the git pack-object is sent as part of the acknowledgement.
* the requestor, on receipt of all the sizes, selects the *smallest*
one to begin the p2p (.torrent) from (by asking the remote client to
create a .torrent specifically for that purpose, with the filename
abcd0123-ebga3456).
in this way you end up with not only an efficient git pack-object but
you get, to 99.5% certainty *THE* most efficient git pack-object.
distributed computing at its best :)
now, an immediately obvious refinement of this is that those .torrent
(pack-objects) "stick around", in a cache (with a hard limit defined
on the cache size of course). and so, when the client that requires a
pack-object makes the request, of course, those remote clients that
*already* have that cached pack-object for that specific commit-range
should be given first priority, to avoid other clients from having to
make massive amounts of git pack-objects.
a further refinement is of course to collect statistics on the number
of peers doing downloads at the time, prioritising those pack-objects
which are most being distributed at the time. this has fairly obvious
benefits :)
yet *another* refinement is slightly less obvious, and it's this:
there *COULD* happen to be some existing pack-objects in the cache,
not of commit abcd0123-efga3456 but in a ready-made "chain": commits
abcd01234-beef7890 packed already and in the cache, and commits
beef7890-efga3456 likewise packed already and in the cache. again:
the requestor should be informed of these, and make their mind up as
to what to do.
it gets rather more complex when you have *part* of the chain already
pre-cached (and have to work out err, i got this bit and this bit, but
i'd have to generate a git pack-object for the bit in the middle, i'll
inform the requestor of this, they can make up their mind what to do),
but again i do not imagine for one second that this would be anything
more than an intriguing coding challenge and, importantly, an
optimisation challenge for gittorrent version 3.0 somewhere down the
line, rather than an all-out absolute requirement that it must, must
be done now, now, now.
what else can i mention, that occurred to me... yeah - abandoning of
a download. if, for some reason it becomes blindingly obvious that
the p2p transfer just isn't working out, then the requestor simply
stops the process and starts again. a refinement of this, which is a
bit cheeky i know, is to keep *two* simultaneous requests and
downloads for the *exact* same git pack-object commit-chain but with
different data from different groups of peers, for a short period of
time, and then abandon one of them once it's clear which one is best.
this does seem a bit cheeky, but it has the advantage that if the one
that _was_ fastest goes tits-up, you can at least go back to the
previous one and, assuming that the cache hasn't been cleared, just
join in again. but this is _really_ something that's wayyy down the
line, for gittorrent version 4.0 or 5.0 or so.
so, can you see that a) this is a far cry from the "simplistic
transfer of blobs and trees" b) it's *not* going to overload peoples'
systems by splattering (eek!) millions of md5 sums across the internet
as bittorrent files c) it _does_ fit neatly into the bittorrent
protocol d) it combines the best of git with the best of p2p
distributed networking principles...
... all of which creates a system which people will _still_ say is a
"hammer looking for nails" :)
... right up until the point where some idiot in the USA government
decides to seize sourceforge.net, github.com, gitorious.org and
savannah.gnu.org because they contain source code of software that
MIGHT be used for copyright infringement. whilst i realise that the
only one of those that might be missed is sourceforget, you cannot
ignore the fact that the trust placed in governments and large
corporations to run the internet infrastructure is now completely
gone, and that the USA and other countries are now putting in place
hypocritical policies that put them into the same category that used
to be reserved for China, Saudi Arabia, Iran and other regimes accused
of being "Totalitarian".
thoughts, anyone? (other than on the last paragraph, please, if that's ok).
l.
^ permalink raw reply
* Re: git fails on large repo clone on intermittent, or intermittently-high-latency, connections
From: Jonathan Nieder @ 2011-01-05 17:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Zenaan Harkness, git
In-Reply-To: <m3tyhnbcf7.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Zenaan Harkness <zen@freedbms.net> writes:
>> How hard would it be to add a wget-like mode to git, for the initial
>> repo download?
>
> Very hard; tthough "resumable clone" was often requested (25%
> responders in "Git User's Survey 2010", see [1]), and there was even
> some discussion about possible implementation, it was not implemented
> yet, even as proof of concept.
>
> The trouble is that packfile is *generated for a client*, and
> bit-for-bit representation of said pack can vary (e.g. if
> multithreaded packing is enabled; usually a good idea).
That said, one possible partial solution would be to automate
generation of a seed bundle for huge repositories (with a script or
a special parameter to "git gc", maybe) and to document serving such a
seed bundle over HTTP as part of the standard setup. If this could be
made simple enough that e.g. all large repos on repo.or.cz had such a
seed bundle then I would call it a success. :)
^ permalink raw reply
* --find-copies-harder finds fewer copies/renames than -C does
From: Stefan Haller @ 2011-01-05 17:46 UTC (permalink / raw)
To: git
I was surprised to find out that --find-copies-harder can, under certain
circumstances, detect fewer renames than -C does for a given commit.
After some digging I think I understand now why this is so, but I find
it extremely unintuitive, and would like to know what other people think
about it. I had expected --find-copies-harder to always detect at least
as many copies/renames as -C, and possibly more, but never less.
The case I had is this: I have a repo with about 10.000 files, and a
commit with 14 files being moved to a different folder; half of them
where unmodified moves, the other half had one-line modifications
(similarity index 97% or so).
"git show -C --name-status <commit>" detects all 14 files as renames;
"git show --find-copies-harder --name-status <commit>" only shows the
unmodified moves as renames, the ones with modifications are shown as
delete plus add.
The reason for this seems to be the condition
"num_create * num_src > rename_limit * rename_limit" in diffcore_rename;
--find-copies-harder exeeds the limit, so it turns off inexact rename
dectection *completely*, while -C stays well below the limit.
I had expected --find-copies-harder to still do inexact rename detection
among the changed files in the commit in this case, and turn it off only
for the unmodified files; I'm not familiar enough with the code to tell
whether that would be easy to implement though.
Any thoughts?
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.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