* [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
* [PATCH] contrib/hooks/post-receive-email: reformat to wrap comments at 76 chars
From: Gerrit Pape @ 2007-11-06 13:48 UTC (permalink / raw)
To: git, Junio C Hamano
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
contrib/hooks/post-receive-email | 199 ++++++++++++++++++++------------------
1 files changed, 107 insertions(+), 92 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 379cedc..9b9a977 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -2,24 +2,26 @@
#
# Copyright (c) 2007 Andy Parkins
#
-# An example hook script to mail out commit update information. This hook sends emails
-# listing new revisions to the repository introduced by the change being reported. The
-# rule is that (for branch updates) each commit will appear on one email and one email
-# only.
+# An example hook script to mail out commit update information. This hook
+# sends emails listing new revisions to the repository introduced by the
+# change being reported. The rule is that (for branch updates) each commit
+# will appear on one email and one email only.
#
-# This hook is stored in the contrib/hooks directory. Your distribution will have put
-# this somewhere standard. You should make this script executable then link to it in
-# the repository you would like to use it in. For example, on debian the hook is stored
-# in /usr/share/doc/git-core/contrib/hooks/post-receive-email:
+# This hook is stored in the contrib/hooks directory. Your distribution
+# will have put this somewhere standard. You should make this script
+# executable then link to it in the repository you would like to use it in.
+# For example, on debian the hook is stored in
+# /usr/share/doc/git-core/contrib/hooks/post-receive-email:
#
# chmod a+x post-receive-email
# cd /path/to/your/repository.git
# ln -sf /usr/share/doc/git-core/contrib/hooks/post-receive-email hooks/post-receive
#
-# This hook script assumes it is enabled on the central repository of a project, with
-# all users pushing only to it and not between each other. It will still work if you
-# don't operate in that style, but it would become possible for the email to be from
-# someone other than the person doing the push.
+# This hook script assumes it is enabled on the central repository of a
+# project, with all users pushing only to it and not between each other. It
+# will still work if you don't operate in that style, but it would become
+# possible for the email to be from someone other than the person doing the
+# push.
#
# Config
# ------
@@ -28,11 +30,11 @@
# emails for every ref update.
# hooks.announcelist
# This is the list that all pushes of annotated tags will go to. Leave it
-# blank to default to the mailinglist field. The announce emails lists the
-# short log summary of the changes since the last annotated tag.
+# blank to default to the mailinglist field. The announce emails lists
+# the short log summary of the changes since the last annotated tag.
# hooks.envelopesender
-# If set then the -f option is passed to sendmail to allow the envelope sender
-# address to be set
+# If set then the -f option is passed to sendmail to allow the envelope
+# sender address to be set
#
# Notes
# -----
@@ -49,8 +51,8 @@
# this is and calls the appropriate body-generation routine after outputting
# the common header
#
-# Note this function doesn't actually generate any email output, that is taken
-# care of by the functions it calls:
+# Note this function doesn't actually generate any email output, that is
+# taken care of by the functions it calls:
# - generate_email_header
# - generate_create_XXXX_email
# - generate_update_XXXX_email
@@ -225,8 +227,9 @@ generate_create_branch_email()
echo $LOGBEGIN
# This shows all log entries that are not already covered by
# another ref - i.e. commits that are now accessible from this
- # ref that were previously not accessible (see generate_update_branch_email
- # for the explanation of this command)
+ # ref that were previously not accessible
+ # (see generate_update_branch_email for the explanation of this
+ # command)
git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
git rev-list --pretty --stdin $newrev
echo $LOGEND
@@ -254,9 +257,10 @@ generate_update_branch_email()
#
# git-rev-list N ^O ^X ^N
#
- # So, we need to build up the list more carefully. git-rev-parse will
- # generate a list of revs that may be fed into git-rev-list. We can get
- # it to make the "--not --all" part and then filter out the "^N" with:
+ # So, we need to build up the list more carefully. git-rev-parse
+ # will generate a list of revs that may be fed into git-rev-list.
+ # We can get it to make the "--not --all" part and then filter out
+ # the "^N" with:
#
# git-rev-parse --not --all | grep -v N
#
@@ -266,16 +270,17 @@ generate_update_branch_email()
# git-rev-list N ^O ^X
#
# This leaves a problem when someone else updates the repository
- # while this script is running. Their new value of the ref we're working
- # on would be included in the "--not --all" output; and as our $newrev
- # would be an ancestor of that commit, it would exclude all of our
- # commits. What we really want is to exclude the current value of
- # $refname from the --not list, rather than N itself. So:
+ # while this script is running. Their new value of the ref we're
+ # working on would be included in the "--not --all" output; and as
+ # our $newrev would be an ancestor of that commit, it would exclude
+ # all of our commits. What we really want is to exclude the current
+ # value of $refname from the --not list, rather than N itself. So:
#
# git-rev-parse --not --all | grep -v $(git-rev-parse $refname)
#
- # Get's us to something pretty safe (apart from the small time between
- # refname being read, and git-rev-parse running - for that, I give up)
+ # Get's us to something pretty safe (apart from the small time
+ # between refname being read, and git-rev-parse running - for that,
+ # I give up)
#
#
# Next problem, consider this:
@@ -283,18 +288,18 @@ generate_update_branch_email()
# \
# * --- X --- * --- N ($newrev)
#
- # That is to say, there is no guarantee that oldrev is a strict subset of
- # newrev (it would have required a --force, but that's allowed). So, we
- # can't simply say rev-list $oldrev..$newrev. Instead we find the common
- # base of the two revs and list from there.
+ # That is to say, there is no guarantee that oldrev is a strict
+ # subset of newrev (it would have required a --force, but that's
+ # allowed). So, we can't simply say rev-list $oldrev..$newrev.
+ # Instead we find the common base of the two revs and list from
+ # there.
#
- # As above, we need to take into account the presence of X; if another
- # branch is already in the repository and points at some of the revisions
- # that we are about to output - we don't want them. The solution is as
- # before: git-rev-parse output filtered.
+ # As above, we need to take into account the presence of X; if
+ # another branch is already in the repository and points at some of
+ # the revisions that we are about to output - we don't want them.
+ # The solution is as before: git-rev-parse output filtered.
#
- # Finally, tags:
- # 1 --- 2 --- O --- T --- 3 --- 4 --- N
+ # Finally, tags: 1 --- 2 --- O --- T --- 3 --- 4 --- N
#
# Tags pushed into the repository generate nice shortlog emails that
# summarise the commits between them and the previous tag. However,
@@ -302,13 +307,14 @@ generate_update_branch_email()
# for a branch update. Therefore we still want to output revisions
# that have been output on a tag email.
#
- # Luckily, git-rev-parse includes just the tool. Instead of using "--all"
- # we use "--branches"; this has the added benefit that "remotes/" will
- # be ignored as well.
-
- # List all of the revisions that were removed by this update, in a fast forward
- # update, this list will be empty, because rev-list O ^N is empty. For a non
- # fast forward, O ^N is the list of removed revisions
+ # Luckily, git-rev-parse includes just the tool. Instead of using
+ # "--all" we use "--branches"; this has the added benefit that
+ # "remotes/" will be ignored as well.
+
+ # List all of the revisions that were removed by this update, in a
+ # fast forward update, this list will be empty, because rev-list O
+ # ^N is empty. For a non fast forward, O ^N is the list of removed
+ # revisions
fast_forward=""
rev=""
for rev in $(git rev-list $newrev..$oldrev)
@@ -321,10 +327,10 @@ generate_update_branch_email()
fi
# List all the revisions from baserev to newrev in a kind of
- # "table-of-contents"; note this list can include revisions that have
- # already had notification emails and is present to show the full detail
- # of the change from rolling back the old revision to the base revision and
- # then forward to the new revision
+ # "table-of-contents"; note this list can include revisions that
+ # have already had notification emails and is present to show the
+ # full detail of the change from rolling back the old revision to
+ # the base revision and then forward to the new revision
for rev in $(git rev-list $oldrev..$newrev)
do
revtype=$(git cat-file -t "$rev")
@@ -334,19 +340,20 @@ generate_update_branch_email()
if [ "$fast_forward" ]; then
echo " from $oldrev ($oldrev_type)"
else
- # 1. Existing revisions were removed. In this case newrev is a
- # subset of oldrev - this is the reverse of a fast-forward,
- # a rewind
- # 2. New revisions were added on top of an old revision, this is
- # a rewind and addition.
+ # 1. Existing revisions were removed. In this case newrev
+ # is a subset of oldrev - this is the reverse of a
+ # fast-forward, a rewind
+ # 2. New revisions were added on top of an old revision,
+ # this is a rewind and addition.
- # (1) certainly happened, (2) possibly. When (2) hasn't happened,
- # we set a flag to indicate that no log printout is required.
+ # (1) certainly happened, (2) possibly. When (2) hasn't
+ # happened, we set a flag to indicate that no log printout
+ # is required.
echo ""
- # Find the common ancestor of the old and new revisions and compare
- # it with newrev
+ # Find the common ancestor of the old and new revisions and
+ # compare it with newrev
baserev=$(git merge-base $oldrev $newrev)
rewind_only=""
if [ "$baserev" = "$newrev" ]; then
@@ -387,21 +394,22 @@ generate_update_branch_email()
git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
git rev-list --pretty --stdin $oldrev..$newrev
- # XXX: Need a way of detecting whether git rev-list actually outputted
- # anything, so that we can issue a "no new revisions added by this
- # update" message
+ # XXX: Need a way of detecting whether git rev-list actually
+ # outputted anything, so that we can issue a "no new
+ # revisions added by this update" message
echo $LOGEND
else
echo "No new revisions were added by this update."
fi
- # The diffstat is shown from the old revision to the new revision. This
- # is to show the truth of what happened in this change. There's no point
- # showing the stat from the base to the new revision because the base
- # is effectively a random revision at this point - the user will be
- # interested in what this revision changed - including the undoing of
- # previous revisions in the case of non-fast forward updates.
+ # The diffstat is shown from the old revision to the new revision.
+ # This is to show the truth of what happened in this change.
+ # There's no point showing the stat from the base to the new
+ # revision because the base is effectively a random revision at this
+ # point - the user will be interested in what this revision changed
+ # - including the undoing of previous revisions in the case of
+ # non-fast forward updates.
echo ""
echo "Summary of changes:"
git diff-tree --stat --summary --find-copies-harder $oldrev..$newrev
@@ -448,7 +456,8 @@ generate_update_atag_email()
#
generate_atag_email()
{
- # Use git-for-each-ref to pull out the individual fields from the tag
+ # Use git-for-each-ref to pull out the individual fields from the
+ # tag
eval $(git for-each-ref --shell --format='
tagobject=%(*objectname)
tagtype=%(*objecttype)
@@ -459,8 +468,10 @@ generate_atag_email()
echo " tagging $tagobject ($tagtype)"
case "$tagtype" in
commit)
+
# If the tagged object is a commit, then we assume this is a
- # release, and so we calculate which tag this tag is replacing
+ # release, and so we calculate which tag this tag is
+ # replacing
prevtag=$(git describe --abbrev=0 $newrev^ 2>/dev/null)
if [ -n "$prevtag" ]; then
@@ -477,25 +488,27 @@ generate_atag_email()
echo ""
echo $LOGBEGIN
- # Show the content of the tag message; this might contain a change log
- # or release notes so is worth displaying.
+ # Show the content of the tag message; this might contain a change
+ # log or release notes so is worth displaying.
git cat-file tag $newrev | sed -e '1,/^$/d'
echo ""
case "$tagtype" in
commit)
- # Only commit tags make sense to have rev-list operations performed
- # on them
+ # Only commit tags make sense to have rev-list operations
+ # performed on them
if [ -n "$prevtag" ]; then
# Show changes since the previous release
git rev-list --pretty=short "$prevtag..$newrev" | git shortlog
else
- # No previous tag, show all the changes since time began
+ # No previous tag, show all the changes since time
+ # began
git rev-list --pretty=short $newrev | git shortlog
fi
;;
*)
- # XXX: Is there anything useful we can do for non-commit objects?
+ # XXX: Is there anything useful we can do for non-commit
+ # objects?
;;
esac
@@ -544,13 +557,14 @@ generate_update_general_email()
#
generate_general_email()
{
- # Unannotated tags are more about marking a point than releasing a version;
- # therefore we don't do the shortlog summary that we do for annotated tags
- # above - we simply show that the point has been marked, and print the log
- # message for the marked point for reference purposes
+ # Unannotated tags are more about marking a point than releasing a
+ # version; therefore we don't do the shortlog summary that we do for
+ # annotated tags above - we simply show that the point has been
+ # marked, and print the log message for the marked point for
+ # reference purposes
#
- # Note this section also catches any other reference type (although there
- # aren't any) and deals with them in the same way.
+ # Note this section also catches any other reference type (although
+ # there aren't any) and deals with them in the same way.
echo ""
if [ "$newrev_type" = "commit" ]; then
@@ -558,10 +572,10 @@ generate_general_email()
git show --no-color --root -s $newrev
echo $LOGEND
else
- # What can we do here? The tag marks an object that is not a commit,
- # so there is no log for us to display. It's probably not wise to
- # output git-cat-file as it could be a binary blob. We'll just say how
- # big it is
+ # What can we do here? The tag marks an object that is not
+ # a commit, so there is no log for us to display. It's
+ # probably not wise to output git-cat-file as it could be a
+ # binary blob. We'll just say how big it is
echo "$newrev is a $newrev_type, and is $(git cat-file -s $newrev) bytes long."
fi
}
@@ -604,8 +618,8 @@ if [ -z "$GIT_DIR" ]; then
fi
projectdesc=$(sed -ne '1p' "$GIT_DIR/description")
-# Check if the description is unchanged from it's default, and shorten it to a
-# more manageable length if it is
+# Check if the description is unchanged from it's default, and shorten it to
+# a more manageable length if it is
if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
then
projectdesc="UNNAMED PROJECT"
@@ -616,11 +630,12 @@ announcerecipients=$(git repo-config hooks.announcelist)
envelopesender=$(git-repo-config hooks.envelopesender)
# --- Main loop
-# Allow dual mode: run from the command line just like the update hook, or if
-# no arguments are given then run as a hook script
+# Allow dual mode: run from the command line just like the update hook, or
+# if no arguments are given then run as a hook script
if [ -n "$1" -a -n "$2" -a -n "$3" ]; then
# Output to the terminal in command line mode - if someone wanted to
- # resend an email; they could redirect the output to sendmail themselves
+ # resend an email; they could redirect the output to sendmail
+ # themselves
PAGER= generate_email $2 $3 $1
else
while read oldrev newrev refname
--
1.5.3.5
^ permalink raw reply related
* [PATCH] contrib/hooks/post-receive-email: fix typo
From: Gerrit Pape @ 2007-11-06 13:48 UTC (permalink / raw)
To: git, Junio C Hamano
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
contrib/hooks/post-receive-email | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 2aa9bb5..379cedc 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -30,7 +30,7 @@
# This is the list that all pushes of annotated tags will go to. Leave it
# blank to default to the mailinglist field. The announce emails lists the
# short log summary of the changes since the last annotated tag.
-# hook.envelopesender
+# hooks.envelopesender
# If set then the -f option is passed to sendmail to allow the envelope sender
# address to be set
#
--
1.5.3.5
^ permalink raw reply related
* [PATCH] hooks--update: fix test for properly set up project description file
From: Gerrit Pape @ 2007-11-06 13:47 UTC (permalink / raw)
To: git, Junio C Hamano
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")
+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
fi
--
1.5.3.5
^ permalink raw reply related
* Re: git-merge ignore specific files
From: Jakub Narebski @ 2007-11-06 13:46 UTC (permalink / raw)
To: Bill Priest; +Cc: git
In-Reply-To: <323303.75335.qm@web55010.mail.re4.yahoo.com>
Bill Priest wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Bill Priest wrote:
>>
>>> All,
>>> I have two branches that are slightly different and
>>> most changes "belong" in both. There are a handful of
>>> files/directories that are disparate. Is there any
>>> way in git to tell it not to merge these files? Kind
>>> of like .gitignore but for merges.
>>
>> Most probably you can use gitattributes for that.
>> Or you can use 'our' merge strategy.
>
> Can you point me to some docs on "our" merge strategy?
git-merge(1), section "Merge strategies":
ours::
This resolves any number of heads, but the result of the
merge is always the current branch head. It is meant to
be used to supersede old development history of side
branches.
>>> In addition I'd like a way to specify to git-merge
>>> to leave all merged files unrecorded in the index.
>>> Then as I go through each file making sure that the
>>> merge "makes sense" (not that git did the right thing;
>>> but that I want the changes in both branches) that
>>> I add the change to the index.
>>
>> You can use gitattributes for that.
>
> I did man gitattributes and nothing jumped out at me
> as far as an attribute that I could set/unset that
> would stop a file from being merged. What am I
> missing?
See `diff' and `merge' attributes, for example
*.nbi -diff -merge
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-merge ignore specific files
From: Bill Priest @ 2007-11-06 13:15 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <fgpong$fmn$1@ger.gmane.org>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Bill Priest wrote:
>
> > All,
> > I have two branches that are slightly different
> and
> > most changes "belong" in both. There are a
> handful of
> > files/directories that are disparate. Is there
> any
> > way in git to tell it not to merge these files?
> Kind
> > of like .gitignore but for merges.
>
> Most probably you can use gitattributes for that.
> Or you can use 'our' merge strategy.
Can you point me to some docs on "our" merge strategy?
>
> > In addition I'd like a way to specify to
> git-merge
> > to leave all merged files unrecorded in the index.
>
> > Then as I go through each file making sure that
> the
> > merge "makes sense" (not that git did the right
> thing;
> > but that I want the changes in both branches) that
> I
> > add the change to the index.
>
> You can use gitattributes for that.
I did man gitattributes and nothing jumped out at me
as far as an attribute that I could set/unset that
would stop a file from being merged. What am I
missing?
Bill
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: git-merge ignore specific files
From: Jakub Narebski @ 2007-11-06 13:03 UTC (permalink / raw)
To: git
In-Reply-To: <174134.11501.qm@web55007.mail.re4.yahoo.com>
Bill Priest wrote:
> All,
> I have two branches that are slightly different and
> most changes "belong" in both. There are a handful of
> files/directories that are disparate. Is there any
> way in git to tell it not to merge these files? Kind
> of like .gitignore but for merges.
Most probably you can use gitattributes for that.
Or you can use 'our' merge strategy.
> In addition I'd like a way to specify to git-merge
> to leave all merged files unrecorded in the index.
> Then as I go through each file making sure that the
> merge "makes sense" (not that git did the right thing;
> but that I want the changes in both branches) that I
> add the change to the index.
You can use gitattributes for that.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-merge ignore specific files
From: Andreas Ericsson @ 2007-11-06 12:53 UTC (permalink / raw)
To: Bill Priest; +Cc: git
In-Reply-To: <174134.11501.qm@web55007.mail.re4.yahoo.com>
Bill Priest wrote:
> All,
> I have two branches that are slightly different and
> most changes "belong" in both. There are a handful of
> files/directories that are disparate. Is there any
> way in git to tell it not to merge these files? Kind
> of like .gitignore but for merges.
> In addition I'd like a way to specify to git-merge
> to leave all merged files unrecorded in the index.
> Then as I go through each file making sure that the
> merge "makes sense" (not that git did the right thing;
> but that I want the changes in both branches) that I
> add the change to the index.
> I'm sure that I'm probably using git "incorrectly"
> and I welcome suggestions for modifying my workflow to
> a git style.
>
> Any and all suggestions greatly appreciated,
>
At a cursory glance at the sources, it looks as if you should be able to
get what you want with pretty small modifications to builtin-read-tree.c
and git-merge.sh.
Specifically, 'git read-tree' (which does the heavy lifting during merges)
takes --exclude-per-directory as an argument. You want to teach 'git merge'
to do the same and pass that argument along to 'git read-tree'. Then it's
just a matter of maintaining two sets of .gitignore files, one of which
you'd probably want to call .mergeignore (or something) and make sure you
don't forget to pass that option when you merge (although I assume you'd
notice if you'd forgotten it during conflict resolution).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Pierre Habouzit @ 2007-11-06 12:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Steven Grimm, git
In-Reply-To: <Pine.LNX.4.64.0711061216330.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]
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.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git-merge ignore specific files
From: Bill Priest @ 2007-11-06 12:38 UTC (permalink / raw)
To: git
All,
I have two branches that are slightly different and
most changes "belong" in both. There are a handful of
files/directories that are disparate. Is there any
way in git to tell it not to merge these files? Kind
of like .gitignore but for merges.
In addition I'd like a way to specify to git-merge
to leave all merged files unrecorded in the index.
Then as I go through each file making sure that the
merge "makes sense" (not that git did the right thing;
but that I want the changes in both branches) that I
add the change to the index.
I'm sure that I'm probably using git "incorrectly"
and I welcome suggestions for modifying my workflow to
a git style.
Any and all suggestions greatly appreciated,
Bill
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ 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 12:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <7vode8j7o5.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 5 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 5 Nov 2007, Junio C Hamano wrote:
> >
> >> Allowing people to revert or cherry pick partially by using paths
> >> limiter is a very good idea; the whole "it comes from a commit so we
> >> also commit" feels an utter nonsense, though.
> >
> > No.
> >
> > When "git revert <commit>" commits the result, "git revert <commit> --
> > <file>" should, too.
>
> I was not questioning about that part. "If 'git revert <some
> other form> foo' does not talk about commit, it should not
> commit" was what I was referring to.
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>".
Ciao,
Dscho
^ 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 12:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <7vk5oviqbe.fsf@gitster.siamese.dyndns.org>
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?
> Reusing the 'merge-recursive' part should be almost trivial. The only
> tricky part is coming up with a fake tree using base and next commit in
> revert_or_cherry_pick() for this purpose.
FWIW I really wanted to use the merge-file machinery, not the
merge-recursive one. But since "<path>" can be a directory, too, I was
mistaken, and you are correct, as always.
> As to "reverting to the index" case, if somebody is interested in doing
> a builtin-checkout.c, please keep in mind that major parts of that work
> should be made available to the implementation of "git revert [--]
> <paths>", as it appears that it will be exactly the same as "git
> checkout" with the same set of options.
I was planning to put cmd_checkout() into builtin-reset.c for that reason.
But first things first, that "git remote prune" with --mirror'ed
repositories misbehaviour annoys me just enough that I started converting
this script first. It has been stable enough for quite a long time, and
the script now shows its limitations.
Besides, remote.[ch] makes it easy, even if not _really_ easy.
Ciao,
Dscho
^ 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 12:16 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Steven Grimm, Pierre Habouzit, Git Mailing List
In-Reply-To: <47305536.5010308@viscovery.net>
Hi,
On Tue, 6 Nov 2007, Johannes Sixt wrote:
> Junio C Hamano schrieb:
> > I am wondering what "git cherry-pick -- <paths>" should do. My
> > current thinking is that it would not make any sense at all.
>
> IMO, at least "git cherry-pick -n -- <paths>" makes tons of sense.
I guess you missed that Junio did not specify any commit. With a commit,
I agree, it makes tons of sense.
Without a commit, it would default to... uhm... HEAD? And applying the
changes to a given file, which are already in HEAD, no, that does not make
sense.
Ciao,
Dscho
^ permalink raw reply
* Re: git pull opinion
From: Andreas Ericsson @ 2007-11-06 12:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bill Lear, Junio C Hamano, Aghiles, git
In-Reply-To: <Pine.LNX.4.64.0711061204160.4362@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 6 Nov 2007, Andreas Ericsson wrote:
>
>> Johannes Schindelin wrote:
>>
>>> On Tue, 6 Nov 2007, Andreas Ericsson wrote:
>>>
>>>> Bill Lear wrote:
>>>>> On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:
>>>>>> Aghiles <aghilesk@gmail.com> writes:
>>>>>>
>>>>>>> Is there an "easier" way to pull into a dirty directory ? I am
>>>>>>> asking this to make sure I understand the problem and not
>>>>>>> because I find it annoying to type those 4 commands to perform
>>>>>>> a pull (although some of my colleagues do find that annoying :).
>>>>>> You need to switch your mindset from centralized SVN workflow.
>>>>>>
>>>>>> The beauty of distributedness is that it redefines the meaning
>>>>>> of "to commit". In distributed systems, the act of committing
>>>>>> is purely checkpointing and it is not associated with publishing
>>>>>> the result to others as centralized systems force you to.
>>>>>>
>>>>>> Stop thinking like "I need to integrate the changes from
>>>>>> upstream into my WIP to keep up to date." You first finish what
>>>>>> you are currently doing, at least to the point that it is
>>>>>> stable, make a commit to mark that state, and then start
>>>>>> thinking about what other people did. You may most likely do a
>>>>>> "git fetch" followed by "git rebase" to update your WIP on top
>>>>>> of the updated work by others.
>>>>>>
>>>>>> Once you get used to that, you would not have "a dirty
>>>>>> directory" problem.
>>>>> I respectfully beg to differ. I think it is entirely reasonable, and
>>>>> not a sign of "centralized" mindset, to want to pull changes others
>>>>> have made into your dirty repository with a single command.
>>>>>
>>>> I find it much more convenient to just fetch them. I'd rather see
>>>> git-pull being given a --rebase option (which would ultimately mean
>>>> teaching git-merge about it) to rebase already committed changes on
>>>> top of the newly fetched tracking branch. It's being worked on, but
>>>> rather slowly.
>>> git-pull learning about --rebase does not mean teaching git-merge about it.
>>> See my patch, which you (and others) failed to enthusiastically embrace,
>>> which is the sole reason it is stalled.
>>>
>> I must have missed it. Found the thread now though. Gonna try the patch in
>> production for a while and see how it pans out.
>>
>> I'm curious about this hunk though. It seems unaffiliated with the --rebase
>> option as such, but was still in the patch. Would you care to clarify?
>>
>> @@ -86,7 +95,6 @@ merge_head=$(sed -e '/ not-for-merge /d' \
>>
>> case "$merge_head" in
>> '')
>> - curr_branch=$(git symbolic-ref -q HEAD)
>> case $? in
>> 0) ;;
>> 1) echo >&2 "You are not currently on a branch; you must
>> explicitly"
>>
>
> No, it is not unaffiliated. If you go back to the patch, you will find
> that this line was not deleted, but moved to the start of git-rebase.sh.
> We need to know the branch name to get the config settings, and might just
> as well reuse the branch name for the merge_head case.
>
Righto. I should learn to not write emails or read patches before 10am.
Thanks for clarifying.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git pull opinion
From: Johannes Schindelin @ 2007-11-06 12:05 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Bill Lear, Junio C Hamano, Aghiles, git
In-Reply-To: <47302D07.9030703@op5.se>
Hi,
On Tue, 6 Nov 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > On Tue, 6 Nov 2007, Andreas Ericsson wrote:
> >
> > > Bill Lear wrote:
> > > > On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:
> > > > > Aghiles <aghilesk@gmail.com> writes:
> > > > >
> > > > > > Is there an "easier" way to pull into a dirty directory ? I am
> > > > > > asking this to make sure I understand the problem and not
> > > > > > because I find it annoying to type those 4 commands to perform
> > > > > > a pull (although some of my colleagues do find that annoying :).
> > > > > You need to switch your mindset from centralized SVN workflow.
> > > > >
> > > > > The beauty of distributedness is that it redefines the meaning
> > > > > of "to commit". In distributed systems, the act of committing
> > > > > is purely checkpointing and it is not associated with publishing
> > > > > the result to others as centralized systems force you to.
> > > > >
> > > > > Stop thinking like "I need to integrate the changes from
> > > > > upstream into my WIP to keep up to date." You first finish what
> > > > > you are currently doing, at least to the point that it is
> > > > > stable, make a commit to mark that state, and then start
> > > > > thinking about what other people did. You may most likely do a
> > > > > "git fetch" followed by "git rebase" to update your WIP on top
> > > > > of the updated work by others.
> > > > >
> > > > > Once you get used to that, you would not have "a dirty
> > > > > directory" problem.
> > > > I respectfully beg to differ. I think it is entirely reasonable, and
> > > > not a sign of "centralized" mindset, to want to pull changes others
> > > > have made into your dirty repository with a single command.
> > > >
> > > I find it much more convenient to just fetch them. I'd rather see
> > > git-pull being given a --rebase option (which would ultimately mean
> > > teaching git-merge about it) to rebase already committed changes on
> > > top of the newly fetched tracking branch. It's being worked on, but
> > > rather slowly.
> >
> > git-pull learning about --rebase does not mean teaching git-merge about it.
> > See my patch, which you (and others) failed to enthusiastically embrace,
> > which is the sole reason it is stalled.
> >
>
> I must have missed it. Found the thread now though. Gonna try the patch in
> production for a while and see how it pans out.
>
> I'm curious about this hunk though. It seems unaffiliated with the --rebase
> option as such, but was still in the patch. Would you care to clarify?
>
> @@ -86,7 +95,6 @@ merge_head=$(sed -e '/ not-for-merge /d' \
>
> case "$merge_head" in
> '')
> - curr_branch=$(git symbolic-ref -q HEAD)
> case $? in
> 0) ;;
> 1) echo >&2 "You are not currently on a branch; you must
> explicitly"
>
No, it is not unaffiliated. If you go back to the patch, you will find
that this line was not deleted, but moved to the start of git-rebase.sh.
We need to know the branch name to get the config settings, and might just
as well reuse the branch name for the merge_head case.
Hth,
Dscho
^ permalink raw reply
* Re: git pull opinion
From: Johannes Schindelin @ 2007-11-06 12:02 UTC (permalink / raw)
To: Aghiles; +Cc: Jakub Narebski, git
In-Reply-To: <3abd05a90711052022j590f1faesb85f4646afd9acec@mail.gmail.com>
Hi,
On Mon, 5 Nov 2007, Aghiles wrote:
> > The consense was that you are much better off committing first, then
> > pulling. And if the work you are doing really is not committable, but
> > you _have_ to pull _now_, you use stash. Although you are quite
> > likely to revert the pull when it succeeds, and _then_ unstash.
>
> Sorry but I don't really understand why one should "revert the pull" ?
> Could elaborate for a newbie ? :)
Yes, no problem.
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.
NOTE: if you pushed that commit (merge or not), do _not_ use reset. This
effectively rewrites history, and _will_ upset people pulling from you.
If you really have to undo a commit you already published, use "git revert
<commit>".
Hth,
Dscho
^ permalink raw reply
* Re: git pull opinion
From: Johannes Schindelin @ 2007-11-06 11:59 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: Benoit Sigoure, Aghiles, git list
In-Reply-To: <20071106073455.GA19106@ins.uni-bonn.de>
Hi,
On Tue, 6 Nov 2007, Ralf Wildenhues wrote:
> * Benoit Sigoure wrote on Tue, Nov 06, 2007 at 06:29:58AM CET:
> > On Nov 6, 2007, at 5:16 AM, Aghiles wrote:
> >
> >>> who will run git stash clear? :)
> >>
> >> Yes you are right. By the way, in the context of merging into a
> >> dirty tree, "git stash clear" seems to be a dangerous command:
> >> there is a risk of loosing all your changes without a question
> >> asked!
>
> I would love it if for once in the git world, there were a pair of
> commands that would do the exact opposite of each other and where the
> naive newbie (me) would immediately recognize that from their names:
> git stash push
> git stash pop
>
> Both applied in this order should be a no-op on both the working tree,
> the index, and also the stash. There's room for extensions (pop
> --keep-stash to not remove the stashed information), explicit naming of
> stashes, doing multiple pops at once, and so on. Please don't add more
> of the git-push/git-pull, git-add/git-rm unsymmetrical interfaces.
> Even if they're perfectly clear to git intimates, each one of them
> takes precious extra time to learn due to this lack of symmetry.
>
> Since I simply don't have the time resources to just implement that,
> I'll thank you for your attention and go back to lurking mode now.
You might as well be honest, and say that they are not time constraints,
but lack of motivation. There is -- still! -- the patch "Teach "git
reflog" a subcommand to delete single entries" in "pu" to delete
single reflogs (and being in "pu" means it is only a fetch and a
cherry-pick away).
Implementing that feature would be a piece of cake, but I will not do it,
since _you_ want it, not _I_. In spite of that, I implemented that reflog
deleting, which was the hardest part of the exercise.
So, out, out with you, out of lurking mode!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Johannes Sixt @ 2007-11-06 11:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Steven Grimm, Pierre Habouzit,
Git Mailing List
In-Reply-To: <7vk5oviqbe.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> I am wondering what "git cherry-pick -- <paths>" should do. My
> current thinking is that it would not make any sense at all.
IMO, at least "git cherry-pick -n -- <paths>" makes tons of sense.
-- Hannes
^ permalink raw reply
* Re: [Patch] Documentation: enhanced "git for CVS users" doc about shared repositories
From: Francesco Pretto @ 2007-11-06 11:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711061052570.4362@racer.site>
Johannes Schindelin ha scritto:
>
> For most people, neither path is correct.
Yeah, I agree. I'll try to reflect this with a neutral wording :-)
In the context of the documentation, we should just take care of logical
following the example.
^ 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 11:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <7vsl3kjdct.fsf@gitster.siamese.dyndns.org>
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.
Reusing the 'merge-recursive' part should be almost trivial.
The only tricky part is coming up with a fake tree using base
and next commit in revert_or_cherry_pick() for this purpose.
When replaying the change from A->B (when cherry-picking, A is
the parent and B is what was named from the command line; when
reverting, they are the other way around), instead of doing the
three-way merge using:
merge-recursive A HEAD B
you would first come up with a modified tree B' that has the
identical contents to A _except_ the parts the path limiters
specify which are taken from B. Then running
merge-recursive A HEAD B'
would replay the revert or cherry-pick of change from A->B,
limited by the path, on top of the current HEAD.
As to "reverting to the index" case, if somebody is interested
in doing a builtin-checkout.c, please keep in mind that major
parts of that work should be made available to the
implementation of "git revert [--] <paths>", as it appears that
it will be exactly the same as "git checkout" with the same set
of options.
I am wondering what "git cherry-pick -- <paths>" should do. My
current thinking is that it would not make any sense at all.
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Johannes Schindelin @ 2007-11-06 11:01 UTC (permalink / raw)
To: Jeff King
Cc: Alex Riesen, Michael Cohen, Gerrit Pape, Fernando J. Pereda, git,
Junio C Hamano
In-Reply-To: <20071106075150.GA21694@sigill.intra.peff.net>
Hi,
On Tue, 6 Nov 2007, Jeff King wrote:
> On Tue, Nov 06, 2007 at 08:28:31AM +0100, Alex Riesen wrote:
>
> > > In Maildir format, cur and new hold the mails. :P
> >
> > 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.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] When exec() fails include the failing command in the error message
From: Ask Bjørn Hansen @ 2007-11-06 10:54 UTC (permalink / raw)
To: git; +Cc: Ask Bjørn Hansen
git-svn occasionally fails with no details as to what went wrong - this should help debug those situations.
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
---
perl/Git.pm | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 3f4080c..dca92c8 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -812,7 +812,7 @@ sub _cmd_exec {
$self->wc_subdir() and chdir($self->wc_subdir());
}
_execv_git_cmd(@args);
- die "exec failed: $!";
+ die qq[exec "@args" failed: $!];
}
# Execute the given Git command ($_[0]) with arguments ($_[1..])
--
1.5.3.5.561.g140d
^ permalink raw reply related
* Re: [Patch] Documentation: enhanced "git for CVS users" doc about shared repositories
From: Johannes Schindelin @ 2007-11-06 10:53 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Junio C Hamano, git
In-Reply-To: <47303C2E.2070103@gmail.com>
Hi,
On Tue, 6 Nov 2007, Francesco Pretto wrote:
> Junio C Hamano ha scritto:
> >> ------------------------------------------------
> >> -$ git clone foo.com:/pub/repo.git/ my-project
> >> +$ git clone foo.com:/pub/scm/repo.git/ my-project
> >> $ cd my-project
> >> ------------------------------------------------
> >
> > This part seems an unnecessary change.
> >
>
> Ironically, that's the same configuration of git.kernel.org. And I think
> is better to put immediately the project in a appropriate directory than
> to move it later.
For most people, neither path is correct. So I really don't see your
point.
Ciao,
Dscho
^ permalink raw reply
* Re: git push problem - unpack unpacker exited with error code; ng refs/heads/rel2_branch n/a (unpacker error)
From: Johannes Schindelin @ 2007-11-06 10:51 UTC (permalink / raw)
To: Piet Delaney; +Cc: Pete/Piet Delaney, git, Piet Delaney
In-Reply-To: <47303826.1000506@bluelane.com>
Hi,
On Tue, 6 Nov 2007, Piet Delaney wrote:
> I'm getting an error when I try to push back a git repository
> that I just pulled and made a slight change to:
> -------------------------------------------------------------------------------------
> -bash-3.00$ git push
> [...]
> error: failed to push to 'git://cvs.bluelane.com/home/git/blux'
For security reasons, you cannot push to git://, by default. git:// does
not have any form of authentication or encryption.
You need to use the ssh protocol (probably something like
cvs.bluelane.com:/home/git/blux in your case).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Implement selectable group ownership in git-init
From: Wincent Colaiuta @ 2007-11-06 10:31 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Junio C Hamano, git
In-Reply-To: <472F98DE.2010406@gmail.com>
El 5/11/2007, a las 23:27, Francesco Pretto escribió:
> Wincent Colaiuta ha scritto:
>> I think this proposal adds unnecessary clutter to the codebase for
>> something that can easily be achieved (and *should*) using chown,
>> chgrp,
>> or "sudo -u" etc.
>
> While still not convinced about that "unnecessary", i had to admit
> the risk
> of breaking something with my addition was too high. What about a
> compromise?
> I have improved the documentation about shared repositories. A patch
> coming
> shortly.
Sounds like an excellent idea.
Cheers,
Wincent
^ 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