* 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
* Re: Deleting remote branch pointed by remote HEAD
From: Felipe Contreras @ 2009-01-21 19:20 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <20090121191619.GE21686@coredump.intra.peff.net>
On Wed, Jan 21, 2009 at 9:16 PM, Jeff King <peff@peff.net> wrote:
> 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.
Ah, good to know. But then the message should appear only when doing
something with the $foo branch.
--
Felipe Contreras
^ permalink raw reply
* Merging adjacent deleted lines?
From: Jonathan del Strother @ 2009-01-21 19:20 UTC (permalink / raw)
To: Git Mailing List
Say I have a file that started out with the following content :
line1
line2
line3
line4
I create a branch, which deletes line2. Someone else's branch deletes line 3.
When I merge those two branches, the conflict looks like :
line1
<<<<<<< HEAD:lines
line3
=======
line2
>>>>>>> SomeoneElse:lines
line4
Which in my cursory overview, looked an awful lot like the obvious
merge resolution ought to be
line1
line3
line4
After all - I know I want to delete line 2, and wasn't aware of the
other person deleting line 3.
It was only later that we discovered that the merge was broken and
both lines should have been deleted. Thinking about it, I guess that
the conflict if the other branch _hadn't_ deleted line 3 would have
looked something like
line1
<<<<<<< HEAD:lines
=======
line2
>>>>>>> SomeoneElse:lines
line3
line4
- which wouldn't have resulted in a conflict anyway.
So, it looks like I need to be way more careful when merging
conflicts. Which leads me to - what tools do you use when studying
conflicts like that? git blame seems the obvious one, for getting the
context of each deletion, but it seems like I need to run it once as
git blame HEAD lines, and once as git blame MERGE_HEAD lines. Is
there something a little more integrated for comparing the origin of
each change from both merge branches simultaneously?
Would welcome any thoughts on how you guys approach conflict-resolution
-Jon
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Markus Heidelberg @ 2009-01-21 19:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Boyd Stephen Smith Jr., Santi Béjar,
Thomas Rast, git, Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901202202370.3586@pacific.mpi-cbg.de>
Johannes Schindelin, 20.01.2009:
> Hi,
>
> On Tue, 20 Jan 2009, Markus Heidelberg wrote:
>
> > Junio C Hamano, 20.01.2009:
> > > None of the existing configuration variables defined use hyphens in
> > > multi-word variable names.
> >
> > Except for diff.suppress-blank-empty
> > Should it be converted or is it intention to reflect GNU diff's option?
>
> Grumble. It's in v1.6.1-rc1~348, so we cannot just go ahead and fix it.
Did I say change it without keeping backward compatibility?
> Ciao,
> Dscho "who loves consistency, and knows new users appreciate it, too"
Me, too.
Markus
^ permalink raw reply
* Re: [PATCH] user-manual: Simplify the user configuration.
From: Felipe Contreras @ 2009-01-21 19:39 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090121191808.GF21686@coredump.intra.peff.net>
On Wed, Jan 21, 2009 at 9:18 PM, Jeff King <peff@peff.net> wrote:
> 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.
That's over complicating the user with what should probably be one of
the first things to do. Besides, do Windows users know which is their
home directory?
Maybe a comment like previous git config commands:
If you examine the file .gitconfig in your home directory, you will see this:
------------------------------------------------
...
[user]
name = Your Name Comes Here
email = you@yourdomain.example.com
...
------------------------------------------------
--
Felipe Contreras
^ permalink raw reply
* Re: Merging adjacent deleted lines?
From: Robin Rosenberg @ 2009-01-21 19:49 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Git Mailing List
In-Reply-To: <57518fd10901211120n62f8d0e9ya8595fc9baa6476c@mail.gmail.com>
onsdag 21 januari 2009 20:20:50 skrev Jonathan del Strother:
[...]
> So, it looks like I need to be way more careful when merging
> conflicts. Which leads me to - what tools do you use when studying
> conflicts like that? git blame seems the obvious one, for getting the
> context of each deletion, but it seems like I need to run it once as
> git blame HEAD lines, and once as git blame MERGE_HEAD lines. Is
> there something a little more integrated for comparing the origin of
> each change from both merge branches simultaneously?
>
> Would welcome any thoughts on how you guys approach conflict-resolution
I think you've illustrated a case for graphical merge resolution tools, i.e.
run git mergetool to help resolve the conlicts. It will run a graphical tool
for you.
The list seems to be: kdiff3 kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
None of the tools can run blame in the merge tool also. That would be nice.
-- robin
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Daniel Barkalow @ 2009-01-21 19:50 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <20090121191408.GA22958@coredump.intra.peff.net>
On Wed, 21 Jan 2009, Jeff King wrote:
> 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.
I think the ideal thing is to keep the symref as a reminder and just give
a non-confusing error message instead of a confusing one. E.g.:
"""
$foo is set to mean the tracking branch $foo/bar, which does not exist.
Use:
git remote set-default $foo <name>
to set a new default branch for $foo.
"""
(And, of course, add that subcommand to remote)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] user-manual: Simplify the user configuration.
From: Jeff King @ 2009-01-21 19:51 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530901211139x6296a48m14aa7ce1d8e65145@mail.gmail.com>
On Wed, Jan 21, 2009 at 09:39:27PM +0200, Felipe Contreras wrote:
> That's over complicating the user with what should probably be one of
> the first things to do. Besides, do Windows users know which is their
> home directory?
Like I said, I don't care one way or the other, personally. But you
should at least address points brought up in the previous iterations:
http://thread.gmane.org/gmane.comp.version-control.git/37921/focus=38007
http://thread.gmane.org/gmane.comp.version-control.git/46903
-Peff
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Jeff King @ 2009-01-21 19:53 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <alpine.LNX.1.00.0901211443140.19665@iabervon.org>
On Wed, Jan 21, 2009 at 02:50:40PM -0500, Daniel Barkalow wrote:
> I think the ideal thing is to keep the symref as a reminder and just give
> a non-confusing error message instead of a confusing one. E.g.:
>
> """
> $foo is set to mean the tracking branch $foo/bar, which does not exist.
> Use:
>
> git remote set-default $foo <name>
>
> to set a new default branch for $foo.
> """
>
> (And, of course, add that subcommand to remote)
I think that would be reasonable behavior (and probably a special mode
for set-default to just update from the remote's idea of HEAD).
-Peff
^ permalink raw reply
* Re: [PATCH (topgit)] tg-patch: add support for generating patches against worktree and index
From: Kirill Smelkov @ 2009-01-21 20:26 UTC (permalink / raw)
To: martin f krafft; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <20090121032052.GB7422@lapse.rw.madduck.net>
On Wed, Jan 21, 2009 at 02:20:52PM +1100, martin f krafft wrote:
> also sprach Kirill Smelkov <kirr@landau.phys.spbu.ru> [2009.01.21.0456 +1100]:
> > No problem and take your time.
> >
> > It was just me having no idea about what's going on.
>
> I am a little confused about the patches, and git-am does not seem
> to be able to apply two patches from the same email. I use Maildir,
> so I am passing the single message with multiple patches to git-am,
> and it applies all changes into one single commit.
I see.
It seems I need to study how to prepare patches with patchy comments, or
get my hands dirty with `git am` :)
> Anyway, do you have a repo which I can cherry-pick from?
Sure
git://repo.or.cz/topgit/kirr.git for-upstream
Thanks,
Kirill
^ permalink raw reply
* Re: John (zzz) Doe <john.doe@xz> (Comment)
From: Kirill Smelkov @ 2009-01-21 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vzlhlic7d.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 20, 2009 at 07:12:54PM -0800, Junio C Hamano wrote:
> Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> > Is it ok?
>
> I think the patch text looks good, but what you have as the proposed
> commit log message does not look anything like log message we usually use.
>
> - If you agree with my comment that "should NOT be included" from the RFC
> you quoted is irrelevant, then I do not think you would even want to
> have anything before "On the other hand,...".
>
> - If you disagree, then why are you bending the patch text to match what
> I say? ;-)
I agree, really :)
It's only me usually tired in the end of the day, like today too.
I'll try to have a rest and will reply with updated patch.
Thanks,
Kirill
^ permalink raw reply
* Re: Planet Git
From: Johannes Gilger @ 2009-01-21 20:27 UTC (permalink / raw)
To: git
In-Reply-To: <a2ce9d792bc2f586e2a1408e573db433.squirrel@webmail.planetgit.org>
On 2009-01-21, webmaster@planetgit.org <webmaster@planetgit.org> wrote:
> Just wanted to let everyone know that I've started a Planet for Git
> users/developers who write about it on their journals/weblogs.
Funny, I just visited it today and didn't know how long this website has
been idle like that (with only 4 blogs or so). So I was about to write
you to post it right here, but you did that already.
Although right now I can't see any subscriptions at all :(
Greetings,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: What about allowing multiple hooks?
From: Anders Waldenborg @ 2009-01-21 20:35 UTC (permalink / raw)
To: git; +Cc: Alexander Potashev, Marc Weber, git, Rogan Dawes, martin f krafft
In-Reply-To: <7vd4f3z8xu.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> I deliberately omitted support for multiple scripts in core git Porcelains
> to avoid this exact issue. It is a huge can of worms and it is dubious if
> you can have a coherent and generic enough semantics.
>
> In the meantime, you can have a single .git/hooks/pre-commit script that
> defines your own convention. Maybe it uses .git/hooks/pre-commit.d/
> directory, full of scripts, and implements the semantics you want,
> including:
>
> (1) the execution order and the naming convention of the scripts (e.g.
> they all live in pre-commit.d/ directory, and executed in ASCII byte
> value order of their names);
>
> (2) how their exit status combine together.
I need multiple hooks, so I've done some thinking about this, so I
thought it may be a good idea to share this here.
I currently use configvalues to specify which hooks to run. For example
this is how my post-receive looks:
data=$(cat)
git config --get-all hooks.post-receive.hook | while read hook; do
$hook <<__EOF__
"$data"
__EOF__
done
Now none of my hooks wants to prevent update, so I don't care about
return status. But it could easily be extended, for example by having
some indicator per hook that can have the values (are these enough?):
ignore - pretent that no failure was returned no matter what
sufficient - if this hook suceeds end result is always sucess
required - if this hook fails we fail, no more hooks are run
That could be done with the simple configvalue thing as follows:
git config -add hooks.post-receive.hook \
"sufficient allow-repo-owner-to-do-anything.sh"
git config -add hooks.post-receive.hook \
"required finegrained-access-control.sh"
git config -add hooks.post-receive.hook \
"required allow-repo-owner-to-do-anything.sh"
git config -add hooks.post-receive.hook \
"ignore send-mail.sh"
git config -add hooks.post-receive.hook \
"ignore send-irc-notification.py"
One problem is that to change order one has to resort to manually
editing config. So maybe something richer could be used:
[hooks "allow-repo-owner-to-do-anything"]
cmd = /usr/share/git-hooks/allow-repo-owner-to-do-anything.sh
enabled = 1
type = post-receive
mode = sufficient
priority = 10
[hooks "mail"]
cmd = /usr/share/git-hooks/allow-repo-owner-to-do-anything.sh
enabled = 1
type = post-receive
mode = ignore
priority = 1000
(this would even allow running hooks at same priority simultaneously)
Also then the hook's own config variables fits nicely in same section.
(note that then each [hooks "x"] will be an instance that could use the
same script, but different configvars)
anders
^ 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