* Re: Unable to checkout a particular SVN revision
From: Daniele Segato @ 2009-11-29 16:50 UTC (permalink / raw)
To: Marc Liyanage; +Cc: git
In-Reply-To: <718EEBA2-FA4B-402D-B2FC-A8F14D79F6FF@entropy.ch>
Il giorno ven, 27/11/2009 alle 18.05 -0800, Marc Liyanage ha scritto:
> I'm trying to clone a specific SVN revision with git-svn:
>
> git svn clone -r 12345 https://host/svn/foo/branches/bar xyz
>
> but it doesn't check out any files, I see just this:
>
> Initialized empty Git repository in /Users/liyanage/Desktop/xyz/.git
>
> If I try the same thing with SVN like this:
>
> svn co -r 12345 https://host/svn/foo/branches/bar xyz
>
> then I get what I expect, it checks out all the files and "svn info" gives me this revision.
>
>
> I think it's because this particular revision wasn't committed on this branch, i.e. it doesn't show up in "svn log". If I try a revision that is listed in the log, it works as expected.
>
>
> Is there a way to make this work?
You had to understand the difference between a distributed version
control system (git) and a centralized version control system (svn).
On SVN there is a central repository and all user checkout a SINGLE
revision at a time, if they want to switch to another revision/branch
they had to update the local files communicating with the central
repository (can't work offline)
On Git you clone the ENTIRE history of a repository and you keep it
(all) locally. If you want to switch to another "revision" or branch you
can do it locally without interacting over network with a remote
repository, if you want to commit you can do it locally and the first
time you got connected to the network you can push your change to the
remote repository and pull others changes.
Git-SVN is a tool that allow you to interact with an SVN repository
using Git as client: the cool thing is that you get a lot of the
features of a distributed repository even if you are interacting with a
centralized one.
The bad news is that cloning the first time is really really slow: this
is because SVN has not been wrote to support distributed repository and
is not optimized to allow cloning of all the history.
to made thinks clearer:
SVN:
svn checkout -r <revision> <url> # this connect to <url> and download
that revision locally
GIT:
git svn clone <url> -T trunk -t tags -b branches # this connect to <url>
and start from revision 1 to the last cloning all the repository
(supposing you have a standard SVN structure with trunk/tags/branches)
this could keep a lot of time if it is a big repository (even days)
but when it is done you can checkout any revision:
git checkout <your-revision-commit>
git doesn't store the history as SVN do, revision numbers does NOT make
sense in a distributed environment... it just keep revision numbars
inside commits comments.. so you'll first had to search your revision
number into the git log history and then checkout the corresponding
commit.
Git is NOT another SVN client, is a completely different way of doing
versioning and you had to understand this and stop trying to use git as
you use svn until now
^ permalink raw reply
* Re: What is the best way to backport a feature?
From: Pascal Obry @ 2009-11-29 16:49 UTC (permalink / raw)
To: Peter Weseloh; +Cc: git
In-Reply-To: <loom.20091129T164518-669@post.gmane.org>
Le 29/11/2009 17:28, Peter Weseloh a écrit :
> Hi,
>
> Suppose I have the following situation:
>
> o--o--o Release_1.0
> / \ \
> o-o-o--o--o-o-o-o-o-o---o--o Mainline
> \ \ \ /
> F1--F2--M1--F3--M2 Feature_A
>
> Now I want to backport "Feature_A" to the "Release_1.0" branch so that it gets
> included into the next minor release, i.e. I want to apply the commits F1, F2
> and F3 onto the "Release_1.0" branch.
> I cannot just merge "Feature_A" into "Release_1.0" because that would also bring
> in the merges M1 and M2 so a lot of other stuff from the Mainline.
>
> I played with cherry-pick but that means I have to manually find the commits F1,
> F2 and F3 (which in reality could be many more if Feature_A is big) which is not
> very nice.
>
> I also tried 'rebase -i' but that means I have to manually delete all the lines
> for changesets from the mainline. Also not very nice.
>
> Is there a better way? To me this scenario sounds not unusual but I could not
> find a solution.
In such a case I would use a rebase onto:
$ git co Feature_A
$ git rebase --onto Release_1.0 F1 F3
Then
$ git co Release_1.0
$ git merge Feature_A
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: What is the best way to backport a feature?
From: Björn Steinbrink @ 2009-11-29 16:47 UTC (permalink / raw)
To: Peter Weseloh; +Cc: git
In-Reply-To: <loom.20091129T164518-669@post.gmane.org>
On 2009.11.29 16:28:17 +0000, Peter Weseloh wrote:
> Suppose I have the following situation:
>
> o--o--o Release_1.0
> / \ \
> o-o-o--o--o-o-o-o-o-o---o--o Mainline
> \ \ \ /
> F1--F2--M1--F3--M2 Feature_A
>
> Now I want to backport "Feature_A" to the "Release_1.0" branch so that
> it gets included into the next minor release, i.e. I want to apply the
> commits F1, F2 and F3 onto the "Release_1.0" branch.
> Is there a better way? To me this scenario sounds not unusual but I
> could not find a solution.
What's unusual there is that you merged from Mainline to Feature_A.
Usually, the history would look like this:
o--o--o Release_1.0
/ \ \
o-o-o--o--o-o-o-o-o-o---o--o Mainline
\ /
F1-----F2------F3 Feature_A
And then you could easily use rebase to get the job done.
Had you known beforehand that Feature_A is a candidate for backporting,
you would have even branch from an older commit like this:
o--o--o Release_1.0
/ \ \
o-o-o--o--o-o-o-o-o-o---o--o Mainline
\ /
F1--------F2-------F3 Feature_A
Then you could easily merge Feature_A to Release_1.0 as well, without
merging anything unrelated.
But that's just for the future...
Given you current history, you could use format-patch + am like this:
git format-patch --stdout --first-parent Mainline..Feature_A > fa.mbox
git checkout Release_1.0
git am -3 fa.mbox
The --first-parent options make it follow the first parent of the merge
commits only, so the whole stuff on the Mainline branch is ignored. And
you just get F1, F2 and F3 in fa.mbox, which you then apply using am.
A long time ago, I hacked the --first-parent thing into rebase, but (of
course) the first iteration of the patch wasn't quite perfect and as
I've not been scratching my own itch there, I never got around to
actually polish the patch so it could get into git.git. Maybe you want
to pick it up?
http://thread.gmane.org/gmane.comp.version-control.git/62782
Björn
^ permalink raw reply
* Re: does clone --depth work?
From: Björn Steinbrink @ 2009-11-29 16:32 UTC (permalink / raw)
To: Dan Carpenter; +Cc: git
In-Reply-To: <20091129160352.GO10640@bicker>
On 2009.11.29 18:03:52 +0200, Dan Carpenter wrote:
> I do: `git clone --depth 0 ./repo1/ repo2` I expected that
> "git log" in repo2 wouldn't show any revisions, but it does.
>
> I'm using 1.6.5.3.171.ge36e.dirty (small unrelated modification).
>
> Am I doing something incorrectly?
Two problems:
a) IIRC depth = 0 is like not specifying depth at all
b) When using plain paths, clone optimizes the process by just doing a
copy, that doesn't apply the depth setting at all
git clone --depth=1 file://$PWD/repo1 repo2
That should work. Of course you still got some commits, so "git log"
will show them. You just don't get all of them, but only to a certain
depth.
Björn
^ permalink raw reply
* What is the best way to backport a feature?
From: Peter Weseloh @ 2009-11-29 16:28 UTC (permalink / raw)
To: git
Hi,
Suppose I have the following situation:
o--o--o Release_1.0
/ \ \
o-o-o--o--o-o-o-o-o-o---o--o Mainline
\ \ \ /
F1--F2--M1--F3--M2 Feature_A
Now I want to backport "Feature_A" to the "Release_1.0" branch so that it gets
included into the next minor release, i.e. I want to apply the commits F1, F2
and F3 onto the "Release_1.0" branch.
I cannot just merge "Feature_A" into "Release_1.0" because that would also bring
in the merges M1 and M2 so a lot of other stuff from the Mainline.
I played with cherry-pick but that means I have to manually find the commits F1,
F2 and F3 (which in reality could be many more if Feature_A is big) which is not
very nice.
I also tried 'rebase -i' but that means I have to manually delete all the lines
for changesets from the mainline. Also not very nice.
Is there a better way? To me this scenario sounds not unusual but I could not
find a solution.
Thanks,
Peter
^ permalink raw reply
* does clone --depth work?
From: Dan Carpenter @ 2009-11-29 16:03 UTC (permalink / raw)
To: git
I do: `git clone --depth 0 ./repo1/ repo2` I expected that
"git log" in repo2 wouldn't show any revisions, but it does.
I'm using 1.6.5.3.171.ge36e.dirty (small unrelated modification).
Am I doing something incorrectly?
regards,
dan carpenter
^ permalink raw reply
* Re: [RFC/PATCH] t7011: Mark fixed test as such
From: Michael J Gruber @ 2009-11-29 13:57 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <fcaeb9bf0911290047t43ea3040x730e04baa81d8a98@mail.gmail.com>
Nguyen Thai Ngoc Duy venit, vidit, dixit 29.11.2009 09:47:
> On 11/29/09, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>> Test 16/17 had been fixed since its introduction in b4d1690 (Teach Git
>> to respect skip-worktree bit (reading part), 2009-08-20). So, mark it as
>> expect_success rather than expect_failure.
>>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>
> No ACK. See below.
>
>> ---
>> I'm actually wondering about 17/17 as well.
>> If commit is called with a file name then shouldn't it simply commit the
>> current state of the file in the worktree, no matter what the index or
>> skip-worktree say? I therefore think 17/17 should be expect_success
>> and have no test_must_fail.
>
> Both 16/17 and 17/17 ensure that Git won't look at files on worktree
> if they are marked as skip-worktree (by definition of skip-worktree,
> you can safely ignore worktree, otherwise you would not mark them as
> such). 16/17 happens to pass, not because it does not touch worktree,
> but because the base index does not have "1", which happens to is the
> same situation in 16/17 (test commit when "1" is gone). The result is
> OK but it is actually not (17/17 shows this clearer as it commits the
> worktree version).
On 16/17, I really cannot agree. You explain that you expect the test to
succeed (we agree here), but that it succeeds for the wrong reasons. So
it should be either "expect_success", or the test itself should be
changed so that it really tests what it intends to, otherwise it raises
a wrong "FIXED". I suggested and submitted the former.
On 17/17, it's not clear what should happen. "skip-worktree" says ignore
the worktree and look in the index instead of accessing worktree files.
But "git commit file" says ignore the index and stage and commit the
file from the worktree directly. And that is exactly what happens:
You say "git commit file".
That means "ignore the index".
That also means that git ignores the skip-worktree bit which is set in
the index.
Therefore, file is committed with the content is has in the worktree.
I'm going by the documentation for git-update-index and git-commit. It
could be that they are wrong, too, but they agree with the code, so
what's the reference for saying both code and documentation are wrong?
Michael
^ permalink raw reply
* [PATCH 1/2] merge-recursive: make the error-message generation an extern function
From: Matthieu Moy @ 2009-11-29 12:18 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <1259497113-1393-1-git-send-email-Matthieu.Moy@imag.fr>
The construction of the struct unpack_trees_error_msgs was done within
git_merge_trees(), which prevented using the same messages easily from
another function.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
merge-recursive.c | 41 +++++++++++++++++++++++------------------
merge-recursive.h | 3 +++
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index a91208f..70cd6cc 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -172,23 +172,6 @@ static int git_merge_trees(int index_only,
int rc;
struct tree_desc t[3];
struct unpack_trees_options opts;
- struct unpack_trees_error_msgs msgs = {
- /* would_overwrite */
- "Your local changes to '%s' would be overwritten by merge. Aborting.",
- /* not_uptodate_file */
- "Your local changes to '%s' would be overwritten by merge. Aborting.",
- /* not_uptodate_dir */
- "Updating '%s' would lose untracked files in it. Aborting.",
- /* would_lose_untracked */
- "Untracked working tree file '%s' would be %s by merge. Aborting",
- /* bind_overlap -- will not happen here */
- NULL,
- };
- if (advice_commit_before_merge) {
- msgs.would_overwrite = msgs.not_uptodate_file =
- "Your local changes to '%s' would be overwritten by merge. Aborting.\n"
- "Please, commit your changes or stash them before you can merge.";
- }
memset(&opts, 0, sizeof(opts));
if (index_only)
@@ -200,7 +183,7 @@ static int git_merge_trees(int index_only,
opts.fn = threeway_merge;
opts.src_index = &the_index;
opts.dst_index = &the_index;
- opts.msgs = msgs;
+ opts.msgs = get_porcelain_error_msgs();
init_tree_desc_from_tree(t+0, common);
init_tree_desc_from_tree(t+1, head);
@@ -1188,6 +1171,28 @@ static int process_entry(struct merge_options *o,
return clean_merge;
}
+struct unpack_trees_error_msgs get_porcelain_error_msgs()
+{
+ struct unpack_trees_error_msgs msgs = {
+ /* would_overwrite */
+ "Your local changes to '%s' would be overwritten by merge. Aborting.",
+ /* not_uptodate_file */
+ "Your local changes to '%s' would be overwritten by merge. Aborting.",
+ /* not_uptodate_dir */
+ "Updating '%s' would lose untracked files in it. Aborting.",
+ /* would_lose_untracked */
+ "Untracked working tree file '%s' would be %s by merge. Aborting",
+ /* bind_overlap -- will not happen here */
+ NULL,
+ };
+ if (advice_commit_before_merge) {
+ msgs.would_overwrite = msgs.not_uptodate_file =
+ "Your local changes to '%s' would be overwritten by merge. Aborting.\n"
+ "Please, commit your changes or stash them before you can merge.";
+ }
+ return msgs;
+}
+
int merge_trees(struct merge_options *o,
struct tree *head,
struct tree *merge,
diff --git a/merge-recursive.h b/merge-recursive.h
index fd138ca..f4b7f57 100644
--- a/merge-recursive.h
+++ b/merge-recursive.h
@@ -17,6 +17,9 @@ struct merge_options {
struct string_list current_directory_set;
};
+/* Return a list of user-friendly error messages to be used by merge */
+struct unpack_trees_error_msgs get_porcelain_error_msgs();
+
/* merge_trees() but with recursive ancestor consolidation */
int merge_recursive(struct merge_options *o,
struct commit *h1,
--
1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply related
* [RFC/PATCH 2/2] builtin-merge: show user-friendly error messages for fast-forward too.
From: Matthieu Moy @ 2009-11-29 12:18 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <1259497113-1393-1-git-send-email-Matthieu.Moy@imag.fr>
fadd069d03 (merge-recursive: give less scary messages when merge did not
start, Sep 7 2009) introduced some friendlier error message for merge
failure, but the messages were shown only for non-fast forward merges.
This patch uses the same for fast-forward.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
This is where I'm not 100% sure I'm not breaking some plumbing.
builtin-merge.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index 57eedd4..0dd363f 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -656,6 +656,7 @@ static int checkout_fast_forward(unsigned char *head, unsigned char *remote)
opts.verbose_update = 1;
opts.merge = 1;
opts.fn = twoway_merge;
+ opts.msgs = get_porcelain_error_msgs();
trees[nr_trees] = parse_tree_indirect(head);
if (!trees[nr_trees++])
--
1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply related
* [PATCH 0/2] User-friendly error messages for merge failure on fast-forward.
From: Matthieu Moy @ 2009-11-29 12:18 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
I noticed that failures of fast-forward merges were still using the
plumbing error message:
$ git merge master
Updating 1fdeef9..e248dad
error: Entry 'foo.txt' not uptodate. Cannot merge.
I'm not 100% sure that my patch doesn't trigger the porcelain behavior
for plumbing. Someone more familiar than me with the codebase should
confirm/infirm this.
Matthieu Moy (2):
merge-recursive: make the error-message generation an extern function
builtin-merge: show user-friendly error messages for fast-forward
too.
builtin-merge.c | 1 +
merge-recursive.c | 41 +++++++++++++++++++++++------------------
merge-recursive.h | 3 +++
3 files changed, 27 insertions(+), 18 deletions(-)
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Felipe Contreras @ 2009-11-29 12:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, James Pickens, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0911272102430.4521@intel-tinevez-2-302>
On Fri, Nov 27, 2009 at 10:07 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Fri, 27 Nov 2009, Jeff King wrote:
>> Yes, as a matter of fact, I do work on 10 different computers. I'm sorry
>> that you find managing your configuration so challenging. But if you
>> don't use the configuration variable, then your own personal setup is
>> totally irrelevant.
>
> As I just demonstrated, this is a false statement.
Yes, defaults are important in UI.
>> If your argument is that this lack of consistency will irritate users,
>> you need to show that:
>>
>> 1. There are users who switch between a large number of setups, but
>> will not apply config consistently.
>
> This is a strawman, and you should be ashamed to put it here. Just
> because nobody does what you actively encourage does not mean that the
> encouraged procedure is good, or for that matter, helps anybody but you.
Not to mention that it's completely irrelevant. The fact that all
users apply their configurations consistently through their setups, or
not, doesn't make a default preference better or worst.
If the argument is that default preferences are not relevant enough,
then step aside and let the people that care about default preferences
to discuss.
>> And the GitTogether had a "users complain about git, and we try to
>> listen" session.
>
> Oh, that makes me so happy. <sarcasm>Soooo happy</sarcasm>. So it was an
> ivory tower meeting, once again?
This is very typical on many open source projects. I think the
benevolent dictator model works pretty good on low-level stuff, but on
UI I think a democratic model works better.
I've been thinking on setting up a pseudo-project on SourceForge and
setup an IdeaTorrent, that way users can generate and organize ideas
so that developers can have meaningful conversations with users:
http://brainstorm.ubuntu.com/
What do you think?
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Felipe Contreras @ 2009-11-29 11:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Uri Okrent, Johannes Schindelin, Jeff King, James Pickens, git
In-Reply-To: <7vk4xbn7nl.fsf@alter.siamese.dyndns.org>
On Fri, Nov 27, 2009 at 8:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> That is exactly how we work and what people have been working hard for
> 1.7.0. Check the planned changes listed in the recent (and not so recent)
> "What's cooking" summary reports.
>
> Changing "grep" is too late for 1.7.0, but we are trying to find an easy
> migration path like you mentioned in your message and that is exactly what
> this thread is about.
How about this. For now, make --full-tree available, and that's it.
Then, on 1.8.0, add the configuration option, and if there's consensus
make it default (-1 from me).
However, in order to ease the transition I think Jeff's GIT_PLUMBING
(I would call it GIT_SCRIPTING) should be introduced on 1.7.0 so
people can start exporting it in their scripts. That way people don't
have to worry about adding --(no-)full-tree on their scripts (nor any
other argument that depends on configurations) and when 1.8.0 comes,
there's no script breakage.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Felipe Contreras @ 2009-11-29 11:38 UTC (permalink / raw)
To: Jeff King; +Cc: A Large Angry SCM, Junio C Hamano, git
In-Reply-To: <20091125232210.GA15538@coredump.intra.peff.net>
On Thu, Nov 26, 2009 at 1:22 AM, Jeff King <peff@peff.net> wrote:
> Probably we would want something flexible, but with sane defaults. Like
> an environment variable to ignore all (or most) config options, but then
> the ability to opt into specific ones. Something like:
>
> GIT_PLUMBING=1; export GIT_PLUMBING
> git log ;# does not respect any non-plumbing config
> git --respect='log.showroot' ;# respect just the one variable
> git --respect='color.*' log ;# you get all color
>
> But there are two big obstacles (besides the obvious issue that
> introducing this in itself needs a gentle transition plan):
>
> 1. We need to annotate every config option with whether it is
> potentially problematic. For example, core.filemode should probably
> be respected no matter what (but I'm not sure if it is simply true
> for core.*).
>
> 2. Script writers need to actually use the system, which is somewhat
> more verbose and annoying than what they have to do now. But at
> least it defaults to safety when they are lazy, and then they can
> re-add options. Of course, they are stuck on an upgrade treadmill
> of analyzing and approving each new option that appears in git.
+1 on this.
This would make it easier to add options in the future that would be
potentially dangerous to scripts otherwise. But more than
"non-plumbing" I would rather define these variables as *preferences*;
things that are not essential to the proper functioning of git
commands, and would vary from user to user.
--
Felipe Contreras
^ permalink raw reply
* Re: [spf:guess] Re: git-svn: SVK merge commits can have >2 parents
From: Sam Vilain @ 2009-11-29 11:26 UTC (permalink / raw)
To: Eric Wong; +Cc: Alex Vandiver, git
In-Reply-To: <20091129080815.GC24222@dcvr.yhbt.net>
On Sun, 2009-11-29 at 08:08 +0000, Eric Wong wrote:
> Alex Vandiver <alex@chmrr.net> wrote:
> > At Sun Nov 29 02:28:39 -0500 2009, Alex Vandiver wrote:
> > > While converting a mildly complicated svn repository that was managed
> > > with SVK, I ran across the following oddness. `svk smerge` can only
> > > merge between _two_ branches at once -- however, the way that svk
> > > merge detection works, you can end up with erroneous extra parents
> > > from long-dead branches.
> >
> > Upon a little more inspection, I now understand that the rev-parse
> > lines in find_extra_svk_parents are attempting to deal with this exact
> > circumstance -- but they fail to properly sort the merge tickets
> > first, which leads to this incorrect behavior. Armed with this
> > understanding, I'm more confident in the attached updated patch. I
>
> Hi Alex, Sam,
>
> I'll defer to Sam for the Ack, my svk knowledge is limited. Thanks.
Yes, the change does make sense to me - nicely done, Alex.
Acked-By: Sam Vilain <sam@vilain.net>
Sam
^ permalink raw reply
* [PATCH] reset: add --quiet option
From: Felipe Contreras @ 2009-11-29 10:58 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
There's already -q, but --quiet is missing.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/git-reset.txt | 1 +
builtin-reset.c | 2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 2d27e40..9df6de2 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -62,6 +62,7 @@ This means that `git reset -p` is the opposite of `git add -p` (see
linkgit:git-add[1]).
-q::
+--quiet::
Be quiet, only report errors.
<commit>::
diff --git a/builtin-reset.c b/builtin-reset.c
index 73e6022..c0127c4 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -209,7 +209,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
"reset HEAD, index and working tree", HARD),
OPT_SET_INT(0, "merge", &reset_type,
"reset HEAD, index and working tree", MERGE),
- OPT_BOOLEAN('q', NULL, &quiet,
+ OPT_BOOLEAN('q', "quiet", &quiet,
"disable showing new HEAD in hard reset and progress message"),
OPT_BOOLEAN('p', "patch", &patch_mode, "select hunks interactively"),
OPT_END()
--
1.6.6.rc0.63.g0471c
^ permalink raw reply related
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-29 10:28 UTC (permalink / raw)
To: Jeff King; +Cc: James Pickens, Junio C Hamano, git
In-Reply-To: <20091127210530.GC26921@coredump.intra.peff.net>
Hi,
On Fri, 27 Nov 2009, Jeff King wrote:
> On Fri, Nov 27, 2009 at 09:07:51PM +0100, Johannes Schindelin wrote:
>
> > > Yes, as a matter of fact, I do work on 10 different computers. I'm sorry
> > > that you find managing your configuration so challenging. But if you
> > > don't use the configuration variable, then your own personal setup is
> > > totally irrelevant.
> >
> > As I just demonstrated, this is a false statement.
>
> I must have missed where you demonstrated it.
Usually, my mails are minimal, and I do not write as many mails as I
used to anymore, so it is hard to miss what I am saying.
For your benefit: both Junio and me talked about experts helping users.
Even if I do not use the config options, I am affected. And it does hurt.
> > > If your argument is that this lack of consistency will irritate users,
> > > you need to show that:
> > >
> > > 1. There are users who switch between a large number of setups, but
> > > will not apply config consistently.
> >
> > This is a strawman, and you should be ashamed to put it here. Just
>
> How is this a strawman?
You are comparing config settings which must be different, because they
affect _what_ project you are working with, with config settings that
affect _how_ you can work with them.
> When the number of "git grep" crash fatalities rises above zero, maybe
> this line of reasoning will be relevant.
Sure. Let's wait for the first crash fatality, and only react then. No
need to think ahead.
That's it. I don't think that I want to participate in this kind of
discussion anymore,
Dscho
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-29 10:21 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, James Pickens, git
In-Reply-To: <20091127205004.GA26921@coredump.intra.peff.net>
Hi,
On Fri, 27 Nov 2009, Jeff King wrote:
> On Fri, Nov 27, 2009 at 10:29:11AM -0800, Junio C Hamano wrote:
>
> > > If only somebody had written a "pager.status" configuration variable,
> > > you could use that. Oh wait. I did. And it shipped in v1.6.0.
> >
> > Nice try but, "grep" and "status" are apples and oranges comparision.
>
> Yes, I think you are right that the existence of pager.* does not
> necessarily imply that there should be a config option for grep. But
> that makes his example even more irrelevant: he is advocating that I use
> a solution in this instance because he uses it in another instance, when
> that solution is not even necessary in the other instance (and as I have
> hopefully already made clear, is in my opinion inferior).
Sorry, no, you got it all wrong.
My point was that your config option introduced something _BAD_. And my
point was that now, as a consequence of having managed to put it into Git,
you want more of such bad stuff.
You continue to ignore that inconsistency -- even if it is introduced with
the best of all intentions -- is bad, bad, bad.
But I guess that I continue to get ignored,
Dscho
^ permalink raw reply
* What's cooking in git.git (Nov 2009, #07; Sun, 29)
From: Junio C Hamano @ 2009-11-29 10:05 UTC (permalink / raw)
To: git
This will be the last update before deciding what should go in 1.6.6-rc1
and describes my current thinking.
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planned changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* "git send-email" won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* "git status" won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
* "git diff -w/-b" won't even produce "diff --git" header when all changes
are about whitespaces.
http://thread.gmane.org/gmane.comp.version-control.git/133256
--------------------------------------------------
[New Topics]
* fc/maint-format-patch-pathspec-dashes (2009-11-26) 2 commits.
- format-patch: add test for parsing of "--"
- format-patch: fix parsing of "--" on the command line
* bw/diff-color-hunk-header (2009-11-27) 2 commits
(merged to 'next' on 2009-11-29 at c446977)
+ Give the hunk comment its own color
(merged to 'next' on 2009-11-27 at 42ab131)
+ emit_line(): don't emit an empty <SET><RESET> followed by a newline
* jc/maint-am-keep (2009-11-27) 1 commit.
(merged to 'next' on 2009-11-27 at 7663874)
+ Remove dead code from "git am"
* tr/http-updates (2009-11-27) 2 commits
- Add an option for using any HTTP authentication scheme, not only basic
- http: maintain curl sessions
* jc/diff-whitespace-prepare (2009-11-28) 2 commits
- diff: flip the default diff.bwoutputonly to true
- diff: optionally allow traditional "-b/-w affects only output" semantics
(this branch uses gb/1.7.0-diff-whitespace-only-output and jc/1.7.0-diff-whitespace-only-status; is used by jc/1.7.0-diff-whitespace-prepare.)
This is to redo the two -b/-w semantic changes to prepare the migration of
existing users before 1.7.0 happens.
* jc/1.7.0-diff-whitespace-prepare (2009-11-28) 2 commits
- diff: disable diff.bwoutputonly warning
- diff: flip the diff.bwoutputonly default to false
(this branch uses gb/1.7.0-diff-whitespace-only-output, jc/1.7.0-diff-whitespace-only-status and jc/diff-whitespace-prepare.)
And this is to actually flip the default and eventually remove the warning.
* ns/send-email-no-chain-reply-to (2009-11-29) 1 commit
- prepare send-email for smoother change of --chain-reply-to default
(this branch is used by ns/1.7.0-send-email-no-chain-reply-to.)
Similarly, this is to start warning about the change to --no-chain-reply-to
in 1.7.0 for smoother transition.
* ns/1.7.0-send-email-no-chain-reply-to (2009-08-22) 1 commit
- send-email: make --no-chain-reply-to the default
(this branch uses ns/send-email-no-chain-reply-to.)
And this is to actually flip the default in 1.7.0.
--------------------------------------------------
[Stalled]
* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* jn/rfc-pull-rebase-error-message (2009-11-12) 1 commit
- git-pull.sh --rebase: overhaul error handling when no candidates are found
I heard this needs at least retitling among other changes?
* jh/notes (2009-11-20) 10 commits
- Add more testcases to test fast-import of notes
- Rename t9301 to t9350, to make room for more fast-import tests
- fast-import: Proper notes tree manipulation using the notes API
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
Johan waits for an Ack from Shawn on "fast-import" one.
* tr/maint-merge-ours-clarification (2009-11-15) 1 commit
(merged to 'next' on 2009-11-21 at fadaf7b)
+ rebase: refuse to rebase with -s ours
I do not think we reached a concensus for solving conflicts between "give
them rope" and "protect users from clearly meaningless combinations". The
author obviously is for the latter (and I am inclined to agree); Dscho
seems to think otherwise.
* jc/fix-tree-walk (2009-10-22) 8 commits
(merged to 'next' on 2009-10-22 at 10c0c8f)
+ Revert failed attempt since 353c5ee
+ read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
This has some stupid bugs and reverted from 'next' until I can fix it, but
the "temporarily" turned out to be very loooong. Sigh...
* sr/gfi-options (2009-09-06) 6 commits.
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
Sverre is working on a re-roll to address comments from Shawn.
--------------------------------------------------
[Cooking]
* sr/vcs-helper (2009-11-18) 12 commits
(merged to 'next' on 2009-11-27 at 83268ab)
+ Add Python support library for remote helpers
+ Basic build infrastructure for Python scripts
+ Allow helpers to report in "list" command that the ref is unchanged
+ Fix various memory leaks in transport-helper.c
+ Allow helper to map private ref names into normal names
+ Add support for "import" helper command
+ Allow specifying the remote helper in the url
+ Add a config option for remotes to specify a foreign vcs
+ Allow fetch to modify refs
+ Use a function to determine whether a remote is valid
+ Allow programs to not depend on remotes having urls
+ Fix memory leak in helper method for disconnect
* jc/grep-full-tree (2009-11-24) 1 commit.
- grep: --full-tree
The interaction with this option and pathspecs need to be worked out
better. I _think_ "grep --full-tree -e pattern -- '*.h'" should find from
all the header files in the tree, for example.
* uk/maint-shortlog-encoding (2009-11-25) 1 commit.
- shortlog: respect commit encoding
The fix is a maint material but the patch was against next, so I
back-rebased it myself. I tried to be careful but please double check the
result.
Perhaps merge it to 'master' before 1.6.6-rc1?
* fc/send-email-envelope (2009-11-26) 2 commits.
(merged to 'next' on 2009-11-27 at 2d0257d)
+ send-email: automatic envelope sender
+ t9001: test --envelope-sender option of send-email
Perhaps merge it to 'master' before 1.6.6-rc1?
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
(merged to 'next' on 2009-11-25 at 09d498f)
+ mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Jim Meyering sent a patch to do a subset of what this does; to allow
keeping '[SECURITY]' when the subject says '[SECURITY][PATCH]', you need
to also teach "am" to pass the new -b option, but that is independent of
what Jim showed the need in real-world, so I think this can go in as-is.
Perhaps merge it to 'master' before 1.6.6-rc1?
* jc/checkout-merge-base (2009-11-20) 2 commits
- "rebase --onto A...B" replays history on the merge base between A and B
- "checkout A...B" switches to the merge base between A and B
I've been using the first one for a while myself but do not see many users
want this (yet); the new feature is not urgent anyway.
* tr/reset-checkout-patch (2009-11-19) 1 commit.
(merged to 'next' on 2009-11-22 at b224950)
+ {checkout,reset} -p: make patch direction configurable
I do not particularly like a configuration like this that changes the
behaviour of a command in a drastic way---it will make helping others much
harder.
Perhaps merge it to 'master' before 1.6.6-rc1?
* jn/gitweb-blame (2009-11-24) 8 commits.
(merged to 'next' on 2009-11-25 at 0a5b649)
+ gitweb.js: fix padLeftStr() and its usage
+ gitweb.js: Harden setting blamed commit info in incremental blame
+ gitweb.js: fix null object exception in initials calculation
+ gitweb: Minify gitweb.js if JSMIN is defined
+ gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-10-11 at 73c4a83)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame, with further fixes. As this does not seem to break existing
features, I am inclined to say that we push this out early, as a new
feature with known breakages, to give it wider audience.
* em/commit-claim (2009-11-04) 1 commit
(merged to 'next' on 2009-11-23 at b5df6fd)
+ commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author
I am not sure if the option name does a good job at explaining it to the
end users, but I think the code and feature is solid.
Perhaps merge it to 'master' before 1.6.6-rc1?
* cc/bisect-doc (2009-11-08) 1 commit
(merged to 'next' on 2009-11-27 at c46d648)
+ Documentation: add "Fighting regressions with git bisect" article
Perhaps merge it to 'master' before 1.6.6-rc1?
* nd/sparse (2009-11-25) 20 commits.
(merged to 'next' on 2009-11-25 at 71380f5)
+ tests: rename duplicate t1009
(merged to 'next' on 2009-11-23 at f712a41)
+ sparse checkout: inhibit empty worktree
+ Add tests for sparse checkout
+ read-tree: add --no-sparse-checkout to disable sparse checkout support
+ unpack-trees(): ignore worktree check outside checkout area
+ unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
+ unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
+ unpack-trees.c: generalize verify_* functions
+ unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
+ Introduce "sparse checkout"
+ dir.c: export excluded_1() and add_excludes_from_file_1()
+ excluded_1(): support exclude files in index
+ unpack-trees(): carry skip-worktree bit over in merged_entry()
+ Read .gitignore from index if it is skip-worktree
+ Avoid writing to buffer in add_excludes_from_file_1()
+ Teach Git to respect skip-worktree bit (writing part)
+ Teach Git to respect skip-worktree bit (reading part)
+ Introduce "skip-worktree" bit in index, teach Git to get/set this bit
+ Add test-index-version
+ update-index: refactor mark_valid() in preparation for new options
* jc/pretty-lf (2009-10-04) 1 commit.
(merged to 'next' on 2009-11-27 at 73651c4)
+ Pretty-format: %[+-]x to tweak inter-item newlines
Perhaps merge it to 'master' before 1.6.6-rc1?
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-11-27) 7 commits.
(merged to 'next' on 2009-11-27 at 91691ec)
+ t7508-status.sh: Add tests for status -s
+ status -s: respect the status.relativePaths option
(merged to 'next' on 2009-11-21 at 884bb56)
+ docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
Immediately after 1.6.6 while rebuilding 'next', we may want to reorder a
few commits at the tip, as "docs: affects only long format" describes a
limitation that will disappear soon.
* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change,
and jc/diff-whitespace-prepare topic is meant to ease the transition.
* gb/1.7.0-diff-whitespace-only-output (2009-11-19) 1 commit
(merged to 'next' on 2009-11-21 at 3375bf4)
+ No diff -b/-w output for all-whitespace changes
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
Likewise.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[Reverted from 'next']
* jc/botched-maint-cygwin-count-objects (2009-11-24) 2 commits
(merged to 'next' on 2009-11-25 at 8aa62a0)
+ Revert "ST_BLOCKS_COUNTS_IN_BLKSIZE to say on-disk size is (st_blksize * st_blocks)"
(merged to 'next' on 2009-11-22 at 4ba5880)
+ ST_BLOCKS_COUNTS_IN_BLKSIZE to say on-disk size is (st_blksize * st_blocks)
This is a revert of the tip one I merged prematurely to 'next'. The real
fix from Ramsay is already in 'master'.
* ks/precompute-completion (2009-11-15) 4 commits.
(merged to 'next' on 2009-11-15 at 23cdb96)
+ Revert ks/precompute-completion series
(merged to 'next' on 2009-10-28 at cd5177f)
+ completion: ignore custom merge strategies when pre-generating
(merged to 'next' on 2009-10-22 at f46a28a)
+ bug: precomputed completion includes scripts sources
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading
Reverted out of 'next', to be replaced with jn/faster-completion-startup
topic.
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/1.7.0-no-commit-no-ff-2 (2009-10-22) 1 commit.
. git-merge: forbid fast-forward and up-to-date when --no-commit is given
This makes "git merge --no-commit" fail when it results in fast-forward or
up-to-date. It appears nobody wants to have this, so I dropped it.
* ne/rev-cache (2009-10-19) 7 commits.
. support for commit grafts, slight change to general mechanism
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
The author indicated that there is another round coming. Does not seem to
pass the tests when merged to 'pu', so it has been ejected for now.
* pb/gitweb-no-project-list (2009-11-06) 3 commits.
. gitweb: Polish the content tags support
. gitweb: Support for no project list on gitweb front page
. gitweb: Refactor project list routines
I picked these up but didn't queue as Warthog9's comments made certain
amount of sense to me.
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Thomas Singer @ 2009-11-29 9:18 UTC (permalink / raw)
To: Maximilien Noal; +Cc: git
In-Reply-To: <4B11AD43.3070307@gmail.com>
Maximilien Noal wrote:
> About the 'boxes' :
>
> The thing is, Windows' files for Asian languages are _not_ installed by
> default.
>
> They can be installed (even while installing Windows), by checking the
> two checkboxes under the "Supplemtal languages support" groupbox in the
> "Languages" tab of the "Regional and language options" control panel.
> *re-take some breath ;-) *
>
> It will remove the "boxes" in Explorer and display nice Asian characters.
Thanks, now the characters are showing up fine in the Explorer.
Reece Dunn wrote:
> This is a bug in git's character encoding/conversion logic. It looks
> like git is taking the source string and converting it to ascii to be
> displayed on the console output (e.g. by using the WideCharToMultiByte
> conversion API) -- these APIs will use a '?' character for characters
> that it cannot map to the target character encoding (like the Hiragana
> characters that you are using).
I have a screenshot from a SmartGit user where 1) the console can show the
far-east-characters and 2) Git *can* show the characters escaped. Are there
two versions of Git available or does Gits behaviour depends somehow on the
system locale?
--
Tom
^ permalink raw reply
* Re: [PATCH 1/6] stg mail: Refactor __send_message and friends
From: Karl Wiberg @ 2009-11-29 9:13 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091128195016.949.17089.stgit@bob.kio>
Alex Chiang wrote:
> Instead of passing all the various smtp* args to __send_message
> individually, let's just pass the options list instead.
Looks good.
> + if (smtppassword and not smtpuser):
> + raise CmdException, 'SMTP password supplied, username needed'
> + if (smtpusetls and not smtpuser):
> + raise CmdException, 'SMTP over TLS requested, username needed'
Python style nit: Use "raise Exception('message')" in new code. (And
yes, I know you just moved these lines around.)
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC/PATCH] t7011: Mark fixed test as such
From: Nguyen Thai Ngoc Duy @ 2009-11-29 8:47 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <0327ed3d7c4621f205d2d111254d716bd1b06c28.1259432535.git.git@drmicha.warpmail.net>
On 11/29/09, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Test 16/17 had been fixed since its introduction in b4d1690 (Teach Git
> to respect skip-worktree bit (reading part), 2009-08-20). So, mark it as
> expect_success rather than expect_failure.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
No ACK. See below.
> ---
> I'm actually wondering about 17/17 as well.
> If commit is called with a file name then shouldn't it simply commit the
> current state of the file in the worktree, no matter what the index or
> skip-worktree say? I therefore think 17/17 should be expect_success
> and have no test_must_fail.
Both 16/17 and 17/17 ensure that Git won't look at files on worktree
if they are marked as skip-worktree (by definition of skip-worktree,
you can safely ignore worktree, otherwise you would not mark them as
such). 16/17 happens to pass, not because it does not touch worktree,
but because the base index does not have "1", which happens to is the
same situation in 16/17 (test commit when "1" is gone). The result is
OK but it is actually not (17/17 shows this clearer as it commits the
worktree version).
--
Duy
^ permalink raw reply
* Re: [RFH] Mention of 1.7.0 transition plans in Release Notes to 1.6.6
From: Junio C Hamano @ 2009-11-29 8:44 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Michael Witten, Jay Soffian
In-Reply-To: <20091129122448.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Subject: prepare send-email for smoother change of --chain-reply-to default
>
> Give a warning message when send-email uses chain-reply-to to thread the
> messages because of the current default, not because the user explicitly
> asked to, either from the command line or from the configuration.
>
> This way, by the time 1.7.0 switches the default, everybody will be ready.
>
> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
> ---
Looks good.
^ permalink raw reply
* Re: git-svn: SVK merge commits can have >2 parents
From: Eric Wong @ 2009-11-29 8:08 UTC (permalink / raw)
To: Sam Vilain; +Cc: Alex Vandiver, git
In-Reply-To: <1259480367-sup-6891@utwig>
Alex Vandiver <alex@chmrr.net> wrote:
> At Sun Nov 29 02:28:39 -0500 2009, Alex Vandiver wrote:
> > While converting a mildly complicated svn repository that was managed
> > with SVK, I ran across the following oddness. `svk smerge` can only
> > merge between _two_ branches at once -- however, the way that svk
> > merge detection works, you can end up with erroneous extra parents
> > from long-dead branches.
>
> Upon a little more inspection, I now understand that the rev-parse
> lines in find_extra_svk_parents are attempting to deal with this exact
> circumstance -- but they fail to properly sort the merge tickets
> first, which leads to this incorrect behavior. Armed with this
> understanding, I'm more confident in the attached updated patch. I
Hi Alex, Sam,
I'll defer to Sam for the Ack, my svk knowledge is limited. Thanks.
--
Eric Wong
^ permalink raw reply
* git-svn: SVK merge commits can have >2 parents
From: Alex Vandiver @ 2009-11-29 7:28 UTC (permalink / raw)
To: Sam Vilain, Eric Wong; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]
Heya,
While converting a mildly complicated svn repository that was managed
with SVK, I ran across the following oddness. `svk smerge` can only
merge between _two_ branches at once -- however, the way that svk
merge detection works, you can end up with erroneous extra parents
from long-dead branches. Case in point:
export SVKROOT=/tmp/svk-testing-$$
svk mkdir //trunk -m 'trunk'
svk mkdir //branches -m 'branches'
svk co //trunk
svk cp //trunk/ //branches/feature1 -m 'branch for feature1'
svk cp //trunk/ //branches/feature2 -m 'branch for feature2'
svk co //branches/feature1
cd feature1
echo "foo" >foo
svk add foo
svk ci -m 'feature1 development'
svk sm //branches/feature1 //trunk -m 'merge feature1 to trunk'
cd ..
svk co //branches/feature2
cd feature2
echo "bar" >bar
svk add bar
svk ci -m 'feature2 development'
svk sm //trunk //branches/feature2 -m 'merge from trunk'
cd ..
git svn clone -s file://$SVKROOT/local
The 'feature2' branch will appear to have three parents: r7, r6, _and_
r5. The r5 parent is extraneous, and only appears because r5 was
previously merged into trunk, as part of r6.
Given this, I'm a little confused why find_extra_svk_parents is
written the way that it is, in seemingly allowing multiple extra
parents to be found. Since the most recent (i.e., highest-numbered)
change is by definition the only one that can account for all of the
other svk:merge changes, I _believe_ the attached diff to be correct,
but I'm unsure because of the implicit current assumption that smerges
can produce multiple parents.
- Alex
--
Networking -- only one letter away from not working
[-- Attachment #2: 0001-git-svn-svk-merge-commits-should-only-add-one-exta-p.patch --]
[-- Type: application/octet-stream, Size: 1400 bytes --]
From b86b4bb0cecb70d828558b046aa0b3e7b899bf41 Mon Sep 17 00:00:00 2001
From: Alex Vandiver <alex@chmrr.net>
Date: Sun, 29 Nov 2009 02:20:21 -0500
Subject: [PATCH] git-svn: svk merge commits should only add one exta parent
When merging branches based on svk:merge properties, a single merge
can have updated or added multiple svk:merge lines. If so. only
include the minimal set of new parents.
Signed-off-by: Alex Vandiver <alex@chmrr.net>
---
git-svn.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 957d44e..668e50c 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2940,10 +2940,12 @@ sub find_extra_svk_parents {
if ( my $commit = $gs->rev_map_get($rev, $uuid) ) {
# wahey! we found it, but it might be
# an old one (!)
- push @known_parents, $commit;
+ push @known_parents, [ $rev, $commit ];
}
}
}
+ # We only care about the highest-numbered applicable commit
+ @known_parents = map {$_->[1]} sort {$b->[0] <=> $a->[0]} @known_parents;
for my $parent ( @known_parents ) {
my @cmd = ('rev-list', $parent, map { "^$_" } @$parents );
my ($msg_fh, $ctx) = command_output_pipe(@cmd);
@@ -2956,6 +2958,7 @@ sub find_extra_svk_parents {
print STDERR
"Found merge parent (svk:merge ticket): $parent\n";
push @$parents, $parent;
+ return;
}
}
}
--
1.6.6.rc0.254.g7352d
^ permalink raw reply related
* Re: git-svn: SVK merge commits can have >2 parents
From: Alex Vandiver @ 2009-11-29 7:46 UTC (permalink / raw)
To: Sam Vilain, Eric Wong; +Cc: git
In-Reply-To: <1259479636-sup-573@utwig>
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]
At Sun Nov 29 02:28:39 -0500 2009, Alex Vandiver wrote:
> While converting a mildly complicated svn repository that was managed
> with SVK, I ran across the following oddness. `svk smerge` can only
> merge between _two_ branches at once -- however, the way that svk
> merge detection works, you can end up with erroneous extra parents
> from long-dead branches.
Upon a little more inspection, I now understand that the rev-parse
lines in find_extra_svk_parents are attempting to deal with this exact
circumstance -- but they fail to properly sort the merge tickets
first, which leads to this incorrect behavior. Armed with this
understanding, I'm more confident in the attached updated patch. I
assume, however, that the logic allows for more than one extra parent
only because such an occurrance could be constructed by hand-editing
svk:merge, because AFAIK svk's command-line tools should be able to
construct such a circumstance.
- Alex
--
Networking -- only one letter away from not working
[-- Attachment #2: 0001-git-svn-sort-svk-merge-tickets-to-account-for-minima.patch --]
[-- Type: application/octet-stream, Size: 1369 bytes --]
From 4d30e57e5da7c2e880908bc742cf80990d6f9f5d Mon Sep 17 00:00:00 2001
From: Alex Vandiver <alex@chmrr.net>
Date: Sun, 29 Nov 2009 02:20:21 -0500
Subject: [PATCH] git-svn: sort svk merge tickets to account for minimal parents
When merging branches based on svk:merge properties, a single merge
can have updated or added multiple svk:merge lines. Attempt to
include the minimal set of parents by sorting the merge properties in
order of revision, highest to lowest.
Signed-off-by: Alex Vandiver <alex@chmrr.net>
---
git-svn.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 957d44e..51f03ad 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2940,10 +2940,14 @@ sub find_extra_svk_parents {
if ( my $commit = $gs->rev_map_get($rev, $uuid) ) {
# wahey! we found it, but it might be
# an old one (!)
- push @known_parents, $commit;
+ push @known_parents, [ $rev, $commit ];
}
}
}
+ # Ordering matters; highest-numbered commit merge tickets
+ # first, as they may account for later merge ticket additions
+ # or changes.
+ @known_parents = map {$_->[1]} sort {$b->[0] <=> $a->[0]} @known_parents;
for my $parent ( @known_parents ) {
my @cmd = ('rev-list', $parent, map { "^$_" } @$parents );
my ($msg_fh, $ctx) = command_output_pipe(@cmd);
--
1.6.6.rc0.254.g7352d
^ permalink raw reply related
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