* Re: [RFC] Submodules in GIT
From: Linus Torvalds @ 2006-11-21 22:51 UTC (permalink / raw)
To: Yann Dirson; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <20061121223130.GA24909@nan92-1-81-57-214-146.fbx.proxad.net>
On Tue, 21 Nov 2006, Yann Dirson wrote:
>
> I'm not sure I get the reason why the submodule should not be recorded
> on "commit level".
Because that would be STUPID.
What does the submodules have to do with the commit level? Nothing. Nada.
Zero.
Submodules are _directories_. They can be anywhere in the directory tree.
If you try to encode that in a commit message, you're going to totally
break the whole notion of trying to "diff" two trees.
All of git is designed around the notion that a tree is the directory
structure. If you put directory structure somewhere else, you totally
screw all abstractions.
Now, if that weren't enough, let me enumerate _another_ reason why it's
idiotic and wrong, namely the fact that a "commit" is fundamnetally the
wrong place to add something like that _anyway_. Quite apart from the fact
that we describe directory trees with (wait for it): "tree objects", the
thing is, a commit is about a totally different _dimension_ altogether.
The only and _whole_ point of a "commit" is to describe the "time
dimension". Something that doesn't always change in time should not be in
a commit object, because it is by definition not what a commit is all
about. A commit should describe the relationship of itself to other
commits, ie it's a "how did this change".
And a sub-project simply doesn't even _do_ that. Much of the time, a
subproject stays constant, and is not something that comes and goes on an
individual commit basis.
I don't understand why people are so fixated with putting things in the
wrong object. WHY do people want to put crap in the "commit" object?
People have wanted to put "rename" information there (which is stupid for
all the same reasons: renames _remain_. They aren't a one-time event. If
something was renamed in commit X, it will _remain_ renamed in commit X+1,
so it's clearly not really a "commit X" thing)
Think of it this way:
- if something _only_ makes sense on an _individual commit_ level, it
goes into the "commit object". But if it makes sense for "git diff",
then it MUST NOT be in a commit object, because you do "git diff" over
a big _range_ of commit objects.
Think "git show". The "author" of a commit is only associated with a
_single_ commit. It thus goes into the commit object, and nowhere else.
Same goes for time, and commit message. A commit message is fundamentally
a "this explains this _one_ commit".
But anything that you expect to have in a "range" of commits MUST NOT be
in a "commit object". If I do "git diff v2.6.13..v2.6.14", and I expect
the behaviour you want to encode to show up (and dammit, subprojects very
much fall under that heading - exactly the same way renames must have
meaning _outside_ of a single commit) then clearly it is NOT something
that is associated with any individual commits. It's something that is
associated with the _state_ of the project.
And the _state_ of the project is the "tree". Not the commit. The commit
is about the _history_ of the project.
So please understand this: "commit" is about the time-dimension
("history"). "tree" is about the space-dimension ("state"). The two are
_related_, but they are also very much different concepts, and "related"
does not mean "you can mix them up".
Sub-projects are clearly not about "time". They are about "state".
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Jakub Narebski @ 2006-11-21 22:53 UTC (permalink / raw)
To: git
In-Reply-To: <45638212.8030501@freescale.com>
Timur Tabi wrote:
> Johannes Schindelin wrote:
>> Try "git clone --depth 1 <url>". This will cut each ancestor chain after
>> one ancestor (IIRC).
>
> I think you mean git-clone.sh instead of git-clone. If I do the above command,
> I get:
>
> $ ./git clone --depth 1 git://127.0.0.1/temp/u-boot-83xx/
> Usage: /home/b04825/bin/git-clone [--template=<template_directory>]
> [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q]
> [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]
>
> However, git-clone.sh is not quite working either. I had to run git-daemon on
> my machine, because git-clone.sh doesn't like the http protocol, and my firewall
> blocks everything but that. So I cloned a repo, started git-daemon, and I tried
> this:
>
> $ ./git-clone.sh --depth 1 git://127.0.0.1/temp/u-boot-83xx
> usage: git-fetch-pack [--all] [-q] [-v] [-k] [--thin] [--exec=upload-pack]
> [host:]directory <refs>...
> fetch-pack from 'git://127.0.0.1/temp/u-boot-83xx/' failed.
>
> A regular git-clone of git://127.0.0.1/temp/u-boot-83xx works, so I think
> there's something wrong with git-clone.sh or my invocation thereof.
Erm, you have to compile git with "make bindir=$(pwd)" to run it from
working directory. Or just install it somewhere not over git, like
/usr/local/ or /home/local/.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Johannes Schindelin @ 2006-11-21 22:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: Shawn Pearce, Thomas Kolejka, git
In-Reply-To: <45638212.8030501@freescale.com>
Hi,
On Tue, 21 Nov 2006, Timur Tabi wrote:
> I think you mean git-clone.sh instead of git-clone.
No. If "git clone" does not work for you, the compilation failed. Do you
run git in-place? Then you _have_ to set
bindir=$(pwd)
in config.mak. Otherwise, the git wrapper (you wrote "git-clone", but then
you used "git clone") will look in $(HOME)/bin for your executables, and I
bet that you have the other (official) git installed there.
> However, git-clone.sh is not quite working either. I had to run
> git-daemon on my machine, because git-clone.sh doesn't like the http
> protocol, and my firewall blocks everything but that.
For now, shallow clones only work with the git protocol, i.e. via
git-daemon and ssh.
Hth,
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Linus Torvalds @ 2006-11-21 22:59 UTC (permalink / raw)
To: Yann Dirson; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0611211437430.3338@woody.osdl.org>
On Tue, 21 Nov 2006, Linus Torvalds wrote:
>
> Submodules are _directories_.
Side note - you can do submodules other ways, but if you do, you'll almost
certainly go crazy.
You could, for example, make submodules be some kind of "union
filesystem", where you allow overlapping trees. It's conceptually
possible. It's also horribly horribly wrong, if only because I guarantee
that you'll have so many problems with it that you will only end up with a
mess that is even worse than "branches" in CVS.
^ permalink raw reply
* [PATCH] move Git.pm build instructions into perl/Makefile
From: Alex Riesen @ 2006-11-21 22:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
...so that I can disable MakeMaker stuff as soon as I get to work,
which is the only windows+cygwin+activestate system available to me.
Alas, it is also the system where I use git most.
The MakeMaker killing patch should follow.
Makefile | 19 +++++++++----------
perl/.gitignore | 3 ++-
perl/Makefile | 23 +++++++++++++++++++++++
3 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/Makefile b/Makefile
index 36ce8cd..c849227 100644
--- a/Makefile
+++ b/Makefile
@@ -592,8 +592,8 @@ export prefix TAR INSTALL DESTDIR SHELL_
all: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk gitweb/gitweb.cgi
-all: perl/Makefile
- $(MAKE) -C perl
+all:
+ $(MAKE) -C perl PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
$(MAKE) -C templates
strip: $(PROGRAMS) git$X
@@ -627,7 +627,11 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.
chmod +x $@+
mv $@+ $@
-$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/Makefile
+$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
+
+perl/perl.mak: GIT-CFLAGS
+ $(MAKE) -C perl PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' $(@F)
+
$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
rm -f $@ $@+
INSTLIBDIR=`$(MAKE) -C perl -s --no-print-directory instlibdir` && \
@@ -767,10 +771,6 @@ $(XDIFF_LIB): $(XDIFF_OBJS)
rm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)
-perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
- (cd perl && $(PERL_PATH) Makefile.PL \
- PREFIX='$(prefix_SQ)')
-
doc:
$(MAKE) -C Documentation all
@@ -833,7 +833,7 @@ install: all
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(INSTALL) git$X gitk '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
- $(MAKE) -C perl install
+ $(MAKE) -C perl prefix='$(prefix_SQ)' install
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
$(INSTALL) $(PYMODULES) '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
@@ -905,8 +905,7 @@ clean:
rm -f $(htmldocs).tar.gz $(manpages).tar.gz
rm -f gitweb/gitweb.cgi
$(MAKE) -C Documentation/ clean
- [ ! -f perl/Makefile ] || $(MAKE) -C perl/ clean || $(MAKE) -C perl/ clean
- rm -f perl/ppport.h perl/Makefile.old
+ $(MAKE) -C perl clean
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
rm -f GIT-VERSION-FILE GIT-CFLAGS
diff --git a/perl/.gitignore b/perl/.gitignore
index e990cae..98b2477 100644
--- a/perl/.gitignore
+++ b/perl/.gitignore
@@ -1,4 +1,5 @@
-Makefile
+perl.mak
+perl.mak.old
blib
blibdirs
pm_to_blib
diff --git a/perl/Makefile b/perl/Makefile
new file mode 100644
index 0000000..cff24dd
--- /dev/null
+++ b/perl/Makefile
@@ -0,0 +1,23 @@
+#
+# Makefile for perl support modules and routine
+#
+makfile:=perl.mak
+
+PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
+prefix_SQ = $(subst ','\'',$(prefix))
+
+all install instlibdir: $(makfile)
+ $(MAKE) -f $(makfile) $@
+
+clean:
+ test -f $(makfile) && $(MAKE) -f $(makfile) $@ || exit 0
+ $(RM) ppport.h
+ $(RM) $(makfile)
+
+$(makfile): Makefile.PL ../GIT-CFLAGS
+ '$(PERL_PATH_SQ)' $< FIRST_MAKEFILE='$@' PREFIX='$(prefix_SQ)'
+
+# this is just added comfort for calling make directly in perl dir
+# (even though GIT-CFLAGS aren't used yet. If ever)
+../GIT-CFLAGS:
+ $(MAKE) -C .. GIT-CFLAGS
--
^ permalink raw reply related
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Timur Tabi @ 2006-11-21 23:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn Pearce, Thomas Kolejka, git
In-Reply-To: <Pine.LNX.4.63.0611212349440.26827@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 21 Nov 2006, Timur Tabi wrote:
>
>> I think you mean git-clone.sh instead of git-clone.
>
> No. If "git clone" does not work for you, the compilation failed. Do you
> run git in-place? Then you _have_ to set
>
> bindir=$(pwd)
>
> in config.mak.
When I tried that, make spits out this:
GIT_VERSION = 1.4.4.ge1173-dirty
* new build flags or prefix
(cd perl && /usr/bin/perl Makefile.PL \
PREFIX='/home/b04825')
Writing Makefile for Git
So I tried this:
make configure
./configure --prefix=$PWD
make
and got this:
* new build flags or prefix
(cd perl && /usr/bin/perl Makefile.PL \
PREFIX='/temp/git')
Writing Makefile for Git
which is better, but git-clone still doesn't work:
$ ./git clone --depth 1 git://127.0.0.1/temp/u-boot-83xx
Failed to run command 'clone': Success
$ ./git-clone --depth 1 git://127.0.0.1/temp/u-boot-83xx
usage: git-fetch-pack [--all] [-q] [-v] [-k] [--thin] [--exec=upload-pack]
[host:]directory <refs>...
fetch-pack from 'git://127.0.0.1/temp/u-boot-83xx' failed.
In both of these cases, the git-daemon process doesn't log anything.
I even tried "export GIT_DIR=$PWD", but that didn't do anything.
--
Timur Tabi
^ permalink raw reply
* Re: [PATCH] xdiff: add xdl_merge() (was: (unknown))
From: Jakub Narebski @ 2006-11-21 23:15 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0611212316080.26827@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> [PATCH] xdiff: add xdl_merge()
Shouldn't this be in the subject of message?
> This new function implements the functionality of RCS merge, but
> in-memory. It returns < 0 on error, otherwise the number of conflicts.
Only RCS merge, or can you implement whole diff3 (from GNU diffutils)
functionality with that?
> Finding the conflicting lines can be a very expensive task. You can
> control the eagerness of this algorithm:
>
> - a level value of 0 means that all overlapping changes are treated
> as conflicts,
> - a value of 1 means that if the overlapping changes are identical,
> it is not treated as a conflict.
> - If you set level to 2, overlapping changes will be analyzed, so that
> almost identical changes will not result in huge conflicts. Rather,
> only the conflicting lines will be shown inside conflict markers.
>
> With each increasing level, the algorithm gets slower, but more accurate.
> Note that the code for level 2 depends on the simple definition of
> mmfile_t specific to git, and therefore it will be harder to port that
> to LibXDiff.
How it compares performance with RCS merge/GNU diff3?
It is really nice to have that. Bram Cohen (of Codeville, SCM built around
sophisticated merge algorithm) wrote about recursive three-way merge in
http://revctrl.org/CrissCrossMerge
Recursive three-way merge _usually_ provides the right answer, however
there are some edge cases. For example, conflict markers can be matched
incorrectly, because they aren't given any special semantic meaning for
the merge algorithm, and are simply treated as lines. In particular,
there are (somewhat complicated) cases where the conflict markers of two
unrelated conflicts get matched against each other, even though the
content sections of them are totally unrelated.
I'm not sure if he has specific examples, or is it just theoretical talk,
but having built-in merge would certainly help revursive merge strategy
(and perhaps also git-rerere).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Jakub Narebski @ 2006-11-21 23:22 UTC (permalink / raw)
To: git
In-Reply-To: <456387D5.9080407@freescale.com>
Timur Tabi wrote:
> make configure
> ./configure --prefix=$PWD
> make
make configure
./configure --prefix=$PWD --bindir=$PWD
make
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Move --pretty options into Documentation/pretty-formats.txt
From: Chris Riddoch @ 2006-11-21 23:49 UTC (permalink / raw)
To: git; +Cc: Chris Riddoch
Asciidoc-include it into the manuals for programs that use the
--pretty command-line option, for consistency among the docs.
This describes all the pretty-formats currently listed in the cmit_fmt
enum in commit.h, and also briefly describes the presence and format
of the 'Merge: ' line in some pretty formats.
There's a hedge that limiting your view of history can affect what
goes in the Merge: line, and that --abbrev/--no-abbrev do nothing to
the 'raw' format.
Signed-off-by: Chris Riddoch <chris@syntacticsugar.org>
---
Documentation/git-diff-tree.txt | 5 +--
Documentation/git-log.txt | 4 +-
Documentation/git-rev-list.txt | 6 +---
Documentation/git-show.txt | 5 +--
Documentation/pretty-formats.txt | 60 ++++++++++++++++++++++++++++++++++++++
5 files changed, 65 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index f7e8ff2..5d6e9dc 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -73,10 +73,7 @@ separated with a single space are given.
This flag causes "git-diff-tree --stdin" to also show
the commit message before the differences.
---pretty[=(raw|medium|short)]::
- This is used to control "pretty printing" format of the
- commit message. Without "=<style>", it defaults to
- medium.
+include::pretty-formats.txt[]
--no-commit-id::
git-diff-tree outputs a line with the commit ID when
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index c9ffff7..79643ac 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -24,8 +24,8 @@ This manual page describes only the most
OPTIONS
-------
---pretty=<format>::
- Controls the way the commit log is formatted.
+
+include::pretty-formats.txt[]
--max-count=<n>::
Limits the number of commits to show.
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 00a95e2..ec43c0b 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -79,11 +79,7 @@ Using these options, gitlink:git-rev-lis
more specialized family of commit log tools: gitlink:git-log[1],
gitlink:git-show[1], and gitlink:git-whatchanged[1]
---pretty[='<format>']::
-
- Pretty print the contents of the commit logs in a given format,
- where '<format>' can be one of 'raw', 'medium', 'short', 'full',
- and 'oneline'. When left out the format default to 'medium'.
+include::pretty-formats.txt[]
--relative-date::
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index 2b4df3f..4c880a8 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -26,10 +26,7 @@ OPTIONS
<commitid>::
ID of the commit to show.
---pretty=<format>::
- Controls the output format for the commit logs.
- <format> can be one of 'raw', 'medium', 'short', 'full',
- and 'oneline'.
+include::pretty-formats.txt[]
Author
------
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
new file mode 100644
index 0000000..4496c87
--- /dev/null
+++ b/Documentation/pretty-formats.txt
@@ -0,0 +1,60 @@
+--pretty[='<format>']::
+
+ Pretty-prints the details of a commit. The default format is
+ 'medium'. If the commit is a merge, and if the pretty-format
+ is not 'oneline', 'email' or 'raw', an additional line is
+ inserted before the 'Author:' line. This line begins with
+ "Merge: " and the sha1s of ancestral commits are printed,
+ separated by spaces. Note that the listed commits may not
+ necessarily be the list of the *direct* parent commits if you
+ have limited your view of history: for example, if you are
+ only interested in changes related to a certain directory or
+ file.
+
+ * 'oneline'
+
+ <sha1> <title line>
+
+ * 'short'
+
+ commit <sha1>
+ Author: <author>
+ <title line>
+
+ * 'medium'
+
+ commit <sha1>
+ Author: <author>
+ Date: <date>
+ <full commit message>
+
+ * 'full'
+
+ commit <sha1>
+ Author: <author>
+ Commit: <committer>
+ <full commit message>
+
+ * 'fuller'
+
+ commit <sha1>
+ Author: <author>
+ AuthorDate: <date & time>
+ Commit: <committer>
+ CommitDate: <date & time>
+ <full commit message>
+
+ * 'email'
+
+ from <sha1> <date>
+ From: <author>
+ Date: <date & time>
+ Subject: [PATCH] <title line>
+
+ <full commit message>
+
+ * 'raw'
+
+ The entire commit exactly as stored in the commit object
+ The SHA1s are displayed in full, regardless of whether
+ --abbrev or --no-abbrev are used.
--
1.4.4
^ permalink raw reply related
* Re: [PATCH] gitweb: make HTML links out of http/https URLs in changelogs
From: Randal L. Schwartz @ 2006-11-21 23:55 UTC (permalink / raw)
To: Kir Kolyshkin; +Cc: git
In-Reply-To: <4563777C.4050108@openvz.org>
>>>>> "Kir" == Kir Kolyshkin <kir@openvz.org> writes:
Kir> + # make HTML links out of http(s) URLs
Kir> + $line =~ s/(http[s]?:\/\/[^[:space:]\]\)]+)/<a href="\1">\1<\/a>/g;
Perl tip of the day:
On the right side of s///, you want $1, not \1, because \1 accidentally
works, but \10 (instead of the proper $10) will give you a control-h. Ick.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Yann Dirson @ 2006-11-21 23:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0611211437430.3338@woody.osdl.org>
On Tue, Nov 21, 2006 at 02:51:56PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 21 Nov 2006, Yann Dirson wrote:
> >
> > I'm not sure I get the reason why the submodule should not be recorded
> > on "commit level".
>
> Because that would be STUPID.
>
> What does the submodules have to do with the commit level? Nothing. Nada.
> Zero.
Oh, I see I may have expressed something in the wrong way :)
Namely, I brought an idea coming from partial merges into a discussion
on submodules, because when thinking about the former, I realized
we could maybe use similar mechanisms for both.
Note that the proposal I outlined did not break the tree, in that the
sumodule tree is still in the same place. In the case of a partial
merge, the info that a subtree has been merged in this commit is indeeed
part of the commit itself.
I agree that the subtree case is somewhat different, and my idea may not
apply to submodules after all :)
A question would be, do "submodules" have to be permanent objects ?
I suppose it depends on what people want to use them for. Indeed, the
"submodule" names strongly carries the idea of a permanent subset of the
repository. My proposal partial merges could be seen as using transient
submodules: they do not matter much during most of the repo life.
Put it another way, I see the proposal of allowing tree entries to be
commits in addition to trees and blobs, akin to recording the submodule
_history_ inside the _tree_, which I feel precisely violates the
distinction you want to keep between those 2 concepts.
> And a sub-project simply doesn't even _do_ that. Much of the time, a
> subproject stays constant, and is not something that comes and goes on an
> individual commit basis.
What about the case of a subproject that would evolve fast, and for
which we may not want intermediate versions to be part of the
supermodule ? (just exploring an idea without real connection to the
one discussed above)
I mean, I have a tree in which the whole software for an embedded
platform is stored, including kernel, apps, etc. While working on the
kernel, I may want to do several commits to that submodule, and may not want
to commit to the supermodule for each kernel commit, only when I feel the
kernel is stable enough.
One may argue I just have to use a branch. Anyway, there will be a need
for submodule-specific branches - eg. kernel.org ones in my case.
An alternative would be to allow committing to the submodule without
creating matching supermodule commits, and let the user decide when he
wants to commit at the higher level. That way, 2 successive supermodule
commits could have non-successive "subcommits".
Best regards,
--
^ permalink raw reply
* Re: [PATCH] gitweb: make HTML links out of http/https URLs in changelogs
From: Petr Baudis @ 2006-11-22 0:06 UTC (permalink / raw)
To: Kir Kolyshkin; +Cc: git
In-Reply-To: <4563777C.4050108@openvz.org>
On Tue, Nov 21, 2006 at 11:02:36PM CET, Kir Kolyshkin wrote:
> Slightly tested on http://git.openvz.org/. Applicable to git-1.4.4.
...but in git's gitweb view it will make this <a
href="http://git.openvz.org/.">http://git.openvz.org/.</a>. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* A documentation to-do list
From: Chris Riddoch @ 2006-11-22 1:13 UTC (permalink / raw)
To: git
Hi, everyone.
Having decided to take it on myself to improve Git's documentation, I
asked on #git if people had particular things they felt I should focus
on. I also was prompted to put up a page on the wiki to make my to-do
list public.
So, I present: http://git.or.cz/gitwiki/Documentation_To-Do_List
Add your favorite, specific, lack-of-documentation or badly-described
annoyance here!
--
epistemological humility
^ permalink raw reply
* Re: A documentation to-do list
From: Junio C Hamano @ 2006-11-22 1:33 UTC (permalink / raw)
To: Chris Riddoch; +Cc: git
In-Reply-To: <6efbd9b70611211713y4a1574adje48622f7bab6d702@mail.gmail.com>
"Chris Riddoch" <riddochc@gmail.com> writes:
> Hi, everyone.
>
> Having decided to take it on myself to improve Git's documentation, I
> asked on #git if people had particular things they felt I should focus
> on. I also was prompted to put up a page on the wiki to make my to-do
> list public.
>
> So, I present: http://git.or.cz/gitwiki/Documentation_To-Do_List
>
> Add your favorite, specific, lack-of-documentation or badly-described
> annoyance here!
Thanks.
I would not likely to be writing the updates because I am not a
good writer myself, but if there are things that need to be
explained, both behaviour-wise and intent/design-wise, I am
willing to help this effort.
Aside from lacking minor details here and there I think the
largest problem in the current documentation set is the
organization, though.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Shawn Pearce @ 2006-11-22 3:40 UTC (permalink / raw)
To: Yann Dirson; +Cc: Linus Torvalds, Junio C Hamano, Jakub Narebski, git
In-Reply-To: <20061121235429.GH5443@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson <ydirson@altern.org> wrote:
> Put it another way, I see the proposal of allowing tree entries to be
> commits in addition to trees and blobs, akin to recording the submodule
> _history_ inside the _tree_, which I feel precisely violates the
> distinction you want to keep between those 2 concepts.
No. Linus is right. Submodule commits belong in the tree.
We want to record a specific subtree within a larger tree. There are
three ways we can refer to a tree: by its tree SHA1, by a commit
which points at the tree SHA1, or by a tag which points at a
commit which points at the tree SHA1, or by a tag which points
at a tag which points at a commit which points at a tree SHA1.
Which is basically a tree-ish.
The advantage of linking to the commit-ish (commit or tag) and
not the tree-ish for a submodule is that it also provides you quick
access to answer the "how did this tree arive at this state" question
as the answer cannot come solely from the top level commit chain.
The reason... keep reading...
> What about the case of a subproject that would evolve fast, and for
> which we may not want intermediate versions to be part of the
> supermodule ? (just exploring an idea without real connection to the
> one discussed above)
Right. The submodule is free to be committed to an infinite number
of times for any given commit in the supermodule.
It is expected that users will commit to a submodule say hundreds of
times for every commit they make to the supermodule. Or thousands.
This is especially true if the submodule is some very large project,
e.g. the Linux kernel, and the supermodule "upgrades" the kernel it
is using after 3 months of staying on the same version. Suddenly the
supermodule has only 1 commit which covers maybe 10,000 commits in
the submodule.
Yet we still want to be able to efficiently perform operations like
"git bisect" within the scope of that submodule, to help narrow down
a particular bug that is within that submodule. To do that we need
the commit chain (all 10,000 of those commits) in the submodule.
To get those we really need a commit-ish and not a tree-ish, as
going from a tree-ish to a commit-ish is not only not unique but
is also pretty infeasible to do (you need to scan *every* commit).
--
^ permalink raw reply
* [PATCH] merge: allow merging into a yet-to-be-born branch.
From: Junio C Hamano @ 2006-11-22 5:24 UTC (permalink / raw)
To: git
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is not useful in a freshly initialized repository, since
it would not have any commits that you can use with the
command. But you can push into the repository and then later
use the updated branch to merge into your 'master' branch
that still does not exist yet.
git-merge.sh | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index 25deb1e..dd4e83d 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -159,6 +159,24 @@ then
shift
head_arg="$1"
shift
+elif ! git-rev-parse --verify HEAD 2>/dev/null
+then
+ # If the merged head is a valid one there is no reason to
+ # forbid "git merge" into a branch yet to be born. We do
+ # the same for "git pull".
+ if test 1 -ne $#
+ then
+ echo >&2 "Can merge only exactly one commit into empty head"
+ exit 1
+ fi
+
+ rh=$(git rev-parse --verify "$1^0") ||
+ die "$1 - not something we can merge"
+
+ git-update-ref -m "initial pull" HEAD "$rh" "" &&
+ git-read-tree --reset -u HEAD
+ exit
+
else
# We are invoked directly as the first-class UI.
head_arg=HEAD
--
1.4.4.g26805
^ permalink raw reply related
* Re: A documentation to-do list
From: Alan Chandler @ 2006-11-22 5:29 UTC (permalink / raw)
To: git
In-Reply-To: <6efbd9b70611211713y4a1574adje48622f7bab6d702@mail.gmail.com>
On Wednesday 22 November 2006 01:13, Chris Riddoch wrote:
> Hi, everyone.
>
> Having decided to take it on myself to improve Git's documentation, I
> asked on #git if people had particular things they felt I should focus
> on. I also was prompted to put up a page on the wiki to make my to-do
> list public.
>
> So, I present: http://git.or.cz/gitwiki/Documentation_To-Do_List
>
> Add your favorite, specific, lack-of-documentation or badly-described
> annoyance here!
Timely, although I will ask the question here rather than there.
I have started to use git-rebase a lot to try and sort out a project that has
got lots of long chains of commits on parallel branches doing roughly the
same thing. But I do not understand what the --merge flag is about.
git-rebase is clearly doing some form of merge for every commit it moves
without the --merge flag, so what does it add?
I thought I understood merging, but clearly I don't.
--
Alan Chandler
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Petr Baudis @ 2006-11-22 5:29 UTC (permalink / raw)
To: git
In-Reply-To: <20061120215116.GA20736@admingilde.org>
On Mon, Nov 20, 2006 at 10:51:16PM CET, Martin Waitz wrote:
> The current status can be viewed in
> http://git.admingilde.org/tali/git.git/module2
> (on top of next)
(For those wondering, a diff of the changes is at:
http://git.admingilde.org/tali/git.git/?a=commitdiff;h=module2;hp=next
Any bright ideas on how to best make such diffs reachable in the UI?)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* [PATCH] Store peeled refs in packed-refs (take 2).
From: Junio C Hamano @ 2006-11-22 7:36 UTC (permalink / raw)
To: git
This fixes the previous implementation which failed to optimize
repositories with tons of lightweight tags. The updated
packed-refs format begins with "# packed-refs with:" line that
lists the kind of extended data the file records. Currently,
there is only one such extension defined, "peeled". This stores
the "peeled tag" on a line that immediately follows a line for a
tag object itself in the format "^<sha-1>".
The header line itself and any extended data are ignored by
older implementation, so packed-refs file generated with this
version can still be used by older git. packed-refs made by
older git can of course be used with this version.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-pack-refs.c | 8 +++-
builtin-show-ref.c | 6 ++-
refs.c | 111 +++++++++++++++++++++++++++++---------------------
refs.h | 7 +--
4 files changed, 77 insertions(+), 55 deletions(-)
diff --git a/builtin-pack-refs.c b/builtin-pack-refs.c
index ee5a556..8dc5b9e 100644
--- a/builtin-pack-refs.c
+++ b/builtin-pack-refs.c
@@ -46,8 +46,8 @@ static int handle_one_ref(const char *pa
if (o->type == OBJ_TAG) {
o = deref_tag(o, path, 0);
if (o)
- fprintf(cb->refs_file, "%s %s^{}\n",
- sha1_to_hex(o->sha1), path);
+ fprintf(cb->refs_file, "^%s\n",
+ sha1_to_hex(o->sha1));
}
}
@@ -111,6 +111,10 @@ int cmd_pack_refs(int argc, const char *
if (!cbdata.refs_file)
die("unable to create ref-pack file structure (%s)",
strerror(errno));
+
+ /* perhaps other traits later as well */
+ fprintf(cbdata.refs_file, "# pack-refs with: peeled \n");
+
for_each_ref(handle_one_ref, &cbdata);
fflush(cbdata.refs_file);
fsync(fd);
diff --git a/builtin-show-ref.c b/builtin-show-ref.c
index 9ae3d08..0739798 100644
--- a/builtin-show-ref.c
+++ b/builtin-show-ref.c
@@ -67,8 +67,10 @@ match:
return 0;
if ((flag & REF_ISPACKED) && !peel_ref(refname, peeled)) {
- hex = find_unique_abbrev(peeled, abbrev);
- printf("%s %s^{}\n", hex, refname);
+ if (!is_null_sha1(peeled)) {
+ hex = find_unique_abbrev(peeled, abbrev);
+ printf("%s %s^{}\n", hex, refname);
+ }
}
else {
obj = parse_object(sha1);
diff --git a/refs.c b/refs.c
index 75cbc0e..96ea8b6 100644
--- a/refs.c
+++ b/refs.c
@@ -5,14 +5,18 @@
#include <errno.h>
+/* ISSYMREF=01 and ISPACKED=02 are public interfaces */
+#define REF_KNOWS_PEELED 04
+
struct ref_list {
struct ref_list *next;
- unsigned char flag; /* ISSYMREF? ISPACKED? ISPEELED? */
+ unsigned char flag; /* ISSYMREF? ISPACKED? */
unsigned char sha1[20];
+ unsigned char peeled[20];
char name[FLEX_ARRAY];
};
-static const char *parse_ref_line(char *line, unsigned char *sha1, int *flag)
+static const char *parse_ref_line(char *line, unsigned char *sha1)
{
/*
* 42: the answer to everything.
@@ -23,7 +27,6 @@ static const char *parse_ref_line(char *
* +1 (newline at the end of the line)
*/
int len = strlen(line) - 42;
- int peeled = 0;
if (len <= 0)
return NULL;
@@ -32,29 +35,18 @@ static const char *parse_ref_line(char *
if (!isspace(line[40]))
return NULL;
line += 41;
-
- if (isspace(*line)) {
- /* "SHA-1 SP SP refs/tags/tagname^{} LF"? */
- line++;
- len--;
- peeled = 1;
- }
+ if (isspace(*line))
+ return NULL;
if (line[len] != '\n')
return NULL;
line[len] = 0;
- if (peeled && (len < 3 || strcmp(line + len - 3, "^{}")))
- return NULL;
-
- if (!peeled)
- *flag &= ~REF_ISPEELED;
- else
- *flag |= REF_ISPEELED;
return line;
}
static struct ref_list *add_ref(const char *name, const unsigned char *sha1,
- int flag, struct ref_list *list)
+ int flag, struct ref_list *list,
+ struct ref_list **new_entry)
{
int len;
struct ref_list **p = &list, *entry;
@@ -66,8 +58,11 @@ static struct ref_list *add_ref(const ch
break;
/* Same as existing entry? */
- if (!cmp)
+ if (!cmp) {
+ if (new_entry)
+ *new_entry = entry;
return list;
+ }
p = &entry->next;
}
@@ -75,10 +70,13 @@ static struct ref_list *add_ref(const ch
len = strlen(name) + 1;
entry = xmalloc(sizeof(struct ref_list) + len);
hashcpy(entry->sha1, sha1);
+ hashclr(entry->peeled);
memcpy(entry->name, name, len);
entry->flag = flag;
entry->next = *p;
*p = entry;
+ if (new_entry)
+ *new_entry = entry;
return list;
}
@@ -114,27 +112,50 @@ static void invalidate_cached_refs(void)
ca->did_loose = ca->did_packed = 0;
}
+static void read_packed_refs(FILE *f, struct cached_refs *cached_refs)
+{
+ struct ref_list *list = NULL;
+ struct ref_list *last = NULL;
+ char refline[PATH_MAX];
+ int flag = REF_ISPACKED;
+
+ while (fgets(refline, sizeof(refline), f)) {
+ unsigned char sha1[20];
+ const char *name;
+ static const char header[] = "# pack-refs with:";
+
+ if (!strncmp(refline, header, sizeof(header)-1)) {
+ const char *traits = refline + sizeof(header) - 1;
+ if (strstr(traits, " peeled "))
+ flag |= REF_KNOWS_PEELED;
+ /* perhaps other traits later as well */
+ continue;
+ }
+
+ name = parse_ref_line(refline, sha1);
+ if (name) {
+ list = add_ref(name, sha1, flag, list, &last);
+ continue;
+ }
+ if (last &&
+ refline[0] == '^' &&
+ strlen(refline) == 42 &&
+ refline[41] == '\n' &&
+ !get_sha1_hex(refline + 1, sha1))
+ hashcpy(last->peeled, sha1);
+ }
+ cached_refs->packed = list;
+}
+
static struct ref_list *get_packed_refs(void)
{
if (!cached_refs.did_packed) {
- struct ref_list *refs = NULL;
FILE *f = fopen(git_path("packed-refs"), "r");
+ cached_refs.packed = NULL;
if (f) {
- struct ref_list *list = NULL;
- char refline[PATH_MAX];
- while (fgets(refline, sizeof(refline), f)) {
- unsigned char sha1[20];
- int flag = REF_ISPACKED;
- const char *name =
- parse_ref_line(refline, sha1, &flag);
- if (!name)
- continue;
- list = add_ref(name, sha1, flag, list);
- }
+ read_packed_refs(f, &cached_refs);
fclose(f);
- refs = list;
}
- cached_refs.packed = refs;
cached_refs.did_packed = 1;
}
return cached_refs.packed;
@@ -177,7 +198,7 @@ static struct ref_list *get_ref_dir(cons
error("%s points nowhere!", ref);
continue;
}
- list = add_ref(ref, sha1, flag, list);
+ list = add_ref(ref, sha1, flag, list, NULL);
}
free(ref);
closedir(dir);
@@ -225,8 +246,7 @@ const char *resolve_ref(const char *ref,
if (lstat(path, &st) < 0) {
struct ref_list *list = get_packed_refs();
while (list) {
- if (!(list->flag & REF_ISPEELED) &&
- !strcmp(ref, list->name)) {
+ if (!strcmp(ref, list->name)) {
hashcpy(sha1, list->sha1);
if (flag)
*flag |= REF_ISPACKED;
@@ -348,8 +368,6 @@ static int do_one_ref(const char *base,
return 0;
if (is_null_sha1(entry->sha1))
return 0;
- if (entry->flag & REF_ISPEELED)
- return 0;
if (!has_sha1_file(entry->sha1)) {
error("%s does not point to a valid object!", entry->name);
return 0;
@@ -368,22 +386,21 @@ int peel_ref(const char *ref, unsigned c
if ((flag & REF_ISPACKED)) {
struct ref_list *list = get_packed_refs();
- int len = strlen(ref);
while (list) {
- if ((list->flag & REF_ISPEELED) &&
- !strncmp(list->name, ref, len) &&
- strlen(list->name) == len + 3 &&
- !strcmp(list->name + len, "^{}")) {
- hashcpy(sha1, list->sha1);
- return 0;
+ if (!strcmp(list->name, ref)) {
+ if (list->flag & REF_KNOWS_PEELED) {
+ hashcpy(sha1, list->peeled);
+ return 0;
+ }
+ /* older pack-refs did not leave peeled ones */
+ break;
}
list = list->next;
}
- /* older pack-refs did not leave peeled ones in */
}
- /* otherwise ... */
+ /* fallback - callers should not call this for unpacked refs */
o = parse_object(base);
if (o->type == OBJ_TAG) {
o = deref_tag(o, ref, 0);
diff --git a/refs.h b/refs.h
index 40048a6..cd1e1d6 100644
--- a/refs.h
+++ b/refs.h
@@ -10,14 +10,13 @@ struct ref_lock {
int force_write;
};
+#define REF_ISSYMREF 01
+#define REF_ISPACKED 02
+
/*
* Calls the specified function for each ref file until it returns nonzero,
* and returns the value
*/
-#define REF_ISSYMREF 01
-#define REF_ISPACKED 02
-#define REF_ISPEELED 04 /* internal use */
-
typedef int each_ref_fn(const char *refname, const unsigned char *sha1, int flags, void *cb_data);
extern int head_ref(each_ref_fn, void *);
extern int for_each_ref(each_ref_fn, void *);
--
1.4.4.g26805
^ permalink raw reply related
* Re: [PATCH] Add support to git-branch to show local and remote branches
From: Andy Parkins @ 2006-11-22 8:53 UTC (permalink / raw)
To: git
In-Reply-To: <7vwt5owlhm.fsf@assigned-by-dhcp.cox.net>
On Tuesday 2006 November 21 21:14, Junio C Hamano wrote:
> Thanks. I'll drop the one in 'pu' and will replace with this
> patch but with style fixes and keeping the documentation updates
> from there.
Sorry; I must remember to write documentation. I'll be sure to look at the
style changes and try to adhere to that style in future.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH] gitweb: make HTML links out of http/https URLs in changelogs
From: Kir Kolyshkin @ 2006-11-22 9:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061122000655.GJ7201@pasky.or.cz>
Petr Baudis wrote:
> On Tue, Nov 21, 2006 at 11:02:36PM CET, Kir Kolyshkin wrote:
>
>> Slightly tested on http://git.openvz.org/. Applicable to git-1.4.4.
>>
>
> ...but in git's gitweb view it will make this <a
> href="http://git.openvz.org/.">http://git.openvz.org/.</a>. :-)
Not a problem actually since "." means "current directory", so it will
work fine (and I have checked that) :)
Sure there is a room for improvement for this regex -- and I am
collecting those.
^ permalink raw reply
* Adding glob support to remotes
From: Andy Parkins @ 2006-11-22 9:04 UTC (permalink / raw)
To: git
Hello,
I'm working on adding (basic) glob support to remote fetch definitions. This
is to allow you to write things like
[remote "origin"]
fetch = refs/heads/*:refs/remotes/upstream/*
I started to add code to git-parse-remote.sh:canon_refs_list_for_fetch() to
preprocess the reflist to catch lines with a "*" in them then use the remote
pattern to filter the output of from "git-ls-remote -h", blah, blah, you get
the idea...
However, git-ls-remote needs the name of the remote repository (of course),
but that isn't directly available in git-parse-remote.sh. Should I
a) pass it as a parameter from git-fetch.sh right through each intermediate
function
b) create a global?
c) change git-check-ref-format to allow "*" in the name, then put the
git-ls-remote call in git-fetch instead.
I don't like to do (b) as it's nasty programming behaviour; however passing a
parameter is fairly intrusive to the existing code. Similarly (c) means I'm
messing in places I suspect I shouldn't be (git-check-ref-format).
git-gods - what do I do?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH] xdiff: add xdl_merge() (was: (unknown))
From: Johannes Schindelin @ 2006-11-22 9:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Davide Libenzi, git
In-Reply-To: <ek0170$h53$1@sea.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4033 bytes --]
Hi,
On Wed, 22 Nov 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > [PATCH] xdiff: add xdl_merge()
>
> Shouldn't this be in the subject of message?
Did I mention that I was tired and hungry?
> > This new function implements the functionality of RCS merge, but
> > in-memory. It returns < 0 on error, otherwise the number of conflicts.
>
> Only RCS merge, or can you implement whole diff3 (from GNU diffutils)
> functionality with that?
As I am interested only in the in-memory merge, only RCS merge. Which
feature would you be interested in? An ed script? :-)
> > Finding the conflicting lines can be a very expensive task. You can
> > control the eagerness of this algorithm:
> >
> > - a level value of 0 means that all overlapping changes are treated
> > as conflicts,
> > - a value of 1 means that if the overlapping changes are identical,
> > it is not treated as a conflict.
> > - If you set level to 2, overlapping changes will be analyzed, so that
> > almost identical changes will not result in huge conflicts. Rather,
> > only the conflicting lines will be shown inside conflict markers.
> >
> > With each increasing level, the algorithm gets slower, but more accurate.
> > Note that the code for level 2 depends on the simple definition of
> > mmfile_t specific to git, and therefore it will be harder to port that
> > to LibXDiff.
>
> How it compares performance with RCS merge/GNU diff3?
Speedwise, I have no clue. It was enough work for a day.
Accuracywise: often I sent a patch (series) which was in my current git
tree (no topic branch), and Junio did some minor adjustments. I _hated_
the fact that RCS merge marked _all_ overlapping changes as conflicts,
even when there was just a minor correction here and there. And "git diff
--ours" does not help at all.
Here is where my implementation should help. With level 2, it will look
again at these conflicting regions, and only output the actual differences
as conflicts.
> It is really nice to have that. Bram Cohen (of Codeville, SCM built around
> sophisticated merge algorithm) wrote about recursive three-way merge in
> http://revctrl.org/CrissCrossMerge
>
> Recursive three-way merge _usually_ provides the right answer, however
> there are some edge cases. For example, conflict markers can be matched
> incorrectly, because they aren't given any special semantic meaning for
> the merge algorithm, and are simply treated as lines. In particular,
> there are (somewhat complicated) cases where the conflict markers of two
> unrelated conflicts get matched against each other, even though the
> content sections of them are totally unrelated.
>
> I'm not sure if he has specific examples, or is it just theoretical talk,
> but having built-in merge would certainly help revursive merge strategy
> (and perhaps also git-rerere).
It should be easy to construct such an example. However, the relevance in
practice is about zero.
Git was built from the beginning to aim to do a merge as good as possible,
but not perfect. There is no such thing as a perfect merge algorithm. You
will always be able to construct cases which are mismerged.
Thus, git takes the pragmatic approach and stops "early": merges work in
99% of the time, and in 99% of the remaining 1% the merge will fail so
that you know you have to fix it manually. (Take these numbers with a
grain of salt, please.) The advantage of stopping there is that we can
make it really fast.
You could probably raise the 99% to 99.5%, by implementing a "rebasing
merge", i.e. cherry-picking the branch-to-be-merged committing only in the
end (if there has not been any conflict). Obviously, this is slow as
Parnell's pitch[1].
As for git-rerere: I could not use it everywhere, because of some Perl
dependencies which I could not compile on some platforms. However, IMHO
git-rerere does not necessarily depend on merge being available in libgit.
Ciao,
Dscho
Footnote 1: http://www.physics.uq.edu.au/pitchdrop/pitchdrop.shtml
^ permalink raw reply
* Re: A documentation to-do list
From: Johannes Schindelin @ 2006-11-22 9:57 UTC (permalink / raw)
To: Chris Riddoch; +Cc: git
In-Reply-To: <6efbd9b70611211713y4a1574adje48622f7bab6d702@mail.gmail.com>
Hi,
On Tue, 21 Nov 2006, Chris Riddoch wrote:
> Having decided to take it on myself to improve Git's documentation, I
> asked on #git if people had particular things they felt I should focus
> on.
I have a request, which is not about _what_ to document, but _how_. People
often complained about the bad introduction into git, pointing to
http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart for a "way
better" tutorial.
It would be really, really easy to just copy that, and describe git
instead of hg. (There is no mention of a license there, so that may not be
allowed, but then, it is too short and obvious to be copyrightable, isn't
it?) You will find that git commands are way shorter!
So, finally my request: we should _organize_ the documentation such that
your average Joe Programmer is able to get started with git in 1 minute.
If she is interested in more subtle operations, then she should have a
technical overview such as "Branching and merging with git", maybe a
little stripped down to leave complicated (but for normal work
uninteresting) issues out. With a pot of steaming coffee.
Finally, for complicated issues, there is Documentation/technical, the man
pages, the source, and the git list (in that order).
Hmmm?
Ciao,
Dscho
^ permalink raw reply
* Struggling with tangled
From: Alan Chandler @ 2006-11-22 10:37 UTC (permalink / raw)
To: Git Mailing List
I am trying to sort out a tangled (in the sense that I several branches that
split a long time ago, but are reasonably close subsets of each other)
repository of mine using git rebase. I want to isolate the commits that
cause the key differences so that I can then easily enhance the code but
carry forward the variants (using git-rebase again probably).
I have some questions which are causing me some grief after merge conflicts.
Can someone help me.
1) I often edit a merge conflicted file to the state I expect it to be in at
the end. This sometimes means that I edit it to a state where no change is
seen. git-update-index notices this and doesn't do anything, but when I try
git-rebase --continue it won't because it says git-update-index has not been
run. What am I supposed to do then? [Is the answer git-rebase --skip ?]
2) Some files get completely munged with conflict resolution markers every
few lines. Is there a simple way to say "don't use this file, but use the
[stage2/stage3] sources of the merge". (ie one of the original inputs to the
merge - and if so, which one is which)
3) I sometime hit a merge conflict in a file which I know will actually be
deleted at the tip of the topic I am rebasing. Is there a way at this point
to just tell the conflict resolution to say make this file go away.
4) I repeat the question I asked in a thread above. What is the --merge
switch on git-rebase actually do. The man page starts talking about merge
strategies, but there already is a -s switch for that.
--
Alan Chandler
alan@chandlerfamily.org.uk
^ 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