* Re: is there an easier way to do this ?
From: Jacob Helwig @ 2008-12-30 4:00 UTC (permalink / raw)
To: git; +Cc: Zorba
In-Reply-To: <gjc5t2$g02$4@ger.gmane.org>
On Mon, Dec 29, 2008 at 19:51, Zorba <cr@altmore.co.uk> wrote:
> The manual shows you can SHOW untracked files, but not add them as part of
> the commit -a jig
>
> Seems a bit strange that git-add operates on both exisging and new files
> when used standalone, but its behaviour changes when encapsulated in
> commit -a...
>
> So, I thought maybe $ git commit -a, then $ git add .
> but then the files tracked have missed the commit boat they were meant to be
> on, haven't they,
>
> hang on -
> what about
>
> $ git add .
> $ git commit -a
>
> I do believe I've cracked it
> if so, it seems a bit wasteful, 2x adds (one explicti and one embedded
> in -a) ? shame on you linux kernel guys, i'd have expected better :-)
>
> "Zorba" <cr@altmore.co.uk> wrote in message
> news:gjc52u$ehc$4@ger.gmane.org...
>> ok, now I'm in this for real, archiving versions of our website project
>> (5k files approx)
>>
>> so here is the workflow:
>>
>> - copy version 1 files into GIT dir
>>
>> - open git bash
>>
>> $ git init
>>
>> $ git add .
>>
>> $ git commit -m "version1"
>>
>> all vanilla ? cool
>> next job = store version 2, so delete version 1 files from GIT dir, copy
>> in version 2
>> version2 has different files from 1 - which ones? Out of 5k files could be
>> 1% = 50 new ones, and same amount removed. Why should I care, with such a
>> powerful friend as git around, n'est pas?
>> THIS TIME we are going to be CLEVER and use "-a" flag on commit to pick up
>> any files that have been REMOVED (or "deleted" in git-speak)
>>
>> $ git commit -a -m "version2"
>>
>> BUT this does not pick up any new ones that have been added,
>>
>> and when we run
>>
>> $ git status > ../git_status.txt
>>
>> these are referred to as "untracked files"
>> only problem there are 50 ish
>> is there not another flag on git commit to treat any untracked file as a
>> new file ?
>> (would save me typing or creating a list out of these untracked ones and
>> feeding them into git add)
>>
>> I know, I realise now I should have looked up git-commit in the manual -
>> in case its not there, pls enlighten me !
>>
>>
>>
>
>
>
> --
> 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
>
If you do an explicit git add, then you don't need the -a on git
commit, since everything you want to commit will already be in the
index for git commit to work with.
^ permalink raw reply
* Re: is there an easier way to do this ?
From: Zorba @ 2008-12-30 3:51 UTC (permalink / raw)
To: git
In-Reply-To: <gjc52u$ehc$4@ger.gmane.org>
The manual shows you can SHOW untracked files, but not add them as part of
the commit -a jig
Seems a bit strange that git-add operates on both exisging and new files
when used standalone, but its behaviour changes when encapsulated in
commit -a...
So, I thought maybe $ git commit -a, then $ git add .
but then the files tracked have missed the commit boat they were meant to be
on, haven't they,
hang on -
what about
$ git add .
$ git commit -a
I do believe I've cracked it
if so, it seems a bit wasteful, 2x adds (one explicti and one embedded
in -a) ? shame on you linux kernel guys, i'd have expected better :-)
"Zorba" <cr@altmore.co.uk> wrote in message
news:gjc52u$ehc$4@ger.gmane.org...
> ok, now I'm in this for real, archiving versions of our website project
> (5k files approx)
>
> so here is the workflow:
>
> - copy version 1 files into GIT dir
>
> - open git bash
>
> $ git init
>
> $ git add .
>
> $ git commit -m "version1"
>
> all vanilla ? cool
> next job = store version 2, so delete version 1 files from GIT dir, copy
> in version 2
> version2 has different files from 1 - which ones? Out of 5k files could be
> 1% = 50 new ones, and same amount removed. Why should I care, with such a
> powerful friend as git around, n'est pas?
> THIS TIME we are going to be CLEVER and use "-a" flag on commit to pick up
> any files that have been REMOVED (or "deleted" in git-speak)
>
> $ git commit -a -m "version2"
>
> BUT this does not pick up any new ones that have been added,
>
> and when we run
>
> $ git status > ../git_status.txt
>
> these are referred to as "untracked files"
> only problem there are 50 ish
> is there not another flag on git commit to treat any untracked file as a
> new file ?
> (would save me typing or creating a list out of these untracked ones and
> feeding them into git add)
>
> I know, I realise now I should have looked up git-commit in the manual -
> in case its not there, pls enlighten me !
>
>
>
^ permalink raw reply
* Re: is there an easier way to do this ?
From: Jacob Helwig @ 2008-12-30 3:46 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjc52u$ehc$4@ger.gmane.org>
On Mon, Dec 29, 2008 at 19:37, Zorba <cr@altmore.co.uk> wrote:
> ok, now I'm in this for real, archiving versions of our website project (5k
> files approx)
>
> so here is the workflow:
>
> - copy version 1 files into GIT dir
>
> - open git bash
>
> $ git init
>
> $ git add .
>
> $ git commit -m "version1"
>
> all vanilla ? cool
> next job = store version 2, so delete version 1 files from GIT dir, copy in
> version 2
> version2 has different files from 1 - which ones? Out of 5k files could be
> 1% = 50 new ones, and same amount removed. Why should I care, with such a
> powerful friend as git around, n'est pas?
> THIS TIME we are going to be CLEVER and use "-a" flag on commit to pick up
> any files that have been REMOVED (or "deleted" in git-speak)
>
> $ git commit -a -m "version2"
>
> BUT this does not pick up any new ones that have been added,
>
> and when we run
>
> $ git status > ../git_status.txt
>
> these are referred to as "untracked files"
> only problem there are 50 ish
> is there not another flag on git commit to treat any untracked file as a new
> file ?
> (would save me typing or creating a list out of these untracked ones and
> feeding them into git add)
>
> I know, I realise now I should have looked up git-commit in the manual - in
> case its not there, pls enlighten me !
>
>
>
> --
> 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
>
git help add
Look at -A
^ permalink raw reply
* why still no empty directory support in git
From: Ping Yin @ 2008-12-30 3:42 UTC (permalink / raw)
To: Git Mailing List
Yes, i know this topic has been discussed for many times. However, i
am still not clear about the real reason.
So which is the reason?
1. it's by design, intentional
2. unclear logic, for example, whether to remove the directory after
the last file in it is deleted
3. hard work, no one has picked it yet
4. hardly done in current model
Ping Yin
^ permalink raw reply
* is there an easier way to do this ?
From: Zorba @ 2008-12-30 3:37 UTC (permalink / raw)
To: git
ok, now I'm in this for real, archiving versions of our website project (5k
files approx)
so here is the workflow:
- copy version 1 files into GIT dir
- open git bash
$ git init
$ git add .
$ git commit -m "version1"
all vanilla ? cool
next job = store version 2, so delete version 1 files from GIT dir, copy in
version 2
version2 has different files from 1 - which ones? Out of 5k files could be
1% = 50 new ones, and same amount removed. Why should I care, with such a
powerful friend as git around, n'est pas?
THIS TIME we are going to be CLEVER and use "-a" flag on commit to pick up
any files that have been REMOVED (or "deleted" in git-speak)
$ git commit -a -m "version2"
BUT this does not pick up any new ones that have been added,
and when we run
$ git status > ../git_status.txt
these are referred to as "untracked files"
only problem there are 50 ish
is there not another flag on git commit to treat any untracked file as a new
file ?
(would save me typing or creating a list out of these untracked ones and
feeding them into git add)
I know, I realise now I should have looked up git-commit in the manual - in
case its not there, pls enlighten me !
^ permalink raw reply
* [PATCH] Pass --upload-pack and --receive-pack through submodules.
From: Jason Riedy @ 2008-12-30 2:44 UTC (permalink / raw)
To: git; +Cc: Jason Riedy
While I no longer have to worry about a zillion ancient OS versions,
I now have to worry about a remote site where I cannot control the
path for non-interactive shells. Thus, submodules need to handle
explicitly specified git-upload-pack and git-receive-pack programs.
There may be a fun shell quoting dance to avoid the extra conditionals.
Any such dance would be even more confusing to read.
Signed-off-by: Jason Riedy <jason@acm.org>
---
git-submodule.sh | 81 +++++++++++++++++++++++++++++++++++++++--
t/t7404-submodule-packbin.sh | 53 +++++++++++++++++++++++++++
2 files changed, 130 insertions(+), 4 deletions(-)
create mode 100755 t/t7404-submodule-packbin.sh
diff --git a/git-submodule.sh b/git-submodule.sh
index 2f47e06..1a8a968 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -90,6 +90,8 @@ module_clone()
{
path=$1
url=$2
+ uploadpack=$3
+ receivepack=$4
# If there already is a directory at the submodule path,
# expect it to be empty (since that is the default checkout
@@ -105,8 +107,23 @@ module_clone()
test -e "$path" &&
die "A file already exist at path '$path'"
- git-clone -n "$url" "$path" ||
+ if test "$uploadpack"
+ then
+ git-clone --upload-pack $uploadpack -n "$url" "$path"
+ else
+ git-clone -n "$url" "$path"
+ fi ||
die "Clone of '$url' into submodule path '$path' failed"
+ if test "$uploadpack"
+ then
+ git config -f "${path}/.git/config" remote.origin.uploadpack "$uploadpack" ||
+ echo " Warn: Failed to set uploadpack for '$url' in submodule path '$path'."
+ fi
+ if test "$receivepack"
+ then
+ git config -f "${path}/.git/config" remote.origin.receivepack "$receivepack" ||
+ echo " Warn: Failed to set receivepack for '$url' in submodule path '$path'."
+ fi
}
#
@@ -130,6 +147,16 @@ cmd_add()
-q|--quiet)
quiet=1
;;
+ -u|--upload-pack)
+ case "$2" in '') usage ;; esac
+ uploadpack=$2
+ shift
+ ;;
+ --receive-pack)
+ case "$2" in '') usage ;; esac
+ receivepack=$2
+ shift
+ ;;
--)
shift
break
@@ -191,9 +218,17 @@ cmd_add()
;;
esac
git config submodule."$path".url "$url"
+ if test "$uploadpack"
+ then
+ git config submodule."$path".uploadpack "$uploadpack"
+ fi
+ if test "$receivepack"
+ then
+ git config submodule."$path".receivepack "$receivepack"
+ fi
else
- module_clone "$path" "$realrepo" || exit
+ module_clone "$path" "$realrepo" "$uploadpack" "$receivepack" || exit
(unset GIT_DIR; cd "$path" && git checkout -f -q ${branch:+-b "$branch" "origin/$branch"}) ||
die "Unable to checkout submodule '$path'"
fi
@@ -202,7 +237,19 @@ cmd_add()
die "Failed to add submodule '$path'"
git config -f .gitmodules submodule."$path".path "$path" &&
- git config -f .gitmodules submodule."$path".url "$repo" &&
+ git config -f .gitmodules submodule."$path".url "$repo" ||
+ die "Failed to register submodule '$path'"
+
+ if test "$uploadpack"
+ then
+ git config -f .gitmodules submodule."$path".uploadpack "$uploadpack" ||
+ die "Failed to register submodule '$path'"
+ fi
+ if test "$receivepack"
+ then
+ git config -f .gitmodules submodule."$path".receivepack "$receivepack" ||
+ die "Failed to register submodule '$path'"
+ fi
git add .gitmodules ||
die "Failed to register submodule '$path'"
}
@@ -277,6 +324,19 @@ cmd_init()
git config submodule."$name".url "$url" ||
die "Failed to register url for submodule path '$path'"
+ uploadpack=$(git config -f .gitmodules submodule."$name".uploadpack)
+ receivepack=$(git config -f .gitmodules submodule."$name".receivepack)
+ if test "$uploadpack"
+ then
+ git config submodule."$name".uploadpack "$uploadpack" ||
+ echo " Warn: Failed to set uploadpack for '$url' in submodule path '$path'."
+ fi
+ if test "$receivepack"
+ then
+ git config submodule."$name".receivepack "$receivepack" ||
+ echo " Warn: Failed to set receivepack for '$url' in submodule path '$path'."
+ fi
+
say "Submodule '$name' ($url) registered for path '$path'"
done
}
@@ -330,7 +390,8 @@ cmd_update()
if ! test -d "$path"/.git -o -f "$path"/.git
then
- module_clone "$path" "$url" || exit
+ module_clone "$path" "$url" "$(git config submodule."$name".uploadpack)" \
+ "$(git config submodule."$name".receivepack)" || exit
subsha1=
else
subsha1=$(unset GIT_DIR; cd "$path" &&
@@ -655,6 +716,18 @@ cmd_sync()
remote=$(get_default_remote)
say "Synchronizing submodule url for '$name'"
git config remote."$remote".url "$url"
+ uploadpack=$(git config -f .gitmodules submodule."$name".uploadpack)
+ receivepack=$(git config -f .gitmodules submodule."$name".receivepack)
+ if test "$uploadpack"
+ then
+ git config submodule."$name".uploadpack "$uploadpack" ||
+ echo " Warn: Failed to set uploadpack for '$url' in submodule path '$name'."
+ fi
+ if test "$receivepack"
+ then
+ git config submodule."$name".receivepack "$receivepack" ||
+ echo " Warn: Failed to set receivepack for '$url' in submodule path '$name'."
+ fi
)
fi
done
diff --git a/t/t7404-submodule-packbin.sh b/t/t7404-submodule-packbin.sh
new file mode 100755
index 0000000..d46b3e6
--- /dev/null
+++ b/t/t7404-submodule-packbin.sh
@@ -0,0 +1,53 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 E. Jason Riedy
+#
+
+test_description='git submodule with explicit pack programs
+
+These tests exercise git submodule with --upload-pack and --receive-pack arguments.
+'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo file > file &&
+ git add file &&
+ test_tick &&
+ git commit -m upstream
+ git clone . super &&
+ git clone super submodule &&
+ (cd super &&
+ git submodule add --upload-pack "${GIT_EXEC_PATH}/git-upload-pack" --receive-pack "${GIT_EXEC_PATH}/git-receive-pack" ../submodule submodule &&
+ test_tick &&
+ git commit -m "submodule"
+ ) &&
+ git clone super super-clone &&
+ (cd super-clone && git submodule update --init)
+'
+
+test_expect_success 'push submodule change' '
+ (cd super &&
+ cd submodule &&
+ git checkout master &&
+ echo second line >> file &&
+ test_tick &&
+ git commit -a -m "change submodule inside" &&
+ git push origin +master:pushed
+ )
+'
+
+test_expect_success 'pull submodule change' '
+ (cd submodule &&
+ git pull . pushed &&
+ echo second line >> file &&
+ test_tick &&
+ git commit -a -m "change submodule outside"
+ ) &&
+ (cd super &&
+ cd submodule &&
+ git pull origin master
+ )
+'
+
+test_done
--
1.6.0.2
^ permalink raw reply related
* Re: turn off "LF will be replaced by CRLF" thingy
From: Boyd Stephen Smith Jr. @ 2008-12-30 2:13 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjbr5k$r89$4@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
On Monday 29 December 2008, "Zorba" <cr@altmore.co.uk> wrote about 'Re:
turn off "LF will be replaced by CRLF" thingy':
>I'd like to be certain, as 500 out of 5000 files could just get changed
> here !
"git reset" will unstage all your changes. You can then issue another "git
add" to stage what you want, and see any warnings or errors.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: getting started, happy with cmd line on windows [Scanned]
From: Zorba @ 2008-12-30 1:22 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LNX.1.00.0812281326300.19665@iabervon.org>
Thanks Daniel, I'm not a tar man anyhow, so that would be one more thing to
learn.
So I'll pass, but someone else into unix will find this useful (maybe me, a
few mths down the track)
Believe it or not, I had budgeted half a day for getting git installed,
learned, and all the versions safely stowed away.
That was on Xmas eve (24th Dec.)
I've been on this every day since - gawd, its becoming an Odyssey.
SCM is a support to my software development, which is a support to my
business (a user business, not technology based) and iin a normal year (not
like this current one) would be <10% of our effort. I can sense the beauty
of git, but A WEEK ! to get close to making the first LIVE COMMIT.
I'm going to assert that a large number of possible users will not be
interested, or how shall I put it better, they'l be very interested in git,
but that's where it will stay. The blogosphere is littered with the burnt
bodies of those who have tried to ride this dragon. Gawd its tempting to
give up and install CVS or something, the only thing keeping me going is
that I HATE quitting !
What is it about this stuff ? I am not unintelligent but struggling with
this.
It seems like to do something simple you have to understand EVERYTHING -
its not like other systems with a clear set of "basic", "intermediate" and
"advanced" commands that are fairly standalone.
everything in git seems so interleaved - its like relativity, or nuclear
physics !
I'm sure git nirvana is coming sometiime for me,
gawd please may it be in this lifetime!
:-)
"Daniel Barkalow" <barkalow@iabervon.org> wrote in message
news:alpine.LNX.1.00.0812281326300.19665@iabervon.org...
> On Fri, 26 Dec 2008, Conor Rafferty wrote:
>
>> We want to use git to
>> a) archive old versions of our project that have till now had no SCM
>> applied
>
> There's actually an importer for this; if you can put all of the old
> versions into tar files in the same format and list them in order, you can
> use "import-tars.perl", which is in contrib/fast-import in the git source
> tree. Of course, using that won't teach you anything about the tools, but
> it might be the best way to get the real import done with the least chance
> of mistakes.
>
> -Daniel
> *This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Apply -p<value> on git-diffs that create/delete files
From: Andrew Ruder @ 2008-12-30 1:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The git_header_name checked the filenames given on the
"diff --git" line in a patch file. It never applied the
-p value. When applying a patch that deleted/created a file,
this unshortened default name was used as the old/new name.
Using this unshortened name as the old/new name resulted in
one of two incorrect results:
*) If the patch did not have the ---/+++ section
(creating/deleting an empty file, a simple mode change, etc.)
the patch would be applied to the unshortened name.
*) If the patch included the ---/+++ lines, the patch would fail
consistency checks in gitdiff_verify_name when the (shortened)
---/+++ filename didn't match the (unshortened)name grabbed off
the "diff --git" line.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
---
builtin-apply.c | 203 +++++++++++++++----------------------------------
t/t4120-apply-popt.sh | 5 +-
2 files changed, 64 insertions(+), 144 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 07244b0..584a910 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -315,7 +315,7 @@ static int name_terminate(const char *name, int namelen, int c, int terminate)
return 1;
}
-static char *find_name(const char *line, char *def, int p_value, int terminate)
+static char *find_name(const char *line, char *def, int p_value, int terminate, const char **endp)
{
int len;
const char *start = line;
@@ -327,7 +327,7 @@ static char *find_name(const char *line, char *def, int p_value, int terminate)
* Proposed "new-style" GNU patch/diff format; see
* http://marc.theaimsgroup.com/?l=git&m=112927316408690&w=2
*/
- if (!unquote_c_style(&name, line, NULL)) {
+ if (!unquote_c_style(&name, line, endp)) {
char *cp;
for (cp = name.buf; p_value; p_value--) {
@@ -363,6 +363,10 @@ static char *find_name(const char *line, char *def, int p_value, int terminate)
if (c == '/' && !--p_value)
start = line;
}
+
+ if (endp)
+ *endp = line;
+
if (!start)
return def;
len = line - start;
@@ -415,7 +419,7 @@ static int guess_p_value(const char *nameline)
if (is_dev_null(nameline))
return -1;
- name = find_name(nameline, NULL, 0, TERM_SPACE | TERM_TAB);
+ name = find_name(nameline, NULL, 0, TERM_SPACE | TERM_TAB, NULL);
if (!name)
return -1;
cp = strchr(name, '/');
@@ -464,16 +468,16 @@ static void parse_traditional_patch(const char *first, const char *second, struc
if (is_dev_null(first)) {
patch->is_new = 1;
patch->is_delete = 0;
- name = find_name(second, NULL, p_value, TERM_SPACE | TERM_TAB);
+ name = find_name(second, NULL, p_value, TERM_SPACE | TERM_TAB, NULL);
patch->new_name = name;
} else if (is_dev_null(second)) {
patch->is_new = 0;
patch->is_delete = 1;
- name = find_name(first, NULL, p_value, TERM_SPACE | TERM_TAB);
+ name = find_name(first, NULL, p_value, TERM_SPACE | TERM_TAB, NULL);
patch->old_name = name;
} else {
- name = find_name(first, NULL, p_value, TERM_SPACE | TERM_TAB);
- name = find_name(second, name, p_value, TERM_SPACE | TERM_TAB);
+ name = find_name(first, NULL, p_value, TERM_SPACE | TERM_TAB, NULL);
+ name = find_name(second, name, p_value, TERM_SPACE | TERM_TAB, NULL);
patch->old_name = patch->new_name = name;
}
if (!name)
@@ -497,7 +501,7 @@ static int gitdiff_hdrend(const char *line, struct patch *patch)
static char *gitdiff_verify_name(const char *line, int isnull, char *orig_name, const char *oldnew)
{
if (!orig_name && !isnull)
- return find_name(line, NULL, p_value, TERM_TAB);
+ return find_name(line, NULL, p_value, TERM_TAB, NULL);
if (orig_name) {
int len;
@@ -507,7 +511,7 @@ static char *gitdiff_verify_name(const char *line, int isnull, char *orig_name,
len = strlen(name);
if (isnull)
die("git apply: bad git-diff - expected /dev/null, got %s on line %d", name, linenr);
- another = find_name(line, NULL, p_value, TERM_TAB);
+ another = find_name(line, NULL, p_value, TERM_TAB, NULL);
if (!another || memcmp(another, name, len))
die("git apply: bad git-diff - inconsistent %s filename on line %d", oldnew, linenr);
free(another);
@@ -562,28 +566,28 @@ static int gitdiff_newfile(const char *line, struct patch *patch)
static int gitdiff_copysrc(const char *line, struct patch *patch)
{
patch->is_copy = 1;
- patch->old_name = find_name(line, NULL, 0, 0);
+ patch->old_name = find_name(line, NULL, 0, 0, NULL);
return 0;
}
static int gitdiff_copydst(const char *line, struct patch *patch)
{
patch->is_copy = 1;
- patch->new_name = find_name(line, NULL, 0, 0);
+ patch->new_name = find_name(line, NULL, 0, 0, NULL);
return 0;
}
static int gitdiff_renamesrc(const char *line, struct patch *patch)
{
patch->is_rename = 1;
- patch->old_name = find_name(line, NULL, 0, 0);
+ patch->old_name = find_name(line, NULL, 0, 0, NULL);
return 0;
}
static int gitdiff_renamedst(const char *line, struct patch *patch)
{
patch->is_rename = 1;
- patch->new_name = find_name(line, NULL, 0, 0);
+ patch->new_name = find_name(line, NULL, 0, 0, NULL);
return 0;
}
@@ -656,137 +660,57 @@ static const char *stop_at_slash(const char *line, int llen)
}
/*
- * This is to extract the same name that appears on "diff --git"
- * line. We do not find and return anything if it is a rename
- * patch, and it is OK because we will find the name elsewhere.
+ * This is to extract the same name that appears on "diff --git" line.
+ * The name that is returned also has the root applied to it and the
+ * p_value applied. We do not find and return anything if it is a
+ * rename patch, and it is OK because we will find the name elsewhere.
* We need to reliably find name only when it is mode-change only,
- * creation or deletion of an empty file. In any of these cases,
- * both sides are the same name under a/ and b/ respectively.
+ * creation or deletion of an empty file. In any of these cases, both
+ * sides are the same name under a/ and b/ respectively.
*/
-static char *git_header_name(char *line, int llen)
+static char *git_header_name(char *line)
{
- const char *name;
- const char *second = NULL;
- size_t len;
+ char *first = NULL, *second = NULL;
line += strlen("diff --git ");
- llen -= strlen("diff --git ");
- if (*line == '"') {
- const char *cp;
- struct strbuf first = STRBUF_INIT;
- struct strbuf sp = STRBUF_INIT;
+ /* First we grab the first name */
+ first = find_name(line, NULL, p_value, TERM_SPACE | TERM_TAB, (const char **)&second);
+ if (!first || !second)
+ goto error1;
- if (unquote_c_style(&first, line, &second))
- goto free_and_fail1;
+ /* Skip to the second name */
+ while (*second && isspace(*(second))) second++;
- /* advance to the first slash */
- cp = stop_at_slash(first.buf, first.len);
- /* we do not accept absolute paths */
- if (!cp || cp == first.buf)
- goto free_and_fail1;
- strbuf_remove(&first, 0, cp + 1 - first.buf);
-
- /*
- * second points at one past closing dq of name.
- * find the second name.
- */
- while ((second < line + llen) && isspace(*second))
- second++;
-
- if (line + llen <= second)
- goto free_and_fail1;
- if (*second == '"') {
- if (unquote_c_style(&sp, second, NULL))
- goto free_and_fail1;
- cp = stop_at_slash(sp.buf, sp.len);
- if (!cp || cp == sp.buf)
- goto free_and_fail1;
- /* They must match, otherwise ignore */
- if (strcmp(cp + 1, first.buf))
- goto free_and_fail1;
- strbuf_release(&sp);
- return strbuf_detach(&first, NULL);
- }
-
- /* unquoted second */
- cp = stop_at_slash(second, line + llen - second);
- if (!cp || cp == second)
- goto free_and_fail1;
- cp++;
- if (line + llen - cp != first.len + 1 ||
- memcmp(first.buf, cp, first.len))
- goto free_and_fail1;
- return strbuf_detach(&first, NULL);
-
- free_and_fail1:
- strbuf_release(&first);
- strbuf_release(&sp);
- return NULL;
- }
+ /* Grab the second name */
+ second = find_name(second, NULL, p_value, TERM_SPACE | TERM_TAB, NULL);
- /* unquoted first name */
- name = stop_at_slash(line, llen);
- if (!name || name == line)
- return NULL;
- name++;
+ /* Make sure they are relative paths or we return NULL */
+ if (!second || *second == '/' || *first == '/')
+ goto error2;
- /*
- * since the first name is unquoted, a dq if exists must be
- * the beginning of the second name.
- */
- for (second = name; second < line + llen; second++) {
- if (*second == '"') {
- struct strbuf sp = STRBUF_INIT;
- const char *np;
-
- if (unquote_c_style(&sp, second, NULL))
- goto free_and_fail2;
-
- np = stop_at_slash(sp.buf, sp.len);
- if (!np || np == sp.buf)
- goto free_and_fail2;
- np++;
-
- len = sp.buf + sp.len - np;
- if (len < second - name &&
- !strncmp(np, name, len) &&
- isspace(name[len])) {
- /* Good */
- strbuf_remove(&sp, 0, np - sp.buf);
- return strbuf_detach(&sp, NULL);
- }
+ /* First we see if they match, if they do, we are done. */
+ if (strcmp(first, second)) {
+ const char *first_slash, *second_slash;
+ /* If they don't, we check that we don't have a a/<match> b/<match>, if we
+ * do we return one of those so the error messages go through correctly
+ * later on */
+ first_slash = stop_at_slash(first, strlen(first));
+ second_slash = stop_at_slash(second, strlen(second));
- free_and_fail2:
- strbuf_release(&sp);
- return NULL;
- }
+ /* If this fails, it must be a rename, just return NULL */
+ if (!first_slash || !second_slash || strcmp(first_slash, second_slash))
+ goto error2;
}
- /*
- * Accept a name only if it shows up twice, exactly the same
- * form.
- */
- for (len = 0 ; ; len++) {
- switch (name[len]) {
- default:
- continue;
- case '\n':
- return NULL;
- case '\t': case ' ':
- second = name+len;
- for (;;) {
- char c = *second++;
- if (c == '\n')
- return NULL;
- if (c == '/')
- break;
- }
- if (second[len] == '\n' && !memcmp(name, second, len)) {
- return xmemdupz(name, len);
- }
- }
- }
+ free(second);
+ return first;
+
+error2:
+ free(second);
+error1:
+ free(first);
+ return NULL;
}
/* Verify that we recognize the lines following a git header */
@@ -804,14 +728,7 @@ static int parse_git_header(char *line, int len, unsigned int size, struct patch
* or removing or adding empty files), so we get
* the default name from the header.
*/
- patch->def_name = git_header_name(line, len);
- if (patch->def_name && root) {
- char *s = xmalloc(root_len + strlen(patch->def_name) + 1);
- strcpy(s, root);
- strcpy(s + root_len, patch->def_name);
- free(patch->def_name);
- patch->def_name = s;
- }
+ patch->def_name = git_header_name(line);
line += len;
size -= len;
diff --git a/t/t4120-apply-popt.sh b/t/t4120-apply-popt.sh
index 83d4ba6..ccba0b8 100755
--- a/t/t4120-apply-popt.sh
+++ b/t/t4120-apply-popt.sh
@@ -10,9 +10,12 @@ test_description='git apply -p handling.'
test_expect_success setup '
mkdir sub &&
echo A >sub/file1 &&
+ echo A >sub/file2 &&
cp sub/file1 file1 &&
- git add sub/file1 &&
+ cp sub/file2 file2 &&
+ git add sub/file1 sub/file2 &&
echo B >sub/file1 &&
+ rm sub/file2 &&
git diff >patch.file &&
rm sub/file1 &&
rmdir sub
--
1.6.1.1.g448a
^ permalink raw reply related
* Re: many git sites homepages megabytes big
From: Jakub Narebski @ 2008-12-30 1:07 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87r63r374j.fsf@jidanni.org>
jidanni@jidanni.org writes:
> I notice the web interfaces to many git sites are very risky to just
> click on. E.g., just clicking http://repo.or.cz/ sends megabytes to
> the users browser. At least the homepage of such sites should be
> something lighter in weight.
That is a bit of historical artifact. Currently the "index" page for
gitweb installation is 'projects_list' page with _all_ the projects
hosted. It is not split into pages, like for example 'log' or 'heads'
views are; there were some patches for that, but would have to be
redone as the area changed a bit since. It could have been replaced by
projects search page...
It is a bit of historical reason.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: turn off "LF will be replaced by CRLF" thingy
From: Zorba @ 2008-12-30 0:48 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.10.0812290928370.15026@asgard.lang.hm>
Hi David & thanks for helping me out,
So I tried again to do
$ git add .
this time no warnings about CRLF / LF, in fact no output, so not sure if it
did anything (though took some time to process)
$ git status
Shows all the files in the index ok, but I don't know if it was the first
git add or the second (post CRLF=false config change) that put them there
....
I'd like to be certain, as 500 out of 5000 files could just get changed here
!
I know I could just delete everything in .git dir, and git init again
But I'm after the intelligent way to do this :-(
<david@lang.hm> wrote in message
news:alpine.DEB.1.10.0812290928370.15026@asgard.lang.hm...
> On Mon, 29 Dec 2008, Zorba wrote:
>
>> Thanks Dmitry,
>>
>> So I have two options to do this - edit the files direct or issue a
>> command,
>> thank you !
>>
>> Now, my next problem is taking all my changes ($ git add . -> puts 5k
>> files
>> into index, with LF in place of CRLF) out of the index.
>>
>> Because I haven't committed anything in this repo yet...
>
> I think if you just do a git add . again it will put the files into the
> index without doing the conversion.
>
> David Lang
>
>> $ git reset --hard
>>
>> ....falls over, as it has no HEAD to reset to
>>
>> I think I read how to do this in a tutorial somewhere, maybe with
>> git-checkout, but I'm searching and can't find it.
>> Any kind soul can point me in the right direction ?
>>
>> thanks !
>> "Dmitry Potapov" <dpotapov@gmail.com> wrote in message
>> news:37fcd2780812290758q3ef989c0w5156da3098d06068@mail.gmail.com...
>>>> I'd rather not let git change any files, many of which are PHP that run
>>>> on
>>>> Apache
>>>> I think I remember reading that this is a config option that gets
>>>> swithced
>>>> on by default on windows (which we are running git on)
>>>>
>>>> how do I switch it off ?
>>>
>>> git config core.autocrlf false
>>>
>>> or if you want to ensure that all your text files have only LF then
>>>
>>> git config core.autocrlf input
>>>
>>> or if you want to disable conversion for some specific files then you
>>> can
>>> use 'crlf' attribute. See 'gitattributes' for more information.
>>> http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
>>>
>>> Dmitry
>>
>>
>>
>> --
>> 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
* git apply didn't catch error? [was Re: [PATCH] Documentation/diff-options.txt: unify options]
From: jidanni @ 2008-12-30 0:02 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7vabafe5ai.fsf@gitster.siamese.dyndns.org>
JCH> $ wget http://article.gmane.org/gmane.comp.version-control.git/104017/raw
JCH> $ git apply raw
JCH> error: diff-options.txt: No such file or directory
JCH> $ echo $?
JCH> 1
$ cd Documentation
$ git apply ../raw
$ echo $?
0
So then one thinks "why of course, the changes we already applied."
However if one makes some sneaky changes:
$ diff ../raw.original raw
46c46
< index 5721548..b05503a 100644
---
> index 6721548..c05503a 100644
70c70
< +-w::
---
> +-w::ZZZZZZZZZZZZZZZZZZ
One gets the same $?=0. git apply should scream instead of silently
returning 0 and doing nothing. git version 1.6.0.6.
^ permalink raw reply
* Re: "git-whatever" the new style vs. "git whatever"?
From: jidanni @ 2008-12-29 23:19 UTC (permalink / raw)
To: gitzilla; +Cc: bss, git, pape
In-Reply-To: <495940AD.2070602@gmail.com>
I swear we new users would have never guessed that git-whatever was
yes the new, but _deprecated_ style, until we asked on this newslist,
and today chucked Debian sid for Debian experimental, to see the
following. OK. Good to finally know. I feel sorry for all the Debian
Sid users who haven't heard the news and are putting the soon to break
form into their scripts and newsposts. Indeed, you on the mailing list
could point out to any users that what they just posted is going to
break soon.
Wait, e.g., git commit --help, man git-commit, etc. are still full of
the old notation here now in 1.6.0...
--- News for git-core (git-core git-email gitk) ---
git-core (1:1.6.0-1) experimental; urgency=low
Most of the programs are now installed outside the default $PATH,
except for "git", "gitk" and some server side programs that need
to be accessible for technical reasons. Invoking a git subcommand
as "git-xyzzy" from the command line has been deprecated since
early 2006 (and officially announced in the 1.5.4 release notes);
using the "git-xyzzy" form in scripts after adding the output from
"git --exec-path" to the $PATH is still supported in this release,
but users are again strongly encouraged to adjust their scripts to
use the "git xyzzy" form, as this support might be dropped in later
releases.
-- Gerrit Pape <pape@smarden.org> Sun, 24 Aug 2008 22:31:44 +0000
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Jeff Whiteside @ 2008-12-29 23:05 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gj6kqq$nvh$4@ger.gmane.org>
hi zorb,
you have done a great justice here to inadvertently explaining the
learning curve of git, through a few mistakes, especially for ppl
behind in their scm use. i enjoyed reading your blog posts though, as
they remind me of myself, not long ago.
you have a couple of mistakes i think you should correct.
-"Imagine a project with 4 versions, made up of various configurations
of the three files."
this line implies that you have branches (the word configurations).
you should be focusing, at first, on a project that has a set number
of files, and the content merely changes. ideally, you don't often
add and rm files across versions. also, the project doesn't really
have 4 versions, like windows has 4 different versions of vista, the
project has 3 old versions and 1 new version.
"Setup a git index in the project directory"
-this implies you're talking about the index. you're not. you're
talking about the repository. either make it clear that the index is
an intermediary staging area, or ignore its existence and change all
git-add && git-commit references to git-commit -a references. this
will ease the user of older scms into git.
-"Rollback to each of the versions, starting with version A"
this is bad. you're saying rollback. to others that have used scms,
this will mean, "retrieve an older copy", but in git, this is DELETING
all the versions after the version that you "rollback" to. your blog
post shouldn't discuss the git-reset --hard command at all, since
you're rewriting history, which is dangerous. afaik, most scms don't
allow you to rewrite history. to "rollback" to an older version you
should use checkout the git-checkout command. maybe the git reset
-–hard HEAD is okay to include... but it won't be immediately obvious
to new users why it does what it does... this nomenclature was likely
not the best choice whenever it was made.
gl with your gitting.
whiteside
u're talking sdf
On Sat, Dec 27, 2008 at 5:29 PM, Zorba <cr@altmore.co.uk> wrote:
>
> tidied up the formatting, added a few more comments where needed, fixed
> errors/lack of clarity
>
> "Zorba" <cr@altmore.co.uk> wrote in message
> news:gj68a0$u56$3@ger.gmane.org...
> > Here is a little exercise / tutorial / warm-up for someone starting out
> > with Git. If you're anyting like me you may find the tutorials etc. on
> > git.or.cz a bit daunting. I recommend you try this after reading the user
> > manual but before tearing your hair out trying to follow all the examples
> > in the user manual. After you've followed this simple workflow, then go
> > back to the more advanced stuff in the tutorials and user manuals (like
> > cloning repositories and creating and merging branches).
> >
> > I created this exercise to try and model our workflow and what we wanted
> > to use git for = tracking a project with multiple files where the filebase
> > might change frequently from one version to the next.
> >
> > http://siliconmouth.wordpress.com/category/nerdy/
> >
> > look for December 27, 2008 or "git warmup"
> >
> >
>
>
>
> --
> 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
* Re: git-add --verbose should say when something is already indexed
From: jidanni @ 2008-12-29 22:55 UTC (permalink / raw)
To: gitster; +Cc: nanako3, git
In-Reply-To: <7v63l3e4lz.fsf@gitster.siamese.dyndns.org>
DESCRIPTION
This command adds the current content of new or modified files to the index, thus staging that content for
inclusion in the next commit.
Maybe also mention that it also adds a new path to be tracked by the
index, if it is not tracked already.
^ permalink raw reply
* Re: [PATCH] Document git-ls-tree --full-tree
From: Markus Heidelberg @ 2008-12-29 22:36 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20081230071818.6117@nanako3.lavabit.com>
Nanako Shiraishi, 29.12.2008:
> diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
> 'git ls-tree' [-d] [-r] [-t] [-l] [-z]
> - [--name-only] [--name-status] [--full-name] [--abbrev=[<n>]]
> + [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev=[<n>]]
> <tree-ish> [paths...]
This can additionally be done in the usage array in the source.
Markus
^ permalink raw reply
* Re: "git-whatever" the new style vs. "git whatever"?
From: jidanni @ 2008-12-29 22:22 UTC (permalink / raw)
To: gitzilla; +Cc: bss, git
In-Reply-To: <495940AD.2070602@gmail.com>
>> That shouldn't be a problem for much longer because "git-whatever"
>> will stop working. From what I understand, "git whatever" has
>> always been the preferred form, and the fact that "git-whatever"
>> worked was just a implementation detail.
I thought if A worked from the start, and now B also works, you all
must have been moving to B, and so I made all my shell scripts use B.
ALAS> This is a revisionist history. Check the history of the git command to
ALAS> find out when it was created and then check the ML archives for
ALAS> related discussions.
All I know is we beginners just encounter both forms in the literature
and won't know about looking into whatever histories... and assumed until
this post that git-whatever was the new style! OK, now I know the truth.
^ permalink raw reply
* Re: rebase -i: learn to rebase root commit
From: Boyd Stephen Smith Jr. @ 2008-12-29 22:21 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <200812292249.45900.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]
On Monday 2008 December 29 15:49:42 Thomas Rast wrote:
> Thomas Rast wrote:
> > Teach git-rebase -i a new option --root, which instructs it to rebase
> > the entire history leading up to <branch>. This is mainly for
> > symmetry with ordinary git-rebase; it cannot be used to edit the root
> > commit in-place (it requires --onto).
>
> Actually, I forgot the "rebase -i -p" code path, which dies if --root
> is used with -p. Apologies.
>
> So for now, consider this broken and RFC: is there any sensible
> use/interpretation of -p --root that I'm missing? Or should it just
> disallow this combination?
Here's the interpretation that *I* come up with for -p --root used together:
The commit with no parents (OLD_ROOT) is rebased as if -p were not given, call
the resulting commit NEW_ROOT. Then, the rebase continues as if "--onto
NEW_ROOT OLD_ROOT <branch>" was specified instead of "--onto=NEW_ROOT^ --root
<branch>".
Basically, --root only changes how the first commit is handled, which I think
is consistent with other uses of --root. It's also similar to cherry-picking
the first commit, follwed by a non-root rebase, which I think is also
consistent with the intention of --root.
--
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
* [PATCH] Document git-ls-tree --full-tree
From: Nanako Shiraishi @ 2008-12-29 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Documentation/git-ls-tree.txt | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index 4c7262f..db6ebcc 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git ls-tree' [-d] [-r] [-t] [-l] [-z]
- [--name-only] [--name-status] [--full-name] [--abbrev=[<n>]]
+ [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev=[<n>]]
<tree-ish> [paths...]
DESCRIPTION
@@ -30,6 +30,8 @@ in the current working directory. Note that:
'sub/dir' in 'HEAD'). You don't want to give a tree that is not at the
root level (e.g. 'git ls-tree -r HEAD:sub dir') in this case, as that
would result in asking for 'sub/sub/dir' in the 'HEAD' commit.
+ However, the current working directory can be ignored by passing
+ --full-tree option.
OPTIONS
-------
@@ -66,6 +68,10 @@ OPTIONS
Instead of showing the path names relative to the current working
directory, show the full path names.
+--full-tree::
+ Do not limit the listing to the current working directory.
+ Implies --full-name.
+
paths::
When paths are given, show them (note that this isn't really raw
pathnames, but rather a list of patterns to match). Otherwise
--
1.6.1
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [PATCH 3/3] pretty: support multiline subjects with format:
From: René Scharfe @ 2008-12-29 22:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: markus.heidelberg, git
In-Reply-To: <4956C47B.4020602@lsrfire.ath.cx>
René Scharfe schrieb:
> Markus Heidelberg schrieb:
>> Sorry, I haven't tested your patch set, what is the output of
>> git-shortlog like now?
>
> It's unchanged since it has it's own commit message parser.
... which displays the first line of the commit message, unlike
--pretty=oneline. Here's a quick fix. I probably won't have time
to come up with something prettier this year.
René
builtin-shortlog.c | 9 ++++++---
pretty.c | 4 ++--
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index d03f14f..e492906 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -29,6 +29,9 @@ static int compare_by_number(const void *a1, const void *a2)
return -1;
}
+const char *format_subject(struct strbuf *sb, const char *msg,
+ const char *line_separator);
+
static void insert_one_record(struct shortlog *log,
const char *author,
const char *oneline)
@@ -41,6 +44,7 @@ static void insert_one_record(struct shortlog *log,
size_t len;
const char *eol;
const char *boemail, *eoemail;
+ struct strbuf subject = STRBUF_INIT;
boemail = strchr(author, '<');
if (!boemail)
@@ -89,9 +93,8 @@ static void insert_one_record(struct shortlog *log,
while (*oneline && isspace(*oneline) && *oneline != '\n')
oneline++;
len = eol - oneline;
- while (len && isspace(oneline[len-1]))
- len--;
- buffer = xmemdupz(oneline, len);
+ format_subject(&subject, oneline, " ");
+ buffer = strbuf_detach(&subject, NULL);
if (dot3) {
int dot3len = strlen(dot3);
diff --git a/pretty.c b/pretty.c
index 343dca5..421d9c5 100644
--- a/pretty.c
+++ b/pretty.c
@@ -486,8 +486,8 @@ static void parse_commit_header(struct format_commit_context *context)
context->commit_header_parsed = 1;
}
-static const char *format_subject(struct strbuf *sb, const char *msg,
- const char *line_separator)
+const char *format_subject(struct strbuf *sb, const char *msg,
+ const char *line_separator)
{
int first = 1;
^ permalink raw reply related
* Re: git svn rebase totally confused; just need some sorta reset
From: Boyd Stephen Smith Jr. @ 2008-12-29 22:04 UTC (permalink / raw)
To: davetron5000; +Cc: git
In-Reply-To: <cd7145c4-a4bb-4ef6-95db-7c4058b6774c@m16g2000vbp.googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]
On Monday 2008 December 29 15:39:45 davetron5000 wrote:
> Is there a way I can basically say: commit XXX is the same as the
> current HEAD of SVN, so treat things as if that's the case.
No, commits are immutable and their "name" is based on their contents.
However, if you've fetched the current HEAD of SVN, you've already got a
commit that corresponds (roughly) to the HEAD of SVN.
> i.e.
> treat things the same as if I had just done a clean git svn clone.
On my git-svn created repository, I have a special ref "git-svn" that appears
to refer to the "HEAD of SVN" commit. ("git branch -a" shows it.) If that's
also the case with you:
git branch -m master master.save
git checkout -b master git-svn
# Make sure you are seeing what you want.
git branch -D master.save
should get you to where you want.
Heck, "git reset git-svn" might work.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git svn rebase totally confused; just need some sorta reset
From: Jacob Helwig @ 2008-12-29 22:04 UTC (permalink / raw)
To: davetron5000; +Cc: git
In-Reply-To: <cd7145c4-a4bb-4ef6-95db-7c4058b6774c@m16g2000vbp.googlegroups.com>
On Mon, Dec 29, 2008 at 13:39, davetron5000 <davetron5000@gmail.com> wrote:
> So, my repo is in a weird state. I have committed my changes to svn
> via git svn dcommit, and it appears that the svn repository has all my
> changes.
>
> However, git svn rebase fails with conflicts, on almost every single
> commit I've made. I think that ultimately, I merged a branch in
> numerous times and git seems confused. BUT, I don't really care about
> preserving that; I just want my master branch to be clean.
>
> Is there a way I can basically say: commit XXX is the same as the
> current HEAD of SVN, so treat things as if that's the case. i.e.
> treat things the same as if I had just done a clean git svn clone.
>
> --
> 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
>
git checkout local-branch-you-want-to-fix
git reset --hard name-of-your-git-svn-branch (probably trunk, or
<prefix>/trunk, if you setup git-svn with the --prefix=<prefix>/
option).
This will wipe out anything you have in local-branch-you-want-to-fix,
and reset it to the same state that name-of-your-git-svn-branch is in.
-Jacob
^ permalink raw reply
* Re: rebase -i: learn to rebase root commit
From: Thomas Rast @ 2008-12-29 21:49 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <5d0be6d15bbdaa8b95c1df161b67ecd4120d7ce4.1230569041.git.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
Thomas Rast wrote:
> Teach git-rebase -i a new option --root, which instructs it to rebase
> the entire history leading up to <branch>. This is mainly for
> symmetry with ordinary git-rebase; it cannot be used to edit the root
> commit in-place (it requires --onto).
Actually, I forgot the "rebase -i -p" code path, which dies if --root
is used with -p. Apologies.
So for now, consider this broken and RFC: is there any sensible
use/interpretation of -p --root that I'm missing? Or should it just
disallow this combination?
[I also seem to manage to shoot myself with format-patch & topgit
every time, no matter how trivial the issue.]
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git svn rebase totally confused; just need some sorta reset
From: davetron5000 @ 2008-12-29 21:39 UTC (permalink / raw)
To: git
So, my repo is in a weird state. I have committed my changes to svn
via git svn dcommit, and it appears that the svn repository has all my
changes.
However, git svn rebase fails with conflicts, on almost every single
commit I've made. I think that ultimately, I merged a branch in
numerous times and git seems confused. BUT, I don't really care about
preserving that; I just want my master branch to be clean.
Is there a way I can basically say: commit XXX is the same as the
current HEAD of SVN, so treat things as if that's the case. i.e.
treat things the same as if I had just done a clean git svn clone.
^ permalink raw reply
* Re: "git-whatever" the new style vs. "git whatever"?
From: A Large Angry SCM @ 2008-12-29 21:27 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: jidanni, git
In-Reply-To: <200812291447.01713.bss@iguanasuicide.net>
Boyd Stephen Smith Jr. wrote:
> On Monday 2008 December 29 13:37:19 jidanni@jidanni.org wrote:
>> JCH> I think he is comparing "git am" and "git-am" the latter of which is
>> JCH> now deprecated and largely removed from the end user.
>>
>> By the way, we here at the end user end have a hard time detecting if
>> "git-whatever" the new style vs. "git whatever"...
>
> That shouldn't be a problem for much longer because "git-whatever" will stop
> working. From what I understand, "git whatever" has always been the
> preferred form, and the fact that "git-whatever" worked was just a
> implementation detail.
This is a revisionist history. Check the history of the git command to
find out when it was created and then check the ML archives for related
discussions.
^ 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