* [PATCH 2/2] Documentation: Refer to git-rebase(1) to warn against rewriting
From: Thomas Rast @ 2008-09-11 15:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1221147525-5589-2-git-send-email-trast@student.ethz.ch>
This points readers at the "Recovering from upstream rebase" warning
in git-rebase(1) when we talk about rewriting published history in the
'reset', 'commit --amend', and 'filter-branch' documentation.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-commit.txt | 4 ++++
Documentation/git-filter-branch.txt | 4 +++-
Documentation/git-reset.txt | 4 +++-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index eb05b0f..eeba58d 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -144,6 +144,10 @@ It is a rough equivalent for:
------
but can be used to amend a merge commit.
--
++
+You should understand the implications of rewriting history if you
+amend a commit that has already been published. (See the "RECOVERING
+FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
-i::
--include::
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index b0e710d..fed6de6 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -36,7 +36,9 @@ the objects and will not converge with the original branch. You will not
be able to easily push and distribute the rewritten branch on top of the
original branch. Please do not use this command if you do not know the
full implications, and avoid using it anyway, if a simple single commit
-would suffice to fix your problem.
+would suffice to fix your problem. (See the "RECOVERING FROM UPSTREAM
+REBASE" section in linkgit:git-rebase[1] for further information about
+rewriting published history.)
Always verify that the rewritten version is correct: The original refs,
if different from the rewritten ones, will be stored in the namespace
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 6abaeac..52aab5e 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -82,7 +82,9 @@ $ git reset --hard HEAD~3 <1>
+
<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
and you do not want to ever see them again. Do *not* do this if
-you have already given these commits to somebody else.
+you have already given these commits to somebody else. (See the
+"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for
+the implications of doing so.)
Undo a commit, making it a topic branch::
+
--
1.6.0.1.470.g200b
^ permalink raw reply related
* [PATCH 1/2] Documentation: new upstream rebase recovery section in git-rebase
From: Thomas Rast @ 2008-09-11 15:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1221147525-5589-1-git-send-email-trast@student.ethz.ch>
Documents how to recover if the upstream that you pull from has
rebased the branches you depend your work on. Hopefully this can also
serve as a warning to potential rebasers.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-rebase.txt | 103 +++++++++++++++++++++++++++++++++++++++--
1 files changed, 98 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 59c1b02..ba5255d 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -257,11 +257,10 @@ include::merge-strategies.txt[]
NOTES
-----
-When you rebase a branch, you are changing its history in a way that
-will cause problems for anyone who already has a copy of the branch
-in their repository and tries to pull updates from you. You should
-understand the implications of using 'git-rebase' on a repository that
-you share.
+
+You should understand the implications of using 'git-rebase' on a
+repository that you share. See also RECOVERING FROM UPSTREAM REBASE
+below.
When the git-rebase command is run, it will first execute a "pre-rebase"
hook if one exists. You can use this hook to do sanity checks and
@@ -396,6 +395,100 @@ consistent (they compile, pass the testsuite, etc.) you should use
after each commit, test, and amend the commit if fixes are necessary.
+RECOVERING FROM UPSTREAM REBASE
+-------------------------------
+
+This section briefly explains the problems that arise from rebasing or
+rewriting published branches, and shows how to recover. As you will
+see, the process is rather tedious, so we emphasize again: 'Avoid
+rewriting published history.' This goes for `rebase`, `commit
+--amend`, `reset HEAD^` and `filter-branch` alike.
+
+To illustrate, suppose you are in a situation where someone develops a
+'subsystem' branch, and you are working on a 'topic' that is dependent
+on this 'subsystem'. You might end up with a history like the
+following:
+
+------------
+ o---o---o---o---o master
+ \
+ o---o---o---o---o subsystem
+ \
+ *---*---* topic
+------------
+
+If 'subsystem' is rebased against master, the following happens:
+
+------------
+ o---o---o---o---o master
+ | \
+ | o'--o'--o'--o'--o' subsystem
+ \
+ o---o---o---o---o---*---*---* topic
+------------
+
+Note that while we have marked your own commits with a '*', there is
+nothing that distinguishes them from the commits that previously were
+on 'subsystem'. Luckily, 'git-rebase' knows to skip commits that are
+textually the same as commits in the upstream. So if you say
+(assuming you're on 'topic')
+------------
+ git rebase subsystem
+------------
+you will end up with the fixed history
+------------
+ o---o---o---o---o master
+ \
+ o'--o'--o'--o'--o' subsystem
+ \
+ *'--*'--*' topic
+------------
+
+This becomes a ripple effect to anyone downstream of the first rebase:
+anyone downstream from 'topic' now needs to rebase too, and so on.
+
+Things get more complicated if your upstream used `git rebase
+--interactive` (or `commit --amend` or `reset --hard HEAD^`). Label
+the example history as follows:
+
+------------
+ o---o---o---o---o master
+ \
+ A---B---C---D---E subsystem
+ \
+ X---Y---Z topic
+------------
+
+Now suppose the 'subsystem' maintainer decides to clean up his history
+with an interactive rebase. He edits commits A and D (marked with a
+`*`), decides to remove D entirely and moves B to the front. This
+results in
+
+------------
+ o---o---o---o---o master
+ | \
+ | A*--C*--E'--B' subsystem
+ \
+ A---B---C---D---E---X---Y---Z topic
+------------
+
+'git-rebase' can still tell that E'=E and B'=B, so a plain `git rebase
+subsystem` would not duplicate those commits. However, it would
+**resurrect** D (which may succeed silently!) and try to apply the
+original versions of A and C (probably resulting in conflicts).
+
+To fix this, you have to manually transplant your own part of the
+history to the new branch head. Looking at `git log`, you should be
+able to determine that three commits on 'topic' are yours. Again
+assuming you are already on 'topic', you can do
+------------
+ git rebase --onto subsystem HEAD~3
+------------
+to put things right. Of course, this again ripples onwards:
+'everyone' downstream from 'subsystem' will have to 'manually' rebase
+all their work!
+
+
Authors
------
Written by Junio C Hamano <gitster@pobox.com> and
--
1.6.0.1.470.g200b
^ permalink raw reply related
* [PATCH 0/2.5] Documentation: new upstream rebase recovery section in git-rebase
From: Thomas Rast @ 2008-09-11 15:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <200809030738.09589.trast@student.ethz.ch>
So here's the follow-up I promised.
Junio C Hamano <gitster@pobox.com> wrote:
>
> Thomas Rast <trast@student.ethz.ch> writes:
> > - Is it perhaps too verbose, or in the wrong place? I did not want to
> > detract from the feature descriptions that the manpage should first
> > and foremost contain. Chances that a user will "accidentally" read
> > the section at this position and length seem fairly low however.
>
> It feels on a bit too repetitive side, but I think this is going in the
> right direction. How about dropping the earlier part of the change to
> Notes section (but keep "See also" which is a good guide for understanding
> the said "implications")?
I rewrote it to include the actual rebase behaviour and some scenarios
that arise from 'rebase -i', 'commit --amend' etc., then tried to
shorten the section as far as I could. Hopefully this cut down on the
repetitions. Unfortunately it still grew longer due to the extra
content. The second patch then includes references to that section in
the appropriate manpages.
The third patch is again RFC, and I made it regarding this section:
> The additions you made are all about why rebasing public history is bad
> from mechanisms [...] POV.
> While that description is all good, I think there should also be a
> discussion from the patchflow/workflow angle.
>
> "Upstream has rebased" almost implies that it has its own upstream
> (i.e. "My upstream" is not the toplevel upstream, but is a subsystem tree
> or something).
>
> Rebasing upstream is bad, but an upstream that backmerges from its own
> upstream too often is equally bad, and the reason of the badness, viewed
> from the workflow angle, shares exactly the same component.
>
> It means that the mid-level upstream in question is not focused enough.
I noticed that there is no manpage in which we document such workflows
anyway. There is a short definition of 'topic branch' in
glossary-content.txt, and a parenthetical definition in
user-manual.txt in a sort of "linux.git howto". Nothing longer,
however.
[I learned what I know from Linus's Google Tech Talk[1], Tv's more
recent EuroPython talk[2], looking at git.git, and mail such as the
ones you linked. I recommended [2] to people who asked about topic
branches on #git a few times.]
So this is an attempt to make a "workflow reference". I tried to
strike a balance between "just" a reference (the Rule/Recipe blocks)
and more of a tutorial approach which explains the reasons. I would
again greatly appreciate comments.
- Thomas
Thomas Rast (2+1):
Documentation: new upstream rebase recovery section in git-rebase
Documentation: Refer to git-rebase(1) to warn against rewriting
Documentation: add manpage about workflows
[1] http://video.google.com/videoplay?docid=-2199332044603874737
[2] http://blip.tv/file/1114793/
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 15:32 UTC (permalink / raw)
To: Theodore Tso; +Cc: Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911135146.GE5082@mit.edu>
Theodore Tso wrote:
>On Thu, Sep 11, 2008 at 02:31:48PM +0200, Stephen R. van den Berg wrote:
>> Well, the train of thought here goes as follows:
>> 2. Add support to cherry-pick/revert to actually generate the field upon
>> demand.
>"git cherry-pick -x" already generates the field you want.
Well, sort of. In order for swift parsing it should be a real field,
i.e. it should not be an English sentence (in order to avoid people
accidentally translating it); and it should list a pair of hashes
(patches/changesets are defined by the difference between two tree
snapshots). So it would be a -o option most likely, in order to provide
backward compatibility to the users of -x.
>> 3. Then add support to prune/gc/fsck/blame/log --graph to take the field
>> into account.
>Um, why should "git fsck", or "git prune" or "git gc" need to
>understand about this field? What were you saying about unclean
>semantics, again? I thought you claimed that dangling origin links
>were OK? So why the heck should git fsck care? And why shouldn't
>gc/prune drop objects that are only referenced via the origin link.
Dangling origin links are ok only if the developer in charge of the
repository doesn't care about the commits/branches they point to.
The definition of a "caring developer" is formalised by the fact that
the offending commits are already present in the repository or not.
This implies that fsck will skip the field if the hashes in question are
unreachable in the current repository.
If they are reachable though, fsck will follow the link and check the
whole tree referenced by the origin link. Obviously there are only two
conditions for an origin link: either the hash points to an unreachable
object or the hash points to a reachable object of type commit (and all
associated checks that go with any commit).
gc will preserve the commits the origin links point to once they are
reachable. I.e. if the developer doesn't care about the commits the
origin links point to (i.e. if the branches are not reachable) then gc
just skips them, if the developer *does* care, the origin links are used
to keep those objects alive (and, of course, all their parenthood).
>> 4. Add support to filter-branch/rebase to renumber the field if necessary.
>As we discussed earlier in some cases renumbering the field is not the
>right thing to do, especially if the commit in question has already
>been cherry-picked --- and you don't know that. Again, this is why
>prototyping it outside of the core git is so useful; it will show up
>some of these fundamental flaws in the origin link proposal.
I agree that the behaviour of especially rebase with respect to the
origin links is still something that needs to be thought through.
I'm not convinced you are right, but I'm not convinced you are wrong
either.
>> Well, and after having done steps 1 to 5, the net result is that it
>> works almost as if the field is present in the header, except that:
>> - It is now at the end of the body in the commit message.
>> - It takes more time to find and parse it.
>A proof of concept, even if it isn't fully performant, is useful to
>prove that an idea actually has merit --- which clearly not everyone
>believes at this point.
Quite.
>I'll also note that having a ***local*** database to cache the origin
>link is a great way of short-circuiting the performance difficulties.
>If it works, then it will be a lot easier to convince people that
>perhaps it should be done git-core, and by modifying core git functions.
Creating local databases for these kinds of structures feels kludgy
somehow, since the git hash objects essentially *are* a working
database. I have not checked yet if git already has some kind of
ready-to-use local database lib inside which I could reuse for that.
>Alternatively, if you think this is such a great idea, why don't you
>grab a copy of the git repository, and start hacking the idea
>yourself?
Actually, in the first hour after posting the initial mail/proposal I
already had altered a local version of git to support the origin links
in commit.[ch], --topo-order and fsck. Before hacking further I decided
to get some feedback first to see if someone would come up with
something better. And they did, instead of the mainline number, I
decided that using two hashes is better. Once the dust has settled,
I'll fill in the rest of the code.
> If you have running code, it tends to make the idea much
>more concrete, and much easier to evaluate.
Agreed, but then again, most of the programming is done without touching
any code (the design phase), which is where we are now. Once the design
is scrutinised (as far as possible), the coding can begin (continue).
The feedback so far was very helpful, and caused me to explore (and
dismiss) some of the alternate avenues to achieve the desired
functionality.
> Or were you hoping to
>convince other people to do all of this programming for you?
I've never needed that so far, and will not need that here either.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Nicolas Pitre @ 2008-09-11 15:02 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911123148.GA2056@cuci.nl>
On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
> So short-circuiting the reasoning suggests that since the only thing
> that actually changes now is the position of the field (at the top or
> end of the commit message), we might as well do it right and put it in
> the top, that gets rid of the two minuses.
>
> Anything I missed?
A good convincing demonstration that this is actually worth doing in the
first place. And here I'm talking about the _feature_ and not the
_implementation_.
> Basically it means that:
>
> a. If there is a better solution to tracking the backports, I'll gladly
> use that instead, but simply using the current really freeform
> approach doesn't cut it (it currently refers to a single commit,
> instead of a pair of commits, and takes too long to parse out in a
> --top-order or blame command). Better solutions I haven't heard so
> far.
>
> b. I need the integrity protection of a commit to make sure that the
> origin fields cannot be altered later; blame would be too easy to fool
> otherwise. So using the notes solution seems to be out (it would also
> be quite a performance hit again).
>
> c. I consider the Origin: field at the end of the commit message a
> workable solution, but it smells like X-header-extension-messes as in
> E-mail headers, and it incurs a small performance hit (in case of
> --topo-order/blame/prune/fsck), but maybe this performance hit can be
> minimised by making sure that the fields are *always* at the end
> of the commit message.
>
> d. Using the proposed origin header in the standard commit header has
> close to zero overhead (in most commits the field is not present), yet
> codecomplexitywise it is almost identical with the Origin: field at
> the end of the commit message.
>
> I find it remarkable though that people are dragging their feet at
> solution d, yet are quite ok with solution c. IMO solution c and d are
> almost identical, except that solution c is ugly, and solution d is
> elegant. But if it makes it easier to prove the usefulness by
> implementing the ugly solution first, that's fine.
Technically speaking, implementation d is obviously the most efficient.
but, as mentioned above, the actual need for this feature has not been
convincing so far. Until then, it is not wise to add random stuff to
the very structure of a commit object, while c can be done even
externally from git which is a good way to demonstrate and convince
people about the usefulness of such feature.
Nicolas
^ permalink raw reply
* [PATCH] Add git-svn branch to allow branch creation in SVN repositories
From: Florian Ragwitz @ 2008-09-11 14:20 UTC (permalink / raw)
To: git; +Cc: Florian Ragwitz
Signed-off-by: Florian Ragwitz <rafl@debian.org>
---
Documentation/git-svn.txt | 24 +++++++++++++++++++++++-
git-svn.perl | 43 ++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 65 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 1e644ca..0fe4955 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -149,6 +149,22 @@ and have no uncommitted changes.
is very strongly discouraged.
--
+'branch'::
+ Create a branch in the SVN repository.
+
+-m;;
+--message;;
+ Allows to specify the commit message.
+
+-t;;
+--tag;;
+ Create a tag by using the tags_subdir instead of the branches_subdir
+ specified during git svn init.
+
+'tag'::
+ Create a tag in the SVN repository. This is a shorthand for
+ 'branch -t'.
+
'log'::
This should make it easy to look up svn log messages when svn
users refer to -r/--revision numbers.
@@ -372,7 +388,8 @@ Passed directly to 'git-rebase' when using 'dcommit' if a
-n::
--dry-run::
-This can be used with the 'dcommit' and 'rebase' commands.
+This can be used with the 'dcommit', 'rebase', 'branch' and 'tag'
+commands.
For 'dcommit', print out the series of git arguments that would show
which diffs would be committed to SVN.
@@ -381,6 +398,9 @@ For 'rebase', display the local branch associated with the upstream svn
repository associated with the current branch and the URL of svn
repository that will be fetched from.
+For 'branch' and 'tag', display the urls that will be used for copying when
+creating the branch or tag.
+
--
ADVANCED OPTIONS
@@ -498,6 +518,8 @@ Tracking and contributing to an entire Subversion-managed project
git svn clone http://svn.foo.org/project -T trunk -b branches -t tags
# View all branches and tags you have cloned:
git branch -r
+# Create a new branch in SVN
+ git svn branch waldo
# Reset your master to trunk (or any other branch, replacing 'trunk'
# with the appropriate name):
git reset --hard remotes/trunk
diff --git a/git-svn.perl b/git-svn.perl
index 88066c9..54a785c 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -66,7 +66,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format, $_commit_url);
+ $_git_format, $_commit_url, $_tag);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -131,6 +131,14 @@ my %cmd = (
'revision|r=i' => \$_revision,
'no-rebase' => \$_no_rebase,
%cmt_opts, %fc_opts } ],
+ branch => [ \&cmd_branch,
+ 'Create a branch in the SVN repository',
+ { 'message|m=s' => \$_message,
+ 'dry-run|n' => \$_dry_run } ],
+ tag => [ sub { $_tag = 1; cmd_branch(@_) },
+ 'Create a tag in the SVN repository',
+ { 'message|m=s' => \$_message,
+ 'dry-run|n' => \$_dry_run } ],
'set-tree' => [ \&cmd_set_tree,
"Set an SVN repository to a git tree-ish",
{ 'stdin|' => \$_stdin, %cmt_opts, %fc_opts, } ],
@@ -537,6 +545,39 @@ sub cmd_dcommit {
unlink $gs->{index};
}
+sub cmd_branch {
+ my ($branch_name, $head) = @_;
+
+ die "branch name required\n" unless $branch_name;
+ $head ||= 'HEAD';
+
+ my ($src, $rev, undef, $gs) = working_head_info($head);
+
+ my $remote = Git::SVN::read_all_remotes()->{svn};
+ my $glob = $remote->{ $_tag ? 'tags' : 'branches' };
+ my ($lft, $rgt) = @{ $glob->{path} }{qw/left right/};
+ my $dst = join '/', $remote->{url}, $lft, $branch_name, ($rgt || ());
+
+ my $ctx = SVN::Client->new(
+ auth => Git::SVN::Ra::_auth_providers(),
+ log_msg => sub {
+ ${ $_[0] } = defined $_message
+ ? $_message
+ : 'Create branch ' . $branch_name;
+ },
+ );
+
+ eval {
+ $ctx->ls($dst, 'HEAD', 0);
+ } and die "branch ${branch_name} already exists\n";
+
+ print "Copying ${src} at r${rev} to ${dst}...\n";
+ $ctx->copy($src, $rev, $dst)
+ unless $_dry_run;
+
+ $gs->fetch_all;
+}
+
sub cmd_find_rev {
my $revision_or_hash = shift or die "SVN or git revision required ",
"as a command-line argument\n";
--
1.5.6.5
^ permalink raw reply related
* Re: [RFC] origin link for cherry-pick and revert
From: Theodore Tso @ 2008-09-11 13:51 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911123148.GA2056@cuci.nl>
On Thu, Sep 11, 2008 at 02:31:48PM +0200, Stephen R. van den Berg wrote:
>
> Well, the train of thought here goes as follows:
> 1. Sure, why not add a field (zero or more) at the bottom of the free-form
> commit message reading like:
>
> Origin: bbb896d8e10f736bfda8f587c0009c358c9a8599 ee837244df2e2e4e9171f508f83f353730db9e53
>
> 2. Add support to cherry-pick/revert to actually generate the field upon
> demand.
"git cherry-pick -x" already generates the field you want.
>
> 3. Then add support to prune/gc/fsck/blame/log --graph to take the field
> into account.
>
Um, why should "git fsck", or "git prune" or "git gc" need to
understand about this field? What were you saying about unclean
semantics, again? I thought you claimed that dangling origin links
were OK? So why the heck should git fsck care? And why shouldn't
gc/prune drop objects that are only referenced via the origin link.
> 4. Add support to filter-branch/rebase to renumber the field if necessary.
As we discussed earlier in some cases renumbering the field is not the
right thing to do, especially if the commit in question has already
been cherry-picked --- and you don't know that. Again, this is why
prototyping it outside of the core git is so useful; it will show up
some of these fundamental flaws in the origin link proposal.
> Well, and after having done steps 1 to 5, the net result is that it
> works almost as if the field is present in the header, except that:
> - It is now at the end of the body in the commit message.
> - It takes more time to find and parse it.
A proof of concept, even if it isn't fully performant, is useful to
prove that an idea actually has merit --- which clearly not everyone
believes at this point.
I'll also note that having a ***local*** database to cache the origin
link is a great way of short-circuiting the performance difficulties.
If it works, then it will be a lot easier to convince people that
perhaps it should be done git-core, and by modifying core git functions.
Alternatively, if you think this is such a great idea, why don't you
grab a copy of the git repository, and start hacking the idea
yourself? If you have running code, it tends to make the idea much
more concrete, and much easier to evaluate. Or were you hoping to
convince other people to do all of this programming for you?
- Ted
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 12:39 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Linus Torvalds, Jakub Narebski, git
In-Reply-To: <48C90F06.4000309@gmail.com>
A Large Angry SCM wrote:
>Stephen R. van den Berg wrote:
>>If you fetch just branches A, B and C, but not D, the origin link from A
>>to D is dangling.
>I do not understand how this can be considered an acceptable behavior.
>If an object ID is referenced in an object header, particularly commit
>objects, fetch must gather those objects also because to do otherwise
>breaks the cryptographic authentication in git.
No it does not.
The cryptographic seal is calculated over the content of the commit,
which includes the hashes of all referenced objects, but doesn't include
the objects themselves.
The content of the commit is not violated.
Do not forget though:
- origin links are a rare occurrence.
- When they occur, they usually were made to point into other (deemed)
important public branches.
- Due to the fact that the branches they are pointing into are important
and public, in most cases the origin links *will* point to objects you
actually already have (even if you fetched from someone else).
- The only time you're going to have dangling origin links is when
they were pointing at someone's private branches, in which case it was
not very prudent of the committer to actually record the link in the
first place. But nothing breaks if you don't have his private branch
locally.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: A Large Angry SCM @ 2008-09-11 12:33 UTC (permalink / raw)
To: Stephen R. van den Berg
Cc: Paolo Bonzini, Jeff King, Theodore Tso, Petr Baudis, git
In-Reply-To: <20080911075539.GA27089@cuci.nl>
Stephen R. van den Berg wrote:
> It would fit with a non-mutable version of the notes. Then again, we
> already *have* the non-mutable version of the notes, it's called the
> header of the commit message.
Almost correct. Remove "header of" from the above and you'd be correct.
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 12:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Linus Torvalds, git
In-Reply-To: <200809111020.55115.jnareb@gmail.com>
Jakub Narebski wrote:
>Stephen R. van den Berg wrote:
>[...]
>> Please focus on the semantics and on the *non*-made up use case of
>> development of several stable branches with backports between them.
>> Discussing made-up use cases is wasting energy at this point.
>By the way, I would really consider trying first to host 'origin' links
>not in repository database itself, but in some extra database inside
>git repository, like reflog or index. Git community is _very_
>reluctant to modifying / extending format of persistent objects. From
Rightfully so, of course.
>So I think you should go the route of externally (outside 'commit'
>objects) maintaing 'origin'/'changeset'/'cset' links (like XLink
>extended links ;-)) as a prototype to examine consequences of the idea.
>That was the way _submodule_ support was added to Git, by the way.
>First there were (at least) two implementations maintaining submodules
>outside object database (see http://git.or.cz/gitwiki/SubprojectSupport
>especially "References" section), then it was officially added first at
>the level of plumbing support, as extension of a 'tree' object (and
>index format, I think).
Well, the train of thought here goes as follows:
1. Sure, why not add a field (zero or more) at the bottom of the free-form
commit message reading like:
Origin: bbb896d8e10f736bfda8f587c0009c358c9a8599 ee837244df2e2e4e9171f508f83f353730db9e53
2. Add support to cherry-pick/revert to actually generate the field upon
demand.
3. Then add support to prune/gc/fsck/blame/log --graph to take the field
into account.
4. Add support to filter-branch/rebase to renumber the field if necessary.
5. Add support to --topo-order to use the field if present and reachable.
6. For bonus points: add support to log to suppress the display of the
field at the end of the commit message, and redisplay the field
as Origin: bbb896d..ee83724
next to the Parent/Merge fields.
Well, and after having done steps 1 to 5, the net result is that it
works almost as if the field is present in the header, except that:
- It is now at the end of the body in the commit message.
- It takes more time to find and parse it.
So that gives two minuses, and no pluses.
So short-circuiting the reasoning suggests that since the only thing
that actually changes now is the position of the field (at the top or
end of the commit message), we might as well do it right and put it in
the top, that gets rid of the two minuses.
Anything I missed?
Basically it means that:
a. If there is a better solution to tracking the backports, I'll gladly
use that instead, but simply using the current really freeform
approach doesn't cut it (it currently refers to a single commit,
instead of a pair of commits, and takes too long to parse out in a
--top-order or blame command). Better solutions I haven't heard so
far.
b. I need the integrity protection of a commit to make sure that the
origin fields cannot be altered later; blame would be too easy to fool
otherwise. So using the notes solution seems to be out (it would also
be quite a performance hit again).
c. I consider the Origin: field at the end of the commit message a
workable solution, but it smells like X-header-extension-messes as in
E-mail headers, and it incurs a small performance hit (in case of
--topo-order/blame/prune/fsck), but maybe this performance hit can be
minimised by making sure that the fields are *always* at the end
of the commit message.
d. Using the proposed origin header in the standard commit header has
close to zero overhead (in most commits the field is not present), yet
codecomplexitywise it is almost identical with the Origin: field at
the end of the commit message.
I find it remarkable though that people are dragging their feet at
solution d, yet are quite ok with solution c. IMO solution c and d are
almost identical, except that solution c is ugly, and solution d is
elegant. But if it makes it easier to prove the usefulness by
implementing the ugly solution first, that's fine.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: A Large Angry SCM @ 2008-09-11 12:28 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Linus Torvalds, Jakub Narebski, git
In-Reply-To: <20080911062242.GA23070@cuci.nl>
Stephen R. van den Berg wrote:
> If you fetch just branches A, B and C, but not D, the origin link from A
> to D is dangling.
I do not understand how this can be considered an acceptable behavior.
If an object ID is referenced in an object header, particularly commit
objects, fetch must gather those objects also because to do otherwise
breaks the cryptographic authentication in git.
^ permalink raw reply
* Re: [PATCH] Use compatibility regex library also on AIX
From: Jeff King @ 2008-09-11 12:12 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Arjen Laarhoven, Junio C Hamano, Johannes Sixt, git
In-Reply-To: <e2b179460809110131h781f0c91i9d478e20b55dec24@mail.gmail.com>
On Thu, Sep 11, 2008 at 09:31:25AM +0100, Mike Ralphson wrote:
> I think the reason it's in pu is that it's in maint, master and next too...
>
> All my test runs went bang this morning. 8-)
Mine too. :)
This is needed for FreeBSD, as well. No idea about OpenBSD or others.
Should probably be squashed with the AIX patch if it's not too late.
-- >8 --
Use compatibility regex library also on FreeBSD
Commit 3632cfc24 makes the same change for Darwin; however, the problem
also exists on FreeBSD.
Signed-off-by: Jeff King <peff@peff.net>
---
diff --git a/Makefile b/Makefile
index 247cd2d..9b1bd7b 100644
--- a/Makefile
+++ b/Makefile
@@ -688,6 +688,8 @@ ifeq ($(uname_S),FreeBSD)
BASIC_LDFLAGS += -L/usr/local/lib
DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
THREADED_DELTA_SEARCH = YesPlease
+ COMPAT_CFLAGS += -Icompat/regex
+ COMPAT_OBJS += compat/regex/regex.o
endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
^ permalink raw reply related
* Re: [PATCH] git wrapper: also uses aliases to suggest mistyped commands
From: Pieter de Bie @ 2008-09-11 10:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailinglist
In-Reply-To: <7vtzcnvfq4.fsf@gitster.siamese.dyndns.org>
On 10 sep 2008, at 23:44, Junio C Hamano wrote:
> Aliases should not hide the commands available elsewhere, and the
> actual
> execution codepath around ll.480-490 in git.c avoids getting fooled by
> misconfigured aliases, but you do not protect yourself from that
> kind of
> misconfiguration in this patch. You can have both "git-foo" command
> on
> your private $PATH and alias.foo in your configuration, and they
> will have
> the same levenshtein score. I suspect this will cause the same "foo"
> suggested twice when the user types "git fo" from the command line.
Yes, I didn't think of that.
> Here is a suggested fix-up on top of your patch to address these
> issues.
Looks good. Do you want me to resend the patch or will you squash it?
- Pieter
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Jan Nieuwenhuizen @ 2008-09-11 8:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080909231009.GD10544@machine.or.cz>
On wo, 2008-09-10 at 01:10 +0200, Petr Baudis wrote:
Hi,
> I decided not to consider the 'tg depend' work by Jan Nieuwenhuiz for
> this release yet, since it will probably take me a bit of time yet to
> fully understand his approach; so far, I have an uneasy feel about it.
Ah, good. It is still an experiment, as far as I'm concerned. Alas,
I haven't gotten round to look at it, really.
We were discussing this, Jonathan Nieder had two more suggestions/ideas
http://kerneltrap.org/mailarchive/git/2008/8/15/2954214
http://kerneltrap.org/mailarchive/git/2008/8/15/2952004
and Bert reported a bug
http://kerneltrap.org/mailarchive/git/2008/9/1/3152864
The last implementation would just recreate a branch with all new
dependencies, which is quite inefficient when you're just removing
or adding one (and the list of dependencies is long, say ~100).
It would be nice if my previous cherry-pick & revert logic would be
combined with git read-tree to create the new dependencies-base.
That could be much faster and hopefully git read-tree could fix
the multiple add/remove issue.
Greetings,
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
^ permalink raw reply
* Re: PATCH: git-p4 optional handling of RCS keywords
From: dhruva @ 2008-09-11 9:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Simon Hausmann, Tor Arvid Lund, GIT SCM, Jing Xue
>From aa822b35925b893de049b6cc4d1531dc476ade56 Mon Sep 17 00:00:00 2001
From: Dhruva Krishnamurthy <dhruva@siml6.eng.btc.netapp.in>
Date: Thu, 11 Sep 2008 14:36:32 +0530
Subject: [PATCH] Modifying RCS keywords prevents submitting to p4 from git due to missing hunks. Optional shrinking of RCS keywords in git-p4. New option git-p4.kwstrip set to true or false controls the behavior
Signed-off-by: Dhruva Krishnamurthy <dhruva@ymail.com>
---
contrib/fast-import/git-p4 | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 2216cac..ac8b7f7 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -16,6 +16,9 @@ from sets import Set;
verbose = False
+# Handling of RCS keyowrds. To ensure backward compatibility, the default
+# is to strip keywords. Default behavior is controlled here
+kwstrip = True
def p4_build_cmd(cmd):
"""Build a suitable p4 command line.
@@ -975,7 +978,9 @@ class P4Sync(Command):
sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
continue
- if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
+ if not kwstrip:
+ pass
+ elif stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
@@ -1850,6 +1855,16 @@ def main():
(cmd, args) = parser.parse_args(sys.argv[2:], cmd);
global verbose
verbose = cmd.verbose
+
+ global kwstrip
+ kwval = gitConfig("git-p4.kwstrip")
+ if len(kwval) > 0:
+ kwval = kwval.lower();
+ if kwval == "false":
+ kwstrip = False
+ elif kwval == "true":
+ kwstrip = True
+
if cmd.needsGit:
if cmd.gitdir == None:
cmd.gitdir = os.path.abspath(".git")
--
1.6.0.1.442.g17b2f
-dhruva
Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here http://in.promos.yahoo.com/address
^ permalink raw reply related
* Re: What's in git.git (Sep 2008, #02; Wed, 10)
From: Michael J Gruber @ 2008-09-11 9:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqt3tk8b.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 11.09.2008 05:49:
> There are still a few topics that are meant for 'maint' cooking in higher
> stages; we will have 1.6.0.2 after they are merged down.
>
> On the 'master' front, it looks like 1.6.1 will not have anything
> particularly big like 1.6.0 did. Other than many s/git-foo/git foo/
> updates in tests (finished -- the documentation needs to go through the
> same process), there are many small bells and whistles enhancements, but
Was there some final consensus on how to undashify the man pages? There
is still the issue of keeping man viewers working which detect links
from man page text like git-commit(1). Within a man page context forms
like that are natural and should not be confusing (assuming man users
know man), but for the html version it's unnatural. In fact, even the
section numbers look unnatural on the html version (pretending to be a
non-man-unaware html "customer"); also, the html doc is not split into
subdirs by section.
I think the cleanest approach would consist in introducing another
linkgit macro (for everything linkgit:git-) which ouputs dashed resp.
dashless forms for docbook (i.e. man) resp. html targets. I'll cook up a
POC if noone keeps me from doing so ;)
Michael
P.S.: There are also dashes to be removed in the text (non-link) of the
doc, of course. But this doesn't pose any technical hurdles.
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Paolo Bonzini @ 2008-09-11 8:45 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jeff King, Theodore Tso, Petr Baudis, git
In-Reply-To: <20080911075539.GA27089@cuci.nl>
>> I actually like the commit notes idea, but then I wonder: why are the
>> author and committer part of the commit object? How does the plumbing
>> use them? Isn't that metadata that could live in the "notes"? And so,
>
> we already *have* the non-mutable version of the notes, it's called the
> header of the commit message.
Yes, that was my point. I don't see how the author and committer fit in
the header of the commit message, if the origin does not.
Paolo
^ permalink raw reply
* Re: [PATCH] Use compatibility regex library also on AIX
From: Mike Ralphson @ 2008-09-11 8:31 UTC (permalink / raw)
To: Arjen Laarhoven, Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <20080911082554.GB27748@regex.yaph.org>
2008/9/11 Arjen Laarhoven <arjen@yaph.org>:
> On Thu, Sep 11, 2008 at 10:14:44AM +0200, Johannes Sixt wrote:
>> This augments 3632cfc24 (Use compatibility regex library on Darwin,
>> 2008-09-07), which already carries a "Tested-by" statement for AIX,
>> but that test was actually done with this patch included.
>
> I hadn't realized it had already gone in to 'pu'. I've put the AIX part
> into my local patch, and also had it tested on HP-UX. Today I'll
> probably can test it on Solaris too, and add that as well.
I think the reason it's in pu is that it's in maint, master and next too...
All my test runs went bang this morning. 8-)
2008/9/11 Junio C Hamano <gitster@pobox.com>:
> Sorry, my fault --- I should have noticed the missing "ifeq AIX"
> anywhere in the hunk headers.
No, I shouldn't have added the Tested-by without making it clear I was
testing the tip of the thread, not the original patch. My bad.
Mike
^ permalink raw reply
* Re: [PATCH] Use compatibility regex library also on AIX
From: Junio C Hamano @ 2008-09-11 8:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Mike Ralphson, git, Arjen Laarhoven
In-Reply-To: <48C8D374.9050007@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> This augments 3632cfc24 (Use compatibility regex library on Darwin,
> 2008-09-07), which already carries a "Tested-by" statement for AIX,
> but that test was actually done with this patch included.
>
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> Tested-by: Mike Ralphson <mike@abacus.co.uk>
> ---
> Mike Ralphson schrieb:
>> 2008/9/10 Mike Ralphson <mike.ralphson@gmail.com>:
>> Junio, sorry, I should have made this clear, but as above in the
>> thread, Johannes Sixt's 'patchlet' is required to be squashed into
>> 3632cfc24, and I think Arjen was going to re-roll the patch.
>>
>> I can submit the required follow-up, but it really should have J6's S-o-b.
>
> Here it is. Disclaimer: This patch submission was hand-crafted. ;)
Sorry, my fault --- I should have noticed the missing "ifeq AIX"
anywhere in the hunk headers.
Thanks.
^ permalink raw reply
* Re: [PATCH] Use compatibility regex library also on AIX
From: Arjen Laarhoven @ 2008-09-11 8:25 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Mike Ralphson, Junio C Hamano, git
In-Reply-To: <48C8D374.9050007@viscovery.net>
On Thu, Sep 11, 2008 at 10:14:44AM +0200, Johannes Sixt wrote:
> This augments 3632cfc24 (Use compatibility regex library on Darwin,
> 2008-09-07), which already carries a "Tested-by" statement for AIX,
> but that test was actually done with this patch included.
I hadn't realized it had already gone in to 'pu'. I've put the AIX part
into my local patch, and also had it tested on HP-UX. Today I'll
probably can test it on Solaris too, and add that as well.
Arjen
--
Arjen Laarhoven
The presence of those seeking the truth is infinitely to be preferred to
those who think they've found it.
-- Terry Pratchett, "Monstrous Regiment"
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jakub Narebski @ 2008-09-11 8:20 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Linus Torvalds, git
In-Reply-To: <20080911062242.GA23070@cuci.nl>
Stephen R. van den Berg wrote:
[...]
> Please focus on the semantics and on the *non*-made up use case of
> development of several stable branches with backports between them.
> Discussing made-up use cases is wasting energy at this point.
By the way, I would really consider trying first to host 'origin' links
not in repository database itself, but in some extra database inside
git repository, like reflog or index. Git community is _very_
reluctant to modifying / extending format of persistent objects. From
all the proposals to add some extra header to a 'commit' object:
the 'prior' link to previous version of rebased, cherry-picked or redone
commit (superceded somewhat by local reflog, on by default in modern
git); the generic 'note' header, with examples of usage including
_non-linking_ cherry-pick and reverted commit-id, merge strategy used,
and hints for rename detection, i.e. something like #pragma in C
(rejected on the grounds that it was too generic and didn't have well
defined semantic); the 'generation' header which was meant to help and
speed up sorting commits, with root (parentless) commit having
generation of 1, and each commit having generation being 1 more than
maximum of generations of its parents (I think that backwards
compatibility killed it, and the fact that date-based heuristics was
improved); only the 'encoding' header was accepted.
So I think you should go the route of externally (outside 'commit'
objects) maintaing 'origin'/'changeset'/'cset' links (like XLink
extended links ;-)) as a prototype to examine consequences of the idea.
That was the way _submodule_ support was added to Git, by the way.
First there were (at least) two implementations maintaining submodules
outside object database (see http://git.or.cz/gitwiki/SubprojectSupport
especially "References" section), then it was officially added first at
the level of plumbing support, as extension of a 'tree' object (and
index format, I think).
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Use compatibility regex library also on AIX
From: Johannes Sixt @ 2008-09-11 8:14 UTC (permalink / raw)
To: Mike Ralphson, Junio C Hamano; +Cc: git, Arjen Laarhoven
In-Reply-To: <e2b179460809110059i2eca8b07x6d263f06cc8e5d32@mail.gmail.com>
This augments 3632cfc24 (Use compatibility regex library on Darwin,
2008-09-07), which already carries a "Tested-by" statement for AIX,
but that test was actually done with this patch included.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Tested-by: Mike Ralphson <mike@abacus.co.uk>
---
Mike Ralphson schrieb:
> 2008/9/10 Mike Ralphson <mike.ralphson@gmail.com>:
> Junio, sorry, I should have made this clear, but as above in the
> thread, Johannes Sixt's 'patchlet' is required to be squashed into
> 3632cfc24, and I think Arjen was going to re-roll the patch.
>
> I can submit the required follow-up, but it really should have J6's S-o-b.
Here it is. Disclaimer: This patch submission was hand-crafted. ;)
-- Hannes
diff --git a/Makefile b/Makefile
index 98d67f1..0637419 100644
--- a/Makefile
+++ b/Makefile
@@ -702,6 +702,8 @@ ifeq ($(uname_S),AIX)
INTERNAL_QSORT = UnfortunatelyYes
NEEDS_LIBICONV=YesPlease
BASIC_CFLAGS += -D_LARGE_FILES
+ COMPAT_CFLAGS += -Icompat/regex
+ COMPAT_OBJS += compat/regex/regex.o
endif
ifeq ($(uname_S),GNU)
# GNU/Hurd
^ permalink raw reply related
* Re: [RFC/PATCH] Use compatibility regex library for OSX/Darwin
From: Mike Ralphson @ 2008-09-11 7:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Arjen Laarhoven, Johannes Sixt
In-Reply-To: <e2b179460809100453r3df4ec8dh3d9bfbbd468c5676@mail.gmail.com>
2008/9/10 Mike Ralphson <mike.ralphson@gmail.com>:
> 2008/9/10 Arjen Laarhoven <arjen@yaph.org>:
>> On Wed, Sep 10, 2008 at 09:03:05AM +0100, Mike Ralphson wrote:
>>> 2008/9/7 Arjen Laarhoven <arjen@yaph.org>
>>> > The standard libc regex library on OSX does not support alternation
>>> > in POSIX Basic Regular Expression mode. This breaks the diff.funcname
>>> > functionality on OSX.
>>> >
>>> > Also, I'm sure the problem occurs on more non-Linux systems (or non
>>> > GNU libc systems). If people who have access to those systems (BSD's,
>>> > HP-UX, AIX, etc) can test it, I'd be happy to add those systems to the
>>> > patch so it can fix for multiple systems at once.
>>>
>>> I can confirm that the issue shown up by your new testcase is also
>>> present in AIX 5.3.
>
>>> Adding -lcompat/regex to COMPAT_CFLAGS as per your Darwin hunk
>>> provokes lots of warnings:
>>
>> I think your problem is a lowercase ell instead of an uppercase i ;-)
>
> Doh. I think my problem is this font! And having not used a language
> with a separate linker since last century.
>
> I guess I picked a really bad patch to try and pick up and test direct
> from gmail. No reflection on your patch, just my workflow.
>
> Having carefully checked the content of the testcase too, I can now
> say this does fix the issue without extra warnings or testcase
> failures on AIX 5.3, so for what it's worth:
>
> Tested-by: Mike Ralphson <mike@abacus.co.uk>
Junio, sorry, I should have made this clear, but as above in the
thread, Johannes Sixt's 'patchlet' is required to be squashed into
3632cfc24, and I think Arjen was going to re-roll the patch.
I can submit the required follow-up, but it really should have J6's S-o-b.
Mike
^ permalink raw reply
* Re: [RFH] git cherry-pick takes forever
From: Michal Vitecek @ 2008-09-11 7:56 UTC (permalink / raw)
To: git list; +Cc: Junio C Hamano
In-Reply-To: <7vk5dkxqvf.fsf@gitster.siamese.dyndns.org>
Hello,
Junio C Hamano wrote:
>Michal Vitecek <fuf@mageo.cz> writes:
>> I have two git repositories: one is the origin of the other. However no
>> merging is being done as the projects in the repositories quite differ
>> but still use the same core. So to propagate changes I cherry-pick
>> those which are useful from one repository to another.
>>
>> however 'git cherry-pick' has lately started to last almost forever:
>
>Can you define "lately"? Is it a function of your git version, or is it a
>function of the age of your repositories?
It's a function a cherry-picking some commits - afterwards
cherry-picking crawls. One of the commits removes a number of files
(614) and also renames some (303).
>> $ time git cherry-pick b42b77e66a83f1298d9900a9bb1078b9b42e8618
>> Finished one cherry-pick.
>> Created commit 7caef83: - removed some superfluous newlines
>> 2 files changed, 0 insertions(+), 2 deletions(-)
>> git cherry-pick b42b77e66a83f1298d9900a9bb1078b9b42e8618 282.97s user 34.69s system 100% cpu 5:17.63 total
>>
>> Both repositories have approximately 16k commits and their forking
>> point (merge base) is 250 to 490 commits far away.
>
>When talking about cherry-pick, the size of the history (unless the
>repository has too many objects and badly packed) does not matter; the
>operation is purely about your current state, the cherry-picked commit
>itself, and the parent commit of the cherry-picked one.
I too thought so but after cherry-picking starting taking so long I
began to doubt my thoughts :)
>Taking 5 minutes to cherry-pick a change to only two paths, one line
>deletion each, is plain ridiculous, but if the tree state of cherry-picked
>commit and the tree state of the target is vastly different (e.g. almost
>no common pathnames), the behaviour is certainly understandable. Ancient
>git used straight three-way merge for cherry-pick, but recent ones use
>more expensive "recursive-merge", which tries to detect renames. If the
>states of trees are very dissimilar, you can end up wasting a lot of time.
>
> $ H=$(git rev-parse 7caef83^) ;# the commit before cherry-pick
> $ C=b42b77e6 ;# the cherry-picked one
>
>cherry-pick operation roughly runs these two diffs:
>
> $ time git diff --shortstat -M $H $C
$ time git diff --shortstat -M $H $C
2 files changed, 0 insertions(+), 2 deletions(-)
git diff --shortstat -M $H $C 0.00s user 0.00s system 72% cpu 0.006 total
> $ time git diff --shortstat -M $H $C^1
$ time git diff --shortstat -M $H $C\^1
git diff --shortstat -M $H $C\^1 0.00s user 0.00s system 0% cpu 0.003 total
>and uses the result to perform its work. Can you clock these?
>
>If you rarely have renames, it may be much more efficient to run "git
>format-patch -1 --stdout $C | git am -3" instead of cherry-pick.
Turning off renames detection in diff (via 'git config --add diff.renames
false') helped and 'git cherry-pick' is instant now.
Maybe my repositories are "strange" in some way. I would be more than
happy to provide more information if needed.
Thank you,
--
Michal Vitecek (fuf@mageo.cz)
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 7:55 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Jeff King, Theodore Tso, Petr Baudis, git
In-Reply-To: <48C8A9A4.7030906@gnu.org>
Paolo Bonzini wrote:
>> Being able to subvert the authenticity of git blame by providing fake
>> origin information is not very appealing.
>You could use a dummy submodule to ensure that each commit pointed to
>the right set of notes. It would force to create a separate commit
>whenever you modified the notes, which is actually not bad.
Possibly, yes. But we'd have to be careful not to incur too much
overhead because every indirection will cost, especially since the
origin link sometimes is checked for on every commit during a treewalk.
The fact that it rarely exists means that it should be fast to find out
that there are no origin links (which obviously is the common case).
>Alternatively, the header of the commit can be modified to add a pointer
>to a tree object for the notes; I suppose this is more palatable than
>the origin link.
This won't work for the original notes concept, because it makes the
notes immutable after commit. For the origin links this would be fine,
since they don't change once committed.
The problem with fitting the origin links in the notes is twofold:
- They become mutable, which is undesirable, I'd like to preserve
history as is (just like parent links).
- There is a performance hit, since origin links need to be found not to
exist on every commit (sometimes, depending on the operation of course).
> The tree could be organized in directories+blobs like
>..git/objects to speed up the lookup.
Yes, that was already in the latest proposal for notes, I believe.
>I actually like the commit notes idea, but then I wonder: why are the
>author and committer part of the commit object? How does the plumbing
>use them? Isn't that metadata that could live in the "notes"? And so,
It would fit with a non-mutable version of the notes. Then again, we
already *have* the non-mutable version of the notes, it's called the
header of the commit message.
>why should the origin link have less privileges?
They both belong in the non-mutable notes, and those happen to live in
the header of the commit (which *is* the most efficient spot, of course).
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ 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