* 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] 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 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 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: 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] 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: [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] 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] 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
* [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
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