* [PATCH] contrib/hooks/post-receive-email: make subject prefix configurable
From: Gerrit Pape @ 2007-11-06 13:49 UTC (permalink / raw)
To: git, Junio C Hamano
Email subjects are prefixed with "[SCM] " by default, make this optionally
configurable through the hooks.emailprefix config option.
Suggested by martin f krafft through
http://bugs.debian.org/428418
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
contrib/hooks/post-receive-email | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 9b9a977..3904c18 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -35,10 +35,12 @@
# hooks.envelopesender
# If set then the -f option is passed to sendmail to allow the envelope
# sender address to be set
+# hooks.emailprefix
+# All emails have their subjects prefixed with this prefix, or "[SCM]"
+# if emailprefix is unset, to aid filtering
#
# Notes
# -----
-# All emails have their subjects prefixed with "[SCM]" to aid filtering.
# All emails include the headers "X-Git-Refname", "X-Git-Oldrev",
# "X-Git-Newrev", and "X-Git-Reftype" to enable fine tuned filtering and
# give information for debugging.
@@ -188,7 +190,7 @@ generate_email_header()
# Generate header
cat <<-EOF
To: $recipients
- Subject: ${EMAILPREFIX}$projectdesc $refname_type, $short_refname, ${change_type}d. $describe
+ Subject: ${emailprefix}$projectdesc $refname_type, $short_refname, ${change_type}d. $describe
X-Git-Refname: $refname
X-Git-Reftype: $refname_type
X-Git-Oldrev: $oldrev
@@ -604,7 +606,6 @@ send_mail()
# ---------------------------- main()
# --- Constants
-EMAILPREFIX="[SCM] "
LOGBEGIN="- Log -----------------------------------------------------------------"
LOGEND="-----------------------------------------------------------------------"
@@ -628,6 +629,7 @@ fi
recipients=$(git repo-config hooks.mailinglist)
announcerecipients=$(git repo-config hooks.announcelist)
envelopesender=$(git-repo-config hooks.envelopesender)
+emailprefix=$(git-repo-config hooks.emailprefix || echo '[SCM] ')
# --- Main loop
# Allow dual mode: run from the command line just like the update hook, or
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] hooks--update: fix test for properly set up project description file
From: Andreas Ericsson @ 2007-11-06 13:55 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git, Junio C Hamano
In-Reply-To: <20071106134749.24233.qmail@809f27f669039a.315fe32.mid.smarden.org>
Gerrit Pape wrote:
> The update hook template intends to abort if the project description file
> hasn't been adjusted or is empty. This patch fixes the check for 'being
> adjusted'.
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
> templates/hooks--update | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/templates/hooks--update b/templates/hooks--update
> index d8c7626..65e8c32 100644
> --- a/templates/hooks--update
> +++ b/templates/hooks--update
> @@ -34,8 +34,8 @@ fi
> allowunannotated=$(git-repo-config --bool hooks.allowunannotated)
>
> # check for no description
> -projectdesc=$(sed -e '1p' "$GIT_DIR/description")
> -if [ -z "$projectdesc" -o "$projectdesc" = "Unnamed repository; edit this file to name it for gitweb" ]; then
> +projectdesc=$(sed -ne '1p' "$GIT_DIR/description")
Write this as
projectdesc=$(sed -e 1q "$GIT_DIR/description")
instead. It's a little shorter, a little faster and slightly more portable.
> +if [ -z "$projectdesc" -o "$projectdesc" = "Unnamed repository; edit this file to name it for gitweb." ]; then
> echo "*** Project description file hasn't been set" >&2
> exit 1
I must have missed when the default updatehook got this addendum, as it's
impossible to push to a repository that isn't named with this hook in
effect. I imagine this could lead to some fun problems when trying to
push to repositories on windows machines.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Rearrange git-format-patch synopsis to improve clarity.
From: Jon Loeliger @ 2007-11-06 15:01 UTC (permalink / raw)
To: David Symonds; +Cc: Junio C Hamano, git
In-Reply-To: <ee77f5c20711051432w284cf22dx71192c145d25dced@mail.gmail.com>
David Symonds wrote:
> On 11/5/07, David Symonds <dsymonds@gmail.com> wrote:
>> [-s | --signoff] [<common diff options>]
>> - [--start-number <n>] [--numbered-files]
>> + [-n | --numbered-files | -N | --no-numbered]
>> + [--start-number <n>]
>
> Now that I look at it again, it seems the long options look quite
> inconsistent. I think it should be either
> --numbered-files/--no-numbered-files or --numbered/--no-numbered. My
> preference is with the latter (for brevity), but that breaks
> backward-compatibility.
>
> Would you accept a patch that changed --numbered-files to --numbered,
> and kept the former as a synonym?
There are two forms of numbered file output names:
the traditional "0001-Foo-the-bar" and just "1" styles.
Please don't break that. Both are needed.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Jeff King @ 2007-11-06 15:47 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Alex Riesen, Michael Cohen, Gerrit Pape, Fernando J. Pereda, git,
Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711061100150.4362@racer.site>
On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
> > > So? Why *STOP* reading the mails if just one of the directories could
> > > not be opened? IOW, I suggest:
> >
> > Because you are then trying to apply a patch series with some patches
> > potentially missing? Continuing only on errno == ENOENT seems prudent.
>
> I fail to see how the absence of one of cur/ or new/ can lead to the
> absence of patches. You could forget to save some patches, yes, but the
> presence of cur/ and new/ is no indicator for that.
Read my message again. Alex is proposing ignoring errors in opening the
directories; I am proposing ignoring such errors _only_ when the error
is that the directory does not exist.
IOW, if there is some other error in opening the directory, it should be
fatal, because you might be missing patches.
-Peff
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Johannes Schindelin @ 2007-11-06 15:51 UTC (permalink / raw)
To: Jeff King
Cc: Alex Riesen, Michael Cohen, Gerrit Pape, Fernando J. Pereda, git,
Junio C Hamano
In-Reply-To: <20071106154740.GA24505@sigill.intra.peff.net>
Hi,
On Tue, 6 Nov 2007, Jeff King wrote:
> On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
>
> > > > So? Why *STOP* reading the mails if just one of the directories could
> > > > not be opened? IOW, I suggest:
> > >
> > > Because you are then trying to apply a patch series with some patches
> > > potentially missing? Continuing only on errno == ENOENT seems prudent.
> >
> > I fail to see how the absence of one of cur/ or new/ can lead to the
> > absence of patches. You could forget to save some patches, yes, but the
> > presence of cur/ and new/ is no indicator for that.
>
> Read my message again. Alex is proposing ignoring errors in opening the
> directories; I am proposing ignoring such errors _only_ when the error
> is that the directory does not exist.
>
> IOW, if there is some other error in opening the directory, it should be
> fatal, because you might be missing patches.
Yeah, sorry, I missed that.
Ciao,
Dscho
^ permalink raw reply
* Re: git pull opinion
From: Linus Torvalds @ 2007-11-06 16:36 UTC (permalink / raw)
To: Aghiles; +Cc: Bill Lear, Junio C Hamano, git
In-Reply-To: <3abd05a90711052230y4d6151c6o3e7985a0c8e18161@mail.gmail.com>
On Tue, 6 Nov 2007, Aghiles wrote:
>
> BitKeeper, for example, does a merge with a "dirty" directory.
> I am not saying that git should behave the same way but I think
> that this argument strengthens the point that it is not a
> "centralized repository" mindset.
Git does merge with a dirty directory too, but refuses to merge if it
needs to *change* any individual dirty *files*.
And that actually comes from one of the great strengths of git: in git
(unlike just about any other SCM out there) you can - and are indeed
expected to - resolve merges sanely in the working tree using normal
filesystem accesses (ie your basic normal editors and other tools).
That means that if there is a unresolved merge, you're actually expected
to edit things in the same place where they are dirty. Which means that
the merge logic doesn't want to mix up your dirty state and whatever
merged state, because that is then not sanely resolvable.
Now, I do think that we could relax the rule so that "files that are
modified must be clean in the working tree" could instead become "files
that actually don't merge _trivially_ must be clean in the working tree".
But basically, if it's not a trivial merge, then since it's done in the
working tree, the working tree has to be clean (or the merge would
overwrite it).
Doing a four-way merge is just going to confuse everybody.
So we *could* probably make unpack-trees.c: treeway_merge() allow this.
It's not totally trivial, because it requires that the CE_UPDATE be
replaced with something more ("CE_THREEWAY"): instead of just writing the
new result, it should do another three-way merge.
So it's within the range of possible, but it's actually pretty subtle. The
reason: we cannot (and *must*not*!) actually do the three-way merge early.
We need to do the full tree merge in stage 1, and then only if all files
are ok can we then check out the new tree. And we currently don't save the
merge information at all.
So to do this, we'd need to:
- remove the "verify_uptodate(old, o); invalidate_ce_path(old);" in
"merged_entry()", and actually *leave* the index with all three stages
intact, but set CE_UPDATE *and* return success.
- make check_updates() do the three-way merge of "original index, working
tree, new merged state" instead of just doing a "unlink_entry() +
checkout_entry()".
It doesn't actually look *hard*, but it's definitely subtle enough that
I'd be nervous about doing it. We're probably talking less than 50 lines
of actual diffs (this whole code uses good data structures, and we can
fairly easily represent the problem, and we already have the ability to do
a three-way merge!), but we're talking some really quite core code and
stuff that absolutely must not have any chance what-so-ever of ever
breaking!
To recap:
- it's probably a fairly simple change to just two well-defined places
(merge_entry() and check_updates())
- but dang, those two places are critical and absolutely must not be
screwed up, and while both of those functions are pretty simple, this
is some seriously core functionality.
If somebody wants to do it, I'll happily look over the result and test it
out, but it really needs to be really clean and obvious and rock solid.
And in the absense of that, I'll take the current safe code that just
says: don't confuse the merge and make it any more complex than it needs
to be.
Linus
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Kristian Høgsberg @ 2007-11-06 16:42 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Johannes Schindelin, Björn Steinbrink, Junio C Hamano, git
In-Reply-To: <20071106091222.GE4435@artemis.corp>
On Tue, 2007-11-06 at 10:12 +0100, Pierre Habouzit wrote:
> On Mon, Nov 05, 2007 at 11:18:36PM +0000, Johannes Schindelin wrote:
> > Hi,
> >
> > On Mon, 5 Nov 2007, Bj?rn Steinbrink wrote:
> >
> > > On 2007.11.05 13:57:53 -0500, Kristian H?gsberg wrote:
> > >
> > > > The shell script just has
> > > >
> > > > case "$all,$interactive,$also,$#" in
> > > > *t,*t,*)
> > > > die "Cannot use -a, --interactive or -i at the same time." ;;
> > > >
> > > > which doesn't seem to care about the value of $also. As far as I
> > > > understand git commit, it doesn't make sense to pass any of -a, -i, -o
> > > > or --interactive at the same time so I guess I could join the checks
> > >
> > > Note that there are only two commas. The asterisks catch everything and
> > > $# won't be "t", so that catches anything with at least two t's.
> >
> > So shouldn't it be
> >
> > if (!!all + !!interactive + !!also > 1)
>
> Btw, I'm starting to work slowly on the diff_opt_parse conversion to the
> macro we discussed, and the need for new option parsing callbacks
> arised, and I've created a:
>
> parse_opt_mask_{or,and,xor} commands that you declare this way:
>
> OPT_MASK_OR('a', "all", &mode, "...", MASK_ALL),
> OPT_MASK_OR('i', "interactive", &mode, "...", MASK_INTERACTIVE),
> ...
That's useful here, and it should be useful in a lot of other places
using parse_options() where we end up or'ing flags into a mask based on
boolean options.
cheers,
Kristian
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Kristian Høgsberg @ 2007-11-06 16:46 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20071106065941.GA6423@atjola.homenet>
On Tue, 2007-11-06 at 07:59 +0100, Björn Steinbrink wrote:
...
> Note though, that Kristian had a similar check at the end of his email,
> that included "only" (but lacked the bool conversion). The original
> reason why I thought that it would be better was that for example
> "git commit --all --only foo" didn't care about "only" at all. But that
> actually was because the --all + paths usage check was broken. So the
> fixed version actually refuses to use accept that, but with a (IMHO) not
> so good error message:
>
> $ git commit -a -o file
> Paths with -a does not make sense.
>
> Given that some people are used to just pass -a all the time, they might
> just automatically pass it together with -o. And I think that we
> actually want to tell them that -a + -o makes no sense instead. Just
> like we do for -a + -i, which is kind of the complementary usage error.
>
> So I'd go for a correct version of Kristian's suggestion:
>
> if (!!also + !!only + !!all + !!interactive > 1)
> die("Only one of --include/--only/--all/--interactive can be used.");
Good points, I will use that in the next version of the patch. Just a
note about the !! idiom (which I can't stand, fwiw): my version just
added the variables, which were all integers, initialized to zero and
incremented by the option parser when it sees the corresponding option.
So what I had would work too, with the extra check that:
$ git commit -a -a
etc would give the error
Only one of --include/--only/--all/--interactive can be used.
which is acutally accurate.
cheers,
Kristian
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Johannes Schindelin @ 2007-11-06 16:58 UTC (permalink / raw)
To: Karl Hasselström
Cc: Jeff King, Alex Riesen, Michael Cohen, Gerrit Pape,
Fernando J. Pereda, git, Junio C Hamano
In-Reply-To: <20071106163548.GA8207@diana.vm.bytemark.co.uk>
Hi,
On Tue, 6 Nov 2007, Karl Hasselstr?m wrote:
> On 2007-11-06 15:51:09 +0000, Johannes Schindelin wrote:
>
> > On Tue, 6 Nov 2007, Jeff King wrote:
> >
> > > On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
> > >
> > > > I fail to see how the absence of one of cur/ or new/ can lead to
> > > > the absence of patches. You could forget to save some patches,
> > > > yes, but the presence of cur/ and new/ is no indicator for that.
> > >
> > > Read my message again. Alex is proposing ignoring errors in
> > > opening the directories; I am proposing ignoring such errors
> > > _only_ when the error is that the directory does not exist.
> > >
> > > IOW, if there is some other error in opening the directory, it
> > > should be fatal, because you might be missing patches.
> >
> > Yeah, sorry, I missed that.
>
> I think it might actually not be totally unreasonable to error out
> unless both directories exist. From
> http://www.qmail.org/qmail-manual-html/man5/maildir.html:
>
> A directory in maildir format has three subdirectories, all on the
> same filesystem: tmp, new, and cur.
>
> In other words, if it doesn't have these three directories, it isn't a
> Maildir directory.
>
> On the other hand, one could argue that requiring both dirs to exist
> is being too picky.
Not only that. The recent patch for OSX' mail program would be trivial
if we did not error out: the array would just contain cur, new and
Messages.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Karl Hasselström @ 2007-11-06 16:35 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Alex Riesen, Michael Cohen, Gerrit Pape,
Fernando J. Pereda, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711061550580.4362@racer.site>
On 2007-11-06 15:51:09 +0000, Johannes Schindelin wrote:
> On Tue, 6 Nov 2007, Jeff King wrote:
>
> > On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
> >
> > > I fail to see how the absence of one of cur/ or new/ can lead to
> > > the absence of patches. You could forget to save some patches,
> > > yes, but the presence of cur/ and new/ is no indicator for that.
> >
> > Read my message again. Alex is proposing ignoring errors in
> > opening the directories; I am proposing ignoring such errors
> > _only_ when the error is that the directory does not exist.
> >
> > IOW, if there is some other error in opening the directory, it
> > should be fatal, because you might be missing patches.
>
> Yeah, sorry, I missed that.
I think it might actually not be totally unreasonable to error out
unless both directories exist. From
http://www.qmail.org/qmail-manual-html/man5/maildir.html:
A directory in maildir format has three subdirectories, all on the
same filesystem: tmp, new, and cur.
In other words, if it doesn't have these three directories, it isn't a
Maildir directory.
On the other hand, one could argue that requiring both dirs to exist
is being too picky.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Björn Steinbrink @ 2007-11-06 17:08 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <1194367619.20020.9.camel@hinata.boston.redhat.com>
On 2007.11.06 11:46:59 -0500, Kristian Høgsberg wrote:
> On Tue, 2007-11-06 at 07:59 +0100, Björn Steinbrink wrote:
> ...
> > Note though, that Kristian had a similar check at the end of his email,
> > that included "only" (but lacked the bool conversion). The original
> > reason why I thought that it would be better was that for example
> > "git commit --all --only foo" didn't care about "only" at all. But that
> > actually was because the --all + paths usage check was broken. So the
> > fixed version actually refuses to use accept that, but with a (IMHO) not
> > so good error message:
> >
> > $ git commit -a -o file
> > Paths with -a does not make sense.
> >
> > Given that some people are used to just pass -a all the time, they might
> > just automatically pass it together with -o. And I think that we
> > actually want to tell them that -a + -o makes no sense instead. Just
> > like we do for -a + -i, which is kind of the complementary usage error.
> >
> > So I'd go for a correct version of Kristian's suggestion:
> >
> > if (!!also + !!only + !!all + !!interactive > 1)
> > die("Only one of --include/--only/--all/--interactive can be used.");
>
> Good points, I will use that in the next version of the patch. Just a
> note about the !! idiom (which I can't stand, fwiw): my version just
> added the variables, which were all integers, initialized to zero and
> incremented by the option parser when it sees the corresponding option.
> So what I had would work too, with the extra check that:
>
> $ git commit -a -a
>
> etc would give the error
>
> Only one of --include/--only/--all/--interactive can be used.
>
> which is acutally accurate.
Hm, why? The user used only one of them. The error message does not say
that you cannot pass the same one multiple times. And I don't think that
passing the same boolean flag twice should be treated as an usage error
either. There's no contradiction in wanting all files and, well, all
files to be committed.
Sidenote: The "or mask" stuff in the option parser would probably
prevent you from catching "-a -a" anyway, because the flag becomes truly
boolean ;-)
Björn
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Wincent Colaiuta @ 2007-11-06 17:43 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Schindelin, Junio C Hamano, Steven Grimm, git
In-Reply-To: <20071106124833.GA25637@artemis.corp>
El 6/11/2007, a las 13:48, Pierre Habouzit escribió:
> On Tue, Nov 06, 2007 at 12:25:33PM +0000, Johannes Schindelin wrote:
>> Hi,
>>
>> On Tue, 6 Nov 2007, Junio C Hamano wrote:
>>
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>>
>>>>> In the same way, I would expect "git revert <commit> -- file" to
>>>>> undo the
>>>>> changes in that commit to _that_ file (something like "git merge-
>>>>> file
>>>>> file <commit>:file <commit>^:file"), but this time commit it,
>>>>> since it
>>>>> was committed at one stage.
>>>>
>>>> Allowing people to revert or cherry pick partially by using
>>>> paths limiter is a very good idea; ...
>>>
>>> As Pierre said earlier, a partial revert via "revert <commit> --
>>> <paths>" and a partial cherry-pick would make quite a lot of
>>> sense, and in addition, it should not be too hard to add.
>>
>> Yes, but Pierre also said earlier that people want to revert their
>> local
>> changes. And the logical thing to try that really is
>>
>> git revert <path>
>>
>> Now, if you read that out in English, it does not make too much
>> sense:
>> "revert the path" (not "revert the _changes_ to that file"). But
>> it is
>> what people try to do.
>>
>> However, IIUC another thing Pierre mentioned is that
>>
>> $scm revert <commit> <path>
>>
>> commonly means "revert the file _to the version_ stored in <commit>".
>> This is just different enough from "revert the _changes_ to that file
>> stored in <commit>" to bite people, no?
>
> Yeah but that's what checkout is for. The main source of iritation
> for
> new users comes (IMHO) from svn, where `svn revert path/to/file` is
> part
> of the workflow: in case of a conflict when you `svn up`, you have
> either to:
> (1) fix the conflict and `svn resolved path/to/file`
> (2) drop your changes and take the trunk version `svn revert path/
> to/file`
>
> People really expect git revert -- path/to/file to do the same as git
> checkout HEAD -- path/to/file. Though I believe that like I said,
> maybe
> we don't wan't git revert -- path/to/file to become the first class
> command to do that, but rather to do what the user meant, hinting
> him in
> the direction of the proper command. I wasn't really advocating that
> git-revert should be a complete implementation of what git checkout
> <comitish> -- <paths> does. YMMV.
I agree; they're semantically different and it wouldn't be a good
thing to start blurring the lines between them too much. It's just
unfortunate that the term "revert" is used by most other SCMs to mean
something different than what it means in "git-revert". I think the
best path here is education, what Pierre says, rather than changing
git-revert's semantics.
The other changes discussed so far in this thread (path-limiting git-
revert with preserving its semantics) seem like a good thing.
Cheers,
Wincent
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Pascal Obry @ 2007-11-06 17:52 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Steffen Prohaska, Abdelrazak Younes, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711060857140.8577@ds9.cixit.se>
Peter Karlsson a écrit :
> I got errors almost right away when trying that (I need text mode to
> interface with some other programs), so Cygwin-git is a no-go for me at
Won't it be possible for you to have a specific mount point using
textmode and one with binmode ? This should allow you to have the best
of both world. Note that I've never done that so I don't know if it is
working fine.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Pierre Habouzit @ 2007-11-06 17:56 UTC (permalink / raw)
To: Nicolas Pitre, Daniel Barkalow, Jeff King, Git ML
In-Reply-To: <20071105175654.GD6205@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
On the same vein, with today's next:
$ git push origin :teaser
To ssh://git.corp/srv/git/mmsx.git
- [deleting] teaser
refs/heads/teaser: 05518bc7df1af680447f58b034b108f66668db03 -> deleted
Everything up-to-date
fatal: Invalid revision range 05518bc7df1af680447f58b034b108f66668db03..0000000000000000000000000000000000000000
fatal: ambiguous argument 'refs/heads/teaser': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Junio C Hamano @ 2007-11-06 18:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0711061230540.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Well, I think that _if_ we allow "git revert <path>" to mean "revert the
> changes to <path>, relative to the index" (which would be the same as "git
> checkout <path>"), then committing that change just does not make sense.
>
> And it is this behaviour that people are seeking, not "git revert <commit>
> <path>".
Heh, I found this in the recent log somewhere.
<gitte> Really, I wonder how difficult git is for people who are not
brainwashed by cvs/svn, and unfortunately enough, partly by bzr and hg.
<gitte> From a user perspective, you might be correct. But then we have to
add 1000 commands to reflect the English language.
<gitte> Not what I want. [06:46]
I am wondering who said it ;-).
But anyway, I am inclined to agree that accepting "$scm revert
paths.." as a synonym for "git checkout -- paths..."
^ permalink raw reply
* Re: git pull opinion
From: Pascal Obry @ 2007-11-06 18:07 UTC (permalink / raw)
To: Aghiles; +Cc: git
In-Reply-To: <3abd05a90711051352t2f6be00bsa862585abd370fb1@mail.gmail.com>
Aghiles a écrit :
> Hello,
>
> I am not sure this is the best place to write about this. Anyway,
> we just switched a couple of repositories to git (from svn) here
> at work and one thing people find annoying is a pull into
> a dirty directory. Before the "stash" feature it was even worse
> but now we can type:
>
> git stash
> git pull
> git stash apply
>
> But isn't that something we should be able to specify to the "pull"
> command ? Additionally and if I am not mistakn, those commands will
> create "dangling" commits and blobs. So one has to execute:
>
> git prune
>
> Is there an "easier" way to pull into a dirty directory ?
I'm using:
$ git config --global alias.update '!git stash && git pull && git stash
apply'
Then in a git repository just do:
$ git update
> ps; if someone is interested to hear what is the general opinion
> on switching to git from svn in our company, I could elaborate.
Would be nice to hear about that indeed.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Jeff King @ 2007-11-06 18:09 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Daniel Barkalow, Git ML
In-Reply-To: <20071106175627.GB9517@artemis.corp>
On Tue, Nov 06, 2007 at 06:56:27PM +0100, Pierre Habouzit wrote:
> On the same vein, with today's next:
>
> $ git push origin :teaser
> To ssh://git.corp/srv/git/mmsx.git
> - [deleting] teaser
> refs/heads/teaser: 05518bc7df1af680447f58b034b108f66668db03 -> deleted
> Everything up-to-date
> fatal: Invalid revision range 05518bc7df1af680447f58b034b108f66668db03..0000000000000000000000000000000000000000
> fatal: ambiguous argument 'refs/heads/teaser': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
I can't replicate this output; can you provide more information on your
test repo?
If it is related to the bug we have been discussing, there haven't been
any fixes applied yet. :)
-Peff
^ permalink raw reply
* Re: git pull opinion
From: Junio C Hamano @ 2007-11-06 18:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Aghiles, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0711061159240.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> A pull is just a fetch and a merge. And a merge is a commit with more
> than one parent. So you can use the command "git reset --hard HEAD^" to
> undo a merge, just as you can undo any other commit.
*DANGER*
A pull is usually just a fetch and a merge, but sometimes it can
fast forward. ORIG_HEAD, not HEAD^, points at the previous HEAD
location in both cases.
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Junio C Hamano @ 2007-11-06 18:23 UTC (permalink / raw)
To: Jeff King; +Cc: Pierre Habouzit, Daniel Barkalow, Git ML
In-Reply-To: <20071106180910.GA25934@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Nov 06, 2007 at 06:56:27PM +0100, Pierre Habouzit wrote:
>
>> On the same vein, with today's next:
>>
>> $ git push origin :teaser
>> To ssh://git.corp/srv/git/mmsx.git
>> - [deleting] teaser
>> refs/heads/teaser: 05518bc7df1af680447f58b034b108f66668db03 -> deleted
>> Everything up-to-date
>> fatal: Invalid revision range 05518bc7df1af680447f58b034b108f66668db03..0000000000000000000000000000000000000000
>> fatal: ambiguous argument 'refs/heads/teaser': unknown revision or path not in the working tree.
>> Use '--' to separate paths from revisions
Isn't this coming from a loosely written post-receive hook that
wants to send mail or something and forgets that a ref could be
removed?
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Johannes Schindelin @ 2007-11-06 18:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <7v8x5bi703.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 6 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Well, I think that _if_ we allow "git revert <path>" to mean "revert the
> > changes to <path>, relative to the index" (which would be the same as "git
> > checkout <path>"), then committing that change just does not make sense.
> >
> > And it is this behaviour that people are seeking, not "git revert <commit>
> > <path>".
>
> Heh, I found this in the recent log somewhere.
>
> <gitte> Really, I wonder how difficult git is for people who are not
> brainwashed by cvs/svn, and unfortunately enough, partly by bzr and hg.
> <gitte> From a user perspective, you might be correct. But then we have to
> add 1000 commands to reflect the English language.
> <gitte> Not what I want. [06:46]
>
> I am wondering who said it ;-).
Now, that is not fair, using my own words against me ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: git pull opinion
From: Johannes Schindelin @ 2007-11-06 18:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aghiles, Jakub Narebski, git
In-Reply-To: <7v1wb3i6nx.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 6 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > A pull is just a fetch and a merge. And a merge is a commit with more
> > than one parent. So you can use the command "git reset --hard HEAD^" to
> > undo a merge, just as you can undo any other commit.
>
> *DANGER*
>
> A pull is usually just a fetch and a merge, but sometimes it can fast
> forward. ORIG_HEAD, not HEAD^, points at the previous HEAD location in
> both cases.
Oops. Right.
Thanks,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] cgit v0.7
From: Patrick Aljord @ 2007-11-06 18:39 UTC (permalink / raw)
To: git list
In-Reply-To: <8c5c35580711060044i7a3d0134p42e9437cbe2a258b@mail.gmail.com>
Looks great, thanks for the new release.
It would be great if when a commit message contains something such as
#1234 it would automatically link to the bug tracker page of that bug
(like Trac does) by preconfiguring the bugtracker URL.
Such as "bug #238 test for root-window that XFree86 fixed in their"
would link the "#238" part to
http://bugs.freedesktop.org/show_bug.cgi?id=238
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Jeff King @ 2007-11-06 18:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, Daniel Barkalow, Git ML
In-Reply-To: <7vwssvgrm6.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 06, 2007 at 10:23:45AM -0800, Junio C Hamano wrote:
> >> $ git push origin :teaser
> >> To ssh://git.corp/srv/git/mmsx.git
> >> - [deleting] teaser
> >> refs/heads/teaser: 05518bc7df1af680447f58b034b108f66668db03 -> deleted
> >> Everything up-to-date
> >> fatal: Invalid revision range 05518bc7df1af680447f58b034b108f66668db03..0000000000000000000000000000000000000000
> >> fatal: ambiguous argument 'refs/heads/teaser': unknown revision or path not in the working tree.
> >> Use '--' to separate paths from revisions
>
> Isn't this coming from a loosely written post-receive hook that
> wants to send mail or something and forgets that a ref could be
> removed?
That would make sense. I was wondering how in the world he managed to
provoke output from git-push that came after the send_pack call. So I
think this is unrelated to the bug we were discussing (although the
'Everything up-to-date' message is easily reproducible and seems a bit
silly given that we did push some changes).
-Peff
^ permalink raw reply
* Re: [PATCH 04/10] Migrate git-clone to use git-rev-parse --parseopt
From: Nicolas Pitre @ 2007-11-06 19:04 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <1194172262-1563-5-git-send-email-madcoder@debian.org>
On Sun, 4 Nov 2007, Pierre Habouzit wrote:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> git-clone.sh | 102 +++++++++++++++++++++++++++++++++-------------------------
> 1 files changed, 58 insertions(+), 44 deletions(-)
Well, this patch was merged in "next" and broke git-clone rather badly.
Just try something as fundamental as this:
$ git clone git://git.kernel.org/pub/scm/git/git.git
fatal: Not a git repository
Don't we have test cases covering this really basic operation?
Nicolas
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Robin Rosenberg @ 2007-11-06 19:27 UTC (permalink / raw)
To: Pascal Obry
Cc: Peter Karlsson, Steffen Prohaska, Abdelrazak Younes,
Git Mailing List
In-Reply-To: <4730A9C3.1090006@obry.net>
tisdag 06 november 2007 skrev Pascal Obry:
> Peter Karlsson a écrit :
> > I got errors almost right away when trying that (I need text mode to
> > interface with some other programs), so Cygwin-git is a no-go for me at
>
> Won't it be possible for you to have a specific mount point using
> textmode and one with binmode ? This should allow you to have the best
> of both world. Note that I've never done that so I don't know if it is
> working fine.
I do that. It works fine. I've set up such paths so I have /cygdrive/c for textmode and
/binmode/c for binary mode and some other extra binary paths for convenience.
-- robin
^ 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