* Re: is it possible filter the revision history of a single file into another repository?
From: Whit Armstrong @ 2008-12-19 13:08 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: git, Junio C Hamano
In-Reply-To: <200812191044.47830.thomas.jarosch@intra2net.com>
thanks, Thomas. I could definitely pull from your tree. seems like
the path of least resistance to get my repo split.
Cheers,
Whit
On Fri, Dec 19, 2008 at 4:44 AM, Thomas Jarosch
<thomas.jarosch@intra2net.com> wrote:
> On Thursday, 18. December 2008 20:51:38 Whit Armstrong wrote:
>> Sorry, seem to be getting this error:
>> `/home/whit/dvl/risk.metrics.utils/RiskMetrics/.git-rewrite/t/../index.new'
>>: No such file or directory
>>
>> do I need to set up the index file first?
>
> Hmm, I guess you have an empty commit in your repository like I did.
> This is currently a corner case in update-index, which does not create empty
> index files. I posted a patch a few days ago and Junio posted an updated
> version of that. I could send you my version for git 1.6.0.5 if you need it.
>
>> Is there a good site that documents this procedure?
>
> A good start is the git-filter-branch man page and the mailinglist archive.
>
> Thomas
>
>
^ permalink raw reply
* [PATCH] Documentation: sync example output with git output
From: Markus Heidelberg @ 2008-12-19 12:14 UTC (permalink / raw)
To: gitster; +Cc: git
Don't confuse the user with old git messages.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Documentation/git-checkout.txt | 1 -
Documentation/git-reset.txt | 2 +-
Documentation/gitcore-tutorial.txt | 11 +++++------
Documentation/pretty-formats.txt | 6 +++---
4 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 79824f4..9cd5151 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -232,7 +232,6 @@ the `-m` option, you would see something like this:
------------
$ git checkout -m mytopic
Auto-merging frotz
-merge: warning: conflicts during merge
ERROR: Merge conflict in frotz
fatal: merge program failed
------------
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 29156f6..2049f3d 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -130,7 +130,7 @@ Undo a merge or pull::
$ git pull <1>
Auto-merging nitfol
CONFLICT (content): Merge conflict in nitfol
-Automatic merge failed/prevented; fix up by hand
+Automatic merge failed; fix conflicts and then commit the result.
$ git reset --hard <2>
$ git pull . topic/branch <3>
Updating from 41223... to 13134...
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 96bf353..df48045 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -899,7 +899,7 @@ file, which had no differences in the `mybranch` branch), and say:
----------------
Auto-merging hello
CONFLICT (content): Merge conflict in hello
- Automatic merge failed; fix up by hand
+ Automatic merge failed; fix conflicts and then commit the result.
----------------
It tells you that it did an "Automatic merge", which
@@ -993,7 +993,7 @@ would be different)
----------------
Updating from ae3a2da... to a80b4aa....
-Fast forward
+Fast forward (no commit created; -m option ignored)
example | 1 +
hello | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
@@ -1265,9 +1265,8 @@ file, using 3-way merge. This is done by giving
------------
$ git merge-index git-merge-one-file hello
-Auto-merging hello.
-merge: warning: conflicts during merge
-ERROR: Merge conflict in hello.
+Auto-merging hello
+ERROR: Merge conflict in hello
fatal: merge program failed
------------
@@ -1447,7 +1446,7 @@ public repository you might want to repack & prune often, or
never.
If you run `git repack` again at this point, it will say
-"Nothing to pack". Once you continue your development and
+"Nothing new to pack.". Once you continue your development and
accumulate the changes, running `git repack` again will create a
new pack, that contains objects created since you packed your
repository the last time. We recommend that you pack your project
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index f18d33e..0a8a948 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -30,7 +30,7 @@ This is designed to be as compact as possible.
commit <sha1>
Author: <author>
- Date: <author date>
+ Date: <author date>
<title line>
@@ -49,9 +49,9 @@ This is designed to be as compact as possible.
* 'fuller'
commit <sha1>
- Author: <author>
+ Author: <author>
AuthorDate: <author date>
- Commit: <committer>
+ Commit: <committer>
CommitDate: <committer date>
<title line>
--
1.6.1.rc3.27.gf650d1
^ permalink raw reply related
* [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Markus Heidelberg @ 2008-12-19 12:14 UTC (permalink / raw)
To: gitster; +Cc: git
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Documentation/diff-format.txt | 2 +-
Documentation/diff-generate-patch.txt | 6 +++---
Documentation/git-commit.txt | 2 +-
Documentation/git-diff-tree.txt | 4 ++--
Documentation/git-mailinfo.txt | 2 +-
Documentation/git-receive-pack.txt | 4 ++--
Documentation/git-reflog.txt | 4 ++--
Documentation/git-show-branch.txt | 4 ++--
Documentation/git-submodule.txt | 2 +-
Documentation/git-update-index.txt | 8 ++++----
Documentation/gitcore-tutorial.txt | 8 ++++----
Documentation/gitk.txt | 4 ++--
Documentation/i18n.txt | 4 ++--
13 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index aafd3a3..1eeb1c7 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -58,7 +58,7 @@ Possible status letters are:
be committed)
- X: "unknown" change type (most probably a bug, please report it)
-Status letters C and M are always followed by a score (denoting the
+Status letters C and R are always followed by a score (denoting the
percentage of similarity between the source and target of the move or
copy), and are the only ones to be so.
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
index 517e1eb..0f25ba7 100644
--- a/Documentation/diff-generate-patch.txt
+++ b/Documentation/diff-generate-patch.txt
@@ -143,15 +143,15 @@ different from it.
A `-` character in the column N means that the line appears in
fileN but it does not appear in the result. A `+` character
-in the column N means that the line appears in the last file,
+in the column N means that the line appears in the result,
and fileN does not have that line (in other words, the line was
added, from the point of view of that parent).
In the above example output, the function signature was changed
from both files (hence two `-` removals from both file1 and
file2, plus `++` to mean one line that was added does not appear
-in either file1 nor file2). Also two other lines are the same
-from file1 but do not appear in file2 (hence prefixed with ` +`).
+in either file1 nor file2). Also eight other lines are the same
+from file1 but do not appear in file2 (hence prefixed with `{plus}`).
When shown by `git diff-tree -c`, it compares the parents of a
merge commit with the merge result (i.e. file1..fileN are the
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 6203461..b5d81be 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -166,7 +166,7 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
'git-commit' if any paths are given on the command line,
in which case this option can be omitted.
If this option is specified together with '--amend', then
- no paths need be specified, which can be used to amend
+ no paths need to be specified, which can be used to amend
the last commit without committing changes that have
already been staged.
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 5d48664..23b7abd 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -43,7 +43,7 @@ include::diff-options.txt[]
show tree entry itself as well as subtrees. Implies -r.
--root::
- When '--root' is specified the initial commit will be showed as a big
+ When '--root' is specified the initial commit will be shown as a big
creation event. This is equivalent to a diff against the NULL tree.
--stdin::
@@ -63,7 +63,7 @@ and terminated by a newline) is printed before the difference. When
comparing commits, the ID of the first (or only) commit, followed by a
newline, is printed.
+
-The following flags further affects the behavior when comparing
+The following flags further affect the behavior when comparing
commits (but not trees).
-m::
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 31eccea..8d95aaa 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Reading a single e-mail message from the standard input, and
+Reads a single e-mail message from the standard input, and
writes the commit log message in <msg> file, and the patches in
<patch> file. The author name, e-mail and e-mail subject are
written out to the standard output to be used by 'git-am'
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index 6b2f8c4..514f03c 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -86,7 +86,7 @@ post-receive Hook
-----------------
After all refs were updated (or attempted to be updated), if any
ref update was successful, and if $GIT_DIR/hooks/post-receive
-file exists and is executable, it will be invoke once with no
+file exists and is executable, it will be invoked once with no
parameters. The standard input of the hook will be one line
for each successfully updated ref:
@@ -133,7 +133,7 @@ post-update Hook
----------------
After all other processing, if at least one ref was updated, and
if $GIT_DIR/hooks/post-update file exists and is executable, then
-post-update will called with the list of refs that have been updated.
+post-update will be called with the list of refs that have been updated.
This can be used to implement any repository wide cleanup tasks.
The exit code from this hook invocation is ignored; the only thing
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index d99236e..7f7a544 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -28,7 +28,7 @@ updated. This command is to manage the information recorded in it.
The subcommand "expire" is used to prune older reflog entries.
Entries older than `expire` time, or entries older than
-`expire-unreachable` time and are not reachable from the current
+`expire-unreachable` time and not reachable from the current
tip, are removed from the reflog. This is typically not used
directly by the end users -- instead, see linkgit:git-gc[1].
@@ -71,7 +71,7 @@ them.
which in turn defaults to 90 days.
--expire-unreachable=<time>::
- Entries older than this time and are not reachable from
+ Entries older than this time and not reachable from
the current tip of the branch are pruned. Without the
option it is taken from configuration
`gc.reflogExpireUnreachable`, which in turn defaults to
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index d3f2588..8277577 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -30,7 +30,7 @@ OPTIONS
-------
<rev>::
Arbitrary extended SHA1 expression (see linkgit:git-rev-parse[1])
- that typically names a branch HEAD or a tag.
+ that typically names a branch head or a tag.
<glob>::
A glob pattern that matches branch or tag names under
@@ -172,7 +172,7 @@ only the primary branches. In addition, if you happen to be on
your topic branch, it is shown as well.
------------
-$ git show-branch --reflog='10,1 hour ago' --list master
+$ git show-branch --reflog="10,1 hour ago" --list master
------------
shows 10 reflog entries going back from the tip as of 1 hour ago.
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index babaa9b..2f207fb 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -87,7 +87,7 @@ use by subsequent users cloning the superproject. If the URL is
given relative to the superproject's repository, the presumption
is the superproject and submodule repositories will be kept
together in the same relative location, and only the
-superproject's URL need be provided: git-submodule will correctly
+superproject's URL needs to be provided: git-submodule will correctly
locate the submodule using the relative URL in .gitmodules.
status::
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 1d9d81a..25e0bbe 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -55,7 +55,7 @@ OPTIONS
default behavior is to error out. This option makes
'git-update-index' continue anyway.
---ignore-submodules:
+--ignore-submodules::
Do not try to update submodules. This option is only respected
when passed before --refresh.
@@ -78,9 +78,9 @@ OPTIONS
--assume-unchanged::
--no-assume-unchanged::
- When these flags are specified, the object name recorded
+ When these flags are specified, the object names recorded
for the paths are not updated. Instead, these options
- sets and unsets the "assume unchanged" bit for the
+ set and unset the "assume unchanged" bit for the
paths. When the "assume unchanged" bit is on, git stops
checking the working tree files for possible
modifications, so you need to manually unset the bit to
@@ -122,7 +122,7 @@ you will need to handle the situation manually.
'git-update-index' refuses an attempt to add `path/file`.
Similarly if a file `path/file` exists, a file `path`
cannot be added. With --replace flag, existing entries
- that conflicts with the entry being added are
+ that conflict with the entry being added are
automatically removed with warning messages.
--stdin::
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 96bf353..da8fa44 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -999,8 +999,8 @@ Fast forward
2 files changed, 2 insertions(+), 0 deletions(-)
----------------
-Because your branch did not contain anything more than what are
-already merged into the `master` branch, the merge operation did
+Because your branch did not contain anything more than what had
+already been merged into the `master` branch, the merge operation did
not actually do a merge. Instead, it just updated the top of
the tree of your branch to that of the `master` branch. This is
often called 'fast forward' merge.
@@ -1353,7 +1353,7 @@ $ GIT_DIR=my-git.git git init
------------
Make sure this directory is available for others you want your
-changes to be pulled by via the transport of your choice. Also
+changes to be pulled via the transport of your choice. Also
you need to make sure that you have the 'git-receive-pack'
program on the `$PATH`.
@@ -1512,7 +1512,7 @@ You can repack this private repository whenever you feel like.
6. Push your changes to the public repository, and announce it
to the public.
-7. Every once in a while, "git-repack" the public repository.
+7. Every once in a while, 'git-repack' the public repository.
Go back to step 5. and continue working.
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index 317f631..4673a75 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -21,7 +21,7 @@ git repository.
OPTIONS
-------
-To control which revisions to shown, the command takes options applicable to
+To control which revisions to show, the command takes options applicable to
the 'git-rev-list' command (see linkgit:git-rev-list[1]).
This manual page describes only the most
frequently used options.
@@ -80,7 +80,7 @@ Examples
--------
gitk v2.6.12.. include/scsi drivers/scsi::
- Show as the changes since version 'v2.6.12' that changed any
+ Show the changes since version 'v2.6.12' that changed any
file in the include/scsi or drivers/scsi subdirectories
gitk --since="2 weeks ago" \-- gitk::
diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt
index 2cdacd9..708da6c 100644
--- a/Documentation/i18n.txt
+++ b/Documentation/i18n.txt
@@ -7,11 +7,11 @@ At the core level, git is character encoding agnostic.
to be what lstat(2) and creat(2) accepts. There is no such
thing as pathname encoding translation.
- - The contents of the blob objects are uninterpreted sequence
+ - The contents of the blob objects are uninterpreted sequences
of bytes. There is no encoding translation at the core
level.
- - The commit log messages are uninterpreted sequence of non-NUL
+ - The commit log messages are uninterpreted sequences of non-NUL
bytes.
Although we encourage that the commit log messages are encoded
--
1.6.1.rc3.27.gf650d1
^ permalink raw reply related
* remote tracking branch deletion problem
From: Thomas Jarosch @ 2008-12-19 11:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Hello together,
while playing around with git, I stumbled upon a strange remote tracking
branch deletion problem. It seems I'm unable to delete the remote tracking
branch "origin/HEAD" using git 1.6.0.5. Here's what I did:
[tomj@storm repo]$ git init
Initialized empty Git repository in /tmp/repo/.git/
[tomj@storm repo]$ echo "test" >test
[tomj@storm repo]$ git add test
[tomj@storm repo]$ git commit -m "Test"
[tomj@storm tmp]$ git clone repo alice
Initialized empty Git repository in /tmp/alice/.git/
[tomj@storm alice]$ git branch -r
origin/HEAD
origin/master
[tomj@storm alice]$ git branch -r -d origin/HEAD
Deleted remote branch origin/HEAD.
[tomj@storm alice]$ git branch -r -d origin/master
Deleted remote branch origin/master.
[tomj@storm alice]$ ls -al .git/refs/remotes/origin/HEAD
-rw-rw---- 1 tomj intra2net 32 19. Dec 12:43 .git/refs/remotes/origin/HEAD
[tomj@storm alice]$ git branch -r
error: refs/remotes/origin/HEAD points nowhere!
Is this supposed to be? git 1.6.1.rc3.35.gc0ceb shows a similar behavior.
Cheers,
Thomas
^ permalink raw reply
* Re: Announcement: Git Extensions stable (windows shell extensions)
From: Peter Krefting @ 2008-12-19 10:36 UTC (permalink / raw)
To: Henk; +Cc: git
In-Reply-To: <1229547366402-1669761.post@n2.nabble.com>
Henk:
> I just rereleased a 0.9 version without the visual studio plugin. Too bad it
> causes problems, I will try to fix them soon. I was able to reproduce the
> error on my laptop, so thats a good start.
I tried with the 0.91 version but ran into a different problem:
"The system cannot open the device or file specified."
followed by
"The installer has encountered an unexpected error installing this
package. This may indicate a problem with this package. The error code
is 2755."
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: is it possible filter the revision history of a single file into another repository?
From: Thomas Jarosch @ 2008-12-19 9:44 UTC (permalink / raw)
To: Whit Armstrong; +Cc: git, Junio C Hamano
In-Reply-To: <8ec76080812181151y4a5a6f5cna57785c935032e77@mail.gmail.com>
On Thursday, 18. December 2008 20:51:38 Whit Armstrong wrote:
> Sorry, seem to be getting this error:
> `/home/whit/dvl/risk.metrics.utils/RiskMetrics/.git-rewrite/t/../index.new'
>: No such file or directory
>
> do I need to set up the index file first?
Hmm, I guess you have an empty commit in your repository like I did.
This is currently a corner case in update-index, which does not create empty
index files. I posted a patch a few days ago and Junio posted an updated
version of that. I could send you my version for git 1.6.0.5 if you need it.
> Is there a good site that documents this procedure?
A good start is the git-filter-branch man page and the mailinglist archive.
Thomas
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Michael J Gruber @ 2008-12-19 9:26 UTC (permalink / raw)
To: C. Scott Ananian; +Cc: David Howells, git, linux-kernel
In-Reply-To: <c6d9bea0812181647n55fbb6b9w333702fc80127198@mail.gmail.com>
C. Scott Ananian venit, vidit, dixit 19.12.2008 01:47:
> On Fri, Dec 12, 2008 at 1:28 PM, David Howells <dhowells@redhat.com> wrote:
>> Add a guide to using GIT's simpler features.
>> diff --git a/Documentation/git-haters-guide.txt b/Documentation/git-haters-guide.txt
>> +In the above example, I've assumed that you've got your own tree with the head
>> +at commit C3, and that you've got a branch that you want to merge, which has
>> +its head at commit B3. After merging them, you'd end up with a directed,
>> +cyclic tree:
>
> That should be, "acyclic". There are no cycles, because the graph is directed.
Well, directed graphs can have cycles. But the revision graph of a
revision control system has to be an acyclic directed graph. Otherwise
parenthood would be a complicated matter ;)
And no, trees by definition don't have cycles. Also, a "tree" in git
lingo is not the graph theoretic notion (which David uses, though
incorrectly); this only adds unnecessary points of confusion.
For whatever reason the graphs in version control systems are called
"dag"s, i.e. directed acyclic graphs, even though "acyclicity" depends
on whether you look at the directed or undirected graphs. (Branching
then merging gives an undirected cycle.) I guess one may read "directed"
as an attribute to "acyclic" here, i.e. ((directed acyclic) graph)
rather than (directed (acyclic graph)); so to say "directedly acyclic
graph". Or it's just that "dag" reads much better than "adg"...
So, please: Simplification yes, but not if it's unnecessarily misleading
or even plain wrong (referring to the original proposal, not the comment).
Cheers,
Michael
^ permalink raw reply
* jgit doesn't support "compare with" and "replace with"?
From: Martin_S @ 2008-12-19 9:10 UTC (permalink / raw)
To: git
Hi, I'm using eclipse 3.4 and jgit 0.4. The right click context menus don't
list "compare with" and "replace with". Am I doing something wrong?
Thanks in Advance, Martin
--
View this message in context: http://n2.nabble.com/jgit-doesn%27t-support-%22compare-with%22-and-%22replace-with%22--tp1677009p1677009.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Odd merge behaviour involving reverts
From: Junio C Hamano @ 2008-12-19 8:45 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Linus Torvalds, Alan, git
In-Reply-To: <20081219124452.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> If I understand Alan's case correctly, I think he does not want to
> "undo" the revert but wants to merge an updated version of the branch,
> as if no mistaken merge nor its revert happened in the past.
>
> If you revert the revert on the branch before merging, doesn't it mean
> that you will be merging what the older version of the branch did (that
> is in the revert of the revert as a single huge patch) and what the
> updated version of the branch wants to do? Wouldn't that lead to a mess
> with huge conflicts?
The history immediately after the "revert of the merge" would look like
this:
---o---o---o---M---x---x---W---x
/
---A---B
where A and B are on the side development that was not so good, M is the
merge that brings those premature changes into the mainline, x are
unrelated changes already made on the mainline and W is the "revert of the
merge M" (doesn't W look M upside down?). IOW, "diff W^..W" is similar to
"diff -R M^..M".
I think you misunderstood what "merging an updated version of the branch"
meant by Alan's description to mean that the side branch developers
discarded their faulty A and B, and redone the changes, which would have
resulted in something like:
---o---o---o---M---x---x---W---x---x
\
A'--B'--C'
If that were the situation, suggestion by Linus to revert the revert and
then merge would result in something like this:
---o---o---o---M---x---x---W---x---x---Y---*
\ /
A'--B'--C'
where Y is the revert of W, A' and B'are rerolled A and B, and there may
also be a further fix-up C' on the side branch. "diff Y^..Y" is similar
to "diff -R W^..W" (which in turn means it is similar to "diff M^..M"),
and "diff A'^..C'" by definition would be similar but different from that,
because it is a rerolled series of the earlier change. There would be a
lot of overlap as you feared. In such a case, not having Y (revert of the
revert) would result in a much more trivial merge:
---o---o---o---M---x---x---W---x---x-------*
\ /
A'--B'--C'
because problematic large commits M and W are already outside of the scope
of this final merge.
But I think what Alan's developers did is different. They did this
instead:
---o---o---o---M---x---x---W---x
/
---A---B-------------------C---D
where C and D are to fix what was broken in A and B. In such a situation,
what Linus suggests makes perfect sense. You first revert the revert,
which would result in this:
---o---o---o---M---x---x---W---x---Y
/
---A---B-------------------C---D
where Y is the revert of W, which would (ignoring possible conflicts
between what W and W..Y changed) be equivalent to not having W nor Y at
all in the history:
---o---o---o---M---x---x-------x----
/
---A---B-------------------C---D
and merging the side branch again will not have conflict arising from an
earlier revert and revert of revert.
---o---o---o---M---x---x-------x-------*
/ /
---A---B-------------------C---D
Of course the changes made in C and D still can conflict with what was
done by any of the x, but that is just a normal merge conflict.
To recap, these are two very different scenarios, and wants two very
different resolution strategies:
- If the faulty side branch whose effects were discarded by an earlier
revert of a merge was rebuilt from scratch (i.e. rebasing and fixing,
as you seem to have interpreted), then re-merging the result without
doing anything else fancy would be the right thing to do.
- If the faulty side branch was fixed by adding corrections on top, then
doing a revert of the previous revert would be the right thing to do.
I hope this clears up confusion and fear.
^ permalink raw reply
* Re: [PATCH] git-send-email: handle email address with quoted comma
From: Wu Fengguang @ 2008-12-19 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org, Matt Kraai
In-Reply-To: <7vej04d5wy.fsf@gitster.siamese.dyndns.org>
On Fri, Dec 19, 2008 at 08:40:13AM +0200, Junio C Hamano wrote:
> Wu Fengguang <fengguang.wu@intel.com> writes:
>
> > Correctly handle email addresses containing quoted commas, e.g.
> >
> > "Zhu, Yi" <yi.zhu@intel.com>, "Li, Shaohua" <shaohua.li@intel.com>
> >
> > Here the commas inside the double quotes are NOT email separators.
>
> Thanks.
>
> > @@ -359,6 +360,12 @@ foreach my $entry (@bcclist) {
> > die "Comma in --bcclist entry: $entry'\n" unless $entry !~ m/,/;
> > }
> >
> > +sub split_addrs($) {
> > + my ($addrs) = @_;
> > +
> > + return "ewords('\s*,\s*', 1, $addrs);
> > +}
> > +
>
> Does it add real value (e.g. type safety, simplified interface to the
> caller, etc.) to force scalar context to the callers? It has been my
> experience that use of prototypes (aka "parameter context templates") in
> Perl programs tend to make the code less readable and more error prone in
> longer term. I would further say that, even though you do not have any
> existing caller of split_addrs sub that uses it for more than two values,
> not using the prototype would be a better way to write this sub in this
> particular case, because it would allow callers to say [*1*]:
>
> @addrs = split_addr(@list_of_addr_lines);
>
> It also is a bit funny-looking to invoke &function() (it is Perl4 style,
> isn't it?)
>
> IOW, wouldn't this be a better alternative?
>
> sub split_addrs {
> return quotewords('\s*,\s*', 1, @_);
> }
Hi Junio and Matt,
Thank you for the helpful information. The patch is updated and tested
according to your comments.
Thanks,
Fengguang
---
git-send-email: handle email address with quoted comma
Correctly handle email addresses containing quoted commas, e.g.
"Zhu, Yi" <yi.zhu@intel.com>, "Li, Shaohua" <shaohua.li@intel.com>
Here the commas inside the double quotes are NOT email separators.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
git-send-email.perl | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 3112f76..6114401 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -20,6 +20,7 @@ use strict;
use warnings;
use Term::ReadLine;
use Getopt::Long;
+use Text::ParseWords;
use Data::Dumper;
use Term::ANSIColor;
use File::Temp qw/ tempdir /;
@@ -359,6 +360,10 @@ foreach my $entry (@bcclist) {
die "Comma in --bcclist entry: $entry'\n" unless $entry !~ m/,/;
}
+sub split_addrs {
+ return parse_line('\s*,\s*', 1, @_);
+}
+
my %aliases;
my %parse_alias = (
# multiline formats can be supported in the future
@@ -367,7 +372,7 @@ my %parse_alias = (
my ($alias, $addr) = ($1, $2);
$addr =~ s/#.*$//; # mutt allows # comments
# commas delimit multiple addresses
- $aliases{$alias} = [ split(/\s*,\s*/, $addr) ];
+ $aliases{$alias} = [ split_addrs($addr) ];
}}},
mailrc => sub { my $fh = shift; while (<$fh>) {
if (/^alias\s+(\S+)\s+(.*)$/) {
@@ -379,7 +384,7 @@ my %parse_alias = (
chomp $x;
$x .= $1 while(defined($_ = <$fh>) && /^ +(.*)$/);
$x =~ /^(\S+)$f\t\(?([^\t]+?)\)?(:?$f){0,2}$/ or next;
- $aliases{$1} = [ split(/\s*,\s*/, $2) ];
+ $aliases{$1} = [ split_addrs($2) ];
}},
gnus => sub { my $fh = shift; while (<$fh>) {
if (/\(define-mail-alias\s+"(\S+?)"\s+"(\S+?)"\)/) {
@@ -588,7 +593,7 @@ if (!@to) {
}
my $to = $_;
- push @to, split /,\s*/, $to;
+ push @to, split_addrs($to);
$prompting++;
}
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] Remove the requirement opaquelocktoken uri scheme
From: Junio C Hamano @ 2008-12-19 7:32 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: git
In-Reply-To: <1229651491-23060-1-git-send-email-catap@catap.ru>
"Kirill A. Korinskiy" <catap@catap.ru> writes:
> Server can use any URI for token by rfc 4918 section 6.5 paragraph five
>
> Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
Could you give a bit more high-level background information behind this
patch?
I can make a guess without knowing much about DAV that this might be...
The program flow of pushing over http is:
- call lock_remote() to issue a DAV_LOCK request to the server to lock
info/refs and branch refs being pushed into; handle_new_lock_ctx() is
used to parse its response to populate "struct remote_lock" that is
returned from lock_remote();
- send objects;
- call unlock_remote() to drop the lock.
The handle_new_lock_ctx() function assumed that the server will use a
lock token in opaquelocktoken URI scheme, which may have been an Ok
assumption under RFC 2518, but under RFC 4918 which obsoletes the older
standard it is not necessarily true.
This resulted in push failure (often resulted in "xxxxx" error message)
when talking to a server that does not use opaquelocktoken URI scheme.
But I shouldn't have to guess or write the commit log message for you.
Giving a bit higher level background is important for people who may have
seen the error message (so filling in the "xxxxx" blank in the above
hypothetical commit log message is *important*) to find your message and
try your commit to see if it fixes the issue for them.
^ permalink raw reply
* Re: [PATCH] git-send-email: handle email address with quoted comma
From: Junio C Hamano @ 2008-12-19 6:40 UTC (permalink / raw)
To: Wu Fengguang; +Cc: git
In-Reply-To: <1229658012-9240-1-git-send-email-fengguang.wu@intel.com>
Wu Fengguang <fengguang.wu@intel.com> writes:
> Correctly handle email addresses containing quoted commas, e.g.
>
> "Zhu, Yi" <yi.zhu@intel.com>, "Li, Shaohua" <shaohua.li@intel.com>
>
> Here the commas inside the double quotes are NOT email separators.
Thanks.
> @@ -359,6 +360,12 @@ foreach my $entry (@bcclist) {
> die "Comma in --bcclist entry: $entry'\n" unless $entry !~ m/,/;
> }
>
> +sub split_addrs($) {
> + my ($addrs) = @_;
> +
> + return "ewords('\s*,\s*', 1, $addrs);
> +}
> +
Does it add real value (e.g. type safety, simplified interface to the
caller, etc.) to force scalar context to the callers? It has been my
experience that use of prototypes (aka "parameter context templates") in
Perl programs tend to make the code less readable and more error prone in
longer term. I would further say that, even though you do not have any
existing caller of split_addrs sub that uses it for more than two values,
not using the prototype would be a better way to write this sub in this
particular case, because it would allow callers to say [*1*]:
@addrs = split_addr(@list_of_addr_lines);
It also is a bit funny-looking to invoke &function() (it is Perl4 style,
isn't it?)
IOW, wouldn't this be a better alternative?
sub split_addrs {
return quotewords('\s*,\s*', 1, @_);
}
[Footnote]
*1* This program demonstrates why use of prototype in this case is more
confusing than it is worth.
-- >8 --
#!/usr/bin/perl -w
use Text::ParseWords;
sub foo ($) { my ($addrs) = @_; return quotewords('\s*,\s*', 1, $addrs); }
sub bar { return quotewords('\s*,\s*', 1, @_); }
my @addrs = ('Frotz, "Xyzzy, Zork", Nitfol', 'Yomin, Rezrov');
my @addr = ($addrs[0]);
for (foo($addrs[0])) {
print "foo(\$addrs[0]) <<$_>>\n";
}
for (foo(@addr)) {
print "foo(\@addr) <<$_>>\n";
}
for (bar($addrs[0])) {
print "bar(\$addrs[0]) <<$_>>\n";
}
for (bar(@addr)) {
print "bar(\@addr) <<$_>>\n";
}
-- 8< --
The output from the above (the fourth one is the most interesting) looks
like this.
foo($addrs[0]) <<Frotz>>
foo($addrs[0]) <<"Xyzzy, Zork">>
foo($addrs[0]) <<Nitfol>>
foo(@addr) <<1>>
bar($addrs[0]) <<Frotz>>
bar($addrs[0]) <<"Xyzzy, Zork">>
bar($addrs[0]) <<Nitfol>>
bar(@addr) <<Frotz>>
bar(@addr) <<"Xyzzy, Zork">>
bar(@addr) <<Nitfol>>
*2* A more detailed discussion on Perl's "prototypes" is found here:
http://web.archive.org/web/20080210085941/http://library.n0i.net/programming/perl/articles/fm_prototypes/
^ permalink raw reply
* Re: [PATCH] git-send-email: handle email address with quoted comma
From: Matt Kraai @ 2008-12-19 6:38 UTC (permalink / raw)
To: Wu Fengguang, git
Howdy,
> +sub split_addrs($) {
> + my ($addrs) = @_;
> +
> + return "ewords('\s*,\s*', 1, $addrs);
> +}
> +
According to the documentation of Text::ParseWords,
The &*quotewords() functions simply call &parse_line(), so if you're
only splitting one line you can call &parse_line() directly and save
a function call.
so quotewords could be replaced by parse_line. I don't know if that's
less readable, though.
--
Matt http://ftbfs.org/
^ permalink raw reply
* Re: [PATCH] Make git revert warn the user when reverting a merge commit.
From: Junio C Hamano @ 2008-12-19 6:35 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: Jay Soffian, git, Johannes Schindelin, Linus Torvalds, Alan
In-Reply-To: <200812182354.16269.bss@iguanasuicide.net>
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> In addition, I think a one-time-per-user warning would be nice, but I'm not
> sure the best way to implement that. My initial thoughts would be reading a
> boolean config option, if unset/true issuing the warning and then if unset
> set it to false. However, that seems a bit... unclean and I fear there might
> be a policy against writing ~/.gitconfig configuration options from a
> subcommand other than 'git config'. Any suggestions on the implementation?
As an end user, I find one-time-per-user warning more frustrating than it
is worth. I may see the warning issued for the first time of my using
certain feature, and because I am so novice to the program suite that I do
not fully understand what the warning is trying to say when I see it.
Thanks to the "one-time-per-user"-ness, that is the only chance for me to
see the message --- which often means that I won't see the warning before
the gravity of it has any chance to really sink in my mind.
"You can set i-know-what-i-am-doing in your ~/.xyzzyconfig file to squelch
this message" is slightly better, as (1) I can control when I stop seeing
it, and (2) because setting that in my config is done by me, as opposed to
the tool doing behind my back, it is much more likely for me to recall how
to get the warning back when I choose to see it again.
The above discussion is "in general". In this particular case, I am not
convinced if the warning itself is worth it, though.
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Willy Tarreau @ 2008-12-19 6:33 UTC (permalink / raw)
To: sverre; +Cc: David Howells, Jakub Narebski, torvalds, git, linux-kernel
In-Reply-To: <bd6139dc0812121716w73ea1145w7f870e887e00adc0@mail.gmail.com>
On Sat, Dec 13, 2008 at 02:16:34AM +0100, Sverre Rabbelier wrote:
> On Sat, Dec 13, 2008 at 02:04, David Howells <dhowells@redhat.com> wrote:
> > (3) You put some non-basic stuff in the basic section (branching - this isn't
> > ordinarily useful, IMHO), but you miss other stuff out ('git rm' for
> > example).
>
> Erm, branching is not ordinarily useful? I think you're Doing It Wrong
> (TM) then, since branching is a Big Thing (also TM) in DVC, not using
> branches would be a bit like only using the first 4 gears in a car;
> sure, it's possible, but you're missing all that extra power!
People who want to use it as a CVS replacement don't realize that they're
using branches. They work in their local "master" branch, and don't realize
that when they fetch updates, they fetch them into a different branch.
CVS people are afraid of branches, so trying to explain them how they can
do what they're used to is better than telling them they'll have to do
what they're afraid of.
I found David's howto quite understandable. I've taught Git to people who
only knew about SVN and to people who had never heard about any SCM at all. I
tried to use the same approach each time, and while I noticed that explaining
how Git works and why it works like that appeared obvious to the newbies,
it was very awkward with SVN users. I switched to something more like
David's approach for those people and it helped a lot. They have plenty
of time after that to discover the tool by themselves.
I really think that David should maintain his doc after applying a few
fixes to it, just like Jeff maintains his own. Also, having several docs
out of the tree is better for a user looking for different analysis of
the tool than having everything offered as the product's documentation,
provided the links are easy to find (might be linked to from the Git doc).
Willy
^ permalink raw reply
* Re: [PATCH] Make git revert warn the user when reverting a merge commit.
From: Boyd Stephen Smith Jr. @ 2008-12-19 5:54 UTC (permalink / raw)
To: Jay Soffian
Cc: git, Junio C Hamano, Johannes Schindelin, Linus Torvalds, Alan
In-Reply-To: <76718490812181955u5f56180en47b3a8268c3538bb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
On Thursday 2008 December 18 21:55:13 Jay Soffian wrote:
> On Thu, Dec 18, 2008 at 10:29 PM, Boyd Stephen Smith Jr.
>
> <bss@iguanasuicide.net> wrote:
> > At least, it might make someone read the manpage again. Still, I'm
> > unhappy with the message, but I didn't want to be too wordy. A URL or
> > manpage reference would be nice, but I didn't know of a good guide that
> > explained the dangers of reverting a merge commit as well as Linus's
> > emails.
>
> Put his email in Documentation/howto/undoing-merge-commits.txt and
> reference that?
Okay, I've got a documentation patch brewing, but it's too late here to work
on it more. I'll post it over the weekend.
In addition, I think a one-time-per-user warning would be nice, but I'm not
sure the best way to implement that. My initial thoughts would be reading a
boolean config option, if unset/true issuing the warning and then if unset
set it to false. However, that seems a bit... unclean and I fear there might
be a policy against writing ~/.gitconfig configuration options from a
subcommand other than 'git config'. Any suggestions on the implementation?
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Paul E. McKenney @ 2008-12-19 5:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Howells, torvalds, git, linux-kernel
In-Reply-To: <alpine.DEB.1.00.0812190336450.14632@racer>
On Fri, Dec 19, 2008 at 03:38:58AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 18 Dec 2008, Paul E. McKenney wrote:
>
> > On Fri, Dec 12, 2008 at 07:57:38PM +0100, Johannes Schindelin wrote:
> >
> > > On Fri, 12 Dec 2008, David Howells wrote:
> > >
> > > > Documentation/git-haters-guide.txt | 1283 ++++++++++++++++++++++++++++++++++++
> > >
> > > I am sure we want to have something like that in git.git.
> >
> > So am I. Except that I am not being sarcastic. ;-)
>
> Good idea. Ask somebody to put up some advertisement _against_ her own
> product into their shop window.
>
> Very good idea.
Actually works fairly well in many cases. But it is your shop, not mine.
Do what you like.
> Ciao,
> Dscho
>
> P.S.: Can I ask you to shoot yourself in the foot?
Sure, go ahead.
> P.P.S.: If you are really a Git hater, why are you lurking here? Go away,
> Subversion is not that bad.
My friend, you are shooting yourself in the foot.
Thanx, Paul
^ permalink raw reply
* Re: Odd merge behaviour involving reverts
From: Daniel Barkalow @ 2008-12-19 5:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nanako Shiraishi, Alan, git
In-Reply-To: <alpine.LFD.2.00.0812181949450.14014@localhost.localdomain>
On Thu, 18 Dec 2008, Linus Torvalds wrote:
> On Fri, 19 Dec 2008, Nanako Shiraishi wrote:
> >
> > If you revert the revert on the branch before merging, doesn't it mean
> > that you will be merging what the older version of the branch did (that
> > is in the revert of the revert as a single huge patch) and what the
> > updated version of the branch wants to do? Wouldn't that lead to a mess
> > with huge conflicts?
>
> Actually, the reverse is likely true. If the branch you are merging is
> actually doing something branch-specific - ie it's a "topic branch", then
> it's likely that the new stuff that is on that branch depends on the
> previous stuff on the branch.
>
> And thats' the thing that got reverted - so with just a revert, it's quite
> likely that you'll get conflicts. But if you revert the revert, now the
> new stuff you're merging actually makes more sense, and is less likely to
> conflict.
>
> Another way of looking at it is that a merge is something that can be done
> both ways: think of the _other_ branch merging yours. The original revert
> ends up being a big change-patch that undoes everything that other branch
> did, so now if that other branch were to merge the main branch, you'd be
> merging a lot of changes. But reverting the revert will undo all those
> changes, so again, it's more likely that the merge will succeed.
>
> So revertign a revert is usually going to make subsequent merges easier
> rather than the reverse.
>
> The _big_ problem with reverting a whole merge is that it effectively
> becomes one commit that does a big change. That's how _normal_ merges tend
> to look like in CVS or SVN (ie the "merge" is really just another commit
> that brings in a lot of changes), and it's a total and utter f*cking
> disaster!
Another option is to do the big revert on the master branch, and on the
side branch merge the parent of the revert (normally), and then merge the
revert but take the side branch tree.
That last merge puts the revert in the branch's history, but rejects its
effects. Now merging the branch again will find the revert to be the
common ancestor, and see the full change of the side branch as the
contribution of that side. Also, blame will come down the side branch,
ignore the merge (on the side branch, the merge contributed no content
changes), and go into the original side branch commits.
You can also think of it as the side branch saying, "I noticed that you
reverted my changes, but I'm keeping them anyway". When the final merge
comes, git will see that the revert isn't new information to the side
branch, and nullify its effect. (Of course, the side branch needs to merge
the parent of the revert so that it isn't rejecting the other changes made
on the main branch before the revert)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git with Hudson
From: Dilip M @ 2008-12-19 4:58 UTC (permalink / raw)
To: git
In-Reply-To: <D2F0F023-862A-4BAB-88B9-BFEFC5592D10@strakersoftware.com>
On Fri, Dec 19, 2008 at 12:53 AM, <indy@strakersoftware.com> wrote:
On Fri, Dec 19, 2008 at 3:37 AM, <stephen@exigencecorp.com> wrote:
indy> However, before we do that I wanted to check if anyone has had any
indy> experience/feedback in integrating Git with Hudson CI server?
We want to try it in futrure when GIT will be used for some projects. It
will be nice to share the knowledge on hudson tool. :)
B.W, what version of hudson you are using? Java version? TOMCAT
version?
It is stable? Have you seen something like "(appears to be stuck)
entries"...
stephen> We eventually wrote our own Hudson git plugin that is simpler and
stephen> doesn't do any funny rev-listing/walking. It just stores last hash
stephen> built and rebuilds once that doesn't match the branch tip. Once that
stephen> was in place, it worked great.
I am eager to have it..please publish.
-dm
^ permalink raw reply
* Re: Odd merge behaviour involving reverts
From: Linus Torvalds @ 2008-12-19 4:23 UTC (permalink / raw)
To: Jay Soffian; +Cc: Nanako Shiraishi, Alan, git
In-Reply-To: <76718490812182018x37e3d6fob8d817c0e0b0e293@mail.gmail.com>
On Thu, 18 Dec 2008, Jay Soffian wrote:
>
> Instead of reverting the revert, why not rebase the branch which was
> merged to the point after the revert was done?
Sure, you can do that too. However, that has its own set of problems, ie
all the "ok, who else was working based on this branch" thing.
But no, there are no single right answers. Rebasing may well be a
reasonable approach.
Linus
^ permalink raw reply
* Re: Odd merge behaviour involving reverts
From: Jay Soffian @ 2008-12-19 4:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nanako Shiraishi, Alan, git
In-Reply-To: <alpine.LFD.2.00.0812181949450.14014@localhost.localdomain>
On Thu, Dec 18, 2008 at 11:01 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> Yes, it's more complex, and no, it's not always going to work (sometimes
> the answer is: "oops, I really shouldn't have merged it, because it wasn't
> ready yet, and I really need to undo _all_ of the merge"). So then you
> really should revert the merge, but when you want to re-do the merge, you
> now need to do it by reverting the revert.
Instead of reverting the revert, why not rebase the branch which was
merged to the point after the revert was done?
j.
^ permalink raw reply
* Re: Odd merge behaviour involving reverts
From: Linus Torvalds @ 2008-12-19 4:01 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Alan, git
In-Reply-To: <20081219124452.6117@nanako3.lavabit.com>
On Fri, 19 Dec 2008, Nanako Shiraishi wrote:
>
> If you revert the revert on the branch before merging, doesn't it mean
> that you will be merging what the older version of the branch did (that
> is in the revert of the revert as a single huge patch) and what the
> updated version of the branch wants to do? Wouldn't that lead to a mess
> with huge conflicts?
Actually, the reverse is likely true. If the branch you are merging is
actually doing something branch-specific - ie it's a "topic branch", then
it's likely that the new stuff that is on that branch depends on the
previous stuff on the branch.
And thats' the thing that got reverted - so with just a revert, it's quite
likely that you'll get conflicts. But if you revert the revert, now the
new stuff you're merging actually makes more sense, and is less likely to
conflict.
Another way of looking at it is that a merge is something that can be done
both ways: think of the _other_ branch merging yours. The original revert
ends up being a big change-patch that undoes everything that other branch
did, so now if that other branch were to merge the main branch, you'd be
merging a lot of changes. But reverting the revert will undo all those
changes, so again, it's more likely that the merge will succeed.
So revertign a revert is usually going to make subsequent merges easier
rather than the reverse.
The _big_ problem with reverting a whole merge is that it effectively
becomes one commit that does a big change. That's how _normal_ merges tend
to look like in CVS or SVN (ie the "merge" is really just another commit
that brings in a lot of changes), and it's a total and utter f*cking
disaster!
But don't get me wrong - it's not something you can't work with. I'm just
trying to say that it's absolutely not a "good model". It's workable, but
it has all these painful issues.
For example, think about what reverting a merge (and then reverting the
revert) does to bisectability. Ignore the fact that the revert of a revert
is undoing it - just think of it as a "single commit that does a lot".
Because that is what it does.
When you have a problem you are chasing down, and you hit a "revert this
merge", what you're hitting is essentially a single commit that contains
all the changes (but obviously in reverse) of all the commits that got
merged. So it's debugging hell, because now you don't have lots of small
changes that you can try to pinpoint which _part_ of it changes.
But does it all work? Sure it does. You can revert a merge, and from a
purely technical angle, git did it very naturally and had no real
troubles. It just considered it a change from "state before merge" to
"state after merge", and that was it. Nothing complicated, nothing odd,
nothing really dangerous. Git will do it without even thinking about it.
So from a technical angle, there's nothing wrong with reverting a merge,
but from a workflow angle it's something that you generally should try to
avoid.
If at all possible, for example, if you find a problem that got merged
into the main tree, rather than revert the merge, try _really_ hard to
bisect the problem down into the branch you merged, and just fix it, or
try to revert the individual commit that caused it.
Yes, it's more complex, and no, it's not always going to work (sometimes
the answer is: "oops, I really shouldn't have merged it, because it wasn't
ready yet, and I really need to undo _all_ of the merge"). So then you
really should revert the merge, but when you want to re-do the merge, you
now need to do it by reverting the revert.
Linus
^ permalink raw reply
* Re: [PATCH] Make git revert warn the user when reverting a merge commit.
From: Jay Soffian @ 2008-12-19 3:55 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: git, Junio C Hamano, Johannes Schindelin, Linus Torvalds, Alan
In-Reply-To: <200812182129.01021.bss@iguanasuicide.net>
On Thu, Dec 18, 2008 at 10:29 PM, Boyd Stephen Smith Jr.
<bss@iguanasuicide.net> wrote:
> At least, it might make someone read the manpage again. Still, I'm unhappy
> with the message, but I didn't want to be too wordy. A URL or manpage
> reference would be nice, but I didn't know of a good guide that explained the
> dangers of reverting a merge commit as well as Linus's emails.
Put his email in Documentation/howto/undoing-merge-commits.txt and
reference that?
j.
^ permalink raw reply
* Re: git-rm -n leaves .git/index.lock if not allowed to finish
From: Miklos Vajna @ 2008-12-19 3:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jidanni, git
In-Reply-To: <7v63lhf1cl.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
On Thu, Dec 18, 2008 at 04:35:54PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> I think you need to have tons of files to cause the pipe buffer to fill up
> with the "rm 'frotz'" output, triggering a SIGPIPE to kill the upstream
> process of the pipe.
Ah, you are right. I did exactly what is in the lockfile.c part of your
patch, but I did not think about "if I don't get a SIGPIPE for 2 lines,
I may get one for 1000 lines". ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Odd merge behaviour involving reverts
From: Nanako Shiraishi @ 2008-12-19 3:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alan, git
In-Reply-To: <alpine.LFD.2.00.0812181534310.14014@localhost.localdomain>
Quoting Linus Torvalds <torvalds@linux-foundation.org>:
> On Thu, 18 Dec 2008, Alan wrote:
>>
>> What am i doing wrong here?
>
> Reverting a merge is your problem.
>
> You can do it, but you seem to have done it without understanding what it
> causes.
>
> A revert of a merge becomes a regular commit that just undoes everything
> that the merge did in your branch. When you then do the next merge, you'll
> do that merge with that in mind, so now git will essentially consider the
> previous merge to be the base line, but your revert undid everything that
> that one brought in, so the new merge will really only contain the new
> stuff from the branch you are merging.
>
> So if a merge causes problems, you generally should either undo it
> _entirely_ (ie do a 'git reset --hard ORIG_HEAD'), not revert it.
>
> Of course, if you had already made the merged state public, or done
> development on top of it, you can't really do that. In which case a revert
> works, but if you want it back, you should revert the revert, not merge
> the branch again - because what you merged last time you threw away, and
> won't be applied again.
If I understand Alan's case correctly, I think he does not want to "undo" the revert but wants to merge an updated version of the branch, as if no mistaken merge nor its revert happened in the past.
If you revert the revert on the branch before merging, doesn't it mean that you will be merging what the older version of the branch did (that is in the revert of the revert as a single huge patch) and what the updated version of the branch wants to do? Wouldn't that lead to a mess with huge conflicts?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ 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