* Re: git-diff should not fire up $PAGER, period!
From: Miles Bader @ 2008-12-22 3:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: jidanni, git
In-Reply-To: <alpine.LFD.2.00.0812171401300.14014@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> And then you have the _gall_ to talk about "unix design"...
Another beer?
-Miles
--
Suburbia: where they tear out the trees and then name streets after them.
^ permalink raw reply
* Re: [PATCH] Add support for changing packed_git_window_size at process start time
From: R. Tyler Ballance @ 2008-12-22 6:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081221222848.GE17355@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]
On Sun, 2008-12-21 at 14:28 -0800, Shawn O. Pearce wrote:
>
> I think this is a good idea, trying to fit within the ulimit
> rather than assuming we can take whatever we please. But you
> also need to drop the packed_git_limit down.
>
> My suggestion is this:
>
> packed_git_limit = as->rlim_cur * 0.85;
> packed_git_window_size = packed_git_limit / 4;
>
> or maybe / 2. You really want at least 2 windows available within
> your limit.
Ah, gotcha, sounds like a good idea. I went ahead and added the change
and I'm still getting the memory issues.
I'm not as familiar with using gdb(1), so I'm having trouble tracking
down the issue in a limited session, I get loads of issues like the
following when trying to step through an execution of `git log`
1368 if (diff_setup_done(&revs->diffopt) < 0)
(gdb)
utils.c:1065: internal-error: virtual memory exhausted: can't
allocate 4064 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n
utils.c:1065: internal-error: virtual memory exhausted: can't
allocate 4064 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
(gdb) q
The program is running. Quit anyway (and kill it)? (y or n) y
tyler@starfruit:~/source/git/main>
Is there a means in which I can cause a core dump on an ENOMEM error passed back from mmap(2)? That or a way to impose these limits on the gdb git-subprocess but not on the gdb process?
Appreciate the help :)
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: git-diff should not fire up $PAGER, period!
From: Johannes Sixt @ 2008-12-22 7:55 UTC (permalink / raw)
To: Miles Bader; +Cc: jidanni, git
In-Reply-To: <buo3aggyjmy.fsf@dhapc248.dev.necel.com>
Miles Bader schrieb:
> Just (setenv "PAGER" "cat") in .emacs.
>
> [I actually have it set to /bin/cat, not sure if that's meaningful or not.]
No, really, you should set it to plain "cat": As a special case git
recognizes this token and does not run any pager. If you set it to
"/bin/cat" it does run a pager, namely /bin/cat.
-- Hannes
^ permalink raw reply
* Re: git-diff should not fire up $PAGER, period!
From: Junio C Hamano @ 2008-12-22 8:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Miles Bader, jidanni, git
In-Reply-To: <494F47E1.8070105@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Miles Bader schrieb:
>> Just (setenv "PAGER" "cat") in .emacs.
>>
>> [I actually have it set to /bin/cat, not sure if that's meaningful or not.]
>
> No, really, you should set it to plain "cat": As a special case git
> recognizes this token and does not run any pager. If you set it to
> "/bin/cat" it does run a pager, namely /bin/cat.
But that would not hurt ;-).
On the other hand, using PAGER=cat or PAGER=/bin/cat is the right thing to
do in compilation and shell modes in Emacs, regardless of your use of git.
^ permalink raw reply
* Re: [PATCH v3] git-svn: Make following parents atomic
From: Thomas Jarosch @ 2008-12-22 8:41 UTC (permalink / raw)
To: Deskin Miller
Cc: Eric Wong, git, Junio C Hamano, Thomas Leonard,
Björn Steinbrink
In-Reply-To: <200812161422.58814.thomas.jarosch@intra2net.com>
On Tuesday, 16. December 2008 14:22:44 Thomas Jarosch wrote:
> This patch has a very nice side effect, it seems to fix a long standing
> problem with subversion imports. Here's the original report:
> https://kerneltrap.org/mailarchive/git/2008/4/8/1377514/thread
>
> Many of the 121 tags in my SVN tree were created by cvs2svn,
> which often created tags by copying older revisions
> of sub paths into the current tree.
>
> I've written a small script that checks out the same tag via git and SVN.
> It runs a diff against those two trees and saves the result to a file
> so I can manually check it. With git-svn from 1.6.0.5, the results are
> horrible: Over 30% of the tags didn't match the code in SVN.
>
> With git-svn from 1.6.1rc3, my first two manual probes look very good.
> Right now I'm reimporting the svn tree and will have the results
> of the complete "checkout comparison" tomorrow.
Yipeee, our SVN repository is fully migrated to git and split into handy 3-5GB
repositories. All the git tags match the code from the SVN tags,
so I guess this was a good stress test for git-svn 1.6.0.6 :-)
Cheers,
Thomas
^ permalink raw reply
* Re: git-svn and empty directories
From: Thomas Jarosch @ 2008-12-22 8:58 UTC (permalink / raw)
To: Eric Wong; +Cc: Deskin Miller, git
In-Reply-To: <20081221070854.GA22014@hand.yhbt.net>
Hello Eric,
On Sunday, 21. December 2008 08:08:54 Eric Wong wrote:
> Modern git-svn never touches the working tree during fetch, it hashes
> objects into the database and adds those to the indexes directly.
Ok
> However, I don't think your proposal is a good idea since it adds too
> much "magic". Complex special cases for delta application if the
> .gitignore gets real content and backwards-incompatibility since I know
> some git-svn users already rely on pushing .gitignore files (empty or
> otherwise) to an upstream SVN repo.
>
> The minor problem of missing empty directories isn't big enough to be
> worth the trouble IMHO.
Ok, this seems to be too much effort to fix. I manually added the directories
to my HEAD version and really hope I don't have to ever checkout
and build something from the past *fingers crossed* :-)
Cheers,
Thomas
^ permalink raw reply
* [patch v2] documentation: Explain how to free up space after filter-branch
From: Thomas Jarosch @ 2008-12-22 9:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Explain how to free up space after filter-branch.
Thanks to Björn Steinbrink for pointing me in the right direction.
The v2 version of this patch uses "git repack -a -d"
instead of "git repack -a -d --depth=250 --window=250"
as this nocked down a box with 4GB of ram using a repository
with medium sized binary files (50 - 100mb).
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-
branch.txt
index fed6de6..1432380 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -319,6 +319,18 @@ git filter-branch --index-filter \
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD
---------------------------------------------------------------
+Free up the space in .git if the rewritten version is correct
+by deleting refs/original and pruning the reflog:
+
+----------------------------------------------------
+git for-each-ref --format='%(refname)' refs/original
+ | xargs -i git update-ref -d {}
+
+git reflog expire --expire=0 --all
+git repack -a -d
+git prune
+----------------------------------------------------
+
Author
------
^ permalink raw reply related
* Re: Git with Hudson
From: Jean-Baptiste Quenot @ 2008-12-22 9:34 UTC (permalink / raw)
To: git
In-Reply-To: <20081218160734.b1992eb8.stephen@exigencecorp.com>
2008/12/18 Stephen Haberman <stephen@exigencecorp.com>:
>
> We tried using the Hudson git plugin that you can download from the
> Hudson site and ended up with problems--whether we had too many branches
> or something, the plugin has some funny "figure out what needs to be
> built" logic that issued near-constant git rev-list commands. To the
> point where our own "git fetch" calls would get starved for 20-30
> seconds.
>
> We eventually wrote our own Hudson git plugin that is simpler and
> doesn't do any funny rev-listing/walking. It just stores last hash
> built and rebuilds once that doesn't match the branch tip. Once that
> was in place, it worked great.
>
> I've got permission to publish it if you're interested--just haven't
> yet.
Good idea! I'm also affected by this problem, although the
git-rev-list is not an issue anymore since version 0.5. Simplifying
the checkout() is still in my plans though, so your contribution comes
at the right moment. Once the code will be made available we'll be
able to take the best of the two Git plugins and merge them into one.
WDYT?
--
Jean-Baptiste Quenot
http://jbq.caraldi.com/
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.1-rc4
From: Junio C Hamano @ 2008-12-22 9:54 UTC (permalink / raw)
To: git
This hopefully will be the last -rc before 1.6.1 becomes your Christmas
present.
Changes since v1.6.1-rc3 are minor and boring details.
Alexander Gavrilov (2):
git-gui: Fix handling of relative paths in blame.
git-gui: Fix commit encoding handling.
Arjen Laarhoven (1):
Enable threaded delta search on Mac OS X/Darwin
Boyd Stephen Smith Jr (1):
git-revert documentation: refer to new HOWTO on reverting faulty merges
Christian Stimming (3):
git-gui: Update German (completed) translation.
gitk: Mark forgotten strings (header sentence parts in color chooser) for translation
gitk: Update German translation
David Aguilar (1):
git-mergetool: properly handle "git mergetool -- filename"
Fredrik Skolmli (1):
git-gui: Starting translation for Norwegian
Giuseppe Bilotta (1):
gitk: Map / to focus the search box
Johannes Schindelin (3):
fast-import: close pack before unlinking it
git-gui: Get rid of the last remnants of GIT_CONFIG_LOCAL
fast-export: deal with tag objects that do not have a tagger
Johannes Sixt (3):
gitk: Use check-buttons' -text property instead of separate labels
gitk: Ensure that "Reset branch" menu entry is enabled
gitk: Force the focus to the main window on Windows
Junio C Hamano (12):
git-show: do not segfault when showing a bad tag
pager: do not dup2 stderr if it is already redirected
gitweb: do not run "git diff" that is Porcelain
GIT 1.5.4.7
gitweb: do not run "git diff" that is Porcelain
make_absolute_path(): check bounds when seeing an overlong symlink
builtin-blame.c: use strbuf_readlink()
combine-diff.c: use strbuf_readlink()
fast-import: make tagger information optional
Make sure lockfiles are unlocked when dying on SIGPIPE
send-email: futureproof split_addrs() sub
GIT 1.6.1-rc4
Kevin Ballard (1):
gitk: Allow unbalanced quotes/braces in commit headers
Kirill A. Korinskiy (1):
Remove the requirement opaquelocktoken uri scheme
Lee Marlow (2):
bash completion: Sort config completion variables
bash completion: Sync config variables with their man pages
Linus Torvalds (5):
Add generic 'strbuf_readlink()' helper function
Make 'ce_compare_link()' use the new 'strbuf_readlink()'
Make 'index_path()' use 'strbuf_readlink()'
Make 'diff_populate_filespec()' use the new 'strbuf_readlink()'
Make 'prepare_temp_file()' ignore st_size for symlinks
Marcel M. Cary (1):
git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
Markus Heidelberg (7):
Documentation: fix description for enabling hooks
doc/git-reset: add reference to git-stash
Documentation: sync example output with git output
Documentation: fix typos, grammar, asciidoc syntax
Documentation: fix typos, grammar, asciidoc syntax
Documentation/git-show-branch: work around "single quote" typesetting glitch
doc/git-fsck: change the way for getting heads' SHA1s
Michael J Gruber (1):
test overlapping ignore patterns
Michele Ballabio (1):
git gui: update Italian translation
Miklos Vajna (4):
git-gui: Update Hungarian translation for 0.12
git-daemon documentation: use {tilde}
githooks documentation: add a note about the +x mode
SubmittingPatches: mention the usage of real name in Signed-off-by: lines
Nanako Shiraishi (3):
git-gui: Update Japanese translation for 0.12
Clarify documentation of "git checkout <tree-ish> paths" syntax
Add a documentat on how to revert a faulty merge
Paul Mackerras (1):
gitk: Fix bugs in blaming code
Peter Krefting (2):
git-gui: Updated Swedish translation (515t0f0u).
git-gui: Fixed typos in Swedish translation.
René Scharfe (3):
Fix type-mismatch compiler warning from diff_populate_filespec()
connect.c: stricter port validation, silence compiler warning
fast-import.c: stricter strtoul check, silence compiler warning
Richard Hartmann (2):
Make help entries alphabetical
Always show which directory is not a git repository
Robin Rosenberg (1):
git-revert: record the parent against which a revert was made
Shawn O. Pearce (2):
git-gui: Update po template to include 'Mirroring %s' message
git-gui 0.12
Wu Fengguang (1):
git-send-email: handle email address with quoted comma
^ permalink raw reply
* Perl 5 now uses Git for version control
From: demerphq @ 2008-12-22 11:32 UTC (permalink / raw)
To: git
In-Reply-To: <a92222c80812212356p766345aaj5f4dc31ebba616aa@mail.gmail.com>
HOLLAND, Michigan - The Perl Foundation has migrated Perl 5 to the Git
version control system, making it easier than ever for Perl's development
team to continue to improve the language that powers many websites.
Moving from Perforce to git provides a number of benefits to the Perl
community:
- With a public repository and Git's extensive support for distributed
and offline work, working on Perl 5's source becomes easier for everyone
involved.
- Because Git is open source, all developers now have equal access to
the tools required to work on Perl's codebase.
- Core committers have less administrative work to do when integrating
contributed changes.
- Developers outside the core team can more easily work on experimental
changes to Perl before proposing them for inclusion in the next release.
- A vast array of improved repository and change analysis tools are now
available to Perl's developers.
- The new Git repository includes every version of Perl 5 ever released,
as well as every revision made during development.
Interested developers can get a copy of the Perl 5 Git repository at
at http://perl5.git.perl.org/perl.git
In true open source style, Sam Vilain converted Perl's history from
Perforce to Git. He did the work both in his spare time and in time
donated by his employer, Catalyst IT. He spent more than a year building
custom tools to transform 21 years of Perl history into the first
ever unified repository of every single change to Perl. In addition
to changes from Perforce, Sam patched together a comprehensive view
of Perl's history incorporating publicly available snapshot releases,
changes from historical mailing list archives and patch sets recovered
from the hard drives of previous Perl release engineers.
Perl 5 is used by businesses around the world including the BBC,
Amazon.com, LiveJournal, Ticketmaster, Craigslist and IMDb. Larry Wall
created Perl in 1987 while working as a systems administrator for NASA.
Larry released Perl 1.000 on December 18th 1987. Over the past 21 years,
Perl has grown into a high-level, general-purpose, dynamic programming
language and is widely used for Web development, Systems Administration,
Genomics and in many other disciplines. The most recent major version
of Perl 5 (5.10.0) was released one year ago.
Git is an open source version control system designed to handle very
large projects with speed and efficiency. Created by Linus Torvalds,
the inventor of Linux to handle the vast number of contributions to
the Linux Kernel, Git is highly flexible and extensible. Perl's motto,
"There's More Than One Way To Do It!" perfectly matches the Git workflow.
Nicholas Clark, the manager for Perl 5.8.9 which was released this week,
said "I'm looking forward to Git giving me the ability to work either
online or offline. Perforce is great when I have a network connection,
but until now those times when I've been trying to develop on trains
or planes, at stations or airports, I'm back in the 'dark ages' before
version control. Git solves this problem and more".
The hardware behind this and the systems administration time to maintain
it is donated by Booking.com. Booking.com has also recently donated
$50,000 to The Perl Foundation, to aid in the further development and
maintenance of the Perl programming language in general, and Perl 5.10
in particular.
Perl originally used the Revision Control System (RCS) until March
1997 when it switched to the Perforce Software Configuration Management
System. The Perforce repository was graciously hosted and maintained,
free of charge, by ActiveState. Perforce provided the core developers
with powerful tools, but these tools were not available to users outside
the core team. The switch to Git removes this barrier.
About The Perl Foundation (http://www.perlfoundation.org/) | The Perl
Foundation is dedicated to the advancement of the Perl programming
language through open discussion, collaboration, design, and code. The
Perl Foundation coordinates the efforts of numerous grass-roots Perl-based
groups, including: International Yet Another Perl Conferences (YAPC's),
Carries the legal responsibility for Perl 5 and Perl 6 and the Artistic
and Artistic 2.0 licenses, perl.org, Perl Mongers, and PerlMonks.
About Booking.com (http://www.booking.com/) | Booking.com is part of
Priceline.com (Nasdaq: PCLN). Its website attracts an average of 30
million unique visitors each month. Booking.com works with more than
57,000 affiliated hotels in 15,000 destinations around the world. Its
services are available in 21 languages. Booking.com currently has 24
offices in Amsterdam, Athens, Barcelona, Berlin, Cambridge, Cape Town,
Dubai, Dublin, London, Loulé (Portugal), Lyon, Madrid, Moscow, Munich,
New York, Orlando, Paris, Rome, San Francisco, Sydney, Singapore,
Stockholm, Vienna and Warsaw.
About Catalyst IT (NZ) Ltd (http://www.catalyst.net.nz/) | Catalyst IT
is New Zealand's premiere Open Source development house. Catalyst looks
after the development requirements for the NZ Electoral Enrolment Centre,
manage the .NZ registry, the largest NZ newspaper's online presence,
the NZ TAB and many other exciting projects, and are organising the 2010
Australasian Linux Conference to be held in Wellington, New Zealand.
http://use.perl.org/articles/08/12/22/0830205.shtml
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [RFC] Automagic patch merge ack emails
From: Richard Hartmann @ 2008-12-22 14:07 UTC (permalink / raw)
To: git
Hi all,
I poked around the docs, but I could not find any option to have git
send email to people who signed off a patch when it's merged.
I only realized the two patches I sent were merged because they were
listed in the RC changelog summary and would have followed up my patch
email in a about a week, asking about its status.
Does anyone else think this is useful? Does anyone else think it should
make it into main so it can be enabled via config, not via a hook that
needs to be imported into each and every repo?
Richard
^ permalink raw reply
* Move-delete merge conflict is not displayed using git ls-files --unmerged
From: Constantine Plotnikov @ 2008-12-22 14:29 UTC (permalink / raw)
To: git
Lets consider repository state created with the following script (git
version 1.6.0.4).
mkdir test-move-delete
cd test-move-delete
git init
echo test1 >file.txt
echo test2 >>file.txt
echo test3 >>file.txt
echo test4 >>file.txt
git add file.txt
git commit -m "start"
git checkout -b moved master
git mv file.txt copy.txt
git commit -m "moved"
git checkout -b deleted master
git rm file.txt
git commit -m "deleted"
git merge moved
The last merge command fails with move-delete conflict.
CONFLICT (rename/delete): Renamed file.txt->copy.txt in moved and
deleted in HEAD
Automatic merge failed; fix conflicts and then commit the result.
However git ls-files --unmerged does not list any conflict in that
case and it is possible to execute git commit command right away
without doing anything with the repository.
I think that if git merge reports the conflicts, such conflicts should
be discoverable using git ls-files and prevent commit with resolving
the conflict like it is done with modify-delete conflicts.
Regards,
Constantine
^ permalink raw reply
* git 1.6.1-rc4 testing dependency
From: Peter van der Does @ 2008-12-22 16:05 UTC (permalink / raw)
To: git
With git 1.6.1 it it seems you need to install the locale en_US.UTF-8
otherwise it won't pass the testing during building the package.
The locale comes in play with test:
t9129-git-svn-i18n-commitencoding.sh
compare_svn_head_with () {
LC_ALL=en_US.UTF-8 svn log --limit 1 `git svn info --url` | \
sed -e 1,3d -e "/^-\{1,\}\$/d" >current &&
test_cmp current "$1"
}
On my building machine I don't have any locales installed, making the
LC_ALL=C.
Not everybody will have this locale installed nor would they want it
installed on their machines.
Is the locale is a dependency for git svn?
Or can this test be changed? Either by not having the locale dependency
or by skipping the test completely?
I apologize if this message shows up twice.
--
Peter van der Does
GPG key: E77E8E98
^ permalink raw reply
* git 1.6.1-rc4 testing dependency
From: Peter van der Does @ 2008-12-22 15:06 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
With git 1.6.1 it it seems you need to install the locale en_US.UTF-8
otherwise it won't pass the testing during building the package.
The locale comes in play with test:
t9129-git-svn-i18n-commitencoding.sh
compare_svn_head_with () {
LC_ALL=en_US.UTF-8 svn log --limit 1 `git svn info --url` | \
sed -e 1,3d -e "/^-\{1,\}\$/d" >current &&
test_cmp current "$1"
}
On my building machine I don't have any locales installed, making the
LC_ALL=C.
Not everybody will have this locale installed nor would they want it
installed on their machines.
Is the locale is a dependency for git svn?
Or can this test be changed? Either by not having the locale dependency
or by skipping the test completely?
--
Peter van der Does
GPG key: E77E8E98
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* push to backup repo periodically fails with "not fast forward"
From: davetron5000 @ 2008-12-22 16:24 UTC (permalink / raw)
To: git
I have a repo on another disk that I ONLY use to backup my in-use
local repo. I have a post-commit hook that does the push (git push --
all remote-repo-name)
>git commit -a -m 'some change'
Counting objects: 71, done.
Compressing objects: 100% (26/26), done.
Writing objects: 100% (29/29), 2.31 KiB, done.
Total 29 (delta 12), reused 0 (delta 0)
Unpacking objects: 100% (29/29), done.
To file:///Volumes/Git/pose/main
22d7f10..0037aaf bimonthly-frequency -> bimonthly-frequency
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'file:///Volumes/Git/pose/main'
Created commit 0037aaf: Removed assertion that made no sense.
1 files changed, 0 insertions(+), 2 deletions(-)
I'm using git as a front-end to Subversion, but I can't figure out why
this is happening.
The repo at /Volumes/Git/pose/main is NEVER pulled from or pushed to
by anything other than my hook. I can't understand why any push to it
would NOT be a fast-forward.
Any ideas how I can figure out what's going on?
^ permalink raw reply
* Re: push to backup repo periodically fails with "not fast forward"
From: Felipe Contreras @ 2008-12-22 17:11 UTC (permalink / raw)
To: davetron5000; +Cc: git
In-Reply-To: <19016122-e19d-4885-8b0f-dec7b686c6ea@o4g2000pra.googlegroups.com>
On Mon, Dec 22, 2008 at 6:24 PM, davetron5000 <davetron5000@gmail.com> wrote:
> I have a repo on another disk that I ONLY use to backup my in-use
> local repo. I have a post-commit hook that does the push (git push --
> all remote-repo-name)
>
>>git commit -a -m 'some change'
> Counting objects: 71, done.
> Compressing objects: 100% (26/26), done.
> Writing objects: 100% (29/29), 2.31 KiB, done.
> Total 29 (delta 12), reused 0 (delta 0)
> Unpacking objects: 100% (29/29), done.
> To file:///Volumes/Git/pose/main
> 22d7f10..0037aaf bimonthly-frequency -> bimonthly-frequency
> ! [rejected] master -> master (non-fast forward)
> error: failed to push some refs to 'file:///Volumes/Git/pose/main'
> Created commit 0037aaf: Removed assertion that made no sense.
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> I'm using git as a front-end to Subversion, but I can't figure out why
> this is happening.
>
> The repo at /Volumes/Git/pose/main is NEVER pulled from or pushed to
> by anything other than my hook. I can't understand why any push to it
> would NOT be a fast-forward.
>
> Any ideas how I can figure out what's going on?
Do you rebase your original repo?
--
Felipe Contreras
^ permalink raw reply
* Re: push to backup repo periodically fails with "not fast forward"
From: David Copeland @ 2008-12-22 17:15 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530812220911l37b825edj55178658f24755c1@mail.gmail.com>
the original gets rebased from a git svn rebase on occasion; so I
guess that is causing things to not be fast-forward.
I guess all I really want to do is keep a duplicate copy of my repo
somewhere else. Should I just use --force in my hook, or abandon git
as the mechanism and use rsync?
Dave
On Mon, Dec 22, 2008 at 12:11 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Dec 22, 2008 at 6:24 PM, davetron5000 <davetron5000@gmail.com> wrote:
>> I have a repo on another disk that I ONLY use to backup my in-use
>> local repo. I have a post-commit hook that does the push (git push --
>> all remote-repo-name)
>>
>>>git commit -a -m 'some change'
>> Counting objects: 71, done.
>> Compressing objects: 100% (26/26), done.
>> Writing objects: 100% (29/29), 2.31 KiB, done.
>> Total 29 (delta 12), reused 0 (delta 0)
>> Unpacking objects: 100% (29/29), done.
>> To file:///Volumes/Git/pose/main
>> 22d7f10..0037aaf bimonthly-frequency -> bimonthly-frequency
>> ! [rejected] master -> master (non-fast forward)
>> error: failed to push some refs to 'file:///Volumes/Git/pose/main'
>> Created commit 0037aaf: Removed assertion that made no sense.
>> 1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> I'm using git as a front-end to Subversion, but I can't figure out why
>> this is happening.
>>
>> The repo at /Volumes/Git/pose/main is NEVER pulled from or pushed to
>> by anything other than my hook. I can't understand why any push to it
>> would NOT be a fast-forward.
>>
>> Any ideas how I can figure out what's going on?
>
> Do you rebase your original repo?
>
> --
> Felipe Contreras
>
^ permalink raw reply
* Re: push to backup repo periodically fails with "not fast forward"
From: Felipe Contreras @ 2008-12-22 17:19 UTC (permalink / raw)
To: David Copeland; +Cc: git
In-Reply-To: <f95d47890812220915h5286d2bdv7c8412ecf77be999@mail.gmail.com>
On Mon, Dec 22, 2008 at 7:15 PM, David Copeland <davetron5000@gmail.com> wrote:
> the original gets rebased from a git svn rebase on occasion; so I
> guess that is causing things to not be fast-forward.
>
> I guess all I really want to do is keep a duplicate copy of my repo
> somewhere else. Should I just use --force in my hook, or abandon git
> as the mechanism and use rsync?
I would manually do 'git push backup' at certain points since not all
my commits are meant to be backed up, specially on temporal feature
branches.
But --force should do the trick.
--
Felipe Contreras
^ permalink raw reply
* Re: push to backup repo periodically fails with "not fast forward"
From: Nicolas Pitre @ 2008-12-22 18:27 UTC (permalink / raw)
To: David Copeland; +Cc: Felipe Contreras, git
In-Reply-To: <f95d47890812220915h5286d2bdv7c8412ecf77be999@mail.gmail.com>
On Mon, 22 Dec 2008, David Copeland wrote:
> the original gets rebased from a git svn rebase on occasion; so I
> guess that is causing things to not be fast-forward.
>
> I guess all I really want to do is keep a duplicate copy of my repo
> somewhere else. Should I just use --force in my hook, or abandon git
> as the mechanism and use rsync?
Using --force is definitively better than rsync.
Nicolas
^ permalink raw reply
* Re: [RFC] Automagic patch merge ack emails
From: Junio C Hamano @ 2008-12-22 20:29 UTC (permalink / raw)
To: Richard Hartmann; +Cc: git
In-Reply-To: <2d460de70812220607j7f218ee3r7722bc8147a3dab4@mail.gmail.com>
"Richard Hartmann" <richih.mailinglist@gmail.com> writes:
> I poked around the docs, but I could not find any option to have git
> send email to people who signed off a patch when it's merged.
The correcty way to say that "the changes from a patch get incorporated"
is "it's applied", not "merged". There is no "post-am" hook you can use
to make an announcement. Nor the sample post-commit hook that is called
after every commit mentions anything about e-mails.
And these are good things, and here is why.
It does not matter a whit to you if/when I applied your patch to a topic
branch in my private repository that I work in, preparing for eventual
pushout to the public tree. Patches are reviewed in e-mail form, and
obvious typos and logic mistakes are corrected while still I am reading
your patch in my MUA, if they are trivial (otherwise you will get a reply
saying to which points I do not agree with your patch). After your patch
passes this process, it may be applied somewhere, perhaps directly on
'master' or 'maint', or perhaps on a new topic branch to house your
changes.
But that is only the beginning of the story. I'll apply many more changes
from other people, testing each step, rebasing and amending these changes
as necessary to fix breakages, and I may realize that some patches are not
quite ready to be in the public history during this process. Your patches
may be part of these patches discarded that way.
When I decide not to apply your patch (iow, it hits my mailbox but I
reject it while it is in my MUA), git obviously would not know about it at
all [*1*].
Even after I apply your patch somewhere, I may decide not to include it in
in any of the public branches after testing and re-reviewing. I may merge
the topic branch I created to host your patch to 'next', but after testing
and re-reviewing, I may decide it is not ready, and I'd rebuild 'next'
without the topic before pushing the results out. And I'd delete such a
topic branch after I am done with it.
What this means is that the time a commit is made (either by patch
application or "git pull" from somebody else's tree) is too early to make
any announcement. "git am" hook would not be useful for that purpose.
The only time that it may make a difference to you is when things are
pushed out to the public repository, and there is a mechanism for
automating tasks after new commits hits the public repository: the
post-receive hook. contrib/hooks/post-receive-email may be a good example
to study if you are interested (I use it in my day job repository, but I
do not use the hook in git.git because the style of announcing I adopted
on this list is to send out "What's in/cooking" messages once or twice a
week).
> Does anyone else think this is useful? Does anyone else think it should
> make it into main so it can be enabled via config, not via a hook that
> needs to be imported into each and every repo?
If your "each and every" repository is used for the same uniform purpose
(namely, publishing to the public), then they can be initialized with the
same hook scripts using the templates mechanism, so in a sense, there
already is a mechanism for that.
But it is very unlikely your repositories are uniform, so I doubt that the
mechanism based on custom templates, or your built-in announcement
mechanism triggered by configuration, would be very useful.
Most of the freedom in a DVCS workflow comes from the separation between
making commits (including patch application and merges) and publishing the
result. You do not want to fear committing crap, because you can
carefully check the result before making it public.
Because of that, private repositories where the real work takes place and
public repositories that serve as distribution points have very different
needs. You do not want to have any announcement triggers in the former
(that's the whole point of separating "making commits" and "publishing the
result"), while some people like announcement triggers in the latter.
[Footnote]
*1* There are two kinds of patches that rejected that way.
* One with good intention but wrong execution receives suggestion for
improvements.
* One with misguided intention or misleading description is requested to
clarify why the change is needed, before receiving comments on the
implementation.
^ permalink raw reply
* Bugs in sub argsfromdir of git-cvsserver
From: Le @ 2008-12-22 20:33 UTC (permalink / raw)
To: Git Mailing List
Hi, all,
I found a bug in git-cvsserver.
sub argsfromdir
{
if ( scalar(@{$state->{args}}) == 1 )
{
my $arg = $state->{args}[0];
#$arg .= $state->{prependdir} if ( defined (
$state->{prependdir} ) );
$arg = $state->{prependdir} . $arg if ( defined (
$state->{prependdir} ) );
$log->info("Only one arg specified, checking for directory
expansion on '$arg'");
...
}
...
}
It makes not sense of the above remarked out code.
But when I use the code followed remarked out, I have problem to use cvs
diff or cvs log in a sub directory of the root (may other commands as
well). Eg.:
I have a project called test1 and in test1 there is a test2 subdirectory
and a file test2/test3.txt.
I have no problem to cvs diff and cvs log in test1 directory. But if I
enter test1/test2 to check these commands then they are not working.
I tried to fixed the problem to remarked out the code:
#$filename = filecleanup($filename);
in req_log and req_diff, then both cvs diff and cvs log work.
In
sub filecleanup
{
...
$filename = $state->{prependdir} . $filename;
return $filename;
}
inserts $state->{prependdir} into the $filename.
But I don't know if what I did brings incompatibilities.
Can anybody check this issue?
Thanks!
Le Wen
^ permalink raw reply
* Re: Move-delete merge conflict is not displayed using git ls-files --unmerged
From: Junio C Hamano @ 2008-12-22 20:48 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git, Johannes Schindelin, Alex Riesen
In-Reply-To: <85647ef50812220629o46134a70waf159bb6cd6d6e72@mail.gmail.com>
"Constantine Plotnikov" <constantine.plotnikov@gmail.com> writes:
> I think that if git merge reports the conflicts, such conflicts should
> be discoverable using git ls-files and prevent commit with resolving
> the conflict like it is done with modify-delete conflicts.
Yeah, I think so, too.
^ permalink raw reply
* Re: git 1.6.1-rc4 testing dependency
From: Junio C Hamano @ 2008-12-22 20:50 UTC (permalink / raw)
To: Peter van der Does; +Cc: git
In-Reply-To: <20081222100637.716c5b8a@montecarlo.grandprix.int>
Peter van der Does <peter@ourvirtualhome.com> writes:
> On my building machine I don't have any locales installed, making the
> LC_ALL=C.
> Not everybody will have this locale installed nor would they want it
> installed on their machines.
I think some tests play nicer than this one and skip tests that want UTF-8
locales; you may want to teach this script the same trick.
In the meantime, perhaps "GIT_SKIP_TETS='t9129' make test" would help.
^ permalink raw reply
* 'Theirs' merge between branches on a binary file.
From: Tim Visher @ 2008-12-22 20:56 UTC (permalink / raw)
To: git
Hello Everyone,
I have a binary file that is coming up with a merge conflict
(obviously) between two branches and I want to simply say, 'take their
version of the file'. Is this possible? In subversion it's a pretty
trivial merge operation, so I assume there's something similar in git.
Thanks in advance!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [RFC] Automagic patch merge ack emails
From: Boyd Stephen Smith Jr. @ 2008-12-22 20:59 UTC (permalink / raw)
To: git; +Cc: Richard Hartmann
In-Reply-To: <2d460de70812220607j7f218ee3r7722bc8147a3dab4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]
On Monday 2008 December 22 08:07:07 Richard Hartmann wrote:
> I poked around the docs, but I could not find any option to have git
> send email to people who signed off a patch when it's merged.
There's not one, since something that that should probably be done in a hook.
Maybe the update hook?
> I only realized the two patches I sent were merged because they were
> listed in the RC changelog summary and would have followed up my patch
> email in a about a week, asking about its status.
>
> Does anyone else think this is useful?
I think it would be nice to get a notification whenever Junio pushes commits
to 'master' or 'maint' in git.git if I've signed off on one of the commits.
I don't think everyone would though so the hook would need to be maintained
indefinitely (updating the email blacklist, etc.).
It would probably be a nice hook to have as an example, I guess.
> Does anyone else think it should
> make it into main so it can be enabled via config, not via a hook that
> needs to be imported into each and every repo?
Definitely not. It's not that difficult to add a hook to the repositories
that need it, and I think the majority of repositories will be private and
not need it.
--
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
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