* Re: [PATCH] Add --path-prefix option to git-fast-import
From: Shawn O. Pearce @ 2009-12-29 15:08 UTC (permalink / raw)
To: Gisle Aas; +Cc: git, gitster, Gisle Aas
In-Reply-To: <1262091083-25401-1-git-send-email-gisle.aas@it.uib.no>
Gisle Aas <gisle.aas@it.uib.no> wrote:
> I found this useful when import multiple external repositories to be merged
> into a single git repo. Not having the files be renamed during the merge
> made it easier to follow the history of the individual files.
>
> Signed-off-by: Gisle Aas <gisle@aas.no>
> ---
> Documentation/git-fast-import.txt | 6 ++++++
> fast-import.c | 24 ++++++++++++++++++++++++
> 2 files changed, 30 insertions(+), 0 deletions(-)
Interesting. Test cases?
> +static const char *path_prefix_prepend(struct strbuf *sb, const char *p)
> +{
> + if (p != sb->buf) {
> + strbuf_reset(sb);
> + strbuf_addstr(sb, p);
> + }
I'd be a bit happier about the change if you could check not only
that p != sb->buf, but that p is not within sb->buf + sb->alloc.
I can't remember if all of the cases below are safe such that
any time you call the function with a p that p isn't pointing to
something within the strbuf you are handing in.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Wrap completions in `type git' conditional statement.
From: Shawn O. Pearce @ 2009-12-29 15:02 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Sung Pae, git
In-Reply-To: <20091229200530.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Junio, could you tell us what happened to this thread?
>
> The patch avoids failing completion script when git is not there.
> No discussion.
Actually, that's probably my fault. I never sent an ack or nak,
or anything else really, on this thread.
Originally this was because the completion was trying to run git
as it loaded. In 1.6.6 this is no longer true, the completion list
is generated lazily on demand during the first completion attempt.
With the lazy loading, I didn't see a reason to add this ugly block
around the entire script.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Smart-http: check if repository is OK to export before serving it
From: Shawn O. Pearce @ 2009-12-29 15:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tarmigan Casebolt, git
In-Reply-To: <7vy6kmjfwo.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Tarmigan Casebolt <tarmigan+git@gmail.com> writes:
>
> > Similar to how git-daemon checks whether a repository is OK to be
> > exported, smart-http should also check. This check can be satisfied
> > in two different ways: the environmental variable GIT_HTTP_EXPORT_ALL
> > may be set to export all repositories, or the individual repository
> > may have the file git-daemon-export-ok.
> >
> > Acked-by: Shawn O. Pearce <spearce@spearce.org>
...
> Looks sane to me, although I am afraid that I am not as familiar with the
> codepath involved as I should be. Shawn, is your Ack still good?
Yes, my ACK is still good. :-)
--
Shawn.
^ permalink raw reply
* Re: Help on CGIT
From: Felipe Contreras @ 2009-12-29 14:58 UTC (permalink / raw)
To: Jorge Bastos; +Cc: git
In-Reply-To: <31576a6d119e2edd66bd8bcc3281e9ad@192.168.1.222>
On Tue, Dec 29, 2009 at 2:18 PM, Jorge Bastos <mysql.jorge@decimal.pt> wrote:
> Am i missing something else? I've asked google but there's not much info
> on the web about it.
This is what I do:
ScriptAlias /cgit /var/www/cgit-files/cgit.cgi
You need a new cgit to use that properly, I use 0.8.3.
--
Felipe Contreras
^ permalink raw reply
* Re: Help on CGIT
From: Lars Hjemli @ 2009-12-29 14:57 UTC (permalink / raw)
To: Jorge Bastos; +Cc: git
In-Reply-To: <31576a6d119e2edd66bd8bcc3281e9ad@192.168.1.222>
On Tue, Dec 29, 2009 at 13:18, Jorge Bastos <mysql.jorge@decimal.pt> wrote:
> I have CGIT working at 50%.
>
> The 1st page show's correctly, but when i click the project name, it
> becames unconfigured and wierd, and apache complains about this:
>
> [Tue Dec 29 12:12:25 2009] [error] [client 192.168.1.3] [cgit] Unable to
> lock slot /var/cache/cgit/53200000.lock: No such file or directory (2)
First, check if cgit works correctly with caching disabled (set
cache-size=0 in /etc/cgitrc).
> My apache configuration for CGIT is:
>
> AllowOverride None
> Options ExecCGI
> Order allow,deny
> Allow from all
>
> DirectoryIndex cgit.cgi
>
> AddHandler cgi-script cgi pl
>
What's the contents of /etc/cgitrc? Which cgit-version are you running?
--
larsh
^ permalink raw reply
* Re: Help on CGIT
From: Jorge Bastos @ 2009-12-29 14:44 UTC (permalink / raw)
To: Luciano Rocha; +Cc: git
In-Reply-To: <20091229140842.GB6154@bit.office.eurotux.com>
On Tue, 29 Dec 2009 14:08:42 +0000, Luciano Rocha <luciano@eurotux.com>
>> Yap, with 777.
>> But the parent dirs don't, they have 755 the debian default, and both
>> /var
>> & /var/log owner by root.
>
> That's what they're supposed to be.
>
>> I also tryed to make /var & /var/log/ be owner by apache's user
>> (www-data)
>> but nothing, and also tried make them 777 aswell, the same.
>> This lock dir can't be configureable?
>
> Probably, don't know much about cgit. One thing, are you using selinux?
> What does sestatus show?
no SELinux compiled or active on kernel.
don't even have setools installed on the system.
I'm out of ideas :(
The info on the web about CGIT is rare... don't find an answer for this.
^ permalink raw reply
* Minor bug in bash completion
From: Sylvain RABOT @ 2009-12-29 14:36 UTC (permalink / raw)
To: spearce; +Cc: git
Hello,
I found a bug in the git bash completion.
It occurs when I press tab to complete branch name when I want to pull
from the origin.
Instead of completing the branch name it prompts me directly for my
password on the origin remote.
I pressed tab
here (just after mem)
|
srabot@khety:~/dev/ribeti.git[memcached]$ git pull origin
memsrabot@git.ps.agematis.loc's password:
srabot@git.ps.agematis.loc's password:
cached
srabot@git.ps.agematis.loc's password:
From git.ps.agematis.loc:/var/git/ribeti
* branch memcached -> FETCH_HEAD
Already up-to-date.
I'm using :
Linux khety 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:01:29 UTC 2009
i686 GNU/Linux
GNU bash, version 4.0.33(1)-release (i486-pc-linux-gnu)
git version 1.6.6
Best regards.
--
Sylvain
^ permalink raw reply
* Re: Help on CGIT
From: Luciano Rocha @ 2009-12-29 14:08 UTC (permalink / raw)
To: Jorge Bastos; +Cc: git
In-Reply-To: <9cf5f850c0c5ea8054e9bebc810ea6d3@192.168.1.222>
[-- Attachment #1: Type: text/plain, Size: 845 bytes --]
On Tue, Dec 29, 2009 at 12:38:15PM +0000, Jorge Bastos wrote:
> Hi Luciano,
>
> >> [Tue Dec 29 12:12:25 2009] [error] [client 192.168.1.3] [cgit] Unable
> to
> >> lock slot /var/cache/cgit/53200000.lock: No such file or directory (2)
> >
> > Does the directory /var/cache/cgit/ exist?
>
> Yap, with 777.
> But the parent dirs don't, they have 755 the debian default, and both /var
> & /var/log owner by root.
That's what they're supposed to be.
> I also tryed to make /var & /var/log/ be owner by apache's user (www-data)
> but nothing, and also tried make them 777 aswell, the same.
> This lock dir can't be configureable?
Probably, don't know much about cgit. One thing, are you using selinux?
What does sestatus show?
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] Add --path-prefix option to git-fast-import
From: Sverre Rabbelier @ 2009-12-29 14:06 UTC (permalink / raw)
To: Gisle Aas; +Cc: git, gitster, Gisle Aas
In-Reply-To: <1262091083-25401-1-git-send-email-gisle.aas@it.uib.no>
Heya,
On Tue, Dec 29, 2009 at 06:51, Gisle Aas <gisle.aas@it.uib.no> wrote:
> +static const char *path_prefix_prepend(struct strbuf *sb, const char *p)
> +{
> + if (p != sb->buf) {
> + strbuf_reset(sb);
> + strbuf_addstr(sb, p);
> + }
> + strbuf_insert(sb, 0, path_prefix, path_prefix_len);
> + return sb->buf;
> +}
> +
> static void file_change_m(struct branch *b)
> {
> const char *p = command_buf.buf + 2;
> @@ -1909,6 +1921,8 @@ static void file_change_m(struct branch *b)
> die("Garbage after path in: %s", command_buf.buf);
> p = uq.buf;
> }
> + if (path_prefix)
> + p = path_prefix_prepend(&uq, p);
You could reduce the size of this change by having path_prefix_prepend
check for path_prefix and just do nothing if it is not set.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] Add --path-prefix option to git-fast-import
From: Gisle Aas @ 2009-12-29 12:51 UTC (permalink / raw)
To: git; +Cc: gitster, Gisle Aas
From: Gisle Aas <gisle@aas.no>
I found this useful when import multiple external repositories to be merged
into a single git repo. Not having the files be renamed during the merge
made it easier to follow the history of the individual files.
Signed-off-by: Gisle Aas <gisle@aas.no>
---
Documentation/git-fast-import.txt | 6 ++++++
fast-import.c | 24 ++++++++++++++++++++++++
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 288032c..b8f9593 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -58,6 +58,12 @@ OPTIONS
Maximum number of branches to maintain active at once.
See ``Memory Utilization'' below for details. Default is 5.
+--path-prefix=<str>:
+ Prepend the given prefix to all the paths imported.
+ This can be used to import stuff into a subdirectory
+ of where the original files where located. Most likely
+ you want <str> to end with a slash.
+
--export-marks=<file>::
Dumps the internal marks table to <file> when complete.
Marks are written one per line as `:markid SHA-1`.
diff --git a/fast-import.c b/fast-import.c
index dd3c99d..32b0d70 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -351,6 +351,8 @@ static struct recent_command *rc_free;
static unsigned int cmd_save = 100;
static uintmax_t next_mark;
static struct strbuf new_data = STRBUF_INIT;
+static const char *path_prefix;
+static size_t path_prefix_len;
static void write_branch_report(FILE *rpt, struct branch *b)
{
@@ -1860,6 +1862,16 @@ static void load_branch(struct branch *b)
}
}
+static const char *path_prefix_prepend(struct strbuf *sb, const char *p)
+{
+ if (p != sb->buf) {
+ strbuf_reset(sb);
+ strbuf_addstr(sb, p);
+ }
+ strbuf_insert(sb, 0, path_prefix, path_prefix_len);
+ return sb->buf;
+}
+
static void file_change_m(struct branch *b)
{
const char *p = command_buf.buf + 2;
@@ -1909,6 +1921,8 @@ static void file_change_m(struct branch *b)
die("Garbage after path in: %s", command_buf.buf);
p = uq.buf;
}
+ if (path_prefix)
+ p = path_prefix_prepend(&uq, p);
if (S_ISGITLINK(mode)) {
if (inline_data)
@@ -1961,6 +1975,8 @@ static void file_change_d(struct branch *b)
die("Garbage after path in: %s", command_buf.buf);
p = uq.buf;
}
+ if (path_prefix)
+ p = path_prefix_prepend(&uq, p);
tree_content_remove(&b->branch_tree, p, NULL);
}
@@ -1984,6 +2000,8 @@ static void file_change_cr(struct branch *b, int rename)
strbuf_add(&s_uq, s, endp - s);
}
s = s_uq.buf;
+ if (path_prefix)
+ s = path_prefix_prepend(&s_uq, s);
endp++;
if (!*endp)
@@ -1996,6 +2014,8 @@ static void file_change_cr(struct branch *b, int rename)
die("Garbage after dest in: %s", command_buf.buf);
d = d_uq.buf;
}
+ if (path_prefix)
+ d = path_prefix_prepend(&d_uq, d);
memset(&leaf, 0, sizeof(leaf));
if (rename)
@@ -2523,6 +2543,10 @@ int main(int argc, const char **argv)
if (max_depth > MAX_DEPTH)
die("--depth cannot exceed %u", MAX_DEPTH);
}
+ else if (!prefixcmp(a, "--path-prefix=")) {
+ path_prefix = a + 14;
+ path_prefix_len = strlen(path_prefix);
+ }
else if (!prefixcmp(a, "--active-branches="))
max_active_branches = strtoul(a + 18, NULL, 0);
else if (!prefixcmp(a, "--import-marks="))
--
1.6.6.rc4.12.g269e7
^ permalink raw reply related
* Re: Help on CGIT
From: Luciano Rocha @ 2009-12-29 12:31 UTC (permalink / raw)
To: Jorge Bastos; +Cc: git
In-Reply-To: <31576a6d119e2edd66bd8bcc3281e9ad@192.168.1.222>
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
On Tue, Dec 29, 2009 at 12:18:38PM +0000, Jorge Bastos wrote:
> Howdy people,
>
> Since i cannot find any CGIT web interface mailing list on their webpage,
> i'm asking here.
>
> I have CGIT working at 50%.
>
> The 1st page show's correctly, but when i click the project name, it
> becames unconfigured and wierd, and apache complains about this:
>
> [Tue Dec 29 12:12:25 2009] [error] [client 192.168.1.3] [cgit] Unable to
> lock slot /var/cache/cgit/53200000.lock: No such file or directory (2)
Does the directory /var/cache/cgit/ exist?
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Help on CGIT
From: Jorge Bastos @ 2009-12-29 12:38 UTC (permalink / raw)
To: Luciano Rocha; +Cc: git
In-Reply-To: <20091229123127.GA6154@bit.office.eurotux.com>
Hi Luciano,
>> [Tue Dec 29 12:12:25 2009] [error] [client 192.168.1.3] [cgit] Unable
to
>> lock slot /var/cache/cgit/53200000.lock: No such file or directory (2)
>
> Does the directory /var/cache/cgit/ exist?
Yap, with 777.
But the parent dirs don't, they have 755 the debian default, and both /var
& /var/log owner by root.
I also tryed to make /var & /var/log/ be owner by apache's user (www-data)
but nothing, and also tried make them 777 aswell, the same.
This lock dir can't be configureable?
^ permalink raw reply
* Help on CGIT
From: Jorge Bastos @ 2009-12-29 12:18 UTC (permalink / raw)
To: git
Howdy people,
Since i cannot find any CGIT web interface mailing list on their webpage,
i'm asking here.
I have CGIT working at 50%.
The 1st page show's correctly, but when i click the project name, it
becames unconfigured and wierd, and apache complains about this:
[Tue Dec 29 12:12:25 2009] [error] [client 192.168.1.3] [cgit] Unable to
lock slot /var/cache/cgit/53200000.lock: No such file or directory (2)
My apache configuration for CGIT is:
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
DirectoryIndex cgit.cgi
AddHandler cgi-script cgi pl
Am i missing something else? I've asked google but there's not much info
on
the web about it.
Thanks,
Jorge,
^ permalink raw reply
* RE: Newbie to git
From: Jorge Bastos @ 2009-12-29 12:11 UTC (permalink / raw)
To: Shantanu Pavgi; +Cc: git
In-Reply-To: <540FAB030B18B14B8E672DB4B500635B1769FFD879@UABEXMBS6.ad.uab.edu>
> I remember having similar problem. I think it is with the user
> permissions. Check if the 'push-user' has read-write permissions on
public
> repo. Check out '--shared' option while initializing bare repo
(git-init
> --bare) or set appropriate permissions using chown/chmod. Hope this
helps..
Bingo!
Thank you,
Jorge,
^ permalink raw reply
* Re: Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE
From: Nguyen Thai Ngoc Duy @ 2009-12-29 11:36 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Fyn Fynn, git, Jeff King
In-Reply-To: <20091229200426.6117@nanako3.lavabit.com>
On 12/29/09, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
>
> > On 12/29/09, Fyn Fynn <fynfynn@gmail.com> wrote:
> >> The exact same git reset command that works in 1.6.4, fails to work
> >> under 1.6.6:
> >>
> >> $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
> >> /usr/local/git-1.6.6/bin/git reset --hard
> >> fatal: hard reset requires a work tree
> >> $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
> >> /usr/local/git-1.6.4/bin/git reset --hard
> >> HEAD is now at 77ec73f...
> >>
> >> What gives?
> >
> > A recent patch by Jeff (952dfc6 (reset: improve worktree safety valves
> > - 2009-12-04)) makes sure that "git reset --hard" will not work
> > outside worktree (which is right).
>
>
> Sorry, but I don't understand why it is *right*. Isn't 'git reset --hard' supposed to make all the files in the working tree match the HEAD, no matter where you start from?
It is generally "right" to work from inside worktree, the way Git
worked before GIT_WORK_TREE came. In case of "git reset --hard", yes
it'd be best if Git could just go to worktree and reset it. I forgot
that "git reset --hard" does not take pathspec. The situation may be a
bit more complicated with "git status" (which also handles worktree as
a whole) because you may need to represent the filename output to be
relative to current working directory, not the GIT_WORK_TREE. Using
GIT_WORK_TREE from outside worktree is imo stretching git to its
limits.
--
Duy
^ permalink raw reply
* Re: [PATCH] Wrap completions in `type git' conditional statement.
From: Nanako Shiraishi @ 2009-12-29 11:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sung Pae, git, spearce
In-Reply-To: <44A6FDEB-71B6-42E1-99E3-D6A595FF1B58@metablu.com>
Junio, could you tell us what happened to this thread?
The patch avoids failing completion script when git is not there.
No discussion.
^ permalink raw reply
* Re: [PATCH RFC v2] builtin-push: add --delete as syntactic sugar for :foo
From: Nanako Shiraishi @ 2009-12-29 11:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan Krüger, Git ML, Sverre Rabbelier
In-Reply-To: <20091109192044.605e50ba@perceptron>
Junio, could you tell us what happened to this thread?
The patch implements "git push repo --delete branch" and rejects
--delete used with other options like --all and --tags, as
suggested in the initial review. I think it makes sense, but
nothing happens after that.
^ permalink raw reply
* Re: Allowing push --dry-run through fetch url
From: Nanako Shiraishi @ 2009-12-29 11:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Mike Hommey
In-Reply-To: <7vfx8obz2o.fsf@alter.siamese.dyndns.org>
Junio, could you tell us what happened to this thread?
After discussing "git push --dry-run" that looks at URL used for
fetching, because pushURL might require authentication, the
maintainer recalls an earlier "git push --confirm" patch
http://thread.gmane.org/gmane.comp.version-control.git/128426/focus=128429
but nothing happens after that.
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Nanako Shiraishi @ 2009-12-29 11:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <d561e70f0aa802ceb96eba16d3bb2316134d69c8.1256062808.git.trast@student.ethz.ch>
Junio, could you tell us what happened to this thread?
The patch rejects "git pull repo A:B" because it is almost always a mistake;
I think it makes sense.
^ permalink raw reply
* Re: Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE
From: Nanako Shiraishi @ 2009-12-29 11:04 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Fyn Fynn, git, Jeff King
In-Reply-To: <fcaeb9bf0912290038u77a5e83cqe2f3cbfab05af263@mail.gmail.com>
Quoting Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
> On 12/29/09, Fyn Fynn <fynfynn@gmail.com> wrote:
>> The exact same git reset command that works in 1.6.4, fails to work
>> under 1.6.6:
>>
>> $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>> /usr/local/git-1.6.6/bin/git reset --hard
>> fatal: hard reset requires a work tree
>> $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>> /usr/local/git-1.6.4/bin/git reset --hard
>> HEAD is now at 77ec73f...
>>
>> What gives?
>
> A recent patch by Jeff (952dfc6 (reset: improve worktree safety valves
> - 2009-12-04)) makes sure that "git reset --hard" will not work
> outside worktree (which is right).
Sorry, but I don't understand why it is *right*. Isn't 'git reset --hard' supposed to make all the files in the working tree match the HEAD, no matter where you start from?
Jeff's commit message says:
make sure we are in a worktree. Otherwise, we can end up
munging files inside of '.git'
But if you have ~/myproject/.git project, whose working tree is ~/myproject, and if you run
% cd ~/myproject/.git
% git reset --hard
the code mistakenly overwrote files in ~/myproject/.git directory before Jeff's patch, and I agree it was a bug.
But shouldn't the correct fix be to go to ~/myproject, the obvious root level of the working tree, and check out the files in that directory?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Smart-http: check if repository is OK to export before serving it
From: Junio C Hamano @ 2009-12-29 9:19 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: git, spearce
In-Reply-To: <1262036940-9678-1-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> writes:
> Similar to how git-daemon checks whether a repository is OK to be
> exported, smart-http should also check. This check can be satisfied
> in two different ways: the environmental variable GIT_HTTP_EXPORT_ALL
> may be set to export all repositories, or the individual repository
> may have the file git-daemon-export-ok.
>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
> ---
> OK, I see what you're saying Shawn. I've changed it back to "404
> Not Found" again.
>
> I've also reordered the new tests since the last time I sent it out.
> The new tests use the same test as in
> "static file is ok"
> so put the new tests after that test in case that test breaks.
Looks sane to me, although I am afraid that I am not as familiar with the
codepath involved as I should be. Shawn, is your Ack still good?
^ permalink raw reply
* Re: Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE
From: Nguyen Thai Ngoc Duy @ 2009-12-29 8:38 UTC (permalink / raw)
To: Fyn Fynn; +Cc: git, Jeff King
In-Reply-To: <1a04eebf0912282247p6975a96el8076cb39378bd104@mail.gmail.com>
On 12/29/09, Fyn Fynn <fynfynn@gmail.com> wrote:
> The exact same git reset command that works in 1.6.4, fails to work
> under 1.6.6:
>
> $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
> /usr/local/git-1.6.6/bin/git reset --hard
> fatal: hard reset requires a work tree
> $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
> /usr/local/git-1.6.4/bin/git reset --hard
> HEAD is now at 77ec73f...
>
> What gives?
A recent patch by Jeff (952dfc6 (reset: improve worktree safety valves
- 2009-12-04)) makes sure that "git reset --hard" will not work
outside worktree (which is right). Where was your current directory,
inside $GIT_WORK_TREE or outside?
--
Duy
^ permalink raw reply
* [PATCH] t7102: make the test fail if one of its check fails
From: Nguyễn Thái Ngọc Duy @ 2009-12-29 8:13 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
t/t7102-reset.sh | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index e85ff02..b8cf260 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -139,19 +139,19 @@ test_expect_success \
test_expect_success \
'resetting to HEAD with no changes should succeed and do nothing' '
git reset --hard &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc &&
git reset --hard HEAD &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc &&
git reset --soft &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc &&
git reset --soft HEAD &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc &&
git reset --mixed &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc &&
git reset --mixed HEAD &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc &&
git reset &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc &&
git reset HEAD &&
check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
'
--
1.6.5.2.216.g9c1ec
^ permalink raw reply related
* Re: Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE
From: Tay Ray Chuan @ 2009-12-29 8:12 UTC (permalink / raw)
To: Fyn Fynn; +Cc: git
In-Reply-To: <1a04eebf0912282247p6975a96el8076cb39378bd104@mail.gmail.com>
Hi,
On Tue, Dec 29, 2009 at 2:47 PM, Fyn Fynn <fynfynn@gmail.com> wrote:
> The exact same git reset command that works in 1.6.4, fails to work
> under 1.6.6:
>
> $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
> /usr/local/git-1.6.6/bin/git reset --hard
> fatal: hard reset requires a work tree
> $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
> /usr/local/git-1.6.4/bin/git reset --hard
> HEAD is now at 77ec73f...
>
> What gives?
perhaps you should also specify the --exec-path option or
GIT_EXEC_PATH environment variable.
Assuming a full installation in /usr/local/git-1.6.6/ and thus that
the git commands are installed at
/usr/local/git-1.6.6/libexec/git-core/, the reset for 1.6.6 would look
like this:
$ GIT_WORK_TREE=$HOME/rawdata/ \
GIT_DIR=$HOME/rawdata/.git \
GIT_EXEC_PATH=/usr/local/git-1.6.6/libexec/git-core/ \
/usr/local/git-1.6.6/bin/git reset --hard
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] Documentation: commit: explain the non-meaning of S-o-b
From: Junio C Hamano @ 2009-12-29 7:54 UTC (permalink / raw)
To: Jan Krüger; +Cc: Git ML
In-Reply-To: <20091228194001.7b4c68f4@perceptron>
Jan Krüger <jk@jk.gs> writes:
> In the manpage for git commit, the option --signoff is mentioned but
> there is no explanation of what it actually means. Add a brief hint that
> S-o-b doesn't have a pre-defined meaning.
The commands am, cherry-pick, commit, format-patch, and revert all share
the "sign-off" and they more or less deliberately refused to define what
it means to sign-off a patch; as your patch says, it is up to the project
policy.
config.txt gives a description for format.signoff option that is too
specific to git and the kernel, which I think is a mistake given the much
wider audience we have these days.
How similar should the document for the "sign-off" options to these
commands be? I am wondering if we should have the same description copied
and pasted to all of them, or avoid repeating ourselves and instead have
them refer to a central place, perhaps somewhere in the Tutorial or the
Workflow document.
> Signed-off-by: Jan Krüger <jk@jk.gs>
> ---
> Semi-resend. Nobody commented on this when I first sent it in early
> December, so here it is again, with a slightly more verbose
> explanation. The repetition is intentional.
>
> Documentation/git-commit.txt | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index d227cec..cae510b 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -114,7 +114,10 @@ OPTIONS
> -s::
> --signoff::
> Add Signed-off-by line by the committer at the end of the commit
> - log message.
> + log message. This line has no inherent meaning; it is up to the
> + potential recipient of the commit to decide what it stands for.
> + It is typically understood as an assurance by the committer that
> + the commit conforms to the receiving project's commit guidelines.
>
> -n::
> --no-verify::
> --
> 1.6.5.3.171.ge36e
^ 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