* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-25 9:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Paul Mackerras
In-Reply-To: <7vabtlf7tf.fsf@assigned-by-dhcp.cox.net>
On 7/25/07, Junio C Hamano <gitster@pobox.com> wrote:
> I've been re-reviewing recent patches, and this is one of them.
Thanks for pushing to pu. Please tell me if you want me to send you a
patch to update to what we have discussed, specifically using "length
unknown" and changing the name to --show-lengths.
> However, I am wondering if this is an intended behaviour...
>
> : git.git master; ./git-log --log-size --abbrev-commit --pretty=oneline \
> ko/master..master
> 9d468ac... log size 47
> Add --log-size to git log to print message size
> ca193cf... log size 40
Well, the patch should be used to speedup the parsing by tools because
you can skip big part of the record and jump directly to the beginning
of the next one. So IMHO I don't see a lot of sense in using it
together with --pretty=oneline.
Anyway only default options should be guaranteed to behave correctly
with all the other options. In general, responsibility for what you
see on the screen it's on the tips of user's fingers. IMHO
responsibility of git is of not crashing and do not show incorrect
info, not that the info should be useful.
Paul, I don't know gitk and Tcl to being able to answer myself, but I
would like to know if this new option could be useful also for gitk.
This option, after the first line, gives the size of the following
part of the record. Does this allow you to delay the parsing of the
biggest part of the commit record?
Author name, date, log title, log message could be read only when it's
needed, so that after reading the first couple lines of a commit you
can point directly to the beginning of the next one skipping the rest.
Marco
^ permalink raw reply
* [PATCH] Document --unified/-U option
From: Robin Rosenberg @ 2007-07-25 10:08 UTC (permalink / raw)
To: junkio; +Cc: git
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Documentation/diff-options.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 1689c74..050e5fd 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -4,6 +4,13 @@
-u::
Synonym for "-p".
+-U<n>::
+ Shorthand for "--unified=<n>".
+
+--unified=<n>::
+ Generate diffs with <n> lines of context instead of
+ the usual three. Implies "-p".
+
--raw::
Generate the raw format.
^ permalink raw reply related
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Steven Grimm @ 2007-07-25 10:22 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marius Storm-Olsen, Alex Riesen, Junio C Hamano, Shawn O. Pearce,
Julian Phillips, git
In-Reply-To: <Pine.LNX.4.64.0707251024390.14781@racer.site>
Johannes Schindelin wrote:
> So this leaves me with the question: do Windows users really want a proper
> native Windows support for Git? If the answer is yes, why don't they _do_
> (as in "not talk") something about it?
>
I'm not a Windows user, but I know some, so I can maybe answer this:
They do want that, but what they primarily want is a good DVCS they can
use without trouble. I know at least two Windows people who took a look
at the Win32 git, had trouble with it, then looked at Mercurial (which,
whatever opinions you might have about it, does work better on Windows)
and just stuck with that since it met their needs.
The fact that Mercurial exists is a big disincentive for Windows people
to work on git; unless they specifically want to interoperate with an
existing git repository, hg gives them a lot of the same features that
we enjoy in git land. And they don't have to fiddle with MinGW or Cygwin
or anything like that. The distance between git and hg is small enough
in their minds that it's not worth the unknown amount of effort to work
on making git run better.
At least, that's my take on it. Maybe an actual Windows git user will
tell me I'm full of it...
-Steve
^ permalink raw reply
* Windows support
From: Dmitry Kakurin @ 2007-07-25 10:35 UTC (permalink / raw)
To: git
How serious are you guys about Windows support?
I'm talking fully-functional port, not Cygwin.
I did a lot of searching for a new SCM to switch to (from Perforce).
And Git is my #1 choice. I love it's internals design and it's
expressive power. I've also tested git-p4 and it has worked like a
charm with my depot (with few tweaks that I may contribute later).
But I do all my work on Windows so I need Git-For-Windows-Done-Right :-).
The current mingw port is not there yet.
Transition to the new SCM must happen now, so basically I have 2 choices:
1. Survive for a few months with the current CygWin port of Git
knowing that Windows support is coming
2. Use another SCM (#2 is Mercurial, #3 is Monotone)
I'd realy love to do #1, but I need to know how long do I have to wait.
- Dmitry
^ permalink raw reply
* Re: Windows support
From: Johannes Schindelin @ 2007-07-25 10:40 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <a1bbc6950707250335m3d37d4farceffc50945e31f6c@mail.gmail.com>
Hi,
On Wed, 25 Jul 2007, Dmitry Kakurin wrote:
> How serious are you guys about Windows support?
Okay, let's talk business:
> I'd realy love to do #1, but I need to know how long do I have to wait.
Pay me decently, and you will have to wait for a few weeks.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Andy Parkins @ 2007-07-25 11:05 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Marius Storm-Olsen, Alex Riesen,
Junio C Hamano, Shawn O. Pearce, Julian Phillips
In-Reply-To: <Pine.LNX.4.64.0707251024390.14781@racer.site>
On Wednesday 2007 July 25, Johannes Schindelin wrote:
> So this leaves me with the question: do Windows users really want a proper
> native Windows support for Git? If the answer is yes, why don't they _do_
> (as in "not talk") something about it?
I don't disagree with you at all - it is completely ridiculous for Windows
users to moan about lack of Windows support without contributing any help.
However, I think there is a good reason.
I think it's a chicken and egg problem. The only reason I started making
(small) contributions to git was because I was using it already. I didn't
set out with the goal "to improve git"; I set out looking for a DVCS.
Luckily for me, I use Linux so git worked pretty well for me straight away.
The same is not true for Windows users. Even if we ignore the fact that
Windows users are notoriously less open-source savvy; it's unlikely that
we'll get any Windows contributions until there are some threshold number of
developers using git on Windows.
Open-source is all about scratching an itch, I can't see how Windows
developers can get a gitch to scratch without being users of git first. On
the positive side though, there surely must come a point when the Windows
port is "good enough" that it will start to gather users and hence
developers. Until then, I suppose it's just a matter of shouting "patch"
every time a windows user asks for a feature :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Windows support
From: Steven Grimm @ 2007-07-25 11:12 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <a1bbc6950707250335m3d37d4farceffc50945e31f6c@mail.gmail.com>
Dmitry Kakurin wrote:
> How serious are you guys about Windows support?
Well, it's really a matter of someone stepping up and doing the work.
Much (nearly all?) of the core git team never touches Windows, so they
both have no selfish motivation to get it working well and no way to
test their changes even if they decide to take it up for the greater good.
As has been pointed out, there are a lot of people coming to the list
and asking for Windows support, but precious few actually contributing
any code. If everyone who asked for Windows support had been willing to
fix one Windows-related issue, git's Windows support would be stellar by
now. I'm as guilty as anyone of asking for stuff without doing it
myself, so I say this as an observation, not an accusation!
> I'm talking fully-functional port, not Cygwin.
There is a port that uses MinGW instead of Cygwin, FYI. It is still
perhaps not as native-Windows-like as one might prefer, but it should be
less alien than Cygwin, anyway.
-Steve
^ permalink raw reply
* Re: Windows support
From: Steven Grimm @ 2007-07-25 11:13 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <a1bbc6950707250335m3d37d4farceffc50945e31f6c@mail.gmail.com>
Dmitry Kakurin wrote:
> The current mingw port is not there yet.
Pfft, that'll teach me to reply after only skimming the original
message. Oops. But the main part of my reply is still valid, I think.
-Steve
^ permalink raw reply
* bug: update hook failure doesn't prevent local deletion of a branch
From: Andy Parkins @ 2007-07-25 11:50 UTC (permalink / raw)
To: Git Mailing List
Hello,
I wanted to delete a branch (let's call it "deleted-branch") from my public
repository. I ran this:
$ git push origin :deleted-branch
deleting 'refs/heads/deleted-branch'
Also local refs/remotes/up/deleted-branch
*** Update hook: aborting
error: hooks/update exited with error code 1
error: hook declined to update refs/heads/deleted-branch
ng refs/heads/deleted-branch hook declined
error: failed to push to '/path/to/git/repo.git'
Coincidentally, my update hook happened to have a bug in it that prevented me
from running the operation.
However, when I run the operation again...
$ git push origin :deleted-branch
deleting 'refs/heads/deleted-branch'
Also local refs/remotes/up/deleted-branch
error: unlink(.git/refs/remotes/up/deleted-branch) failed: No such file or
directory
error: Failed to delete
If the remote didn't get deleted, then it seems wrong that the local copy does
get deleted.
Summary: when using git-push to delete a remote branch, and that deletion is
disallowed by the update hook, the local tracking branch _is_ deleted.
Obviously, this isn't _that_ serious because it could be recovered again with
a git-fetch; but it does make some scary looking errors.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Marius Storm-Olsen @ 2007-07-25 12:10 UTC (permalink / raw)
To: Andy Parkins
Cc: git, Johannes Schindelin, Alex Riesen, Junio C Hamano,
Shawn O. Pearce, Julian Phillips
In-Reply-To: <200707251205.48235.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2615 bytes --]
Andy Parkins said the following on 25.07.2007 13:05:
> On Wednesday 2007 July 25, Johannes Schindelin wrote:
>
>> So this leaves me with the question: do Windows users really want
>> a proper native Windows support for Git? If the answer is yes,
>> why don't they _do_ (as in "not talk") something about it?
>
> I don't disagree with you at all - it is completely ridiculous for
> Windows users to moan about lack of Windows support without
> contributing any help. However, I think there is a good reason.
>
> I think it's a chicken and egg problem. The only reason I started
> making (small) contributions to git was because I was using it
> already. I didn't set out with the goal "to improve git"; I set
> out looking for a DVCS. Luckily for me, I use Linux so git worked
> pretty well for me straight away.
>
> The same is not true for Windows users. Even if we ignore the fact
> that Windows users are notoriously less open-source savvy; it's
> unlikely that we'll get any Windows contributions until there are
> some threshold number of developers using git on Windows.
>
> Open-source is all about scratching an itch, I can't see how
> Windows developers can get a gitch to scratch without being users
> of git first. On the positive side though, there surely must come
> a point when the Windows port is "good enough" that it will start
> to gather users and hence developers. Until then, I suppose it's
> just a matter of shouting "patch" every time a windows user asks
> for a feature :-)
Hi Andy,
Your mail is refreshingly spot on. I agree fully with what you say.
I will try to do my part to get Git to this 'threshold', so we can get
a proper Windows community behind it too. (It's just a matter of time
and resources, which I hope we clear up soon)
My first roadmap item will be to get a fully native compile of the
built-in code. If we at least have a Git built with native tools, I
think we'll have a lot more people wanting(/able?) to contribute.
AFAIK the MinGW port is cross-compiled on Linux, and can be hard to
set up on Windows. The required MinGW packages are scattered all over
the place. So, it's not impossible at the moment, but I guess most
Windows users feel a bit unmotivated to work on the code mostly since
they'll have to develop using Cygwin. (I don't know if that's the
reason, just a hunch)
So, IMO its not that Windows users don't _want_ to contribute. I think
they feel they can't. Let's see if we can fix that. I'll let the list
know as soon as I get native builds going.
Later!
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Windows support
From: Nguyen Thai Ngoc Duy @ 2007-07-25 12:13 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <a1bbc6950707250335m3d37d4farceffc50945e31f6c@mail.gmail.com>
On 7/25/07, Dmitry Kakurin <dmitry.kakurin@gmail.com> wrote:
> How serious are you guys about Windows support?
> I'm talking fully-functional port, not Cygwin.
> I did a lot of searching for a new SCM to switch to (from Perforce).
> And Git is my #1 choice. I love it's internals design and it's
> expressive power. I've also tested git-p4 and it has worked like a
> charm with my depot (with few tweaks that I may contribute later).
> But I do all my work on Windows so I need Git-For-Windows-Done-Right :-).
> The current mingw port is not there yet.
What features is mingw port missing?
> Transition to the new SCM must happen now, so basically I have 2 choices:
> 1. Survive for a few months with the current CygWin port of Git
> knowing that Windows support is coming
FYI, I'm working on getting rid of msys requirement from mingw port. I
can't tell you how long it would take though. Could be one month or
two.
--
Duy
^ permalink raw reply
* Re: Windows support
From: Steffen Prohaska @ 2007-07-25 12:30 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <a1bbc6950707250335m3d37d4farceffc50945e31f6c@mail.gmail.com>
On Jul 25, 2007, at 12:35 PM, Dmitry Kakurin wrote:
> How serious are you guys about Windows support?
> I'm talking fully-functional port, not Cygwin.
What's wrong with the Cygwin port?
Is it just that windows developer hate cygwin because it's to
complex to install or is there any severe limitation?
functionality? stability? performance?
I'm personally only working on Windows if force to, but people
are asking me the same question that you have. Does git
seriously and fully support Windows?
Steffen
^ permalink raw reply
* rc3 gitweb is broken, won't deliver snapshots
From: Mark Levedahl @ 2007-07-25 13:27 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
gitweb in 1.5.3-rc3 fails to deliver snapshots in any useable format
(bzip2, gz, or zip). Clicking on a link seems to work, but the
delivered file as stored on my system is empty. No error messages
appear anywhere I can find. I am hosting gitweb on FC7 using lighttpd,
if that matters.
The snapshot service at git.kernel.org also seems broken, I don't know
what gitweb is running there so don't know if the issue is related.
I have fixed this for my use by reverting the following commits
3473e7df5f8c7f8dc3e2c3f2fdc99a1d1a719c16 gitweb: More detailed error
messages for snapshot format
a781785d8f1eb7adf05a24b121104716a086a67a gitweb: Fix support for
legacy gitweb config for snapshots
a3c8ab30a54c30a6a434760bedf04548425416ef gitweb: snapshot cleanups &
support for offering multiple formats
The snapshot problem first appears when a3c8ab30a54 is applied.
Mark Levedahl
^ permalink raw reply
* gitk and the first commit
From: Medve Emilian-EMMEDVE1 @ 2007-07-25 13:51 UTC (permalink / raw)
To: git
Hello,
I noticed that in a repo with a single commit gitk will show no commits
and the message displayed is: "No commits selected". After the second
commit it starts to work as expected. I'm not sure if this is intended
behavior or not.
Cheers,
Emil.
This e-mail, and any associated attachments have been classified as:
--------------------------------------------------------------------
[x] Public
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
^ permalink raw reply
* Bug in gitk search box
From: Brian Downing @ 2007-07-25 13:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
To reproduce:
* Open gitk in any repository, the Git one seems to work fine.
* Type a string that it won't find into the search box, like 'asdfasdf'.
* Click find.
You'll get:
can't read "commitdata(e83c5163316f89bfbde7d9ab23ca2e25604af290)": no such element in array
can't read "commitdata(e83c5163316f89bfbde7d9ab23ca2e25604af290)": no such element in array
while executing
"doesmatch $commitdata($id)"
(procedure "findmore" line 21)
invoked from within
"findmore"
("eval" body line 1)
invoked from within
"eval $script"
(procedure "dorunq" line 9)
invoked from within
"dorunq"
("after" script)
Where the SHA1 is always the earliest SHA1 in the rev-list gitk is
examining.
After this happens you get a "busy cursor" when hovering over most of
gitk, and you can't search again until gitk is restarted.
-bcd
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Johannes Schindelin @ 2007-07-25 14:09 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Andy Parkins, git, Alex Riesen, Junio C Hamano, Shawn O. Pearce,
Julian Phillips
In-Reply-To: <46A73DB6.4090007@trolltech.com>
Hi,
On Wed, 25 Jul 2007, Marius Storm-Olsen wrote:
> Andy Parkins said the following on 25.07.2007 13:05:
> > On Wednesday 2007 July 25, Johannes Schindelin wrote:
> >
> > > So this leaves me with the question: do Windows users really want
> > > a proper native Windows support for Git? If the answer is yes,
> > > why don't they _do_ (as in "not talk") something about it?
> >
> > I don't disagree with you at all - it is completely ridiculous for
> > Windows users to moan about lack of Windows support without
> > contributing any help. However, I think there is a good reason.
> >
> > I think it's a chicken and egg problem. The only reason I started
> > making (small) contributions to git was because I was using it
> > already. I didn't set out with the goal "to improve git"; I set
> > out looking for a DVCS. Luckily for me, I use Linux so git worked
> > pretty well for me straight away.
> >
> > The same is not true for Windows users. Even if we ignore the fact
> > that Windows users are notoriously less open-source savvy; it's
> > unlikely that we'll get any Windows contributions until there are
> > some threshold number of developers using git on Windows.
> >
> > Open-source is all about scratching an itch, I can't see how
> > Windows developers can get a gitch to scratch without being users
> > of git first. On the positive side though, there surely must come
> > a point when the Windows port is "good enough" that it will start
> > to gather users and hence developers. Until then, I suppose it's
> > just a matter of shouting "patch" every time a windows user asks
> > for a feature :-)
>
> Hi Andy,
>
> Your mail is refreshingly spot on. I agree fully with what you say.
> I will try to do my part to get Git to this 'threshold', so we can get a
> proper Windows community behind it too. (It's just a matter of time and
> resources, which I hope we clear up soon)
> My first roadmap item will be to get a fully native compile of the built-in
> code. If we at least have a Git built with native tools, I think we'll have a
> lot more people wanting(/able?) to contribute.
Well, why don't people come here then, say "I am willing to test whatever
you throw at me, and contribute the installer"? Huh?
I once (AGAIN!) extend this offer to _anybody_. I'll make a zip of
everything you need, I'll fix bugs as you report them, I'll do plenty of
stuff.
But you have to give me an INCENTIVE!
(I am usually not such a shouter, but underlining seems not to help here.
As can be seen by the infamous "When can I expect" mail.)
> AFAIK the MinGW port is cross-compiled on Linux, and can be hard to set
> up on Windows. The required MinGW packages are scattered all over the
> place. So, it's not impossible at the moment, but I guess most Windows
> users feel a bit unmotivated to work on the code mostly since they'll
> have to develop using Cygwin. (I don't know if that's the reason, just a
> hunch)
No, not even close. It is written in README.MinGW how to go about
compiling yourself. Only Han-Wen cross-compiled the beast on Linux.
> So, IMO its not that Windows users don't _want_ to contribute. I think
> they feel they can't. Let's see if we can fix that.
I beg to differ here, strongly. On the two first points at least. On the
third point, I am already disap-point-ed.
Ciao,
Dscho
^ permalink raw reply
* Re: Windows support
From: Johannes Schindelin @ 2007-07-25 14:10 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0707250513v587d7a92lb688b52da3c28bb7@mail.gmail.com>
Hi,
On Wed, 25 Jul 2007, Nguyen Thai Ngoc Duy wrote:
> FYI, I'm working on getting rid of msys requirement from mingw port. I
> can't tell you how long it would take though. Could be one month or two.
Is there a repo out there?
Ciao,
Dscho
^ permalink raw reply
* Re: Windows support
From: Nguyen Thai Ngoc Duy @ 2007-07-25 14:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707251510130.14781@racer.site>
On 7/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 25 Jul 2007, Nguyen Thai Ngoc Duy wrote:
>
> > FYI, I'm working on getting rid of msys requirement from mingw port. I
> > can't tell you how long it would take though. Could be one month or two.
>
> Is there a repo out there?
http://repo.or.cz/w/git/pclouds.git?a=shortlog;h=gitbox
There are some patches on mob I have not merged to gitbox branch yet.
--
Duy
^ permalink raw reply
* [PATCH] git-submodule: Error messages from 'git describe' shouldn't end up on the terminal
From: Emil Medve @ 2007-07-25 14:21 UTC (permalink / raw)
To: git; +Cc: Emil Medve
As of now a failure to locate the closest tag to a commit (e.g because there is
no tag in the repository) is handled explicitly by displaying an 'undefined' tag
error message. However when git describe fails it will still display an
undesirable "fatal: cannot describe SHA1" message. This patch hides that
message as git-submodule has an alternative and explicit error handling method
in place for this situation
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 1f0cb99..3804f18 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -233,7 +233,7 @@ modules_list()
say "-$sha1 $path"
continue;
fi
- revname=$(unset GIT_DIR && cd "$path" && git describe --tags $sha1)
+ revname=$(unset GIT_DIR && cd "$path" && git describe --tags $sha1 2>/dev/null)
set_name_rev "$path" "$sha1"
if git diff-files --quiet -- "$path"
then
--
1.5.3.rc2.38.g11308-dirty
^ permalink raw reply related
* Re: [PATCH] Further changes to it.po
From: Marco Costalba @ 2007-07-25 16:10 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git, Johannes.Schindelin
In-Reply-To: <20070724223854.35715c77@paolo-desktop>
On 7/24/07, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> +msgstr "Fondi (Merge)"
>
> +msgstr "Prendi (Fetch)"
>
> +msgstr "Propaga (Push)"
>
Grande! (Great)
Marco
^ permalink raw reply
* Re: Git User's Survey 2007
From: Marco Costalba @ 2007-07-25 16:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200707250358.58637.jnareb@gmail.com>
On 7/25/07, Jakub Narebski <jnareb@gmail.com> wrote:
> It was little more than year ago since Git User's Survey
> http://marc.info/?l=git&m=115116592330648&w=2
> http://git.or.cz/gitwiki/GitSurvey
>
> I do wonder what has changed since then... ?
>
I think the next step will be to raise some funds to make Johannes
work out the Windows port :-)
Marco
^ permalink raw reply
* [PATCH 1/2] resolve symlinks when creating lockfiles
From: Bradford C. Smith @ 2007-07-25 16:49 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Bradford C. Smith
In-Reply-To: <11853821932079-git-send-email-bradford.carl.smith@gmail.com>
From: Bradford C. Smith <bradford.carl.smith@gmail.com>
Without this fix, the lockfile code will replace a symlink with a real file.
Signed-off-by: "Bradford C. Smith" <bradford.carl.smith@gmail.com>
---
lockfile.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 86 insertions(+), 1 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index fb8f13b..4c35224 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -25,10 +25,95 @@ static void remove_lock_file_on_signal(int signo)
raise(signo);
}
+/**
+ * p = absolute or relative path name
+ *
+ * Return a pointer into p showing the beginning of the last path name
+ * element. If p is empty or the root directory ("/"), just return p.
+ */
+static char * last_path_elm(char * p)
+{
+ int p_len = strlen(p);
+ char * r;
+
+ if (p_len < 1) return p;
+ /* r points to last non-null character in p */
+ r = p + p_len - 1;
+ /* first skip any trailing slashes */
+ while (*r == '/' && r > p) r--;
+ /* then go back to the first non-slash */
+ while (r > p && *(r-1) != '/') r--;
+ return r;
+}
+
+/**
+ * p = char array containing path to existing file or symlink
+ * s = size of p
+ *
+ * If p indicates a valid symlink to an existing file, overwrite p with
+ * the path to the real file. Otherwise, leave p unmodified.
+ *
+ * Always returns p in any case.
+ *
+ * NOTE: This is a best-effort routine. It will give no indication of
+ * failure if it is unable to fully resolve p. However, it is
+ * guaranteed to leave p in one of the following states if there isn't
+ * enough room in p or some other failure occurs:
+ *
+ * 1. unmodified
+ * OR
+ * 2. path to a different symlink in a chain that eventually leads to a
+ * real file or directory.
+ */
+static char * resolve_symlink(char * p, size_t s)
+{
+ struct stat st;
+ char link[PATH_MAX];
+ int link_len;
+
+ /* To avoid an infinite loop of symlinks, try a normal stat()
+ * first. This will fail if p is a symlink that cannot be
+ * resolved, so we won't waste our time following a bad link. */
+ if (stat(p, &st)) return p;
+ /* if I can stat() the file, I sure ought to be able to lstat()
+ * it, but if something bizarre happens, just return p. */
+ if (lstat(p, &st)) return p;
+ /* if not a link, return p unmodified */
+ if (!S_ISLNK(st.st_mode)) return p;
+ link_len = st.st_size;
+ /* link is too big, so just return p */
+ if (link_len >= sizeof(link)) return p;
+ /* fail if readlink fails, and just return p */
+ if (link_len != readlink(p, link, sizeof(link))) return p;
+ /* readlink never null-terminates */
+ link[link_len] = '\0';
+ if (link[0] == '/') {
+ /* absolute path simply replaces p */
+ /* fail if link won't fit in p */
+ if (link_len >= s) return p;
+ strcpy(p, link);
+ } else {
+ /* link is relative path, so we must replace the last
+ * element of p with it. */
+ char * r = last_path_elm(p);
+ /* make sure there's room in p for us to replace the
+ * last element with the link contents */
+ if (r - p + link_len >= s) return p;
+ strcpy(r, link);
+ }
+ /* try again in case we've resolved to another symlink */
+ return resolve_symlink(p, s);
+}
+
static int lock_file(struct lock_file *lk, const char *path)
{
int fd;
- sprintf(lk->filename, "%s.lock", path);
+ if (strlen(path) >= sizeof(lk->filename)) return -1;
+ strcpy(lk->filename, path);
+ /* subtract 5 from size to make sure there's room for adding
+ * ".lock" for the lock file name */
+ resolve_symlink(lk->filename, sizeof(lk->filename)-5);
+ strcat(lk->filename, ".lock");
fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
if (0 <= fd) {
if (!lock_file_list) {
--
1.5.3.rc2.30.g1c06-dirty
^ permalink raw reply related
* [PATCH 0/2] git-config should not replace symlink
From: Bradford C. Smith @ 2007-07-25 16:49 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vps2s2chy.fsf@assigned-by-dhcp.cox.net>
These patches fix a problem that caused git-config to replace my
~/.gitconfig symlink with a real file.
[PATCH 1/2] resolve symlinks when creating lockfiles
[PATCH 2/2] use lockfile.c routines in git_commit_set_multivar()
^ permalink raw reply
* [PATCH 2/2] use lockfile.c routines in git_commit_set_multivar()
From: Bradford C. Smith @ 2007-07-25 16:49 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Bradford C. Smith
In-Reply-To: <11853821951367-git-send-email-bradford.carl.smith@gmail.com>
From: Bradford C. Smith <bradford.carl.smith@gmail.com>
Changed git_commit_set_multivar() to use the routines provided by
lockfile.c to reduce code duplication and ensure consistent behavior.
Signed-off-by: "Bradford C. Smith" <bradford.carl.smith@gmail.com>
---
config.c | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/config.c b/config.c
index f89a611..9101de9 100644
--- a/config.c
+++ b/config.c
@@ -715,7 +715,7 @@ int git_config_set_multivar(const char* key, const char* value,
int fd = -1, in_fd;
int ret;
char* config_filename;
- char* lock_file;
+ struct lock_file *lock = NULL;
const char* last_dot = strrchr(key, '.');
config_filename = getenv(CONFIG_ENVIRONMENT);
@@ -725,7 +725,6 @@ int git_config_set_multivar(const char* key, const char* value,
config_filename = git_path("config");
}
config_filename = xstrdup(config_filename);
- lock_file = xstrdup(mkpath("%s.lock", config_filename));
/*
* Since "key" actually contains the section name and the real
@@ -770,11 +769,12 @@ int git_config_set_multivar(const char* key, const char* value,
store.key[i] = 0;
/*
- * The lock_file serves a purpose in addition to locking: the new
+ * The lock serves a purpose in addition to locking: the new
* contents of .git/config will be written into it.
*/
- fd = open(lock_file, O_WRONLY | O_CREAT | O_EXCL, 0666);
- if (fd < 0 || adjust_shared_perm(lock_file)) {
+ lock = xcalloc(sizeof(struct lock_file), 1);
+ fd = hold_lock_file_for_update(lock, config_filename, 0);
+ if (fd < 0) {
fprintf(stderr, "could not lock config file\n");
free(store.key);
ret = -1;
@@ -914,25 +914,29 @@ int git_config_set_multivar(const char* key, const char* value,
goto write_err_out;
munmap(contents, contents_sz);
- unlink(config_filename);
}
- if (rename(lock_file, config_filename) < 0) {
- fprintf(stderr, "Could not rename the lock file?\n");
+ if (close(fd) || commit_lock_file(lock) < 0) {
+ fprintf(stderr, "Cannot commit config file!\n");
ret = 4;
goto out_free;
}
+ /* fd is closed, so don't try to close it below. */
+ fd = -1;
+ /* lock is committed, so don't try to roll it back below.
+ * NOTE: Since lockfile.c keeps a linked list of all created
+ * lock files, it isn't safe to free(lock). It's better to just
+ * leave it hanging around. */
+ lock = NULL;
ret = 0;
out_free:
if (0 <= fd)
close(fd);
+ if (lock)
+ rollback_lock_file(lock);
free(config_filename);
- if (lock_file) {
- unlink(lock_file);
- free(lock_file);
- }
return ret;
write_err_out:
--
1.5.3.rc2.30.g1c06-dirty
^ permalink raw reply related
* Re: Windows support
From: Stephen Cuppett @ 2007-07-25 16:58 UTC (permalink / raw)
To: Steffen Prohaska, git
In-Reply-To: <693D0FFF-B271-4781-BCE2-3BF00C8BF426@zib.de>
On 7/25/07, Steffen Prohaska <prohaska@zib.de> wrote:
> Is it just that windows developer hate cygwin because it's to
> complex to install or is there any severe limitation?
> functionality? stability? performance?
I actually have no problems with cygwin and find it works pretty well
with git repositories. Starting the xserver to run git-gui is pretty
annoying though. Windows-based development teams are going to expect
easy access to those kinds of tooling. Otherwise, the champion will
be pushing a type of workflow change that would hinder adoption anyway
and leave a sour taste for a long time.
In addition, performance is atrocious. In my particular case I have
an older P4 running F7 and a newer machine running Windows and cygwin.
On a pserver based cvsimport of a large, enterprise project, Linux
was able to generate the full history in 4 hours, cygwin took 3 and a
half days. When I sync up every now and then, typical times for
windows are 25 minutes and Linux is around 4. That should give you an
idea of what kind of multiplier we are talking about.
I don't know if the performance problems are cygwin or not. More
knowledgeable people might be able to answer, it's just what I'm
observing right now. It could be more fundamental to the types of
access being performed en masse on inode-based versus NTFS systems.
^ 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