* git bisect not accepting -git kernels
From: Amit Walambe @ 2007-07-17 16:03 UTC (permalink / raw)
To: git; +Cc: Amit Walambe (awalambe@arcom.com)
Hi!
I was trying to do a git bisect on 2.6.22-git6 and 2.6.22-git8. For
which I get following error :
root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6
Bad rev input: v2.6.22-git6
The repository is obtained by :
root@amit:/usr/src # git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 linux-git
I am running following git version on Debian Sid, updated today.
# git --version
git version 0.99.8.GIT
'# dpkg -l | grep git' shows ' git-core
1:1.5.2.3-1'
I tried searching man-pages/documentation/website but couldn't find any
references to git bisect on -git kernels. I would be grateful if anyone
can help me find what's going wrong.
As I am not subscribed to the mailing-list, please cc me to all the
messages on the thread.
Thanks and Regards,
--
Amit Walambe
Design Engineer, Arcom Control Systems Ltd.
http://www.arcom.com
Tel: +44-(0)1223 411200 ext. 3204
Direct: +44-(0)1223 403465
_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
This message has been virus scanned by MessageLabs.
^ permalink raw reply
* Seeing differences at origin/branch?
From: Thomas Adam @ 2007-07-17 15:53 UTC (permalink / raw)
To: git
Hello all,
This is perhaps going to seem like a very CVS/SVN type of question,
but is there a way to see a list of differences between one's local
copy and the origin branch? I'm after something analogous to "svn
status -u" really (yes, I know I could get my hands scorched for such
things. :P). Is this possible?
I've tried:
git-diff-tree -p origin/master
But that won't list changes waiting for me that I would get when I
issue a "git pull".
Many thanks,
Thomas Adam
^ permalink raw reply
* [ANNOUNCE] Guilt v0.26
From: Josef Sipek @ 2007-07-17 15:28 UTC (permalink / raw)
To: guilt; +Cc: git, linux-kernel, brandon
Guilt v0.26 is available for download (once it mirrors out on kernel.org).
Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
queues-like functionality and interface to git.
Tarballs:
http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/
Git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git
Although there was a v0.26-rc1 release, I never announced it so the
following summary includes all the changes since v0.25. Unfortunately, it
took two months to get this release out. I promise to get back to the 2-3
week release cycle.
The major change since v0.25 (contributed by Pierre Habouzit) is that Guilt
no longer depends on bash. Other than that, there have been a number of bug
fixes, as well several new commands and options:
branch Branch the repository & patch series
diff Output a diff against the top-most applied patch
fold -k Keep patch file
graph Generate dot(1) patch dependecy graph
new -f Force new patch creation
refresh --git Detect renames & copies
series -g Start gitk on the applied patches
Additionally, Guilt now knows how to:
Grab Cc: lines from the patch descriptions for patchbomb
Strip 'Subject: ' from the first line of patch description
All in all, quite a number of changes, so it is possible that I forgot to
mention something. For more details, check the change list below, or the git
repository near you :)
As always, patches, and other feedback is welcome.
Josef "Jeff" Sipek.
------------
Changes since v0.25:
Josef 'Jeff' Sipek (20):
graph: generate a dot(1) dependency graph of patches
graph: Remove graph cache after command terminates
new: Added new option, -f to force new patch creation
refresh: Added --git option to generate more git friendly diff
new: current working dir should not be displayed
export: Create subdirectories before copying the patch files
series: Added -g option to start gitk
refresh: Reintroduce the --git option that got accidentally dropped
guilt: added -V/--version option to display only the version number
fold: Added -k option to keep patch file
Guilt v0.26-rc1
guilt: Strip "^Subject: " from first line of patch message
Docs/Requirements: sh is now required instead of bash
branch: new command to create a new branch with duplicated patches directory
Docs: A begining of a Features file
graph: Fixed graph generation
patchbomb: Grab additional Cc info from '^Cc:' lines in patch desc
patchbomb: Remove leftover debug code
diff: Create a diff against the top-most applied patch
Guilt v0.26
Pierre Habouzit (8):
Add a guilt-export(1) command to export a guilt series to quilt.
guilt(1): Obvious bashisms fixed.
guilt(1): simplifications...
guilt(1): reimplement push_patch, using a subshell to avoid locals.
Remove bashisms - easy commands
guilt-status(1): Remove bashisms.
Remove last bashisms from remaining commands.
Regression test suite needs bash, that's OK.
Theodore Ts'o (1):
Fix guilt to work correctly even if the refs are packed
^ permalink raw reply
* Re: git-config: replaces ~/.gitconfig symlink with real file
From: Matthieu Moy @ 2007-07-17 14:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bradford Smith, Nikolai Weibull, git
In-Reply-To: <Pine.LNX.4.64.0707170834040.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 16 Jul 2007, Bradford Smith wrote:
>
>> So, I guess I need to add a GIT_CONFIG_HOME environment variable. If I
>> get that done, I'll send a patch to the list including doc updates.
>
> Alternatively, you could actually not ignore my hint at readlink(2) and
> have a proper fix, instead of playing games with environment variables.
I second that.
Using an environment variable means having a configuration which is
about git in my shell's config file, and that's a source of a lot of
troubles. Murphy's law implies that one day, the environment variable
won't be set properly (because you changed your shell, because you
launch git from something which isn't a shell, because you logged-in
in a way that didn't read the config file in which the variable was
set, ...).
I can do with it, like many other software require an environment
variable, but I find the symlink trick much more robust.
--
Matthieu
^ permalink raw reply
* Re: git-config: replaces ~/.gitconfig symlink with real file
From: Johannes Schindelin @ 2007-07-17 13:56 UTC (permalink / raw)
To: Bradford Smith; +Cc: Nikolai Weibull, git
In-Reply-To: <f158199e0707160626j1025ab2cp3339ca6ab91d9af0@mail.gmail.com>
Hi,
On Mon, 16 Jul 2007, Bradford Smith wrote:
> So, I guess I need to add a GIT_CONFIG_HOME environment variable. If I
> get that done, I'll send a patch to the list including doc updates.
Alternatively, you could actually not ignore my hint at readlink(2) and
have a proper fix, instead of playing games with environment variables.
Hth,
Dscho
^ permalink raw reply
* Re: git-config: replaces ~/.gitconfig symlink with real file
From: Catalin Marinas @ 2007-07-17 13:39 UTC (permalink / raw)
To: Bradford Smith; +Cc: git
In-Reply-To: <f158199e0707151427h52da3e38rae3be6e44e27e918@mail.gmail.com>
"Bradford Smith" <bradford.carl.smith@gmail.com> wrote:
> However, when I tried running 'git-config --global color.diff auto'
> today, it removed my symlink and replaced it with a real file. This
> left me briefly a bit confused when the changes I had made didn't show
> up in ~/etc/gitconfig, but git-config reported them anyway.
Another problem I have with 'git config --global' is that it changes
the access permission bits of ~/.gitconfig. Since I use the same file
to store global StGIT configuration like SMTP username and password,
I'd like to make its access 0600 but it always goes back to 0644 after
'git config --global'.
Maybe fixing the symlink case would solve my problem as well.
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH] translate bad characters in refnames during git-svn fetch
From: martin f krafft @ 2007-07-17 13:17 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <20070717122852.GA21372@mayonaise>
[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]
also sprach Eric Wong <normalperson@yhbt.net> [2007.07.17.1428 +0200]:
> I like it, too. How about something like the two functions below?
> This will break things a bit for people currently using % in
> refnames, however.
Well, wait. git-svn usually works in its own repo, and if that's
tracked by another repo, then it is tracked under the
remote/whatever namespace, so there should not be any conflicts. You
also hardly ever run git-svn to clone stuff *into* an existing repo,
so there can't be conflicts with existing refnames-with-%. Thus the
only breakage is if a person creates a new refname inside a git-svn
repo, which uses % in such a way as to collide with an imported
branch/tag/whatever from git-svn. That's not breakage, since git
will just refuse to do it.
Remember that we're only translating from <char> -> %XX, never the
other way around, really. Okay, we might be during git-svn
rebase/dcommit, but only for those refnames which we store in
.git/svn/ anyway. So a user-specified refname containing % will not
be a problem, will it?
> I think this will work rather nicely once I've figured out how the path
> globbing code works[1] and where to sanitize/desanitize the refnames
> properly.
I am glad you're having the same problem; makes me feel less stupid.
:)
> Somebody naming directories on the SVN side with the path component
> ":refs/remotes" in them could screw things up for us.
Those people should be tarred and feathered. git owns the trademark
on these names.
> sub desanitize_ref_name {
> my ($refname) = @_;
> $refname =~ s{%(?:([0-9A-F]{2})}{chr hex($1)}g;
>
> $refname;
> }
We could make it escape to %25; instead of %25. That's ugly but it
would make desanitation a little safer.
> > On the other hand, we could make the translation regexps
> > configurable...
>
> Hopefully not needed. I fear it would just add to confusion.
I was thinking about something like.
git-svn clone ...
...
error: remote branch/tagn name includes ~, which git does not
allow. please specify a replacement character in .git/config
and then have config.svn-remote.svn.translations simply be a list of
pairs in vim pairlist syntax:
~:!,^:#,.:\,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"it is easier to be a lover than a husband for the simple reason
that it is more difficult to be witty every day
than to say pretty things from time to time."
-- honoré de balzac
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* gitignore and shared worktrees (was: finding the right remote branch for a commit)
From: martin f krafft @ 2007-07-17 13:09 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]
Sorry for the somewhat late reply, I just found time on the weekend
to check out this suggestion by Johannes
(http://marc.info/?l=git&m=118418927823760&w=2)
also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.07.11.2126 +0200]:
> Come to think of it, this is maybe what I would have done, but it
> appears to me that this is the _ideal_ use case for worktree:
>
> In $HOME/gits:
>
> $ mkdir vim.git && cd vim.git
> $ git --work-tree=$HOME init
> $ cat >> info/exclude < EOF
> *
> !/.vimrc
> EOF
>
> Then you could do all Git operations like push, fetch, pull, log in
> $HOME/gits/vim.git, and all editing in $HOME.
This actually seems to work really nicely, but I am somewhat
displeased by the gitignore/exclude handling, since it's local. What
I want to do is synchronise the vim configuration across many
workstations with git, and I don't want to have to modify
$GIT_DIR/info/exclude on each machine.
So I am tempted to use .gitignore, but that lives in the worktree,
and since the suggestion is to share worktrees between different git
repos, I can only ever have one .gitignore file, which would have to
list ignores for *all* repos in $HOME/gits, which breaks my head.
Do you have any other idea on how to handle ignores? I guess one
alternative is just to ignore git status output altogether, but
that's not really nice.
Would people consider honoring .gitignore-* in addition to just
.gitignore? Or maybe even honouring .gitignore/*, if .gitignore is
a directory, not a file?
Cheers,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"i like .net for the same reason i like gentoo. it keeps all the
people with no clue from writing c code, which is much harder for me
to identify and eliminate from my systems. in the same way that
gentoo gives those people a place to be that isn't in debian"
-- andrew suffield
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] translate bad characters in refnames during git-svn fetch
From: Eric Wong @ 2007-07-17 12:28 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <20070716174731.GA4792@lapse.madduck.net>
martin f krafft <madduck@madduck.net> wrote:
> also sprach Eric Wong <normalperson@yhbt.net> [2007.07.16.0530 +0200]:
> > The major issue with this is that it doesn't handle odd cases
> > where a refname is sanitized into something (say "1234~2"
> > sanitizes to "1234=2"), and then another branch is created named
> > "1234=2".
>
> Well, we can't please everyone, can we? :)
>
> I like Jan's proposal about using the % escape, even though it
> doesn't make pretty branch names.
I like it, too. How about something like the two functions below? This
will break things a bit for people currently using % in refnames,
however.
I think this will work rather nicely once I've figured out how the path
globbing code works[1] and where to sanitize/desanitize the refnames
properly.
It would be far easier to take your approach and sanitize them only
for the command-line, but storing unsanitized git refnames into the
.git/config is something I want to avoid:
Somebody naming directories on the SVN side with the path component
":refs/remotes" in them could screw things up for us.
# transform the refname as per rules in git-check-ref-format(1):
sub sanitize_ref_name {
my ($refname) = @_;
# It cannot end with a slash /, we'll throw up on this because
# SVN can't have directories with a slash in their name, either:
if ($refname =~ m{/$}) {
die "ref: '$refname' ends with a trailing slash, this is ",
"not permitted by git nor Subversion\n";
}
# It cannot have ASCII control character space, tilde ~, caret ^,
# colon :, question-mark ?, asterisk *, or open bracket[ anywhere
#
# Additionally, % must be escaped because it is used for escaping
# and we want our escaped refname to be reversible
$refname =~ s{( \%~\^:\?\*\[\t)}{uc sprintf('%%%02x',ord($1))}eg;
# no slash-separated component can begin with a dot .
# /.* becomes /%2E*
$refname =~ s{/\.}{/%2E}g;
# It cannot have two consecutive dots .. anywhere
# .. becomes %2E%2E
$refname =~ s{\.\.}{%2E%2E}g;
$refname;
}
sub desanitize_ref_name {
my ($refname) = @_;
$refname =~ s{%(?:([0-9A-F]{2})}{chr hex($1)}g;
$refname;
}
> On the other hand, we could make the translation regexps
> configurable...
Hopefully not needed. I fear it would just add to confusion.
[1] I don't remember writing the globbing code myself, maybe it was my
psychotic alter ego, but I'm having trouble following it at this time of
the night/morning.
--
Eric Wong
^ permalink raw reply
* Re: Problem running git-gui
From: Thomas Glanzmann @ 2007-07-17 12:04 UTC (permalink / raw)
To: Julian Phillips; +Cc: Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0707171244080.13359@reaper.quantumfyre.co.uk>
Hello Julian,
> 'Error in startup script: expected version number but got "1.5.3.GIT"'
I get the same error. However it works with released versions of git:
(faui04a) [~] git gui
Error in startup script: invalid command name "git-version"
while executing
"git-version >= 1.5.3"
(in namespace eval "::blame" script line 36)
invoked from within
"namespace eval $class $body"
(procedure "class" line 16)
invoked from within
"class blame {
image create photo ::blame::img_back_arrow -data {R0lGODlhGAAYAIUAAPwCBEzKXFTSZIz+nGzmhGzqfGTidIT+nEzGXHTqhGzmfGzifFzadETCVES+VARWDFzWb..."
(file "/usr/share/git-gui/lib/blame.tcl" line 4)
invoked from within
"source [file join $oguilib $p]"
("foreach" body line 3)
invoked from within
"foreach p $idx {
if {[lsearch -exact $loaded $p] >= 0} continue
source [file join $oguilib $p]
lappend loaded $p
}"
invoked from within
"if {$idx ne {}} {
set loaded [list]
foreach p $idx {
if {[lsearch -exact $loaded $p] >= 0} continue
source [file join $oguilib $p]
lappend loa..."
(file "/usr/bin/git-gui" line 98)
it is because "1.5.3.GIT" is not a number I guess.
Thomas
^ permalink raw reply
* Problem running git-gui
From: Julian Phillips @ 2007-07-17 11:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
I have a machine on which git was installed from a tarball created by
running git-archive on master (so a 1.5.3ish version).
When I try running git-gui I get an error message:
'Error in startup script: expected version number but got "1.5.3.GIT"'
followed by what I assume is a code snippet where it failed (I wouldn't
know tcl if it hit me with a large brick).
Is this expected? driver error? or maybe a bug?
--
Julian
---
mixed emotions:
Watching a bus-load of lawyers plunge off a cliff.
With five empty seats.
^ permalink raw reply
* Re: Installation failure caused by CDPATH environment variable
From: Uwe Kleine-König @ 2007-07-17 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, git
In-Reply-To: <7vejje3a4k.fsf@assigned-by-dhcp.cox.net>
Hello,
Junio C Hamano wrote:
> We could write it as "$(TAR) Ccf blt - ." if we can rely on the
> 'C' option, but I suspect it is a GNU extension. Does anybody
> have POSIX.1 handy?
I don't have POSIX.1 handy, but on Solaris 10, you need to say:
tar cf - -C blt .
(That is, Solaris' tar has the 'C' option, which is quite a good
indication, that it's included in POSIX :-)
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=gigabyte+in+bit
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Thomas Glanzmann @ 2007-07-17 10:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzs3a0xg.fsf@assigned-by-dhcp.cox.net>
Hello Junio,
> This is wrong. If the filesystem has a symlink and we would want a
> directory there, we should unlink(). So at least the stat there needs
> to be lstat().
I see.
> I wonder if anybody involved in the discussion has actually
> tested this patch (or the other one, that has the same problem)?
I tested it. But I did not test it with symlinks.
> Does the following replacement work for you? It adds far more lines
> than your version, but they are mostly comments to make it clear why
> we do things this way.
Yes, it does. Excuse the delay but my build machine is not the fastest.
(faui04a) [/var/tmp] git clone ~/work/repositories/public/easix.git test-10
Initialized empty Git repository in /var/tmp/test-10/.git/
remote: Generating pack...
remote: Done counting 317 objects.
remote: Deltifying 317 objects...
remote: te: % (317/317) done: ) done
Indexing 317 objects...
remote: Total 317 (delta 182), reused 278 (delta 157)
100% (317/317) done
Resolving 182 deltas...
100% (182/182) done
(faui04a) [/var/tmp] cd test-10
./test-10
(faui04a) [/var/tmp/test-10] git status
# On branch master
nothing to commit (working directory clean)
I rebased your patch on top of current HEAD (as I can access it on
git.kernel.org) and removed trailing whitspace from one line (git-apply
complained)
Thomas
>From 3b60b807007507ce5e1f8490f1469dac5bb95917 Mon Sep 17 00:00:00 2001
From: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
Date: Tue, 17 Jul 2007 11:31:07 +0200
Subject: [PATCH] Do _not_ call unlink on a directory
Calling unlink on a directory on a Solaris UFS filesystem as root makes it
inconsistent. Thanks to Junio for the not so obvious fix.
---
entry.c | 37 ++++++++++++++++++++++++++++++-------
1 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/entry.c b/entry.c
index c540ae1..0625112 100644
--- a/entry.c
+++ b/entry.c
@@ -8,17 +8,40 @@ static void create_directories(const char *path, const struct checkout *state)
const char *slash = path;
while ((slash = strchr(slash+1, '/')) != NULL) {
+ struct stat st;
+ int stat_status;
+
len = slash - path;
memcpy(buf, path, len);
buf[len] = 0;
+
+ if (len <= state->base_dir_len)
+ /*
+ * checkout-index --prefix=<dir>; <dir> is
+ * allowed to be a symlink to an existing
+ * directory.
+ */
+ stat_status = stat(buf, &st);
+ else
+ /*
+ * if there currently is a symlink, we would
+ * want to replace it with a real directory.
+ */
+ stat_status = lstat(buf, &st);
+
+ if (!stat_status && S_ISDIR(st.st_mode))
+ continue; /* ok, it is already a directory. */
+
+ /*
+ * We know stat_status == 0 means something exists
+ * there and this mkdir would fail, but that is an
+ * error codepath; we do not care, as we unlink and
+ * mkdir again in such a case.
+ */
if (mkdir(buf, 0777)) {
- if (errno == EEXIST) {
- struct stat st;
- if (len > state->base_dir_len && state->force && !unlink(buf) && !mkdir(buf, 0777))
- continue;
- if (!stat(buf, &st) && S_ISDIR(st.st_mode))
- continue; /* ok */
- }
+ if (errno == EEXIST && state->force &&
+ !unlink(buf) && !mkdir(buf, 0777))
+ continue;
die("cannot create directory at %s", buf);
}
}
--
1.5.2.1
^ permalink raw reply related
* Re: Can someone explain this git-blame/git-rev behavior to me?
From: David Kastrup @ 2007-07-17 9:57 UTC (permalink / raw)
To: git
In-Reply-To: <7v7ip02b81.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> git-rev-list HEAD --not tags/v1.4.2-rc1~88 --parents contrib/emacs/vc-git.el|tail -1|git-name-rev --stdin
>>
>> d87b90e47f7430455385edcf8506288b9a73d3b5 (tags/v1.4.2-rc1~87) b5dd9d2027c1bd5758033c7baf6d087752b0263d (tags/v1.4.2-rc1~88) 280242d1cc1fe2847f649d2f16b273e168fcbc48 (tags/v1.4.2-rc1~92)
>>
>> So we have tags/v1.4.2-rc1~87 listed as successor again, so I get into
>> a loop of blame.
>
> Without the final name-rev, it reads:
>
> d87b90e4... b5dd9d20... 280242d1...
>
> Without the --parent option, you get only d87b90e4...;
No. Without the --parents option, I get
076a10c7282a08f783a28c1b64d0e114a3fe3d39
which is what I would think correct, as opposed to the output with
--parents option. Have you actually tried this?
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: David Kastrup @ 2007-07-17 8:58 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0707161252330.20061@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, 16 Jul 2007, Thomas Glanzmann wrote:
>>
>> Calling unlink on a directory on a Solaris UFS filesystem as root makes it
>> inconsistent. Thanks to Johannes Sixt for the obvious fix.
>
> Ack, I think this is the right thing to do.
>
> As pointed out, it doesn't _guarantee_ that git won't call
> "unlink()" on a directory (race conditions etc), but that's
> fundamentally true (there is no "funlink()" like there is
> "fstat()"), and besides, that is in no way git-specific (ie it's
> true of *any* application that gets run as root).
Please note that doing "remove" before "mkdir" without checking for
directoriness still offers a race window where one can slip in a new
non-directory file.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Document "git stash message..."
From: Junio C Hamano @ 2007-07-17 8:50 UTC (permalink / raw)
To: しらいしななこ; +Cc: git
In-Reply-To: <20070624192215.6117@nanako3.bluebottle.com>
しらいしななこ <nanako3@bluebottle.com> writes:
> The command was recently updated to take message on the command line, but
> this feature has not been documented.
>
> Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
Thanks -- that was my fault.
> Documentation/git-stash.txt | 11 +++++++----
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
> index ad95ed9..4404361 100644
> --- a/Documentation/git-stash.txt
> +++ b/Documentation/git-stash.txt
> @@ -22,7 +23,9 @@ The modifications stashed away by this command can be listed with
> `git-stash list`, inspected with `git-stash show`, and restored
> (potentially on top of a different commit) with `git-stash apply`.
> Calling git-stash without any arguments is equivalent to `git-stash
> -save`.
> +save`. A stash is by default listed as "WIP on 'branchname' ...", but
> +you can give more descriptive message on the command line when
> +you create one.
Perhaps "give a more descriptive message"?
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Junio C Hamano @ 2007-07-17 8:28 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <11846059721204-git-send-email-sithglan@stud.uni-erlangen.de>
Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
> Calling unlink on a directory on a Solaris UFS filesystem as root makes it
> inconsistent. Thanks to Johannes Sixt for the obvious fix.
> ---
> entry.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/entry.c b/entry.c
> index 82bf725..1f2e34d 100644
> --- a/entry.c
> +++ b/entry.c
> @@ -14,10 +14,10 @@ static void create_directories(const char *path, const struct checkout *state)
> if (mkdir(buf, 0777)) {
> if (errno == EEXIST) {
> struct stat st;
> - if (len > state->base_dir_len && state->force && !unlink(buf) && !mkdir(buf, 0777))
> - continue;
> if (!stat(buf, &st) && S_ISDIR(st.st_mode))
> continue; /* ok */
> + if (len > state->base_dir_len && state->force && !unlink(buf) && !mkdir(buf, 0777))
> + continue;
> }
> die("cannot create directory at %s", buf);
> }
> --
> 1.5.2.1
This is wrong. If the filesystem has a symlink and we would
want a directory there, we should unlink(). So at least the
stat there needs to be lstat().
I wonder if anybody involved in the discussion has actually
tested this patch (or the other one, that has the same problem)?
Does the following replacement work for you? It adds far more
lines than your version, but they are mostly comments to make it
clear why we do things this way.
---
entry.c | 37 ++++++++++++++++++++++++++++++-------
1 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/entry.c b/entry.c
index f9e7dc5..42fda36 100644
--- a/entry.c
+++ b/entry.c
@@ -8,17 +8,40 @@ static void create_directories(const char *path, const struct checkout *state)
const char *slash = path;
while ((slash = strchr(slash+1, '/')) != NULL) {
+ struct stat st;
+ int stat_status;
+
len = slash - path;
memcpy(buf, path, len);
buf[len] = 0;
+
+ if (len <= state->base_dir_len)
+ /*
+ * checkout-index --prefix=<dir>; <dir> is
+ * allowed to be a symlink to an existing
+ * directory.
+ */
+ stat_status = stat(buf, &st);
+ else
+ /*
+ * if there currently is a symlink, we would
+ * want to replace it with a real directory.
+ */
+ stat_status = lstat(buf, &st);
+
+ if (!stat_status && S_ISDIR(st.st_mode))
+ continue; /* ok, it is already a directory. */
+
+ /*
+ * We know stat_status == 0 means something exists
+ * there and this mkdir would fail, but that is an
+ * error codepath; we do not care, as we unlink and
+ * mkdir again in such a case.
+ */
if (mkdir(buf, 0777)) {
- if (errno == EEXIST) {
- struct stat st;
- if (!stat(buf, &st) && S_ISDIR(st.st_mode))
- continue; /* ok */
- if (len > state->base_dir_len && state->force && !unlink(buf) && !mkdir(buf, 0777))
- continue;
- }
+ if (errno == EEXIST && state->force &&
+ !unlink(buf) && !mkdir(buf, 0777))
+ continue;
die("cannot create directory at %s", buf);
}
}
^ permalink raw reply related
* [PATCH] Document "git stash message..."
From: しらいしななこ @ 2007-07-17 8:15 UTC (permalink / raw)
To: git
The command was recently updated to take message on the command line, but
this feature has not been documented.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
---
Documentation/git-stash.txt | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index ad95ed9..4404361 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -8,7 +8,8 @@ git-stash - Stash the changes in a dirty working directory away
SYNOPSIS
--------
[verse]
-'git-stash' (save | list | show [<stash>] | apply [<stash>] | clear)
+'git-stash' (list | show [<stash>] | apply [<stash>] | clear)
+'git-stash' [save] [message...]
DESCRIPTION
-----------
@@ -22,7 +23,9 @@ The modifications stashed away by this command can be listed with
`git-stash list`, inspected with `git-stash show`, and restored
(potentially on top of a different commit) with `git-stash apply`.
Calling git-stash without any arguments is equivalent to `git-stash
-save`.
+save`. A stash is by default listed as "WIP on 'branchname' ...", but
+you can give more descriptive message on the command line when
+you create one.
The latest stash you created is stored in `$GIT_DIR/refs/stash`; older
stashes are found in the reflog of this reference and can be named using
@@ -48,8 +51,8 @@ list::
based on.
+
----------------------------------------------------------------
-stash@{0}: submit: 6ebd0e2... Add git-stash
-stash@{1}: master: 9cc0589... Merge branch 'master' of gfi
+stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
+stash@{1}: On master: 9cc0589... Add git-stash
----------------------------------------------------------------
show [<stash>]::
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2
^ permalink raw reply related
* Re: [PATCH] Add --show-size to git log to print message size
From: Andy Parkins @ 2007-07-17 7:49 UTC (permalink / raw)
To: git; +Cc: Marco Costalba, Junio C Hamano
In-Reply-To: <e5bfff550707140952hb60735bi95a4f03636c4aa99@mail.gmail.com>
On Saturday 2007 July 14, Marco Costalba wrote:
> Print message size just before the corresponding message
> to speedup the parsing by scripts/porcelains tools.
Does this really give a speedup?
I'd be surprised, as long as the parse is being done during the output from
git using the QProcess::readyRead() signal once and only once, then git is
the bottle neck. Parsing the stream is almost trivial in comparison to the
work that git is doing.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Update a bare repository
From: Thomas Glanzmann @ 2007-07-17 7:41 UTC (permalink / raw)
To: Jeff King; +Cc: GIT
In-Reply-To: <20070717073115.GA14629@coredump.intra.peff.net>
Hello Peff,
> echo "echo Sorry, no pushing allowed.; exit 1" >.git/hooks/pre-receive
> chmod +x .git/hooks/pre-receive
thank you, that does exactly what I wanted:
(faui03) [/var/tmp/git] git commit -a
Created commit 9e89d1d: added some whitespace
1 files changed, 1 insertions(+), 0 deletions(-)
(faui03) [/var/tmp/git] git push origin
updating 'refs/heads/master'
from 9dfdf14b3805e89aa2782458bda15b3dfae24c09
to 9e89d1d3890c6b0fd8546143a6e797820e274cb1
Generating pack...
Done counting 5 objects.
Result has 3 objects.
Deltifying 3 objects...
100% (3/3) done
Writing 3 objects...
100% (3/3) done
Total 3 (delta 2), reused 0 (delta 0)
Sorry, no pushing allowed.
error: hooks/pre-receive exited with error code 1
ng refs/heads/master pre-receive hook declined
error: failed to push to '131.188.30.103:/home/cip/adm/sithglan/work/repositories/mirror/git.git'
Thomas
^ permalink raw reply
* Re: Update a bare repository
From: Jeff King @ 2007-07-17 7:31 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20070717072635.GG5823@cip.informatik.uni-erlangen.de>
On Tue, Jul 17, 2007 at 09:26:35AM +0200, Thomas Glanzmann wrote:
> > The simplest thing is not to give write access to the repo for your
> > pushers. However, you could also put in a pre-receive hook that rejects
> > all pushes.
>
> Is there an example somewhere?
Not that I know of, but it should be as simple as:
echo "echo Sorry, no pushing allowed.; exit 1" >.git/hooks/pre-receive
chmod +x .git/hooks/pre-receive
-Peff
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Junio C Hamano @ 2007-07-17 7:30 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <11846059721204-git-send-email-sithglan@stud.uni-erlangen.de>
Thanks.
^ permalink raw reply
* Re: Update a bare repository
From: Thomas Glanzmann @ 2007-07-17 7:26 UTC (permalink / raw)
To: Jeff King; +Cc: GIT
In-Reply-To: <20070717070428.GA13266@coredump.intra.peff.net>
Hello,
> The "+" in both cases means that it copies whatever Junio has, even if
> it might lose some commits of yours. But that seems to be what you
> want in this case.
thanks a lot. That is exactly what I was looking for.
> The simplest thing is not to give write access to the repo for your
> pushers. However, you could also put in a pre-receive hook that rejects
> all pushes.
Is there an example somewhere?
Thomas
^ permalink raw reply
* Re: Update a bare repository
From: Jeff King @ 2007-07-17 7:04 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20070717063026.GA5823@cip.informatik.uni-erlangen.de>
On Tue, Jul 17, 2007 at 08:30:26AM +0200, Thomas Glanzmann wrote:
> I have a _bare_ clone of a git repository and would like to update it
> from Junios repository at kernel.org from time to time.
> [...]
> "git pull" does not work. "git fetch" does, but it does update all
> references?
You don't want to pull because that involves merging, which doesn't make
sense. A git-fetch is what you want, and you can use wildcards to make
sure you get all of the refs. The default is something like this:
[remote "origin"]
url = git://git2.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/origin/*
However, if you are intending to make this an _exact_ copy of Junio's
(because you will be fetching from it with your other, non-bare repos),
then you probably don't want the "separate remotes" layout. You want to
copy the refs with the same names:
[remote "origin"]
url = git://git2.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/heads/*
The "+" in both cases means that it copies whatever Junio has, even if
it might lose some commits of yours. But that seems to be what you want
in this case.
> I also would like to check that it is impossible to push anything to the
> repository.
The simplest thing is not to give write access to the repo for your
pushers. However, you could also put in a pre-receive hook that rejects
all pushes.
-Peff
^ permalink raw reply
* Update a bare repository
From: Thomas Glanzmann @ 2007-07-17 6:30 UTC (permalink / raw)
To: GIT
Hello,
what I would like to do is the following:
I have a _bare_ clone of a git repository and would like to update it
from Junios repository at kernel.org from time to time.
How do I do that? In a way that it is a fire and forget solution? It
should also fetch new upstream branches.
"git pull" does not work. "git fetch" does, but it does update all
references?
(faui02) [~/work/repositories/mirror/git.git] git pull
fatal: /usr/bin/git-pull cannot be used without a working tree.
(faui02) [~/work/repositories/mirror/git.git] git fetch
(faui02) [~/work/repositories/mirror/git.git]
I also would like to check that it is impossible to push anything to the
repository.
Thomas
^ 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