* Re: git gc - out of memory
From: Alejandro Riveira @ 2009-11-15 14:44 UTC (permalink / raw)
To: git
In-Reply-To: <df1390cc0911141126w1a0c5691p83885053a73f829@mail.gmail.com>
El Sat, 14 Nov 2009 20:26:00 +0100, Simon Strandgaard escribió:
> My bare repository is on an OpenBSD machine. I was unaware of the
> importance of git gc until today after investigating a problem with "git
> pull". So there hasn't been run git gc on the repository ever.
>
> The biggest file in the repository is a 45 mb file. The repository size
> is near 2 gb.
>
> What can I do?
run « git repack -adf --window=memory » on the repo where memory is
escaled apropiately for your machine ?
See « git help repack »
Regards;
^ permalink raw reply
* Bugs ignoring submodules?
From: Felipe Contreras @ 2009-11-15 14:57 UTC (permalink / raw)
To: git
Hi,
I'm trying to format patches ignoring changes in the submodules, and
so far everything I've tried is failing, which I think points to
multiple bugs. I'm using 1.6.5.2.
First I tried:
% git format-patch --ignore-submodules
That ignores the submodules, all right, but still generates an empty
patch, just like 'git log' shows no diff.
Then I tried:
% git log <committish> -- $(git ls-files -x <submodule>)
But the submodule is still listed:
% git ls-files --exclude=common | grep ^common
common
These are bugs, right? Is there some other recommendation?
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Thomas Rast @ 2009-11-15 17:07 UTC (permalink / raw)
To: Nanako Shiraishi, rocketraman; +Cc: git, gitster
In-Reply-To: <20091114071946.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> Quoting rocketraman@fastmail.fm
> > Add a basic introduction to the branch management undertaken during a
> > git.git release
[...]
> Here are some corrections that can be applied on top of your change.
At the bottom there are some more corrections on top of your combined
patches. At this point I would prefer to squash everything into a
single patch, but if you want to keep them separate I can come up with
a commit message.
All but the last change are just intended to "sound nicer". Since I'm
not a native speaker either (I'm not sure any have commented in the
threads so far), it would probably be nice to get some additional
comments.
As for the last hunk, I felt it was misleading to state 'pu' uses the
same process as 'next' immediately after mentioning the "next will be
rewound shortly" messages that Junio sends out. Such a message is
never required for 'pu' because (as is already explained in the
manpage) the "contract" is that the maintainer may rewind it anytime
he likes.
Apart from that, I'm not entirely happy with the way the "release" and
"maint, after a feature release" sections are tangled yet. There are
several forward and backward references between them. I see that you
are trying to drive home the point that maint needs to be contained in
master. Can't we just deal with that in the "feature release"
section?
-- 8< --
diff --git i/Documentation/gitworkflows.txt w/Documentation/gitworkflows.txt
index 2a9329f..490346c 100644
--- i/Documentation/gitworkflows.txt
+++ w/Documentation/gitworkflows.txt
@@ -225,8 +225,8 @@ should first make sure that condition holds.
git log master..maint
=====================================
-There should be no commit listed from this command (otherwise, check
-out 'master' and merge 'maint' into it).
+This command should not list any commits. Otherwise, check out
+'master' and merge 'maint' into it.
Then you can tag the tip of
'master' with a tag indicating the release version.
@@ -241,15 +241,15 @@ Similarly, for a maintenance release, 'maint' is tracking the commits
to be released. Therefore, simply replace 'master' above with
'maint'.
-You need to push the new tag to a public git server,
-at the same time you push the updated 'master' or 'maint',
-if you are making a maintenance release. (see
-"DISTRIBUTED WORKFLOWS" below). This push makes the tag available to
+You need to push the new tag to a public git server
+when you push the updated 'master' (or 'maint',
+if you are making a maintenance release). See
+"DISTRIBUTED WORKFLOWS" below. This makes the tag available to
others tracking your project. The push could also trigger a
post-update hook to perform release-related items such as building
release tarballs and preformatted documentation pages. You may want
-to wait this push-out before you update your 'maint' branch (see the
-next section).
+to defer the push until after you have updated your 'maint' branch
+(see the next section).
Maintenance branch management after a feature release
@@ -319,8 +319,6 @@ so.
If you do this, then you should make a public announcement indicating
that 'next' was rewound and rebuilt.
-The same process may be followed for 'pu'.
-
DISTRIBUTED WORKFLOWS
---------------------
^ permalink raw reply related
* [PATCH 0/3] Document and refuse rebase -s ours
From: Thomas Rast @ 2009-11-15 18:25 UTC (permalink / raw)
To: git
Cc: Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <7vvdhggote.fsf@alter.siamese.dyndns.org>
Junio convinced me that it is not possible to limit the choice to only
'subtree', so here's a short series that implements the other changes
I had already posted in diff form.
I also implemented Nicolas's suggestion to reject -s ours outright;
I'm not really happy with starting a blacklist there, but maybe it
helps the next unwary user. I split it because even if you reject
3/3, I think the first two should go in as extra documentation.
Thomas Rast (3):
Documentation: clarify 'ours' merge strategy
rebase docs: clarify --merge and --strategy
rebase: refuse to rebase with -s ours
Documentation/git-rebase.txt | 14 +++++++++++---
Documentation/merge-strategies.txt | 5 +++--
git-rebase--interactive.sh | 4 ++++
git-rebase.sh | 4 ++++
4 files changed, 22 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH 2/3] rebase docs: clarify --merge and --strategy
From: Thomas Rast @ 2009-11-15 18:25 UTC (permalink / raw)
To: git
Cc: Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <cover.1258309432.git.trast@student.ethz.ch>
Add a paragraph about the swapped sides in a --merge rebase, which was
otherwise only documented in the sources.
Add a paragraph about the effects of the 'ours' strategy to the -s
description. Also remove the mention of the 'octopus' strategy, which
was copied from the git-merge description but is pointless in a
rebase.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-rebase.txt | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 33e0ef1..5fa9100 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -228,13 +228,20 @@ OPTIONS
Use merging strategies to rebase. When the recursive (default) merge
strategy is used, this allows rebase to be aware of renames on the
upstream side.
++
+Note that in a rebase merge (hence merge conflict), the sides are
+swapped: "theirs" is the to-be-applied patch, and "ours" is the so-far
+rebased series, starting with <upstream>.
-s <strategy>::
--strategy=<strategy>::
Use the given merge strategy.
- If there is no `-s` option, a built-in list of strategies
- is used instead ('git-merge-recursive' when merging a single
- head, 'git-merge-octopus' otherwise). This implies --merge.
+ If there is no `-s` option 'git-merge-recursive' is used
+ instead. This implies --merge.
++
+Due to the peculiarities of 'git-rebase' (see \--merge above), using
+the 'ours' strategy simply discards all patches from the <branch>,
+which makes little sense.
-q::
--quiet::
--
1.6.5.2.420.gf6c057.dirty
^ permalink raw reply related
* [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Thomas Rast @ 2009-11-15 18:25 UTC (permalink / raw)
To: git
Cc: Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <cover.1258309432.git.trast@student.ethz.ch>
Using the "ours" strategy with rebase just discards all changes,
turning <branch> into <upstream> (or <newbase> if given). This is
unlikely to be what the user wants, so simply refuse to do it.
Also document what would happen near the -s option, and point the user
at it with the error message.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-rebase.txt | 3 ++-
git-rebase--interactive.sh | 4 ++++
git-rebase.sh | 4 ++++
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 5fa9100..2203e63 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -241,7 +241,8 @@ rebased series, starting with <upstream>.
+
Due to the peculiarities of 'git-rebase' (see \--merge above), using
the 'ours' strategy simply discards all patches from the <branch>,
-which makes little sense.
+which makes little sense. Thus 'git-rebase' does not accept this
+strategy.
-q::
--quiet::
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 53ad248..c6bc156 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -584,6 +584,10 @@ first and then run 'git rebase --continue' again."
STRATEGY="-s $2"
shift ;;
esac
+ if test "$STRATEGY" = "-s ours"
+ then
+ die "Refusing to rebase with 'ours' strategy; see git help rebase."
+ fi
;;
-m)
# we use merge anyway
diff --git a/git-rebase.sh b/git-rebase.sh
index 6ec155c..2d7d566 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -306,6 +306,10 @@ do
strategy="$2"
shift ;;
esac
+ if test $strategy = ours
+ then
+ die "Refusing to rebase with 'ours' strategy; see git help rebase."
+ fi
do_merge=t
;;
-n|--no-stat)
--
1.6.5.2.420.gf6c057.dirty
^ permalink raw reply related
* [PATCH 1/3] Documentation: clarify 'ours' merge strategy
From: Thomas Rast @ 2009-11-15 18:25 UTC (permalink / raw)
To: git
Cc: Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <cover.1258309432.git.trast@student.ethz.ch>
Make it clear in the docs that the merge takes the tree of HEAD and
ignores everything in the other branches. This should hopefully clear
up confusion, usually caused by the user looking for a strategy that
resolves all conflict hunks in favour of HEAD (which is completely
different and currently not supported).
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/merge-strategies.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 4365b7e..42910a3 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -29,8 +29,9 @@ octopus::
pulling or merging more than one branch.
ours::
- This resolves any number of heads, but the result of the
- merge is always the current branch head. It is meant to
+ This resolves any number of heads, but the resulting tree of the
+ merge is always that of the current branch head, effectively
+ ignoring all changes from all other branches. It is meant to
be used to supersede old development history of side
branches.
--
1.6.5.2.420.gf6c057.dirty
^ permalink raw reply related
* Re: git gc - out of memory
From: Simon Strandgaard @ 2009-11-15 18:33 UTC (permalink / raw)
To: git
In-Reply-To: <hdp44d$4ml$1@ger.gmane.org>
On Sun, Nov 15, 2009 at 3:44 PM, Alejandro Riveira <ariveira@gmail.com> wrote:
> El Sat, 14 Nov 2009 20:26:00 +0100, Simon Strandgaard escribió:
[snip]
>> What can I do?
>
> run « git repack -adf --window=memory » on the repo where memory is
> escaled apropiately for your machine ?
Thank you Alejandro, it now works!
I think the default is 10, so I tried with window=5 and
it completed a full repack.
$ git repack -adf --window=5
Counting objects: 5934, done.
Compressing objects: 100% (5711/5711), done.
Writing objects: 100% (5934/5934), done.
Total 5934 (delta 3733), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.
$ git gc
Counting objects: 5934, done.
Compressing objects: 100% (1978/1978), done.
Writing objects: 100% (5934/5934), done.
Total 5934 (delta 3733), reused 5934 (delta 3733)
$
Now that it works..
Should I report the original issue as a bug somewhere?
e.g. malloc failed sounds like a bug.
Kind regards
Simon Strandgaard - http://gdtoolbox.com/
^ permalink raw reply
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Sverre Rabbelier @ 2009-11-15 18:39 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <efd7770d166a97481e8e31e407b9c2da02a341e5.1258309432.git.trast@student.ethz.ch>
Heya,
On Sun, Nov 15, 2009 at 19:25, Thomas Rast <trast@student.ethz.ch> wrote:
> + if test "$STRATEGY" = "-s ours"
Is this solid? Would "-s ours" (two spaces) work?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Thomas Rast @ 2009-11-15 18:44 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <fabb9a1e0911151039g7c7373b5o3c14a9056c419f6@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> On Sun, Nov 15, 2009 at 19:25, Thomas Rast <trast@student.ethz.ch> wrote:
> > + if test "$STRATEGY" = "-s ours"
>
> Is this solid? Would "-s ours" (two spaces) work?
Well, the variable is set by the case immediately before the new test:
case "$#,$1" in
*,*=*)
STRATEGY="-s "$(expr "z$1" : 'z-[^=]*=\(.*\)') ;;
1,*)
usage ;;
*)
STRATEGY="-s $2"
shift ;;
esac
I didn't want to split that for a direct comparison with the second
half of the value, but unless I'm missing something, you'd have to say
-s ' ours' to make the test fail.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Update 'git remote' usage and man page to match.
From: Tim Henigan @ 2009-11-15 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vr5s0qhnp.fsf@alter.siamese.dyndns.org>
On Sun, Nov 15, 2009 at 4:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
> You noticed a good issue to address. That is, "git remote -h" output
> looks Ok but "git remote add -h" and friends show way suboptimal help.
> The current output looks like:
>
> $ git remote add -h
> usage: git remote [-v | --verbose]
> or: git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name>
> <url>
> or: git remote rename <old> <new>
> or: git remote rm <name>
> or: git remote set-head <name> [-a | -d | <branch>]
> or: git remote show [-n] <name>
> or: git remote prune [-n | --dry-run] <name>
> or: git remote [-v | --verbose] update [-p | --prune] [group]
>
> add specific options
> -f, --fetch fetch the remote branches
> -t, --track <branch> branch(es) to track
> -m, --master <branch>
> master branch
> --mirror no separate remotes
>
> As the user already knows "add" is the subcommand she is interested in,
> this is insane.
>
> My preference is:
>
> (1) to drop your change to the synopsis section ("git remote -v" is a
> valid way to get more verbose information, isn't it?);
Sounds reasonable.
> (2) to keep the current output of "git remote -h";
The usage string for "git remote update" should still be modified to match
the changes made to the man page in commit b344e161. That commit
taught 'git remote update' to understand [group | remote]. The man page
was changed to document the new feature, but the usage string was not.
I will send v2 of this patch to make this change and add the author of
b344e161 (Finn Arne Gangstad) to the CC list to confirm.
> (3) to drop the general description section altogether from "git remote
> add -h" output;
Okay, I will look into this. If I find a good solution, I will send
an RFC patch
that updates 'git remote add'. Based on the email threads you cited below,
it sounds like the usage string for 'git push' is a good model to
follow. If the
change looks sane, I will follow up with a patch series that updates each of
the 'git remote' subcommands.
> I think this is related to a bigger issue of how we generally would want
> to show help in response to "-h", and also in the manual pages.
>
> http://thread.gmane.org/gmane.comp.version-control.git/129399/focus=129424
> http://thread.gmane.org/gmane.comp.version-control.git/129906/focus=130646
^ permalink raw reply
* [PATCH v2] Update 'git remote update' usage string to match man page.
From: Tim Henigan @ 2009-11-15 19:46 UTC (permalink / raw)
To: Junio C Hamano, finnag; +Cc: git, Nanako Shiraishi
Commit b344e161 taught 'git remote update' to understand
[group | remote] as its argument. The man page was updated
to document this change, but the usage string was not.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
---
This updates the patch found at:
http://article.gmane.org/gmane.comp.version-control.git/132953
The change to the man page synopsis has been dropped. This
patch now only updates the usage string in builtin-remote.c.
The author of commit b344e161 has been added to the CC list.
Based on advice from Junio, further changes to the usage string
and man pages will be explored in a separate patch series.
builtin-remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..c4edb86 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -15,7 +15,7 @@ static const char * const builtin_remote_usage[] = {
"git remote set-head <name> [-a | -d | <branch>]",
"git remote show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [-p | --prune] [group]",
+ "git remote [-v | --verbose] update [-p | --prune] [group | remote]",
NULL
};
--
1.6.5.2.185.gb7fba.dirty
^ permalink raw reply related
* Re: Question about "git pull --rebase"
From: Johan 't Hart @ 2009-11-15 19:47 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <m2my2noo0g.fsf@gmail.com>
Francis Moreau schreef:
> Looks like you did :)
>
> I've been somehow confused by the git-pull man page, which says:
>
> A parameter <ref> without a colon is equivalent to <ref>: when
> pulling/fetching, so it merges <ref> into the current branch without
> storing the remote branch anywhere locally
>
> So I thought that both of the commands were equivalent for 'git pull
> --rebase'.
>
> Thanks for the explanation.
Ah that part.
It means that
$ git pull --rebase origin master
means the same as:
$ git pull --rebase origin master:
(note extra colon at the end)
But not as:
$ git pull --rebase origin master:foo
It means that, when you give a refspec without a colon, it is the same
as the refspec with the colon and without the right side.
^ permalink raw reply
* Re: git svn fetch loses data
From: Johan 't Hart @ 2009-11-15 19:52 UTC (permalink / raw)
To: Thomas Rast; +Cc: Victor Engmark, Sverre Rabbelier, git
In-Reply-To: <200911151433.54797.trast@student.ethz.ch>
Thomas Rast schreef:
> Victor Engmark wrote:
>> On Sun, Nov 15, 2009 at 12:35 AM, Johan 't Hart <johanthart@gmail.com> wrote:
>>> Sverre Rabbelier schreef:
>>>
>>>> $ git rebase git-svn
>>> Why not just
>>> $ git svn rebase
>> What is the difference between the two?
>
> 'git svn rebase' magically[*] picks the right remote branch to rebase
> against, and also first talks to the network to update said branch.
>
>
> [*] actually it looks at the first git-svn-id line found in git log
> --first-parent.
>
I didn't even know you could also do
$ git rebase git-svn
Unless git-svn is a ref...
^ permalink raw reply
* Re: Question about "git pull --rebase"
From: Junio C Hamano @ 2009-11-15 20:18 UTC (permalink / raw)
To: Johan 't Hart; +Cc: Francis Moreau, git
In-Reply-To: <4B005AEC.1000002@gmail.com>
Johan 't Hart <johanthart@gmail.com> writes:
> Francis Moreau schreef:
>> Looks like you did :)
>>
>> I've been somehow confused by the git-pull man page, which says:
>>
>> A parameter <ref> without a colon is equivalent to <ref>: when
>> pulling/fetching, so it merges <ref> into the current branch without
>> storing the remote branch anywhere locally
>>
>> So I thought that both of the commands were equivalent for 'git pull
>> --rebase'.
>>
>> Thanks for the explanation.
>
> Ah that part.
>
> It means that
> $ git pull --rebase origin master
>
> means the same as:
> $ git pull --rebase origin master:
> (note extra colon at the end)
>
> But not as:
> $ git pull --rebase origin master:foo
>
> It means that, when you give a refspec without a colon, it is the same
> as the refspec with the colon and without the right side.
Thanks for clearing it up.
I was puzzled by the above pointing-finger because I wanted to see where a
misinformation originated from to fix it at the source. But still don't
see anything wrong with it.
Perhaps there was some other part of the manual that confused Francis to
think master: and master:foo are equivalent in that context? I somehow
doubt it, but if there is one, we would need to fix that
In a separate thread, Thomas reported a gross misinformation in github
wiki he recently fixed:
From: Thomas Rast <trast@student.ethz.ch>
Subject: Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
Date: Sun, 15 Nov 2009 13:24:03 +0100
Message-ID: <200911151324.05109.trast@student.ethz.ch>
Perhaps that page had some impact on this misunderstanding?
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Junio C Hamano @ 2009-11-15 20:22 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200911151324.05109.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Yesterday on IRC I helped 'thrope' with the github pull requests
> guide. This is a wiki page, but placed at a sufficiently prominent
> URL to make it look like an authoritative guide to a new user.
>
> http://github.com/guides/pull-requests
>
> I have since replaced the part in question ...
Thanks.
It is hard to control the quality of random third-party documents, and
such a help as yours is greatly appreciated.
A document with gross misinformation is much worse than not having it.
^ permalink raw reply
* Re: Question about "git pull --rebase"
From: Johan 't Hart @ 2009-11-15 20:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Francis Moreau, git
In-Reply-To: <7vlji7k0dm.fsf@alter.siamese.dyndns.org>
Junio C Hamano schreef:
> Johan 't Hart <johanthart@gmail.com> writes:
>>> I've been somehow confused by the git-pull man page, which says:
>>>
>>> A parameter <ref> without a colon is equivalent to <ref>: when
>>> pulling/fetching, so it merges <ref> into the current branch without
>>> storing the remote branch anywhere locally
>>>
> Thanks for clearing it up.
>
> I was puzzled by the above pointing-finger because I wanted to see where a
> misinformation originated from to fix it at the source. But still don't
> see anything wrong with it.
>
My guess is that he was confused by '<ref>:' not meaning '<ref>:<ref>'.
But I can't speak for him ofcource :)
Refspecs confused me too at the beginning... But knowing more and more
about git, it seems that this part of the docs look OK to me.. At most
an example might make things a little more clear, but I doubt it is
necessary.
^ permalink raw reply
* Re: git svn fetch loses data
From: Thomas Rast @ 2009-11-15 20:52 UTC (permalink / raw)
To: Johan 't Hart; +Cc: Victor Engmark, Sverre Rabbelier, git
In-Reply-To: <4B005C14.8090607@gmail.com>
Johan 't Hart wrote:
> I didn't even know you could also do
> $ git rebase git-svn
> Unless git-svn is a ref...
You can't, but in git-svn's default configuration (without
--stdlayout) the cloned SVN history is called refs/remotes/git-svn.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC] format-patch: Ensure that author and commit time are not lost
From: Junio C Hamano @ 2009-11-15 21:03 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git
In-Reply-To: <4B000141.5070503@gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
> 'git format-patch' encodes the author of the commit in the From: header
> and the time of the commit in the Date: header. Depending on how the
> email is sent, however, those headers can be lost before the email
> reaches its destination.
>
> Therefore, if the sender of the email (i.e. the configuration options
> user.name and user.email) are different from the author of a commit,
> insert From: and Date: headers at the beginning of the body of the
> commit message.
I think you are addressing a very valid issue, but I suspect that you are
doing so at a wrong place in the "patch mail-out" workflow.
> +static int sender_is_not_author(const char *message)
> +{
> + const char **msg_p = &message;
> +
> + for (;;) {
> ...
> + }
> +}
This new function is not about "Is the _sender_ the same as the author?",
but is about "Is the person who is running format-patch the same as the
author?". There is a big difference.
What you want to catch is really "Does the MUA that sends out the final
message have the name of the author on its 'From: ' header?", and that
depends on how the output from format-patch command is processed in the
downstream of the workflow.
You may read the file into your MUA edit session. You would typically
edit the first three lines out and move Subject: to the MUA's subject line.
You can choose to keep From:/Date: when you do so. This happens to be the
way I work, by the way.
The output may not even be used by a MUA; you may upload it to web based
thingy like Bugzilla or FrySpray. The recipient will download the whole
thing and there is no need to edit.
I would expect the right solution would be to give send-email an ability
to either (1) use "Sender:" to record the operator of the MUA while
keeping "From: " taken from the payload, or (2) duplicate "From: " as an
in-body header when it sends out.
It is a separate issue if that ability should be on by default or
controlled by an option, of course. But I do not think it should be in
the format-patch.
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Junio C Hamano @ 2009-11-15 21:03 UTC (permalink / raw)
To: Jakub Narebski, Petr Baudis, Luben Tuikov, J.H.; +Cc: git, Sylvain Rabot
In-Reply-To: <7fce93be0911150204h259b7424md251c54186d05b7d@mail.gmail.com>
Sylvain Rabot <sylvain@abstraction.fr> writes:
> I made gitweb behave a bit like UserDir module will in apache.
> In fact it's only configuration but I think it could be useful to others.
Thanks. Any comment from gitweb gangs?
> Basicly it allows users of your server who use git to be able to use
> gitweb to browse their own root project. E.G. :
>
> Alice's private repos :
>
> /home/alice/git/product_a.git (cloned from /var/git/product_a.git)
> /home/alice/git/product_b.git (cloned from /var/git/product_b.git)
> /home/alice/git/product_c.git (cloned from /var/git/product_c.git)
>
> Alice's links to her repos which she wants to be able to browse with gitweb :
>
> /home/alice/gitweb/product_a -> /home/alice/git/product_a.git/.git
> /home/alice/gitweb/product_c -> /home/alice/git/product_c.git/.git
>
> Bare repos :
>
> /var/git/product_a.git
> /var/git/product_b.git
> /var/git/product_c.git
> /var/git/product_d.git
>
> /etc/gitweb.conf :
>
> $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/var/git/";
>
> Apache configuration :
>
> RewriteRule ^/~([^\/]+)/?$ /cgi-bin/gitweb.cgi
> [QSA,E=GITWEB_PROJECTROOT:/home/$1/gitweb/,L,PT]
>
> So now all users with a gitweb folder in their home will be able to
> browse all git repos in it through http://<host>/~<user>.
>
> You will find a patch enclosed which try to describe best what I did
> and why in the gitweb/README.
^ permalink raw reply
* Re: [PATCH v2] Update 'git remote update' usage string to match man page.
From: Junio C Hamano @ 2009-11-15 21:04 UTC (permalink / raw)
To: Tim Henigan; +Cc: finnag, git, Nanako Shiraishi
In-Reply-To: <32c343770911151146m82ac4a3p12ecc988da88ab6b@mail.gmail.com>
Thanks, will queue.
^ permalink raw reply
* Re: [PATCH 0/3] Document and refuse rebase -s ours
From: Junio C Hamano @ 2009-11-15 21:04 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <cover.1258309432.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> I also implemented Nicolas's suggestion to reject -s ours outright;
> I'm not really happy with starting a blacklist there, but maybe it
> helps the next unwary user.
I am inclined to agree with you and Nicolas on this, but I'll let the list
decide if [3/3] is a good idea.
I'd rewrite [3/3] in the following way to keep it easier to maintain the
blacklist, like this.
case "$1" in
- ours)
+ ours | theirs | octopus | subtree)
die "Refusing to rebase with $1; see git help rebase."
esac
It would also make it easier to turn this into a whitelist if we choose
to,
git-rebase--interactive.sh | 5 +----
git-rebase.sh | 5 +----
git-sh-setup.sh | 7 +++++++
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 53d35f3..de7448b 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -571,10 +571,7 @@ first and then run 'git rebase --continue' again."
STRATEGY="-s $2"
shift ;;
esac
- if test "$STRATEGY" = "-s ours"
- then
- die "Refusing to rebase with 'ours' strategy; see git help rebase."
- fi
+ git_check_merge_strategy_used_in_rebase "${STRATEGY#-s }"
;;
-m)
# we use merge anyway
diff --git a/git-rebase.sh b/git-rebase.sh
index 2d7d566..dd9ec63 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -306,10 +306,7 @@ do
strategy="$2"
shift ;;
esac
- if test $strategy = ours
- then
- die "Refusing to rebase with 'ours' strategy; see git help rebase."
- fi
+ git_check_merge_strategy_used_in_rebase "$strategy"
do_merge=t
;;
-n|--no-stat)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index c41c2f7..724955f 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -199,3 +199,10 @@ case $(uname -s) in
}
;;
esac
+
+git_check_merge_strategy_used_in_rebase () {
+ case "$1" in
+ ours)
+ die "Refusing to rebase with $1; see git help rebase."
+ esac
+}
^ permalink raw reply related
* Re: [PATCH 2/3] rebase docs: clarify --merge and --strategy
From: Junio C Hamano @ 2009-11-15 21:05 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <b7f805f2497d748b685544b64cd91a36c3bdf5d6.1258309432.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Add a paragraph about the swapped sides in a --merge rebase, which was
> otherwise only documented in the sources.
>
> Add a paragraph about the effects of the 'ours' strategy to the -s
> description. Also remove the mention of the 'octopus' strategy, which
> was copied from the git-merge description but is pointless in a
> rebase.
Instead of saying "peculiarities" without saying what is peculiar about
it, it might be better to give an explanation that would help the reader
understand why they appear "swapped".
Here is my attempt. Thoughts?
Documentation/git-rebase.txt | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index e802421..a6f8182 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -229,9 +229,11 @@ OPTIONS
strategy is used, this allows rebase to be aware of renames on the
upstream side.
+
-Note that in a rebase merge (hence merge conflict), the sides are
-swapped: "theirs" is the to-be-applied patch, and "ours" is the so-far
-rebased series, starting with <upstream>.
+Note that a rebase merge works by replaying each commit from the working
+branch on top of the <upstream> branch. Because of this, when a merge
+conflict happens, the side reported as 'ours' is the so-far rebased
+series, starting with <upstream>, and 'theirs' is the working branch. In
+other words, the sides are swapped.
-s <strategy>::
--strategy=<strategy>::
@@ -239,7 +241,9 @@ rebased series, starting with <upstream>.
If there is no `-s` option 'git-merge-recursive' is used
instead. This implies --merge.
+
-Due to the peculiarities of 'git-rebase' (see \--merge above), using
+Because 'git-rebase' replays each commit from the working branch
+on top of the <upstream> branch using the given strategy,
+(see \--merge above), using
the 'ours' strategy simply discards all patches from the <branch>,
which makes little sense. Thus 'git-rebase' does not accept this
strategy.
^ permalink raw reply related
* Re: [PATCH 2/3] rebase docs: clarify --merge and --strategy
From: Thomas Rast @ 2009-11-15 21:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <7v7htrfqi1.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index e802421..a6f8182 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -229,9 +229,11 @@ OPTIONS
> strategy is used, this allows rebase to be aware of renames on the
> upstream side.
> +
> -Note that in a rebase merge (hence merge conflict), the sides are
> -swapped: "theirs" is the to-be-applied patch, and "ours" is the so-far
> -rebased series, starting with <upstream>.
> +Note that a rebase merge works by replaying each commit from the working
> +branch on top of the <upstream> branch. Because of this, when a merge
> +conflict happens, the side reported as 'ours' is the so-far rebased
> +series, starting with <upstream>, and 'theirs' is the working branch. In
> +other words, the sides are swapped.
This is much nicer than mine!
> -Due to the peculiarities of 'git-rebase' (see \--merge above), using
> +Because 'git-rebase' replays each commit from the working branch
> +on top of the <upstream> branch using the given strategy,
> +(see \--merge above), using
> the 'ours' strategy simply discards all patches from the <branch>,
> which makes little sense. Thus 'git-rebase' does not accept this
> strategy.
Here I'm not sure if it makes such a big difference, since we already
explained the problem in --merge (and point to it). But yours is fine
too.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 0/3] Document and refuse rebase -s ours
From: Thomas Rast @ 2009-11-15 21:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <7veinzfqj9.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> I'd rewrite [3/3] in the following way to keep it easier to maintain the
> blacklist, like this.
>
> case "$1" in
> - ours)
> + ours | theirs | octopus | subtree)
I agree with the rewrite; it's easier to maintain, even though it's
now in a quite strange place.
However, I think the example you gave is misleading: 'subtree' is a
useful strategy if you want to rebase across a subtree merge boundary,
isn't it?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ 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