* git-svn help for authorsfile
From: Dongsheng Song @ 2007-10-18 6:26 UTC (permalink / raw)
To: git
In general, all svn projects share the same authorsfile, e.g.
[svn]
authorsfile=/path/to/authorsfile
[svn-remote "project-a"]
url = http://server.org/svn
branches = branches/*/project-a:refs/remotes/project-a/branches/*
tags = tags/*/project-a:refs/remotes/project-a/tags/*
trunk = trunk/project-a:refs/remotes/project-a/trunk
[svn-remote "project-b"]
url = http://server.org/svn
branches = branches/*/project-b:refs/remotes/project-b/branches/*
tags = tags/*/project-b:refs/remotes/project-b/tags/*
trunk = trunk/project-b:refs/remotes/project-b/trunk
But if project-a and project-b has same svn id, map to different
user/email, how do I do?
Can we move authorsfile from svn to svn-remote section ?
Thanks for some help,
---
Dongsheng
^ permalink raw reply
* [PATCH] git-blame shouldn't crash if run in an unmerged tree
From: Shawn O. Pearce @ 2007-10-18 6:34 UTC (permalink / raw)
To: Linus Torvalds, git; +Cc: B.Steinbrink
I'm applying this patch to my maint tree tonight as it does resolve
the issue for now. What surprised me was the file that we were
crashing out on wasn't even the file we wanted to get the blame
data for. :-\
--8>--
From: Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH] git-blame shouldn't crash if run in an unmerged tree
If we are in the middle of resolving a merge conflict there may be
one or more files whose entries in the index represent an unmerged
state (index entries in the higher-order stages).
Attempting to run git-blame on any file in such a working directory
resulted in "fatal: internal error: ce_mode is 0" as we use the magic
marker for an unmerged entry is 0 (set up by things like diff-lib.c's
do_diff_cache() and builtin-read-tree.c's read_tree_unmerged())
and the ce_match_stat_basic() function gets upset about this.
I'm not entirely sure that the whole "ce_mode = 0" case is a good
idea to begin with, and maybe the right thing to do is to remove
that horrid freakish special case, but removing the internal error
seems to be the simplest fix for now.
Linus
[sp: Thanks to Björn Steinbrink for the test case]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
read-cache.c | 2 +
t/t8004-blame.sh | 73 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 75 insertions(+), 0 deletions(-)
create mode 100755 t/t8004-blame.sh
diff --git a/read-cache.c b/read-cache.c
index 536f4d0..928e8fa 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -149,6 +149,8 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
else if (ce_compare_gitlink(ce))
changed |= DATA_CHANGED;
return changed;
+ case 0: /* Special case: unmerged file in index */
+ return MODE_CHANGED | DATA_CHANGED | TYPE_CHANGED;
default:
die("internal error: ce_mode is %o", ntohl(ce->ce_mode));
}
diff --git a/t/t8004-blame.sh b/t/t8004-blame.sh
new file mode 100755
index 0000000..ba19ac1
--- /dev/null
+++ b/t/t8004-blame.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+
+# Based on a test case submitted by Björn Steinbrink.
+
+test_description='git blame on conflicted files'
+. ./test-lib.sh
+
+test_expect_success 'setup first case' '
+ # Create the old file
+ echo "Old line" > file1 &&
+ git add file1 &&
+ git commit --author "Old Line <ol@localhost>" -m file1.a &&
+
+ # Branch
+ git checkout -b foo &&
+
+ # Do an ugly move and change
+ git rm file1 &&
+ echo "New line ..." > file2 &&
+ echo "... and more" >> file2 &&
+ git add file2 &&
+ git commit --author "U Gly <ug@localhost>" -m ugly &&
+
+ # Back to master and change something
+ git checkout master &&
+ echo "
+
+bla" >> file1 &&
+ git commit --author "Old Line <ol@localhost>" -a -m file1.b &&
+
+ # Back to foo and merge master
+ git checkout foo &&
+ if git merge master; then
+ echo needed conflict here
+ exit 1
+ else
+ echo merge failed - resolving automatically
+ fi &&
+ echo "New line ...
+... and more
+
+bla
+Even more" > file2 &&
+ git rm file1 &&
+ git commit --author "M Result <mr@localhost>" -a -m merged &&
+
+ # Back to master and change file1 again
+ git checkout master &&
+ sed s/bla/foo/ <file1 >X &&
+ rm file1 &&
+ mv X file1 &&
+ git commit --author "No Bla <nb@localhost>" -a -m replace &&
+
+ # Try to merge into foo again
+ git checkout foo &&
+ if git merge master; then
+ echo needed conflict here
+ exit 1
+ else
+ echo merge failed - test is setup
+ fi
+'
+
+test_expect_success \
+ 'blame runs on unconflicted file while other file has conflicts' '
+ git blame file2
+'
+
+test_expect_success 'blame runs on conflicted file in stages 1,3' '
+ git blame file1
+'
+
+test_done
--
1.5.3.4.1231.gac645
^ permalink raw reply related
* Re: [PATCH] t5516: test update of local refs on push
From: Shawn O. Pearce @ 2007-10-18 6:59 UTC (permalink / raw)
To: Jeff King; +Cc: git, Perry Wagle
In-Reply-To: <20071018062136.GB11938@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Thu, Oct 18, 2007 at 02:17:46AM -0400, Jeff King wrote:
> > The first test (updating local refs) should succeed, but the
> > second one (not updating on error) currently fails.
>
> Oops, this should of course be labeled as 1/2.
>
> For the fix, I didn't need anything from 'next', after all, and 2/2 also
> works fine there (it was almost literally a code move).
Yay. I like it when I'm proven wrong. Especially by a short patch.
:)
This will be in next tonight. Give it a few days, then probably
graduate up to master.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Make the output of "git svn clone" less confusing.
From: Shawn O. Pearce @ 2007-10-18 7:06 UTC (permalink / raw)
To: Eric Wong; +Cc: David Kågedal, git
In-Reply-To: <87k5poflp5.fsf@lysator.liu.se>
David Kgedal <davidk@lysator.liu.se> wrote:
> The problem is that the first thing it prints is
>
> Initialized empty Git repository in .git/
>
> even if actually created a subdirectory and changed into it first. But to the
> user, it looks like it is creating a .git/ dir in the directory he/she is
> started git from.
Eric, ack/nack?
> ---
> git-svn.perl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> This change makes it more chatty, which might not be a good thing. But
> I think the previous output was worse.
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 777e436..d4450ca 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -286,6 +286,7 @@ sub do_git_init_db {
>
> sub init_subdir {
> my $repo_path = shift or return;
> + print "Creating directory $repo_path\n";
> mkpath([$repo_path]) unless -d $repo_path;
> chdir $repo_path or die "Couldn't chdir to $repo_path: $!\n";
> $ENV{GIT_DIR} = '.git';
> --
> 1.5.3.4.213.gb3127-dirty
--
Shawn.
^ permalink raw reply
* Re: On Tabs and Spaces
From: David Kågedal @ 2007-10-18 7:12 UTC (permalink / raw)
To: git
In-Reply-To: <20071018023103.5d27ee35@localhost.localdomain>
Christer Weinigel <christer@weinigel.se> writes:
> I usually have no need to use git since my employer doesn't use it.
That is actually not true. My employer doesn't use it either (we use
svn). But that doesn't stop me from using it all the time. git is an
excellent offline svn client.
(hej wingel)
--
David Kågedal
^ permalink raw reply
* Re: On Tabs and Spaces
From: David Kågedal @ 2007-10-18 7:15 UTC (permalink / raw)
To: git
In-Reply-To: <47168E70.4070305@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Jari Aalto wrote:
>> * Wed 2007-10-17 Michael Witten <mfwitten@MIT.EDU>
>> * Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu
>>> On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote:
>>>
>>>> But I still haven't seen any compelling arguments against the "all
>>>> space" case
>>> Overhead!
>>>
>>> If you use 8 spaces instead of one tab,
>>> that's using up 7x more space!
>>
>> Software is the right place to worry about optimization. We should trust
>> SCM to make proper and efficient deltas. If not, algorithms need
>> improvemnts.
>>
>> Any cross platform development or electronic exchange is guaranteed to
>> be interpreted correctly when policy enforces "only spaces"
>>
>> As we have already seen in numerous times in this thread, using tabs
>> will - eventually - be interpreted in some editor, in some display, in
>> some encironment using some tools ... incorrectly or different than the
>> author intended. Simply because editors are configurable and we cannot
>> know what settings they may have when they load the file in.
>>
>
> And simply because nearly all (unix) editors still insert a hard tab
> when pressing the tab key, and *mixing* tabs and spaces makes the
> situation *really* unbearable, one really shouldn't use all spaces.
I guess that means that you consider emacs to be an obscure or
non-unix editor?
When you press TAB while editing program code in emacs it doesn't
insert a hard tab. It reindents the current line according to the
indentation rules. The whitespace at the beginning of the line is
filled with spaces and/or tabs, depending on the indent-tabs-mode
setting.
--
David Kågedal
^ permalink raw reply
* Re: [PATCH 1/2 v3] mergetool: use path to mergetool in config var mergetool.<tool>.path
From: Steffen Prohaska @ 2007-10-18 7:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071018052724.GA27813@spearce.org>
On Oct 18, 2007, at 7:27 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>> This commit adds a mechanism to provide absolute paths to the
>> external programs called by 'git mergetool'. ...
> ...
>> @@ -297,17 +297,38 @@ do
>> shift
>> done
>>
>> +valid_tool() {
>> + case "$1" in
>> + kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff |
>> gvimdiff)
>> + ;; # happy
>> + *)
>> + return 1
>> + ;;
>> + esac
>> +}
> ...
>> + test -n "$merge_tool" || valid_tool "$merge_tool" || {
>
> Wouldn't an empty $merge_tool string be caught above in the
> valid_tool function where it falls through and returns 1?
> So isn't test -n here redundant?
Sharp eyes, thanks.
Correct is
test -z "$merge_tool" || valid_tool "$merge_tool" || {
No merge tool or a valid merge tool is allowed at this place.
If the tool's already empty there's no need to tell the user
that it will be reset to empty.
I'll send a v4 version.
Steffen
^ permalink raw reply
* [PATCH 1/2 v4] mergetool: use path to mergetool in config var mergetool.<tool>.path
From: Steffen Prohaska @ 2007-10-18 7:53 UTC (permalink / raw)
To: spearce; +Cc: git, Steffen Prohaska
In-Reply-To: <923DDB10-C9E9-4797-9FC1-D31DEEBE75B7@zib.de>
This commit adds a mechanism to provide absolute paths to the
external programs called by 'git mergetool'. A path can be
specified in the configuation variable mergetool.<tool>.path.
The configuration variable is similar to how we name branches
and remotes. It is extensible if we need to specify more details
about a tool.
The mechanism is especially useful on Windows, where external
programs are unlikely to be in PATH.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-mergetool.txt | 6 ++
git-mergetool.sh | 97 +++++++++++++++++++++-----------------
2 files changed, 60 insertions(+), 43 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6c32c6d..78b2f43 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -31,6 +31,12 @@ If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
configuration variable merge.tool is not set, 'git mergetool'
will pick a suitable default.
++
+You can explicitly provide a full path to the tool by setting the
+configuration variable mergetool.<tool>.path. For example, you
+can configure the absolute path to kdiff3 by setting
+mergetool.kdiff3.path. Otherwise, 'git mergetool' assumes the tool
+is available in PATH.
Author
------
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 9f4f313..987aeda 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -192,10 +192,10 @@ merge_file () {
case "$merge_tool" in
kdiff3)
if base_present ; then
- (kdiff3 --auto --L1 "$path (Base)" --L2 "$path (Local)" --L3 "$path (Remote)" \
+ ("$merge_tool_path" --auto --L1 "$path (Base)" --L2 "$path (Local)" --L3 "$path (Remote)" \
-o "$path" -- "$BASE" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
else
- (kdiff3 --auto --L1 "$path (Local)" --L2 "$path (Remote)" \
+ ("$merge_tool_path" --auto --L1 "$path (Local)" --L2 "$path (Remote)" \
-o "$path" -- "$LOCAL" "$REMOTE" > /dev/null 2>&1)
fi
status=$?
@@ -203,35 +203,35 @@ merge_file () {
;;
tkdiff)
if base_present ; then
- tkdiff -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
else
- tkdiff -o "$path" -- "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -o "$path" -- "$LOCAL" "$REMOTE"
fi
status=$?
save_backup
;;
meld|vimdiff)
touch "$BACKUP"
- $merge_tool -- "$LOCAL" "$path" "$REMOTE"
+ "$merge_tool_path" -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
;;
gvimdiff)
touch "$BACKUP"
- gvimdiff -f -- "$LOCAL" "$path" "$REMOTE"
+ "$merge_tool_path" -f -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
;;
xxdiff)
touch "$BACKUP"
if base_present ; then
- xxdiff -X --show-merged-pane \
+ "$merge_tool_path" -X --show-merged-pane \
-R 'Accel.SaveAsMerged: "Ctrl-S"' \
-R 'Accel.Search: "Ctrl+F"' \
-R 'Accel.SearchForward: "Ctrl-G"' \
--merged-file "$path" -- "$LOCAL" "$BASE" "$REMOTE"
else
- xxdiff -X --show-merged-pane \
+ "$merge_tool_path" -X --show-merged-pane \
-R 'Accel.SaveAsMerged: "Ctrl-S"' \
-R 'Accel.Search: "Ctrl+F"' \
-R 'Accel.SearchForward: "Ctrl-G"' \
@@ -243,18 +243,18 @@ merge_file () {
opendiff)
touch "$BACKUP"
if base_present; then
- opendiff "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$path" | cat
+ "$merge_tool_path" "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$path" | cat
else
- opendiff "$LOCAL" "$REMOTE" -merge "$path" | cat
+ "$merge_tool_path" "$LOCAL" "$REMOTE" -merge "$path" | cat
fi
check_unchanged
save_backup
;;
emerge)
if base_present ; then
- emacs -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
+ "$merge_tool_path" -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
else
- emacs -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$path")"
+ "$merge_tool_path" -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$path")"
fi
status=$?
save_backup
@@ -297,17 +297,38 @@ do
shift
done
+valid_tool() {
+ case "$1" in
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff)
+ ;; # happy
+ *)
+ return 1
+ ;;
+ esac
+}
+
+init_merge_tool_path() {
+ merge_tool_path=`git config mergetool.$1.path`
+ if test -z "$merge_tool_path" ; then
+ case "$merge_tool" in
+ emerge)
+ merge_tool_path=emacs
+ ;;
+ *)
+ merge_tool_path=$merge_tool
+ ;;
+ esac
+ fi
+}
+
+
if test -z "$merge_tool"; then
merge_tool=`git config merge.tool`
- case "$merge_tool" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | "")
- ;; # happy
- *)
+ test -z "$merge_tool" || valid_tool "$merge_tool" || {
echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
echo >&2 "Resetting to default..."
unset merge_tool
- ;;
- esac
+ }
fi
if test -z "$merge_tool" ; then
@@ -329,40 +350,30 @@ if test -z "$merge_tool" ; then
merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
echo "merge tool candidates: $merge_tool_candidates"
for i in $merge_tool_candidates; do
- if test $i = emerge ; then
- cmd=emacs
- else
- cmd=$i
- fi
- if type $cmd > /dev/null 2>&1; then
+ init_merge_tool_path $i
+ if type "$merge_tool_path" > /dev/null 2>&1; then
merge_tool=$i
break
fi
done
if test -z "$merge_tool" ; then
- echo "No available merge resolution programs available."
+ echo "No known merge resolution program available."
exit 1
fi
+else
+ valid_tool "$merge_tool" || {
+ echo >&2 "Unknown merge_tool $merge_tool"
+ exit 1
+ }
+
+ init_merge_tool_path "$merge_tool"
+
+ if ! type "$merge_tool_path" > /dev/null 2>&1; then
+ echo "The merge tool $merge_tool is not available as '$merge_tool_path'"
+ exit 1
+ fi
fi
-case "$merge_tool" in
- kdiff3|tkdiff|meld|xxdiff|vimdiff|gvimdiff|opendiff)
- if ! type "$merge_tool" > /dev/null 2>&1; then
- echo "The merge tool $merge_tool is not available"
- exit 1
- fi
- ;;
- emerge)
- if ! type "emacs" > /dev/null 2>&1; then
- echo "Emacs is not available"
- exit 1
- fi
- ;;
- *)
- echo "Unknown merge tool: $merge_tool"
- exit 1
- ;;
-esac
if test $# -eq 0 ; then
files=`git ls-files -u | sed -e 's/^[^ ]* //' | sort -u`
--
1.5.3.4.222.g2830
^ permalink raw reply related
* Re: [PATCH 1/2 v3] mergetool: use path to mergetool in config var mergetool.<tool>.path
From: Shawn O. Pearce @ 2007-10-18 8:00 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <923DDB10-C9E9-4797-9FC1-D31DEEBE75B7@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Oct 18, 2007, at 7:27 AM, Shawn O. Pearce wrote:
> >...
> >>+ test -n "$merge_tool" || valid_tool "$merge_tool" || {
> >
> >Wouldn't an empty $merge_tool string be caught above in the
> >valid_tool function where it falls through and returns 1?
> >So isn't test -n here redundant?
>
> Sharp eyes, thanks.
>
> Correct is
>
> test -z "$merge_tool" || valid_tool "$merge_tool" || {
>
> No merge tool or a valid merge tool is allowed at this place.
> If the tool's already empty there's no need to tell the user
> that it will be reset to empty.
>
> I'll send a v4 version.
Thanks but its a little late. I'm about to push maint/master/next/pu
and this series is in next. While testing it I found another
bug related to init_tool_merge_tool_path() not having $merge_tool
initialized and thus causing it to never select a default tool if
the user didn't have one configured.
Here's what I'm actually about to push out:
--8>--
From e3fa2c761fdc490494e8e0855bcee4d7e58ada6a Mon Sep 17 00:00:00 2001
From: Steffen Prohaska <prohaska@zib.de>
Date: Wed, 17 Oct 2007 19:16:11 +0200
Subject: [PATCH] mergetool: use path to mergetool in config var mergetool.<tool>.path
This commit adds a mechanism to provide absolute paths to the
external programs called by 'git mergetool'. A path can be
specified in the configuation variable mergetool.<tool>.path.
The configuration variable is similar to how we name branches
and remotes. It is extensible if we need to specify more details
about a tool.
The mechanism is especially useful on Windows, where external
programs are unlikely to be in PATH.
[sp: Fixed a few minor issues prior to applying]
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/git-mergetool.txt | 6 ++
git-mergetool.sh | 97 +++++++++++++++++++++-----------------
2 files changed, 60 insertions(+), 43 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6c32c6d..78b2f43 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -31,6 +31,12 @@ If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
configuration variable merge.tool is not set, 'git mergetool'
will pick a suitable default.
++
+You can explicitly provide a full path to the tool by setting the
+configuration variable mergetool.<tool>.path. For example, you
+can configure the absolute path to kdiff3 by setting
+mergetool.kdiff3.path. Otherwise, 'git mergetool' assumes the tool
+is available in PATH.
Author
------
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 9f4f313..4f89cbe 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -192,10 +192,10 @@ merge_file () {
case "$merge_tool" in
kdiff3)
if base_present ; then
- (kdiff3 --auto --L1 "$path (Base)" --L2 "$path (Local)" --L3 "$path (Remote)" \
+ ("$merge_tool_path" --auto --L1 "$path (Base)" --L2 "$path (Local)" --L3 "$path (Remote)" \
-o "$path" -- "$BASE" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
else
- (kdiff3 --auto --L1 "$path (Local)" --L2 "$path (Remote)" \
+ ("$merge_tool_path" --auto --L1 "$path (Local)" --L2 "$path (Remote)" \
-o "$path" -- "$LOCAL" "$REMOTE" > /dev/null 2>&1)
fi
status=$?
@@ -203,35 +203,35 @@ merge_file () {
;;
tkdiff)
if base_present ; then
- tkdiff -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
else
- tkdiff -o "$path" -- "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -o "$path" -- "$LOCAL" "$REMOTE"
fi
status=$?
save_backup
;;
meld|vimdiff)
touch "$BACKUP"
- $merge_tool -- "$LOCAL" "$path" "$REMOTE"
+ "$merge_tool_path" -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
;;
gvimdiff)
touch "$BACKUP"
- gvimdiff -f -- "$LOCAL" "$path" "$REMOTE"
+ "$merge_tool_path" -f -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
;;
xxdiff)
touch "$BACKUP"
if base_present ; then
- xxdiff -X --show-merged-pane \
+ "$merge_tool_path" -X --show-merged-pane \
-R 'Accel.SaveAsMerged: "Ctrl-S"' \
-R 'Accel.Search: "Ctrl+F"' \
-R 'Accel.SearchForward: "Ctrl-G"' \
--merged-file "$path" -- "$LOCAL" "$BASE" "$REMOTE"
else
- xxdiff -X --show-merged-pane \
+ "$merge_tool_path" -X --show-merged-pane \
-R 'Accel.SaveAsMerged: "Ctrl-S"' \
-R 'Accel.Search: "Ctrl+F"' \
-R 'Accel.SearchForward: "Ctrl-G"' \
@@ -243,18 +243,18 @@ merge_file () {
opendiff)
touch "$BACKUP"
if base_present; then
- opendiff "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$path" | cat
+ "$merge_tool_path" "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$path" | cat
else
- opendiff "$LOCAL" "$REMOTE" -merge "$path" | cat
+ "$merge_tool_path" "$LOCAL" "$REMOTE" -merge "$path" | cat
fi
check_unchanged
save_backup
;;
emerge)
if base_present ; then
- emacs -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
+ "$merge_tool_path" -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
else
- emacs -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$path")"
+ "$merge_tool_path" -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$path")"
fi
status=$?
save_backup
@@ -297,17 +297,38 @@ do
shift
done
+valid_tool() {
+ case "$1" in
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff)
+ ;; # happy
+ *)
+ return 1
+ ;;
+ esac
+}
+
+init_merge_tool_path() {
+ merge_tool_path=`git config mergetool.$1.path`
+ if test -z "$merge_tool_path" ; then
+ case "$1" in
+ emerge)
+ merge_tool_path=emacs
+ ;;
+ *)
+ merge_tool_path=$1
+ ;;
+ esac
+ fi
+}
+
+
if test -z "$merge_tool"; then
merge_tool=`git config merge.tool`
- case "$merge_tool" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | "")
- ;; # happy
- *)
+ if ! valid_tool "$merge_tool"; then
echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
echo >&2 "Resetting to default..."
unset merge_tool
- ;;
- esac
+ fi
fi
if test -z "$merge_tool" ; then
@@ -329,40 +350,30 @@ if test -z "$merge_tool" ; then
merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
echo "merge tool candidates: $merge_tool_candidates"
for i in $merge_tool_candidates; do
- if test $i = emerge ; then
- cmd=emacs
- else
- cmd=$i
- fi
- if type $cmd > /dev/null 2>&1; then
+ init_merge_tool_path $i
+ if type "$merge_tool_path" > /dev/null 2>&1; then
merge_tool=$i
break
fi
done
if test -z "$merge_tool" ; then
- echo "No available merge resolution programs available."
+ echo "No known merge resolution program available."
exit 1
fi
+else
+ if ! valid_tool "$merge_tool"; then
+ echo >&2 "Unknown merge_tool $merge_tool"
+ exit 1
+ fi
+
+ init_merge_tool_path "$merge_tool"
+
+ if ! type "$merge_tool_path" > /dev/null 2>&1; then
+ echo "The merge tool $merge_tool is not available as '$merge_tool_path'"
+ exit 1
+ fi
fi
-case "$merge_tool" in
- kdiff3|tkdiff|meld|xxdiff|vimdiff|gvimdiff|opendiff)
- if ! type "$merge_tool" > /dev/null 2>&1; then
- echo "The merge tool $merge_tool is not available"
- exit 1
- fi
- ;;
- emerge)
- if ! type "emacs" > /dev/null 2>&1; then
- echo "Emacs is not available"
- exit 1
- fi
- ;;
- *)
- echo "Unknown merge tool: $merge_tool"
- exit 1
- ;;
-esac
if test $# -eq 0 ; then
files=`git ls-files -u | sed -e 's/^[^ ]* //' | sort -u`
--
1.5.3.4.1231.gac645
--
Shawn.
^ permalink raw reply related
* Re: On Tabs and Spaces
From: Jari Aalto @ 2007-10-18 8:19 UTC (permalink / raw)
To: git
In-Reply-To: <200710180031.54819.dmitry.torokhov@gmail.com>
* Thu 2007-10-18 Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Message-Id: 200710180031.54819.dmitry.torokhov@gmail.com
> On Wednesday 17 October 2007, Jari Aalto wrote:
>
>> - Any editor will display the text written in "all spaces"
>> 100 % the same. Regradless of any viewer or editor used.
>>
>> But the same is not true with text that uses tabs (because you
>> really can't know what options the editor is preset / user set /
>> regarding the treatment of tabs).
>>
>> The score is 1 - 0 for "all spaces" in this contest.
>>
>
> How about this - I like tabs because when you removing it you
> need to hit Backspace just once and don't have to strain your
> eyes figuring out "Did I delete enough? Does it line up now?"
First I must say that you're right. From user's perspective some things
are convenient and some things not so convenient; it depends:
a) select an editor where these are no-issues
b) use an editor that can be configured so that these are no-issues
c) use the current editor and live by its limitations
I do not speak for any particular project here, just from a general
perspective[1]:
A project policy QA enforces standards so that everybody can expect
things to work the same way. The common denominator from view
perspective (person A, B, C, D ... loads the text into a editor) is
"all spaces". Similarly if code is post processed, all tools can
expect that there are no surprises (it's all spaces, no combination
of spaces and tabs).
The effect of a project policy in general is to enforce standards that
may not necessary match everybody's preferences[2].
Jari
[1] 99 % of the projects do not use Kernel's 8-wide indentation
convention. In all seriously taken editors, the TAB-key is configurable
to move to specific positions; so called "tab stops". Therefore "hit
TAB-key to insert tab character" does not usually apply in coding
context. In coding, the TAB-key is used to control the indentation
level, which is a measure defined in Project policy (coding style).
[2]
The tabs vs spaces issue is simular to those of:
- Starting curly brace placement policy: at EOL, or at separate line
- Identifier naming policy: camelCase vs. dash_names
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* Re: [PATCH] git-blame shouldn't crash if run in an unmerged tree
From: Björn Steinbrink @ 2007-10-18 8:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, git
In-Reply-To: <20071018063407.GA28861@spearce.org>
On 2007.10.18 02:34:07 -0400, Shawn O. Pearce wrote:
> I'm applying this patch to my maint tree tonight as it does resolve
> the issue for now. What surprised me was the file that we were
> crashing out on wasn't even the file we wanted to get the blame
> data for. :-\
The first merge moved some code from file1 (which doesn't exist in the
branch anymore) into file2, so I guess the code move detection comes
into play here.
Actually, in the original case that crashed here, I was curious about
some lines in file2 which looked like they had been automatically merged
from file1, so I tried to use git blame with file2 to see if that really
happened (I didn't expect git to be even able to follow code moves while
merging). Unfortunately, I didn't get such a test case yet, which might
indicate that I've only imagined that merge, and thinking about it, I
think that file2 wasn't marked as modified in "git status". Hm, I'll try
to find that merge conflict again and try that again.
Björn
>
> --8>--
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Subject: [PATCH] git-blame shouldn't crash if run in an unmerged tree
>
> If we are in the middle of resolving a merge conflict there may be
> one or more files whose entries in the index represent an unmerged
> state (index entries in the higher-order stages).
>
> Attempting to run git-blame on any file in such a working directory
> resulted in "fatal: internal error: ce_mode is 0" as we use the magic
> marker for an unmerged entry is 0 (set up by things like diff-lib.c's
> do_diff_cache() and builtin-read-tree.c's read_tree_unmerged())
> and the ce_match_stat_basic() function gets upset about this.
>
> I'm not entirely sure that the whole "ce_mode = 0" case is a good
> idea to begin with, and maybe the right thing to do is to remove
> that horrid freakish special case, but removing the internal error
> seems to be the simplest fix for now.
>
> Linus
>
> [sp: Thanks to Björn Steinbrink for the test case]
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> read-cache.c | 2 +
> t/t8004-blame.sh | 73 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 75 insertions(+), 0 deletions(-)
> create mode 100755 t/t8004-blame.sh
>
> diff --git a/read-cache.c b/read-cache.c
> index 536f4d0..928e8fa 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -149,6 +149,8 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
> else if (ce_compare_gitlink(ce))
> changed |= DATA_CHANGED;
> return changed;
> + case 0: /* Special case: unmerged file in index */
> + return MODE_CHANGED | DATA_CHANGED | TYPE_CHANGED;
> default:
> die("internal error: ce_mode is %o", ntohl(ce->ce_mode));
> }
> diff --git a/t/t8004-blame.sh b/t/t8004-blame.sh
> new file mode 100755
> index 0000000..ba19ac1
> --- /dev/null
> +++ b/t/t8004-blame.sh
> @@ -0,0 +1,73 @@
> +#!/bin/sh
> +
> +# Based on a test case submitted by Björn Steinbrink.
> +
> +test_description='git blame on conflicted files'
> +. ./test-lib.sh
> +
> +test_expect_success 'setup first case' '
> + # Create the old file
> + echo "Old line" > file1 &&
> + git add file1 &&
> + git commit --author "Old Line <ol@localhost>" -m file1.a &&
> +
> + # Branch
> + git checkout -b foo &&
> +
> + # Do an ugly move and change
> + git rm file1 &&
> + echo "New line ..." > file2 &&
> + echo "... and more" >> file2 &&
> + git add file2 &&
> + git commit --author "U Gly <ug@localhost>" -m ugly &&
> +
> + # Back to master and change something
> + git checkout master &&
> + echo "
> +
> +bla" >> file1 &&
> + git commit --author "Old Line <ol@localhost>" -a -m file1.b &&
> +
> + # Back to foo and merge master
> + git checkout foo &&
> + if git merge master; then
> + echo needed conflict here
> + exit 1
> + else
> + echo merge failed - resolving automatically
> + fi &&
> + echo "New line ...
> +... and more
> +
> +bla
> +Even more" > file2 &&
> + git rm file1 &&
> + git commit --author "M Result <mr@localhost>" -a -m merged &&
> +
> + # Back to master and change file1 again
> + git checkout master &&
> + sed s/bla/foo/ <file1 >X &&
> + rm file1 &&
> + mv X file1 &&
> + git commit --author "No Bla <nb@localhost>" -a -m replace &&
> +
> + # Try to merge into foo again
> + git checkout foo &&
> + if git merge master; then
> + echo needed conflict here
> + exit 1
> + else
> + echo merge failed - test is setup
> + fi
> +'
> +
> +test_expect_success \
> + 'blame runs on unconflicted file while other file has conflicts' '
> + git blame file2
> +'
> +
> +test_expect_success 'blame runs on conflicted file in stages 1,3' '
> + git blame file1
> +'
> +
> +test_done
^ permalink raw reply
* git stash apply usability issues
From: Johannes Sixt @ 2007-10-18 8:32 UTC (permalink / raw)
To: Git Mailing List
(1) Looking at git-stash.sh I see a few uses of 'git diff' in apply_stash().
Shouldn't these use one of git-diff-{tree,index,files)? The reason is that
porcelain 'git diff' invokes custom diff drivers (that in my case run a UI
program), whereas the plumbing does not.
Is there a particular reason to use porcelain 'git diff'?
(2) when 'git stash apply' runs merge-recursive, it treats the current state
as 'ours' and the stash as 'theirs'. IMHO it should be the other way round:
I have stashed away changes to a binary file. Then committed a different
modification to it, and now want to apply the stash. This results in a
conflict that leaves the current state in the working tree, but I had
preferred that the stashed binary file were in the working tree now.
What do other git-stash users think about changing the order?
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/6] more compact progress display
From: Karl Hasselström @ 2007-10-18 8:34 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.9999.0710171653500.19446@xanadu.home>
On 2007-10-17 16:56:09 -0400, Nicolas Pitre wrote:
> On Wed, 17 Oct 2007, Karl Hasselström wrote:
>
> > Maybe an env variable could cause the code to emit
> > machine-friendly progress information instead?
>
> That won't help with remotely generated progress unaware of local
> env variable, and the remote server might still be generating old
> format.
Ah, I didn't realize the progress meter was generated on the remote
side. Sorry for the noise.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/2 v3] mergetool: use path to mergetool in config var mergetool.<tool>.path
From: Steffen Prohaska @ 2007-10-18 8:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071018080049.GK14735@spearce.org>
On Oct 18, 2007, at 10:00 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>> On Oct 18, 2007, at 7:27 AM, Shawn O. Pearce wrote:
>>> ...
>>>> + test -n "$merge_tool" || valid_tool "$merge_tool" || {
>>>
>>> Wouldn't an empty $merge_tool string be caught above in the
>>> valid_tool function where it falls through and returns 1?
>>> So isn't test -n here redundant?
>>
>> Sharp eyes, thanks.
>>
>> Correct is
>>
>> test -z "$merge_tool" || valid_tool "$merge_tool" || {
>>
>> No merge tool or a valid merge tool is allowed at this place.
>> If the tool's already empty there's no need to tell the user
>> that it will be reset to empty.
>>
>> I'll send a v4 version.
>
> Thanks but its a little late.
Sorry.
> I'm about to push maint/master/next/pu
> and this series is in next. While testing it I found another
> bug related to init_tool_merge_tool_path() not having $merge_tool
> initialized and thus causing it to never select a default tool if
> the user didn't have one configured.
I see. Thanks for fixing this.
> Here's what I'm actually about to push out:
One remark ...
[...]
>
> if test -z "$merge_tool"; then
> merge_tool=`git config merge.tool`
> - case "$merge_tool" in
> - kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff |
> gvimdiff | "")
> - ;; # happy
> - *)
> + if ! valid_tool "$merge_tool"; then
I think its ok to have an empty tool here ...
> echo >&2 "git config option merge.tool set to unknown tool:
> $merge_tool"
> echo >&2 "Resetting to default..."
... So we should not print this message if the tool is empty.
But an empty tool is not valid. Therefore a check if "$merge_tool"
is not empty should be added to the if.
Steffen
^ permalink raw reply
* [BUG] git remote add failure
From: Guido Ostkamp @ 2007-10-18 8:55 UTC (permalink / raw)
To: Git Mailing List
Hello,
I think I've found a bug in "git remote add". I tried the following:
$ git remote add -f spearce2 http://repo.or.cz/git/spearce.git
Cannot get the repository state from http://repo.or.cz/git/spearce.git
fetch spearce2: command returned error: 1
Obviously I used the wrong URI. Then I tried again:
$ git remote add -f spearce2 http://repo.or.cz/r/git/spearce.git
remote spearce2 already exists.
I think Git should not store the bad info and block the name when the
first call wasn't successfull.
Regards
Guido
^ permalink raw reply
* Re: [PATCH] git-blame shouldn't crash if run in an unmerged tree
From: Björn Steinbrink @ 2007-10-18 9:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, git
In-Reply-To: <20071018083105.GA21768@atjola.homenet>
On 2007.10.18 10:31:05 +0200, Björn Steinbrink wrote:
> On 2007.10.18 02:34:07 -0400, Shawn O. Pearce wrote:
> > I'm applying this patch to my maint tree tonight as it does resolve
> > the issue for now. What surprised me was the file that we were
> > crashing out on wasn't even the file we wanted to get the blame
> > data for. :-\
>
> The first merge moved some code from file1 (which doesn't exist in the
> branch anymore) into file2, so I guess the code move detection comes
> into play here.
>
> Actually, in the original case that crashed here, I was curious about
> some lines in file2 which looked like they had been automatically merged
> from file1, so I tried to use git blame with file2 to see if that really
> happened (I didn't expect git to be even able to follow code moves while
> merging). Unfortunately, I didn't get such a test case yet, which might
> indicate that I've only imagined that merge, and thinking about it, I
> think that file2 wasn't marked as modified in "git status". Hm, I'll try
> to find that merge conflict again and try that again.
Nope, didn't succeed in reproducing what I probably just pretend to have
seen.
Björn
^ permalink raw reply
* Howto request: going home in the middle of something?
From: Jan Wielemaker @ 2007-10-18 9:44 UTC (permalink / raw)
To: git
Hi,
I've somewhere seen it in a mail, but I can't find it anymore. I have a
bare central (public) repository and clones on various machines I work
on. We all know it, you're right in the middle of something and it is
really time to go home. You want to pick up your work at home, but
without pushing to the shared repository.
I'm sure GIT can do this elegantly, but I'm not yet sure how. I guess
Ideally I want "git stash" at work, transfer the stashed changes to my
other machine and apply them. How do I do that?
Alternatively, I guess, one can commit at machine A, fetch the commit
from machine A and continue. I'm still too uncertain about the remote
access options to work this out properly, but it also feels less
clean.
How do you deal with this?
Thanks --- Jan
^ permalink raw reply
* [PATCH] mergetool: avoid misleading message "Resetting to default..."
From: Steffen Prohaska @ 2007-10-18 10:25 UTC (permalink / raw)
To: spearce; +Cc: git, Steffen Prohaska
In-Reply-To: <4591BA15-EB6B-4058-A2D0-879556481E59@zib.de>
If no mergetool is configured in the configuration variable
merge.tool the resetting message should not be printed.
This is fixed. The message is only printed if a tool is configured
but the entry in merge.tool is invalid.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-mergetool.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 94511f9..a68b403 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -334,7 +334,7 @@ init_merge_tool_path() {
if test -z "$merge_tool"; then
merge_tool=`git config merge.tool`
- if ! valid_tool "$merge_tool"; then
+ if test -n "$merge_tool" && ! valid_tool "$merge_tool"; then
echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
echo >&2 "Resetting to default..."
unset merge_tool
--
1.5.3.4.222.g2830
^ permalink raw reply related
* Re: [PATCH] Make the output of "git svn clone" less confusing.
From: Eric Wong @ 2007-10-18 10:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Kågedal, git
In-Reply-To: <20071018070617.GA29238@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> David Kågedal <davidk@lysator.liu.se> wrote:
> > The problem is that the first thing it prints is
> >
> > Initialized empty Git repository in .git/
> >
> > even if actually created a subdirectory and changed into it first. But to the
> > user, it looks like it is creating a .git/ dir in the directory he/she is
> > started git from.
>
> Eric, ack/nack?
Nack, here's (hopefully) a better patch.
David: agree/disagree?
From 62648d512a27a546707da160c939d665e6da57b4 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Thu, 18 Oct 2007 03:29:28 -0700
Subject: [PATCH] git-svn: make the output of "git svn clone" less confusing
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Original patch by David Kågedal:
> The problem is that the first thing it prints is
>
> Initialized empty Git repository in .git/
>
> even if actually created a subdirectory and changed into it
> first. But to the user, it looks like it is creating a .git/ dir
> in the directory he/she is started git from.
Instead of using a relative path, I'm capturing the
output of git-init and adding the absolute path to it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
I've actually just noticed that setting GIT_DIR= before running
git-svn clone is very broken, and I probably won't get a chance
to fix it for at least 24 hours (if I'm even awake)...
Johannes/Benoit/all: git-svn submodules will probably have to
wait till the weekend...
git-svn.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 777e436..4873bad 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3,6 +3,7 @@
# License: GPL v2 or later
use warnings;
use strict;
+use Cwd qw/getcwd/;
use vars qw/ $AUTHOR $VERSION
$sha1 $sha1_short $_revision
$_q $_authors %users/;
@@ -272,7 +273,9 @@ sub do_git_init_db {
push @init_db, "--shared";
}
}
- command_noisy(@init_db);
+ my $init_out = command(@init_db);
+ $init_out =~ s!(\.git)!getcwd . "/$1"!e;
+ print $init_out, "\n";
}
my $set;
my $pfx = "svn-remote.$Git::SVN::default_repo_id";
--
Eric Wong
^ permalink raw reply related
* Re: On Tabs and Spaces
From: Jari Aalto @ 2007-10-18 10:36 UTC (permalink / raw)
To: git
In-Reply-To: <20071018054246.GA9423@glandium.org>
* Thu 2007-10-18 Mike Hommey <mh@glandium.org> gmane.comp.version-control.git
* Message-Id: 20071018054246.GA9423@glandium.org
>> Any cross platform development or electronic exchange is guaranteed to
>> be interpreted correctly when policy enforces "only spaces"
>
> There is such problem with spaces. A lot of editors will just insert
> tabs to indent a new line when the previous you were typing begins with
> enough spaces, in which case you end up with spaces and tabs mixed all
> the way. It ends up being worse than all tabs.
There is "all-spaces", but there is no "all-tabs" choice.
The latter will always be mixture of "spaces and tabs". We have no
control how the tabs mix with spaces or vice versa: there could even be
"eight spaces" + proper tabs.
Speaking generalities (not the git project):
People can't be controlled, or their settings. Therefore there is a
policy and QA tools to monitor the issues and make things canonical;
whatever that is for the project.
Jari
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* Re: Howto request: going home in the middle of something?
From: Johannes Sixt @ 2007-10-18 10:37 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <200710181144.22655.wielemak@science.uva.nl>
Jan Wielemaker schrieb:
> I've somewhere seen it in a mail, but I can't find it anymore. I have a
> bare central (public) repository and clones on various machines I work
> on. We all know it, you're right in the middle of something and it is
> really time to go home. You want to pick up your work at home, but
> without pushing to the shared repository.
>
> I'm sure GIT can do this elegantly, but I'm not yet sure how. I guess
> Ideally I want "git stash" at work, transfer the stashed changes to my
> other machine and apply them. How do I do that?
One way is to use a bundle:
$ git checkout -b home
$ git bundle create home.bdl origin..home
Then put home.bdl on or USB stick or send by email. At home:
$ git fetch home.bdl home
$ git checkout -b to-be-continued FETCH_HEAD
You better make double sure that the commit "origin" that is used above is
available at home.
Judge yourself whether this is "elegant".
-- Hannes
^ permalink raw reply
* Re: Howto request: going home in the middle of something?
From: Karl Hasselström @ 2007-10-18 11:07 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jan Wielemaker, git
In-Reply-To: <4717377E.1010604@viscovery.net>
On 2007-10-18 12:37:50 +0200, Johannes Sixt wrote:
> Jan Wielemaker schrieb:
>
> > I've somewhere seen it in a mail, but I can't find it anymore. I
> > have a bare central (public) repository and clones on various
> > machines I work on. We all know it, you're right in the middle of
> > something and it is really time to go home. You want to pick up
> > your work at home, but without pushing to the shared repository.
> >
> > I'm sure GIT can do this elegantly, but I'm not yet sure how. I
> > guess Ideally I want "git stash" at work, transfer the stashed
> > changes to my other machine and apply them. How do I do that?
>
> One way is to use a bundle:
Another way is to push the unfinished changes to a temp branch, either
at the same central repository if it's acceptable for people to have
temp branches there, or at another repository where temp branches
_are_ permitted. All you need to set up a private repository for
yourself is an ssh account somewhere. Or you could store the
repository on an usb stick.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [BUG] git-svn not following svn moves
From: cho @ 2007-10-18 11:20 UTC (permalink / raw)
To: git
Hello,
I have a git-svn checkout that apparently did not follow a move correctly.
The files are not present in an svn checkout, but are in a git svn clone.
According to a trac browser, some of the files that appear in my git
checkout had in fact been moved to their separate branch before doing git-
svn clone. I noticed this when trying to commit changes to those files,
getting the error message:
> Le système de fichiers ne contient pas cet élément: Fichier non
trouvé : transaction '3926-1', chemin '.../composants.py' at /home/marc/
bin/git-svn line 2960
It's a standard subversion error, "Filesystem has no item"
I've made a clean checkout (with today's 1.5.3.4.206.g58ba4), and I still
have the moved files present.
The clone command is just:
git svn clone --stdlayout svn+ssh://host/srv/subversion/proj/appli/proj
Tell me if I can give more info (the repository isn't public).
^ permalink raw reply
* Re: Howto request: going home in the middle of something?
From: Petr Baudis @ 2007-10-18 11:27 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <200710181144.22655.wielemak@science.uva.nl>
Hi,
On Thu, Oct 18, 2007 at 11:44:22AM +0200, Jan Wielemaker wrote:
> I've somewhere seen it in a mail, but I can't find it anymore. I have a
> bare central (public) repository and clones on various machines I work
> on. We all know it, you're right in the middle of something and it is
> really time to go home. You want to pick up your work at home, but
> without pushing to the shared repository.
>
> I'm sure GIT can do this elegantly, but I'm not yet sure how. I guess
> Ideally I want "git stash" at work, transfer the stashed changes to my
> other machine and apply them. How do I do that?
>
> Alternatively, I guess, one can commit at machine A, fetch the commit
> from machine A and continue. I'm still too uncertain about the remote
> access options to work this out properly, but it also feels less
> clean.
this should be pretty simple assuming SSH access to machine A. Git can
fetch over SSH, so it's merely about telling it that repository X is
available over ssh over there and it'll fetch it home.
The exact setup depends on whether you want to do this just once or
semi-regularily. If the former, just
git pull git+ssh://a.machine.aero/absolute/path
Note that this should fetch only the remote master branch, if I'm not
mistaken.
If the latter, tell your home repository about your work repository:
git remote add workrepo git+ssh://a.machine.aero/absolute/path
Then, you can anytime just
git fetch workrepo
and it will fetch all the branches from workrepo; whether you want to
use git fetch and git merge or git pull depends on your local
arrangement of branches at home.
So, basically, when fetching you deal with your work repository
exactly the same way as in the shared repository.
When pushing, this is not so trivial. Git _allows_ you to just push to
your work repository, but if you push to a branch that is currently
checked out, unexpected things will happen - always avoid that. If you
can fetch from home at work, do. If not, at least push to a branch at
work that can never be checked out and is reserved for that purpose.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: Howto request: going home in the middle of something?
From: Andy Parkins @ 2007-10-18 11:29 UTC (permalink / raw)
To: git; +Cc: Jan Wielemaker
In-Reply-To: <200710181144.22655.wielemak@science.uva.nl>
On Thursday 2007 October 18, Jan Wielemaker wrote:
> I've somewhere seen it in a mail, but I can't find it anymore. I have a
> bare central (public) repository and clones on various machines I work
> on. We all know it, you're right in the middle of something and it is
> really time to go home. You want to pick up your work at home, but
> without pushing to the shared repository.
>
> I'm sure GIT can do this elegantly, but I'm not yet sure how. I guess
> Ideally I want "git stash" at work, transfer the stashed changes to my
> other machine and apply them. How do I do that?
>
> Alternatively, I guess, one can commit at machine A, fetch the commit
> from machine A and continue. I'm still too uncertain about the remote
> access options to work this out properly, but it also feels less
> clean.
>
> How do you deal with this?
I have two remotes (typically) in my .git/config. One for the real central
repository and one for the alternate computer. The two locations (say home
and work) list the other as a remote.
So; before I go home I do this:
git commit -b temp -a -m "Hold for transport home"
Then when I get home I do this:
git fetch work
git merge work/temp
git reset HEAD^
# code code code
git commit -b temp -a -m "Hold for transport to work"
When I'm finished at home and want to carry on at work:
git fetch --force home
git merge home/temp
git reset HEAD^
# start coding for the day
Obviously if you do this repeatedly you'd need to tidy up the left over temp
branches, or ensure that your remote configurations list "+" in the fetch
lines. You can also use pushes instead of fetches if you're that way
inclined, or you have a connection problem in one direction because of a
firewall.
It's slightly inelegant but it does ensure that nothing is ever accidentally
lost by overwriting new with newer, which happened a few times in the days
when I used rsync for copying the working directory between computers.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ 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