* Re: Newbie to git
From: Jorge Bastos @ 2009-12-28 22:23 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Junio C Hamano, git
In-Reply-To: <76c5b8580912280851k141bc6cev36df72b1993b8359@mail.gmail.com>
> Your /home/apache/gitprojects is a folder where your git repositories
> are supposed to be placed.
> Your Git repository = your project.
>
> By running a git daemon the way you do - you say that you are going to
> serve all repositories from /home/apache/gitprojects.
>
> Bare repo = repo without working copy - the one which contains only
> history and git objects (imagine it to be only .git folder from normal
> repo) Therefore for bare repos there is a naming convention so they
> have .git extension, while normal repo doesn't. So, myProject.git is
> server based bare repo, while myProject is a local repo.
>
> Finally you have /home/apache/gitprojects/myProject.git
>
> The URL to clone from there will be - should be shown to you by CGIT
> if you have everything correctly set up
> git://192.168.1.206/myProject.git
Lets see if i understood:
my steps:
git init --bare /home/apache/gitbare
cd /home/apache/gitprojects
mkdir project
cd project
git init myproject.git
on gitweb, i see the project names in this format:
"myproject.git/.git"
for example, for the git repo on git.kernel.org, it is shown as:
"git/git.git"
shouldn't it appear in the same way here?
i have:
$projectroot = "/home/apache/gitprojects/project/";
for CGIT, i have:
repo.path=/home/apache/gitprojects/project/myproject.git
but it doesn't show nothing after i click it.
on the other hand, i cannot push changes via remote, after cloned the
repository with:
git clone git://192.168.1.206/project/myproject.git
add some files
git add .
git commit -m "aaaa"
git push --tags "origin" master:master
and get:
error: unpack failed: unpack-objects abnormal exit
To git://192.168.1.206/project/myproject.git
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to
'git://192.168.1.206/project/myproject.git'
Failed
i feel i'm almost there but something is missing here... sorry my
newbienest!
^ permalink raw reply
* file in new branch also shown in master branch?
From: Carlos Santana @ 2009-12-28 22:37 UTC (permalink / raw)
To: git
Hi,
I tried following commands to test branching:
git branch test
git checkout test
echo "Test branch" >> testfile
git status
git checkout master
git add .
git commit
git push
The 'testfile' file shows up in 'master' as well as 'test'. I thought
it would be seen only in test branch, but it is not so. Is it normal
or am I missing something? I was unable to repeat same behavior again,
so I am confused now. Any clues?
-
CS.
^ permalink raw reply
* Re: file in new branch also shown in master branch?
From: David Aguilar @ 2009-12-28 23:25 UTC (permalink / raw)
To: Carlos Santana; +Cc: git
In-Reply-To: <92c9564e0912281437g20fe51f9ta33383791ef20385@mail.gmail.com>
On Mon, Dec 28, 2009 at 04:37:08PM -0600, Carlos Santana wrote:
> Hi,
>
> I tried following commands to test branching:
>
> git branch test
> git checkout test
1. You are now on branch "test"
> echo "Test branch" >> testfile
> git status
2. This does nothing as far as git is concerned.
"testfile" is still unknown to git.
> git checkout master
3. You are now on branch "master"
> git add .
> git commit
4. You just committed "testfile" to branch "master".
Recall #3. This may be where your confusion began.
> The 'testfile' file shows up in 'master' as well as 'test'. I thought
Nope, it only shows up in master.
try:
git checkout test
It is gone.
> or am I missing something? I was unable to repeat same behavior again,
> so I am confused now. Any clues?
These are great references:
http://book.git-scm.com/3_basic_branching_and_merging.html
http://progit.org/book/ch3-0.html
Have fun,
--
David
^ permalink raw reply
* config for merging master to test branch
From: Daniel Convissor @ 2009-12-28 23:38 UTC (permalink / raw)
To: Git Mailing List
Hello:
Here's my workflow...
testing directory (test branch)
[set origin to server repository]
git pull
git branch test
git checkout test
[edit settings files]
git commit ...
working directory (master branch)
[set origin to server repository]
[make changes]
git commit ...
git push origin master
Now, here's the question. I want to go back into the testing directory
and do a "git pull" and have the changes from master automatically merged
into my test branch in one step, without having to do an explicit set of
checkouts and merges. I get the impression there are configuration
settings that allow such to be done. Is my impression correct? If so,
what are the explicit configuration commands, please? Or is there some
command other than "pull" I should be using to do this?
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
^ permalink raw reply
* RE: Newbie to git
From: Shantanu Pavgi @ 2009-12-28 23:51 UTC (permalink / raw)
To: mysql.jorge@decimal.pt; +Cc: git@vger.kernel.org
In-Reply-To: <4e972734347b7ad47786807a7abe1c0e@192.168.1.222>
Jorge,
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..
Thanks,
Shantanu Pavgi.
________________________________________
From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] On Behalf Of Jorge Bastos [mysql.jorge@decimal.pt]
Sent: Monday, December 28, 2009 4:23 PM
To: Eugene Sajine
Cc: Junio C Hamano; git@vger.kernel.org
Subject: Re: Newbie to git
> Your /home/apache/gitprojects is a folder where your git repositories
> are supposed to be placed.
> Your Git repository = your project.
>
> By running a git daemon the way you do - you say that you are going to
> serve all repositories from /home/apache/gitprojects.
>
> Bare repo = repo without working copy - the one which contains only
> history and git objects (imagine it to be only .git folder from normal
> repo) Therefore for bare repos there is a naming convention so they
> have .git extension, while normal repo doesn't. So, myProject.git is
> server based bare repo, while myProject is a local repo.
>
> Finally you have /home/apache/gitprojects/myProject.git
>
> The URL to clone from there will be - should be shown to you by CGIT
> if you have everything correctly set up
> git://192.168.1.206/myProject.git
Lets see if i understood:
my steps:
git init --bare /home/apache/gitbare
cd /home/apache/gitprojects
mkdir project
cd project
git init myproject.git
on gitweb, i see the project names in this format:
"myproject.git/.git"
for example, for the git repo on git.kernel.org, it is shown as:
"git/git.git"
shouldn't it appear in the same way here?
i have:
$projectroot = "/home/apache/gitprojects/project/";
for CGIT, i have:
repo.path=/home/apache/gitprojects/project/myproject.git
but it doesn't show nothing after i click it.
on the other hand, i cannot push changes via remote, after cloned the
repository with:
git clone git://192.168.1.206/project/myproject.git
add some files
git add .
git commit -m "aaaa"
git push --tags "origin" master:master
and get:
error: unpack failed: unpack-objects abnormal exit
To git://192.168.1.206/project/myproject.git
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to
'git://192.168.1.206/project/myproject.git'
Failed
i feel i'm almost there but something is missing here... sorry my
newbienest!
^ permalink raw reply
* [PATCH 1/2] MinGW: Use pid_t more consequently, introduce uid_t for greater compatibility
From: Sebastian Schuberth @ 2009-12-29 1:18 UTC (permalink / raw)
To: git
MinGW: Use pid_t more consequently, introduce uid_t for greater compatibility
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
---
compat/mingw.h | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index b3d299f..af2f810 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -6,6 +6,7 @@
*/
typedef int pid_t;
+typedef int uid_t;
#define hstrerror strerror
#define S_IFLNK 0120000 /* Symbolic link */
@@ -75,17 +76,17 @@ static inline int symlink(const char *oldpath, const char *newpath)
{ errno = ENOSYS; return -1; }
static inline int fchmod(int fildes, mode_t mode)
{ errno = ENOSYS; return -1; }
-static inline int fork(void)
+static inline pid_t fork(void)
{ errno = ENOSYS; return -1; }
static inline unsigned int alarm(unsigned int seconds)
{ return 0; }
static inline int fsync(int fd)
{ return 0; }
-static inline int getppid(void)
+static inline pid_t getppid(void)
{ return 1; }
static inline void sync(void)
{}
-static inline int getuid()
+static inline uid_t getuid()
{ return 1; }
static inline struct passwd *getpwnam(const char *name)
{ return NULL; }
@@ -117,7 +118,7 @@ static inline int mingw_unlink(const char *pathname)
}
#define unlink mingw_unlink
-static inline int waitpid(pid_t pid, int *status, unsigned options)
+static inline pid_t waitpid(pid_t pid, int *status, unsigned options)
{
if (options == 0)
return _cwait(status, pid, 0);
@@ -158,7 +159,7 @@ int poll(struct pollfd *ufds, unsigned int nfds, int timeout);
struct tm *gmtime_r(const time_t *timep, struct tm *result);
struct tm *localtime_r(const time_t *timep, struct tm *result);
int getpagesize(void); /* defined in MinGW's libgcc.a */
-struct passwd *getpwuid(int uid);
+struct passwd *getpwuid(uid_t uid);
int setitimer(int type, struct itimerval *in, struct itimerval *out);
int sigaction(int sig, struct sigaction *in, struct sigaction *out);
int link(const char *oldpath, const char *newpath);
--
1.6.5.rc2.13.g1be2
^ permalink raw reply related
* [PATCH 2/2] MinGW: Add missing file mode bit defines
From: Sebastian Schuberth @ 2009-12-29 1:19 UTC (permalink / raw)
To: git
MinGW: Add missing file mode bit defines
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
---
compat/mingw.h | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index af2f810..885be51 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -12,12 +12,24 @@ typedef int uid_t;
#define S_IFLNK 0120000 /* Symbolic link */
#define S_ISLNK(x) (((x) & S_IFMT) == S_IFLNK)
#define S_ISSOCK(x) 0
+
+#ifndef _STAT_H_
+#define S_IRUSR 0
+#define S_IWUSR 0
+#define S_IXUSR 0
+#define S_IRWXU (S_IRUSR | S_IWUSR | S_IXUSR)
+#endif
#define S_IRGRP 0
#define S_IWGRP 0
#define S_IXGRP 0
-#define S_ISGID 0
+#define S_IRWXG (S_IRGRP | S_IWGRP | S_IXGRP)
#define S_IROTH 0
+#define S_IWOTH 0
#define S_IXOTH 0
+#define S_IRWXO (S_IROTH | S_IWOTH | S_IXOTH)
+#define S_ISUID 0
+#define S_ISGID 0
+#define S_ISVTX 0
#define WIFEXITED(x) 1
#define WIFSIGNALED(x) 0
--
1.6.5.rc2.13.g1be2
^ permalink raw reply related
* Re: [PATCH 0/4] clone: use --progress to mean -v
From: Junio C Hamano @ 2009-12-29 1:30 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: Johannes Schindelin, git, Miklos Vajna, Nicolas Pitre,
Junio C Hamano
In-Reply-To: <be6fef0d0912261927p4aff3ecet5cc26bd6dfc7e1c2@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> On Sat, Dec 26, 2009 at 4:53 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> On Sat, 26 Dec 2009, Tay Ray Chuan wrote:
>>
>>> This series makes git-clone follow the "argument convention" of
>>> git-pack-objects, where the option --progress is used to force reporting
>>> of reporting. This was previously done with -v/--verbose.
>>
>> No objections from my side, although you might want to advertise more that
>> this is a change in behavior. (Meaning in the release notes)
>
> Indeed, -v/--verbose to force reporting of progress was done sometime
> last year (Thu Oct 9 2008) so there may be scripts/applications
> dependent on this option.
>
> Junio, do you have any advice on this front?
[1/4] sounds like a sane thing to do regardless of the remainder of the
series, as stderr is where we write the progress output anyway. [2/4]
looks trivially correct.
It is unclear what impact [3/4] has. I can read "With this patch,
transport can pay attention to the verbose option given from the end user
and act more verbosely, which was not something they couldn't do before",
but what is the practical difference our existing users would see? IOW,
which transports are silent without this patch even when the user gives -v
from the command line?
And continuing the theme to separate the "verbosity" and the "progress"
into two separate switches, and push them down to the transport layer by
[3/4], [4/4] sounds like a logical conclusion.
I however wonder if it is of lessor impact if we only added --progress
but without removing the progress from -v. Is there a downside?
^ permalink raw reply
* Re: [PATCH 0/4] clone: use --progress to mean -v
From: Tay Ray Chuan @ 2009-12-29 3:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Johannes Schindelin, git, Miklos Vajna, Nicolas Pitre
In-Reply-To: <7vljgmpnxj.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, Dec 29, 2009 at 9:30 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tay Ray Chuan <rctay89@gmail.com> writes:
>
>> On Sat, Dec 26, 2009 at 4:53 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>> On Sat, 26 Dec 2009, Tay Ray Chuan wrote:
>>>
>>>> This series makes git-clone follow the "argument convention" of
>>>> git-pack-objects, where the option --progress is used to force reporting
>>>> of reporting. This was previously done with -v/--verbose.
>>>
>>> No objections from my side, although you might want to advertise more that
>>> this is a change in behavior. (Meaning in the release notes)
>>
>> Indeed, -v/--verbose to force reporting of progress was done sometime
>> last year (Thu Oct 9 2008) so there may be scripts/applications
>> dependent on this option.
>>
>> Junio, do you have any advice on this front?
>
> [1/4] sounds like a sane thing to do regardless of the remainder of the
> series, as stderr is where we write the progress output anyway. [2/4]
> looks trivially correct.
>
> It is unclear what impact [3/4] has. I can read "With this patch,
> transport can pay attention to the verbose option given from the end user
> and act more verbosely, which was not something they couldn't do before",
> but what is the practical difference our existing users would see? IOW,
> which transports are silent without this patch even when the user gives -v
> from the command line?
I know at least one transport which behaves in this manner (ie. silent
even when -v is supplied to git-clone), and that is the http (via
curl) transport.
> I however wonder if it is of lessor impact if we only added --progress
> but without removing the progress from -v. Is there a downside?
(Just to clarify: progress reporting will be done if stderr is a
terminal - it will be done even if -v or --progress isn't present.
What -v/--progress does is force progress reporting even if stderr is
not a terminal.)
Leaving -v as it is (ie. forcing progress reporting) while adding
--progress would be a "safe" option, as it won't break people's
existing setups (ie. those that depend on -v to force progress
reporting), which the patch series does. I have in mind IDEs/editors
that use this behaviour to monitor progress.
On the other hand, if we decide -v shouldn't imply forcing progress
reporting, then I think this breakable change should be made soon,
when only a small minority of git commands are affected (only one,
git-clone). That way, we don't give users/integrators the impression
that -v forces progress reporting with git commands. They won't get
annoyed when try -v to force progress reporting and find that it isn't
the case.
By the way, I got this "-v doesn't imply forced progress reporting"
rule from Jeff (added to Cc list), who mentioned it some time ago:
Date: Mon, 8 Jun 2009 07:54:31 -0400
From: Jeff King <peff@peff.net>
Subject: Re: [Patch] Prevent cloning over http from spewing
Message-ID: <20090608115431.GC13775@coredump.intra.peff.net>
I was imagining:
- without "-q", show progress if isatty(1).
- with "-q", never show progress
- with "-v", show the "getting pack" and "walk" output we show now;
without "-v", don't show it. "-v" has no impact on the progress
indicator.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE
From: Fyn Fynn @ 2009-12-29 6:47 UTC (permalink / raw)
To: git
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?
^ permalink raw reply
* [PATCH] Documentation: always respect core.worktree if set
From: Nguyễn Thái Ngọc Duy @ 2009-12-29 7:48 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin, Robin Rosenberg
Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <7viqbrv4pa.fsf@alter.siamese.dyndns.org>
The value of core.worktree in a ".git/config" is honored even when it
differs from the directory that has the ".git" directory as its
subdirectory. This is likely to be a misconfiguration, so warn users
about it. Also, drop the part of the documentation that incorrectly
claimed that we ignore such a misconfigured value.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/config.txt | 23 +++++++++++++++--------
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7d10a21..2eb9758 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -297,17 +297,24 @@ false), while all other repositories are assumed to be bare (bare
= true).
core.worktree::
- Set the path to the working tree. The value will not be
- used in combination with repositories found automatically in
- a .git directory (i.e. $GIT_DIR is not set).
+ Set the path to the root of the work tree.
This can be overridden by the GIT_WORK_TREE environment
variable and the '--work-tree' command line option. It can be
- a absolute path or relative path to the directory specified by
- --git-dir or GIT_DIR.
- Note: If --git-dir or GIT_DIR are specified but none of
+ an absolute path or a relative path to the .git directory,
+ either specified by --git-dir or GIT_DIR, or automatically
+ discovered.
+ If --git-dir or GIT_DIR are specified but none of
--work-tree, GIT_WORK_TREE and core.worktree is specified,
- the current working directory is regarded as the top directory
- of your working tree.
+ the current working directory is regarded as the root of the
+ work tree.
++
+Note that this variable is honored even when set in a configuration
+file in a ".git" subdirectory of a directory, and its value differs
+from the latter directory (e.g. "/path/to/.git/config" has
+core.worktree set to "/different/path"), which is most likely a
+misconfiguration. Running git commands in "/path/to" directory will
+still use "/different/path" as the root of the work tree and can cause
+great confusion to the users.
core.logAllRefUpdates::
Enable the reflog. Updates to a ref <ref> is logged to the file
--
1.6.5.2.216.g9c1ec
^ permalink raw reply related
* 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
* 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
* [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: 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
* 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: 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] 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: 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 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: [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: 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: 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
* 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: 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
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