* Re: git format-patch should honor notes
From: Michael J Gruber @ 2010-12-08 8:20 UTC (permalink / raw)
To: Jeff King; +Cc: Eric Blake, Thomas Rast, Git Mailing List
In-Reply-To: <20101207221151.GC1036@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 07.12.2010 23:11:
> On Tue, Dec 07, 2010 at 02:53:09PM -0700, Eric Blake wrote:
>
>> My workflow is that I post patch series for upstream review via 'git
>> send-email'. Often, that results in feedback that requires me to
>> amend/rebase my series, and post a v2 or v3 of the series. By adding
>> 'git config notes.rewriteRef refs/notes/commits', I can add notes that
>> will carry across my rebase, and remind me what I changed in v2 (for
>> example, git notes add -m 'v2: fix foo, per mail xyz@example.com').
>> This is handy for me, and I think it is also handy for reviewers -
>> someone who took the time to read through v1 should know what I changed
>> in response to their comments, and only have to focus in on commits with
>> changes, rather than on the entire resent series.
>
> Yeah, that is a workflow that some others have mentioned using here,
> too. And I think there is general agreement that notes should go after
> the "---" in format-patch. We just need a working patch.
>
> Thomas posted one in February:
>
> http://article.gmane.org/gmane.comp.version-control.git/140819
>
> But there were some issues and it never got polished. Michael suggested
> that he does something similar here:
>
> http://article.gmane.org/gmane.comp.version-control.git/140819
>
> but there was no indication on whether it happens manually or if he has
> a patch. I don't know if anything else has happened in that area. I'm
> sure if you feel like working on a patch it would be well received.
>
> -Peff
I do it with ":r!git notes show" in vim (after "/---"), which has the
advantage over "format-patch --show-notes" that the notes are not
indented nor preceded by a "Notes:" header. (I wouldn't mind the
latter.) This is comfortable enough to have kept me from writing a patch.
Also, in order to be really useful, I would need a place to store the
cover letter also. I was experimenting a while back with a design for
annotating branchnames which "basically" worked but haven't had time to
really implement it. If I remember correctly, I had to set up some
"bogus" refs to keep my notes from being garbage collected and was still
figuring out the best place to put them. I'll dig it up when I have time to.
Michael
^ permalink raw reply
* Vendor branches workflow
From: Leonid Podolny @ 2010-12-08 8:57 UTC (permalink / raw)
To: git
Hi, list,
I would like an advice on organizing a vendor branch workflow, to
minimize the risk of it biting me in the future.
In our project, we have two upstreams, which are rather massively
patched. One of the upstreams is an SF svn repository, the other
arrives in form of tgz's with sources. Now git is tracking the patched
version, and I want to add a vendor branch to simplify future vendor
drops.
Out of the SVN upstream, we use only specific directories.
So, two questions:
- How do I deal with unneeded directories? Do I filter them out before
commiting to the vendor branch or while merging the vendor branch into
the master?
- Do you think it would be a good idea to keep .svn directories around
at the vendor branch? (Kind of connected to the first question,
because if I keep the .svn's, I will also have to keep the unneeded
dirs).
^ permalink raw reply
* Re: Vendor branches workflow
From: Jonathan Nieder @ 2010-12-08 9:09 UTC (permalink / raw)
To: Leonid Podolny; +Cc: git
In-Reply-To: <AANLkTi=s9p3RycRCrocHEzfc4L-pnU6S9xCKfEL7TP=i@mail.gmail.com>
Hi Leonid,
Leonid Podolny wrote:
> In our project, we have two upstreams, which are rather massively
> patched. One of the upstreams is an SF svn repository, the other
> arrives in form of tgz's with sources. Now git is tracking the patched
> version, and I want to add a vendor branch to simplify future vendor
> drops.
>
> Out of the SVN upstream, we use only specific directories.
If I were in this situation, I would use "git svn" with its
ignore-paths option. Like so:
git svn -Rsvn init --ignore-paths='^(?!directory-a|directory-b)' \
$url/trunk
This way, using "git svn fetch" causes the history of these files to
be fetched, and one can use gitk, git log -S, git bisect, and other
familiar tools to browse through it.
Alternatively, a more usual vendor branch workflow (manually
committing the relevant files) can work well, too. In either case I
would only track the upstream files relevant to the history of my
project. A .gitignore file can be useful to avoid accidentally
tracking other files (like the .svn metadata).
Hope that helps,
Jonathan
^ permalink raw reply
* Re: diff for deleted file only, when changed to directory
From: Bert Wesarg @ 2010-12-08 9:29 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git Mailing List, Nguyễn Thái Ngọc
In-Reply-To: <20101208082103.GA4927@burratino>
2010/12/8 Jonathan Nieder <jrnieder@gmail.com>:
> Bert Wesarg wrote:
>
>> git
>> diff --cached -- foo shows me the diff for both the file foo and file
>> foo/bar.
> [...]
>> But for the case
>> file->directory, I would like to see only the deleted diff, not
>> recursing into the directory.
>
> If I understand correctly, this is a documentation bug and feature
> request.
>
> The documentation bug: the "git diff" documentation says something
> like
>
> git diff [--options] [<tree>[..<tree>]] [--] [<path>...]
>
> but the <path>s after "--" are actually patterns (path specifiers).
> See [1] ([RFD] git glossary: define pathspec, 2010-11-29).
>
> The feature request: there is no way to specify an "exact match"
> or "negative match" when specifying paths. At least "negative
> match" has been suggested before.
>
Thanks for the pointers.
I don't expect that we can change <foo> to match only files and not directories.
Bert
> [1] http://thread.gmane.org/gmane.comp.version-control.git/162379
>
^ permalink raw reply
* Re: diff for deleted file only, when changed to directory
From: Nguyen Thai Ngoc Duy @ 2010-12-08 9:56 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Jonathan Nieder, Git Mailing List
In-Reply-To: <AANLkTikMf5qRaqkdiOKP_PBf=Q68fMc2U5WVN-7SWFYC@mail.gmail.com>
2010/12/8 Bert Wesarg <bert.wesarg@googlemail.com>:
> 2010/12/8 Jonathan Nieder <jrnieder@gmail.com>:
>> Bert Wesarg wrote:
>>
>>> git
>>> diff --cached -- foo shows me the diff for both the file foo and file
>>> foo/bar.
>> [...]
>>> But for the case
>>> file->directory, I would like to see only the deleted diff, not
>>> recursing into the directory.
>>
>> If I understand correctly, this is a documentation bug and feature
>> request.
>>
>> The documentation bug: the "git diff" documentation says something
>> like
>>
>> git diff [--options] [<tree>[..<tree>]] [--] [<path>...]
>>
>> but the <path>s after "--" are actually patterns (path specifiers).
>> See [1] ([RFD] git glossary: define pathspec, 2010-11-29).
>>
>> The feature request: there is no way to specify an "exact match"
>> or "negative match" when specifying paths. At least "negative
>> match" has been suggested before.
>>
>
> Thanks for the pointers.
>
> I don't expect that we can change <foo> to match only files and not directories.
Try
diff --cached -- '[f]'
From top of my memory, directory matching does not work with
wildcards. By putting wildcards to your patterns, dir should never be
matched again. I haven't tested it though.
--
Duy
^ permalink raw reply
* Re: git format-patch should honor notes
From: Johan Herland @ 2010-12-08 10:12 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber, Jeff King, Eric Blake, Thomas Rast
In-Reply-To: <4CFF3FE4.4080104@warpmail.net>
On Wednesday 08 December 2010, Michael J Gruber wrote:
> Also, in order to be really useful, I would need a place to store the
> cover letter also. I was experimenting a while back with a design for
> annotating branchnames which "basically" worked but haven't had time
> to really implement it. If I remember correctly, I had to set up some
> "bogus" refs to keep my notes from being garbage collected and was
> still figuring out the best place to put them. I'll dig it up when I
> have time to.
I believe the last time the issue of adding notes to branch names was
discussed, the consensus was that rather than using notes, they could
be stored using a custom entry in the config file, e.g.
git config branch.mybranch.description "Description of mybranch"
I might have misremembered this, though.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [WIP/RFH] format-patch: Allow diffs for first-parent history
From: Michael J Gruber @ 2010-12-08 10:18 UTC (permalink / raw)
To: git
Introduce a new option "--first-parent" to format-patch which allows
to export the "main development" line as a series of patches, where
merge commits are represented by their diff against the first parent.
This is useful for keeping development steps and history in side
branches and exporting the cleaned up main line for upstream ("mergy
rebase").
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
This does not work yet! Work In Progress/Request For Help
"git log -p -m --first-parent" does exactly what I want to achieve,
since the parent rewriting done by "--first-parent" makes "-p -m" output
the diff to the first parent only.
The attached patch teaches format-patch not to ignore merges (on
"--first-parent"), but I failed to track how "diff-tree" sets options
based on "-m" and how to do that for "format-patch". I am sure someone
here can help me!
builtin/log.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 4191d9c..34d01d3 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -983,6 +983,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
int cover_letter = 0;
int boundary_count = 0;
int no_binary_diff = 0;
+ int first_parent = 0;
struct commit *origin = NULL, *head = NULL;
const char *in_reply_to = NULL;
struct patch_ids ids;
@@ -1023,6 +1024,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
{ OPTION_BOOLEAN, 'p', "no-stat", &use_patch_format, NULL,
"show patch format instead of default (patch + stat)",
PARSE_OPT_NONEG | PARSE_OPT_NOARG },
+ OPT_BOOLEAN(0, "first-parent", &first_parent,
+ "follow first parents"),
OPT_GROUP("Messaging"),
{ OPTION_CALLBACK, 0, "add-header", NULL, "header",
"add email header", 0, header_callback },
@@ -1055,7 +1058,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
rev.commit_format = CMIT_FMT_EMAIL;
rev.verbose_header = 1;
rev.diff = 1;
- rev.no_merges = 1;
+ rev.no_merges = !first_parent;
+ rev.first_parent_only = first_parent;
DIFF_OPT_SET(&rev.diffopt, RECURSIVE);
rev.subject_prefix = fmt_patch_subject_prefix;
memset(&s_r_opt, 0, sizeof(s_r_opt));
--
1.7.3.2.660.g7cc83
^ permalink raw reply related
* Re: git format-patch should honor notes
From: Michael J Gruber @ 2010-12-08 10:24 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Jeff King, Eric Blake, Thomas Rast
In-Reply-To: <201012081112.12112.johan@herland.net>
Johan Herland venit, vidit, dixit 08.12.2010 11:12:
> On Wednesday 08 December 2010, Michael J Gruber wrote:
>> Also, in order to be really useful, I would need a place to store the
>> cover letter also. I was experimenting a while back with a design for
>> annotating branchnames which "basically" worked but haven't had time
>> to really implement it. If I remember correctly, I had to set up some
>> "bogus" refs to keep my notes from being garbage collected and was
>> still figuring out the best place to put them. I'll dig it up when I
>> have time to.
>
> I believe the last time the issue of adding notes to branch names was
> discussed, the consensus was that rather than using notes, they could
> be stored using a custom entry in the config file, e.g.
>
> git config branch.mybranch.description "Description of mybranch"
>
> I might have misremembered this, though.
They certainly "could". The question whether they "should" depends on
what they are used for:
- config is neither versioned nor easily shareable; perfect for your own
scratch notes to go away once work is done
- notes are versioned and can be shared (I don't need to tell you...);
perfect for longer term annotations you want to keep
Note that "sharing" here includes also pushing to your backup repo and
cloning around. I'd certainly put patch series cover letters in the
second category.
Michael
^ permalink raw reply
* Re: [PATCH 04/14] msvc: Fix macro redefinition warnings
From: Sebastian Schuberth @ 2010-12-08 10:32 UTC (permalink / raw)
To: Ramsay Jones
Cc: Johannes Sixt, Junio C Hamano, GIT Mailing-list, patthoyts,
pharris
In-Reply-To: <4CFECBB8.2070900@ramsay1.demon.co.uk>
On Wed, Dec 8, 2010 at 01:05, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
> Johannes Sixt wrote:
>> Instead of removing the macros, wouldn't we be much safer with just
>>
>> #ifndef S_IWUSR
>>
>> ? ...
>
> Er... no.
>
> Commit 4091bfc (which added these macros) does not provide any motivation
> for the change, and I'm having a hard time trying to imagine a useful
> purpose for this part of the commit. (I'm not saying there isn't one - just
> that I can't see it :-P )
Sorry for not finding the time to respond to the thread in [1] about
two months ago where this issue about my commit was first raised.
While it's true that my commit message does not contain any detailed
information about its motivation, it says the defines were "missing",
suggesting a compile error. Indeed, I remember that back then my
msysgit working tree did not compile with MSVC if I didn't have these
defines (and I vaguely remember that this was caused by MSVC using
different a header file than MinGW, or in a different order, or
something similar).
However, I'm not able to reproduce this anymore. I checked out
4091bfc^ and 4091bfc, and both compile file with MSVC for me now, the
latter just giving a lot of the mentioned macro redefinition warnings.
Maybe this was caused my me using older MSVC project files with a
newer code base ... I probably should have run
contrib/buildsystems/generate again.
After defining LF_FACESIZE and TMPF_TRUETYPE in winansi.c, and
INTMAX_MAX in git-compat-util.h, I was also able to compile the
v1.7.3.2.msysgit.0 tag with MSVC. If I revert 4091bfc on top of it, it
still compiles fine for me.
> So, once again, I see no reason to keep them ... Unless you know otherwise.
I agree to remove the lines and vote in favor of Ramsay's patch. Feel
free to add me as Signed-off-by or Acked-by.
[1] http://thread.gmane.org/gmane.comp.version-control.git/158144/focus=158409
--
Sebastian Schuberth
^ permalink raw reply
* Re: git format-patch should honor notes
From: Johan Herland @ 2010-12-08 10:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Jeff King, Eric Blake, Thomas Rast
In-Reply-To: <4CFF5CD2.2000009@drmicha.warpmail.net>
On Wednesday 08 December 2010, Michael J Gruber wrote:
> Johan Herland venit, vidit, dixit 08.12.2010 11:12:
> > On Wednesday 08 December 2010, Michael J Gruber wrote:
> >> Also, in order to be really useful, I would need a place to store
> >> the cover letter also. I was experimenting a while back with a
> >> design for annotating branchnames which "basically" worked but
> >> haven't had time to really implement it. If I remember correctly,
> >> I had to set up some "bogus" refs to keep my notes from being
> >> garbage collected and was still figuring out the best place to put
> >> them. I'll dig it up when I have time to.
> >
> > I believe the last time the issue of adding notes to branch names
> > was discussed, the consensus was that rather than using notes, they
> > could be stored using a custom entry in the config file, e.g.
> >
> > git config branch.mybranch.description "Description of mybranch"
> >
> > I might have misremembered this, though.
>
> They certainly "could". The question whether they "should" depends on
> what they are used for:
>
> - config is neither versioned nor easily shareable; perfect for your
> own scratch notes to go away once work is done
>
> - notes are versioned and can be shared (I don't need to tell
> you...); perfect for longer term annotations you want to keep
>
> Note that "sharing" here includes also pushing to your backup repo
> and cloning around. I'd certainly put patch series cover letters in
> the second category.
True. I was wrong to equate cover letters with local-only branch name
descriptions.
As has been discussed before, you can use notes to store the cover
letter, the question is which SHA-1 to attach it to.
Using a SHA-1 that doesn't exist in the repo (e.g. the SHA-1 of the
branch name) leaves the note vulnerable to 'git notes prune', but maybe
that is an acceptable restriction ('git notes prune' must be manually
invoked in any case). For extra safety, we could add a config option
that refuses 'git notes prune' for a given notes ref, something like:
git config notes.mynotes.refusePrune true
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [WIP/RFH] format-patch: Allow diffs for first-parent history
From: Jonathan Nieder @ 2010-12-08 10:52 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <f60b93ae61c0e3088112cd6e1185d9c66f623813.1291803440.git.git@drmicha.warpmail.net>
Michael J Gruber wrote:
> The attached patch teaches format-patch not to ignore merges (on
> "--first-parent"), but I failed to track how "diff-tree" sets options
> based on "-m"
With hindsight, here's a search result:
$ git grep -e argv -- builtin/diff-tree.c
int cmd_diff_tree(int argc, const char **argv, const char *prefix)
argc = setup_revisions(argc, argv, opt, &s_r_opt);
const char *arg = *++argv;
So it's setup_revisions, in revision.c, which clears revs->ignore_merges
when -m is detected.
Maybe it should clear revs->no_merges while at it? I can't see any
other meaningful meaning for
git alias.lg "log --no-merges"
git lg -m HEAD~2..HEAD
or
git format-patch -m --first-parent HEAD~2..HEAD
Meanwhile I would also be happy to see --first-parent imply -m, though
that might be more controversial since -p -c --first-parent and
-p --cc --first-parent are also meaningful.
^ permalink raw reply
* Re: git format-patch should honor notes
From: Thomas Rast @ 2010-12-08 11:15 UTC (permalink / raw)
To: Jeff King; +Cc: Eric Blake, Michael J Gruber, Git Mailing List
In-Reply-To: <20101207221151.GC1036@sigill.intra.peff.net>
Jeff King wrote:
> > My workflow is that I post patch series for upstream review via 'git
> > send-email'. Often, that results in feedback that requires me to
> > amend/rebase my series, and post a v2 or v3 of the series. By adding
> > 'git config notes.rewriteRef refs/notes/commits', I can add notes that
> > will carry across my rebase, and remind me what I changed in v2 (for
> > example, git notes add -m 'v2: fix foo, per mail xyz@example.com').
>
> Yeah, that is a workflow that some others have mentioned using here,
Incidentally it's what I wrote the rewriteRef support for :-)
> too. And I think there is general agreement that notes should go after
> the "---" in format-patch. We just need a working patch.
>
> Thomas posted one in February:
>
> http://article.gmane.org/gmane.comp.version-control.git/140819
>
> But there were some issues and it never got polished.
I got pretty frustrated with gfp being rather brittle. It is very
hard to insert anything anywhere in the output stream in such a way
that the output is not affected in any *other* scenario where this
option is disabled.
So I think a good angle of attack if you want to hack around on this
would be to clean up gfp so that it becomes easier to work on, and/or
come up with a better/cleaner place to insert the notes support than I
had.
That being said, the version I still use just shifts around a linefeed
after the ---, IIRC, and so far nobody complained about that in
practice ;-)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCHv2] git-rm.txt: Fix quoting
From: Michael J Gruber @ 2010-12-08 11:15 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Jonathan Nieder
In-Reply-To: <20101207172542.GA25827@sigill.intra.peff.net>
Literal " produces typographically incorrect quotations, but "works" in
most circumstances. In the subheadings of git-rm.txt, it "works" for the
html backend but not for the docbook conversion to nroff: double "" and
spurious double spaces appear in the output.
Replace "incorrect" quotations by ``correct'' ones, and fix other
"quotations" which are really 'command names' resp. plain words.
This should make git-rm.txt "-clean.
Reported-by: Jeff King <peff@peff.net>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
While we don't need to match the underlines to the header's length, it
looks nicer. So v2 incorporates this and the other changes:
- untar is not a command on proper OSs
- rsync is not a complete command line (implicit style guide...)
Documentation/git-rm.txt | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 71e3d9f..0adbe8b 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -89,8 +89,8 @@ the paths that have disappeared from the filesystem. However,
depending on the use case, there are several ways that can be
done.
-Using "git commit -a"
-~~~~~~~~~~~~~~~~~~~~~
+Using ``git commit -a''
+~~~~~~~~~~~~~~~~~~~~~~~
If you intend that your next commit should record all modifications
of tracked files in the working tree and record all removals of
files that have been removed from the working tree with `rm`
@@ -98,8 +98,8 @@ files that have been removed from the working tree with `rm`
automatically notice and record all removals. You can also have a
similar effect without committing by using `git add -u`.
-Using "git add -A"
-~~~~~~~~~~~~~~~~~~
+Using ``git add -A''
+~~~~~~~~~~~~~~~~~~~~
When accepting a new code drop for a vendor branch, you probably
want to record both the removal of paths and additions of new paths
as well as modifications of existing paths.
@@ -111,8 +111,8 @@ tree using this command:
git ls-files -z | xargs -0 rm -f
----------------
-and then "untar" the new code in the working tree. Alternately
-you could "rsync" the changes into the working tree.
+and then untar the new code in the working tree. Alternately
+you could 'rsync' the changes into the working tree.
After that, the easiest way to record all removals, additions, and
modifications in the working tree is:
--
1.7.3.2.662.g6fd5b8.dirty
^ permalink raw reply related
* t9010 broken in pu [Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)]
From: Thomas Rast @ 2010-12-08 11:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonathan Nieder
In-Reply-To: <7voc90wx36.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> * jn/svn-fe (2010-11-19) 17 commits
> - vcs-svn: Implement Prop-delta handling
> - vcs-svn: Sharpen parsing of property lines
> - vcs-svn: Split off function for handling of individual properties
> - vcs-svn: Make source easier to read on small screens
> - vcs-svn: More dump format sanity checks
> - vcs-svn: Reject path nodes without Node-action
> - vcs-svn: Delay read of per-path properties
> - vcs-svn: Combine repo_replace and repo_modify functions
> - vcs-svn: Replace = Delete + Add
> - vcs-svn: handle_node: Handle deletion case early
> - vcs-svn: Use mark to indicate nodes with included text
> - vcs-svn: Unclutter handle_node by introducing have_props var
> - vcs-svn: Eliminate node_ctx.mark global
> - vcs-svn: Eliminate node_ctx.srcRev global
> - vcs-svn: Check for errors from open()
> - vcs-svn: Allow simple v3 dumps (no deltas yet)
> - vcs-svn: Error out for v3 dumps
>
> Some RFC patches, to give them early and wider exposure.
If I'm reading the test report right, the merge conflict in
t/t9010-svn-fe.sh broke tests. It bisects to 5ea8b68 (Merge branch
'jn/svn-fe' into pu, 2010-12-07), failing with
expecting success:
svnadmin create simple-svn &&
svnadmin load simple-svn <"$TEST_DIRECTORY/t9135/svn.dump" &&
svn_cmd export "file://$PWD/simple-svn" simple-svnco &&
git init simple-git &&
test-svn-fe "$TEST_DIRECTORY/t9135/svn.dump" >simple.fe &&
(
cd simple-git &&
git fast-import <../simple.fe
) &&
(
cd simple-svnco &&
git init &&
git add . &&
git fetch ../simple-git master &&
git diff --exit-code FETCH_HEAD
)
svnadmin: Repository creation failed
svnadmin: Could not create top-level directory
svnadmin: 'simple-svn' exists and is non-empty
not ok - 18 t9135/svn.dump
A quick reading of the merge suggests that you concatenated with an
earlier test that goes
test_dump () {
label=$1
dump=$2
test_expect_success "$dump" '
svnadmin create "$label-svn" &&
# <snip>
'
}
test_dump simple t9135/svn.dump
hence creating simple-svn, too. So a rename or rm -rf should suffice.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: t9010 broken in pu [Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)]
From: Jonathan Nieder @ 2010-12-08 11:28 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <201012081223.47642.trast@student.ethz.ch>
Thomas Rast wrote:
> If I'm reading the test report right, the merge conflict in
> t/t9010-svn-fe.sh broke tests. It bisects to 5ea8b68 (Merge branch
> 'jn/svn-fe' into pu, 2010-12-07), failing with
[...]
> A quick reading of the merge suggests that you concatenated with an
> earlier test that goes
>
> test_dump () {
[...]
> hence creating simple-svn, too. So a rename or rm -rf should suffice.
Thanks for the analysis. Even better would be to remove the redundant
definition and invocation of test_dump, like this (imitating b3e5bce,
vcs-svn: Error out for v3 dumps, 2010-11-17):
---
diff --git a/t/t9010-svn-fe.sh b/t/t9010-svn-fe.sh
index 6e3b6ad..d207aeb 100755
--- a/t/t9010-svn-fe.sh
+++ b/t/t9010-svn-fe.sh
@@ -14,31 +14,6 @@ svn_cmd () {
svn "$subcommand" --config-dir "$svnconf" "$@"
}
-test_dump () {
- label=$1
- dump=$2
- test_expect_success "$dump" '
- svnadmin create "$label-svn" &&
- svnadmin load "$label-svn" < "$TEST_DIRECTORY/$dump" &&
- svn_cmd export "file://$PWD/$label-svn" "$label-svnco" &&
- git init "$label-git" &&
- test-svn-fe "$TEST_DIRECTORY/$dump" >"$label.fe" &&
- (
- cd "$label-git" &&
- git fast-import < ../"$label.fe"
- ) &&
- (
- cd "$label-svnco" &&
- git init &&
- git add . &&
- git fetch "../$label-git" master &&
- git diff --exit-code FETCH_HEAD
- )
- '
-}
-
-test_dump simple t9135/svn.dump
-
reinit_git () {
rm -fr .git &&
git init
^ permalink raw reply related
* Re: cmd_cherry in builtin/log.c?
From: Thiago Farina @ 2010-12-08 11:57 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git Mailing List, rene.scharfe
In-Reply-To: <20101207173923.GA21483@burratino>
On Tue, Dec 7, 2010 at 3:39 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> Thiago Farina wrote:
>
>> I was looking into builtin/log.c to see how it does --reverse and I
>> saw that cmd_cherry is there.
>>
>> I'm wondering, why is it there?
>
> Good question. So let's check.
>
> $ git log --oneline -Scmd_cherry builtin/log.c
> 81b50f3 Move 'builtin-*' into a 'builtin/' subdirectory
>
> That wasn't too helpful. Okay, okay.
>
> $ git log --oneline -Scmd_cherry -- builtin-log.c
> 81b50f3 Move 'builtin-*' into a 'builtin/' subdirectory
> e827633 Built-in cherry
>
> Running "git show e827633" reveals that the core of the original
> script is
>
> for c in $inup
> do
> git-diff-tree -p $c
> done | git-patch-id |
> while read id name
> do
> echo $name >>$patch/$id
> done
>
> while the core of the builtin version is
>
> get_patch_ids(&revs, &patch_id_opts, prefix);
>
> The latter function is static, introduced by v1.4.1~12^2~5
> (format-patch: introduce "--ignore-if-in-upstream", 2006-06-25).
>
> So the answer is that "git cherry" is considered a variant on
> "git log" (like format-patch, show, and whatchanged) and that it uses
> "git log" internals.
>
Yup, thanks for digging into it. Now makes sense.
^ permalink raw reply
* Re: [PATCH 02/14] msvc: git-daemon.exe: Fix linker "unresolved externals" error
From: Erik Faye-Lund @ 2010-12-08 12:41 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, Johannes Sixt, GIT Mailing-list
In-Reply-To: <4CFECD34.3080809@ramsay1.demon.co.uk>
On Wed, Dec 8, 2010 at 1:11 AM, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
> Erik Faye-Lund wrote:
>> On Sat, Dec 4, 2010 at 7:55 PM, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>>> The msvc linker complains about external symbols referenced by
>>> the new poll() emulation code. In particular, it complains about
>>> the DispatchMessage(), PeekMessage(), TranslateMessage() and
>>> MsgWaitForMultipleObjects() functions.
>>>
>>> In order to satisfy the external references, we link against the
>>> user32.lib library.
>>>
>>> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
>>> ---
>>> Makefile | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 1d42413..bda9fa6 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -1087,7 +1087,7 @@ ifeq ($(uname_S),Windows)
>>> COMPAT_OBJS = compat/msvc.o compat/fnmatch/fnmatch.o compat/winansi.o compat/win32/pthread.o compat/win32/syslog.o compat/win32/sys/poll.o
>>> COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -DHAVE_ALLOCA_H -Icompat -Icompat/fnmatch -Icompat/regex -Icompat/fnmatch -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
>>> BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE -NODEFAULTLIB:MSVCRT.lib
>>> - EXTLIBS = advapi32.lib shell32.lib wininet.lib ws2_32.lib
>>> + EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib
>>> PTHREAD_LIBS =
>>> lib =
>>> ifndef DEBUG
>>
>> Looks sane. But it's a bit odd - it currently builds fine without this
>> patch from the IDE, but not from the makefile. Is the linker-libs
>> different between these?
>
> Er... dunno! ;-) I don't use the IDE (except to read the msdn docs), I'm
> *much* more productive in vim (yeah, I'm a luddite!).
>
> So, how did you create your project file? What does it say?
> ie. you tell me! :-P
>
probably by contrib/buildsystems/generate, but I don't quite remember ;)
Anyway, if the result of contrib/buildsystems/generate builds
differently than "make MSVC=1", then I consider this an issue with
contrib/buildsystems/generate, not the MSVC-port.
I can try to reproduce it at some point, but I'm really tight on time right now.
^ permalink raw reply
* git stash path/to/only/one/subdirectory
From: Patrick Doyle @ 2010-12-08 14:15 UTC (permalink / raw)
To: git
Looking at the man page for git-stash, it seems like I can do this
with the --patch option to git-stash, but I figured I'd ask the
questions anyway...
Is it possible to git-stash a single directory, while leaving the rest
of my working copy in the state it's in?
In my particular case (as of 9:00am this morning), I've realized that
I want to split my work into 2 separate commits; I'm not done with
either of them yet; and they are in completely separate directories
from each other. I would like to do something like:
$ git stash --subdir-only dir1
edit/test stuff in dir2, possibly committing once or twice along the way
$ git commit dir2
go off and do other stuff for a while, and come back to the dir1 stuff
I was playing with
$ git stash pop
finish the dir1 work
$ git commit dir1
If this capability doesn't exist, I could try adding it... would other
folks see this as useful?
--wpd
^ permalink raw reply
* [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators
From: Nguyễn Thái Ngọc Duy @ 2010-12-08 14:58 UTC (permalink / raw)
To: git, Junio C Hamano, Kevin Ballard, Yann Dirson, Jeff King,
Jakub Narebski
Cc: Nguyễn Thái Ngọc Duy
Let's start off from where the previous discussion [1] stopped. People
seem to agree ref^{/regex} is a good choice. But we have not come to
conclusion how to specify the count yet. Possible suggestions are
- ref^{/foo}2
- ref^{2/foo}
- ref^{:2/foo}
- ref^{2nd/foo}
For whatever syntax chosen, :/ should benefit too. I notice that :/!
is reserved for future use. Perhaps :/!2/regex is not too cryptic?
I'd also like to do case-insensitive regex, by the way. :/!2i/regex
looks a bit ugly.
[1] http://mid.gmane.org/9D675671-693D-4B59-AF2A-0EFE4C537362@sb.org
Nguyễn Thái Ngọc Duy (2):
get_sha1_oneline: allow to input commit_list
get_sha1: support ref^{/regex} syntax
Documentation/revisions.txt | 7 ++++++
sha1_name.c | 45 ++++++++++++++++++++++++++++++++----------
2 files changed, 41 insertions(+), 11 deletions(-)
--
1.7.3.2.316.gda8b3
^ permalink raw reply
* [PATCH 1/2] get_sha1_oneline: allow to input commit_list
From: Nguyễn Thái Ngọc Duy @ 2010-12-08 14:58 UTC (permalink / raw)
To: git, Junio C Hamano, Kevin Ballard, Yann Dirson, Jeff King,
Jakub Narebski
Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1291820319-12455-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
sha1_name.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 2c3a5fb..f4ccdc5 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -686,13 +686,14 @@ static int handle_one_ref(const char *path,
if (object->type != OBJ_COMMIT)
return 0;
insert_by_date((struct commit *)object, list);
- object->flags |= ONELINE_SEEN;
return 0;
}
-static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
+static int get_sha1_oneline(const char *prefix,
+ unsigned char *sha1,
+ struct commit_list *list_)
{
- struct commit_list *list = NULL, *backup = NULL, *l;
+ struct commit_list *list = list_, *backup = NULL, *l;
int retval = -1;
char *temp_commit_buffer = NULL;
regex_t regex;
@@ -706,9 +707,12 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
if (regcomp(®ex, prefix, REG_EXTENDED))
die("Invalid search pattern: %s", prefix);
- for_each_ref(handle_one_ref, &list);
- for (l = list; l; l = l->next)
+ if (!list)
+ for_each_ref(handle_one_ref, &list);
+ for (l = list; l; l = l->next) {
commit_list_insert(l->item, &backup);
+ l->item->object.flags |= ONELINE_SEEN;
+ }
while (list) {
char *p;
struct commit *commit;
@@ -737,7 +741,8 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
}
regfree(®ex);
free(temp_commit_buffer);
- free_commit_list(list);
+ if (!list_)
+ free_commit_list(list);
for (l = backup; l; l = l->next)
clear_commit_marks(l->item, ONELINE_SEEN);
return retval;
@@ -1090,7 +1095,7 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,
int pos;
if (namelen > 2 && name[1] == '/')
/* don't need mode for commit */
- return get_sha1_oneline(name + 2, sha1);
+ return get_sha1_oneline(name + 2, sha1, NULL);
if (namelen < 3 ||
name[2] != ':' ||
name[1] < '0' || '3' < name[1])
--
1.7.3.2.316.gda8b3
^ permalink raw reply related
* [PATCH 2/2] get_sha1: support ref^{/regex} syntax
From: Nguyễn Thái Ngọc Duy @ 2010-12-08 14:58 UTC (permalink / raw)
To: git, Junio C Hamano, Kevin Ballard, Yann Dirson, Jeff King,
Jakub Narebski
Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1291820319-12455-1-git-send-email-pclouds@gmail.com>
This works like :/ syntax, but only limited to one ref.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/revisions.txt | 7 +++++++
sha1_name.c | 26 ++++++++++++++++++++++----
2 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 3d4b79c..fbe6245 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -106,6 +106,13 @@ the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file.
and dereference the tag recursively until a non-tag object is
found.
+* A suffix '{caret}' to a revision parameter followed by a brace
+ pair that contains a text led by a slash (e.g. `HEAD^{/fix nasty bug}`):
+ this names a commit whose commit message matches the specified
+ regular expression. This name returns the youngest matching commit
+ which is reachable from the dereferenced commit. The leading '!'
+ in the text is treated especially like in `:/` syntax below.
+
* A colon, followed by a slash, followed by a text (e.g. `:/fix nasty bug`): this names
a commit whose commit message matches the specified regular expression.
This name returns the youngest matching commit which is
diff --git a/sha1_name.c b/sha1_name.c
index f4ccdc5..00e52b0 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -527,6 +527,7 @@ struct object *peel_to_type(const char *name, int namelen,
}
}
+static int get_sha1_oneline(const char *, unsigned char *, struct commit_list *);
static int peel_onion(const char *name, int len, unsigned char *sha1)
{
unsigned char outer[20];
@@ -562,6 +563,11 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)
expected_type = OBJ_BLOB;
else if (sp[0] == '}')
expected_type = OBJ_NONE;
+ else if (sp[0] == '/') {
+ if (sp[1] == '}')
+ return -1;
+ expected_type = OBJ_COMMIT;
+ }
else
return -1;
@@ -584,11 +590,23 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)
* barf.
*/
o = peel_to_type(name, len, o, expected_type);
- if (o) {
- hashcpy(sha1, o->sha1);
- return 0;
+ if (!o)
+ return -1;
+
+ hashcpy(sha1, o->sha1);
+ if (sp[0] == '/') { /* ^{/foo} */
+ struct commit_list *list = NULL;
+ char *prefix;
+ int ret;
+
+ commit_list_insert((struct commit *)o, &list);
+ prefix = xstrndup(sp + 1, name + len - 1 - (sp + 1));
+ ret = get_sha1_oneline(prefix, sha1, list);
+ free(prefix);
+ free_commit_list(list);
+ return ret;
}
- return -1;
+ return 0;
}
return 0;
}
--
1.7.3.2.316.gda8b3
^ permalink raw reply related
* Re: [PATCH 1/2] get_sha1_oneline: allow to input commit_list
From: Thiago Farina @ 2010-12-08 15:11 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, Kevin Ballard, Yann Dirson, Jeff King,
Jakub Narebski
In-Reply-To: <1291820319-12455-2-git-send-email-pclouds@gmail.com>
2010/12/8 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> -static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
> +static int get_sha1_oneline(const char *prefix,
> + unsigned char *sha1,
> + struct commit_list *list_)
> {
micronit: can we have a better name for |list_|, the suffix _ is very
ugly and uncommon :(
^ permalink raw reply
* Re: git-svn checksum mismatch
From: Reynald Borer @ 2010-12-08 15:17 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTik0NBkjrPTzLp9ozMnnV+bng_u5Br1v+H4y6ed0@mail.gmail.com>
Hi again,
Sorry to bother you again but I am still experiencing this problem. I
tried with a more up to date version of Git (version 1.7.3.2), and
this is still happening. I also tried to diagnose this issue but I am
completely lost.
I am very annoyed because this is preventing me using Git on all my
SVN repos (2 are failing on 30...)
Does anyone know how I could try to solve this issue?
Thanks very much in advance.
Regards,
Reynald
---------- Forwarded message ----------
From: Reynald Borer <reynald.borer@gmail.com>
Date: Wed, Dec 8, 2010 at 3:28 PM
Subject: git-svn checksum mismatch
To: git@vger.kernel.org
Hello all,
I'm using git with a subversion repository and am experiencing the
well known checksum mismatch problem when I try to fetch from our
repository:
r5289 = f110f54fc3a488639e8b645438c4538e7785228f (refs/remotes/trunk)
Checksum mismatch:
app/tnin/model/src/main/resources/etc/sql/migration_scripts/STX-12229.sql
expected: c70c72fe170781e3279c37d0de637a55
got: f90d31e1fd8e0f88569f87eb087c06c9
I have already been trying to diagnose this issue and have found
nothing to fix it so far. I have tried to do a checkout with an svn
client of the revision 5289, the previous one and then do an update,
everything works fine when doing so.
The only thing I see that may cause this issue is that the file has
special svn property (eol-style=native).
I am using git version version 1.7.2.3 (using svn 1.6.13).
Thanks in advance for your help,
Reynald Borer
^ permalink raw reply
* Re: git-svn checksum mismatch
From: Patrick Doyle @ 2010-12-08 15:36 UTC (permalink / raw)
To: Reynald Borer; +Cc: git
In-Reply-To: <AANLkTimVyCndGZQLUnVM9CCQmDfOHYywcfzBAL2w0gbC@mail.gmail.com>
On Wed, Dec 8, 2010 at 10:17 AM, Reynald Borer <reynald.borer@gmail.com> wrote:
> Hi again,
>
> Sorry to bother you again but I am still experiencing this problem. I
> tried with a more up to date version of Git (version 1.7.3.2), and
> this is still happening. I also tried to diagnose this issue but I am
> completely lost.
>
> I am very annoyed because this is preventing me using Git on all my
> SVN repos (2 are failing on 30...)
>
> Does anyone know how I could try to solve this issue?
Tossing out a random theory with nothing to back it up...
I don't know anything about the "well known checksum mismatch
problem", but are you trying to check out the SVN repository onto a
file system that is case insensitive, such as on a Windows or (default
setup) Mac host?
If so, the repository might have files with different spellings such
as README and Readme in the same directory, which will get clobbered
on such a host. I've run into that issue in the past in a different
context.
--wpd
^ permalink raw reply
* Re: git stash path/to/only/one/subdirectory
From: Johan Herland @ 2010-12-08 15:38 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <AANLkTim+sOeVfkAac1v-CsD5GG8Vj2VSjXn-9SSw+Hjb@mail.gmail.com>
On Wednesday 08 December 2010, Patrick Doyle wrote:
> Looking at the man page for git-stash, it seems like I can do this
> with the --patch option to git-stash, but I figured I'd ask the
> questions anyway...
>
> Is it possible to git-stash a single directory, while leaving the
> rest of my working copy in the state it's in?
>
> In my particular case (as of 9:00am this morning), I've realized that
> I want to split my work into 2 separate commits; I'm not done with
> either of them yet; and they are in completely separate directories
> from each other. I would like to do something like:
>
> $ git stash --subdir-only dir1
> edit/test stuff in dir2, possibly committing once or twice along the
> way $ git commit dir2
> go off and do other stuff for a while, and come back to the dir1
> stuff I was playing with
> $ git stash pop
> finish the dir1 work
> $ git commit dir1
Usually, I solve these problems by staging dir2 with 'git add dir2' and
then committing it ('git commit' without -a), then running 'git stash'
to remove dir1 changes from the worktree. I can now test the dir2
changes and fix the dir2 commit (if needed) with 'git commit --amend'.
Then, when it looks good, I can bring dir1 back with 'git stash pop'
and continue working on that.
You should also look at 'git add -p' to stage changes hunk-by-hunk. That
is really helpful when dir1 changes and dir2 changes are not in
separate directories.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ 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