* [ANNOUNCE] tig-0.13
From: Jonas Fonseca @ 2009-01-13 23:36 UTC (permalink / raw)
To: git
Hello,
This release contains a major rewrite of the IO layer of tig to use
fork+exec instead of popen() and remove use of stdio's fopen() and
friends. The new IO API removes the need for shell quoting and improves
the overall speed of loading view data. On the downside, it brings a few
incompatibilities wrt. commands given via the environment. While the
patch series began by being based on git's run-command.c module, the
final version contains no code from git.
The release also brings a few new features, such as new identifiers for
use in external commands as well as a handful of bug fixes.
What is tig?
------------
Tig is an ncurses-based text-mode interface for git. It functions mainly
as a git repository browser, but can also assist in staging changes for
commit at chunk level and act as a pager for output from various git
commands.
- Homepage: http://jonas.nitro.dk/tig/
- Manual: http://jonas.nitro.dk/tig/manual.html
- Tarballs: http://jonas.nitro.dk/tig/releases/
- Git URL: git://repo.or.cz/tig.git
- Gitweb: http://repo.or.cz/w/tig.git
Release notes
-------------
Incompatibilities:
- Commands from the environment (e.g. TIG_MAIN_CMD) will no longer have
access to shell features, such as subshells and variable expansion.
The easiest way to upgrade your configuration is to put such commands
in a script file.
Improvements:
- Display repository references in the sorted order: tags, heads,
tracked remotes, remotes.
- Add bash completion for blame.
- Tree view: edit files of the current branch.
- Run requests: new identifiers %(directory), %(file), and %(ref)
- Improve responsiveness and view loading speed by using select(2).
Bug fixes:
- Separate blame revision and file argument by "--" to avoid problems.
- Main view: fix redrawing of the last commit wrt. the revision graph.
- Fix waiting for input after executing a run request in pager mode.
- Status & stage view: refuse to open directories and deleted files.
- Tree view: show error when requesting blame for all non-file entries.
- Do not draw loading views, which are not displayed.
- Fix launching of mergetool from a subdirectory.
Change summary
--------------
The diffstat and log summary for changes made in this release.
NEWS | 29 +
VERSION | 2 +-
contrib/announcement.sh | 2 +-
contrib/tig-completion.bash | 25 +-
manual.txt | 281 ++++---
tig.1.txt | 6 +-
tig.c | 1774 +++++++++++++++++++++--------------
tigrc.5.txt | 23 +-
8 files changed, 1325 insertions(+), 817 deletions(-)
53 Jonas Fonseca
--
Jonas Fonseca
^ permalink raw reply
* Re: egit problem with sym linked eclipse project dirs
From: Stephen Bannasch @ 2009-01-13 23:27 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git, Scott Cytacki
In-Reply-To: <200901132237.11946.robin.rosenberg.lists@dewire.com>
At 10:37 PM +0100 1/13/09, Robin Rosenberg wrote:
> > 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).
Done: http://code.google.com/p/egit/issues/detail?id=52
Fxing this will make using Eclipse and Git together SO much nicer!
^ permalink raw reply
* Re: Removing options from build
From: Daniel Barkalow @ 2009-01-13 22:47 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: Thomas Rast, git
In-Reply-To: <1231884045.14181.36.camel@starfruit>
On Tue, 13 Jan 2009, R. Tyler Ballance wrote:
> 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)
Creating a merge is a non-fast-forward update, but sending the merge to a
repository that is currently at one of the parents is a fast-forward.
Hopefully, you're generating merge commits with merge, not with push. :)
> > 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 ;)
Denying non-fast-forward updates means that people can rebase, but if they
rebase anything that they've pushed (or anyone else has pushed), they
can't push.
You can't really disallow rebasing of private commits while still using
git; a user can always clone the upstream repository again, get diffs from
the repository where they don't like the history, apply them to the new
clone, and throw away the repository with the bad history. Or they can
call up a coworker, tell them what changes to make, commit, and push, and
then lose their work in a hard drive crash. People can always make the
excuse "My identical twin did stuff wrong, but I knocked him out before
he could push and did everything right." As long as they can't say "My
evil twin pushed the changes to the repository's evil twin, but I knocked
him out and destoryed the evil repository, and now we've got the good
repository."
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Fix Documentation typos surrounding the word 'handful'.
From: Johannes Schindelin @ 2009-01-13 22:45 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Junio C Hamano, Git List
In-Reply-To: <1231869591.19818.33.camel@ld0161-tx32>
Hi,
On Tue, 13 Jan 2009, Jon Loeliger wrote:
> On Tue, 2009-01-13 at 01:24 -0800, Junio C Hamano wrote:
> > Thanks, applied with fix from Markus and Sam.
>
> Thanks, Junio, for fixinf my lameness... :-)
Heh, I found this quote from Gerald M. Weinberg today:
The computer "doth make fools of us all," so that any fool without
the ability to share a laugh on himself will be unable to tolerate
programming for long.
Chuckles,
Dscho
^ permalink raw reply
* [PATCH] Git.pm: call Error::Simple() properly
From: Jay Soffian @ 2009-01-13 22:41 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Eric Wong, Junio C Hamano
The error message to Error::Simple() must be passed as a single argument.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
perl/Git.pm | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 8392a68..e9f8c9c 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1010,8 +1010,8 @@ sub _temp_cache {
my $temp_fd = \$TEMP_FILEMAP{$name};
if (defined $$temp_fd and $$temp_fd->opened) {
if ($TEMP_FILES{$$temp_fd}{locked}) {
- throw Error::Simple("Temp file with moniker '",
- $name, "' already in use");
+ throw Error::Simple("Temp file with moniker '" .
+ $name . "' already in use");
}
} else {
if (defined $$temp_fd) {
--
1.6.1.77.g81ea1
^ permalink raw reply related
* Re: [PATCH next] git-notes: fix printing of multi-line notes
From: Johannes Schindelin @ 2009-01-13 22:40 UTC (permalink / raw)
To: Tor Arne Vestbø; +Cc: git, junio
In-Reply-To: <496CF21C.2050500@trolltech.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 556 bytes --]
Hi,
On Tue, 13 Jan 2009, Tor Arne Vestbø wrote:
> 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>
> ---
Patch looks good, so
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
For extra browny points, you could add a test with multi-line notes.
Ciao,
Dscho
^ permalink raw reply
* Re: Removing options from build
From: Boyd Stephen Smith Jr. @ 2009-01-13 22:34 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
In-Reply-To: <1231885132.14181.38.camel@starfruit>
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
On Tuesday 2009 January 13 16:18:52 R. Tyler Ballance wrote:
>On Tue, 2009-01-13 at 16:06 -0600, Boyd Stephen Smith Jr. wrote:
>> 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.
>
>Looks good, thanks; sorry I missed it, didn't even think to look at the
>git-config(1) page for such an option.
I didn't really know about it until earlier this week. I was expecting to be
able to do a non-ff push to one of my repositories and it didn't work because
this was set "behind my back". (I'm not sure when it got added, but I don't
think the shared repositories I set up with git 1.4.4.4 had it, so I wasn't
expecting it.)
>I'm assuming this will actually cover the rebase -i case as well?
I don't know exactly what you mean. It prevents fast-forwards, so once a
commit is "visible" on one of your central branches, it won't ever go away.
(You can, of course, use git revert to undo it's changes.)
As others mentioned, now would be a good time to look at receive.denyDeletes
and/or a custom hook as well.
--
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:18 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901131606.04634.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]
On Tue, 2009-01-13 at 16:06 -0600, Boyd Stephen Smith Jr. wrote:
> 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.
Looks good, thanks; sorry I missed it, didn't even think to look at the
git-config(1) page for such an option.
I'm assuming this will actually cover the rebase -i case as well?
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: Removing options from build
From: Boyd Stephen Smith Jr. @ 2009-01-13 22:10 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: Thomas Rast, git
In-Reply-To: <1231884045.14181.36.camel@starfruit>
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
On Tuesday 2009 January 13 16:00:45 R. Tyler Ballance wrote:
>On Tue, 2009-01-13 at 22:53 +0100, Thomas Rast wrote:
>> IMHO your update (or pre-receive) hook should just disallow
>> non-fast-forward updates.
>
>Don't merges count as non-fast-forward updates?
No. If there is a chain of parent links X ~> Y then updating a ref Y -> X is
a fast-forward.
--
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: Björn Steinbrink @ 2009-01-13 22:07 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: Thomas Rast, git
In-Reply-To: <1231884045.14181.36.camel@starfruit>
On 2009.01.13 14:00:45 -0800, R. Tyler Ballance wrote:
> 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)
No, merges are "fast-forward". In rev-list terms:
git rev-list new_head..old_head ==> Empty
IOW: No commits are lost by the push.
Merges only add commits to the history, they don't remove anything.
Björn
^ permalink raw reply
* Re: How to pull remote branch with specified commit id?
From: Brad King @ 2009-01-13 21:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailinglist
In-Reply-To: <496C6234.9040903@viscovery.net>
Johannes Sixt wrote:
> Consider this: You accidentally push a branch with confidential data to a
> public repository. You notice it early, and quickly delete the branch
> using 'git push the-repo :refs/heads/that-branch'. At this time the
> objects with the confidential data are still lingering in the public
> repository. But with the current behavior noone can access them even if
> the SHA1 happens to be known.
Might a repack (perhaps an automatic one) put the object in a pack
(perhaps in a delta chain) that can be fetched through another ref?
-Brad
^ permalink raw reply
* Re: Removing options from build
From: Jakub Narebski @ 2009-01-13 22:05 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
In-Reply-To: <1231883002.14181.27.camel@starfruit>
"R. Tyler Ballance" <tyler@slide.com> writes:
> 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).
First, the title (subject) of this email is misleading: it is about
your solution, and not about the problem you have (protecting against
"git push --force").
Second, there are two possible solutions: use receive.denyNonFastForwards
and perhaps also receive.denyDeletes (see git-config(1)) to forbid forced
pushes on server (target of push); removing '--force' is a client solution.
Or, better, use update or post-receive hook on server, forbidding
non-fastforward updates to selected set of 'stable' branches; you can
use contrib/hooks/update-paranoid for that.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* 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
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