* Re: fatal: cannot store pack file (git 1.6.0.2 + sshfs)
From: Jhair Tocancipa Triana @ 2008-09-24 20:05 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: Shawn O. Pearce, Jhair Tocancipa Triana, git
In-Reply-To: <d77df1110809241057rb1d7361pf76a4cde8834b1df@mail.gmail.com>
"Nathan W. Panike" <nathan.panike@gmail.com> writes:
> Resend with reply to all:
>
> When I mount with sshfs, I have to give the option
>
> sshfs -o workaround=rename ...
>
> to make things work normally.
I also mount with the same option (-o workaround=rename) to fix other
issues I had before, see
http://git.or.cz/gitwiki/GitFaq#head-c04838bdb94dae45b743fe6ebefde24e4df04c62
Will try with latest gist "master" as advised by Shawn.
Thanks,
--
Jhair
^ permalink raw reply
* Re: [RFC/PATCH] remove vim syntax highlighting in favor of upstream
From: Jeff King @ 2008-09-24 19:59 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: vim, Shawn O. Pearce, git
In-Reply-To: <20080924195658.GB6816@neumann>
On Wed, Sep 24, 2008 at 09:56:58PM +0200, SZEDER Gábor wrote:
> vim 7.2 provides support not only for commit messages but also for
> other git-related filetypes. I think it would be good to mention
> them, too, therefore I extended your patch with them.
I think that is a sensible change.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] remove vim syntax highlighting in favor of upstream
From: SZEDER Gábor @ 2008-09-24 19:56 UTC (permalink / raw)
To: Jeff King; +Cc: vim, Shawn O. Pearce, git
In-Reply-To: <20080924175315.GA10337@coredump.intra.peff.net>
Hi,
On Wed, Sep 24, 2008 at 01:53:15PM -0400, Jeff King wrote:
> +Syntax highlighting for git commit messages is included with the vim
> +distribution as of vim 7.2, and should work automatically.
> +
> +If you have an older version of vim, you can get the latest syntax file
> +from the vim project:
> +
> + http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitcommit.vim
vim 7.2 provides support not only for commit messages but also for
other git-related filetypes. I think it would be good to mention
them, too, therefore I extended your patch with them.
-- >8 --
remove vim syntax highlighting in favor of upstream
As of version 7.2, vim ships with its own syntax
highlighting for git commit messages, which is:
1. more comprehensive in splitting up the various
components of the file
2. in accordance with the usual vim behavior for syntax
highlighting (e.g., respecting b:current_syntax)
3. presumably better maintained (I have not been using
what's in git's contrib/ directory for some time in
favor of the upstream version)
Furthermore, vim 7.2 also provides syntax highlighting for
other git filetypes (gitconfig, rebase, send-email).
This patch gets rid of our local version and just points
interested parties to the upstream version.
The code for auto-detecting filetypes is taken from vim 7.2's
runtime/filetype.vim.
---
contrib/vim/README | 38 ++++++++++++++++++++++++++++++--------
contrib/vim/syntax/gitcommit.vim | 18 ------------------
2 files changed, 30 insertions(+), 26 deletions(-)
delete mode 100644 contrib/vim/syntax/gitcommit.vim
diff --git a/contrib/vim/README b/contrib/vim/README
index 9e7881f..a811675 100644
--- a/contrib/vim/README
+++ b/contrib/vim/README
@@ -1,8 +1,30 @@
-To syntax highlight git's commit messages, you need to:
- 1. Copy syntax/gitcommit.vim to vim's syntax directory:
- $ mkdir -p $HOME/.vim/syntax
- $ cp syntax/gitcommit.vim $HOME/.vim/syntax
- 2. Auto-detect the editing of git commit files:
- $ cat >>$HOME/.vimrc <<'EOF'
- autocmd BufNewFile,BufRead COMMIT_EDITMSG set filetype=gitcommit
- EOF
+Syntax highlighting for git commit messages, config files, etc. is
+included with the vim distribution as of vim 7.2, and should work
+automatically.
+
+If you have an older version of vim, you can get the latest syntax
+files from the vim project:
+
+ http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/git.vim
+ http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitcommit.vim
+ http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitconfig.vim
+ http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitrebase.vim
+ http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitsendemail.vim
+
+To install:
+
+ 1. Copy these files to vim's syntax directory $HOME/.vim/syntax
+ 2. Auto-detect the editing of various git-related filetypes:
+ $ cat >>$HOME/.vimrc <<'EOF'
+ autocmd BufNewFile,BufRead *.git/COMMIT_EDITMSG setf gitcommit
+ autocmd BufNewFile,BufRead *.git/config,.gitconfig setf gitconfig
+ autocmd BufNewFile,BufRead git-rebase-todo setf gitrebase
+ autocmd BufNewFile,BufRead .msg.[0-9]*
+ \ if getline(1) =~ '^From.*# This line is ignored.$' |
+ \ setf gitsendemail |
+ \ endif
+ autocmd BufNewFile,BufRead *.git/**
+ \ if getline(1) =~ '^\x\{40\}\>\|^ref: ' |
+ \ setf git |
+ \ endif
+ EOF
diff --git a/contrib/vim/syntax/gitcommit.vim b/contrib/vim/syntax/gitcommit.vim
deleted file mode 100644
index 332121b..0000000
--- a/contrib/vim/syntax/gitcommit.vim
+++ /dev/null
@@ -1,18 +0,0 @@
-syn region gitLine start=/^#/ end=/$/
-syn region gitCommit start=/^# Changes to be committed:$/ end=/^#$/ contains=gitHead,gitCommitFile
-syn region gitHead contained start=/^# (.*)/ end=/^#$/
-syn region gitChanged start=/^# Changed but not updated:/ end=/^#$/ contains=gitHead,gitChangedFile
-syn region gitUntracked start=/^# Untracked files:/ end=/^#$/ contains=gitHead,gitUntrackedFile
-
-syn match gitCommitFile contained /^#\t.*/hs=s+2
-syn match gitChangedFile contained /^#\t.*/hs=s+2
-syn match gitUntrackedFile contained /^#\t.*/hs=s+2
-
-hi def link gitLine Comment
-hi def link gitCommit Comment
-hi def link gitChanged Comment
-hi def link gitHead Comment
-hi def link gitUntracked Comment
-hi def link gitCommitFile Type
-hi def link gitChangedFile Constant
-hi def link gitUntrackedFile Constant
^ permalink raw reply related
* Re: [PATCH (GIT-GUI)] git-gui: Reenable staging unmerged files by clicking the icon.
From: Shawn O. Pearce @ 2008-09-24 19:53 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Johannes Sixt
In-Reply-To: <20080924182508.GC3669@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Alexander Gavrilov <angavrilov@gmail.com> wrote:
> > This restores functionality of the file icon for unmerged files.
> > Safety is enforced by loading the diff and checking for lines
> > that look like conflict markers. If such lines are found, or
> > the conflict involves deletion and/or symlinks, a confirmation
> > dialog is presented. Otherwise, the icon immediately stages the
> > working copy version of the file.
> >
> > Includes a revert of 2fe5b2ee42897a3acc78e5ddaace3775eb2713ca
> > (Restore ability to Stage Working Copy for conflicts)
>
> Can I get a resend of this patch?
Never mind. Its applied now. I broke down after lunch and found
the one hunk that was an issue, and trivially hand merged it.
--
Shawn.
^ permalink raw reply
* Re: [GIT-GUI PATCH] call prepare-commit-msg hook
From: Shawn O. Pearce @ 2008-09-24 19:46 UTC (permalink / raw)
To: Joshua Williams; +Cc: git, Jay Blakeborough, Bill Lohse
In-Reply-To: <48DA90F9.8070606@qlogic.com>
Joshua Williams <joshua.williams@qlogic.com> wrote:
>>
>> Can you please try to put this onto my current git-gui tree?
>> I don't have the base 10d8a44 object so I can't 3-way merge
>> this in, and the patch doesn't apply cleanly anymore.
>
> Absolutely. Here it is:
I'm not sure what happened, but any line of context got an extra
space inserted at the front of it. I had to go rip out the extra
spaces from every line of context to get git-apply to process the
patch.
Anyway, its applied now. Thanks.
--
Shawn.
^ permalink raw reply
* Re: [GIT-GUI PATCH] call prepare-commit-msg hook
From: Joshua Williams @ 2008-09-24 19:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Jay Blakeborough, Bill Lohse
In-Reply-To: <20080924170434.GW3669@spearce.org>
Shawn O. Pearce wrote:
> Joshua Williams <joshua.williams@qlogic.com> wrote:
>> Small change. Still need to load MERGE_MSG and SQUASH_MSG
>> if there's no prepare-commit-msg hook. We now process the hook
>> first and if it's not there, load MERGE_MSG or SQUASH_MSG.
>>
>> Signed-off-by: Joshua Williams <joshua.williams@qlogic.com>
>
> This patch looks reasonable. My only comment is maybe we want
> to delete PREPARE_COMMIT_MSG file when we "exit 1" when the hook
> has declined.
Good catch. I've added that to the latest patch.
>> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
>> index 10d8a44..8d06cd1 100755
>> --- a/git-gui/git-gui.sh
>> +++ b/git-gui/git-gui.sh
>
> Can you please try to put this onto my current git-gui tree?
> I don't have the base 10d8a44 object so I can't 3-way merge
> this in, and the patch doesn't apply cleanly anymore.
Absolutely. Here it is:
Add support to git-gui for calling out to the prepare-commit-msg hook.
Signed-off-by: Joshua Williams <joshua.williams@qlogic.com>
---
diff --git a/git-gui.sh b/git-gui.sh
index 1939001..cb0fcac 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1170,6 +1170,7 @@ proc rescan {after {honor_trustmtime 1}} {
|| [string trim [$ui_comm get 0.0 end]] eq {})} {
if {[string match amend* $commit_type]} {
} elseif {[load_message GITGUI_MSG]} {
+ } elseif {[run_prepare_commit_msg_hook]} {
} elseif {[load_message MERGE_MSG]} {
} elseif {[load_message SQUASH_MSG]} {
}
@@ -1269,6 +1270,70 @@ proc load_message {file} {
return 0
}
+proc run_prepare_commit_msg_hook {} {
+ global pch_error
+
+ # prepare-commit-msg requires PREPARE_COMMIT_MSG exist. From git-gui
+ # it will be .git/MERGE_MSG (merge), .git/SQUASH_MSG (squash), or an
+ # empty file but existant file.
+
+ set fd_pcm [open [gitdir PREPARE_COMMIT_MSG] a]
+
+ if {[file isfile [gitdir MERGE_MSG]]} {
+ set pcm_source "merge"
+ set fd_mm [open [gitdir MERGE_MSG] r]
+ puts -nonewline $fd_pcm [read $fd_mm]
+ close $fd_mm
+ } elseif {[file isfile [gitdir SQUASH_MSG]]} {
+ set pcm_source "squash"
+ set fd_sm [open [gitdir SQUASH_MSG] r]
+ puts -nonewline $fd_pcm [read $fd_sm]
+ close $fd_sm
+ } else {
+ set pcm_source ""
+ }
+
+ close $fd_pcm
+
+ set fd_ph [githook_read prepare-commit-msg \
+ [gitdir PREPARE_COMMIT_MSG] $pcm_source]
+ if {$fd_ph eq {}} {
+ catch {file delete [gitdir PREPARE_COMMIT_MSG]}
+ return 0;
+ }
+
+ ui_status [mc "Calling prepare-commit-msg hook..."]
+ set pch_error {}
+
+ fconfigure $fd_ph -blocking 0 -translation binary -eofchar {}
+ fileevent $fd_ph readable \
+ [list prepare_commit_msg_hook_wait $fd_ph]
+
+ return 1;
+}
+
+proc prepare_commit_msg_hook_wait {fd_ph} {
+ global pch_error
+
+ append pch_error [read $fd_ph]
+ fconfigure $fd_ph -blocking 1
+ if {[eof $fd_ph]} {
+ if {[catch {close $fd_ph}]} {
+ ui_status [mc "Commit declined by prepare-commit-msg hook."]
+ hook_failed_popup prepare-commit-msg $pch_error
+ catch {file delete [gitdir PREPARE_COMMIT_MSG]}
+ exit 1
+ } else {
+ load_message PREPARE_COMMIT_MSG
+ }
+ set pch_error {}
+ catch {file delete [gitdir PREPARE_COMMIT_MSG]}
+ return
+ }
+ fconfigure $fd_ph -blocking 0
+ catch {file delete [gitdir PREPARE_COMMIT_MSG]}
+}
+
proc read_diff_index {fd after} {
global buf_rdi
^ permalink raw reply related
* [PATCH/RFC 2/2 v2] git-gui: Do not automatically stage file after merge tool finishes
From: Johannes Sixt @ 2008-09-24 19:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Alexander Gavrilov
In-Reply-To: <20080924175033.GZ3669@spearce.org>
If a merge tool was invoked on a conflicted file and the tool completed,
then the conflicted file was staged automatically. However, the fact that
the user closed the merge tool cannot be understood as the unequivocal
sign that the conflict was completely resolved. For example, the user
could have decided to postpone the resolution of the conflict, or could
have accidentally closed the tool. We better leave the file unstaged and
let the user stage it explicitly.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
On Mittwoch, 24. September 2008, Shawn O. Pearce wrote:
> Alexander Gavrilov <angavrilov@gmail.com> wrote:
> > You also cannot simply remove merge_add_resolution, because then it
> > would leave the diff view stale.
>
> Is it just a matter of calling reshow_diff instead?
Indeed. I'd tried do_rescan, but reshow_diff does it, too, and it doesn't
mess with the file lists!
This version of the patch also removes the check whether the merge tool
had modified the file, because now we don't do anything with the file
anyway.
-- Hannes
lib/mergetool.tcl | 10 +---------
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/lib/mergetool.tcl b/lib/mergetool.tcl
index 965cfe4..f292f30 100644
--- a/lib/mergetool.tcl
+++ b/lib/mergetool.tcl
@@ -348,14 +348,6 @@ proc merge_tool_finish {fd} {
}
}
- # Check the modification time of the target file
- if {!$failed && [file mtime $mtool_target] eq $mtool_mtime} {
- if {[ask_popup [mc "File %s unchanged, still accept as resolved?" \
- [short_path $mtool_target]]] ne {yes}} {
- set failed 1
- }
- }
-
# Finish
if {$failed} {
file rename -force -- $backup $mtool_target
@@ -368,6 +360,6 @@ proc merge_tool_finish {fd} {
delete_temp_files $mtool_tmpfiles
- merge_add_resolution $mtool_target
+ reshow_diff
}
}
--
1.6.0.2.295.g3898d
^ permalink raw reply related
* [JGIT PATCH] Use ".have" advertisements during push to reduce what is transferred
From: Shawn O. Pearce @ 2008-09-24 19:05 UTC (permalink / raw)
To: Robin Rosenberg, Marek Zawirski; +Cc: git
If a remote peer has an alternate object database it might show
the refs of the alternate repositories by sending special ".have"
ref lines in the advertisement. These can be used to compute a
better common base, avoiding uploading objects which the remote
side has physically available (and complete), but which aren't in
the ref space of the remote repository.
As most repositories have more than one ref, there can be more than
one ".have" line, and the same object might appear more than once.
Collecting these into a special "additionalHaves" set avoids them
from showing up in the advertised refs collection.
PackWriter already gracefully skips over remoteObjects that
we don't have locally. We can simply include the entire set
of additionalHaves when we start creating a pack for the push
transfer and PackWriter will seek the best common base available.
Anything advertised that we lack will be silently skipped.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
I'm likely to merge Junio's jc/alternate-push branch in git.git
from next to master when I start merging over the cooked topics.
JGit clients need this to prevent crashing when they talk to a
newer git-receive-pack process that is sending these .have lines.
Without this patch JGit will throw a "duplicate advertisement"
error when it receives more than one ref with the name ".have".
Fortunately the entire implementation of the client side of this
alternate-push feature is 7 lines of Java.
See http://thread.gmane.org/gmane.comp.version-control.git/95351
.../spearce/jgit/transport/BasePackConnection.java | 7 ++++++-
.../jgit/transport/BasePackPushConnection.java | 1 +
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackConnection.java
index 2d145a6..e5fc040 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackConnection.java
@@ -93,6 +93,9 @@
/** Capability tokens advertised by the remote side. */
private final Set<String> remoteCapablities = new HashSet<String>();
+ /** Extra objects the remote has, but which aren't offered as refs. */
+ protected final Set<ObjectId> additionalHaves = new HashSet<ObjectId>();
+
BasePackConnection(final PackTransport packTransport) {
local = packTransport.local;
uri = packTransport.uri;
@@ -160,7 +163,9 @@ private void readAdvertisedRefsImpl() throws IOException {
}
final ObjectId id = ObjectId.fromString(line.substring(0, 40));
- if (name.endsWith("^{}")) {
+ if (name.equals(".have")) {
+ additionalHaves.add(id);
+ } else if (name.endsWith("^{}")) {
name = name.substring(0, name.length() - 3);
final Ref prior = avail.get(name);
if (prior == null)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackPushConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackPushConnection.java
index 2594623..17f6915 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackPushConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackPushConnection.java
@@ -195,6 +195,7 @@ private void writePack(final Map<String, RemoteRefUpdate> refUpdates,
for (final Ref r : getRefs())
remoteObjects.add(r.getObjectId());
+ remoteObjects.addAll(additionalHaves);
for (final RemoteRefUpdate r : refUpdates.values()) {
if (!ObjectId.zeroId().equals(r.getNewObjectId()))
newObjects.add(r.getNewObjectId());
--
1.6.0.2.471.g47a76
^ permalink raw reply related
* Re: please consider remove those tags named master, which is ambigous with master branch
From: Andreas Ericsson @ 2008-09-24 18:56 UTC (permalink / raw)
To: Alex Riesen; +Cc: rae l, Matthias Urlichs, Andrew Morton, git, linux-kernel
In-Reply-To: <81b0412b0809240844y42218bedqe0e1eb22c067fcc3@mail.gmail.com>
Alex Riesen wrote:
> 2008/9/23 rae l <crquan@gmail.com>:
>> To Git developers:
>> I found that different git subcommand have inconsitent processing
>> about ambiguous refname,
>>
>> git show will take "master" tag first,
>> while git tag -v will take "master" branch first,
>>
>> So what's your suggestion to fix this? Just simple remove ambiguous refnames?
>
> You can use "refs/tags/master" and "refs/heads/master"...
Apart from that..
"git tag -v" taking a branch *at all* is not something we want to
happen, as it's supposed to verify the pgp signature of a signed
tag. Are you absolutely 100% certain that "git tag -v" tries to
verify refs/heads/master as a tag object?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC/PATCH] remove vim syntax highlighting in favor of upstream
From: Garry Dolley @ 2008-09-24 18:39 UTC (permalink / raw)
To: Jeff King; +Cc: SZEDER Gábor, vim, Shawn O. Pearce, git
In-Reply-To: <20080924175315.GA10337@coredump.intra.peff.net>
On Wed, Sep 24, 2008 at 01:53:15PM -0400, Jeff King wrote:
> [Tim Pope cc'd as the author of the official version. Tim: just an FYI,
> but if you have any comments, please feel free to share]
>
> [Shawn cc'd as the interim maintainer. I, for one, welcome our
> new Java-programming overlords].
>
> On Wed, Sep 24, 2008 at 07:01:54PM +0200, SZEDER Gábor wrote:
>
> > > Is there any objection to simply removing it (and probably replacing it
> > > with a note to go look at the official highlighting file)?
> > I'm for it, because I didn't know that there is an official git syntax
> > highlight file out there. Indeed, I haven't even know that vim 7.2 is
> > out.
>
> Here is a patch, then. Shawn, we should probably give any vim users a
> few days to object in case there is something they don't like about the
> upstream version, but other than that, I think this should be applied to
> master.
As a Vim user, I think removing the syntax file, and giving a
reference to the official one, is fine.
--
Garry Dolley
ARP Networks, Inc.
http://scie.nti.st
Los Angeles County REACT, Unit 336
WQGK336
^ permalink raw reply
* Re: [PATCH (GIT-GUI)] git-gui: Reenable staging unmerged files by clicking the icon.
From: Shawn O. Pearce @ 2008-09-24 18:25 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Johannes Sixt
In-Reply-To: <200809201219.18630.angavrilov@gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> This restores functionality of the file icon for unmerged files.
> Safety is enforced by loading the diff and checking for lines
> that look like conflict markers. If such lines are found, or
> the conflict involves deletion and/or symlinks, a confirmation
> dialog is presented. Otherwise, the icon immediately stages the
> working copy version of the file.
>
> Includes a revert of 2fe5b2ee42897a3acc78e5ddaace3775eb2713ca
> (Restore ability to Stage Working Copy for conflicts)
>
> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
> ---
> git-gui.sh | 18 ++++++++----------
> lib/diff.tcl | 52 +++++++++++++++++++++++++++++++++++-----------------
> lib/mergetool.tcl | 33 +++++++++++++++++++++++++++------
> 3 files changed, 70 insertions(+), 33 deletions(-)
Can I get a resend of this patch?
I don't seem to have the base objects it applies to, and it doesn't
apply clean to any branch I can find... :-|
--
Shawn.
^ permalink raw reply
* Re: Files that want to delete themselves
From: Andrew Vit @ 2008-09-24 18:18 UTC (permalink / raw)
To: git
In-Reply-To: <20080924180436.GJ10544@machine.or.cz>
Petr Baudis wrote:
>
> so how does that look like in git diff? My guess is you have a .git/
> subdirectory there and thus Git assumes that it is a submodule?
>
Yes, that did it! I was sure I deleted that .git directory in the plugin,
I'm guessing it came back when I downloaded an updated one a while ago...
Díky za dobrou radu!
--Andrew Vit
--
View this message in context: http://n2.nabble.com/Files-that-want-to-delete-themselves-tp1116033p1116082.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: TopGit: how to deal with upstream inclusion
From: martin f krafft @ 2008-09-24 18:13 UTC (permalink / raw)
To: Petr Baudis, git
In-Reply-To: <20080924152913.GY10360@machine.or.cz>
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
also sprach Petr Baudis <pasky@suse.cz> [2008.09.24.1729 +0200]:
> Please read again carefully :-) :
Oh. dear. Sorry.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"i worked myself up from nothing to a state of extreme poverty."
-- groucho marx
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] remove vim syntax highlighting in favor of upstream
From: Shawn O. Pearce @ 2008-09-24 18:07 UTC (permalink / raw)
To: Jeff King; +Cc: SZEDER GGGbor, vim, git
In-Reply-To: <20080924175315.GA10337@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> [Shawn cc'd as the interim maintainer. I, for one, welcome our
> new Java-programming overlords].
Heh.
> Here is a patch, then. Shawn, we should probably give any vim users a
> few days to object in case there is something they don't like about the
> upstream version, but other than that, I think this should be applied to
> master.
Thanks. Its queued in my pile of patches waiting for ACKs and/or
comments before I actually apply them to my tree. I'll let it sit
for a little, but I think we want to apply it.
> -- >8 --
> remove vim syntax highlighting in favor of upstream
>
> As of version 7.2, vim ships with its own syntax
> highlighting for git commit messages, which is:
>
> 1. more comprehensive in splitting up the various
> components of the file
>
> 2. in accordance with the usual vim behavior for syntax
> highlighting (e.g., respecting b:current_syntax)
>
> 3. presumably better maintained (I have not been using
> what's in git's contrib/ directory for some time in
> favor of the upstream version)
>
> This patch gets rid of our local version and just points
> interested parties to the upstream version.
--
Shawn.
^ permalink raw reply
* Re: Files that want to delete themselves
From: Shawn O. Pearce @ 2008-09-24 18:05 UTC (permalink / raw)
To: Andrew Vit; +Cc: git
In-Reply-To: <19654453.post@talk.nabble.com>
Andrew Vit <andrew@avit.ca> wrote:
>
> I have a Rails project that I'm managing with git and I have a strange
> problem with one of the plugin directories. Every time I do `git add .` it
> tries to delete itself... Any idea what might be happening?
>
> andrew$ git status
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # new file: vendor/plugins/restful_authentication
> # deleted: vendor/plugins/restful_authentication/CHANGELOG
> # deleted: vendor/plugins/restful_authentication/README.textile
> # deleted: vendor/plugins/restful_authentication/Rakefile
> # deleted: vendor/plugins/restful_authentication/TODO
Are you on a case-insensitive filesystem like HFS+?
Is it possible that restful_authentication exists as a file in
your working directory, but as a directory in Git, but with a
different case?
What does `git ls-tree HEAD:vendor/plugins` show you as the last
committed contents of vendor/plugins?
I'm a little stumped, but it sounds like the issues that have come
up before due to a case-insensitive filesystem.
--
Shawn.
^ permalink raw reply
* Re: Files that want to delete themselves
From: Petr Baudis @ 2008-09-24 18:04 UTC (permalink / raw)
To: Andrew Vit; +Cc: git
In-Reply-To: <19654453.post@talk.nabble.com>
Hi,
On Wed, Sep 24, 2008 at 10:55:02AM -0700, Andrew Vit wrote:
> I have a Rails project that I'm managing with git and I have a strange
> problem with one of the plugin directories. Every time I do `git add .` it
> tries to delete itself... Any idea what might be happening?
so how does that look like in git diff? My guess is you have a .git/
subdirectory there and thus Git assumes that it is a submodule? I don't
think we actually have a way to specify that some directory should NOT
be considered a submodule even if it is a git checkout... So you will
probably either have to actually convert this to a submodule in your
project (probably the sanest thing to do), move the .git subdirectory
away or submit a patch that will add say a .gitattributes flag not to
consider this subdirectory to be a submodule (which might make some
sense).
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism,
but they have cold baths.
^ permalink raw reply
* Re: fatal: cannot store pack file (git 1.6.0.2 + sshfs)
From: Nathan W. Panike @ 2008-09-24 17:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jhair Tocancipa Triana, git
In-Reply-To: <20080924163400.GU3669@spearce.org>
Resend with reply to all:
When I mount with sshfs, I have to give the option
sshfs -o workaround=rename ...
to make things work normally.
On Wed, Sep 24, 2008 at 11:34 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Jhair Tocancipa Triana <jhair.tocancipa@gmail.com> wrote:
>> I'm getting the following when running git on a partition mounted with
>> sshfs:
>>
>> $ git pull
> ...
>> error: unable to write sha1 filename .git/objects/pack/pack-dc5c3614e795918f457a2f98a58f10134ebf246b.pack: Operation not permitted
>> fatal: cannot store pack file
>> fatal: index-pack failed
>>
>> git pull worked fine in the same repository yesterday (new files where
>> committed in the meantime).
>>
>> I'm not sure if this is a problem in git or in sshfs (or somewhere
>> else).
>
> Its the size of the fetch. The day before you probably had a smaller
> number of objects downloaded (<100) so Git used unpack-objects
> instead of index-pack. Yesterday it was a larger download (>100),
> so it used index-pack.
>
> In 1.6.0.2 index-pack writes a temporary file to .git/objects but
> later tries to rename it into .git/objects/pack. That renaming
> must not be working on sshfs.
>
> Latest "master" has a change from Pasky (8b4eb6b6 "Do not perform
> cross-directory renames") that should fix this issue. Or just
> don't use sshfs. Or teach sshfs to rename across directories.
>
> --
> Shawn.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Files that want to delete themselves
From: Andrew Vit @ 2008-09-24 17:55 UTC (permalink / raw)
To: git
Hi,
I have a Rails project that I'm managing with git and I have a strange
problem with one of the plugin directories. Every time I do `git add .` it
tries to delete itself... Any idea what might be happening?
andrew$ git status
# On branch master
nothing to commit (working directory clean)
andrew$ git add .
andrew$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: vendor/plugins/restful_authentication
# deleted: vendor/plugins/restful_authentication/CHANGELOG
# deleted: vendor/plugins/restful_authentication/README.textile
# deleted: vendor/plugins/restful_authentication/Rakefile
# deleted: vendor/plugins/restful_authentication/TODO
# ...
# ...
# ...
#
--
View this message in context: http://www.nabble.com/Files-that-want-to-delete-themselves-tp19654453p19654453.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [RFC/PATCH] remove vim syntax highlighting in favor of upstream
From: Jeff King @ 2008-09-24 17:53 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: vim, Shawn O. Pearce, git
In-Reply-To: <20080924170154.GA6816@neumann>
[Tim Pope cc'd as the author of the official version. Tim: just an FYI,
but if you have any comments, please feel free to share]
[Shawn cc'd as the interim maintainer. I, for one, welcome our
new Java-programming overlords].
On Wed, Sep 24, 2008 at 07:01:54PM +0200, SZEDER Gábor wrote:
> > Is there any objection to simply removing it (and probably replacing it
> > with a note to go look at the official highlighting file)?
> I'm for it, because I didn't know that there is an official git syntax
> highlight file out there. Indeed, I haven't even know that vim 7.2 is
> out.
Here is a patch, then. Shawn, we should probably give any vim users a
few days to object in case there is something they don't like about the
upstream version, but other than that, I think this should be applied to
master.
-- >8 --
remove vim syntax highlighting in favor of upstream
As of version 7.2, vim ships with its own syntax
highlighting for git commit messages, which is:
1. more comprehensive in splitting up the various
components of the file
2. in accordance with the usual vim behavior for syntax
highlighting (e.g., respecting b:current_syntax)
3. presumably better maintained (I have not been using
what's in git's contrib/ directory for some time in
favor of the upstream version)
This patch gets rid of our local version and just points
interested parties to the upstream version.
---
contrib/vim/README | 13 +++++++++++--
contrib/vim/syntax/gitcommit.vim | 18 ------------------
2 files changed, 11 insertions(+), 20 deletions(-)
delete mode 100644 contrib/vim/syntax/gitcommit.vim
diff --git a/contrib/vim/README b/contrib/vim/README
index 9e7881f..12d61bb 100644
--- a/contrib/vim/README
+++ b/contrib/vim/README
@@ -1,8 +1,17 @@
-To syntax highlight git's commit messages, you need to:
- 1. Copy syntax/gitcommit.vim to vim's syntax directory:
+Syntax highlighting for git commit messages is included with the vim
+distribution as of vim 7.2, and should work automatically.
+
+If you have an older version of vim, you can get the latest syntax file
+from the vim project:
+
+ http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitcommit.vim
+
+To install:
+
+ 1. Copy gitcommit.vim to vim's syntax directory:
$ mkdir -p $HOME/.vim/syntax
$ cp syntax/gitcommit.vim $HOME/.vim/syntax
2. Auto-detect the editing of git commit files:
$ cat >>$HOME/.vimrc <<'EOF'
autocmd BufNewFile,BufRead COMMIT_EDITMSG set filetype=gitcommit
EOF
diff --git a/contrib/vim/syntax/gitcommit.vim b/contrib/vim/syntax/gitcommit.vim
deleted file mode 100644
index 332121b..0000000
--- a/contrib/vim/syntax/gitcommit.vim
+++ /dev/null
@@ -1,18 +0,0 @@
-syn region gitLine start=/^#/ end=/$/
-syn region gitCommit start=/^# Changes to be committed:$/ end=/^#$/ contains=gitHead,gitCommitFile
-syn region gitHead contained start=/^# (.*)/ end=/^#$/
-syn region gitChanged start=/^# Changed but not updated:/ end=/^#$/ contains=gitHead,gitChangedFile
-syn region gitUntracked start=/^# Untracked files:/ end=/^#$/ contains=gitHead,gitUntrackedFile
-
-syn match gitCommitFile contained /^#\t.*/hs=s+2
-syn match gitChangedFile contained /^#\t.*/hs=s+2
-syn match gitUntrackedFile contained /^#\t.*/hs=s+2
-
-hi def link gitLine Comment
-hi def link gitCommit Comment
-hi def link gitChanged Comment
-hi def link gitHead Comment
-hi def link gitUntracked Comment
-hi def link gitCommitFile Type
-hi def link gitChangedFile Constant
-hi def link gitUntrackedFile Constant
--
1.6.0.2.473.g126a14
^ permalink raw reply related
* Re: Partial tree export and merging
From: Nguyen Thai Ngoc Duy @ 2008-09-24 17:51 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann
In-Reply-To: <48DA476F.1070700@mahr.de>
On 9/24/08, Heiko Voigt <heiko.voigt@mahr.de> wrote:
> Hallo,
>
> I am currently facing a challenge for adding limited access to a git
> repository for the i18n and documentation (language) team. Our repository
> contains *.html and *.loc files which are located along with the code. The
> language team should not see the code. At the same time a developer using
> the full tree needs to be able to contribute to the i8n files.
That could be done with (under-developing) sparse checkout. Basically
language team's people do "git clone --sparse-checkout='*.loc:*.html'
your-repo.git". Then they only have *.loc and *.html files in working
directory. When they commit, all other files are unchanged. Developers
merge to have updated *.log/html as usual.
I have a question though: is language team allowed to checkout/modify
files other than *.loc and *.html?
--
Duy
^ permalink raw reply
* Re: [PATCH/RFC 2/2] git-gui: Do not automatically stage file after merge tool finishes
From: Shawn O. Pearce @ 2008-09-24 17:50 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Johannes Sixt, git
In-Reply-To: <bb6f213e0809170525q286f5d42xfd734660dc935cbf@mail.gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> On Wed, Sep 17, 2008 at 3:40 PM, Johannes Sixt <johannes.sixt@telecom.at> wrote:
> > If a merge tool was invoked on a conflicted file and the tool completed,
> > then the conflicted file was staged automatically. However, the fact that
> > the user closed the merge tool cannot be understood as the unequivocal
> > sign that the conflict was completely resolved. For example, the user
> > could have decided to postpone the resolution of the conflict, or could
> > have accidentally closed the tool. We better leave the file unstaged and
> > let the user stage it explicitly.
>
> It completely reproduces the logic that git-mergetool uses. Namely, if
> the file is unchanged, it asks explicitly, and if the tool returns a
> non-zero exit code, it does not stage at all.
>
> You also cannot simply remove merge_add_resolution, because then it
> would leave the diff view stale.
Is it just a matter of calling reshow_diff instead?
--
Shawn.
^ permalink raw reply
* Re: [PATCH/RFC 0/2] git-gui: issues with merge tool series
From: Shawn O. Pearce @ 2008-09-24 17:48 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Johannes Sixt, git
In-Reply-To: <bb6f213e0809170550q5be339d1s825f95b1165e6507@mail.gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> On Wed, Sep 17, 2008 at 3:40 PM, Johannes Sixt <johannes.sixt@telecom.at> wrote:
> > 1. The inability to stage a conflicted file by clicking the icon is
> > *very* disruptive. The new menu entry "Stage Working Copy" is
> > really only a workaround, and it shows.
>
> I can see two ways to fix it:
>
> 1) Allow that icon to work only if the diff is currently displayed,
> and also ask for confirmation if there are any conflict markers
> present.
>
> Problem: What should it do with modify/delete conflicts, which
> don't have any conflict markers?
I'm inclined to say we should just let the icon work like it used
to, stage the whole working copy. That's exactly what it does on
a non-merge, and thus is what it should do on a merge.
As a safety feature we can scan the working copy for merge marks if
we are currently in a merge and prompt the user for confirmation
if it looks like they are merging an unmerged working copy.
> 2) Much harder: implement complete one-click undo. This involves
> saving information from the index somewhere, and forcing such items to
> remain in the 'staged' list, even if the index isn't different from
> the tree version any more.
>
> By the way, is there a simple way to re-create a conflict file from
> the saved multistage index entries?
Run git-merge-file after extracting the stages to temporary files.
You can also jam the stages back into the index with update-index
--index-info.
--
Shawn.
^ permalink raw reply
* Re: Applying changes across divergent branches
From: Jeff King @ 2008-09-24 17:09 UTC (permalink / raw)
To: Tom Schutzer-Weissmann; +Cc: git
In-Reply-To: <48DA514E.6060904@siscog.pt>
On Wed, Sep 24, 2008 at 03:40:14PM +0100, Tom Schutzer-Weissmann wrote:
> Could we use git, or a tool based on git, to change on the development
> branch and selectively apply changes to the other branches - is it as
> simple as using git cherry-pick?
If I am understanding your description of the problem correctly, then
yes, it is as simple as cherry-picking.
If your branches have a strict hierarchy, you can also use a "merge up"
workflow where some branches always contain all of other branches. For
example, in git has a "maint" branch for stable bugfixes and a "master"
branch for general development. The rule is that one must always merge
"up", meaning that master can merge from maint, but maint can never
merge from master. Stable bugfixes go on maint, and then get to master
by merging.
Depending on the details of your branches, something like that may work
for you. You can have a "base" branch that all product branches merge
from, and only changes which should affect all products go on that
branch (or on topic branches that are based on the "base" branch).
-Peff
^ permalink raw reply
* Re: [GIT-GUI PATCH] call prepare-commit-msg hook
From: Shawn O. Pearce @ 2008-09-24 17:04 UTC (permalink / raw)
To: Joshua Williams; +Cc: git, Jay Blakeborough, Bill Lohse
In-Reply-To: <48D02D99.9090102@qlogic.com>
Joshua Williams <joshua.williams@qlogic.com> wrote:
> Small change. Still need to load MERGE_MSG and SQUASH_MSG
> if there's no prepare-commit-msg hook. We now process the hook
> first and if it's not there, load MERGE_MSG or SQUASH_MSG.
>
> Signed-off-by: Joshua Williams <joshua.williams@qlogic.com>
This patch looks reasonable. My only comment is maybe we want
to delete PREPARE_COMMIT_MSG file when we "exit 1" when the hook
has declined.
> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
> index 10d8a44..8d06cd1 100755
> --- a/git-gui/git-gui.sh
> +++ b/git-gui/git-gui.sh
Can you please try to put this onto my current git-gui tree?
I don't have the base 10d8a44 object so I can't 3-way merge
this in, and the patch doesn't apply cleanly anymore.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] vim syntax: highlight the diff in commit message template
From: SZEDER Gábor @ 2008-09-24 17:01 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20080924155745.GA3908@coredump.intra.peff.net>
Hi,
On Wed, Sep 24, 2008 at 11:57:45AM -0400, Jeff King wrote:
> Is there any objection to simply removing it (and probably replacing it
> with a note to go look at the official highlighting file)?
I'm for it, because I didn't know that there is an official git syntax
highlight file out there. Indeed, I haven't even know that vim 7.2 is
out.
Thanks,
Gábor
^ 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