* Re: Removing options from build
From: Boyd Stephen Smith Jr. @ 2009-01-13 22:06 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
In-Reply-To: <1231883002.14181.27.camel@starfruit>
[-- Attachment #1: Type: text/plain, Size: 967 bytes --]
On Tuesday 2009 January 13 15:43:22 R. Tyler Ballance wrote:
>One of our developers "discovered" the --force option on `git push` and
>used it without taking the appropriate care and hosed one of the project
>branches we have running around in our central repository.
Reflogs should let you recover from this.
>Besides a vigorous flogging, we're looking at other ways to prevent this
>sort of thing from happening again;
receive.denyNonFastForwards
If set to true, git-receive-pack will deny a ref update which
is not a fast forward. Use this to prevent such an update via a
push, even if that push is forced. This configuration variable
is set when initializing a shared repository.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Removing options from build
From: R. Tyler Ballance @ 2009-01-13 22:00 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200901132253.15370.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]
On Tue, 2009-01-13 at 22:53 +0100, Thomas Rast wrote:
> R. Tyler Ballance wrote:
> > Besides a vigorous flogging, we're looking at other ways to prevent this
> > sort of thing from happening again; the option we've settled on is to
> > remove the "--force" flag from our internal build of v1.6.1
> >
> > I'm wondering if somebody could point me in the right direction to
> > remove "--force" (safely) from the builtin-push.c and removing the
> > "rebase" command (we've got no use for it, and would prefer it gone).
>
> IMHO your update (or pre-receive) hook should just disallow
> non-fast-forward updates.
Don't merges count as non-fast-forward updates? We generate merge
commits with almost every merge, rarely do we actually have
fast-forwards anymore (highly active repository)
>
> This doesn't really address git-rebase, but it will disallow pushing a
> "harmfully" rebased branch since those are by definition non-ff. Why
> take away the option to correct a mistake in the last commit with 'git
> rebase -i'?
I'm a strong proponent of revision history only moving forward, I would
much rather see a series of revert commits than having somebody who is
inexperienced with the tools they're using muck about an jeopardize the
stability of our central repository.
Used correctly, both --force and `rebase` have good reason to exist in
the Git codebase; they just haven't been used correctly, and proper
bamboo to flog developers with will take a couple days to ship from
Asia, so removing the options from our internal build is a lot easier
and faster ;)
Cheers :D
--
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Removing options from build
From: Thomas Rast @ 2009-01-13 21:56 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
In-Reply-To: <200901132253.15370.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]
Thomas Rast wrote:
> R. Tyler Ballance wrote:
> > I'm wondering if somebody could point me in the right direction to
> > remove "--force" (safely) from the builtin-push.c
>
> IMHO your update (or pre-receive) hook should just disallow
> non-fast-forward updates.
Actually there's even this config option:
receive.denyNonFastForwards
If set to true, git-receive-pack will deny a ref update
which is not a fast forward. Use this to prevent such an
update via a push, even if that push is forced. This
configuration variable is set when initializing a shared
repository.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Removing options from build
From: Björn Steinbrink @ 2009-01-13 21:55 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
In-Reply-To: <1231883002.14181.27.camel@starfruit>
On 2009.01.13 13:43:22 -0800, R. Tyler Ballance wrote:
> One of our developers "discovered" the --force option on `git push` and
> used it without taking the appropriate care and hosed one of the project
> branches we have running around in our central repository.
>
> Besides a vigorous flogging, we're looking at other ways to prevent this
> sort of thing from happening again; the option we've settled on is to
> remove the "--force" flag from our internal build of v1.6.1
>
> I'm wondering if somebody could point me in the right direction to
> remove "--force" (safely) from the builtin-push.c and removing the
> "rebase" command (we've got no use for it, and would prefer it gone).
git help config
receive.denyNonFastForwards (to refuse non-fast-forwards, even with -f)
receive.denyDeletes (to stop users from working around the non-ff using
a delete + recreate operation)
Björn
^ permalink raw reply
* Re: Removing options from build
From: Thomas Rast @ 2009-01-13 21:53 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
In-Reply-To: <1231883002.14181.27.camel@starfruit>
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]
R. Tyler Ballance wrote:
> Besides a vigorous flogging, we're looking at other ways to prevent this
> sort of thing from happening again; the option we've settled on is to
> remove the "--force" flag from our internal build of v1.6.1
>
> I'm wondering if somebody could point me in the right direction to
> remove "--force" (safely) from the builtin-push.c and removing the
> "rebase" command (we've got no use for it, and would prefer it gone).
IMHO your update (or pre-receive) hook should just disallow
non-fast-forward updates.
This doesn't really address git-rebase, but it will disallow pushing a
"harmfully" rebased branch since those are by definition non-ff. Why
take away the option to correct a mistake in the last commit with 'git
rebase -i'?
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Jay Soffian @ 2009-01-13 21:46 UTC (permalink / raw)
To: Vladimir Pouzanov; +Cc: git, Eric Wong
In-Reply-To: <loom.20090113T213400-985@post.gmane.org>
On Tue, Jan 13, 2009 at 4:34 PM, Vladimir Pouzanov <farcaller@gmail.com> wrote:
> Jay Soffian <jaysoffian <at> gmail.com> writes:
>> Perhaps this will help in tracking down the problem.
>
> $ git svn clone http://qsb-mac.googlecode.com/svn/trunk qsb-mac
> Initialized empty Git repository in /Users/farcaller/temp/qsb-mac/.git/
> r1 = 810fe584c48b884460b5403a28bc61d872452b93 (git-svn)
> Temp file with moniker 'svn_delta' already in use at /opt/local/lib/perl5/
> site_perl/5.8.8/Git.pm line 1011.
Hrmm, to me that doesn't help very much. Perhaps the author of git-svn
(cc'd) might have an idea.
BTW, I installed git-core via DarwinPorts and I can clone w/that
version as well.
$ port info --name --version git-core subversion perl5.8
version: 1.6.1
name: git-core
--
version: 1.5.5
name: subversion
--
version: 5.8.9
name: perl5.8
I was hoping it would fail for me so I could poke and prod.
j.
^ permalink raw reply
* Removing options from build
From: R. Tyler Ballance @ 2009-01-13 21:43 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
One of our developers "discovered" the --force option on `git push` and
used it without taking the appropriate care and hosed one of the project
branches we have running around in our central repository.
Besides a vigorous flogging, we're looking at other ways to prevent this
sort of thing from happening again; the option we've settled on is to
remove the "--force" flag from our internal build of v1.6.1
I'm wondering if somebody could point me in the right direction to
remove "--force" (safely) from the builtin-push.c and removing the
"rebase" command (we've got no use for it, and would prefer it gone).
Cheers
--
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: egit problem with sym linked eclipse project dirs
From: Robin Rosenberg @ 2009-01-13 21:37 UTC (permalink / raw)
To: Stephen Bannasch, Shawn O. Pearce; +Cc: git, Scott Cytacki
In-Reply-To: <p0624081cc5928e2885fd@[192.168.1.114]>
> To hack around Eclipse's problem with projects in nested directories
> I clone a repo and then create a new top-level dir that just has
> symbolic links to all the project directories.
>
> However when I Team/Share with git using egit the resources become
> untracked when displayed in Eclipse -- they still are tracked however
> when I check from the command line.
I've seen this too, but so far not got myself to actually fix it. I think it has do with
that we ask eclipse project for it's path end there we gets off track. Thanks
for providing a good example that help "someone" to fix it.
Could you add an issue at http://code.google.com/p/egit/issues/list and maybe
include a tar ball with a simple project displaying this behaviour? (with a note
that the symlinks makes this impossible to recreate on Windows).
-- robin
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Vladimir Pouzanov @ 2009-01-13 21:34 UTC (permalink / raw)
To: git
In-Reply-To: <76718490901131328x5ec30805u3cae29132defd695@mail.gmail.com>
Jay Soffian <jaysoffian <at> gmail.com> writes:
> Perhaps this will help in tracking down the problem.
$ git svn clone http://qsb-mac.googlecode.com/svn/trunk qsb-mac
Initialized empty Git repository in /Users/farcaller/temp/qsb-mac/.git/
r1 = 810fe584c48b884460b5403a28bc61d872452b93 (git-svn)
Temp file with moniker 'svn_delta' already in use at /opt/local/lib/perl5/
site_perl/5.8.8/Git.pm line 1011.
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Jay Soffian @ 2009-01-13 21:28 UTC (permalink / raw)
To: Vladimir Pouzanov; +Cc: git
In-Reply-To: <loom.20090113T211437-12@post.gmane.org>
On Tue, Jan 13, 2009 at 4:16 PM, Vladimir Pouzanov <farcaller@gmail.com> wrote:
> Temp file with moniker ' at /opt/local/lib/perl5/site_perl/5.8.8/Git.pm line
> 1011.
Ah "throw Error::Simple(...)" w/multiple arguments does not work as
the caller thought. Can you manually edit
/opt/local/lib/perl5/site_perl/5.8.8/Git.pm and edit lines 1011 and
1012. So instead of:
if ($TEMP_FILES{$$temp_fd}{locked}) {
throw Error::Simple("Temp file with moniker '",
$name, "' already in use");
}
It will look like:
if ($TEMP_FILES{$$temp_fd}{locked}) {
throw Error::Simple("Temp file with moniker '" .
$name . "' already in use");
}
(i.e., replace the commas with dots.)
Perhaps this will help in tracking down the problem.
j.
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Jay Soffian @ 2009-01-13 21:20 UTC (permalink / raw)
To: Vladimir Pouzanov; +Cc: git
In-Reply-To: <76718490901131312j28f8283bi94f55000e70c532e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
On Tue, Jan 13, 2009 at 4:12 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> Your original email doesn't appear to provide the complete error
> message. I'm on OS X 10.5.6 (Intel), git 1.6.1.77.g81ea1, system perl
> (/usr/bin/perl - 5.8.8) and I'm able to clone okay:
BTW, since it's the system perl, it's also the system Perl subversion
bindings, which means 1.4.4.
IOW, even though I have MacPorts installed, I define NO_DARWIN_PORTS=1
during install. I've attached the script I use for compiling &
installing git for reference.
j.
[-- Attachment #2: gitmake --]
[-- Type: application/octet-stream, Size: 1033 bytes --]
#!/bin/sh -ex
export PATH=.:$PATH
SUDO=
export ASCIIDOC8=1
export DOCBOOK_XSL_172=1
makecmd () {
$SUDO make prefix="/opt/git" \
CFLAGS="-Wall -O2 -I/usr/include" \
LDFLAGS="-L/usr/lib" \
CURLDIR="/usr" \
OPENSSLDIR="/usr" \
ICONVDIR="/usr" \
PERL_PATH="/usr/bin/perl" \
THREADED_DELTA_SEARCH=1 \
NO_FINK=1 NO_DARWIN_PORTS=1 \
"$@"
}
build () {
(cd git-gui && sudo make clean)
makecmd all doc gitweb/gitweb.cgi
}
test () {
makecmd test
}
install () {
build
sudo rm -rf /opt/git
SUDO=sudo makecmd install install-man install-html
sudo rm -rf /opt/git/System
sudo mkdir /opt/git/share/gitweb || true
sudo cp -f gitweb/git* /opt/git/share/gitweb/
sudo rm -f /opt/git/share/gitweb/gitweb.perl
sudo cp contrib/gitview/gitview /opt/git/bin/gitview
sudo chmod 755 /opt/git/bin/gitview
sudo cp contrib/completion/git-completion.bash /opt/git/share/git-core/
sudo chmod 644 /opt/git/share/git-core/git-completion.bash
}
case "$1" in
test) test ;;
build) build ;;
install) install ;;
*) build ;;
esac
^ permalink raw reply
* Re: stg coalesce -> squash?
From: Catalin Marinas @ 2009-01-13 21:19 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20090113164157.GA20143@diana.vm.bytemark.co.uk>
2009/1/13 Karl Hasselström <kha@treskal.com>:
> Would it be a good idea to rename "stg coalesce" to "stg squash"?
> That's the term git uses, and it's shorter, easier to spell, and
> easier to say.
Yes, that's a good change. I always wondered how to pronounce "coalesce" :-).
--
Catalin
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Vladimir Pouzanov @ 2009-01-13 21:16 UTC (permalink / raw)
To: git
In-Reply-To: <76718490901131312j28f8283bi94f55000e70c532e@mail.gmail.com>
Jay Soffian <jaysoffian <at> gmail.com> writes:
> Your original email doesn't appear to provide the complete error
> message. I'm on OS X 10.5.6 (Intel), git 1.6.1.77.g81ea1, system perl
> (/usr/bin/perl - 5.8.8) and I'm able to clone okay:
$ git version
git version 1.6.1
$ git svn clone http://qsb-mac.googlecode.com/svn/trunk qsb-mac
Initialized empty Git repository in /Users/farcaller/temp/qsb-mac/.git/
r1 = 810fe584c48b884460b5403a28bc61d872452b93 (git-svn)
A externals/BSJSONAdditions/NSDictionary+BSJSONAdditions.m
A externals/BSJSONAdditions/Example/Unit Tests/Test
Files/json_test_valid_01.txt
A externals/BSJSONAdditions/Example/Unit Tests/Test
Files/json_test_valid_02.txt
A externals/BSJSONAdditions/Example/version.plist
A externals/BSJSONAdditions/Example/main.m
A externals/BSJSONAdditions/Example/Unit Tests/Test
Files/json_test_valid_03.txt
A externals/BSJSONAdditions/NSArray+BSJSONAdditions.m
A externals/BSJSONAdditions/BSJSON.h
A externals/BSJSONAdditions/NSDictionary+BSJSONAdditions.h
Temp file with moniker ' at /opt/local/lib/perl5/site_perl/5.8.8/Git.pm line
1011.
Git, subversion and perl are from macports:
$ port info perl5
perl5 @5.8.8, Revision 2 (lang)
$ port info git-core
git-core @1.6.1 (devel)
Variants: bash_completion, doc, gitweb, svn
$ port info subversion
subversion @1.5.5 (devel)
Variants: bash_completion, (-)darwin_7, mac_os_x_server_mod_dav_svn,
mod_dav_svn, no_bdb, no_neon, tools, unicode_path, (-)universal
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Jay Soffian @ 2009-01-13 21:12 UTC (permalink / raw)
To: Vladimir Pouzanov; +Cc: git
In-Reply-To: <loom.20090113T204616-845@post.gmane.org>
On Tue, Jan 13, 2009 at 3:46 PM, Vladimir Pouzanov <farcaller@gmail.com> wrote:
> Björn Steinbrink <B.Steinbrink <at> gmx.de> writes:
>> Is that Linux box using Gentoo? If so, try emerging subversion with -dso
>> in your build flags.
>
> Yeah, that's gentoo. Will try rebuilding svn now. Any hints about OSX
> perl problem?
Your original email doesn't appear to provide the complete error
message. I'm on OS X 10.5.6 (Intel), git 1.6.1.77.g81ea1, system perl
(/usr/bin/perl - 5.8.8) and I'm able to clone okay:
$ which git
/opt/git/bin/git
$ git version
git version 1.6.1.77.g81ea1
$ git svn clone http://qsb-mac.googlecode.com/svn/trunk qsb-mac
...
Checked out HEAD:
http://qsb-mac.googlecode.com/svn/trunk r21
j.
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Vladimir Pouzanov @ 2009-01-13 20:46 UTC (permalink / raw)
To: git
In-Reply-To: <20090113203922.GD30404@atjola.homenet>
Björn Steinbrink <B.Steinbrink <at> gmx.de> writes:
> Is that Linux box using Gentoo? If so, try emerging subversion with -dso
> in your build flags.
Yeah, that's gentoo. Will try rebuilding svn now. Any hints about OSX
perl problem?
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Björn Steinbrink @ 2009-01-13 20:39 UTC (permalink / raw)
To: Vladimir Pouzanov; +Cc: git
In-Reply-To: <loom.20090113T185918-397@post.gmane.org>
On 2009.01.13 19:01:28 +0000, Vladimir Pouzanov wrote:
> Michael J Gruber <git <at> drmicha.warpmail.net> writes:
> > This is with git 1.6.1rc4 (yeah I should have updated), perl 5.8.8 and
> > svn 1.4.6 on Linux. Same with git 1.6.0.6, perl 5.10.0 and svn 1.5.4 on
> > another box. The one git-svn change between 1.6.0.4 and 1.6.0.6 should
> > not matter because you don't have branches. What's your svn version?
>
> svn, version 1.5.5 (r34862) on OSX (where perl fails with error) and
> svn, version 1.5.0 (Release Candidate
> 5) on Linux
> (where perl segfaults somewhere in apr).
Is that Linux box using Gentoo? If so, try emerging subversion with -dso
in your build flags.
Cloning the svn repo you mentioned works fine with
git-svn version 1.6.1.40.g8ea6a (svn 1.5.1)
(On debian sid)
Björn
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Kyle Moffett @ 2009-01-13 20:26 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Linus Torvalds, Sam Ravnborg, Johannes Schindelin, git,
Linux Kernel Mailing List
In-Reply-To: <200901112239.20306.borntraeger@de.ibm.com>
On Sun, Jan 11, 2009 at 4:39 PM, Christian Borntraeger
<borntraeger@de.ibm.com> wrote:
> In my opinion we should really avoid subtree merges in the future as a curtesy
> to people who do the uncool work of testing, problem tracking and bisecting.
> </rant>
As an alternative, you can relatively easily rewrite the following
independent histories:
A -- B -- C
X -- Y -- Z
To look like this:
A -- B -- C -- X' -- Y' -- Z'
Where X' is (C + sub/dir/X), Y' is (C + sub/dir/Y), etc...
Assuming the following:
"master" branch points to commit C
"child" branch points to commit Z
"${KIDSTART}" is the SHA1 id of commit X
echo "${KIDSTART} $(git rev-parse --verify master)" >>.git/info/grafts
git filter-branch --index-filter 'git read-tree master && git
read-tree --prefix="sub/dir/" "${GIT_COMMIT}"' -- master..child
The one downside is then somebody actually has to *test* those commits
when doing a bisect, even though they did not materially change
anything. The upside is that there isn't any "what the hell just
happened?" when you *do* end up in the newly-created branch.
Cheers,
Kyle Moffett
^ permalink raw reply
* Commit messages
From: Teemu Likonen @ 2009-01-13 20:24 UTC (permalink / raw)
To: Adeodato Simó
Cc: Boyd Stephen Smith Jr., Shawn O. Pearce, Ted Pavlic, git,
Junio C Hamano
In-Reply-To: <20090113201024.GA20129@chistera.yi.org>
Adeodato Simó (2009-01-13 21:10 +0100) wrote:
> * Boyd Stephen Smith Jr. [Tue, 13 Jan 2009 14:03:11 -0600]:
>
>> My rule for this is absolutely no more than 80 characters.
>
> My rule for *all* of the commit message is "absolutely no more than 76
> characters". With more than 76, `git log` wraps in a 80-column terminal.
Here's my rule:
(add-to-list 'auto-mode-alist
'("/\\.git/\\(COMMIT\\|TAG\\)_EDITMSG\\'" .
vcs-message-mode))
(define-derived-mode vcs-message-mode text-mode "VCS-message"
"Major mode for editing commit and tag messages."
(auto-fill-mode 1)
(set (make-local-variable 'tab-stop-list)
(number-sequence 4 100 4))
(setq indent-tabs-mode nil
fill-column 72
truncate-lines t))
^ permalink raw reply
* Re: [PATCH/RFC v7 0/5] git checkout: optimise away lots of lstat() calls
From: Junio C Hamano @ 2009-01-13 20:17 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Pete Harlan, Linus Torvalds
In-Reply-To: <1231849748-8244-1-git-send-email-barvik@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> Junio, I hope it is possible to use patches 1/5, 2/5 and 3/5 from this
> version instead of 1/3, 2/3 and 3/3 from version 6, for the possible
> future in origin/pu? See also a) above. Thanks in advance!
>
> In general, are we allowed to redesign the patch-series while the
> patches is inside origin/pu?
You won't be too far off if you thought of 'pu' branch nothing more than
my bookmarks into the list archive. They are interesting enough to keep
an eye on their evolution but not yet stable enough to go into initial
round of wider testing and incremental development which starts to happen
when they hit 'next'.
So yes, while you are not yet confident that the series does not need
major redesign, please keep sending replacements (not incremental
updates), making it clear that you still have reservations and I'll keep
them in 'pu', until the initial barrage of "Oh, I think this way is
better", "The previous review comments were valuable, and this round
contains all of them" is over and things seem to stabilize into a testable
shape.
Personally I felt your v5 and later ones were already 'next' material, and
the only reason why the series haven't landed on 'next' was because you
kept sending updates before I sat down in the evening and said "Ok, this
looks good---let's merge it to 'next'". Instead I ended up saying "Hmph,
I thought it looked good already but the author seems not satisfied yet;
there is another round of update to replace the previous one. Let's queue
it in 'pu', as it may be updated again, and I have to also look at series
from other people.' ;-)
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Asheesh Laroia @ 2009-01-13 20:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alex Riesen, git
In-Reply-To: <200901130039.48340.jnareb@gmail.com>
On Tue, 13 Jan 2009, Jakub Narebski wrote:
> Asheesh Laroia wrote:
>> On Mon, 12 Jan 2009, Jakub Narebski wrote:
>>
>>> But I have to run
>>>
>>> $ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
>>>
>>> first. Is there any way to automate this?
>>
>> Check out 'gstm' or 'autossh'.
>
> I don't know about gSTM (Gnome SSH Tunnel Manager), but autossh
> does only provide reconnect in the case the gateway host closes
> connection. I still have to run it, perhaps from startup script.
Yeah, gSTM is pretty manual in that regard. autossh from a startup script
makes sense.
-- Asheesh.
--
Q: How many marketing people does it take to change a light bulb?
A: I'll have to get back to you on that.
^ permalink raw reply
* Re: [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors can recognize, it as a bash script. Also adds a few simple comments above commands that, take arguments. The comments are meant to remind editors of potential, problems that can occur when the script is sourced on systems with "set, -u."
From: Adeodato Simó @ 2009-01-13 20:10 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Shawn O. Pearce, Ted Pavlic, git, Junio C Hamano
In-Reply-To: <200901131403.16012.bss@iguanasuicide.net>
* Boyd Stephen Smith Jr. [Tue, 13 Jan 2009 14:03:11 -0600]:
> On Tuesday 2009 January 13 10:45:18 Shawn O. Pearce wrote:
> >See [...] how the subject is a niceshort, one
> >line summary of the module impacted and the change?
> My rule for this is absolutely no more than 80 characters.
My rule for *all* of the commit message is "absolutely no more than 76
characters". With more than 76, `git log` wraps in a 80-column terminal.
Just my 2¢,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
La música es de los que la quieren escuchar y de nadie más.
-- Andrés Calamaro
^ permalink raw reply
* Re: [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors can recognize, it as a bash script. Also adds a few simple comments above commands that, take arguments. The comments are meant to remind editors of potential, problems that can occur when the script is sourced on systems with "set, -u."
From: Boyd Stephen Smith Jr. @ 2009-01-13 20:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Ted Pavlic, git, Junio C Hamano
In-Reply-To: <20090113164518.GS10179@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]
On Tuesday 2009 January 13 10:45:18 Shawn O. Pearce wrote:
>See [...] how the subject is a niceshort, one
>line summary of the module impacted and the change?
My rule for this is absolutely no more than 80 characters. Generally, you
wouldn't want more than 60 or so, since it is used as the Subject: header and
generally has some prefix added.
As shown says, details can go in the rest of the commit message. If you are
using more than 60-80 characters even without details, you might think about
splitting the patch.
>This is all based on the formatting at the time of commit.
>Anything up to the first "\n\n" in a commit message goes into the
>email subject line.
IIRC, multiple "-m" options to "git commit" will be separated by "\n\n", so
that's one way to do it if you don't like your $EDITOR for some reason.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* egit problem with sym linked eclipse project dirs
From: Stephen Bannasch @ 2009-01-13 20:00 UTC (permalink / raw)
To: git; +Cc: Scott Cytacki
To hack around Eclipse's problem with projects in nested directories
I clone a repo and then create a new top-level dir that just has
symbolic links to all the project directories.
However when I Team/Share with git using egit the resources become
untracked when displayed in Eclipse -- they still are tracked however
when I check from the command line.
---- more details ----
using v0.4.0.200901041117 of egit
I've got a large dir structure in a git repo in which there are many
eclipse projects at different levels of the tree.
However Eclipse doesn't work with projects at different levels in a
nested dir structure (bad Eclipse) -- see: Eclipse bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973
When we work with these projects with svn we checkout each one
individually into it's own dir to create the flat hierarchy Eclipse
needs. Updating all these separate projects takes forever -- at
least compared to using Git.
I created a Ruby script to create a new dir named 'workspace' at the
top level of a checkout with symbolic links to all the enclosed
directories that have a .project file inside them.
http://svn.concord.org/svn/projects/trunk/common/flatten_projects.rb
or here in the git mirror:
http://gitorious.org/projects/otrunk-examples/repos/mainline/blobs/raw/5c5ca6ff830f4ad3e4d427df92c1a5dff64831b5/flatten_projects.rb
(warning: repos are public but very big)
The result is a dir: workspace/ that emulates the flat project space
that Eclipse needs:
http://gist.github.com/4658 (a bunch of these are legacy projects)
Then I open Eclipse, switch to a new Workspace, select the
newly-created 'workspace' dir and import the projects to work on.
This works fine for Eclipse. The projects build and reference each other.
But when I then turn on the team/sharing/git for each project ...
The operation completes -- the git decorator appears showing [Git @ master] ...
but the files are all untracked.
Screenshots showing the sequence after importing just 7 projects:
apple-support, framework, frameworkview, otrunk, swing, thirdparty-jars
share projects:
http://skitch.com/stepheneb/bbnqf/skitched-20090113-144412
select git:
http://img.skitch.com/20090113-peu5y38a1yqm4kfqasf6hh9r9t.png
iterate through each project:
http://img.skitch.com/20090113-k6wf8xgs2bc4ehy9siscdyteqr.png
http://img.skitch.com/20090113-jughm7eatnuum43gfuedmctrw5.png
showing untracked files on master branch:
http://skitch.com/stepheneb/bbnqc/skitched-20090113-144646
However from the command line git shows the appropriate untracked
files after an Eclipse build:
$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# java/core/apple-support/bin/
# java/core/framework/lib/
# java/core/frameworkview/lib/
# java/core/swing/lib/
# java/otrunk/otrunk/lib/
# java/thirdparty/phet-simulations-java/simulations/cck/cck
# rails/portal/portal
# workspace/
^ permalink raw reply
* [PATCH next] git-notes: fix printing of multi-line notes
From: Tor Arne Vestbø @ 2009-01-13 19:57 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, junio
The line length was read from the same position every time,
causing mangled output when printing notes with multiple lines.
Also, adding new-line manually for each line ensures that we
get a new-line between commits, matching git-log for commits
without notes.
Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com>
---
This approach uses a msg pointer, but I started out with just using
msg + msgoffset all over the place, so if that's a preferred way
to do things I'm happy to provide an alternate patch.
Also, I'm guessing this printing should go into pretty.c at some
point, so you can reference the notes as part of a custom pretty
format. If so, this code could be converted to use helpers such
as get_one_line().
This is my first patch to Git, so sorry if I messed something up :)
notes.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/notes.c b/notes.c
index ad43a2e..bd73784 100644
--- a/notes.c
+++ b/notes.c
@@ -110,8 +110,8 @@ void get_commit_notes(const struct commit *commit, struct strbuf *sb,
{
static const char *utf8 = "utf-8";
unsigned char *sha1;
- char *msg;
- unsigned long msgoffset, msglen;
+ char *msg, *msg_p;
+ unsigned long linelen, msglen;
enum object_type type;
if (!initialized) {
@@ -148,12 +148,13 @@ void get_commit_notes(const struct commit *commit, struct strbuf *sb,
strbuf_addstr(sb, "\nNotes:\n");
- for (msgoffset = 0; msgoffset < msglen;) {
- int linelen = strchrnul(msg, '\n') - msg;
+ for (msg_p = msg; msg_p < msg + msglen; msg_p += linelen + 1) {
+ linelen = strchrnul(msg_p, '\n') - msg_p;
strbuf_addstr(sb, " ");
- strbuf_add(sb, msg + msgoffset, linelen);
- msgoffset += linelen;
+ strbuf_add(sb, msg_p, linelen);
+ strbuf_addch(sb, '\n');
}
+
free(msg);
}
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: [PATCH 1/3] Purest update to bash completions to prevent unbounded variable errors.
From: Junio C Hamano @ 2009-01-13 19:43 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Shawn O. Pearce, git
In-Reply-To: <496CC3E7.8060805@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
>> Your commit message leaves a lot to be desired. I would instead
>> have written something like this:
>
> I agree completely. Sorry about that. stg fired off vim to edit the
> commit message, and I just wasn't thinking.
>
> Would you like me to modify the commit message and resubmit?
Luckily or unluckily, you need to do that anyway, as your patches are
whitespace damaged.
Please don't send "format=flowed".
^ 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