* Re: [PATCH] mergetool merge/skip/abort
From: Johannes Schindelin @ 2009-01-21 16:33 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0901210817r49971c09kea9dc8ee5ae21572@mail.gmail.com>
Hi,
On Wed, 21 Jan 2009, Caleb Cushing wrote:
> just a typo fix in the patch
>
> >From 29c2873861a3aec8304529735307385e9e5c248a Mon Sep 17 00:00:00 2001
> From: Caleb Cushing <xenoterracide@gmail.com>
> Date: Tue, 20 Jan 2009 11:33:30 -0500
> Subject: [PATCH] mergetool merge/skip/abort
> add functionality to skip merging a file or abort from the merge
>
> ---
If you look at other patch submissions, you will find that they all do it
differently. You will never see a "Date:" or "Subject:" line. You will
see a much shorter commit subject. And a more verbose commit message.
Sometimes, you will see that a commit message is not quite informative, or
does not explain the _motivation_ why it should be a good idea to do what
the patch does, and me saying so very directly (but never meaning to
offend).
Hth,
Dscho
^ permalink raw reply
* Re: how to git a read only directory
From: Boaz Harrosh @ 2009-01-21 16:46 UTC (permalink / raw)
To: Boaz Harrosh, git
In-Reply-To: <20090121155256.GB6966@b2j>
bill lam wrote:
> On Wed, 21 Jan 2009, Boaz Harrosh wrote:
>> I created a master project folder under ~home, init a new git repo,
>> then symlink /etc/ onto an etc/ in the project dir, added all etc/
>> files. I like the extra a/etc/fstab in the patch files better then
>> a/fstab.
>
> I create a symlink in ~/gitrepo/etc to /etc and git init an empty repo
> there. However it failed in symlink when I tried to add files. Could
> you give more detail how to do it? Meanwhile I use worktree method as
> suggested by Michael.
>
What? I don't know this is what I did:
[~] $ mkdir gitrepo; cd gitrepo
[gitrepo] $ git-init
[gitrepo] $ ln -s /etc
[gitrepo] $ git-add /etc/fstab
[gitrepo] $ git-commit -s
Edit commit message in editor
[gitrepo] $ git-show
commit fd6a4a72bf91526b56528f4036c525f6d6fd3dc0
Author: Boaz Harrosh <bharrosh@panasas.com>
Date: Wed Jan 21 18:36:58 2009 +0200
{REMOVEME} etc/fstab test
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
diff --git a/etc/fstab b/etc/fstab
new file mode 100644
index 0000000..2e3f8d3
--- /dev/null
+++ b/etc/fstab
@@ -0,0 +1,18 @@
+LABEL=/fc7 / ext3 noatime 1 1
+LABEL=/usr0 /usr0 ext3 noatime 1 2
+LABEL=/boot /boot ext2 noatime 1 2
+LABEL=/fc10 /alt ext3 defaults 1 2
+tmpfs /dev/shm tmpfs defaults 0 0
+devpts /dev/pts devpts gid=5,mode=620 0 0
+sysfs /sys sysfs defaults 0 0
+proc /proc proc defaults 0 0
+LABEL=SWAP-sda7 swap swap defaults 0 0
+panstor:/main /mnt/panstor nfs soft,intr,rsize=65536,wsize=65536 0 0
<... snip ...>
So in short I did nothing. I have git 1.6.0.1
Boaz
^ permalink raw reply related
* git diff, git mergetool and CRLF conversion
From: Hannu Koivisto @ 2009-01-21 16:55 UTC (permalink / raw)
To: git
Hi,
Suppose I have core.autocrlf set to true and and due to that a
version controlled file in a working tree with CRLF line endings.
If I modify such a file and then say "git diff", I get a patch with
LF line endings.
Also, if get a merge conflict with a file to which CRLF conversion
is applied and run e.g. "git mergetool -t emerge", the temporary
files representing stage2 and stage3 versions seem to have LF line
endings.
Is this intended behaviour? I'm using 1.6.1 on Cygwin.
--
Hannu
^ permalink raw reply
* git gui browser documentation bug
From: Hannu Koivisto @ 2009-01-21 17:12 UTC (permalink / raw)
To: git
Hi,
git-gui(1) says:
browser
Start a tree browser showing all files in the specified commit
(or HEAD by default).
However, if I try to run it with just "git gui browser", it doesn't
start (Cygwin, 1.6.1) or says "usage:
/usr/local/libexec/git-core/git-gui browser rev? path" (Linux,
1.6.1.28.gc32f76) -- I have to say "git gui browser HEAD".
--
Hannu
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Charles Bailey @ 2009-01-21 17:04 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0901210637j52fa7a55q51b599e9ff16f6dc@mail.gmail.com>
On Wed, Jan 21, 2009 at 09:37:20AM -0500, Caleb Cushing wrote:
> ---
> git-mergetool.sh | 24 ++++++++++++++++++++----
> 1 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index 00e1337..43d2a9e 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -177,11 +177,27 @@ merge_file () {
> describe_file "$local_mode" "local" "$LOCAL"
> describe_file "$remote_mode" "remote" "$REMOTE"
> if "$prompt" = true; then
> - printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
> - read ans
> - fi
> + while true; do
> + printf "Use (m)erge file or (s)skip file, or (a)bort? (%s): " \
> + "$merge_tool"
> + read ans
> + case "$ans" in
> + [mM]*)
> + break
> + ;;
> + [sS]*)
> + cleanup_temp_files
> + return 0
> + ;;
> + [aA]*)
> + cleanup_temp_files
> + exit 0
> + ;;
> + esac
> + done
> + fi
This looks to me like no merge will happen if --no-prompt/-y or
mergetool.prompt is set to false. Have you tested with this option or
have I misread?
Also, I think you've lost some tabs. Mergetool does have some
inconsistent tabbing but they way I've been aiming towards (which
matches most, but not all of git-mergetool.sh) is to use tabs == 8
spaces for indents but to indent each level by 4 spaces. e.g. three
levels of indent is one tab plus four spaces.
It might be quite nice to offer the option of directly using an 'ours'
or 'theirs' as an alternative to skip for binary files. A bit like
symlinks are handled in mergetool.
Charles.
^ permalink raw reply
* Re: git diff, git mergetool and CRLF conversion
From: Charles Bailey @ 2009-01-21 17:23 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83k58ofvjt.fsf@kalahari.s2.org>
On Wed, Jan 21, 2009 at 06:55:34PM +0200, Hannu Koivisto wrote:
> Hi,
>
> Suppose I have core.autocrlf set to true and and due to that a
> version controlled file in a working tree with CRLF line endings.
> If I modify such a file and then say "git diff", I get a patch with
> LF line endings.
>
> Also, if get a merge conflict with a file to which CRLF conversion
> is applied and run e.g. "git mergetool -t emerge", the temporary
> files representing stage2 and stage3 versions seem to have LF line
> endings.
>
> Is this intended behaviour? I'm using 1.6.1 on Cygwin.
Speaking for mergetool, I believe that it's simply because mergetool
uses git cat-file which just outputs the raw contents of a blob and
doesn't do any line ending conversion.
IMHO, I think that it should probably perform the 'convert to working
tree format' change when preparing the temporary files. I'm not sure
how best to do that, but perhaps it should be using git checkout-index
with the --temp option instead of cat-file.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* cherry-pick/rebase question
From: Jay Soffian @ 2009-01-21 17:27 UTC (permalink / raw)
To: Git Mailing List
Say I have the following linear set of commits on master:
A---B---C---D---E---F---G master
And I realize that I've intermixed two topics such that I want to move
commits B and E-G to their own branch. So my result should be:
A---C'---D' master
\
B'---E'---F'---G' topic
What's the best way to do it?
I read the rebase and cherry-pick man pages, found myself confused,
tried rebase a few different ways, failed, and ended up doing what I
needed with format-patch and am. (Extract B-G with format-patch, reset
master to A, create topic branch, apply B,E,F,G to topic with am,
similarly apply C,D to master with am.)
Thanks,
j.
^ permalink raw reply
* Re: cherry-pick/rebase question
From: Jay Soffian @ 2009-01-21 17:46 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <76718490901210927m7fd3fbdey6ebd4cbfe44b1b71@mail.gmail.com>
On Wed, Jan 21, 2009 at 12:27 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> Say I have the following linear set of commits on master:
>
> A---B---C---D---E---F---G master
>
> And I realize that I've intermixed two topics such that I want to move
> commits B and E-G to their own branch. So my result should be:
>
> A---C'---D' master
> \
> B'---E'---F'---G' topic
>
> What's the best way to do it?
>
> I read the rebase and cherry-pick man pages, found myself confused,
> tried rebase a few different ways, failed, and ended up doing what I
> needed with format-patch and am. (Extract B-G with format-patch, reset
> master to A, create topic branch, apply B,E,F,G to topic with am,
> similarly apply C,D to master with am.)
Hmm, not sure why I didn't think of it earlier, but I guess the easiest way is:
(master)$ git co -b topic
(topic )$ git rebase -i A (remove C and D)
(topic )$ git co master
(master)$ git rebase -i A (remove B, E-G)
j.
^ permalink raw reply
* [PATCH 1/2] user-manual: Simplify the user configuration.
From: Felipe Contreras @ 2009-01-21 18:09 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
This is shorter, avoids the burder to think about the format of the
configuration file, and git config is already used in other places in
the manual.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 19f571a..3a9704c 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -981,13 +981,11 @@ Telling git your name
---------------------
Before creating any commits, you should introduce yourself to git. The
-easiest way to do so is to make sure the following lines appear in a
-file named .gitconfig in your home directory:
+easiest way is to use the linkgit:git-config[1] command:
------------------------------------------------
-[user]
- name = Your Name Comes Here
- email = you@yourdomain.example.com
+$ git config user.name "Your Name Comes Here"
+$ git config user.email you@yourdomain.example.com
------------------------------------------------
(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
--
1.6.1
^ permalink raw reply related
* [PATCH 2/2] Fix typo.
From: Felipe Contreras @ 2009-01-21 18:09 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1232561365-5919-1-git-send-email-felipe.contreras@gmail.com>
"its pointless" is wrong, should be "it is pointless" so "it's
pointless".
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
sha1_file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index f08493f..69fef9f 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -800,7 +800,7 @@ unsigned char* use_pack(struct packed_git *p,
if (p->pack_fd == -1 && open_packed_git(p))
die("packfile %s cannot be accessed", p->pack_name);
- /* Since packfiles end in a hash of their content and its
+ /* Since packfiles end in a hash of their content and it's
* pointless to ask for an offset into the middle of that
* hash, and the in_window function above wouldn't match
* don't allow an offset too close to the end of the file.
--
1.6.1
^ permalink raw reply related
* Re: Deleting remote branch pointed by remote HEAD
From: Daniel Barkalow @ 2009-01-21 18:30 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <20090121161940.GA20702@coredump.intra.peff.net>
On Wed, 21 Jan 2009, Jeff King wrote:
> On Wed, Jan 21, 2009 at 04:24:56PM +0100, Michael J Gruber wrote:
>
> > So, you get these errors on the local repo when dealing with the remote
> > repo, right? I guess this means two things:
> >
> > 1) You are deleting a remote branch
>
> Actually, he doesn't have to delete the remote branch; somebody else
> can. The problem is that the HEAD pointer for his remote tracking
> branches points to a branch that doesn't exist. This can happen because
> we sometimes update the tracking branches (including deletion) without
> impacting the HEAD pointer.
>
> There are two ways that I can think of (and there may be more) to
> provoke this:
>
> 1. delete a remote branch via push. The local side will helpfully
> delete your local tracking branch to match what happened on the
> remote. If it was the remote's HEAD, then you get a broken state
> (and while we discourage pushing to the remote HEAD on a non-bare
> repo, it is perfectly OK for a bare one).
>
> 2. somebody else deletes the remote branch that is the HEAD, and you
> update your tracking branches via "git remote prune", which deletes
> your tracking branches corresponding to any deleted remote branches.
>
> And actually there is a slight variant on both of the above. The deleted
> branch does not actually have to be the current HEAD on the remote. It
> just has to match your _idea_ of the current HEAD on the remote, which
> may be out of date.
>
> Situation (1) happens entirely locally. So it can be fixed fairly easily
> by checking whether the remote tracking HEAD points to a branch we are
> deleting, and deleting the HEAD in that case (the code should be in
> builtin-send-pack.c:update_tracking_ref). Of course you have probably
> also created a broken situation on the remote, so perhaps receive-pack
> should handle that.
>
> Situation (2) could do something similar: when we see that we are about
> to delete the ref pointed to by the remote tracking HEAD, we could
> delete the HEAD.
>
> But both situations are a little hack-ish to me. You are deleting the
> HEAD because you don't know what the right value is from the remote end.
> A better fix would be to actually pull the HEAD information down during
> fetch. And I seem to recall a patch about that at some point (it
> required a new protocol extension), but I don't know what become of it.
The information is available already; the only thing is that we don't have
a way to know that the user wants to get the remote's suggested HEAD; as
Junio pointed out at the time, a user might decide that "next" is the most
interesting branch, and set refs/remotes/origin/HEAD to that branch, and
therefore doesn't want it reset to the remote server's value.
That is, refs/remotes/origin/HEAD is only there to let the user abbreviate
the most useful branch of the remote; there's no reason it should reflect
the remote's HEAD, except that the remote's HEAD is a good guess if the
user hasn't said anything.
I think it might be more appropriate to just care less about a broken
symref, explain what's wrong if the user actually tries to use it, and
otherwise mostly ignore it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Felipe Contreras @ 2009-01-21 18:31 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <20090121161940.GA20702@coredump.intra.peff.net>
On Wed, Jan 21, 2009 at 6:19 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Jan 21, 2009 at 04:24:56PM +0100, Michael J Gruber wrote:
>
>> So, you get these errors on the local repo when dealing with the remote
>> repo, right? I guess this means two things:
>>
>> 1) You are deleting a remote branch
>
> Actually, he doesn't have to delete the remote branch; somebody else
> can. The problem is that the HEAD pointer for his remote tracking
> branches points to a branch that doesn't exist. This can happen because
> we sometimes update the tracking branches (including deletion) without
> impacting the HEAD pointer.
>
> There are two ways that I can think of (and there may be more) to
> provoke this:
>
> 1. delete a remote branch via push. The local side will helpfully
> delete your local tracking branch to match what happened on the
> remote. If it was the remote's HEAD, then you get a broken state
> (and while we discourage pushing to the remote HEAD on a non-bare
> repo, it is perfectly OK for a bare one).
>
> 2. somebody else deletes the remote branch that is the HEAD, and you
> update your tracking branches via "git remote prune", which deletes
> your tracking branches corresponding to any deleted remote branches.
>
> And actually there is a slight variant on both of the above. The deleted
> branch does not actually have to be the current HEAD on the remote. It
> just has to match your _idea_ of the current HEAD on the remote, which
> may be out of date.
>
> Situation (1) happens entirely locally. So it can be fixed fairly easily
> by checking whether the remote tracking HEAD points to a branch we are
> deleting, and deleting the HEAD in that case (the code should be in
> builtin-send-pack.c:update_tracking_ref). Of course you have probably
> also created a broken situation on the remote, so perhaps receive-pack
> should handle that.
>
> Situation (2) could do something similar: when we see that we are about
> to delete the ref pointed to by the remote tracking HEAD, we could
> delete the HEAD.
>
> But both situations are a little hack-ish to me. You are deleting the
> HEAD because you don't know what the right value is from the remote end.
> A better fix would be to actually pull the HEAD information down during
> fetch. And I seem to recall a patch about that at some point (it
> required a new protocol extension), but I don't know what become of it.
>
> However, even if we kept the tracking HEAD totally in sync with the
> remote's HEAD, it still may be possible that the remote HEAD is broken.
> In which case it might be nice to detect that when pulling it down and
> just leave the tracking HEAD unset.
Why should we care about the remote HEAD? Isn't that relevant only
when cloning to find out the branch to checkout?
Also, it's not nice to leave the remote repo with a broken HEAD
pointer, shouldn't git ask for a new head, or fail with a proper
message?
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Markus Heidelberg @ 2009-01-21 18:49 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0901210817r49971c09kea9dc8ee5ae21572@mail.gmail.com>
Caleb Cushing, 21.01.2009:
> git-mergetool.sh | 24 ++++++++++++++++++++----
> 1 files changed, 20 insertions(+), 4 deletions(-)
> + case "$ans" in
> + [mM]*)
> + break
I'd like to keep (additionally) the behaviour, that the merge starts
with just pressing <Enter>. Because what you mostly want to do, when
using git-mergetool, is actually merging.
> - case "$merge_tool" in
> + case "$merge_tool" in
> kdiff3)
This doesn't seem right.
Markus
^ permalink raw reply
* Planet Git
From: webmaster @ 2009-01-21 18:44 UTC (permalink / raw)
To: git
Hi everyone,
Just wanted to let everyone know that I've started a Planet for Git
users/developers who write about it on their journals/weblogs.
http://planetgit.org
Regards,
Tiago
^ permalink raw reply
* [PATCH] Change octal literals to be XEmacs friendly
From: malc @ 2009-01-21 17:02 UTC (permalink / raw)
To: git
case uses eql and (eql ?\001 1) evaluates to nil under XEmacs
(probably because some internal type of ?\001 is char)
Signed-off-by: Vassili Karpov <av1474@comtv.ru>
---
contrib/emacs/git.el | 30 +++++++++++++++---------------
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 09e8bae..715580a 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -562,29 +562,29 @@ the process output as a string, or nil if the git command failed."
(let* ((old-type (lsh (or old-perm 0) -9))
(new-type (lsh (or new-perm 0) -9))
(str (case new-type
- (?\100 ;; file
+ (#o100 ;; file
(case old-type
- (?\100 nil)
- (?\120 " (type change symlink -> file)")
- (?\160 " (type change subproject -> file)")))
- (?\120 ;; symlink
+ (#o100 nil)
+ (#o120 " (type change symlink -> file)")
+ (#o160 " (type change subproject -> file)")))
+ (#o120 ;; symlink
(case old-type
- (?\100 " (type change file -> symlink)")
- (?\160 " (type change subproject -> symlink)")
+ (#o100 " (type change file -> symlink)")
+ (#o160 " (type change subproject -> symlink)")
(t " (symlink)")))
- (?\160 ;; subproject
+ (#o160 ;; subproject
(case old-type
- (?\100 " (type change file -> subproject)")
- (?\120 " (type change symlink -> subproject)")
+ (#o100 " (type change file -> subproject)")
+ (#o120 " (type change symlink -> subproject)")
(t " (subproject)")))
- (?\110 nil) ;; directory (internal, not a real git state)
- (?\000 ;; deleted or unknown
+ (#o110 nil) ;; directory (internal, not a real git state)
+ (#o000 ;; deleted or unknown
(case old-type
- (?\120 " (symlink)")
- (?\160 " (subproject)")))
+ (#o120 " (symlink)")
+ (#o160 " (subproject)")))
(t (format " (unknown type %o)" new-type)))))
(cond (str (propertize str 'face 'git-status-face))
- ((eq new-type ?\110) "/")
+ ((eq new-type #o110) "/")
(t ""))))
(defun git-rename-as-string (info)
--
mailto:av1474@comtv.ru
^ permalink raw reply related
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Markus Heidelberg @ 2009-01-21 18:55 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1232561365-5919-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras, 21.01.2009:
> +++ b/Documentation/user-manual.txt
> @@ -981,13 +981,11 @@ Telling git your name
> ---------------------
>
> Before creating any commits, you should introduce yourself to git. The
> -easiest way to do so is to make sure the following lines appear in a
> -file named .gitconfig in your home directory:
> +easiest way is to use the linkgit:git-config[1] command:
>
> ------------------------------------------------
> -[user]
> - name = Your Name Comes Here
> - email = you@yourdomain.example.com
> +$ git config user.name "Your Name Comes Here"
> +$ git config user.email you@yourdomain.example.com
--global
Markus
^ permalink raw reply
* Re: [PATCH 1/2 v2] Add valgrind support in test scripts
From: Jeff King @ 2009-01-21 19:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901210209580.19014@racer>
On Wed, Jan 21, 2009 at 02:10:17AM +0100, Johannes Schindelin wrote:
> - symbolic links are inspected for correct targets now, and if they
> point somewhere else than expected, they are removed (this can
> error out if the file could not be removed) and recreated.
Now you _do_ have a race on this, and triggering it will cause you to
run a random version of git from your PATH, not using valgrind (instead
of running the version from the repo using valgrind). Something like:
A: execvp("git-foo")
B: oops, "git-foo" is out of date
B: rm $GIT_VALGRIND/git-foo
A: look for $GIT_VALGRIND/git-foo; not there
A: look for $PATH[1]/git-foo; ok, there it is
B: ln -s ../../git-valgrind $GIT_VALGRIND/git-foo
> +--valgrind::
> + Execute all Git binaries with valgrind and stop on errors (the
> + exit code will be 126).
It doesn't necessarily stop: it just causes the command to fail, which
causes the test to fail. Which _will_ stop if you have "-i".
Also, you might want to mention that valgrind errors go to stderr, so
using "-v" is helpful.
> + # override all git executables in PATH and TEST_DIRECTORY/..
> + GIT_VALGRIND=$TEST_DIRECTORY/valgrind/bin
I think you should leave GIT_VALGRIND pointing to the main valgrind
directory. That way it is more convenient for people using
GIT_VALGRIND_OPTIONS to make use of GIT_VALGRIND without having to ".."
everything (for example, they may want to pick and choose suppressions
to load for their platform).
> + case "$base" in
> + *.sh|*.perl)
> + symlink_target=../unprocessed-script
> + esac
AFAIK, this triggers an error if I try to call "git-foo.perl" directly.
What does this have to do with valgrind? Why does this error checking
happen when I run --valgrind, but _not_ otherwise?
And yes, I know the answer is "because it's easy to do here, since
--valgrind is munging the PATH anyway". But my point is that that is an
_implementation_ detail, and the external behavior to a user is
nonsensical.
The fact that there are other uses for munging the PATH than valgrind
implies to me that we should _always_ be munging the PATH like this to
catch these sorts of errors. And then "--valgrind" can just change the
way we munge.
> + # create the link, or replace it if it is out of date
> + if test ! -h "$GIT_VALGRIND"/"$base" ||
> + test "$symlink_target" != \
> + "$(readlink "$GIT_VALGRIND"/"$base")"
> + then
readlink is not portable; it's part of GNU coreutils. Right now valgrind
basically only runs on Linux, which I think generally means that
readlink will be available (though I have no idea if there are
distributions that vary in this). However, there is an experimental
valgrind port to FreeBSD and NetBSD, which are unlikely to have
readlink.
-Peff
^ permalink raw reply
* [PATCH] user-manual: Simplify the user configuration.
From: Felipe Contreras @ 2009-01-21 19:04 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <200901211955.47362.markus.heidelberg@web.de>
This is shorter, avoids the burder to think about the format of the
configuration file, and git config is already used in other places in
the manual.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 19f571a..c8a1b7b 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -981,13 +981,11 @@ Telling git your name
---------------------
Before creating any commits, you should introduce yourself to git. The
-easiest way to do so is to make sure the following lines appear in a
-file named .gitconfig in your home directory:
+easiest way is to use the linkgit:git-config[1] command:
------------------------------------------------
-[user]
- name = Your Name Comes Here
- email = you@yourdomain.example.com
+$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com
------------------------------------------------
(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
--
1.6.1
^ permalink raw reply related
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-21 19:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901210216440.19014@racer>
On Wed, Jan 21, 2009 at 02:26:56AM +0100, Johannes Schindelin wrote:
> Well, in this case, you will find that the "bug" is _at most_ some
> binaries not being found.
> [...]
> (Actually, with my new patch, the may be replaced, but _only_ if
> necessary, and the same thing would apply as I said earlier: the binary
> would not be found, or a binary from the PATH would be run without
> valgrind; but the next runs will not have the problem.)
You can run a random binary from the PATH. So I have asked git to test
the version in the repository using valgrind, and to report success only
if both the git command itself succeeds and valgrind reports zero
errors. But it might run some other random version of git, not using
valgrind, and if _that_ succeeds, report success. And you don't think
that is a bug?
I'll grant it is an unlikely race to lose. I guess I just prefer my
races to be non-existent.
-Peff
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Boyd Stephen Smith Jr. @ 2009-01-21 19:09 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Jeff King, Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <alpine.LNX.1.00.0901211237530.19665@iabervon.org>
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
On Wednesday 21 January 2009, Daniel Barkalow <barkalow@iabervon.org> wrote
about 'Re: Deleting remote branch pointed by remote HEAD':
>I think it might be more appropriate to just care less about a broken
>symref, explain what's wrong if the user actually tries to use it, and
>otherwise mostly ignore it.
That sounds reasonable. It's not like "find" complains about every broken
symlink it sees. Simple traversal or the repository should probably not
complain about every broken symref.
--
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: [PATCH 2/2 v2] valgrind: ignore ldso errors
From: Jeff King @ 2009-01-21 19:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901210236320.19014@racer>
On Wed, Jan 21, 2009 at 02:36:40AM +0100, Johannes Schindelin wrote:
> Only change vs v1: adds Addr4 suppression, so that ld.so "errors"
> are ignored on 32-bit, too.
I don't think it is wrong to add the extra suppression, but out of
curiosity, did you actually trigger it? I tested the original on both
32- and 64-bit platforms, and that was what made me create the original
(i.e., for some reason my 32-bit platform did not need the same ld.so
suppression).
-Peff
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Jeff King @ 2009-01-21 19:12 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <alpine.LNX.1.00.0901211237530.19665@iabervon.org>
On Wed, Jan 21, 2009 at 01:30:10PM -0500, Daniel Barkalow wrote:
> The information is available already; the only thing is that we don't have
> a way to know that the user wants to get the remote's suggested HEAD; as
> Junio pointed out at the time, a user might decide that "next" is the most
> interesting branch, and set refs/remotes/origin/HEAD to that branch, and
> therefore doesn't want it reset to the remote server's value.
>
> That is, refs/remotes/origin/HEAD is only there to let the user abbreviate
> the most useful branch of the remote; there's no reason it should reflect
> the remote's HEAD, except that the remote's HEAD is a good guess if the
> user hasn't said anything.
Good point. It is probably wrong to just fetch it without asking, then.
> I think it might be more appropriate to just care less about a broken
> symref, explain what's wrong if the user actually tries to use it, and
> otherwise mostly ignore it.
I thought about that, but I still wonder if deleting it when the
pointed-to ref is deleted might be more convenient. Remember that
"refs/remotes/$foo/HEAD" can be accessed by a shorthand "$foo". So that
means it can impact ref ambiguity lookup. I guess the chance of that
happening is fairly unlikely, though.
-Peff
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Jeff King @ 2009-01-21 19:14 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <20090121191219.GD21686@coredump.intra.peff.net>
On Wed, Jan 21, 2009 at 02:12:19PM -0500, Jeff King wrote:
> > I think it might be more appropriate to just care less about a broken
> > symref, explain what's wrong if the user actually tries to use it, and
> > otherwise mostly ignore it.
>
> I thought about that, but I still wonder if deleting it when the
> pointed-to ref is deleted might be more convenient. Remember that
> "refs/remotes/$foo/HEAD" can be accessed by a shorthand "$foo". So that
> means it can impact ref ambiguity lookup. I guess the chance of that
> happening is fairly unlikely, though.
Not to mention that even without others refs with matching names, it is
probably nicer to the user who does try to access it via "$foo" to
simply say "there is no $foo" rather than a confusing error message
about a deleted branch that they have to manually fix. And that is
easily accomplished by deleting such a bogus symref.
-Peff
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Jeff King @ 2009-01-21 19:16 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <94a0d4530901211031s18261776rf8abfddcdcb42402@mail.gmail.com>
On Wed, Jan 21, 2009 at 08:31:50PM +0200, Felipe Contreras wrote:
> Why should we care about the remote HEAD? Isn't that relevant only
> when cloning to find out the branch to checkout?
You can use the shorthand $foo to refer to refs/remotes/$foo/HEAD. Which
means, in the default case, you can refer to just "origin" to talk about
origin's master branch.
But as Daniel noted, that is really about local preference for "what is
the most interesting branch on the remote". You might want to track what
the remote sets to HEAD, or you might want to set it individually.
-Peff
^ permalink raw reply
* Re: [PATCH] user-manual: Simplify the user configuration.
From: Jeff King @ 2009-01-21 19:18 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1232564650-3701-1-git-send-email-felipe.contreras@gmail.com>
On Wed, Jan 21, 2009 at 09:04:10PM +0200, Felipe Contreras wrote:
> This is shorter, avoids the burder to think about the format of the
> configuration file, and git config is already used in other places in
> the manual.
I seem to recall this coming up several times before, and there being a
sentiment that it was _good_ to introduce the user to concept of a
config file. It lets them know that it exists, approximately what the
syntax looks like, and demystifies what is going on when you type "git
config" (i.e., it intentionally shows that there is more than way to do
it).
I don't have a personal preference, but you may want to grep the
list archives for other discussion.
-Peff
^ 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