* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Johannes Schindelin @ 2007-08-04 11:46 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Junio C Hamano, Steven Grimm, Ismail Dönmez, git
In-Reply-To: <20070804133923.eb84a308.tihirvon@gmail.com>
Hi,
On Sat, 4 Aug 2007, Timo Hirvonen wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>
> > It might be more worthwhile to research what other "Text-ish
> > lightweight mark-up" systems are availble, and if there is one
> > that is more efficient and can go to at least html and man,
> > one-time convert our documentation source to that format using
> > your Perl magic. The minimum requirements are:
> >
> > * The source is readable without too much mark-up distraction;
> >
> > * Can go to roff -man;
> >
> > * Can go to html.
>
> I used asciidoc too but it was really PITA to install and use
I disagree. Whenever I had the need, installing asciidoc was pretty
swift. No problems at all.
> so I wrote a small tool (ttman) in C which converts .txt files directly
> to man pages.
I was impressed! Right until I saw that
- it rolls its own parser/lexer without using bison/flex, which
makes it much longer than necessary,
- it looks like a perl script doing the same job would have been
even smaller yet, and
- the syntax is nowhere near asciidoc syntax.
The last point is really something to keep in mind. We have not only a
large amount of documentation in that format, which would have to be
converted -- accurately! -- to the new format. We also have quite a
number of documentation contributors which would have to be "migrated"
towards the new format.
I think that Steven's goal is a laudable one. We have the 'man' and
'html' branch mainly for the reason that some cannot/wantnot install
asciidoc.
But I think that we do not have to have a _complete_ replacement. I, for
one, would be happy to see a small script which converts all the man pages
more or less accurately, with the main goal to be _fast_ and having as
few dependencies as possible (I think Perl is okay here).
For official releases, I'd still want to rely on asciidoc.
Ciao,
Dscho
^ permalink raw reply
* Re: Help a sed noob
From: Jeff King @ 2007-08-04 11:50 UTC (permalink / raw)
To: martin f krafft; +Cc: Nguyen Thai Ngoc Duy, Git Mailing List
In-Reply-To: <20070804103126.GA28402@lapse.madduck.net>
On Sat, Aug 04, 2007 at 12:31:26PM +0200, martin f krafft wrote:
> also sprach Nguyen Thai Ngoc Duy <pclouds@gmail.com> [2007.08.04.0122 +0200]:
> > sed -ne '/^URL: */{
> > s///p
> > q
> > }' "$GIT_DIR/remotes/$1"
>
> Looks like it prints the first matching line:
>
> grep '^URL: *' | head -1
No, it prints everything _except_ "URL: *" from the first matching line.
-Peff
^ permalink raw reply
* Re: git-gui console app ?
From: Erik Colson @ 2007-08-04 11:53 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0708041225520.14781@racer.site>
On Sat, Aug 04, 2007 at 12:29:03PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 4 Aug 2007, Erik Colson wrote:
>
> > git-gui is a nice application and I like to use it while developping.
> > However as probably a lot of developpers do, I regularly code in Emacs
> > from a distant ssh client.
> > Therefor I'd want to find some app like git-gui running in console...
> > Does this exist or is there a project in development ?
>
> There is tig. http://repo.or.cz/w/tig.git
>
> It is something similar to gitk but based on curses, so it is a viewer for
> now. But I do not see any fundamental reason why it should not be
> possible to teach it many of the tricks git-gui does.
>
> Just fork it (you can even do that on repo.or.cz; tig.git is mirrored
> there), and give it a go!
Thanks for the very fast answer. I'm currently trying it out. However
I can't figure out how to view the 'changed but not updated' in diff
format...
Any clue what I'm missing ?
--
Erik
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Jeff King @ 2007-08-04 12:02 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <854pjfin68.fsf@lola.goethe.zz>
On Sat, Aug 04, 2007 at 12:55:43PM +0200, David Kastrup wrote:
> A local branch is one with a local branch head. In contrast, checking
> out a remote branch, while possible, leaves one with a detached head.
Yes, if by "remote branch" you mean a "remote tracking branch".
> "remote-tracking" basically means that git-pull will update the branch
> according to changes in the remote repository.
A "remote tracking branch" is a branch in refs/remotes/* that is updated
by _git-fetch_ (which is in turn called by git-pull) to track a remote's
position of a branch.
A local branch which tracks a remote branch (I don't recall seeing the
phrase "remote-tracking" -- where did this come from?) has the correct
magic in .git/config to pull from a specific remote branch when
'git-pull' is given without arguments.
> Creating a branch using git-branch or git-checkout will always create
> a local branch which may or may not be remote-tracking according to
> the --no-track or --track options.
Yes, although again, I think calling it a "remote-tracking branch" to
mean "a local branch that tracks a remote branch" is confusingly similar
to the more common "remote tracking branch" to mean "a branch in
refs/remotes that track's a remote repository's idea of a branch".
> So there are basically three types of branches in a repository that I
> can see:
>
> local branch, not remote-tracking
> local branch, remote-tracking
> remote branch, remote-tracking
No, the remote branch is not remote-tracking in the sense that you
defined above; it is not meant to be pulled into.
I think you are confused by two uses of the word "track". In one case,
we mean that git-fetch will remember the remote's idea of a branch in
refs/remotes/<remote>/<branch>. In another, we mean that a local branch
will default to pulling from a particular (remote,branch) combination.
> So the terminology seems fuzzy at the moment, and my attempt to clear
> it up might not be the preferred way of doing it.
Yes, it is very fuzzy. Using "track" for the concept of a local branch
defaulting to a particular (remote,branch) pair for git-pull is, I
think, more recent and less used. If there were another term for this,
it might be more clear.
-Peff
^ permalink raw reply
* Re: git-gui console app ?
From: Jeff King @ 2007-08-04 12:03 UTC (permalink / raw)
To: git
In-Reply-To: <20070804115331.GA2962@Mac2.local>
On Sat, Aug 04, 2007 at 01:53:31PM +0200, Erik Colson wrote:
> Thanks for the very fast answer. I'm currently trying it out. However
> I can't figure out how to view the 'changed but not updated' in diff
> format...
git-diff ?
By default, it will show the changes between your working tree and the
index (i.e., changed but not updated). You can show the diff of "updated
but not commited" with "git-diff --cached".
-Peff
^ permalink raw reply
* Re: [RFC (take 3)] Git User's Survey 2007
From: Jakub Narebski @ 2007-08-04 12:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070804054157.GN20052@spearce.org>
On Sat, 4 August 2007, Shawn O. Pearce wrote:
>> How you use GIT
>>
>> 1. Do you use GIT for work, unpaid projects, or both?
>> work/unpaid projects/both/none(*)
>> (*)I use git to interact with some project I'm interested in
>
> I don't understand the (*) point here. What's the middle ground
> between work and unpaid projects? Paid projects that aren't work?
> Isn't that the definition of work? Very confused...
I meant here to add an option for people who use git (or git web
interface) only for tracking some project(s). For example what if I'm
tracking git.git repository, but do not have repositories with my own
projects? It is a bit of gray area if you publish your own changes to
somebody else project if it is "none" or "unpaid projects".
But perhaps it is too vague distinction. One can always not to answer
this question, if one does not have any projects, and do not use git
for work.
I'll think about removing this option.
>> 8. Which porcelains do you use?
>> (zero or more: multiple choice)
>> - core-git, cogito, StGIT, pg, guilt, other
>
> I really hope nobody chooses pg. I haven't supported it in a very
> long time. Might be a good idea to keep it in this survey just to
> make sure its 0, then omit it from the next survey. :-)
I'd use "core-git, cogito (deprecated), StGIT, guilt, pg (deprecated),
other", then.
>> Changes in GIT (since year ago, or since you started using it)
> ...
>> 5. Which of the new features do you use?
>> (zero or more: multiple choice)
>> - git-gui, bundle, eol conversion, gitattributes,
>> submodules, worktree, release notes, user's manual,
>> reflog, stash, shallow clone, detached HEAD, fast-import,
>> mergetool, interactive rebase, commit template, blame
>> improvements, other (not mentioned here)
>
> Wow.
>
> This community has accomplished a lot since the last survey.
> That list covers most of the major items over the past year, if
> not all of them. But I'd never really seen it all written out
> in such a concise list; there's so much blood, sweat and tears
> in those topics from everyone on (and off) this mailing list.
> Reading it now is bringing back a lot of memories for me.
>
> Sorry, I just had a very emotional reaction to seeing how much we
> have managed to accomplish in so little time. Thank you to everyone
> who has made this list possible!
And that are only user visible features! This list does not include
improvements to git "engine", like better support for huge files, or
"thickening" downloaded pack during fetch, or non-feature improvements
to git UI, like git-gc, git-remote, changes to git-diff, git-log,
git-show, making separate remote layout default, etc.
On the other hand this list might include some features which were
present at the time of previous (first) survey, like reflog, but were
not enabled by default and had almost no porcelain support.
>> Getting help, staying in touch
>>
>> 1. Have you tried to get GIT help from other people?
>> - yes/no
>> 2. If yes, did you get these problems resolved quickly
>> and to your liking?
>> - yes/no
>
> Possible new item:
>
> Would commerical (paid) support from a support vendor be of
> interest to you/your organization?
This is a very good idea. I'd add this question to the list.
> I think Sam Vilain was suggesting he sell Git support
> to my day-job company, so my coworkers could call him and ask him
> questions, and he could ask me those same questions on #git, then
> mail me a 6-pack of beer[*1*] for my troubles. :)
>
>
> [*1*] And sadly I don't drink beer...
So what would be the proper compensation? Bottle of wine? Bar of
chocolate? ;-p
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Jakub Narebski @ 2007-08-04 12:14 UTC (permalink / raw)
To: git
In-Reply-To: <854pjfin68.fsf@lola.goethe.zz>
[Cc: David Kastrup <dak@gnu.org>, git@vger.kernel.org]
David Kastrup wrote:
> The way to add a remote branch basically is not via git-branch or
> git-checkout -b (those always create local branches), but by editing
> .git/config.
Or by using "git remote" command.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Help a sed noob
From: martin f krafft @ 2007-08-04 12:18 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, Git Mailing List
In-Reply-To: <20070804115003.GA9716@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
also sprach Jeff King <peff@peff.net> [2007.08.04.1350 +0200]:
> No, it prints everything _except_ "URL: *" from the first matching line.
I am convinced we could submit this to the Obfuscated Code Contest.
:)
The behaviour is absolutely unclear from the manpage and defies my
logic. Can you elaborate a bit, even though this is off-topic?
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
kill ugly radio
-- frank zappa
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: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-04 12:19 UTC (permalink / raw)
To: Steven Grimm; +Cc: Sam Ravnborg, Junio C Hamano, Ismail Dönmez, git
In-Reply-To: <46B45B1E.5020104@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> Sam Ravnborg wrote:
>> Never looked at Ascii-doc... but how about finding the loopholes
>> in Ascii-doc to make it 10x faster?
>> That would benefit a larger user-base than just doing-it-ourself.
>>
>
> Because AsciiDoc is only half of the toolchain we use. (Though in your
> defense, I made the mistake of only mentioning AsciiDoc by name,
> rather than "the AsciiDoc toolchain.") We run asciidoc's output
> through xmlto, which is just as slow and is a highly general piece of
> software for doing arbitrary transformations of XML documents. I won't
> say it's impossible to speed up xmlto as well, of course, but it's
> probably an order of magnitude more work than implementing a new
> parser/renderer for our .txt files.
Personally, I think it would make sense to move to a different
documentation system, or at least a different organization. The
problem with the current layout is that it is basically flat.
A system such as info, in contrast, is hierarchical, and organized
with indexes and cross references making it much easier to find
things. More importantly, it makes it possible to put things into
perspective: which commands are porcelain, which are plumbing? What
do you do in a typical workflow? What are the related internal data
structures? Where are they documented? Can I print or navigate a
complete PDF document explaining the whole system?
The manual pages of git have a high quality, but they remain manual
pages: they are all standalone, not putting the tool into a context or
hierarchy. While the user manual is a place to start, it is more or
less added as an afterthought: it does not structure the available
documentation.
For Texinfo there is a large number of backends, and there are also
usable reader plugins (Tkinfo, and the presumably embeddable GNOME
"yelp" also displays info files and the embedded links, and of course
the wonderful Emacs info browser) for things like git-gui.
It may be that the asciidoc/Docbook workflow also contains ways to get
similarly useful stuff out: comments welcome. I am just more
acquainted with Texinfo myself.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Help a sed noob
From: Simon 'corecode' Schubert @ 2007-08-04 12:26 UTC (permalink / raw)
To: Jeff King, Nguyen Thai Ngoc Duy, Git Mailing List
In-Reply-To: <20070804121811.GA1605@lapse.madduck.net>
martin f krafft wrote:
> also sprach Jeff King <peff@peff.net> [2007.08.04.1350 +0200]:
>> No, it prints everything _except_ "URL: *" from the first matching line.
>
> I am convinced we could submit this to the Obfuscated Code Contest.
> :)
This is basic sed scripting.
> The behaviour is absolutely unclear from the manpage and defies my
> logic. Can you elaborate a bit, even though this is off-topic?
-ne means "don't print, execute the following code".
/.../ should be clear, { starts a "function list"
s// is "match last regexp, so s/// is "match last regexp and replace with empty string.
flag "p" to function "s" means "print if matched"
q is "quit".
that's really straight forward and all documented in my sed(1).
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-04 12:36 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070804120243.GB9716@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Aug 04, 2007 at 12:55:43PM +0200, David Kastrup wrote:
>
>> A local branch is one with a local branch head. In contrast, checking
>> out a remote branch, while possible, leaves one with a detached head.
>
> Yes, if by "remote branch" you mean a "remote tracking branch".
Jeff, I actually have no _clue_ what I "mean" with respect to the
established git terminology because I can't reconcile the
documentation's use of words with my meagre understanding of the
technical processes involved.
So I can't even tell you whether "by remote branch I mean a remote
tracking branch".
>> "remote-tracking" basically means that git-pull will update the
>> branch according to changes in the remote repository.
>
> A "remote tracking branch" is a branch in refs/remotes/* that is
> updated by _git-fetch_ (which is in turn called by git-pull) to
> track a remote's position of a branch.
>
> A local branch which tracks a remote branch (I don't recall seeing
> the phrase "remote-tracking" -- where did this come from?) has the
> correct magic in .git/config to pull from a specific remote branch
> when 'git-pull' is given without arguments.
>
>> Creating a branch using git-branch or git-checkout will always
>> create a local branch which may or may not be remote-tracking
>> according to the --no-track or --track options.
>
> Yes, although again, I think calling it a "remote-tracking branch"
> to mean "a local branch that tracks a remote branch" is confusingly
> similar to the more common "remote tracking branch" to mean "a
> branch in refs/remotes that track's a remote repository's idea of a
> branch".
Well, of _course_ it is confusingly similar. After all, I am posting
this question because I _am_ confused! And I am trying to both clear
up my confusion as well as get an idea how to fix the documentation to
be less confusing.
>> So there are basically three types of branches in a repository that
>> I can see:
>>
>> local branch, not remote-tracking local branch, remote-tracking
>> remote branch, remote-tracking
>
> No, the remote branch is not remote-tracking in the sense that you
> defined above; it is not meant to be pulled into.
Sigh. But it is cached and updated locally in some manner when
pulling, isn't it? I can diff against it.
> I think you are confused by two uses of the word "track". In one
> case, we mean that git-fetch will remember the remote's idea of a
> branch in refs/remotes/<remote>/<branch>. In another, we mean that a
> local branch will default to pulling from a particular
> (remote,branch) combination.
>
>> So the terminology seems fuzzy at the moment, and my attempt to
>> clear it up might not be the preferred way of doing it.
>
> Yes, it is very fuzzy. Using "track" for the concept of a local
> branch defaulting to a particular (remote,branch) pair for git-pull
> is, I think, more recent and less used. If there were another term
> for this, it might be more clear.
It is not just git-pull. I don't get the fine lines between "remote",
"remote tracking" and the respective details in either the user manual
or the manual pages of branch-related commands.
And it's actually worse after your explanations. Previously I
imagined to have a chance to figure this out on my own, by trying to
abstract from what I see happening when using the various commands.
Now I think that I basically have no chance figuring this out on my
own sufficiently well to be able to improve the documentation.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git-gui console app ?
From: Erik Colson @ 2007-08-04 12:38 UTC (permalink / raw)
To: git
In-Reply-To: <20070804120342.GC9716@coredump.intra.peff.net>
On Sat, Aug 04, 2007 at 08:03:42AM -0400, Jeff King wrote:
> On Sat, Aug 04, 2007 at 01:53:31PM +0200, Erik Colson wrote:
>
> > Thanks for the very fast answer. I'm currently trying it out. However
> > I can't figure out how to view the 'changed but not updated' in diff
> > format...
>
> git-diff ?
>
> By default, it will show the changes between your working tree and the
> index (i.e., changed but not updated). You can show the diff of "updated
> but not commited" with "git-diff --cached".
Peff,
yep that is the info I would like to browse in a way git-gui does it...
showing a list of the files in the diff, and letting the user select a
file to show the part of the diff for that file.
--
Erik
^ permalink raw reply
* Re: Help a sed noob
From: Jeff King @ 2007-08-04 12:40 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20070804121811.GA1605@lapse.madduck.net>
On Sat, Aug 04, 2007 at 02:18:11PM +0200, martin f krafft wrote:
> The behaviour is absolutely unclear from the manpage and defies my
> logic. Can you elaborate a bit, even though this is off-topic?
The original sed code in question was:
sed -ne '/^URL: */{
s///p
q
}' "$GIT_DIR/remotes/$1"
There are a few things to note:
1. -n means "do not print lines by default"
2. sed addresses consist of an address (in this case a regex meaning
"do this for lines that match the regex") and a command
3. The braces start a set of commands, so that for lines matching the
address, we do all of the commands.
4. An empty matching portion for a regex means "use the last regex".
So this script comes down to:
- don't write any lines except the ones we match
- find a line that starts with URL:
- replace the URL: part with nothing
- print the result
- quit
It could be more simply written as:
sed -ne 's/^URL: *//pq'
which uses the substitution as an address, but I don't know whether that
was allowed in the original sed.
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Timo Hirvonen @ 2007-08-04 12:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Steven Grimm, Ismail Dönmez, git
In-Reply-To: <Pine.LNX.4.64.0708041240500.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 4 Aug 2007, Timo Hirvonen wrote:
>
> > I used asciidoc too but it was really PITA to install and use
>
> I disagree. Whenever I had the need, installing asciidoc was pretty
> swift. No problems at all.
Well asciidoc doesn't even have a Makefile. You have to copy the files
manually (maybe it's easier now, I don't know). Also getting it work
correctly with xsl-stylesheets etc. was really frustrating experience.
Now there's asciidoc, xmlto etc. in Arch Linux community repo but I
wouldn't be surprised if it couldn't build the GIT documentation.
> > so I wrote a small tool (ttman) in C which converts .txt files directly
> > to man pages.
>
> I was impressed! Right until I saw that
>
> - it rolls its own parser/lexer without using bison/flex, which
> makes it much longer than necessary,
I've never liked parser generators.
> - it looks like a perl script doing the same job would have been
> even smaller yet, and
Very likely but perl is incompatible with my brain :)
> - the syntax is nowhere near asciidoc syntax.
I needed something really simple. asciidoc's syntax is full of
surprises and it's much harder to parse.
Of course having a perl script which could convert asciidoc files
directly to man and html would be really nice. We just need some brave
perl hacker to write the script.
> For official releases, I'd still want to rely on asciidoc.
Agreed, rushing to change the documentation format wouldn't be wise.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Lars Hjemli @ 2007-08-04 13:07 UTC (permalink / raw)
To: David Kastrup; +Cc: Jeff King, git
In-Reply-To: <85tzrfh3yg.fsf@lola.goethe.zz>
On 8/4/07, David Kastrup <dak@gnu.org> wrote:
> Now I think that I basically have no chance figuring this out on my
> own sufficiently well to be able to improve the documentation.
Remote-tracking branch:
A local copy of a branch in another repository. This kind of branch
cannot be updated by 'git-commit' but only by 'git-fetch' (hence
indirectly by 'git-pull' and 'git-remote update'). If you try to
'git-checkout' a remote-tracking branch, you will get a detached HEAD.
Local branch:
A branch to which you may commit changes. Optionally, the branch can be
configured to "follow" one of your remote-tracking branches. This means
that a 'git-pull' without arguments (when your local branch is checked
out), will automatically 'git-fetch' and then 'git-merge' the remote-
tracking branch.
Example:
Your local branch 'master' is setup to "follow" 'refs/remotes/origin/master'.
So if you do this:
$ git checkout master
$ git pull
Then the 'git pull'-command will do this:
$ git fetch -f origin master:remotes/origin/master
$ git merge remotes/origin/master
The magic setup that makes this happen is the following lines in .git/config:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Was this helpful?
--
larsh
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Robin Rosenberg @ 2007-08-04 13:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzm18jg7p.fsf@assigned-by-dhcp.cox.net>
Commit 281a53bb79786a6d7e54f9715cc8ad46fc2bdb0e introduced some stains on my man pages. They
look like:
.ft C
A---B---C topic
/
D---E---F---G master
.ft
Versions (Mandriva 20071):
asciidoc-8.1.0-1mdv2007.1
docbook-style-xsl-1.72.0-1mdv2007.1
You should also mention that the man pages goes to a new location when installed.
-- robin
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Ismail Dönmez @ 2007-08-04 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodhoj8l2.fsf@assigned-by-dhcp.cox.net>
On Saturday 04 August 2007 06:13:13 you wrote:
> Ismail Dönmez <ismail@pardus.org.tr> writes:
> > Attached patch from Fedora against docbook-xsl 1.73 fixes the issue.
>
> Thanks. I'll mention this in the INSTALL document somewhere.
>
> Perhaps the patch should go to docbook-xsl maintainers.
I sent a mail to docbook mailing list.
Regards,
ismail
--
Perfect is the enemy of good
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Sean @ 2007-08-04 13:29 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <854pjfin68.fsf@lola.goethe.zz>
On Sat, 04 Aug 2007 12:55:43 +0200
David Kastrup <dak@gnu.org> wrote:
> I am trying to dig through man-pages and user manual and trying to
> match them with reality. I seem to have a hard time. My current
> understanding (which definitely differs from the documented state) is
> that there are two types of branches, local and remote branches, and
> both types of branches can be remote-tracking (it may not be possible
> to have a non-remote-tracking remote branch, though).
>
> A local branch is one with a local branch head. In contrast, checking
> out a remote branch, while possible, leaves one with a detached head.
Yes.
> "remote-tracking" basically means that git-pull will update the branch
> according to changes in the remote repository.
To be clear, it's the job of git-fetch to update remote-tracking branches
with any changes found in the remote repository. Git-pull runs git-fetch
and then runs a git-merge to update the currently-checked-out branch.
When this happens, git-merge must decide which remote-tracking-branch
to merge into the currently checked out local branch. You can set which
remote-tracking-branch will be selected in this situation with
the --track option.
So assuming a remote-repo has two branches "master" and "branchX":
git clone remote-repo
will give us two remote-branch (AKA remote-tracking-branches) of
"origin/master" and "origin/branchX". So:
git branch --track mylocalbranch origin/branchX
git checkout mylocalbranch
Creates a local branch named "mylocalbranch" that by default will
merge in any changes found in the remote-tracking branch
"origin/branchX". Thus:
git pull
First runs git fetch which will update all remote-tracking branches
such as origin/master and origin/branchX. Then it runs git merge.
Git merge has to decide whether to merge in the changes from
origin/master or origin/branchX. Because of the --track option used
to setup "mylocalbranch", "origin/branchX" will be merged.
> Creating a branch using git-branch or git-checkout will always create
> a local branch which may or may not be remote-tracking according to
> the --no-track or --track options.
No, a local branch is never a remote-tracking branch; even when created
with a --track option. The --track option has muddied the terminology
waters a bit and you're not the first to be confused by it. The
--track selects a branch from the repo to merge by default.
> So there are basically three types of branches in a repository that I
> can see:
>
> local branch, not remote-tracking
> local branch, remote-tracking
> remote branch, remote-tracking
>
> The way to add a remote branch basically is not via git-branch or
> git-checkout -b (those always create local branches), but by editing
> .git/config.
>
> Is this understanding correct or did I get things completely wrong?
> Because there is little sense in myself working on changing the
> documentation if I have not understood the situation.
Functionally, your understanding is correct. But it helps when you
understand that remote-branches are the "real" remote-tracking-branches.
You don't commit to them locally, they are essentially read-only copies
of exactly what is happening in a remote repository.
A local --track branch, is one that merges changes from the proper
remote-tracking-branch, and is also a place where you can commit your
own work.
> Also, the documentation currently uses "remote-tracking"
> interchangeably for "local branch, remote-tracking" and "remote
> branch, remote-tracking", at some times claiming that one can locally
> switch to a "remote-tracking" branch, at other times not.
A remote branch and a remote-tracking branch are the same thing.
Strictly speaking a local branch is never a remote-tracking-branch
although the "--track" option makes that harder to explain.
> So the terminology seems fuzzy at the moment, and my attempt to clear
> it up might not be the preferred way of doing it.
Yeah, the documentation could use some fine tuning.
Sean
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-04 13:38 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jeff King, git
In-Reply-To: <8c5c35580708040607ya186edcg89fbc90587b64d68@mail.gmail.com>
"Lars Hjemli" <lh@elementstorage.no> writes:
> On 8/4/07, David Kastrup <dak@gnu.org> wrote:
>> Now I think that I basically have no chance figuring this out on my
>> own sufficiently well to be able to improve the documentation.
>
> Remote-tracking branch:
> A local copy of a branch in another repository. This kind of branch
> cannot be updated by 'git-commit' but only by 'git-fetch' (hence
> indirectly by 'git-pull' and 'git-remote update'). If you try to
> 'git-checkout' a remote-tracking branch, you will get a detached HEAD.
>
> Local branch:
> A branch to which you may commit changes. Optionally, the branch can be
> configured to "follow" one of your remote-tracking branches. This means
> that a 'git-pull' without arguments (when your local branch is checked
> out), will automatically 'git-fetch' and then 'git-merge' the remote-
> tracking branch.
Does that mean that specifying "--track" to git-checkout or git-branch
never creates a remote-tracking branch?
> Example:
>
> Your local branch 'master' is setup to "follow"
> 'refs/remotes/origin/master'.
So --track/--no-track are actually supposed to be --follow and
--no-follow?
> So if you do this:
>
> $ git checkout master
> $ git pull
>
> Then the 'git pull'-command will do this:
>
> $ git fetch -f origin master:remotes/origin/master
This is then tracking?
> $ git merge remotes/origin/master
And this is then following?
> The magic setup that makes this happen is the following lines in .git/config:
>
> [remote "origin"]
Namely: a remote-tracking branch "origin"
> url = git://git.kernel.org/pub/scm/git/git.git
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> [branch "master"]
> remote = origin
Namely: follow the remote tracking branch origin?
> merge = refs/heads/master
>
>
> Was this helpful?
So we have remote tracking branches, and we have local branches
following remote tracking branches, and "--track" and "--no-track"
create local branches following or not following a remote tracking
branch? And have nothing whatsoever to do with tracking or not
tracking a remove branch?
Talk about misleading option names here.
Then in man git-branch we have:
In its second form, a new branch named <branchname> will be
created. It will start out with a head equal to the one
given as <start-point>. If no <start-point> is given, the
branch will be created with a head equal to that of the
currently checked out branch.
When a local branch is started off a remote branch, git can
setup the branch so that git-pull(1) will appropriately
merge from that remote branch. If this behavior is desired,
it is possible to make it the default using the global
branch.autosetupmerge configuration flag. Otherwise, it can
be chosen per-branch using the --track and --no-track
options.
What does "remote branch" in this context mean? A local branch
following a remote tracked branch? A remote tracked branch (which by
definition can't be checked out as a branch, since that leads to a
detached head)? What does "start off" mean in this context? If I
can't check out a remote branch, I can't start off on it, can I?
Does "--track" mean that the new branch will copy any "remote" lines
which incidentally don't point to remote branches as their name would
suggest, but rather to remote tracking branches? And we want to have
the relation to the remote tracking branch preserved, not to the
actual remote branch?
I don't get it. Really. No chance. There are fine distinction lines
in the git terminology, it would appear, and those lines are freely
ignored in naming options and configuration parameters. And the
manual pages themselves are not overly concerned about explaining
those distinctions either.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Julian Phillips @ 2007-08-04 13:42 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Junio C Hamano, git
In-Reply-To: <200708041511.05191.robin.rosenberg.lists@dewire.com>
On Sat, 4 Aug 2007, Robin Rosenberg wrote:
>
> Commit 281a53bb79786a6d7e54f9715cc8ad46fc2bdb0e introduced some stains on my man pages. They
> look like:
>
> .ft C
> A---B---C topic
> /
> D---E---F---G master
> .ft
>
> Versions (Mandriva 20071):
>
> asciidoc-8.1.0-1mdv2007.1
> docbook-style-xsl-1.72.0-1mdv2007.1
docbook xsl 1.72 is the culprit. This version has extra escaping rules
that weren't in 1.71 and were removed for 1.73. In addition these rules
are not backwardly compatible. Basically, you can't build the git docs
properly with 1.72 ...
See http://thread.gmane.org/gmane.comp.version-control.git/52369
--
Julian
---
<seemant> you should always know where your inodes are, and who they are with
^ permalink raw reply
* Re: Help a sed noob
From: martin f krafft @ 2007-08-04 13:56 UTC (permalink / raw)
To: Simon 'corecode' Schubert
Cc: Jeff King, Nguyen Thai Ngoc Duy, Git Mailing List
In-Reply-To: <46B4705D.2010208@fs.ei.tum.de>
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
also sprach Simon 'corecode' Schubert <corecode@fs.ei.tum.de> [2007.08.04.1426 +0200]:
> s// is "match last regexp, so s/// is "match last regexp and replace with
> empty string.
This fact is not in the manpage, AFAICT, at least not on Debian
systems.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
due to lack of interest tomorrow has been cancelled.
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: Terminology question about remote branches.
From: David Kastrup @ 2007-08-04 14:01 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <20070804092933.aaec6d52.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> writes:
> David Kastrup <dak@gnu.org> wrote:
>
>> A local branch is one with a local branch head. In contrast,
>> checking out a remote branch, while possible, leaves one with a
>> detached head.
>
> Yes.
>
>> "remote-tracking" basically means that git-pull will update the
>> branch according to changes in the remote repository.
>
> To be clear, it's the job of git-fetch to update remote-tracking
> branches with any changes found in the remote repository. Git-pull
> runs git-fetch and then runs a git-merge to update the
> currently-checked-out branch.
>
> When this happens, git-merge must decide which
> remote-tracking-branch to merge into the currently checked out local
> branch. You can set which remote-tracking-branch will be selected
> in this situation with the --track option.
>
> So assuming a remote-repo has two branches "master" and "branchX":
>
> git clone remote-repo
>
> will give us two remote-branch (AKA remote-tracking-branches) of
> "origin/master" and "origin/branchX". So:
>
> git branch --track mylocalbranch origin/branchX
> git checkout mylocalbranch
So --track does not set up a tracking branch, but makes a local
_following_ branch _refer_ to a tracking branch.
What happens with
git checkout origin/branchX
git branch --track mylocalbranch
git checkout mylocalbranch
? What if after the checkout (which leads to a detached head) I check
in a few things, and then decide to name the branch and set it up as
following a remote tracking branch? Instead of using git-branch for
setting up the following, do I have to explicitly add the respective
"remote" line (which does not specify a remote, but a remote tracking
branch) into, uh, where?
> No, a local branch is never a remote-tracking branch; even when
> created with a --track option. The --track option has muddied the
> terminology waters a bit and you're not the first to be confused by
> it. The --track selects a branch from the repo to merge by default.
Well, GOOD. I have already come to the conclusion that the "--track"
option, like the "remote" configuration recorded by it have the main
purpose of confusing people and should not be confused with setting up
a remote tracking branch, or referring to a remote branch.
> A remote branch and a remote-tracking branch are the same thing.
> Strictly speaking a local branch is never a remote-tracking-branch
> although the "--track" option makes that harder to explain.
You bet.
>> So the terminology seems fuzzy at the moment, and my attempt to
>> clear it up might not be the preferred way of doing it.
>
> Yeah, the documentation could use some fine tuning.
It is much too fine-tuned already. I think that first option names
and config file options need to get some coarse-tuning where one does
not have to split hairs and ignore the meaning of terms in order to
understand them.
I have now "following" or "automerge" local branches which are set up
to follow a "remote tracking" branch. Presumably, if I do
git-branch -b new-branch --track remote-branch
then I get a following branch set up which follows/automerges a remote
tracking branch. So far so good. What do I get with
git-branch -b another-new-branch --track new-branch
Does this follow/automerges with new-branch? Does this
follow/automerge with remote-branch?
What if I do
git-checkout remote-branch
git-branch -b new-branch --track
Does this follow anything?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Lars Hjemli @ 2007-08-04 14:03 UTC (permalink / raw)
To: David Kastrup; +Cc: Jeff King, git
In-Reply-To: <85k5sbh129.fsf@lola.goethe.zz>
On 8/4/07, David Kastrup <dak@gnu.org> wrote:
> "Lars Hjemli" <lh@elementstorage.no> writes:
>
> > On 8/4/07, David Kastrup <dak@gnu.org> wrote:
> >> Now I think that I basically have no chance figuring this out on my
> >> own sufficiently well to be able to improve the documentation.
> >
> > Remote-tracking branch:
> > A local copy of a branch in another repository. This kind of branch
> > cannot be updated by 'git-commit' but only by 'git-fetch' (hence
> > indirectly by 'git-pull' and 'git-remote update'). If you try to
> > 'git-checkout' a remote-tracking branch, you will get a detached HEAD.
> >
> > Local branch:
> > A branch to which you may commit changes. Optionally, the branch can be
> > configured to "follow" one of your remote-tracking branches. This means
> > that a 'git-pull' without arguments (when your local branch is checked
> > out), will automatically 'git-fetch' and then 'git-merge' the remote-
> > tracking branch.
>
> Does that mean that specifying "--track" to git-checkout or git-branch
> never creates a remote-tracking branch?
Yes. The "--track" option just adds some extra info in .git/config:
[branch "master"]
remote = origin
merge = refs/heads/master
This info is then used by "git-pull" to
1. fetch updates from the remote repository "origin"
2. merge those updates from refs/remotes/origin/master
>
> > Example:
> >
> > Your local branch 'master' is setup to "follow"
> > 'refs/remotes/origin/master'.
>
> So --track/--no-track are actually supposed to be --follow and
> --no-follow?
Maybe ;-)
I just tried to avoid using the word "track" in more than one context,
since it seemed to be a main source of confusion.
>
> > So if you do this:
> >
> > $ git checkout master
> > $ git pull
> >
> > Then the 'git pull'-command will do this:
> >
> > $ git fetch -f origin master:remotes/origin/master
>
> This is then tracking?
Yes, this is the part that downloads objects from the remote
repository and updates refs/remotes/origin/master to refer to the same
commit as the master branch in the remote repository.
>
> > $ git merge remotes/origin/master
>
> And this is then following?
Yes, this updates your local 'master' with the commits downloaded by git-fetch
>
> > The magic setup that makes this happen is the following lines in .git/config:
> >
> > [remote "origin"]
> Namely: a remote-tracking branch "origin"
No. A remote repository: the name 'origin' can be used as an alias for
git://git.kernel.org/pub/scm/git/git.git
>
> > url = git://git.kernel.org/pub/scm/git/git.git
> > fetch = +refs/heads/*:refs/remotes/origin/*
> >
> > [branch "master"]
> > remote = origin
>
> Namely: follow the remote tracking branch origin?
No. Fetch objects from the remote repository alias "origin"
>
> > merge = refs/heads/master
And this is the info added by "git branch --track" which enables the
automatic merging of refs/remotes/origin/master (since
refs/remotes/origin/master is your local copy of refs/heads/master in
the 'origin' repository)
> >
> >
> > Was this helpful?
Talking to myself: obviously not
--
larsh
^ permalink raw reply
* Re: Help a sed noob
From: David Kastrup @ 2007-08-04 14:06 UTC (permalink / raw)
To: Simon 'corecode' Schubert
Cc: Jeff King, Nguyen Thai Ngoc Duy, Git Mailing List
In-Reply-To: <20070804135630.GC1605@lapse.madduck.net>
martin f krafft <madduck@madduck.net> writes:
> also sprach Simon 'corecode' Schubert <corecode@fs.ei.tum.de> [2007.08.04.1426 +0200]:
>> s// is "match last regexp, so s/// is "match last regexp and replace with
>> empty string.
>
> This fact is not in the manpage, AFAICT, at least not on Debian
> systems.
IIRC, this is a traditional _ed_ feature. I don't think it has ever
been a traditional part of _sed_, but maybe some implementations have
adopted this usage.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-04 14:11 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jeff King, git
In-Reply-To: <8c5c35580708040703w44781498t7396588a3f8c81c8@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
>> > Was this helpful?
>
> Talking to myself: obviously not
Disagree. "Does this answer all questions and makes git's behavior
perfectly transparent" -- no. But let's not confuse "magical" with
"helpful" here.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ 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