* Re: Two minor glitches in git-gui
From: Shawn O. Pearce @ 2007-10-10 5:50 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git
In-Reply-To: <200710091121.59422.barra_cuda@katamail.com>
Michele Ballabio <barra_cuda@katamail.com> wrote:
> On Linux:
> 1. run git-gui
> 2. open edit->options dialog box
> 3. click on "select font". It will open the "choose font" box.
> 4. click on "options" box to give it focus.
> 5. return to the "choose font" box and try to choose a font.
>
> At this point, the "choose font" box won't react to my actions.
>
> The workaround is to iconify the "select font" dialog box and
> then restore it. Can someone reproduce this?
>
> I think I've seen a similar behaviour before, on git-gui's
> about window, but I'm not sure (it doesn't trigger anymore).
>
> The other problem is that it is possible to open the same
> "choose font" box many times (one is enough :).
I've actually seen this once before on X11. I thought that I had
it fixed. Apparently not. Its got to do with the fact that I have
a grab on the options dialog, and then I set another one on the
font dialog. Switching focus into the options dialog causes all
window to no longer go to the font dialog, but the option dialog
is the one with the focus.
I'll try to poke at it more and see if I can figure it out. But
I already thought I had. :-\
Thanks for the bug report.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Fixed crash in fetching remote tags when there is not tags.
From: Jeff King @ 2007-10-10 5:10 UTC (permalink / raw)
To: Alex Riesen; +Cc: Väinö Järvelä, git, Junio C Hamano
In-Reply-To: <20071009182043.GA2997@steel.home>
On Tue, Oct 09, 2007 at 08:20:43PM +0200, Alex Riesen wrote:
> Your test does not crash on my system and your fix is obviously bogus.
> Just take a look at the only call site of the tail_link_ref: ret
> cannot be NULL. alloc_ref will crash in memset, if this were the case.
His work is almost certainly on top of next, which crashes reliably with
the test and has an additional call site for tail_link_ref. Aside from
some trailing whitespace in the patch, I think his fix is reasonable.
-Peff
^ permalink raw reply
* Re: [msysGit] Re: [PATCH] git-gui: offer a list of recent repositories on startup
From: Shawn O. Pearce @ 2007-10-10 4:40 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, Git Mailing List, msysGit
In-Reply-To: <4A4F8FC7-E0AB-4C07-B4C8-AFE2EBD9C3DD@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Oct 9, 2007, at 1:43 PM, Johannes Schindelin wrote:
> >On Mon, 8 Oct 2007, Steffen Prohaska wrote:
> >
> >>commit a483fdd562d6c44d68a998224e0bbb17933b624a
> >>Author: Steffen Prohaska <prohaska@zib.de>
> >>Date: Mon Oct 8 08:25:47 2007 +0200
> >>
> >> git-gui: offer a list of recent repositories on startup
> >
> >May I suggest not putting this list into ~/.gitconfig, but rather
> >~/.gitguirc? It is not really a user-specific git configuration...
>
> git-gui already stores other options as global variables gui.*.
> (see git-gui/lib/option.tcl). I just added gui.recentrepo. The
> list of recent repos should go to wherever git-gui stores its options.
>
> Right now this is in ~/.gitconfig, if I understand correctly. Shawn?
Yes, that's correct.
An item on my todo list (see todo branch in git-gui.git) is to move
this into a ~/.gitguiconfig or something like that, but I was going
to keep it as a git-config style file so git-config can be used to
process its contents.
Until that task is complete I'd rather keep all of the "gui" options
in ~/.gitconfig (global) or .git/config (per-repository). When I
split stuff out to git-gui specific files I'll have to migrate the
entire "gui" section at once.
--
Shawn.
^ permalink raw reply
* stg branch command failures.
From: Aneesh Kumar @ 2007-10-10 3:31 UTC (permalink / raw)
To: Git Mailing List, catalin.marinas, kha
Hi,
Both the below commands doesn't work
stg branch --rename review test-large-file
stg branch -c review v2.6.23-rc9
It throws error
fatal: Needed a single revision
-aneesh
^ permalink raw reply
* Re: inexplicable failure to merge recursively across cherry-picks
From: Linus Torvalds @ 2007-10-10 2:54 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20071010015545.GA17336@lapse.madduck.net>
On Wed, 10 Oct 2007, martin f krafft wrote:
>
> There are five commits between mdadm-2.6.2 and
> mdadm-2.6.3+200709292116+4450e59 that affect Monitor.c:
>
> 01d9299
> e4dc510
> * 66f8bbb
> 98127a6
> 4450e59
>
> The third commit, the one with the asterisk is the one that
> I cherry-picked (as 845eef9); the other two cherries I picked do not
> touch Monitor.c.
Side note - run
gitk --merge
when you have a merge conflict, and it will basically show you the thing
graphically (ie history as it is relevant to the merge, and only to the
files that get conflicts).
But basically, both sides have modified the code *around* that line, and
they have modified it differently.
Do this in your partial merge tree on 'master':
git diff ...mdadm-2.6.3+200709292116+4450e59 Monitor.c
git diff mdadm-2.6.3+200709292116+4450e59... Monitor.c
which will show you the diff from the common base ancestor. And in
particular, it will show how one branch did this:
@@ -399,9 +401,8 @@ int Monitor(mddev_dev_t devlist,
struct mdstat_ent *mse;
for (mse=mdstat; mse; mse=mse->next)
if (mse->devnum != MAXINT &&
- (strcmp(mse->level, "raid1")==0 ||
- strcmp(mse->level, "raid5")==0 ||
- strcmp(mse->level, "multipath")==0)
+ (strcmp(mse->level, "raid0")!=0 &&
+ strcmp(mse->level, "linear")!=0)
) {
struct state *st = malloc(sizeof *st);
mdu_array_info_t array;
and the other one did
@@ -398,10 +402,9 @@ int Monitor(mddev_dev_t devlist,
if (scan) {
struct mdstat_ent *mse;
for (mse=mdstat; mse; mse=mse->next)
- if (mse->devnum != MAXINT &&
- (strcmp(mse->level, "raid1")==0 ||
- strcmp(mse->level, "raid5")==0 ||
- strcmp(mse->level, "multipath")==0)
+ if (mse->devnum != INT_MAX &&
+ (strcmp(mse->level, "raid0")!=0 &&
+ strcmp(mse->level, "linear")!=0)
) {
struct state *st = malloc(sizeof *st);
mdu_array_info_t array;
And now maybe git's behaviour makes more sense. See? You basically had two
different branches that made *almost* the same changes to the same area,
but not quite. So how is git to know which one was the *right* one to
pick? The one that changed the "if (mse->devnum != MAXINT &&" line, or the
one that left it alone?
> I branched master2 off 845eef9b~1, cherry-picked the first two
> commits that touch Monitor.c, cherry-picked all the commits
> 845eef9b..master into master2 and merge upstream...
Cherry-picking is immaterial. It doesn't matter how the changes come into
the tree. It doesn't matter what the history is. The only thing git cares
about is the content, and the end result.
Git knows that the two branches got to two different end results. They
were identical except for that one line, and it asks you to say which
branch was "right" wrt that one line.
In other words, git never looks at individual commits when trying to
merge. It doesn't try to figure out what the "meaning" of the changes are,
it purely looks at the content.
And btw, it *has* to work that way, because if you don't work that way,
then you get different results depending on which path the development
took (eg you might get different results if something was considered a
"revert", for example, or if something was split up into two patches on
one side but not the other etc etc).
But in this case it's pretty obvious: the commit from one side (the one
that changes MAXINT->INT_MAX: "Monitor.c s/MAXINT/INT_MAX/g") merged fine
into the result *except* for that one section that had touched the same
general area for other reasons. And that one area was seen as a conflict
because of those other reasons being in the same hunk.
And yes, in this case the "other reasons" happened to be cherry-picked and
thus "the same" on both sides, but that doesn't mean that they should have
been considered in any way special: the result of cherry-picking is
context-dependent and is a part of the history of the target, and does not
equate any kind of "identity" with the source. Cherry-picking is 100%
equivalent to re-doing the commit entirely, and for all git knows, there
was a reason why it wasn't done together with that s/MAXINT/INT_MAX/g
change.
(Not that git even thinks in those terms - git literally just says: "I
cannot resolve the _content_ independently and without understanding the
history and thinking behind the differences, so you'd better help me")
Linus
^ permalink raw reply
* Re: Problem with git-cvsimport
From: Michael Haggerty @ 2007-10-10 2:34 UTC (permalink / raw)
To: Eyvind Bernhardsen
Cc: Thomas Pasch, git, Jan Wielemaker, Gerald (Jerry) Carter, dev
In-Reply-To: <47065A5D-D170-4D11-A802-85376F97F8D2@orakel.ntnu.no>
Eyvind Bernhardsen wrote:
> On 9. okt.. 2007, at 15.21, Gerald (Jerry) Carter wrote:
>> I would actually plug using cvs2svn to convert directly to git.
>> See this thread for Michael's original announcement.
>>
>> http://marc.info/?l=git&m=118592701426175&w=2
>
> Seconded! I've tried git-cvsimport, parsecvs, fromcvs, and cvs2svn on
> my employer's many large CVS modules, and cvs2svn is the only one that
> has never mangled an import.
I'm glad this worked.
> That said, it is a work in progress, so there are some caveats:
>
> [...]
>
> * Tags each get a branch with a single commit, with the actual tag
> pointing to that commit. This makes it harder than necessary to figure
> out what the history looks like; gitk's default view won't show any
> tags, for example, since it only shows the master branch and not the
> single-commit tag branches.
I just fixed this in cvs2svn trunk r4213. Now it reuses a single branch
called 'refs/heads/TAG.FIXUP' whenever it needs to make a tag fixup
branch, and it resets that branch when done. (Resetting the tag fixup
branch changes it to 0000000000000000000000000000000000000000 but
doesn't really delete it; I don't know the ramifications of that but at
least it doesn't appear in gitk output any more.)
> * Branches all get a useless commit at their branch point. All branches
> from the main branch appear to be merged from the vendor branch (ie, the
> useless commit has the vendor branch as an extra parent), which might
> make sense to someone who knows what the vendor branch is for, but makes
> no sense to me. This combined with the previous point makes "gitk
> --all" look needlessly spaghetti-like if you have a slightly complicated
> CVS history.
I assume that the "useless commit" that you are referring to is the one
with log message "This commit was manufactured by cvs2svn to create
branch 'BRANCH'." Is that correct?
I'm not a git expert, so I don't know whether these commits are in fact
useless. But let me explain the reason I put them in and you can tell
me whether it is nonsense.
When you branch a file in CVS, CVS notes that the branch exists in the
file but doesn't record an author, log message, or timestamp. The
contents of a file just after it is branched are exactly the same as the
contents on the parent branch. Moreover, different files can be added
to a branch from different parent branches.
The intended purpose of the "useless commit" in the git output of
cvs2svn is to record the fact that a branch was created, to record
exactly which files exist on the branch at the time it was created, and
to record the source branches of the file on the branch.
I imagine that *if* a branch is created with a single parent branch, and
*if* each and every file from the parent branch is added to the new
branch, then it is possible that the "useless commit" could be omitted.
But this decision would require information that cvs2svn doesn't
currently have at that stage of the conversion, and keeping the
necessary records would be quite expensive.
But in the general case, it doesn't seem to me that the commits are
really useless. Am I wrong? If so, please tell me what should be
changed in the git-fast-import data that is output when a branch is
created (e.g., for the main-cvsrepos in the cvs2svn test suite).
Regarding the superfluous vendorbranch parent: vendor branches are an
obscure CVS feature for tracking upstream sources. The file contents on
the vendorbranch are typically exactly the same as that on trunk, and if
a branch is created while the vendorbranch is active, CVS doesn't record
whether the branch's parent was trunk or the vendorbranch. Haven't yet
built the heuristics into cvs2svn to make this decision more
intelligently, so sometimes "vendorbranch" is listed as a branch parent
when it could be omitted.
> To sum up, cvs2svn gets the important stuff right, but has some sharp
> corners you need to watch so you don't put an eye out.
Thanks for the feedback!
Michael
[1] http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html
^ permalink raw reply
* inexplicable failure to merge recursively across cherry-picks
From: martin f krafft @ 2007-10-10 1:55 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]
Hi folks,
I hope this is not a daily series of mine, being confused about Git
merging, but I've run my head against a wall again and before
I crush my skull, I'd prefer to reach out to you to help me regain
an understanding.
This is about the new mdadm for Debian packaging effort. You can
clone from git://git.debian.org/git/pkg-mdadm/mdadm-new.git and see
the repo at
http://git.debian.org/?p=pkg-mdadm/mdadm-new.git;a=summary. Do not
track as this repo is subject to change.
My master branch was last merged with upstream's mdadm-2.6.2 tag
(commit 263a535). Since then, I've committed a couple of changes to
master including three cherry-picks from upstream since mdadm-2.6.2.
I tagged upstream at the point which I want to merge into master:
mdadm-2.6.3+200709292116+4450e59. When I merge that tag into master,
I get a merge conflict on Monitor.c:
<<<<<<< HEAD:Monitor.c
if (mse->devnum != MAXINT &&
=======
if (mse->devnum != INT_MAX &&
>>>>>>> upstream:Monitor.c
There are five commits between mdadm-2.6.2 and
mdadm-2.6.3+200709292116+4450e59 that affect Monitor.c:
01d9299
e4dc510
* 66f8bbb
98127a6
4450e59
The third commit, the one with the asterisk is the one that
I cherry-picked (as 845eef9); the other two cherries I picked do not
touch Monitor.c.
The fifth/last commit (4450e59) is the one responsible for the
change which seems to cause the conflict. It is the *only* commit
since the common ancestor of *both* branches that touches the
conflicting lines.
The fourth commit (98127a6) inserts a single line at the top of the
file, so that's nothing that would cause a conflict.
To be honest, I can't explain it. But I didn't give up.
I branched master2 off 845eef9b~1, cherry-picked the first two
commits that touch Monitor.c, cherry-picked all the commits
845eef9b..master into master2 and merge upstream...
... to get exactly the same conflict in exactly the same line in
exactly the same file.
What is going on. Am I seriously overestimating Git's merging
capacities, or do I have a bug in my brain?
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"the only difference between shakespeare and you
was the size of his idiom list -- not the size of his vocabulary."
-- alan perlis
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Adding color to git-add--interactive
From: Jeff King @ 2007-10-09 23:40 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Git Mailing List
In-Reply-To: <91EBB71E-BB4E-4089-8C33-6B0C4A61223A@steelskies.com>
On Tue, Oct 09, 2007 at 02:06:31PM +0100, Jonathan del Strother wrote:
> For me at least, adding color would make the interactive mode far more
> readable. I hacked in basic color support (just coloring PROMPT &
> HEADER in list_and_choose, and the "Stage this hunk?" prompt) - which
> helped a lot - but then reached the limits of my perl knowledge. For
> instance, I can't see a sensible way of reusing git-svn's
> log_use_color function without importing the entire file, and I can't
> figure out how you'd go about diff-coloring the hunks. Is anyone with
> more perl knowledge than me interested in taking this on?
Why don't you post what you have, and we can make comments on it?
As far as reusing code from git-svn, there is a 'Git.pm' module in the
perl/ subdirectory. You can move the code there and 'use Git' in
git-add--interactive.perl (git-svn already uses it).
-Peff
^ permalink raw reply
* Re: [PATCH] git-config: respect other options after -l, most notably --file
From: Frank Lichtenheld @ 2007-10-09 22:49 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, git
In-Reply-To: <20071009125024.1259.qmail@d8e601127fe8d0.315fe32.mid.smarden.org>
On Tue, Oct 09, 2007 at 12:50:24PM +0000, Gerrit Pape wrote:
> When git-commit is seeing the -l|--list option, it stops reading the
> following command line options. So although they should be the same,
> the following commands act differently:
>
> git config --file ../repo2/.git/config -l
> git config -l --file ../repo2/.git/config
>
> This patch delays the 'list all variables' to after the command line
> options have been processed.
Note that I have posted a conflicting patch for the same problem some
days ago. I think my patch is more consistent with the behaviour for
other options.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] Support cvs via git-shell
From: Frank Lichtenheld @ 2007-10-09 22:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, hjemli, Jan Wielemaker, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710091531360.4174@racer.site>
On Tue, Oct 09, 2007 at 03:33:25PM +0100, Johannes Schindelin wrote:
> static struct commands {
> const char *name;
> int (*exec)(const char *me, char *arg);
> } cmd_list[] = {
> { "git-receive-pack", do_generic_cmd },
> { "git-upload-pack", do_generic_cmd },
> + { "cvs", do_cvs_cmd },
> { NULL },
Maybe this should also allow git-cvsserver for completeness' sake?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: removing content from git history
From: Bill Lear @ 2007-10-09 22:25 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Shawn O. Pearce, Linus Torvalds, Michael Hendricks, git
In-Reply-To: <20071009210235.GB9633@fieldses.org>
On Tuesday, October 9, 2007 at 17:02:35 (-0400) J. Bruce Fields writes:
>On Tue, Oct 09, 2007 at 03:58:57PM -0500, Bill Lear wrote:
>> As I understand this thread, it does not appear that a resolution
>> was reached. Our company has content in our central git repository
>> that we need to remove per a contractual obligation. I believe the
>> content in question is limited to one sub-directory, that has existed
>> since (or near to) the beginning of the repo, if that matters. We
>> obviously would just like to issue a "git nuke" operation and be done
>> with it, if that is available. Barring that, we could probably follow
>> reasonably simple steps to purge the content and rebuild the repo.
>>
>> So, what options do we have at present?
>
>Have you looked at git-filter-branch in a recent version of git? The
>man page has some good examples.
Ah, no, though I will do so. It is apparently not in the version
I have (1.5.2.4), but it is in 1.5.3.1. We'll give this a shot
and complain if we can't handle it.
Thank you.
Bill
^ permalink raw reply
* Re: [PATCH 0/6] manual: Fix or remove em dashes.
From: Thomas Adam @ 2007-10-09 22:02 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20071009215255.GB3146@ins.uni-bonn.de>
On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> Hello, and sorry, this patch should be number 6/6 of course.
>
> * Thomas Adam wrote on Tue, Oct 09, 2007 at 11:41:41PM CEST:
> > On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> > > em dashes were used inconsistently in the manual.
> > > This changes them to the way they are used in US English.
> >
> > I find this particular patch to be rather odd; there is nothing
> > invalid in the way the em-dashes are used.
>
> No, not invalid, just inconsistent usage in the manual.
>
> > Why is it US English is somehow de facto over, say, proper English?
> > :)
>
> Oh, that was written quoting from memory and experience. But here's a
> quote to back it up, from <http://en.wikipedia.org/wiki/Dash> as of now:
>
> | According to most American sources (e.g., The Chicago Manual of Style)
> | and to some British sources (e.g., The Oxford Guide to Style), an em
> | dash should always be set closed (not surrounded by spaces). But the
> | practice in many parts of the English-speaking world[...] sets it
> | open [...]
>
> No, I did not write that! ;-)
Well, I don't see why it needs to change, to be honest. I use
em-dashes all the time surrounded by spaces, as do many academics.
The fact that may here in the UK do not use the letter z in place of s
to satisfy the OSD is also of equal testament to this.
-- Thomas Adam
^ permalink raw reply
* Re: [PATCH 0/6] manual: Fix or remove em dashes.
From: Ralf Wildenhues @ 2007-10-09 21:52 UTC (permalink / raw)
To: Thomas Adam; +Cc: git
In-Reply-To: <18071eea0710091441n717c0a99p58a9b585d15cc778@mail.gmail.com>
Hello, and sorry, this patch should be number 6/6 of course.
* Thomas Adam wrote on Tue, Oct 09, 2007 at 11:41:41PM CEST:
> On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> > em dashes were used inconsistently in the manual.
> > This changes them to the way they are used in US English.
>
> I find this particular patch to be rather odd; there is nothing
> invalid in the way the em-dashes are used.
No, not invalid, just inconsistent usage in the manual.
> Why is it US English is somehow de facto over, say, proper English?
> :)
Oh, that was written quoting from memory and experience. But here's a
quote to back it up, from <http://en.wikipedia.org/wiki/Dash> as of now:
| According to most American sources (e.g., The Chicago Manual of Style)
| and to some British sources (e.g., The Oxford Guide to Style), an em
| dash should always be set closed (not surrounded by spaces). But the
| practice in many parts of the English-speaking world[...] sets it
| open [...]
No, I did not write that! ;-)
Cheers,
Ralf
^ permalink raw reply
* Re: Status of kha/experimental
From: Yann Dirson @ 2007-10-09 21:46 UTC (permalink / raw)
To: Catalin Marinas
Cc: Karl Hasselström, David Kågedal, Git Mailing List
In-Reply-To: <b0943d9e0710091410w1559f1a0yb5055182fd289646@mail.gmail.com>
On Tue, Oct 09, 2007 at 10:10:12PM +0100, Catalin Marinas wrote:
> On 07/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> > On 2007-10-07 22:18:44 +0100, Catalin Marinas wrote:
> >
> > > How stable is the kha/experimental branch? Since there are more and
> > > more bugs added to the tracking system, I'll have to start looking
> > > at them before a 0.14 release. Is it worth merging the
> > > kha/experimental now or we better wait for after 0.14?
> >
> > The idea is that experimental contains changes that need testing, but
> > may not yet be ready for your master. (They are generally safe,
> > though; I run StGit from my experimental branch at work, for example.)
> > When I decide that they are ready, I move them to safe. If there are
> > any patches you feel should be in safe rather than experimental, just
> > ask. Or you could just take them directly from experimental without
> > asking, of course. :-)
>
> OK. My plan is to merge kha/safe and have a look at what seems safer
> to merge from kha/experimental. Fix bugs (and freeze the current
> features). Release 0.14. Merge kha/experimental entirely post 0.14 and
> test/stabilize it over couple of months. How does this sound?
Sounds like a good time to bring back my refactoring patches from the
hydra patchset. I have not addressed yet the remarks that were voiced
at that time, and the hydra patch itself has not been completed, and
in fact the refactorings touch so many parts of the code that I can't
envision mantaining them outside the tree (in fact, I left them bitrot
for that very reason). If there is no other remarks than those
already posted as replies to the patchset, maybe we could consider
merging them soon after kha/experimental ?
That would require that I update them, but I'm not sure Karl would
want them in kha/experimental, since virtually any other patch causes
a conflict... The best situation would be that there would be a code
freeze at some time, during which I could update those patches without
too much perturbations, but that may be asking a lot :)
The ideal situation would be if we would make diffcore and merge aware
of a (de)indentation type of change. That's something I have felt the
need for since ages, but I'm unfortunately not going to find the time
to implement that anytime soon :)
Best regards,
--
Yann
^ permalink raw reply
* Re: [PATCH 0/6] manual: Fix or remove em dashes.
From: Thomas Adam @ 2007-10-09 21:41 UTC (permalink / raw)
To: Ralf Wildenhues, git
In-Reply-To: <20071009210530.GH31317@ins.uni-bonn.de>
Hello --
On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> em dashes were used inconsistently in the manual.
> This changes them to the way they are used in US English.
I find this particular patch to be rather odd; there is nothing
invalid in the way the em-dashes are used. Why is it US English is
somehow de facto over, say, proper English? :)
-- Thomas Adam
^ permalink raw reply
* [PATCH] exec_git_cmd: fix executing commands if path contains spaces
From: Steffen Prohaska @ 2007-10-09 21:39 UTC (permalink / raw)
To: j.sixt; +Cc: Johannes.Schindelin, git, Steffen Prohaska
In-Reply-To: <470BB44B.3030500@viscovery.net>
This patch fixed executing of non-builtins if installation
dir contains spaces. That is 'git var' works now.
The original patch is by Johannes Sixt <j.sixt@viscovery.net>.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
compat/mingw.c | 2 +-
exec_cmd.c | 2 +-
git-compat-util.h | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
Ok, this is what I created from the quick-fix. It works for
me in msysgit.
Should the patch be polished that it can be applied to git.git
or will we only apply it to 4msysgit?
If it should be polished, what would be the right way?
ifdef in exec_cmd.c?
Steffen
diff --git a/compat/mingw.c b/compat/mingw.c
index 6632192..0dd0cb0 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -196,7 +196,7 @@ void openlog(const char *ident, int option, int facility)
{
}
-static const char *quote_arg(const char *arg)
+const char *quote_arg(const char *arg)
{
/* count chars to quote */
int len = 0, n = 0;
diff --git a/exec_cmd.c b/exec_cmd.c
index 2a8e48b..4c7c7ca 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -132,7 +132,7 @@ int execv_git_cmd(const char **argv)
*/
tmp = argv[0];
- argv[0] = git_command;
+ argv[0] = quote_arg(git_command);
trace_argv_printf(argv, -1, "trace: exec:");
diff --git a/git-compat-util.h b/git-compat-util.h
index ba5a1a1..5276221 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -482,6 +482,7 @@ int mingw_socket(int domain, int type, int protocol);
#define fsync(x) 0
extern void quote_argv(const char **dst, const char **src);
+extern const char *quote_arg(const char *arg);
extern const char *parse_interpreter(const char *cmd);
extern __attribute__((noreturn)) int git_exit(int code);
--
1.5.3.mingw.1.13.g70ed-dirty
^ permalink raw reply related
* [PATCH 1/6] Fix some typos, punctuation, missing words, minor markup.
From: Ralf Wildenhues @ 2007-10-09 21:00 UTC (permalink / raw)
To: git
In-Reply-To: <20071009205755.GB31317@ins.uni-bonn.de>
---
Documentation/config.txt | 4 ++--
Documentation/git-diff.txt | 2 +-
Documentation/git-index-pack.txt | 2 +-
Documentation/git-merge-index.txt | 2 +-
Documentation/git-stash.txt | 2 +-
Documentation/git-svn.txt | 2 +-
Documentation/git-tag.txt | 2 +-
Documentation/git.txt | 4 ++--
Documentation/glossary.txt | 6 +++---
Documentation/user-manual.txt | 27 ++++++++++++++-------------
10 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 015910f..6afc1dc 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -188,7 +188,7 @@ core.worktree::
Set the path to the working tree. The value will not be
used in combination with repositories found automatically in
a .git directory (i.e. $GIT_DIR is not set).
- This can be overriden by the GIT_WORK_TREE environment
+ This can be overridden by the GIT_WORK_TREE environment
variable and the '--work-tree' command line option.
core.logAllRefUpdates::
@@ -588,7 +588,7 @@ merge.verbosity::
message if conflicts were detected. Level 1 outputs only
conflicts, 2 outputs conflicts and file changes. Level 5 and
above outputs debugging information. The default is level 2.
- Can be overriden by 'GIT_MERGE_VERBOSITY' environment variable.
+ Can be overridden by 'GIT_MERGE_VERBOSITY' environment variable.
merge.<driver>.name::
Defines a human readable name for a custom low-level
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index db2eb46..ce0f502 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -125,7 +125,7 @@ $ git diff topic...master <3>
+
<1> Changes between the tips of the topic and the master branches.
<2> Same as above.
-<3> Changes that occured on the master branch since when the topic
+<3> Changes that occurred on the master branch since when the topic
branch was started off it.
Limiting the diff output::
diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
index a8a7f6f..bf5c2bd 100644
--- a/Documentation/git-index-pack.txt
+++ b/Documentation/git-index-pack.txt
@@ -43,7 +43,7 @@ OPTIONS
a default name determined from the pack content. If
<pack-file> is not specified consider using --keep to
prevent a race condition between this process and
- gitlink::git-repack[1] .
+ gitlink::git-repack[1].
--fix-thin::
It is possible for gitlink:git-pack-objects[1] to build
diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt
index 17e9f10..b726ddf 100644
--- a/Documentation/git-merge-index.txt
+++ b/Documentation/git-merge-index.txt
@@ -40,7 +40,7 @@ If "git-merge-index" is called with multiple <file>s (or -a) then it
processes them in turn only stopping if merge returns a non-zero exit
code.
-Typically this is run with the a script calling git's imitation of
+Typically this is run with a script calling git's imitation of
the merge command from the RCS package.
A sample script called "git-merge-one-file" is included in the
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 5723bb0..c0147b9 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -57,7 +57,7 @@ stash@{1}: On master: 9cc0589... Add git-stash
show [<stash>]::
- Show the changes recorded in the stash as a diff between the the
+ Show the changes recorded in the stash as a diff between the
stashed state and its original parent. When no `<stash>` is given,
shows the latest one. By default, the command shows the diffstat, but
it will accept any format known to `git-diff` (e.g., `git-stash show
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index e157c6a..488e4b1 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -404,7 +404,7 @@ section because they affect the 'git-svn-id:' metadata line.
BASIC EXAMPLES
--------------
-Tracking and contributing to a the trunk of a Subversion-managed project:
+Tracking and contributing to the trunk of a Subversion-managed project:
------------------------------------------------------------------------
# Clone a repo (like git clone):
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 990ae4f..22a23bf 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -112,7 +112,7 @@ You really want to call the new version "X" too, 'even though'
others have already seen the old one. So just use "git tag -f"
again, as if you hadn't already published the old one.
-However, Git does *not* (and it should not)change tags behind
+However, Git does *not* (and it should not) change tags behind
users back. So if somebody already got the old tag, doing a "git
pull" on your tree shouldn't just make them overwrite the old
one.
diff --git a/Documentation/git.txt b/Documentation/git.txt
index abce801..bba8d54 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -325,7 +325,7 @@ For a more complete list of ways to spell object names, see
File/Directory Structure
------------------------
-Please see link:repository-layout.html[repository layout] document.
+Please see the link:repository-layout.html[repository layout] document.
Read link:hooks.html[hooks] for more details about each hook.
@@ -335,7 +335,7 @@ Higher level SCMs may provide and manage additional information in the
Terminology
-----------
-Please see link:glossary.html[glossary] document.
+Please see the link:glossary.html[glossary] document.
Environment Variables
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 3f7b1e4..d99fa19 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -52,8 +52,8 @@ GIT Glossary
[[def_cherry-picking]]cherry-picking::
In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
changes out of a series of changes (typically commits) and record them
- as a new series of changes on top of different codebase. In GIT, this is
- performed by "git cherry-pick" command to extract the change introduced
+ as a new series of changes on top of a different codebase. In GIT, this is
+ performed by the "git cherry-pick" command to extract the change introduced
by an existing <<def_commit,commit>> and to record it based on the tip
of the current <<def_branch,branch>> as a new commit.
@@ -347,7 +347,7 @@ This commit is referred to as a "merge commit", or sometimes just a
it as my origin branch head". And `git push
$URL refs/heads/master:refs/heads/to-upstream` means "publish my
master branch head as to-upstream branch at $URL". See also
- gitlink:git-push[1]
+ gitlink:git-push[1].
[[def_repository]]repository::
A collection of <<def_ref,refs>> together with an
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c7fdf25..6adeca7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1495,7 +1495,7 @@ Ensuring good performance
-------------------------
On large repositories, git depends on compression to keep the history
-information from taking up to much space on disk or in memory.
+information from taking up too much space on disk or in memory.
This compression is not performed automatically. Therefore you
should occasionally run gitlink:git-gc[1]:
@@ -1920,7 +1920,7 @@ As with git-fetch, git-push will complain if this does not result in
a <<fast-forwards,fast forward>>. Normally this is a sign of
something wrong. However, if you are sure you know what you're
doing, you may force git-push to perform the update anyway by
-proceeding the branch name by a plus sign:
+preceding the branch name by a plus sign:
-------------------------------------------------
$ git push ssh://yourserver.com/~you/proj.git +master
@@ -2040,7 +2040,7 @@ $ git branch --track test origin/master
$ git branch --track release origin/master
-------------------------------------------------
-These can be easily kept up to date using gitlink:git-pull[1]
+These can be easily kept up to date using gitlink:git-pull[1].
-------------------------------------------------
$ git checkout test && git pull
@@ -2132,7 +2132,7 @@ changes are in a specific branch, use:
$ git log linux..branchname | git-shortlog
-------------------------------------------------
-To see whether it has already been merged into the test or release branches
+To see whether it has already been merged into the test or release branches,
use:
-------------------------------------------------
@@ -2145,12 +2145,12 @@ or
$ git log release..branchname
-------------------------------------------------
-(If this branch has not yet been merged you will see some log entries.
+(If this branch has not yet been merged, you will see some log entries.
If it has been merged, then there will be no output.)
Once a patch completes the great cycle (moving from test to release,
then pulled by Linus, and finally coming back into your local
-"origin/master" branch) the branch for this change is no longer needed.
+"origin/master" branch), the branch for this change is no longer needed.
You detect this when the output from:
-------------------------------------------------
@@ -2479,7 +2479,7 @@ $ git checkout -b mywork-new origin
$ gitk origin..mywork &
-------------------------------------------------
-And browse through the list of patches in the mywork branch using gitk,
+and browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
cherry-pick, and possibly modifying them as you go using commit --amend.
The gitlink:git-gui[1] command may also help as it allows you to
@@ -2739,7 +2739,7 @@ others:
- Git can quickly determine whether two objects are identical or not,
just by comparing names.
-- Since object names are computed the same way in ever repository, the
+- Since object names are computed the same way in every repository, the
same content stored in two repositories will always be stored under
the same name.
- Git can detect errors when it reads an object, by checking that the
@@ -3425,9 +3425,10 @@ The Workflow
------------
High-level operations such as gitlink:git-commit[1],
-gitlink:git-checkout[1] and git-reset[1] work by moving data between the
-working tree, the index, and the object database. Git provides
-low-level operations which perform each of these steps individually.
+gitlink:git-checkout[1] and gitlink:git-reset[1] work by moving data
+between the working tree, the index, and the object database. Git
+provides low-level operations which perform each of these steps
+individually.
Generally, all "git" operations work on the index file. Some operations
work *purely* on the index file (showing the current state of the
@@ -3704,7 +3705,7 @@ Merging multiple trees, continued
---------------------------------
Sadly, many merges aren't trivial. If there are files that have
-been added.moved or removed, or if both branches have modified the
+been added, moved or removed, or if both branches have modified the
same file, you will be left with an index tree that contains "merge
entries" in it. Such an index tree can 'NOT' be written out to a tree
object, and you will have to resolve any such merge clashes using
@@ -4061,7 +4062,7 @@ $ git branch new # create branch "new" starting at current HEAD
$ git branch -d new # delete branch "new"
-----------------------------------------------
-Instead of basing new branch on current HEAD (the default), use:
+Instead of basing a new branch on current HEAD (the default), use:
-----------------------------------------------
$ git branch new test # branch named "test"
--
1.5.3.3.g34c6d
^ permalink raw reply related
* [PATCH 0/6] Some small documentation fixes
From: Ralf Wildenhues @ 2007-10-09 20:57 UTC (permalink / raw)
To: git
Hello git list,
Being rather new to git, I've read the manual, and found some
minor issues. Posting them in the hope that they are useful,
and that you don't mind me splitting them up in small pieces.
Please Cc: me on replies.
Cheers,
Ralf, thanks for a cool tool :-)
^ permalink raw reply
* [PATCH 2/6] Fix wording in push definition.
From: Ralf Wildenhues @ 2007-10-09 21:01 UTC (permalink / raw)
To: git
In-Reply-To: <20071009205755.GB31317@ins.uni-bonn.de>
Make the definition of push in the glossary readable.
---
Documentation/glossary.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index d99fa19..5645177 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -301,8 +301,8 @@ This commit is referred to as a "merge commit", or sometimes just a
[[def_push]]push::
Pushing a <<def_branch,branch>> means to get the branch's
<<def_head_ref,head ref>> from a remote <<def_repository,repository>>,
- find out if it is an ancestor to the branch's local
- head ref is a direct, and in that case, putting all
+ find out if it is a direct ancestor to the branch's local
+ head ref, and in that case, putting all
objects, which are <<def_reachable,reachable>> from the local
head ref, and which are missing from the remote
repository, into the remote
--
1.5.3.3.g34c6d
^ permalink raw reply related
* [PATCH 3/6] manual: Fix example finding commits referencing given content.
From: Ralf Wildenhues @ 2007-10-09 21:02 UTC (permalink / raw)
To: git
In-Reply-To: <20071009205755.GB31317@ins.uni-bonn.de>
If I'm handed a file, then it typically lives outside the
working directory. git-log only operates on in-tree files,
so the first 'filename' should be an in-tree one, or it should
look at all files. This patch does the latter, so it would
also find renamed files. However, it is also slower.
---
Documentation/user-manual.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 6adeca7..2b1b324 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -926,7 +926,7 @@ file such that it contained the given content either before or after the
commit. You can find out with this:
-------------------------------------------------
-$ git log --raw --abbrev=40 --pretty=oneline -- filename |
+$ git log --raw --abbrev=40 --pretty=oneline |
grep -B 1 `git hash-object filename`
-------------------------------------------------
--
1.5.3.3.g34c6d
^ permalink raw reply related
* Re: Status of kha/experimental
From: Catalin Marinas @ 2007-10-09 21:10 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Yann Dirson, David Kågedal, Git Mailing List
In-Reply-To: <20071007213307.GA32210@diana.vm.bytemark.co.uk>
On 07/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-10-07 22:18:44 +0100, Catalin Marinas wrote:
>
> > How stable is the kha/experimental branch? Since there are more and
> > more bugs added to the tracking system, I'll have to start looking
> > at them before a 0.14 release. Is it worth merging the
> > kha/experimental now or we better wait for after 0.14?
>
> The idea is that experimental contains changes that need testing, but
> may not yet be ready for your master. (They are generally safe,
> though; I run StGit from my experimental branch at work, for example.)
> When I decide that they are ready, I move them to safe. If there are
> any patches you feel should be in safe rather than experimental, just
> ask. Or you could just take them directly from experimental without
> asking, of course. :-)
OK. My plan is to merge kha/safe and have a look at what seems safer
to merge from kha/experimental. Fix bugs (and freeze the current
features). Release 0.14. Merge kha/experimental entirely post 0.14 and
test/stabilize it over couple of months. How does this sound?
--
Catalin
^ permalink raw reply
* Re: Proposed command: git-sync
From: Pierre Habouzit @ 2007-10-09 21:08 UTC (permalink / raw)
To: Sven Herzberg; +Cc: git
In-Reply-To: <470BD5CF.9050201@imendio.com>
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
On Tue, Oct 09, 2007 at 07:26:07PM +0000, Sven Herzberg wrote:
> I really regularly find myself typing git pull directly after git push.
> That's why I write a small shell script that might be added to the stock
> git distribution.
this is the default behavior of git push in recent gits.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 0/6] manual: Fix or remove em dashes.
From: Ralf Wildenhues @ 2007-10-09 21:05 UTC (permalink / raw)
To: git
In-Reply-To: <20071009205755.GB31317@ins.uni-bonn.de>
em dashes were used inconsistently in the manual.
This changes them to the way they are used in US English.
---
Documentation/user-manual.txt | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 38e35d8..d99adc6 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2756,7 +2756,7 @@ There are four different types of objects: "blob", "tree", "commit", and
"blob" objects into a directory structure. In addition, a tree object
can refer to other tree objects, thus creating a directory hierarchy.
- A <<def_commit_object,"commit" object>> ties such directory hierarchies
- together into a <<def_DAG,directed acyclic graph>> of revisions - each
+ together into a <<def_DAG,directed acyclic graph>> of revisions--each
commit contains the object name of exactly one tree designating the
directory hierarchy at the time of the commit. In addition, a commit
refers to "parent" commit objects that describe the history of how we
@@ -3029,7 +3029,7 @@ There are also other situations that cause dangling objects. For
example, a "dangling blob" may arise because you did a "git add" of a
file, but then, before you actually committed it and made it part of the
bigger picture, you changed something else in that file and committed
-that *updated* thing - the old state that you added originally ends up
+that *updated* thing--the old state that you added originally ends up
not being pointed to by any commit or tree, so it's now a dangling blob
object.
@@ -3044,7 +3044,7 @@ up pointing to them, so they end up "dangling" in your repository.
Generally, dangling objects aren't anything to worry about. They can
even be very useful: if you screw something up, the dangling objects can
be how you recover your old tree (say, you did a rebase, and realized
-that you really didn't want to - you can look at what dangling objects
+that you really didn't want to--you can look at what dangling objects
you have, and decide to reset your head to some old dangling state).
For commits, you can just use:
@@ -3088,10 +3088,10 @@ $ git prune
------------------------------------------------
and they'll be gone. But you should only run "git prune" on a quiescent
-repository - it's kind of like doing a filesystem fsck recovery: you
+repository--it's kind of like doing a filesystem fsck recovery: you
don't want to do that while the filesystem is mounted.
-(The same is true of "git-fsck" itself, btw - but since
+(The same is true of "git-fsck" itself, btw, but since
git-fsck never actually *changes* the repository, it just reports
on what it found, git-fsck itself is never "dangerous" to run.
Running it while somebody is actually changing the repository can cause
@@ -3483,7 +3483,7 @@ You write your current index file to a "tree" object with the program
$ git write-tree
-------------------------------------------------
-that doesn't come with any options - it will just write out the
+that doesn't come with any options--it will just write out the
current index into the set of tree objects that describe that state,
and it will return the name of the resulting top-level tree. You can
use that tree to re-generate the index at any time by going in the
@@ -3494,7 +3494,7 @@ object database -> index
~~~~~~~~~~~~~~~~~~~~~~~~
You read a "tree" file from the object database, and use that to
-populate (and overwrite - don't do this if your index contains any
+populate (and overwrite--don't do this if your index contains any
unsaved state that you might want to restore later!) your current
index. Normal operation is just
@@ -3542,7 +3542,7 @@ Tying it all together
To commit a tree you have instantiated with "git-write-tree", you'd
create a "commit" object that refers to that tree and the history
-behind it - most notably the "parent" commits that preceded it in
+behind it--most notably the "parent" commits that preceded it in
history.
Normally a "commit" has one parent: the previous state of the tree
@@ -3685,7 +3685,7 @@ Once you know the three trees you are going to merge (the one "original"
tree, aka the common tree, and the two "result" trees, aka the branches
you want to merge), you do a "merge" read into the index. This will
complain if it has to throw away your old index contents, so you should
-make sure that you've committed those - in fact you would normally
+make sure that you've committed those--in fact you would normally
always do a merge against your last commit (which should thus match what
you have in your current index anyway).
@@ -3957,7 +3957,7 @@ Two things are interesting here:
- `get_sha1()` returns 0 on _success_. This might surprise some new
Git hackers, but there is a long tradition in UNIX to return different
- negative numbers in case of different errors -- and 0 on success.
+ negative numbers in case of different errors--and 0 on success.
- the variable `sha1` in the function signature of `get_sha1()` is `unsigned
char \*`, but is actually expected to be a pointer to `unsigned
--
1.5.3.3.g34c6d
^ permalink raw reply related
* [PATCH 5/6] manual: use 'URL' instead of 'url'.
From: Ralf Wildenhues @ 2007-10-09 21:03 UTC (permalink / raw)
To: git
In-Reply-To: <20071009205755.GB31317@ins.uni-bonn.de>
Just for consistency, use the spelling URL everywhere.
---
Documentation/user-manual.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index df482e6..38e35d8 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1782,7 +1782,7 @@ $ git clone /path/to/repository
$ git pull /path/to/other/repository
-------------------------------------------------
-or an ssh url:
+or an ssh URL:
-------------------------------------------------
$ git clone ssh://yourhost/~you/repository
@@ -1843,7 +1843,7 @@ Exporting a git repository via the git protocol
This is the preferred method.
If someone else administers the server, they should tell you what
-directory to put the repository in, and what git:// url it will appear
+directory to put the repository in, and what git:// URL it will appear
at. You can then skip to the section
"<<pushing-changes-to-a-public-repository,Pushing changes to a public
repository>>", below.
@@ -1880,8 +1880,8 @@ $ chmod a+x hooks/post-update
gitlink:git-update-server-info[1], and the documentation
link:hooks.html[Hooks used by git].)
-Advertise the url of proj.git. Anybody else should then be able to
-clone or pull from that url, for example with a command line like:
+Advertise the URL of proj.git. Anybody else should then be able to
+clone or pull from that URL, for example with a command line like:
-------------------------------------------------
$ git clone http://yourserver.com/~you/proj.git
--
1.5.3.3.g34c6d
^ permalink raw reply related
* [PATCH 4/6] manual: add some markup.
From: Ralf Wildenhues @ 2007-10-09 21:03 UTC (permalink / raw)
To: git
In-Reply-To: <20071009205755.GB31317@ins.uni-bonn.de>
---
Documentation/glossary.txt | 2 +-
Documentation/user-manual.txt | 10 +++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 5645177..fc18744 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -281,7 +281,7 @@ This commit is referred to as a "merge commit", or sometimes just a
[[def_pickaxe]]pickaxe::
The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore
routines that help select changes that add or delete a given text
- string. With the --pickaxe-all option, it can be used to view the full
+ string. With the `--pickaxe-all` option, it can be used to view the full
<<def_changeset,changeset>> that introduced or removed, say, a
particular line of text. See gitlink:git-diff[1].
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 2b1b324..df482e6 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1536,7 +1536,7 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
Dangling objects are not a problem. At worst they may take up a little
extra disk space. They can sometimes provide a last-resort method for
recovering lost work--see <<dangling-objects>> for details. However, if
-you wish, you can remove them with gitlink:git-prune[1] or the --prune
+you wish, you can remove them with gitlink:git-prune[1] or the `--prune`
option to gitlink:git-gc[1]:
-------------------------------------------------
@@ -1555,7 +1555,7 @@ Recovering lost changes
Reflogs
^^^^^^^
-Say you modify a branch with gitlink:git-reset[1] --hard, and then
+Say you modify a branch with `gitlink:git-reset[1] --hard`, and then
realize that the branch was the only reference you had to that point in
history.
@@ -1684,7 +1684,7 @@ $ git pull
More generally, a branch that is created from a remote branch will pull
by default from that branch. See the descriptions of the
branch.<name>.remote and branch.<name>.merge options in
-gitlink:git-config[1], and the discussion of the --track option in
+gitlink:git-config[1], and the discussion of the `--track` option in
gitlink:git-checkout[1], to learn how to control these defaults.
In addition to saving you keystrokes, "git pull" also helps you by
@@ -2412,7 +2412,7 @@ $ git rebase --continue
and git will continue applying the rest of the patches.
-At any point you may use the --abort option to abort this process and
+At any point you may use the `--abort` option to abort this process and
return mywork to the state it had before you started the rebase:
-------------------------------------------------
@@ -2481,7 +2481,7 @@ $ gitk origin..mywork &
and browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
-cherry-pick, and possibly modifying them as you go using commit --amend.
+cherry-pick, and possibly modifying them as you go using `commit --amend`.
The gitlink:git-gui[1] command may also help as it allows you to
individually select diff hunks for inclusion in the index (by
right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
--
1.5.3.3.g34c6d
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox