* Re: Init on push
From: Junio C Hamano @ 2008-11-08 20:12 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Robin Rosenberg, git
In-Reply-To: <bb6f213e0811081201w22a36800j1713b91d0cf66fb2@mail.gmail.com>
"Alexander Gavrilov" <angavrilov@gmail.com> writes:
> Gitosis works by replacing the shell with a program called
> gitosis-serve, which parses and validates the incoming commands
> against the user access configuration. If it sees an unknown command,
> it will simply refuse to execute it.
If you implement a new feature by enhancing receive-pack (or anything
else), you obviously cannot use the new feature against an installation
with an older implementation, so what you said is a known. My point was
how to enhance the receiving end and what constraints we would have in
enhancing it.
> On the other hand it will automatically perform initialization before
> calling receive-pack if the user is authorized to write to a certain
> path, but the repository does not exist yet.
That's good to know. I also realize that gitosis does not need any hook
for "git init -D $there" to decide whether a new repository can be created
at requested location, as it reads the command line and makes decision
before driving the underlying command in response to the request.
On the other hand, people who enable 'push' access to their git-daemon
would need it, as the daemon would not even know who is asking for --init.
^ permalink raw reply
* Re: Init on push
From: Francis Galiegue @ 2008-11-08 20:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gf4rf6$v52$1@ger.gmane.org>
Le Saturday 08 November 2008 21:06:01 Jakub Narebski, vous avez écrit :
> Junio C Hamano wrote:
> > - Teach "-D $there" option to "git init", which does an "mkdir -p $it &&
> > chdird $it" before it does its work.
>
> Shouldn't it be "-C $there" (like make and tar)?
I agree with that. It's pretty much a standard for quite a few "command line
people", insofar as I always look for such an option in case I want to know
whether a command has the ability to chdir() to a different directory than
the current one :p
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: Init on push
From: Jakub Narebski @ 2008-11-08 20:06 UTC (permalink / raw)
To: git
In-Reply-To: <7viqqyc93w.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> - Teach "-D $there" option to "git init", which does an "mkdir -p $it &&
> chdird $it" before it does its work.
Shouldn't it be "-C $there" (like make and tar)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Configuring (future) committags support in gitweb
From: Francis Galiegue @ 2008-11-08 20:02 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200811082007.55045.jnareb@gmail.com>
Le Saturday 08 November 2008 20:07:53 Jakub Narebski, vous avez écrit :
> Francis Galiegue <fg@one2team.net> writes
> in "Need help for migration from CVS to git in one go..."
>
> > * third: also Bonsai-related; Bonsai can link to Bugzilla by
> > matching (wild guess) /\b(?:#?)(\d+)\b/ and transforming this into
> > http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have
> > this built-in? (haven't looked yet) Is this planned, or has it been
> > discussed and been considered not worth the hassle?
>
> Here below there is proposal how the committags support could look like
> for gitweb _user_, which means how to configure gitweb to use (or do not
> use) committags, how to configure committags, and how to define new
> committags.
>
Your proposal goes much further than my initial question, but I thought I'd
jump in anyway :p
> Committags are "tags" in commit messages, expanded when rendering commit
> message, like gitweb now does for (shortened) SHA-1, converting them to
> 'object' view link. It should be done in a way to make it easy
> configurable, preferably having to configure only variable part, and not
> having to write whole replacement rule.
>
> Possible committags include: _BUG(n)_, bug _#n_, _FEATURE(n),
> Message-Id, plain text URL e.g. _http://repo.or.cz_, spam protecting
> of email addresses, "rich text formatting" like *bold* and _underline_,
> syntax highlighting of signoff lines.
>
What do you mean with "not having to write whole replacement rule"?
> I think it would be good idea to use repository config file for
> setting-up repository-specific committags, and use whatever Perl
> structure for global configuration. The config language can be
> borrowed from "drivers" in gitattributes (`diff' and `merge' drivers).
>
> So the example configuration could look like this:
>
> [gitweb]
> committags = sha1 signoff bugzilla
>
> [committag "bugzilla"]
> match = "\\b(?:#?)(\\d+)\\b"
> link = "http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1"
>
> where 'sha1' and 'signoff' are built-in committags, committags are
> applied in the order they are put in gitweb.committags;
I don't understand what the "signoff" builtin is : is that a link to see only
commits "Signed-off-by:" a particular person?
If so, might I suggest that an "alt" tells "Only show commits signed off by
this person"?
And also, what about the sha1 builtin? AFAIK, a SHA1 can point to a commit, a
tree, and others... In fact, it points to any of these right now, but how
would you tell apart these different SHA1s in a commit message? The only
obvious use I see for it is the builtin "Revert ..." commit message, that the
commiter _can_ override...
Or would that be:
my $sha1_re = qr/[a-z[0-9]{40}/;
/(?:(?i:commit\s+))?\b($sha1_re)\b/ => [link to commit $1]
/(?:(?i:tree\s+))\b($sha1_re)\b)/ => [link to tree $1]
/(?:(?:tag\s+))\b($sha1_re)\b)/ => [link to tag $1]
Finally, is there any reason to think that a sha1 or signoff committag will
ever need to be overriden in some way?
> possible actions
> for committag driver include:
> * link: replace $match by '_<a href="$link">_$match_</a>_'
> * html: replace $match by '_$html_'
> * text: replace $match by '$text'
> where '_a_' means that 'a' is treated as HTML, and is not expanded
> further, and 'b' means that it can be further expanded by later
> committags, and finally is HTML-escaped (esc_html).
>
What use do you see for the html match? Just asking...
And I don't see what you '_a_' and '_b_' are about...
--
fge
^ permalink raw reply
* Re: Init on push
From: Alexander Gavrilov @ 2008-11-08 20:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, git
In-Reply-To: <7viqqyc93w.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 8, 2008 at 10:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> An easy alternative would be to issue the usual "mkdir && git init" shell
> script before spawning receive-pack. This will limit the feature to
> pushing over the ssh transport, and pushing over the git protocol against
> a loose git-daemon will not be able to support it. Also I suspect this
> will break sites managed by gitosis, where all repositories are held under
> the same UNIX user identity, differenciated only via an environment it
> sets based on the ssh key used to make the connection.
Gitosis works by replacing the shell with a program called
gitosis-serve, which parses and validates the incoming commands
against the user access configuration. If it sees an unknown command,
it will simply refuse to execute it.
On the other hand it will automatically perform initialization before
calling receive-pack if the user is authorized to write to a certain
path, but the repository does not exist yet.
Alexander
^ permalink raw reply
* Re: Init on push
From: Junio C Hamano @ 2008-11-08 19:26 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200811081708.45672.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> git remote add someremote someurl
> git push --init someremote/someurl
>
> The implementation would invoke receive pack on the receiving side with
> an --init option. On the server side the repository would be created and
> initialized just as one had executed and mkdir and git init --bare.
We saw this quite a number of times. I think it's about time we did
something about it.
But I do not think it is a reasonable design to give receive-pack such an
option.
An easy alternative would be to issue the usual "mkdir && git init" shell
script before spawning receive-pack. This will limit the feature to
pushing over the ssh transport, and pushing over the git protocol against
a loose git-daemon will not be able to support it. Also I suspect this
will break sites managed by gitosis, where all repositories are held under
the same UNIX user identity, differenciated only via an environment it
sets based on the ssh key used to make the connection.
I wonder if you can take a middle ground alternative:
- Make "git push --init [--shared] $site:$there" and "git push --init
[--shared] git://$site/$there" run "git init -D [--shared] $there"
followed by "git receive-pack $there";
- Teach "-D $there" option to "git init", which does an "mkdir -p $it &&
chdird $it" before it does its work.
- Teach "git daemon" about the "init" service, which is disabled by
default, and can be enabled just like you can enable receive-pack
there.
If sites like repo.or.cz, github, or managed with gitosis want to use
this, I think you might further need to give "git init -D $there" a hook
to control who can create new repositories at which location (gitosis is
the most interesting case, as described above).
^ permalink raw reply
* [RFC] Configuring (future) committags support in gitweb
From: Jakub Narebski @ 2008-11-08 19:07 UTC (permalink / raw)
To: git; +Cc: Francis Galiegue
Francis Galiegue <fg@one2team.net> writes
in "Need help for migration from CVS to git in one go..."
> * third: also Bonsai-related; Bonsai can link to Bugzilla by
> matching (wild guess) /\b(?:#?)(\d+)\b/ and transforming this into
> http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have
> this built-in? (haven't looked yet) Is this planned, or has it been
> discussed and been considered not worth the hassle?
Here below there is proposal how the committags support could look like
for gitweb _user_, which means how to configure gitweb to use (or do not
use) committags, how to configure committags, and how to define new
committags.
Committags are "tags" in commit messages, expanded when rendering commit
message, like gitweb now does for (shortened) SHA-1, converting them to
'object' view link. It should be done in a way to make it easy
configurable, preferably having to configure only variable part, and not
having to write whole replacement rule.
Possible committags include: _BUG(n)_, bug _#n_, _FEATURE(n),
Message-Id, plain text URL e.g. _http://repo.or.cz_, spam protecting
of email addresses, "rich text formatting" like *bold* and _underline_,
syntax highlighting of signoff lines.
I think it would be good idea to use repository config file for
setting-up repository-specific committags, and use whatever Perl
structure for global configuration. The config language can be
borrowed from "drivers" in gitattributes (`diff' and `merge' drivers).
So the example configuration could look like this:
[gitweb]
committags = sha1 signoff bugzilla
[committag "bugzilla"]
match = "\\b(?:#?)(\\d+)\\b"
link = "http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1"
where 'sha1' and 'signoff' are built-in committags, committags are
applied in the order they are put in gitweb.committags; possible actions
for committag driver include:
* link: replace $match by '_<a href="$link">_$match_</a>_'
* html: replace $match by '_$html_'
* text: replace $match by '$text'
where '_a_' means that 'a' is treated as HTML, and is not expanded
further, and 'b' means that it can be further expanded by later
committags, and finally is HTML-escaped (esc_html).
What do you think about this?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: pull --preserve-merges
From: Stephen Haberman @ 2008-11-08 17:57 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Johannes Schindelin, git
In-Reply-To: <200811081807.53199.fg@one2team.net>
Replying to both Johannes and Francis...
> > > Awhile ago I brought up wanting to have a "rebase with preserve merges"
> > > option for `git pull`
> >
> > That might be something you want, but you cannot call it
> >
> > git pull --preserve-merges
> >
> > since everybody used to "pull = fetch && merge" would go "Huh? A merge
> > _does_ preserve merges".
Ah, right, sorry, Johannes, I know it only makes sense in the context if
--rebase is also being in use, I was just being too brief.
> > If at all, you could call it "--rebase=preserve-merges".
I'd be fine with that, I had not thought of it.
> Why not --rebase --keep-merges? Personnally, I think it makes things clearer
> since in general options are either standalone or have a value.
I originally had --rebase --preserve-merges in mind because it matches
the existing -p/--preserve-merges flag that git rebase has that I'd
like git pull to just pass along.
If they were separate flags, passing just --preserve-merges without
--rebase should likely report an error. Probably the same thing if
someone sets `branch.name.preservemerges` but `branch.name.rebase` is
not set.
Unless instead of separate config parameters, `branch.name.rebase` uses
Johannes's suggestion and has separate values...true or false or
preserve-merges. That would probably better parallelize with the
--rebase=preserve-merges style command line argument.
Between one flag/config parameter or two flags/config parameters, I
could go either way and would be willing to patch together either one
to get it in.
Thanks,
Stephen
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-11-08 17:27 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Steve Frécinaux, Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <4915A3CB.5010909@op5.se>
[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]
On Sat, Nov 08, 2008 at 02:35:55PM +0000, Andreas Ericsson wrote:
> Steve Frécinaux wrote:
> > Just a random question: is there a reason why you have put all the
> > .h in a separate includes/ directory instead of relying on the
> > install target to put the include files at the right place ?
> > To me it makes it much harder to hack on the files as one is always
> > required to switch between both directories...
>
> I agree with this, but as I guess Shawn will do roughly 45 times more
> work on it than me (according to current commit-count in git.git), I'll
> live with it.
I don't, modifying the public includes may break the ABI and the API.
I believe it to be a good practice to put them in a separate directory
so that people modifying them will know this particular header is
public. Yes you can name your private headers differently, but it's not
really the same, it doesn't make editing public headers hard, and it has
to. People modifying them _have_ to thing "err why am I modifying this
specific header in the first place" before doing anything in it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Init on push
From: Robin Rosenberg @ 2008-11-08 16:08 UTC (permalink / raw)
To: git
Hi,
I am missing the ability to do this (command line or GUI)
git remote add someremote someurl
git push --init someremote/someurl
The implementation would invoke receive pack on the receiving side with
an --init option. On the server side the repository would be created and
initialized just as one had executed and mkdir and git init --bare.
The target audience is people who are either lazy (like me) or "shellofobic" users.
GUI's would get an extra check box.
This could be extended by passing options to the init switch with init options
for the server side, say --init="--shared=false".
Could a patch for this be acceptable?
-- robin
^ permalink raw reply
* Re: pull --preserve-merges
From: Francis Galiegue @ 2008-11-08 17:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stephen Haberman, git
In-Reply-To: <alpine.DEB.1.00.0811081607300.30769@pacific.mpi-cbg.de>
Le Saturday 08 November 2008 16:08:41 Johannes Schindelin, vous avez écrit :
> Hi,
>
> On Fri, 7 Nov 2008, Stephen Haberman wrote:
> > Awhile ago I brought up wanting to have a "rebase with preserve merges"
> > option for `git pull`
>
> That might be something you want, but you cannot call it
>
> git pull --preserve-merges
>
> since everybody used to "pull = fetch && merge" would go "Huh? A merge
> _does_ preserve merges".
>
> If at all, you could call it "--rebase=preserve-merges".
>
Why not --rebase --keep-merges? Personnally, I think it makes things clearer
since in general options are either standalone or have a value.
--
fge
^ permalink raw reply
* Re: absurdly slow git-diff
From: Davide Libenzi @ 2008-11-08 16:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Abhijit Menon-Sen, Pierre Habouzit,
Git Mailing List
In-Reply-To: <7v7i7eeqcz.fsf@gitster.siamese.dyndns.org>
On Fri, 7 Nov 2008, Junio C Hamano wrote:
> Davide Libenzi <davidel@xmailserver.org> writes:
>
> > Yeah, similar. Mine is below. There's one less branch in the for loops.
>
> Thanks, will apply like this, but I am not sure if you meant windowN or
> just window...
Whoops, just WINDOW.
- Davide
^ permalink raw reply
* [PATCH 7/7 v3 updated] bisect: use "--bisect-replace" options when checking merge bases
From: Christian Couder @ 2008-11-08 15:33 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 4 ++--
t/t6035-bisect-replace.sh | 10 ++++++++++
2 files changed, 12 insertions(+), 2 deletions(-)
This is the same as [PATCH 7/7 v3] but with a test case
added.
diff --git a/git-bisect.sh b/git-bisect.sh
index 1daa81c..87e186f 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -401,7 +401,7 @@ check_merge_bases() {
_bad="$1"
_good="$2"
_skip="$3"
- for _mb in $(git merge-base --all $_bad $_good)
+ for _mb in $(git merge-base --all --bisect-replace $_bad $_good)
do
if is_among "$_mb" "$_good"; then
continue
@@ -436,7 +436,7 @@ check_good_are_ancestors_of_bad() {
# Bisecting with no good rev is ok
test -z "$_good" && return
- _side=$(git rev-list $_good ^$_bad)
+ _side=$(git rev-list --bisect-replace $_good ^$_bad)
if test -n "$_side"; then
# Return if a checkout was done
check_merge_bases "$_bad" "$_good" "$_skip" || return
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
index 8fe7cc5..dabf1ae 100755
--- a/t/t6035-bisect-replace.sh
+++ b/t/t6035-bisect-replace.sh
@@ -144,6 +144,16 @@ test_expect_success '"git merge-base --bisect-replace" works' '
test "$hash" = "$HASH1"
'
+test_expect_success 'git bisect works when starting on the replace branch' '
+ git bisect start $HASH7 $HASHFIX3 &&
+ test "$(git rev-parse --verify HEAD)" = "$HASH5" &&
+ git bisect bad &&
+ test "$(git rev-parse --verify HEAD)" = "$HASHFIX4" &&
+ git bisect good > my_bisect_log.txt &&
+ grep "$HASH5 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
#
#
test_done
--
1.6.0.3.620.ge1fc
^ permalink raw reply related
* Re: How it was at GitTogether'08 ?
From: Jakub Narebski @ 2008-11-08 15:31 UTC (permalink / raw)
To: David Symonds; +Cc: git, Johannes Schindelin
In-Reply-To: <ee77f5c20811072108o21f97c97i8174f4f7ecd67030@mail.gmail.com>
On Sat, 8 Nov 2008, David Symonds wrote:
> On Fri, Nov 7, 2008 at 5:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> Here's my thoughts on some of these talks.
>
> > Mon, Oct 27, 2008
> > -----------------
> > * Dscho: Contributing with Git
> > http://www.youtube.com/watch?v=j45cs5_nY2k
>
> It was a good intro, but I was expecting a few more non-GitTogether
> people. We had quite a large room, but there was only about a dozen
> other people who came along. I don't know whether that was the fault
> of the timing, lack of advertising, or a lack of interest.
By the way, it would be nice to have transcript for this talk, just
like there is for Linus talk:
http://git.or.cz/gitwiki/LinusTalk200705Transcript
(but this would take some doing).
It would be also nice to have slides for the talk available somewhere,
just like slides for "Git Chronicle".
> > * Junio: Git Chronicle
> >
> > blog: Junio went though a sort of statistical history of the Git project
> > that was fascinating (turns out there are still about 220 lines of code
> > still around from Linus original first commit).
>
> This was really interesting. It would be great to put this on a
> general web page instead of in a PDF.
Something like Sam Vilain slides from "perl.git" talk?,
http://utsl.gen.nz/talks/perl-history/slides/
It shouldn't be that hard, depending on the original program the slides
were made... well, it was made in Impress from OpenOffice.org 2.4; it
might have export to (X)HTML + images, and to SWF (Flash presentation).
> > * Petr: Renames Again and Again and Again
> >
> > IRC: detection of wholesame renames of directories (WIP) and '--follow'
> > limitation were mentioned, but outcome is unclear; pasky plans to hack
> > together some patch implementing explicit renames hinting
>
> One thing I didn't get around to bringing up: one of the benefits of
> diff-time rename detection that is often touted is that algorithms can
> improve over time. Do folk here know whether that has actually
> happened recently, in a general way? Do people actually expect major
> improvements in the future?
If I remember correctly there was at least one improvement in rename
detection, namely better talking into account filename similarity score,
so for example similar files moved (or copied) didn't get marked as
coming from one source (and rest deleted).
> > * Tom: GitHub
> >
> > IRC: a tour, some history, and insight into how it works; some nice
> > gimmicks, such as "gist" (a git backed pastebin), or like network graphs
> > (look graphically at forks of a repository).
> >
> > blog: Tom got to demonstrate GitHub and Gist to the group, most of whom
> > are very command line oriented and had not used either before.
>
> The demo of iGitHub (an iPhone app that can act as a clone/push
> target) looked really cool, if it can get further development. It
> could potentially be really handy for travellers who could push to
> their iPhone, and then push from there to an internet server.
iGitHub has nothing to do with GitHub; I think you put the comment in
a wrong place; the iGitHub (or iGit / iGitRouter) was a separate talk
in "Lighting Round Talks" next day.
> > * Scott: Linkable Library
> >
> > blog: got to talk about the need for a linkable git library
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/99608
>
> It's good to see this starting to get wider traction. I think we
> discussed that there could be benefits to git itself, beyond just
> helping other programs access git repositories faster than fork/exec.
What benefits would be those? Current design of "fire and forget",
which stopped libification efforts till now was used for a reason...
> > * Sam: perl.git
> >
> > blog: Sam demonstrated the work he went through to import 20 years of Perl
> > history into the git repository that the Perl team is just now finishing
> > transitioning to from Perforce.
> >
> > http://utsl.gen.nz/talks/perl-history/slides/
>
> It was very cool to see old-school email addresses like <isis!aburt>
> in git, handled just fine.
This is not suprising, as Git treats committer and author email data
as opaque data, not analysing it at all (some commits from early
versions of git might not have this data at all, IIRC).
> > * Tim: Git as a Media Repository
> > http://www.thousandparsec.net/~tim/media+git.pdf
>
> This has kicked off some mailing list discussion; I think this can be
> a major weak point for git, since checking out only a subtree (and
> only the latest revision) is the common SVN way, which copes with
> media repositories and the like just fine.
Well, you can workaround this weakness by (ab)using submodules...
...and one should always remember that casual partial checkouts
interfere a bit with whole-tree commits.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Repo corrupted somehow?
From: Andrew Arnott @ 2008-11-08 15:19 UTC (permalink / raw)
To: Eyvind Bernhardsen; +Cc: Daniel Barkalow, git
In-Reply-To: <77005B51-0170-42EC-BBA7-DCF39C7CFC5E@orakel.ntnu.no>
I thought that autocrlf always 'added' CRLF instead of adding merely
CR. Dang. I'd rather have CRLF text files.
On Wed, Nov 5, 2008 at 4:26 AM, Eyvind Bernhardsen
<eyvind-git@orakel.ntnu.no> wrote:
> On 5. nov.. 2008, at 06.56, Daniel Barkalow wrote:
>
>> On Tue, 4 Nov 2008, Andrew Arnott wrote:
>>
>>> It was the CRLF conversion. When I played around with
>>> git config --global core.autocrlf true/false
>>> I got the problem to eventually go away.
>>>
>>> Thanks for all your responses.
>>
>> It's still worth debugging further, because git should know that it wrote
>> the files differently and not see that as changes. It's not too helpful to
>> have autocrlf if it causes this problem.
>
> I think I know what this is. If a repository contains files with CRLFs,
> those files will show as modified when core.autcorlf is true (if you commit
> them, the CRLFs will be converted to CRs in the repository, so in a sense
> they _are_ modified). Try turning autocrlf back on, cloning the repository,
> then touching all the files (to make git check them for changes) and see if
> you get the same problem.
>
> I proposed an alternative autocrlf implementation on the list a while back:
> making it an attribute instead of a configuration setting and adding a
> configuration setting to tell git which line ending is preferred when the
> autocrlf attribute is set.
>
> That would allow you to turn on autocrlf and let git convert all CRLFs to
> CRs in a single commit, thus converting a repository with CRLFs to one that
> can be used with autocrlf in a versioned way. In theory that lets you check
> out new commits with EOL conversion while old commits will be left alone
> (avoiding the problem you saw), but since .gitattributes is read from the
> working directory and not the tree to be checked out, it doesn't work
> perfectly.
>
> I implemented the easy bit (reading autocrlf from .gitattributes), but for
> various reasons the patch has just been gathering dust in my private git.git
> repo. Maybe I should dust it off :)
> --
> Eyvind
>
>
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Johannes Schindelin @ 2008-11-08 15:12 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <20081108142756.GC17100@coredump.intra.peff.net>
Hi,
On Sat, 8 Nov 2008, Jeff King wrote:
> On Fri, Nov 07, 2008 at 03:16:53PM -0800, Junio C Hamano wrote:
>
> > > The FAQ even says "don't do this until you know what you are doing."
> > > So the safety valve is configurable, so that those who know what
> > > they are doing can switch it off.
> >
> > "We are breaking your existing working setup but you can add a new
> > configuration to unbreak it" should not be done lightly. I think as
> > the end result it is a reasonable thing to aim for for this particular
> > feature, but we do need a transition plan patch in between that
> > introduces a step that warns but not forbids. We can ship 1.6.1 with
> > it and then switch the default to forbid in 1.6.3, for example.
>
> Yeah, I was kind of hoping we could assume that anybody relying on this
> behavior was somewhat insane, and wouldn't be too upset when it broke.
I think I have a repository with "git read-tree -u -m HEAD" as update hook
for that kind of behavior.
But I will not be the person responsible to keep that behavior, if I am
the only one relying on it.
I very much like the approach of defaulting to "warn" for quite some time
(but setting the variable to "refuse" in git-init) and then adapt the
default after some time.
Ciao,
Dscho
^ permalink raw reply
* Re: pull --preserve-merges
From: Johannes Schindelin @ 2008-11-08 15:08 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git
In-Reply-To: <20081107160138.aa96405c.stephen@exigencecorp.com>
Hi,
On Fri, 7 Nov 2008, Stephen Haberman wrote:
> Awhile ago I brought up wanting to have a "rebase with preserve merges"
> option for `git pull`
That might be something you want, but you cannot call it
git pull --preserve-merges
since everybody used to "pull = fetch && merge" would go "Huh? A merge
_does_ preserve merges".
If at all, you could call it "--rebase=preserve-merges".
Ciao,
Dscho
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-11-08 14:35 UTC (permalink / raw)
To: Steve Frécinaux; +Cc: Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <4915939B.1070306@gmail.com>
Steve Frécinaux wrote:
> Shawn O. Pearce wrote:
>> During the GitTogether we were kicking around the idea of a ground-up
>> implementation of a Git library. This may be easier than trying
>> to grind down git.git into a library, as we aren't tied to any
>> of the current global state baggage or the current die() based
>> error handling.
>>
>> I've started an _extremely_ rough draft. The code compiles into a
>> libgit.a but it doesn't even implement what it describes in the API,
>> let alone a working Git implementation. Really what I'm trying to
>> incite here is some discussion on what the API looks like.
>
> Just a random question: is there a reason why you have put all the .h in
> a separate includes/ directory instead of relying on the install target
> to put the include files at the right place ?
>
> To me it makes it much harder to hack on the files as one is always
> required to switch between both directories...
I agree with this, but as I guess Shawn will do roughly 45 times more
work on it than me (according to current commit-count in git.git), I'll
live with it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Jeff King @ 2008-11-08 14:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sam Vilain
In-Reply-To: <7v3ai3f7oa.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 07, 2008 at 03:16:53PM -0800, Junio C Hamano wrote:
> > The FAQ even says "don't do this until you know what you are doing." So
> > the safety valve is configurable, so that those who know what they are
> > doing can switch it off.
>
> "We are breaking your existing working setup but you can add a new
> configuration to unbreak it" should not be done lightly. I think as the
> end result it is a reasonable thing to aim for for this particular
> feature, but we do need a transition plan patch in between that introduces
> a step that warns but not forbids. We can ship 1.6.1 with it and then
> switch the default to forbid in 1.6.3, for example.
Yeah, I was kind of hoping we could assume that anybody relying on this
behavior was somewhat insane, and wouldn't be too upset when it broke.
But you're probably right that we should be more conservative. I'll
rework it with a "yes/no/warn" option for the config, and we can set it
to "warn" (and those who really do want it can shut off the warning with
"no"). Or we can even start with just leaving it on "no", but I think
the deprecation period should begin when we switch it to "warn".
> > Patch 4/4 is the interesting one. 1/4 is a cleanup I saw while fixing
> > tests. 2/4 is a cleanup to prepare for 3/4. And 3/4 fixes a bunch of
> > tests which were inadvertently doing such a push (but didn't care
> > because they didn't look at the working directory).
>
> I wonder if you can use the tests 3/4 touches as the test for your "keep
> existing setup" configuration variable, pretending that they are old
> timer's repositories?
Yes, they do break with 4/4 applied without 3/4 (that was how I found
them, but "git rebase -i" let me pretend I had the proper foresight. ;)
). We can keep 3/4 back until the switch from "warn" to "yes", if that's
what you are suggesting.
-Peff
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Jeff King @ 2008-11-08 14:17 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Jakub Narebski
In-Reply-To: <200811080441.25796.johan@herland.net>
On Sat, Nov 08, 2008 at 04:41:25AM +0100, Johan Herland wrote:
> > * Discussion on notes
>
> Can someone elaborate on this? AFAIK, notes have popped up on this list
> often enough that I'm convinced it would be a _really_ useful feature. The
> only drawback I was aware of, was the lack of an efficient implementation,
> but then Jeff comes out of the blue and posts some interesting numbers [1]
> a week or so ago. Does this mean there are no remaining obstacles?
>
> [1]: http://article.gmane.org/gmane.comp.version-control.git/99415
The discussion was along the lines of "here are some more cool things we
could do, if we had notes." I don't remember the specifics of the cool
things, but they were related to annotating patches with review
information. Shawn can probably elaborate more.
That led to a "notes as a tree are nice, but too slow because looking up
a tree entry is linear" (and obviously you do a ton of lookups in the
notes tree during "git log"). Dscho had posted an implementation with a
persistent notes cache long ago. Since I failed to actually look at
that, I started on a slightly different approach, which is simply doing
an in-memory hash table to speedup the notes tree. And those are the
numbers and patch I posted.
My eventual plan was to re-work Dscho's patches with this performance
approach. But it is not at the top of my queue, so if somebody else
wanted to pick it up, I would be very happy. Everything I have done so
far is in the post you referenced.
The only other thing I remember discussing was notes namespaces. The two
obvious approaches are:
1. a separate ref for each notes namespace, with each note ending up a
blob in a tree. So you might have refs/notes/acked-by:$SHA1 as a
blob.
2. one notes ref, with the notes tree pointing a sub-tree that has
named entries, one for each note type. So you might have
refs/notes:$SHA1/acked-by as a blob.
The advantage of '1' is that it keeps your different note types
separate, which means it is easy to distribute one type but not the
other. The advantage of '2' is that I do one lookup per-commit, and then
I can see all of the notes, which keeps performance nice when you want
to annotate with several note types.
After some discussion, I think Dscho and I came to the conclusion that
supporting both might be desirable. And it should be pretty
straightforward. You can just have multiple note refs (but default to a
"main" one), and within each one, either point to a tree or blob (and we
will see which and use it appropriately).
And then depending on which notes the user wants, they can refer to them
appropriately. My suggestion for naming (and this wasn't discussed
earlier, so Dscho has not endorsed this) would be something like
"$X:$Y", which would mean "to get the notes for $SHA1, look at the tree
in refs/notes/$X for the file $SHA1/$Y". If $Y is empty, then expect
$SHA1 to be a blob (if it's a tree, maybe look at $SHA1/default). If
"$X" is empty, then use "refs/notes/default". If there is no colon,
assume we have "$Y".
So you could have a bunch of notes in some "main" namespace just by
calling them some name; without a name, you get some "default" note. But
if you wanted a separate database (say, for SVN information), you could
use "svn:" or "svn:name".
-Peff
^ permalink raw reply
* Re: libgit2 - a true git library
From: Steve Frécinaux @ 2008-11-08 13:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Scott Chacon
In-Reply-To: <20081031170704.GU14786@spearce.org>
Shawn O. Pearce wrote:
> During the GitTogether we were kicking around the idea of a ground-up
> implementation of a Git library. This may be easier than trying
> to grind down git.git into a library, as we aren't tied to any
> of the current global state baggage or the current die() based
> error handling.
>
> I've started an _extremely_ rough draft. The code compiles into a
> libgit.a but it doesn't even implement what it describes in the API,
> let alone a working Git implementation. Really what I'm trying to
> incite here is some discussion on what the API looks like.
Just a random question: is there a reason why you have put all the .h in
a separate includes/ directory instead of relying on the install target
to put the include files at the right place ?
To me it makes it much harder to hack on the files as one is always
required to switch between both directories...
^ permalink raw reply
* [question] git svn fail to fetch GCC source due to index mismatch
From: dennis @ 2008-11-07 20:24 UTC (permalink / raw)
To: git
HI:
I have problem when use git svn fetch command to
retrieve the GCC source code.
It says index mismatch, then abort, any suggestion?
$git svn fetch
Index mismatch: 98ba56dbceddf50ebfab9e4649e9b1b1a319b377 !=
4f40f4619690f89454614be0eba63d584d25523e
rereading 19e22aa4cbc9f7e3667243481f33c859e3bba358
Found possible branch point: svn://gcc.gnu.org/svn/gcc/trunk =>
svn://gcc.gnu.org/svn/gcc/trunk, 130802
Initializing parent: git-svn@130802
Found branch parent: (git-svn) 9a08076e1ad241080838d547f64a2a9aceb083ca
Index mismatch: 4f40f4619690f89454614be0eba63d584d25523e !=
98ba56dbceddf50ebfab9e4649e9b1b1a319b377
rereading 9a08076e1ad241080838d547f64a2a9aceb083ca
Following parent with do_switch
Malformed network data: Malformed network data at
/usr/libexec/git-core/git-svn line 2340
$git branch -a
git-svn
git-svn@130802
^ permalink raw reply
* [PATCH] checkout: Don't crash when switching away from an invalid branch.
From: Alexandre Julliard @ 2008-11-08 12:03 UTC (permalink / raw)
To: git
When using alternates, it is possible for HEAD to end up pointing to
an invalid commit. git checkout should be able to recover from that
situation without crashing.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
builtin-checkout.c | 8 ++++----
t/t2011-checkout-invalid-head.sh | 18 ++++++++++++++++++
2 files changed, 22 insertions(+), 4 deletions(-)
create mode 100755 t/t2011-checkout-invalid-head.sh
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 57b94d2..06904c3 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -47,7 +47,7 @@ static int post_checkout_hook(struct commit *old, struct commit *new,
memset(&proc, 0, sizeof(proc));
argv[0] = name;
- argv[1] = xstrdup(sha1_to_hex(old->object.sha1));
+ argv[1] = xstrdup(sha1_to_hex(old ? old->object.sha1 : null_sha1));
argv[2] = xstrdup(sha1_to_hex(new->object.sha1));
argv[3] = changed ? "1" : "0";
argv[4] = NULL;
@@ -492,10 +492,10 @@ static void update_refs_for_switch(struct checkout_opts *opts,
}
old_desc = old->name;
- if (!old_desc)
+ if (!old_desc && old->commit)
old_desc = sha1_to_hex(old->commit->object.sha1);
strbuf_addf(&msg, "checkout: moving from %s to %s",
- old_desc, new->name);
+ old_desc ? old_desc : "(invalid)", new->name);
if (new->path) {
create_symref("HEAD", new->path, msg.buf);
@@ -551,7 +551,7 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
* a new commit, we want to mention the old commit once more
* to remind the user that it might be lost.
*/
- if (!opts->quiet && !old.path && new->commit != old.commit)
+ if (!opts->quiet && !old.path && old.commit && new->commit != old.commit)
describe_detached_head("Previous HEAD position was", old.commit);
if (!old.commit) {
diff --git a/t/t2011-checkout-invalid-head.sh b/t/t2011-checkout-invalid-head.sh
new file mode 100755
index 0000000..764bb0a
--- /dev/null
+++ b/t/t2011-checkout-invalid-head.sh
@@ -0,0 +1,18 @@
+#!/bin/sh
+
+test_description='checkout switching away from an invalid branch'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo hello >world &&
+ git add world &&
+ git commit -m initial
+'
+
+test_expect_success 'checkout master from invalid HEAD' '
+ echo 0000000000000000000000000000000000000000 >.git/HEAD &&
+ git checkout master --
+'
+
+test_done
--
1.6.0.3.669.g76740
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: [PATCH 1/2] diffcore-rename: support rename cache
From: Nguyen Thai Ngoc Duy @ 2008-11-08 12:00 UTC (permalink / raw)
To: Jeff King; +Cc: Yann Dirson, Junio C Hamano, git
In-Reply-To: <20081108114719.GA4989@sigill.intra.peff.net>
On 11/8/08, Jeff King <peff@peff.net> wrote:
> On Sat, Nov 08, 2008 at 10:24:10AM +0100, Yann Dirson wrote:
>
> > Well, it could be that an out-of-pathspec pair would have a better
> > score than an in-pathspec one. Maybe cache recording should be turned
> > off when doing pathspec limitation ?
>
>
> One thing I notice is that the cache works at the level of "here is the
> best rename for this commit." Maybe it could go down a level and say
> "here is the inexact rename score between these blobs". Then you would
> still find the best score between two blobs each time, but save the
> really computationally intensive part (which is comparing the actual
> _content_ of the blobs).
> That should work in the face of path limiting or any other option,
> because it is caching something immutable: this is the similarity score
> between two pieces of content. And then you get arbitrary tree-to-tree
> speedups for free, since such a cache would be valid for every commit.
I did that and realized the cost was not from each diff, in
--find-copies-harder case, but from the number of diffs you had to do.
Even with exact matching on linux-2.6.git, it could take significant
time (it was about 5 minutes in no-cache case, 1 minute without exact
match cache, and less than 1 sec if everything is cached).
>
> The downsides are:
>
> - your cache is potentially bigger, since you are caching the score of
> every pair you look at, instead of just "good" pairs (OTOH, you are
> not doing a per-commit cache, which helps reduce the size)
It is huge if you accidentially add --find-copies-harder to your
command, considering that every new file will be compared against
every files in tree (about 25k).
> - you can still "lie" about a score to pre-seed imported SVN renames,
> but such lying will actually apply to all commits.
--
Duy
^ permalink raw reply
* Re: [minor usability suggestion] git rebase <upstream> --onto <newbase> ?
From: Ingo Molnar @ 2008-11-08 11:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vy6zvfdp5.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > "git log origin/master -p" works, though.
>
> That's an accident. Do not rely on it.
hm, i frequently rely on tacking-on options after the fact, especially
the -- ones.
Just like the best workflow is append-mostly, command parameters are
often added append-only as well, without jumping back and forth in the
command line to edit the command.
Path or brach names starting with '--' are weird anyway, so isnt this
a reasonable expectation? I hope i'm not misunderstanding something
here.
Ingo
^ 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