* Re: Cleaning up git user-interface warts
From: Shawn Pearce @ 2006-11-20 19:46 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Junio C Hamano, hanwen, git
In-Reply-To: <200611201944.kAKJiCAw014973@laptop13.inf.utfsm.cl>
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote:
> If you make pushing into an empty repository work also, you fix the case of
> "create an empty repo for somebody, let them fill it up remotely later".
This seems to work just fine now. I do it all of the time.
--
^ permalink raw reply
* Re: git-diff opens too many files?
From: Junio C Hamano @ 2006-11-20 19:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Nguyen Thai Ngoc Duy
In-Reply-To: <Pine.LNX.4.64.0611200832450.3692@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Anyway, there's two possible solutions:
>
> - simply make sure that you can have that many open files.
>
> If it's a Linux system, just increase the value of the file
> /proc/sys/fs/file-max, and you're done. Of course, if you're not the
> admin of the box, you may need to ask somebody else to do it for you..
>
> - we could try to make git not keep them mmap'ed for the whole time.
>
> Junio? This is your speciality, I'm not sure how painful it would be to
> unmap and remap on demand.. (or switch it to some kind of "keep the last
> <n> mmaps active" kind of thing to avoid having thousands and thousands of
> mmaps active).
60,000 files 1kB each is 60MB which is a peanuts these days, but
10kB each would be already nontrivial burden on 32-bit (20%
under 3+1 split), so even if we do the "read in small files
instead of mapping" we would need diff_unpopulate_filespec() calls.
I think after diffcore_rename() runs, the data in filespec is
used only once during final textual diff generation. We would
use once more before diff generation if diffcore_pickaxe() is in
use. These codepaths begin with diff_populate_filespec(), so if
we unpopulate them after diffcore_rename() runs nobody would
notice (other than performance degradation and strace showing us
reading the same thing twice).
The diffcore_rename() matrix code expects all filespecs involved
can be populated at the same time, but it should not be too hard
to change it to keep one dst and all src candidates populated
but others dropped if space gets tight. I need to look at the
code for the details.
But Nguyen's command line did not have -M; I think the filespecs
are populated only during the text generation in that case, so
the above would not help him while it would be a worthwhile
change.
Because there is _no_ processing that comes after textual diff
generation that looks at the data, I think diff_flush_patch()
after calling run_diff() can unpopulate the data from the
filepair *p before returning without harming performance.
I think diff_flush_stat() and diff_flush_checkdiff() would have
the same issue, though. Ideally these should be able to do
their processing while the main textual diff holds the data in
memory for its processing but that is currently not the way the
code is structured.
^ permalink raw reply
* Re: Shouldn't git-ls-files --others use $GIT_DIR?
From: Nikolai Weibull @ 2006-11-20 19:51 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061119183756.GZ7201@pasky.or.cz>
On 11/19/06, Petr Baudis <pasky@suse.cz> wrote:
> On Sun, Nov 19, 2006 at 02:37:42PM CET, Nikolai Weibull wrote:
> > If I do
> >
> > GIT_DIR=$HOME/projects/<project>/.git git ls-files --others
> >
> > from, e.g., $HOME, I get a list of all the files in $HOME and its
> > subdirectories that aren't in said git repository. Shouldn't --others
> > use $GIT_DIR, instead of ".", or am I missing something here?
>
> git-ls-files --others lists untracked files in the current directory by
> comparing it to the index stored in $GIT_DIR/index and listing files
> present in the current directory but not in the index.
Ah, of course; how silly of me. Thanks.
^ permalink raw reply
* Re: [PATCH] git-merge: make it usable as the first class UI
From: Junio C Hamano @ 2006-11-20 19:52 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <200611201700.kAKH0msM012002@laptop13.inf.utfsm.cl>
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
>> Most notably, $commit above can be any committish, so you can
>> say for example:
>>
>> git merge js/shortlog~2
>>
>> to merge early part of a topic branch without merging the rest
>> of it.
>
> "Early part", i.e., branch js/shortlog up to js/shortlog~2 or just that one
> commit?
"Early part up to that commit" -- this is not a cherry pick.
>> A custom merge message can be given with the new --message=<msg>
>> parameter. The message is prepended in front of the usual
>> "Merge ..." message autogenerated with fmt-merge-message.
>
> Why not -m too (consistency!)?
That form also is accepted, I think.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-20 20:02 UTC (permalink / raw)
To: git
In-Reply-To: <200611201944.kAKJiCAw014973@laptop13.inf.utfsm.cl>
Horst H. von Brand wrote:
> Junio C Hamano <junkio@cox.net> wrote:
>> Junio C Hamano <junkio@cox.net> writes:
>>> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>>>
>>>> [hanwen@haring y]$ git pull ../x
>>>> fatal: Needed a single revision
>>>> Pulling into a black hole?
>>
>> Having said all that, I happen to think that this particular
>> case of pulling into void could deserve to be special cased to
>> pretend it is a fast forward (after all, nothingness is an
>> ancestor of anything), if only to make new people's first
>> experience more pleasant.
>
> If you make pushing into an empty repository work also, you fix the case of
> "create an empty repo for somebody, let them fill it up remotely later".
That was only the _pull_ which didn't work in empty repo.
Fetch and push worked (and work) just fine with empty repo.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Patch to tutorial.txt
From: Alan Chandler @ 2006-11-20 20:11 UTC (permalink / raw)
To: git
In-Reply-To: <200611200949.32722.jnareb@gmail.com>
On Monday 20 November 2006 08:49, Jakub Narebski wrote:
> On Mon, 20 Nov 2006, Paolo Ciarrocchi wrote:
> >>> -made in each. To merge the changes made in the two branches, run
> >>> +made in each. To merge the changes made in experimental into master
> >> I would rather say:
> >> To merge the changes made in the two branches into master, run
> >
> > Why Jakub? There are only two branches, master and experimental.
> > While sitting in master and doing git pull . experimental I would
> > expect to merge I did in experimental into master. Changes did in
> > master are alreay merged in master. Am I wrong?
>
> For me, "merge" in "to merge the changes" phrase is merge in common-sense
> meaning of the world, not the SCM jargon. Merge the changes == join the
> changes, so you have to give both sides, both changes you join.
>
> Merge the changes == take changes in branch 'experimental' since forking,
> take changes in branch 'master' since forking, join those changes
> together (merge), and put the result of this joining (this merge) into
> branch 'master'.
>
> On the contrary, in "merge branch 'experimenta' into 'master'" phrase
> "merge" is in the SCM meaning of this word.
>
>
> Just my 2 eurocoents of not native English speaker...
As a native English speaker the way the tutorial was before any of these
changes meant that the contents of experimental and master had merged into
one, but there was not specific indication of where this merged result had
been put
From _your_ phrasing I took the meaning that there were two independent
branches which then got merged into master although that leaves me puzzled
because there is only one other independant branch and thats the experimental
one
I think the wording Paolo used is clearer and precisely right - we are merging
the experimental stuff into master and experimental remains as it was
(although in a fast forward experimental and master end up the same - this is
not true in the example in the tutorial which says that changes are made on
both branches).
--
Alan Chandler
^ permalink raw reply
* [PATCH] Doc: Make comment about merging in tutorial.txt more clear
From: Paolo Ciarrocchi @ 2006-11-20 20:29 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]
Rephrased a sentence in order to make more clear the concept of
pull . branch
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
Documentation/tutorial.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 554ee0a..646395d 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -141,7 +141,7 @@ $ git commit -a
------------------------------------------------
at this point the two branches have diverged, with different changes
-made in each. To merge the changes made in the two branches, run
+made in each. To merge the changes did in experimental into master, run
------------------------------------------------
$ git pull . experimental
--
1.4.4.ge3d4
--
Paolo
http://docs.google.com/View?docid=dhbdhs7d_4hsxqc8
http://www.linkedin.com/pub/0/132/9a3
Non credo nelle otto del mattino. Però esistono. Le otto del mattino
sono l'incontrovertibile prova della presenza del male nel mondo.
Gli ultimi giorni, Andrew Masterson
[-- Attachment #2: 0001-Doc-Make-comment-about-merging-in-tutorial.txt-more-clear.txt --]
[-- Type: text/plain, Size: 955 bytes --]
From 1a4e078515547c346b5d6e8b74abcd24b20acb78 Mon Sep 17 00:00:00 2001
From: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Date: Mon, 20 Nov 2006 21:25:47 +0100
Rephrased a sentence in order to make more clear the concept of
pull . branch
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
Documentation/tutorial.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 554ee0a..646395d 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -141,7 +141,7 @@ $ git commit -a
------------------------------------------------
at this point the two branches have diverged, with different changes
-made in each. To merge the changes made in the two branches, run
+made in each. To merge the changes did in experimental into master, run
------------------------------------------------
$ git pull . experimental
--
1.4.4.ge3d4
^ permalink raw reply related
* [BUG] StGit removed git branch of the same name as StGit branch
From: Jakub Narebski @ 2006-11-20 21:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
I have used StGit (wonderfull tool) to manage patches on git branch
gitweb/web. Unfortunately, I have named stg branch the same as git
branch. When removing stg branch (I wanted to remove
heads/base/gitweb/web) using "stg branch --delete gitweb/web" it
deleted also git branch when I wanted to remove only the StGit managed
indicator. Fortunately I was able to recover the branch from reflog, as
StGit didn't delete reflog with deletion of git branch.
Perhaps that is correct behavior... but certainly unexpected.
Stacked GIT 0.11
git version 1.4.3.4
Python version 2.4.3 (#1, Jun 13 2006, 16:41:18)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)]
--
Jakub Narebski
^ permalink raw reply
* Re: git-diff opens too many files?
From: Junio C Hamano @ 2006-11-20 21:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Nguyen Thai Ngoc Duy
In-Reply-To: <Pine.LNX.4.64.0611200832450.3692@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Junio? This is your speciality, I'm not sure how painful it would be to
> unmap and remap on demand.. (or switch it to some kind of "keep the last
> <n> mmaps active" kind of thing to avoid having thousands and thousands of
> mmaps active).
>
> One simple thing that might be worth it is to simply _not_ use mmap() at
> all for small files. If a file is less than 1kB, it might be better to do
> a malloc() and a read() - partly because it avoids having tons of file
> descriptors, but partly because it's also more efficient from a virtual
> memory usage perspective (not that you're probably very likely to ever
> really hit that problem in practice).
>
> Nguyen - that "use malloc+read" thing might be a quick workaround, but
> only if you have tons of _small_ files (and if you can't easily just
> increase file-max).
So here is a lunch-time hack to get Nguyen unstuck.
-- >8 --
[PATCH] diff.c: avoid mmap() of small files in populate_filespec()
This would hopefully behave better in VM usage. It is not a
real fix if you are dealing with truly huge diff, in which case
we would have to LRU out the data in memory for filespecs that
are not used in immediate future.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/diff.c b/diff.c
index 3315378..af50b6f 100644
--- a/diff.c
+++ b/diff.c
@@ -1294,11 +1294,22 @@ int diff_populate_filespec(struct diff_f
fd = open(s->path, O_RDONLY);
if (fd < 0)
goto err_empty;
- s->data = mmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
+ if (s->size < MINIMUM_MMAP) {
+ s->data = xmalloc(s->size);
+ s->should_free = 1;
+ if (xread(fd, s->data, s->size) != s->size) {
+ free(s->data);
+ goto err_empty;
+ }
+ }
+ else {
+ s->data = mmap(NULL, s->size, PROT_READ, MAP_PRIVATE,
+ fd, 0);
+ s->should_munmap = 1;
+ }
close(fd);
if (s->data == MAP_FAILED)
goto err_empty;
- s->should_munmap = 1;
}
else {
char type[20];
diff --git a/diffcore.h b/diffcore.h
index 2249bc2..f129aa0 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -21,6 +21,7 @@
#define DEFAULT_MERGE_SCORE 36000 /* maximum for break-merge to happen 60%) */
#define MINIMUM_BREAK_SIZE 400 /* do not break a file smaller than this */
+#define MINIMUM_MMAP 4096 /* do not mmap a file smaller than this */
struct diff_filespec {
unsigned char sha1[20];
^ permalink raw reply related
* Re: [BUG] StGit removed git branch of the same name as StGit branch
From: Junio C Hamano @ 2006-11-20 21:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611202201.45521.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> I have used StGit (wonderfull tool) to manage patches on git branch
> gitweb/web. Unfortunately, I have named stg branch the same as git
> branch. When removing stg branch (I wanted to remove
> heads/base/gitweb/web) using "stg branch --delete gitweb/web" it
> deleted also git branch when I wanted to remove only the StGit managed
> indicator. Fortunately I was able to recover the branch from reflog, as
> StGit didn't delete reflog with deletion of git branch.
>
> Perhaps that is correct behavior... but certainly unexpected.
I am also a novice who recently started appreciating the
convenience of StGIT. I _think_ the usage StGIT expect us to
follow is to run "stg clean" to make the series empty, and not
worry about leftover refs/bases/ at all, but I may well be
mistaken.
^ permalink raw reply
* Some tips for doing a CVS importer
From: Jon Smirl @ 2006-11-20 21:49 UTC (permalink / raw)
To: Git Mailing List
I have tried all of the available CVS importers. None of them are
without problems. If anyone is interested in writing one for git here
are some ideas on how to structure it.
1) there is a working lex/yacc for CVS in the parsecvs source code
2) The first time you parse a CVS file record everything and don't
parse it again.
3) When the file is first parsed use the deltas to generate the
revisions and feed them to git-fastimport, just remember the SHA1 or
an id in the import code. This is a critical step to getting decent
performance.
4) If you do #1 and #2 you don't need to store CVS revision numbers
and file names in memory. Because of that you can can easily do a
Mozilla import in 2GB, probably 1GB.
5) When comparing CVS revisions only use the CVS timestamps as a last
resort, instead use the dependency information in the CVS file
6) Match up commits by using an sha1 of the author and commit message
7) After all files are loaded, match up the symbols and insert them
into the dependency chains, if any of the symbols depend on a branch
commit the symbol lies on the branch, otherwise the symbol is on the
trunk,
8) Do a topological sort to build the change set commit tree
9) when you hit a loop in the tree break up delta change sets until
the loop can be removed, don't break up symbol change sets.
10) Mozilla has some large commits that were made over dial up. Commit
change sets can span hours. All of these commits need to be merged
into a single change set.
11) An algorithm needs to be developed for detecting branches merging
back into the trunk
12) cvs2svn has excellent test cases, use them to test the new
importer. The cvs2svn code is quite nice but it doesn't handle #7
--
Jon Smirl
^ permalink raw reply
* [RFC] Submodules in GIT
From: Martin Waitz @ 2006-11-20 21:51 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 6400 bytes --]
I am currently working on adding submodule support to GIT.
Here I am presenting some prototyping work to show how submodules could
be implemented in GIT.
What is a submodule
-------------------
A submodule in a GIT repository which is managed by another higher-layer
parent repository. Both the submodule and the parent repository can be
used as a normal GIT repository but there are links between them. That
means that you can merge, push and pull both on the parent and on
individual submodule level.
The parent repository is special in that it does not only hold individual
files but also complete submodule trees, complete with their own history.
The history of the parent and the submodule are independent, but each
version of the parent is linked to exactly one version of the submodule.
The submodule is special in that it has one special branch which is tracked
by the parent. Each time something is commited to this branch, this
automatically changes the parent, just like modifying normal files. Each
time the parent gets updated, this submodule branch gets updated
automatically.
As a submodule has all the properties of a normal GIT repository,
it can also contain submodules itself.
Previous submodule proposal
---------------------------
My first experiment in implementing submodules was a very simple one: Store
the submodule refs in the working directory of the parent repository and
include them in the version control.
This way the most important properties of submodules are easily to obtain.
Each version of the parent stores the exact version of all submodules and
with the help of some shell scripts it is easily possible to update the
submodule when there are updates to the parent repository.
However, this easy approach has several drawbacks. The most important one
is that the GIT core does not know about submodules, they are only built on
top of them. For this reason it is difficult to support fsck-objects and
prune in such a setup.
In order to permanently keep all previous stages of the parent, there is
the need to also keep all versions of the submodules which have been linked
to the parent. All operations which have to walk the entire object database
have to know all possible references of the submodule. This is easy if the
submodule is only fast-forwarded, without switching branches and without
removing the submodule. Under these conditions it is enough to walk the
current reference of the submodule which is stored in its parent. But if
there are past versions of the submodule which are not reachable by the
current submodule commit then it is difficult to keep them in the database
when the submodule is handled by a standard GIT core. This could only be
solved by creating fake references for all possible versions of the
submodule.
New approach
------------
In order to make the GIT core know about all possible versions of the
submodule it is not enough to store one reference in the parent working
directory. The GIT core has to be changed so that it knows about all
submodule references while traversing the parent repository. This means
that both the submodule and the parent repository have to use the same
object database. (I already did this for my first experiment, but it was
not really neccessary at that time.)
A submodule really is part of the parent tree, so it is very natural to
add the link to the submodule commit into the GIT tree data structure.
In addition to links to blobs and other trees, they can now also hold
a link to a commit, which in turn has the pointers to the submodule tree
and its history. In order to differenciate a submodule entry with
normal file or directory entries, they get a special file mode.
Directly including the submodules in the object database allows the
traversal of the entire repository, together with the parent and all
submodules. In this way it is possible to support fsck-objects and prune
when they are executed in the parent repository. However, submodules can
contain branches which are independent from the one stored in the parent.
So all references and the working directory index of the submodules have
to be made available to the parent, too.
When a parent containing submodules is checked out, the submodul entry is
stored in the index, just like it is done for all normal files. But instead
of writing one file to the working directory, a complete GIT repository is
created (with the object database linked to the parent one). This submodule
gets a reference "refs/heads/module" from the parent's index entry.
The index entry in the parent can be updated with update-index just
like other entries.
When a merge in the parent has to resolve changes in the submodule,
then it does exactly the same as for files: at first it is tried to resolve
it in the index and if this is not possible it will have store stages 1-3
in the index and tries a content merge. The only difference with submodules
is that the content merge is not possible with a simple diff3 call, but
that the GIT merge machinery has to recurse into the submodule.
Implementation
--------------
Obviously, all the tree traversal routines have to be modified to recognize
a submodule and to correctly traverse it. The submodule entry gets
a special S_IFSOCK file mode to distinguish it from other entries.
This special file mode is used for both the tree entries in the object
database and for the index entries of the submodule in the parent index.
Some basic low-level commands now (more or less) cope with submodules.
Merging of submodules has not yet been implemented.
The current status can be viewed in
http://git.admingilde.org/tali/git.git/module2
(on top of next)
The code now passes the small test-script so at least a little bit of
it must be working ;-). Please feel free to give it a try and complain
that it does not work the way you expect it.
What's next?
------------
The most important next step is to commit to some object database format
for submodules. So please, do give feedback about the proposed changes
to the tree object.
The second most important step is to make it possible to merge submodules.
After that, for sure there are enough bugs to fix to keep me busy for some
time... ;-)
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Jakub Narebski @ 2006-11-20 22:16 UTC (permalink / raw)
To: git
In-Reply-To: <20061120215116.GA20736@admingilde.org>
Martin Waitz wrote:
> A submodule really is part of the parent tree, so it is very natural to
> add the link to the submodule commit into the GIT tree data structure.
> In addition to links to blobs and other trees, they can now also hold
> a link to a commit, which in turn has the pointers to the submodule tree
> and its history. In order to differenciate a submodule entry with
> normal file or directory entries, they get a special file mode.
Erm... isn't a _type_ of tree entry saved somewhere? Currently it can
be only 'tree' or 'blob', what you do is adding 'commit' (then permissions
are permissions of top tree of module, of course).
By the way, in todo branch, in Subpro.txt, there is talk about adding
link to submodule trees in _commit object_... well link to submodule tree
or commit, with the "mount point".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [BUG] StGit removed git branch of the same name as StGit branch
From: J. Bruce Fields @ 2006-11-20 22:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Catalin Marinas, git
In-Reply-To: <200611202201.45521.jnareb@gmail.com>
On Mon, Nov 20, 2006 at 10:01:44PM +0100, Jakub Narebski wrote:
> I have used StGit (wonderfull tool) to manage patches on git branch
> gitweb/web. Unfortunately, I have named stg branch the same as git
> branch. When removing stg branch (I wanted to remove
> heads/base/gitweb/web) using "stg branch --delete gitweb/web" it
> deleted also git branch when I wanted to remove only the StGit managed
> indicator.
You probably actually had to "stg branch --delete --force", didn't you?
What you want is "stg commit".
> Perhaps that is correct behavior... but certainly unexpected.
I think "stg branch --delete" is pretty clearly named and documented....
The idea I guess was to make it possible to use stgit (and only stgit)
for everything, and never type a git command. It might have been better
to make stgit only manage patch series, and admit that people should use
git for the rest. Then it might work more like you expect.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-11-20 22:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejt9dh$kfm$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]
hoi :)
On Mon, Nov 20, 2006 at 11:16:45PM +0100, Jakub Narebski wrote:
> Martin Waitz wrote:
> > A submodule really is part of the parent tree, so it is very natural to
> > add the link to the submodule commit into the GIT tree data structure.
> > In addition to links to blobs and other trees, they can now also hold
> > a link to a commit, which in turn has the pointers to the submodule tree
> > and its history. In order to differenciate a submodule entry with
> > normal file or directory entries, they get a special file mode.
>
> Erm... isn't a _type_ of tree entry saved somewhere? Currently it can
> be only 'tree' or 'blob', what you do is adding 'commit' (then permissions
> are permissions of top tree of module, of course).
It is saved inside the object which is being refered to.
Right now tree objects are also identified by their file mode and not
by the type of object which is referenced.
> By the way, in todo branch, in Subpro.txt, there is talk about adding
> link to submodule trees in _commit object_... well link to submodule tree
> or commit, with the "mount point".
But isn't the submodule really part of the tree?
Right now the commit is used to construct the history of one project.
And a submodule is not part of the history of the parent, it is part
of the parent's tree.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Documentation tutorial.txt: Teach the reader about git commit -a -s
From: Paolo Ciarrocchi @ 2006-11-20 22:30 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 820 bytes --]
I think it's important to mention, in the collaboration section,
that is possible to use the -s option to add the Signed-off-by
line
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
Documentation/tutorial.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 554ee0a..402afdf 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -200,7 +200,7 @@ Bob then makes some changes and commits
------------------------------------------------
(edit files)
-$ git commit -a
+$ git commit -a (add -s to add Signed-off-by line at the end of the
commit message)
(repeat as necessary)
------------------------------------------------
--
1.4.4.gef06
--
Paolo
http://www.linkedin.com/pub/0/132/9a3
[-- Attachment #2: 0001-Documentation-Teach-the-reader-about-git-commit-a-s.txt --]
[-- Type: text/plain, Size: 1007 bytes --]
From 1d1eed70816997eeb181a5493cec9f58467bd01e Mon Sep 17 00:00:00 2001
From: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Date: Mon, 20 Nov 2006 23:28:16 +0100
Subject: [PATCH] Documentation: Teach the reader about git commit -a -s
I think it's important to mention, in the collaboration section,
that is possible to use the -s option to add the Signed-off-by
line
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
Documentation/tutorial.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 554ee0a..402afdf 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -200,7 +200,7 @@ Bob then makes some changes and commits
------------------------------------------------
(edit files)
-$ git commit -a
+$ git commit -a (add -s to add Signed-off-by line at the end of the commit message)
(repeat as necessary)
------------------------------------------------
--
1.4.4.gef06
^ permalink raw reply related
* Re: [BUG] StGit removed git branch of the same name as StGit branch
From: Jakub Narebski @ 2006-11-20 22:37 UTC (permalink / raw)
To: git
In-Reply-To: <20061120222812.GE12285@fieldses.org>
J. Bruce Fields wrote:
> On Mon, Nov 20, 2006 at 10:01:44PM +0100, Jakub Narebski wrote:
>
>> I have used StGit (wonderfull tool) to manage patches on git branch
>> gitweb/web. Unfortunately, I have named stg branch the same as git
>> branch. When removing stg branch (I wanted to remove
>> heads/base/gitweb/web) using "stg branch --delete gitweb/web" it
>> deleted also git branch when I wanted to remove only the StGit managed
>> indicator.
>
> You probably actually had to "stg branch --delete --force", didn't you?
Nope. "stg branch --delete gitweb/web"
> What you want is "stg commit".
No. Whole stack was committed, I wanted only get rid of
heads/base/gitweb/web (of StGit managed branch indicator).
>> Perhaps that is correct behavior... but certainly unexpected.
>
> I think "stg branch --delete" is pretty clearly named and documented....
I thought it delete only stg branch, refs/base/gitwbe/web, and not
refs/heads/gitweb/web.
> The idea I guess was to make it possible to use stgit (and only stgit)
> for everything, and never type a git command. It might have been better
> to make stgit only manage patch series, and admit that people should use
> git for the rest. Then it might work more like you expect.
Yes, I expected to use StGit as a kind of preprocessing (branch preparation)
for git.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Junio C Hamano @ 2006-11-20 22:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: jnareb
In-Reply-To: <ejt9dh$kfm$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> By the way, in todo branch, in Subpro.txt, there is talk about adding
> link to submodule trees in _commit object_... well link to submodule tree
> or commit, with the "mount point".
That was shot down by Linus and I agree with him. "bind" was a
bad idea because binding of a particular subproject commit into
a tree is a property of the tree, not one of the commits that
happen to have that tree.
^ permalink raw reply
* Re: [BUG] StGit removed git branch of the same name as StGit branch
From: J. Bruce Fields @ 2006-11-20 22:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejtal6$p8s$1@sea.gmane.org>
On Mon, Nov 20, 2006 at 11:37:54PM +0100, Jakub Narebski wrote:
> J. Bruce Fields wrote:
> > You probably actually had to "stg branch --delete --force", didn't you?
>
> Nope. "stg branch --delete gitweb/web"
>
> > What you want is "stg commit".
>
> No. Whole stack was committed, I wanted only get rid of
> heads/base/gitweb/web (of StGit managed branch indicator).
Oh, right, got it.
> > The idea I guess was to make it possible to use stgit (and only stgit)
> > for everything, and never type a git command. It might have been better
> > to make stgit only manage patch series, and admit that people should use
> > git for the rest. Then it might work more like you expect.
>
> Yes, I expected to use StGit as a kind of preprocessing (branch preparation)
> for git.
The multiple-porcelains idea seems like a mistake to me--it'd be fine if
you're just adding new features on the side, but who wants to learn
entirely different sets of commands, with subtly different syntax,
semantics, and feature sets, for doing the same thing?
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Jakub Narebski @ 2006-11-20 22:49 UTC (permalink / raw)
To: git
In-Reply-To: <20061120215116.GA20736@admingilde.org>
Could you please add to http://git.or.cz/gitwiki/SubprojectSupport
(even if all it would be is a link to archive of this thread)? TIA.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation tutorial.txt: Teach the reader about git commit -a -s
From: J. Bruce Fields @ 2006-11-20 22:52 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30611201430l6135814yc89f4abdb9044340@mail.gmail.com>
On Mon, Nov 20, 2006 at 11:30:56PM +0100, Paolo Ciarrocchi wrote:
> I think it's important to mention, in the collaboration section,
> that is possible to use the -s option to add the Signed-off-by
> line
>
> Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
The -s option is easy to learn later, and isn't really necessary for
basic project management; I'd rather leave it out of the first tutorial.
(In fact, the best place for it may be in SubmittingPatches or
equivalent for the particular project.)
^ permalink raw reply
* Re: [BUG] StGit removed git branch of the same name as StGit branch
From: Jakub Narebski @ 2006-11-20 22:57 UTC (permalink / raw)
To: git
In-Reply-To: <20061120224800.GF12285@fieldses.org>
J. Bruce Fields wrote:
> On Mon, Nov 20, 2006 at 11:37:54PM +0100, Jakub Narebski wrote:
>> J. Bruce Fields wrote:
>>> The idea I guess was to make it possible to use stgit (and only stgit)
>>> for everything, and never type a git command. It might have been better
>>> to make stgit only manage patch series, and admit that people should use
>>> git for the rest. Then it might work more like you expect.
>>
>> Yes, I expected to use StGit as a kind of preprocessing (branch preparation)
>> for git.
>
> The multiple-porcelains idea seems like a mistake to me--it'd be fine if
> you're just adding new features on the side, but who wants to learn
> entirely different sets of commands, with subtly different syntax,
> semantics, and feature sets, for doing the same thing?
I don't think so. StGit seems that way because it mainly adds new feature:
patch management. But it can be used both as standalone SCM (like Quilt),
or as a tool to manage patches in branch (rebase/cherry-pick on steroids).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Jakub Narebski @ 2006-11-20 23:02 UTC (permalink / raw)
To: git
In-Reply-To: <7v7ixp20za.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> By the way, in todo branch, in Subpro.txt, there is talk about adding
>> link to submodule trees in _commit object_... well link to submodule tree
>> or commit, with the "mount point".
>
> That was shot down by Linus and I agree with him. "bind" was a
> bad idea because binding of a particular subproject commit into
> a tree is a property of the tree, not one of the commits that
> happen to have that tree.
"bind" was kind of "mount tree" idea; I agree that adding subproject
commits to trees is better idea than adding commits or trees to
superproject commit object.
By the way, what permissions get the subproject tree?
I wonder if it makes sense to be able to add tag objects instead
of commit objects to trees (depeel to tree or blob)...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Some tips for doing a CVS importer
From: Martin Langhoff @ 2006-11-20 23:03 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910611201349s4d08b984g772c64982f148bfa@mail.gmail.com>
On 11/21/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> I have tried all of the available CVS importers. None of them are
> without problems. If anyone is interested in writing one for git here
> are some ideas on how to structure it.
Hi Jon,
I gather this means that the cvs2svn track hasn't been as productive
as expected. Any remaining/unsolvable issues with it? I have been
chronically busy on my e-learning projects, but don't discard coming
back to this when I have some time.
cheers,
^ permalink raw reply
* Re: [PATCH] Documentation tutorial.txt: Teach the reader about git commit -a -s
From: Junio C Hamano @ 2006-11-20 23:03 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30611201430l6135814yc89f4abdb9044340@mail.gmail.com>
"Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
> I think it's important to mention, in the collaboration section,
> that is possible to use the -s option to add the Signed-off-by
> line
>
> Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
S-O-B is a project convention that follows the patch acceptance
policy similar to the kernel, and I am a bit reluctant to tell
people to use -s before making it clear what the legal intent of
that line is. And git tutorial is not the place to talk about
the patch acceptance policy of the git project.
So instead, my preference is to suggest people to use "commit
-s" in "Documentation/SubmittingPatches" section. That _is_
about the git project, and I think it helps the users that the
same rule/tip applies to the kernel by making it clear that the
convention and legal intent of S-O-B were borrowed from them.
I am slightly disturbed by
> ------------------------------------------------
> (edit files)
> +$ git commit -a (add -s to add Signed-off-by line at the end of the
> commit message)
> (repeat as necessary)
> ------------------------------------------------
this formatting. The examples that begin with '$' are meant to
be "copy-me" examples, and we do "# comment" elsewhere for
exactly that reason.
If your MUA corrupts patches, then working it around by using
attachment is tolerated, but please do try to see if you can
make your MUA behave first. Attachments are hard to comment on
inline.
If you need to do an attachment, please do not include the patch
twice. That is a lot worse than having your patch only in the
attachment. I need to detach only the attachment part, compare
it with what were discussed on the list based on the patch that
was in the non-attachment part of your message to make sure
there is no inconsistency between the two, and then apply the
one from the attachment separately.
Instead, make the first "text" part of the multipart to contain
the proposed commit log message, and make sure that the rest of
the message (if multipart, then mailinfo will unwrap them for me
and concatenate them together after the first '---' in the cover
text) does not have the same patch twice.
Your message has the first text part in "format=flawed", which
included a corrupted patch, and then the attachment contained a
full format-patch output. As a result, taken as a whole the
message includes the patch twice (once corrupted and then
uncorrupted). Please don't.
^ 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