* Re: Fwd: What is the best way to backport a feature?
From: Peter Weseloh @ 2009-11-29 19:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200911291933.54301.j6t@kdbg.org>
2009/11/29 Johannes Sixt <j6t@kdbg.org>:
> [please keep the Cc list]
Sorry!
>
> http://gitster.livejournal.com/42247.html
>
> Basically, as soon as you merge Mainline into Feature_A, you change the topic
> of Feature_A from "Feature for Release_1.0" to "Feature for this Mainline".
> Clearly, this topic is not suitable for Release_1.0 anymore.
>
> There is a way around this that doesn't sacrifice the topic-oriented nature of
> the branch: You keep developing Feature_A as planned for Release_1.0 and when
> you notice that merging this feature to Mainline will become increasingly
> complex, you fork off a new branch Feature_A_for_Release_2.0 from Mainline
> and merge Feature_A into this new branch:
>
> o--o--o Release_1.0
> / \ \
> o-o-o--o--o-o-o-o-X-o---o--o Mainline
> \ \
> F1 o--o Feature_A_for_Release_2.0
> \ / /
> F2--------F3-F4 Feature_A
>
> The fork point X must be in Release_2.0.
That makes perfect sense. I will discuss your suggestion with my
colleagues and will send them the link you mentioned. It's just that
branching and especially merging with CVS is so painful that they
might get scared :-). With git that's completly different, of course.
Thanks a lot,
Peter
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Uri Okrent @ 2009-11-29 19:45 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jeff King, A Large Angry SCM, Junio C Hamano, git
In-Reply-To: <94a0d4530911290338h459dd5a2p4752f7d58c455964@mail.gmail.com>
Felipe Contreras wrote:
> 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.
>
Sounds like a good idea to me, speaking as someone who has git support
scripts. Dealing with configuration soup in every script would be very
bad.
The same type of insulation though could probably be achieved by not
adding configuration options that alter the behavior of commands,
and instead have user's rely on aliases for that purpose. (The cat's
probably already out of the bag WRT to configuration though).
--
Uri
Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-29 19:49 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, James Pickens, git
In-Reply-To: <20091129183217.GB21520@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Nov 29, 2009 at 11:28:27AM +0100, Johannes Schindelin wrote:
> ...
>> > 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.
>
> ... The actual situation
> at hand is a git grep configuration variable. I am weighing the
> preference of people who use git every day and want it to work in a
> certain way against the possibility that somebody helping them will be
> slightly inconvenienced or surprised.
While my position is *not* "hurting people who help is too grave and we
shouldn't even weigh other upsides against it---bad is bad is bad, and it
is absolutely bad" (which is what I think Dscho is saying), I think
"slightly inconvenienced or surprised" is trying to make it sound a lot
lighter than it is.
Imagine you are helping somebody to track down a bug in a project whose
source happens to be under git. You two scratch your heads together, and
you try to find if the function you are fixing have other call sites, and
you run "git grep" to find them. You think you covered the whole tree,
identified all the callsites and made sure that the updated behaviour of
the function with your fix is consistent with all of them. But it turns
out that you didn't check the whole tree, due to user's configuration, and
you didn't notice.
You can easily waste 30 minutes of two people until you realize what
happened. Because the whole point of your grep.fulltree configuration is
that you can set it once and forget about it, even after you noticed that
your grep didn't look in the whole tree as you expected, the configuration
variable is not the first thing that will come to your mind. You will
waste more minutes wondering why grep is not working as you expect, until
you finally come up with a suggestion to set the configuration to make
grep look in the full tree by default in her repository.
Put it another way, your "I can set it and forget about it" may be a way
to solve "differentiating two things is a mental burden and I do not want
to think about it". But I do not think the "mental burden" problem is
necessarily what we want to solve. The "set and forget" will bring
confusion.
The best solution to the "mental burden" problem may not even be "I can
set it and forget about it". An obvious solution to that problem, that is
far easier to explain, is not to have two things to begin with, and that is
what we do: "If you want to grep in the whole tree, you go to the top and
run grep there." Of course, its downside is that it is often cumbersome
to "got to the top" when you are somewhere deep.
That is why I think it would be a lot better solution to spend our efforts
making sure that both semantics can be called for from the command line in
a concise and clear way. IOW, the problem I see worth solving first is
not the "mental burden" problem, but is "differentiating two things is
necessary, but it is cumbersome to say which one I want."
You probably can add both configuration and concise command line syntax,
but "solving" the "mental burden" problem will make you forget about the
need to use --full-tree option (or its quivalent that will happen in the
solution of the "cumbersome to say which one I want" problem). On the
other hand, not "solving" the "mental burden" problem will hopefully train
your brain and your fingers to always be aware of and to say which one you
want, to the point that you do not even have to think.
For that to happen, "cumbersome to say which" problem must be solved
nicely, of course.
> ... Something that will happen much
> less frequently than the person actually _using_ git, and something
> which has much smaller negative consequences than people dying.
It is of course not _fatal_, but there are not many things that are fatal.
Saying "that is not fatal so it is Ok" is not particularly a good way to
weigh downsides against upsides.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Uri Okrent @ 2009-11-29 19:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Schindelin, James Pickens, git
In-Reply-To: <20091127205305.GB26921@coredump.intra.peff.net>
Jeff King wrote:
> On Fri, Nov 27, 2009 at 10:47:45AM -0800, Uri Okrent wrote:
>> As a matter of
>> fact, my personal opinion (which I probably neglected to mention) is
>> that grep default behavior should stay the same since it is semantically
>> closer to unix (or gnu) grep.
>
> Keeping consistency with non-git grep has been mentioned a few times in
> this thread. I really don't understand how default file selection is
> supposed to maintain consistency with non-git grep. Regular grep
> defaults to stdin if no paths are given. That mode doesn't make any
> sense for git grep.
>
> So of the two options (grepping the list of files from the full tree, or
> the list of files rooted at the current directory), how is one closer to
> non-git grep than the other?
>
> -Peff
I guess you're right, in that neither is exactly the same as non-git,
and so it's impossible to objectively quantify how one is "closer". My
general feeling though is that grep rooted at the current directory is
more similar because grep -r does exist and is common enough that the
layman isn't too surprised at git's default behavior. Git grep with
--full-tree though, has no analogue in non-git grep.
--
Uri
Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/
^ permalink raw reply
* Re: [spf:guess] Re: git-svn: SVK merge commits can have >2 parents
From: Eric Wong @ 2009-11-29 20:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Vandiver, git, Sam Vilain
In-Reply-To: <1259493967.31767.4.camel@denix>
Sam Vilain <sam@vilain.net> wrote:
> 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>
Thanks Sam, acked and pushed to git://git.bogomips.org/git-svn
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 3/6] stg mail: make __send_message do more
From: Karl Wiberg @ 2009-11-29 21:23 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091128195026.949.1772.stgit@bob.kio>
On Sat, Nov 28, 2009 at 8:50 PM, Alex Chiang <achiang@hp.com> wrote:
> Factor out the common code required to send either a cover mail
> or patch, and implement it in __send_message.
Nice code size reduction.
> + msg_id = email.Utils.make_msgid('stgit')
> + build = { 1: __build_cover, 4: __build_message }
> + msg = build[len(args)](tmpl, msg_id, options, *args)
> +
> + from_addr, to_addrs = __parse_addresses(msg)
> + msg_str = msg.as_string(options.mbox)
> + if options.mbox:
> + out.stdout_raw(msg_str + '\n')
> + return msg_id
> +
> + outstr = { 1: 'the cover message', 4: 'patch "%s"' % args[0] }
> + out.start('Sending ' + outstr[len(args)])
You could consolidate the two dictionaries like this, to avoid making
the same choice twice and make the code more pleasant to read:
(build, outstr) = { 1: (__build_cover, 'the cover message'), 4:
(__build_message, 'patch "%s"' % args[0]) }
> + # give recipients a chance of receiving related patches in correct order
> + # patch_nr < total_nr
> + if len(args) == 1 or (len(args) == 4 and args[1] < args[2]):
> + sleep = options.sleep or config.getint('stgit.smtpdelay')
> + time.sleep(sleep)
Hmm. I must say I find all the args[x] a bit hard to read. I'd prefer
symbolic names.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 5/6] stg mail: add basic support for git send-email
From: Karl Wiberg @ 2009-11-29 21:54 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091128195037.949.63611.stgit@bob.kio>
On Sat, Nov 28, 2009 at 8:50 PM, Alex Chiang <achiang@hp.com> wrote:
> + # XXX: yuck, there's gotta be a more pythonic way. Ideally we'd like
> + # to use the git_opts dictionary as our mapping between stg mail and
> + # git send-email; extract k, v pairs from git_opts, and use those
> + # to iterate across options somehow.
> + git_opts = { 'to': '--to=', 'cc': '--cc=', 'bcc': '--bcc=' }
> + if options.to:
> + for a in options.to:
> + cmd.append("--to=%s" % a)
> + if options.cc:
> + for a in options.cc:
> + cmd.append("--cc=%s" % a)
> + if options.bcc:
> + for a in options.bcc:
> + cmd.append("--bcc=%s" % a)
> + if not options.auto:
> + cmd.append("--suppress-cc=body")
Like this?
for x in ['to', 'cc', 'bcc']:
if getattr(options, x):
cmd.extend('--%s=%s' % (x, a) for a in getattr(options, x))
> + (fd, path) = mkstemp()
> + os.write(fd, msg.as_string(options.mbox))
> + os.close(fd)
> +
> + try:
> + cmd.append(path)
> + call(cmd)
> + except Exception, err:
> + os.unlink(path)
> + raise CmdException, str(err)
> +
> + os.unlink(path)
To avoid having to remember to call unlink in all paths, you can write
try:
try:
cmd.append(path)
call(cmd)
except Exception, e:
raise CmdException(str(e))
finally:
os.unlink(path)
(The combined try...except...finally statement didn't appear until
python 2.5, but we'd like to stay compatible with 2.4.)
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit RFC PATCH 0/6] add support for git send-email
From: Karl Wiberg @ 2009-11-29 22:05 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091128194056.949.88791.stgit@bob.kio>
On Sat, Nov 28, 2009 at 8:50 PM, Alex Chiang <achiang@hp.com> wrote:
> stg mail still has some nice features over git send-email, such
> as the -v command line parameter and --prefix. Maybe at some point
> in the future, we can migrate those features into git send-email and
> continue thinning out stg mail.
Yes. But note that we tend to be conservative and not require a
too-new git, so a patch adding such a dependency would have to wait a
while. (I'm currently carrying two such patches in my experimental
branch.)
> But I wanted to get some feedback first to make sure I'm going in the
> right direction before going too much further.
I've read the patches, and it looks about right from where I stand.
Did you remember to run the regression tests? It's very helpful when
reviewing to know that the regression suite passes at every point in
the series.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* help reverting a merge
From: Justin Mattock @ 2009-11-29 23:24 UTC (permalink / raw)
To: git
(I'm not on the list, so hopefully this goes through).
I've done a bisect on a problem with the kernel,
and am a bit confused on what to do. i.g. the
results are showing this:
a03fdb7612874834d6847107198712d18b5242c7 is the first bad commit
when trying to revert this commit I get this:
git revert a03fdb7612874834d6847107198712d18b5242c7
fatal: Commit a03fdb7612874834d6847107198712d18b5242c7 is a merge but
no -m option was given.
then doing this I get this:
git revert -m 1 a03fdb7612874834d6847107198712d18b5242c7
Automatic revert failed. After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result.
how do I find out the commits in this merge to automatically
revert to find the problem that's causing this bug?
--
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH] reset: add --quiet option
From: Stephen Boyd @ 2009-11-30 1:18 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1259492290-21771-1-git-send-email-felipe.contreras@gmail.com>
On Sun, 2009-11-29 at 12:58 +0200, Felipe Contreras wrote:
> 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()
Why not just OPT__QUIET? We lose the specific help string but it's
possible that what quiet is silencing will change in the future.
Maybe you could move the help string to the documentation if you want to
save it.
^ permalink raw reply
* Re: [RFC/PATCH] t7011: Mark fixed test as such
From: Nguyen Thai Ngoc Duy @ 2009-11-30 1:56 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <4B127DC0.4020108@drmicha.warpmail.net>
On Sun, Nov 29, 2009 at 8:57 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> 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.
That was my bad in setting up the environment for 16/17. I will fix
that in the next roll of nd/sparse.
> 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.
To me, no command should break out skip-worktree mask. In reality I
would expect that case 17/17 only happens when a user accidentally
leaves a file that is marked skip-worktree and tries to commit it. An
error would be more appropriate to keep consistency with other
commands ("git diff HEAD -- 1" would show nothing before committing),
and to warn the user that he/she is stepping on the border. He/she can
then choose to extend worktree area if still wants to commit that
file. How does that sound?
> 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?
Both code and documentation are for Git without skip-worktree. If you
agree with my reasoning above, I will update documentation to reflect
this too.
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH 2/2] builtin-merge: show user-friendly error messages for fast-forward too.
From: Junio C Hamano @ 2009-11-30 2:23 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1259497113-1393-3-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> This is where I'm not 100% sure I'm not breaking some plumbing.
I think this change is safe for the current codebase, as the only caller
of checkout_fast_forward() is cmd_merge(), which is an implementation of
"git merge". Even if there were a plumbing implementation that internally
runs "git merge", either by calling cmd_merge() or via run_command()
interface (there isn't as far as I know), or if somebody adds such a thing
in the future, such a "plumbing" will get Porcelain messages from other
codepaths in cmd_merge() anyway. You are not introducing a new problem.
Or did you have something a lot more subtle in mind?
Side note. checkout_fast_forward() switches between two commits (the one
that matches HEAD) to another (given as remote), which is the same as what
"git checkout other-branch" and "git checkout -b new-branch" do. We might
want to replace it with the main part of merge_working_tree() from
builtin-checkout.c eventually, which would teach the "checkout -m" logic
that carries the local changes forward to fast-forward of "git merge".
> 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++])
^ permalink raw reply
* [PATCH] Update $GIT_DIR/remotes to $GIT_DIR/refs/remotes in docs
From: ayiehere @ 2009-11-30 3:38 UTC (permalink / raw)
To: git
I think this patch is is order now that $GIT_DIR/remotes is no longer used.
^ permalink raw reply
* [PATCH] Update $GIT_DIR/remotes to $GIT_DIR/refs/remotes in docs
From: ayiehere @ 2009-11-30 3:38 UTC (permalink / raw)
To: git; +Cc: Nazri Ramliy
In-Reply-To: <1259552316-20088-1-git-send-email-ayiehere@gmail.com>
From: Nazri Ramliy <ayiehere@gmail.com>
---
Documentation/git-parse-remote.txt | 2 +-
Documentation/git-pull.txt | 6 +++---
Documentation/git-remote.txt | 14 +++++++-------
Documentation/git-show-branch.txt | 2 +-
Documentation/urls-remotes.txt | 8 ++++----
5 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/Documentation/git-parse-remote.txt b/Documentation/git-parse-remote.txt
index 39d9daa..9d27489 100644
--- a/Documentation/git-parse-remote.txt
+++ b/Documentation/git-parse-remote.txt
@@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
-----------
This script is included in various scripts to supply
-routines to parse files under $GIT_DIR/remotes/ and
+routines to parse files under $GIT_DIR/refs/remotes/ and
$GIT_DIR/branches/ and configuration variables that are related
to fetching, pulling and pushing.
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index b932011..250d64c 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -74,13 +74,13 @@ present while on branch `<name>`, that value is used instead of
In order to determine what URL to use to fetch from, the value
of the configuration `remote.<origin>.url` is consulted
and if there is not any such variable, the value on `URL: ` line
-in `$GIT_DIR/remotes/<origin>` file is used.
+in `$GIT_DIR/refs/remotes/<origin>` file is used.
In order to determine what remote branches to fetch (and
optionally store in the tracking branches) when the command is
run without any refspec parameters on the command line, values
of the configuration variable `remote.<origin>.fetch` are
-consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>`
+consulted, and if there aren't any, `$GIT_DIR/refs/remotes/<origin>`
file is consulted and its `Pull: ` lines are used.
In addition to the refspec formats described in the OPTIONS
section, you can have a globbing refspec that looks like this:
@@ -104,7 +104,7 @@ line of `git pull`, they are all merged.
When no refspec was given on the command line, then `git pull`
uses the refspec from the configuration or
-`$GIT_DIR/remotes/<origin>`. In such cases, the following
+`$GIT_DIR/refs/remotes/<origin>`. In such cases, the following
rules apply:
. If `branch.<name>.merge` configuration for the current
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index c272c92..9dbcb0b 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -50,11 +50,11 @@ the remote information is set up.
+
With `-t <branch>` option, instead of the default glob
refspec for the remote to track all branches under
-`$GIT_DIR/remotes/<name>/`, a refspec to track only `<branch>`
+`$GIT_DIR/refs/remotes/<name>/`, a refspec to track only `<branch>`
is created. You can give more than one `-t <branch>` to track
multiple branches without grabbing all branches.
+
-With `-m <master>` option, `$GIT_DIR/remotes/<name>/HEAD` is set
+With `-m <master>` option, `$GIT_DIR/refs/remotes/<name>/HEAD` is set
up to point at remote's `<master>` branch. See also the set-head command.
+
In mirror mode, enabled with `\--mirror`, the refs will not be stored
@@ -69,7 +69,7 @@ Rename the remote named <old> to <new>. All remote tracking branches and
configuration settings for the remote are updated.
+
In case <old> and <new> are the same, and <old> is a file under
-`$GIT_DIR/remotes` or `$GIT_DIR/branches`, the remote is converted to
+`$GIT_DIR/refs/remotes` or `$GIT_DIR/branches`, the remote is converted to
the configuration file format.
'rm'::
@@ -79,23 +79,23 @@ configuration settings for the remote are removed.
'set-head'::
-Sets or deletes the default branch (`$GIT_DIR/remotes/<name>/HEAD`) for
+Sets or deletes the default branch (`$GIT_DIR/refs/remotes/<name>/HEAD`) for
the named remote. Having a default branch for a remote is not required,
but allows the name of the remote to be specified in lieu of a specific
branch. For example, if the default branch for `origin` is set to
`master`, then `origin` may be specified wherever you would normally
specify `origin/master`.
+
-With `-d`, `$GIT_DIR/remotes/<name>/HEAD` is deleted.
+With `-d`, `$GIT_DIR/refs/remotes/<name>/HEAD` is deleted.
+
With `-a`, the remote is queried to determine its `HEAD`, then
-`$GIT_DIR/remotes/<name>/HEAD` is set to the same branch. e.g., if the remote
+`$GIT_DIR/refs/remotes/<name>/HEAD` is set to the same branch. e.g., if the remote
`HEAD` is pointed at `next`, "`git remote set-head origin -a`" will set
`$GIT_DIR/refs/remotes/origin/HEAD` to `refs/remotes/origin/next`. This will
only work if `refs/remotes/origin/next` already exists; if not it must be
fetched first.
+
-Use `<branch>` to set `$GIT_DIR/remotes/<name>/HEAD` explicitly. e.g., "git
+Use `<branch>` to set `$GIT_DIR/refs/remotes/<name>/HEAD` explicitly. e.g., "git
remote set-head origin master" will set `$GIT_DIR/refs/remotes/origin/HEAD` to
`refs/remotes/origin/master`. This will only work if
`refs/remotes/origin/master` already exists; if not it must be fetched first.
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index 7343361..3671c2e 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -161,7 +161,7 @@ $ git show-branch master fixes mhf
+ [mhf~5] Infamous 'octopus merge'
+ [mhf~6] Retire git-parse-remote.
+ [mhf~7] Multi-head fetch.
- + [mhf~8] Start adding the $GIT_DIR/remotes/ support.
+ + [mhf~8] Start adding the $GIT_DIR/refs/remotes/ support.
*++ [master] Add 'git show-branch'.
------------------------------------------------
diff --git a/Documentation/urls-remotes.txt b/Documentation/urls-remotes.txt
index 2a0e7b8..5c4deeb 100644
--- a/Documentation/urls-remotes.txt
+++ b/Documentation/urls-remotes.txt
@@ -7,7 +7,7 @@ The name of one of the following can be used instead
of a URL as `<repository>` argument:
* a remote in the git configuration file: `$GIT_DIR/config`,
-* a file in the `$GIT_DIR/remotes` directory, or
+* a file in the `$GIT_DIR/refs/remotes` directory, or
* a file in the `$GIT_DIR/branches` directory.
All of these also allow you to omit the refspec from the command line
@@ -35,11 +35,11 @@ config file would appear like this:
The `<pushurl>` is used for pushes only. It is optional and defaults
to `<url>`.
-Named file in `$GIT_DIR/remotes`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Named file in `$GIT_DIR/refs/remotes`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can choose to provide the name of a
-file in `$GIT_DIR/remotes`. The URL
+file in `$GIT_DIR/refs/remotes`. The URL
in this file will be used to access the repository. The refspec
in this file will be used as default when you do not
provide a refspec on the command line. This file should have the
--
1.6.6.rc0.63.g66abc
^ permalink raw reply related
* Re: [PATCH] Update $GIT_DIR/remotes to $GIT_DIR/refs/remotes in docs
From: Jeff King @ 2009-11-30 5:03 UTC (permalink / raw)
To: ayiehere; +Cc: git
In-Reply-To: <1259552316-20088-2-git-send-email-ayiehere@gmail.com>
On Mon, Nov 30, 2009 at 11:38:36AM +0800, ayiehere@gmail.com wrote:
> DESCRIPTION
> -----------
> This script is included in various scripts to supply
> -routines to parse files under $GIT_DIR/remotes/ and
> +routines to parse files under $GIT_DIR/refs/remotes/ and
> $GIT_DIR/branches/ and configuration variables that are related
> to fetching, pulling and pushing.
Er, what? $GIT_DIR/remotes/ and $GIT_DIR/refs/remotes/ are not even
remotely the same thing. The former holds information about how to
contact remotes (but that information is usually held in the config file
these days). The latter holds any tracking refs we have fetched from
the remotes.
-Peff
^ permalink raw reply
* [PATCH v2 1/6] t2300: use documented technique to invoke git-sh-setup
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-1-git-send-email-mmogilvi_git@miniinfo.net>
This is needed to allow the test suite to run against a standard
install bin directory instead of GIT_EXEC_PATH.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
t/t2300-cd-to-toplevel.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
index 3b01ad2..9965bc5 100755
--- a/t/t2300-cd-to-toplevel.sh
+++ b/t/t2300-cd-to-toplevel.sh
@@ -8,7 +8,7 @@ test_cd_to_toplevel () {
test_expect_success $3 "$2" '
(
cd '"'$1'"' &&
- . git-sh-setup &&
+ . "$(git --exec-path)"/git-sh-setup &&
cd_to_toplevel &&
[ "$(pwd -P)" = "$TOPLEVEL" ]
)
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH v2 0/6] Run test suite without dashed commands in PATH
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
This patch series runs the test suite without the dashed commands
in the PATH.
Changes since version 1:
- Added patch 3 that documents the pre-existing GIT_TEST_INSTALLED
feature.
- Rename what used to be "test-bin" directory as "bin-wrappers", to
more clearly describe what it is.
- Split off patch 6 (INSTALL documention) from patch
4 (was patch 3), describing how the bin-wrappers directory
is a very convenient way to manually test an uninstalled build.
I also reworded it a bit to mention the downsides. Junio
doesn't seem to agree this is useful; splitting it off makes
it easy to leave it out.
Not changed:
There was some discussion about not building the bin-wrappers directory
unless you are actually running tests. But I don't really think it
is worth the additional complexity to manage this. The "make all"
target is already building several full-up binaries to support the
test suite (not just the small sed-ed scripts that this adds). And any
such solution would need to deal with parallel execution locking
issues, as well as additional uglyness (either duplicating a list
of bindir executables within test-lib.sh itself, or calling into a
parent directory makefile that might already be running in
a grandparent process).
Matthew Ogilvie (6):
t2300: use documented technique to invoke git-sh-setup
t3409 t4107 t7406: use dashless commands
t/README: Document GIT_TEST_INSTALLED and GIT_TEST_EXEC_PATH
build dashless "bin-wrappers" directory similar to installed bindir
run test suite without dashed git-commands in PATH
INSTALL: document a simpler way to run uninstalled builds
.gitignore | 1 +
INSTALL | 11 +++++++-
Makefile | 49 ++++++++++++++++++++++++++---------
t/README | 21 +++++++++++++++
t/t2300-cd-to-toplevel.sh | 2 +-
t/t3409-rebase-preserve-merges.sh | 6 ++--
t/t4107-apply-ignore-whitespace.sh | 20 +++++++-------
t/t7406-submodule-update.sh | 4 +-
t/test-lib.sh | 33 +++++++++++++++---------
wrap-for-bin.sh | 15 +++++++++++
10 files changed, 120 insertions(+), 42 deletions(-)
create mode 100644 wrap-for-bin.sh
^ permalink raw reply
* [PATCH v2 5/6] run test suite without dashed git-commands in PATH
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-5-git-send-email-mmogilvi_git@miniinfo.net>
Only put bin-wrappers in the PATH (not GIT_EXEC_PATH), to emulate the
default installed user environment, and ensure all the programs run
correctly in such an environment. This is now the default, although
it can be overridden with a --with-dashes test option when running
tests.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
t/README | 8 ++++++++
t/test-lib.sh | 33 +++++++++++++++++++++------------
2 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/t/README b/t/README
index 4e1d7dd..8c5d892 100644
--- a/t/README
+++ b/t/README
@@ -75,6 +75,14 @@ appropriately before running "make".
As the names depend on the tests' file names, it is safe to
run the tests with this option in parallel.
+--with-dashes::
+ By default tests are run without dashed forms of
+ commands (like git-commit) in the PATH (it only uses
+ wrappers from TOP/git-bin). Use this option to include TOP
+ in the PATH, which conains all the dashed forms of commands.
+ This option is currently implied by other options like --valgrind
+ and GIT_TEST_INSTALLED.
+
You can also set the GIT_TEST_INSTALLED environment variable to
the bindir of an existing git installation to test that installation.
You still need to have built this git sandbox, from which various
diff --git a/t/test-lib.sh b/t/test-lib.sh
index ec3336a..85377c8 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -105,6 +105,8 @@ do
verbose=t; shift ;;
-q|--q|--qu|--qui|--quie|--quiet)
quiet=t; shift ;;
+ --with-dashes)
+ with_dashes=t; shift ;;
--no-color)
color=; shift ;;
--no-python)
@@ -551,19 +553,8 @@ test_done () {
# Test the binaries we have just built. The tests are kept in
# t/ subdirectory and are run in 'trash directory' subdirectory.
TEST_DIRECTORY=$(pwd)
-if test -z "$valgrind"
+if test -n "$valgrind"
then
- if test -z "$GIT_TEST_INSTALLED"
- then
- PATH=$TEST_DIRECTORY/..:$PATH
- GIT_EXEC_PATH=$TEST_DIRECTORY/..
- else
- GIT_EXEC_PATH=$($GIT_TEST_INSTALLED/git --exec-path) ||
- error "Cannot run git from $GIT_TEST_INSTALLED."
- PATH=$GIT_TEST_INSTALLED:$TEST_DIRECTORY/..:$PATH
- GIT_EXEC_PATH=${GIT_TEST_EXEC_PATH:-$GIT_EXEC_PATH}
- fi
-else
make_symlink () {
test -h "$2" &&
test "$1" = "$(readlink "$2")" || {
@@ -625,6 +616,24 @@ else
PATH=$GIT_VALGRIND/bin:$PATH
GIT_EXEC_PATH=$GIT_VALGRIND/bin
export GIT_VALGRIND
+elif test -n "$GIT_TEST_INSTALLED" ; then
+ GIT_EXEC_PATH=$($GIT_TEST_INSTALLED/git --exec-path) ||
+ error "Cannot run git from $GIT_TEST_INSTALLED."
+ PATH=$GIT_TEST_INSTALLED:$TEST_DIRECTORY/..:$PATH
+ GIT_EXEC_PATH=${GIT_TEST_EXEC_PATH:-$GIT_EXEC_PATH}
+else # normal case, use ../bin-wrappers only unless $with_dashes:
+ git_bin_dir="$TEST_DIRECTORY/../bin-wrappers"
+ if ! test -x "$git_bin_dir/git" ; then
+ if test -z "$with_dashes" ; then
+ say "$git_bin_dir/git is not executable; using GIT_EXEC_PATH"
+ fi
+ with_dashes=t
+ fi
+ PATH="$git_bin_dir:$PATH"
+ GIT_EXEC_PATH=$TEST_DIRECTORY/..
+ if test -n "$with_dashes" ; then
+ PATH="$TEST_DIRECTORY/..:$PATH"
+ fi
fi
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
unset GIT_CONFIG
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH v2 4/6] build dashless "bin-wrappers" directory similar to installed bindir
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-4-git-send-email-mmogilvi_git@miniinfo.net>
The new bin-wrappers directory contains wrapper scripts
for executables that will be installed into the standard
bindir. It explicitly does not contain most dashed-commands.
The scripts automatically set environment variables to run out
of the source tree, not the installed directory.
This will allow running the test suite without dashed commands in
the PATH. It also provides a simplified way to test run custom
built git executables without installing them first.
bin-wrappers also contains wrappers for some test suite support
executables, where the test suite will soon make use of them.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
There was some discussion of only building bin-wrappers when
actually running tests, but I don't think it is worth the
extra complexity. See the cover letter (0/6).
.gitignore | 1 +
Makefile | 49 ++++++++++++++++++++++++++++++++++++-------------
wrap-for-bin.sh | 15 +++++++++++++++
3 files changed, 52 insertions(+), 13 deletions(-)
create mode 100644 wrap-for-bin.sh
diff --git a/.gitignore b/.gitignore
index ac02a58..5d32289 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,7 @@
/GIT-CFLAGS
/GIT-GUI-VARS
/GIT-VERSION-FILE
+/bin-wrappers/
/git
/git-add
/git-add--interactive
diff --git a/Makefile b/Makefile
index 5a0b3d4..77892ec 100644
--- a/Makefile
+++ b/Makefile
@@ -416,6 +416,15 @@ ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
# what 'all' will build but not install in gitexecdir
OTHER_PROGRAMS = git$X
+# what test wrappers are needed and 'install' will install, in bindir
+BINDIR_PROGRAMS_NEED_X += git
+BINDIR_PROGRAMS_NEED_X += git-upload-pack
+BINDIR_PROGRAMS_NEED_X += git-receive-pack
+BINDIR_PROGRAMS_NEED_X += git-upload-archive
+BINDIR_PROGRAMS_NEED_X += git-shell
+
+BINDIR_PROGRAMS_NO_X += git-cvsserver
+
# Set paths to tools early so that they can be used for version tests.
ifndef SHELL_PATH
SHELL_PATH = /bin/sh
@@ -1690,19 +1699,30 @@ endif
### Testing rules
-TEST_PROGRAMS += test-chmtime$X
-TEST_PROGRAMS += test-ctype$X
-TEST_PROGRAMS += test-date$X
-TEST_PROGRAMS += test-delta$X
-TEST_PROGRAMS += test-dump-cache-tree$X
-TEST_PROGRAMS += test-genrandom$X
-TEST_PROGRAMS += test-match-trees$X
-TEST_PROGRAMS += test-parse-options$X
-TEST_PROGRAMS += test-path-utils$X
-TEST_PROGRAMS += test-sha1$X
-TEST_PROGRAMS += test-sigchain$X
+TEST_PROGRAMS_NEED_X += test-chmtime
+TEST_PROGRAMS_NEED_X += test-ctype
+TEST_PROGRAMS_NEED_X += test-date
+TEST_PROGRAMS_NEED_X += test-delta
+TEST_PROGRAMS_NEED_X += test-dump-cache-tree
+TEST_PROGRAMS_NEED_X += test-genrandom
+TEST_PROGRAMS_NEED_X += test-match-trees
+TEST_PROGRAMS_NEED_X += test-parse-options
+TEST_PROGRAMS_NEED_X += test-path-utils
+TEST_PROGRAMS_NEED_X += test-sha1
+TEST_PROGRAMS_NEED_X += test-sigchain
+
+TEST_PROGRAMS = $(patsubst %,%$X,$(TEST_PROGRAMS_NEED_X))
-all:: $(TEST_PROGRAMS)
+test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X))
+
+all:: $(TEST_PROGRAMS) $(test_bindir_programs)
+
+bin-wrappers/%: wrap-for-bin.sh
+ @mkdir -p bin-wrappers
+ $(QUIET_GEN)sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+ -e 's|__GIT_EXEC_PATH__|$(shell pwd)|' \
+ -e 's|__PROG__|$(@F)|' < $< > $@ && \
+ chmod +x $@
# GNU make supports exporting all variables by "export" without parameters.
# However, the environment gets quite big, and some programs have problems
@@ -1763,11 +1783,13 @@ endif
gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
export gitexec_instdir
+install_bindir_programs := $(patsubst %,%$X,$(BINDIR_PROGRAMS_NEED_X)) $(BINDIR_PROGRAMS_NO_X)
+
install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
- $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver '$(DESTDIR_SQ)$(bindir_SQ)'
+ $(INSTALL) $(install_bindir_programs) '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
ifndef NO_PERL
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
@@ -1878,6 +1900,7 @@ clean:
$(LIB_FILE) $(XDIFF_LIB)
$(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
$(RM) $(TEST_PROGRAMS)
+ $(RM) -r bin-wrappers
$(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags cscope*
$(RM) -r autom4te.cache
$(RM) config.log config.mak.autogen config.mak.append config.status config.cache
diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh
new file mode 100644
index 0000000..ee2bc98
--- /dev/null
+++ b/wrap-for-bin.sh
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+# wrap-for-bin.sh: Template for git executable wrapper scripts
+# to run test suite against sandbox, but with only bindir-installed
+# executables in PATH. The Makefile copies this into various
+# files in bin-wrappers, substituting
+# __GIT_EXEC_PATH__ and __PROG__.
+
+GIT_EXEC_PATH="__GIT_EXEC_PATH__"
+GIT_TEMPLATE_DIR="__GIT_EXEC_PATH__/templates/blt"
+GITPERLLIB="__GIT_EXEC_PATH__/perl/blib/lib"
+PATH="__GIT_EXEC_PATH__/bin-wrappers:$PATH"
+export GIT_EXEC_PATH GIT_TEMPLATE_DIR GITPERLLIB PATH
+
+exec "${GIT_EXEC_PATH}/__PROG__" "$@"
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH v2 3/6] t/README: Document GIT_TEST_INSTALLED and GIT_TEST_EXEC_PATH
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-3-git-send-email-mmogilvi_git@miniinfo.net>
These were added without documentation in 2009-03-16 (6720721).
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
t/README | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/t/README b/t/README
index d8f6c7d..4e1d7dd 100644
--- a/t/README
+++ b/t/README
@@ -75,6 +75,19 @@ appropriately before running "make".
As the names depend on the tests' file names, it is safe to
run the tests with this option in parallel.
+You can also set the GIT_TEST_INSTALLED environment variable to
+the bindir of an existing git installation to test that installation.
+You still need to have built this git sandbox, from which various
+test-* support programs, templates, and perl libraries are used.
+If your installed git is incomplete, it will silently test parts of
+your built version instead.
+
+When using GIT_TEST_INSTALLED, you can also set GIT_TEST_EXEC_PATH to
+override the location of the dashed-form subcommands (what
+GIT_EXEC_PATH would be used for during normal operation).
+GIT_TEST_EXEC_PATH defaults to `$GIT_TEST_INSTALLED/git --exec-path`.
+
+
Skipping Tests
--------------
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH v2 2/6] t3409 t4107 t7406: use dashless commands
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-2-git-send-email-mmogilvi_git@miniinfo.net>
This is needed to allow test suite to run against a standard
install bin directory instead of GIT_EXEC_PATH.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
t/t3409-rebase-preserve-merges.sh | 6 +++---
t/t4107-apply-ignore-whitespace.sh | 20 ++++++++++----------
t/t7406-submodule-update.sh | 4 ++--
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/t/t3409-rebase-preserve-merges.sh b/t/t3409-rebase-preserve-merges.sh
index 297d165..8f785e7 100755
--- a/t/t3409-rebase-preserve-merges.sh
+++ b/t/t3409-rebase-preserve-merges.sh
@@ -32,14 +32,14 @@ export GIT_AUTHOR_EMAIL
test_expect_success 'setup for merge-preserving rebase' \
'echo First > A &&
git add A &&
- git-commit -m "Add A1" &&
+ git commit -m "Add A1" &&
git checkout -b topic &&
echo Second > B &&
git add B &&
- git-commit -m "Add B1" &&
+ git commit -m "Add B1" &&
git checkout -f master &&
echo Third >> A &&
- git-commit -a -m "Modify A2" &&
+ git commit -a -m "Modify A2" &&
git clone ./. clone1 &&
cd clone1 &&
diff --git a/t/t4107-apply-ignore-whitespace.sh b/t/t4107-apply-ignore-whitespace.sh
index 484654d..b04fc8f 100755
--- a/t/t4107-apply-ignore-whitespace.sh
+++ b/t/t4107-apply-ignore-whitespace.sh
@@ -136,37 +136,37 @@ void print_int(int num) {
EOF
test_expect_success 'file creation' '
- git-apply patch1.patch
+ git apply patch1.patch
'
test_expect_success 'patch2 fails (retab)' '
- test_must_fail git-apply patch2.patch
+ test_must_fail git apply patch2.patch
'
test_expect_success 'patch2 applies with --ignore-whitespace' '
- git-apply --ignore-whitespace patch2.patch
+ git apply --ignore-whitespace patch2.patch
'
test_expect_success 'patch2 reverse applies with --ignore-space-change' '
- git-apply -R --ignore-space-change patch2.patch
+ git apply -R --ignore-space-change patch2.patch
'
git config apply.ignorewhitespace change
test_expect_success 'patch2 applies (apply.ignorewhitespace = change)' '
- git-apply patch2.patch
+ git apply patch2.patch
'
test_expect_success 'patch3 fails (missing string at EOL)' '
- test_must_fail git-apply patch3.patch
+ test_must_fail git apply patch3.patch
'
test_expect_success 'patch4 fails (missing EOL at EOF)' '
- test_must_fail git-apply patch4.patch
+ test_must_fail git apply patch4.patch
'
test_expect_success 'patch5 applies (leading whitespace)' '
- git-apply patch5.patch
+ git apply patch5.patch
'
test_expect_success 'patches do not mangle whitespace' '
@@ -175,11 +175,11 @@ test_expect_success 'patches do not mangle whitespace' '
test_expect_success 're-create file (with --ignore-whitespace)' '
rm -f main.c &&
- git-apply patch1.patch
+ git apply patch1.patch
'
test_expect_success 'patch5 fails (--no-ignore-whitespace)' '
- test_must_fail git-apply --no-ignore-whitespace patch5.patch
+ test_must_fail git apply --no-ignore-whitespace patch5.patch
'
test_done
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 2d33d9e..8e2449d 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -14,8 +14,8 @@ submodule and "git submodule update --rebase/--merge" does not detach the HEAD.
compare_head()
{
- sha_master=`git-rev-list --max-count=1 master`
- sha_head=`git-rev-list --max-count=1 HEAD`
+ sha_master=`git rev-list --max-count=1 master`
+ sha_head=`git rev-list --max-count=1 HEAD`
test "$sha_master" = "$sha_head"
}
--
1.6.4.GIT
^ permalink raw reply related
* Re: [PATCH 3/8] git-merge-recursive-{ours,theirs}
From: Junio C Hamano @ 2009-11-30 6:21 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130911261405q6564d8f2o30b7d7fd6f708d05@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
>> - I think we should avoid adding the extra argument to ll_merge_fn() by
>> combining virtual_ancestor and favor into one "flags" parameter. If
>> you do so, we do not have to change the callsites again next time we
>> need to add new optional features that needs only a few bits.
>>
>> I vaguely recall that I did the counterpart of this patch that way
>> exactly for the above reason, but it is more than a year ago, so maybe
>> I didn't do it that way.
>
> You did do that, in fact,... <<rationale omitted>>
Think of the "flag" parameter as a mini "struct option". When you add a
feature to a function at or near the leaf level of call chains that are
potentially deep, you add one element to the option structure, and take
advantage of the fact that existing callers put a sane default value in
the new field, i.e. 0, by doing a "memset(&opt, 0, sizeof(opt))" already,
so that the callsites that do not even have to know about the new feature
will keep working the same old way without breakage. You saw this exact
pattern in the [1/8] patch in your series to cram new "favor this side"
information into an existing parameter.
As you mentioned, sometimes changing function signature is preferred to
catch semantic differences at compilation time. The report given by the
compiler of extra or missing parameter at the call site is a wonderful way
to find out that you forgot to convert them to the new semantics of the
function. This also helps when there is an in-flight patch that adds a
new callsite to the function whose semantics you are changing. The
semantic conflict is caught when compiling the result of a merge with a
branch with such a patch. It is a trick worth knowing about.
The approach however cuts both ways. When you are adding an optional
feature that is used only in a very few call sites, the semantic merge
conflict resulting from such a function signature change is rarely worth
it.
As long as you choose the default "no-op" value carefully enough so that
existing callers will naturally use it without modification, the old code
will work the way they did before the new optional feature was added. In
other words, "let's implement this as purely an opt-in feature" is often
preferrable over "let's force semantic conflict and compilation failure,
just in case existing callsites may also want to trigger this new
feature".
That is why [1/8] patch in your series uses 0 to mean "don't do the funny
'favor' trick, but just leave the conflicts there".
I've queued the series with minor fixes to 'pu' and pushed it out.
^ permalink raw reply
* [PATCH v2 6/6] INSTALL: document a simpler way to run uninstalled builds
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-6-git-send-email-mmogilvi_git@miniinfo.net>
The new scripts automatically saved in the bin-wrappers
directory allow you test run a build when you have neither installed
git nor tweaked environment variables. Mention this in INSTALL,
along with the slight performance issue of doing so.
This can be especially handy for manually testing
network-invoked git (from ssh, web servers, or similar), but
it is also handy with a plain command prompt.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
INSTALL | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/INSTALL b/INSTALL
index be504c9..ee718c6 100644
--- a/INSTALL
+++ b/INSTALL
@@ -39,7 +39,19 @@ Issues of note:
with --disable-transition option to avoid this.
- You can use git after building but without installing if you
- wanted to. Various git commands need to find other git
+ want to.
+
+ The simplest option for running some manual tests of a build
+ before installing it is to use the wrapper scripts that are built
+ and saved into `pwd`/bin-wrappers. Either invoke the scripts in
+ bin-wrappers using their full paths, put bin-wrappers in your
+ PATH, or copy/symlink just the bin-wrappers scripts into somewhere
+ already in your PATH. But this option is slightly inefficient,
+ so for a more permanent solution we recommend either installing
+ git (you can set a prefix to install right next to your
+ build directory), or use the alternative below.
+
+ Alternatively, various git commands need to find other git
commands and scripts to do their work, so you would need to
arrange a few environment variables to tell them that their
friends will be found in your built source area instead of at
--
1.6.4.GIT
^ permalink raw reply related
* Re: [PATCH v2 4/6] build dashless "bin-wrappers" directory similar to installed bindir
From: Junio C Hamano @ 2009-11-30 6:28 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: git
In-Reply-To: <1259561971-25730-5-git-send-email-mmogilvi_git@miniinfo.net>
Matthew Ogilvie <mmogilvi_git@miniinfo.net> writes:
> diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh
> new file mode 100644
> index 0000000..ee2bc98
> --- /dev/null
> +++ b/wrap-for-bin.sh
> @@ -0,0 +1,15 @@
> +#!/bin/sh
> +
> +# wrap-for-bin.sh: Template for git executable wrapper scripts
> +# to run test suite against sandbox, but with only bindir-installed
> +# executables in PATH. The Makefile copies this into various
> +# files in bin-wrappers, substituting
> +# __GIT_EXEC_PATH__ and __PROG__.
> +
> +GIT_EXEC_PATH="__GIT_EXEC_PATH__"
> +GIT_TEMPLATE_DIR="__GIT_EXEC_PATH__/templates/blt"
> +GITPERLLIB="__GIT_EXEC_PATH__/perl/blib/lib"
> +PATH="__GIT_EXEC_PATH__/bin-wrappers:$PATH"
> +export GIT_EXEC_PATH GIT_TEMPLATE_DIR GITPERLLIB PATH
> +
> +exec "${GIT_EXEC_PATH}/__PROG__" "$@"
Two issues, one minor and one not so minor but not grave:
- Everywhere else we seem to use "@@UPPERCASE_NAME@@" not
double-underscore as placeholders like the above.
- @@PROG@@ is under our control and it is easy for us to guarantee that
it won't have any funny letters, but GIT_EXEC_PATH is not. Is it safe
to do a simple-minded "sed" replacement, or does it need the usual sq
trick employed in the other replacement in our Makefile?
^ permalink raw reply
* git include
From: Rakotomandimby Mihamina @ 2009-11-30 6:41 UTC (permalink / raw)
To: git
Hi all,
I would like to track only *.ml files and ignore all others.
Is there a way to do that in .gitignore?
Thanks.
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 33 11 207 36
^ 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