* Re: [PATCH] Documentation/RelNotes-1.6.0.txt: Expand on the incompatible packfiles
From: Petr Baudis @ 2008-07-17 17:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <g5nue6$3ek$1@ger.gmane.org>
On Thu, Jul 17, 2008 at 07:10:32PM +0200, Jakub Narebski wrote:
> Petr Baudis wrote:
>
> > +introduced in v1.5.2 and v1.4.4.5. If you want to keep your repositories
> > +backwards compatible past these versions, set repack.useDeltaBaseOffset
> > +to false or pack.indexVersion to 1, respectively.
>
> 'or'? Not 'and'?
>
> You shouldn't have, I think, this "respectively" here. You need it only
> if you are writing "a, b, c, then a', b', c', respectively".
The "respectively" means that the two options relate each to one of the
two new features. I'm unclear about the 'or'-'and' question, though.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] Documentation/RelNotes-1.6.0.txt: Expand on the incompatible packfiles
From: Jakub Narebski @ 2008-07-17 17:10 UTC (permalink / raw)
To: git
In-Reply-To: <20080717170118.14083.87086.stgit@localhost>
Petr Baudis wrote:
> +introduced in v1.5.2 and v1.4.4.5. If you want to keep your repositories
> +backwards compatible past these versions, set repack.useDeltaBaseOffset
> +to false or pack.indexVersion to 1, respectively.
'or'? Not 'and'?
You shouldn't have, I think, this "respectively" here. You need it only
if you are writing "a, b, c, then a', b', c', respectively".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Documentation/RelNotes-1.6.0.txt: Expand on the incompatible packfiles
From: Petr Baudis @ 2008-07-17 17:01 UTC (permalink / raw)
To: gitster; +Cc: git
Note that v1.4.4.5 supports pack index v2, and describe how to keep
your repositories backwards-compatible, shall you need to.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/RelNotes-1.6.0.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/RelNotes-1.6.0.txt b/Documentation/RelNotes-1.6.0.txt
index b29ba25..9bbb07e 100644
--- a/Documentation/RelNotes-1.6.0.txt
+++ b/Documentation/RelNotes-1.6.0.txt
@@ -21,7 +21,9 @@ main git.git codebase.
By default, packfiles created with this version uses delta-base-offset
encoding introduced in v1.4.4. Pack idx files are using version 2 that
allows larger packs and added robustness thanks to its CRC checking,
-introduced in v1.5.2.
+introduced in v1.5.2 and v1.4.4.5. If you want to keep your repositories
+backwards compatible past these versions, set repack.useDeltaBaseOffset
+to false or pack.indexVersion to 1, respectively.
GIT_CONFIG, which was only documented as affecting "git config", but
actually affected all git commands, now only affects "git config".
^ permalink raw reply related
* [PATCH] cvsserver: Add cvs co -c support
From: Lars Noschinski @ 2008-07-17 17:00 UTC (permalink / raw)
To: git, gitster; +Cc: lars, fabian.emmes
In-Reply-To: <1216314030-10887-4-git-send-email-lars@public.noschinski.de>
Implement cvs checkout's -c option by returning a list of all "modules".
This is more useful than displaying a perl warning if -c is given.
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
git-cvsserver.perl | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 66aebf8..064952e 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -801,6 +801,18 @@ sub req_co
argsplit("co");
+ # Provide list of modules, if -c was used.
+ if (exists $state->{opt}{c}) {
+ my $showref = `git show-ref --heads`;
+ for my $line (split '\n', $showref) {
+ if ( $line =~ m% refs/heads/(.*)$% ) {
+ print "M $1\t$1\n";
+ }
+ }
+ print "ok\n";
+ return 1;
+ }
+
my $module = $state->{args}[0];
$state->{module} = $module;
my $checkout_path = $module;
--
1.5.6.2
^ permalink raw reply related
* [PATCH] testsuite for cvs co -c
From: Lars Noschinski @ 2008-07-17 17:00 UTC (permalink / raw)
To: git, gitster; +Cc: lars, fabian.emmes
In-Reply-To: <1216314030-10887-5-git-send-email-lars@public.noschinski.de>
From: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Check that all branches are displayed.
Signed-off-by: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
t/t9400-git-cvsserver-server.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 8120087..4b91f8d 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -477,4 +477,15 @@ test_expect_success 'cvs status (no subdirs in header)' '
! grep / <../out
'
+#------------
+# CVS CHECKOUT
+#------------
+
+cd "$WORKDIR"
+test_expect_success 'cvs co -c (shows module database)' '
+ GIT_CONFIG="$git_config" cvs co -c > out &&
+ grep "^master[ ]\+master$" < out &&
+ ! grep -v "^master[ ]\+master$" < out
+'
+
test_done
--
1.5.6.2
^ permalink raw reply related
* Some cvs related fixes and enhancements v2
From: Lars Noschinski @ 2008-07-17 17:00 UTC (permalink / raw)
To: git, gitster; +Cc: lars, fabian.emmes
This patch series
- fixes a small bug in the cvsimport testsuite
- adds support for packed-refs to cvsserver
- adds basic support cvs co -c to cvsserver
Changes to v1:
- do not change output format of req_up (noticed by Johannes Schindelxein)
- test output of the cvs client instead of raw server output
- remove superfluous line from the "cvs co -c" patch
---
git-cvsserver.perl | 34 ++++++++++++++++++++--------------
t/t9400-git-cvsserver-server.sh | 18 ++++++++++++++++++
t/t9600-cvsimport.sh | 1 +
3 files changed, 39 insertions(+), 14 deletions(-)
^ permalink raw reply
* [PATCH] cvsserver: Add testsuite for packed refs
From: Lars Noschinski @ 2008-07-17 17:00 UTC (permalink / raw)
To: git, gitster; +Cc: lars, fabian.emmes
In-Reply-To: <1216314030-10887-3-git-send-email-lars@public.noschinski.de>
Check that req_update shows refs, even if all refs are packed.
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
t/t9400-git-cvsserver-server.sh | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index e97aaa6..8120087 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -438,6 +438,13 @@ test_expect_success 'cvs update (-p)' '
test -z "$(cat failures)"
'
+cd "$WORKDIR"
+test_expect_success 'cvs update (module list supports packed refs)' '
+ GIT_DIR="$SERVERDIR" git pack-refs --all &&
+ GIT_CONFIG="$git_config" cvs -n up -d 2> out &&
+ grep "cvs update: New directory \`master'\''" < out
+'
+
#------------
# CVS STATUS
#------------
--
1.5.6.2
^ permalink raw reply related
* [PATCH] Testsuite: Unset CVS_SERVER
From: Lars Noschinski @ 2008-07-17 17:00 UTC (permalink / raw)
To: git, gitster; +Cc: lars, fabian.emmes
In-Reply-To: <1216314030-10887-1-git-send-email-lars@public.noschinski.de>
From: Fabian Emmes <fabian.emmes@rwth-aachen.de>
The CVS_SERVER environment variable can cause some of the cvsimport tests
to fail. So unset this variable at the beginning of the test script.
Signed-off-by: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
t/t9600-cvsimport.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 1e01e5c..0d7786a 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -5,6 +5,7 @@ test_description='git-cvsimport basic tests'
CVSROOT=$(pwd)/cvsroot
export CVSROOT
+unset CVS_SERVER
# for clean cvsps cache
HOME=$(pwd)
export HOME
--
1.5.6.2
^ permalink raw reply related
* [PATCH] cvsserver: Add support for packed refs
From: Lars Noschinski @ 2008-07-17 17:00 UTC (permalink / raw)
To: git, gitster; +Cc: lars, fabian.emmes
In-Reply-To: <1216314030-10887-2-git-send-email-lars@public.noschinski.de>
req_update still parses /refs/heads manually. Replace this by
a call to show-ref.
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
git-cvsserver.perl | 22 ++++++++--------------
1 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index b00d1c2..66aebf8 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -947,21 +947,15 @@ sub req_update
# projects (heads in this case) to checkout.
#
if ($state->{module} eq '') {
- my $heads_dir = $state->{CVSROOT} . '/refs/heads';
- if (!opendir HEADS, $heads_dir) {
- print "E [server aborted]: Failed to open directory, "
- . "$heads_dir: $!\nerror\n";
- return 0;
- }
+ my $showref = `git show-ref --heads`;
print "E cvs update: Updating .\n";
- while (my $head = readdir(HEADS)) {
- if (-f $state->{CVSROOT} . '/refs/heads/' . $head) {
- print "E cvs update: New directory `$head'\n";
- }
- }
- closedir HEADS;
- print "ok\n";
- return 1;
+ for my $line (split '\n', $showref) {
+ if ( $line =~ m% refs/heads/(.*)$% ) {
+ print "E cvs update: New directory `$1'\n";
+ }
+ }
+ print "ok\n";
+ return 1;
}
--
1.5.6.2
^ permalink raw reply related
* Segmentation fault git pull
From: Len Brown @ 2008-07-17 16:52 UTC (permalink / raw)
To: git
$ git --version
git version 1.5.6.3.439.g1e10
...while doing a pull on my vanilla linus' linux tracking tree,
which I have not touched in about a week.
$ good.morning
...
+ git checkout master
Already on "master"
+ git pull
remote: Counting objects: 31759, done.
remote: Compressing objects: 100% (5397/5397), done.
remote: Total 28193 (delta 23770), reused 27116 (delta 22765)
Receiving objects: 100% (28193/28193), 6.76 MiB | 526 KiB/s, done.
Resolving deltas: 100% (23770/23770), completed with 3141 local objects.
From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
f57e916..33af79d master -> origin/master
From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
* [new tag] v2.6.26 -> v2.6.26
Updating f57e916..33af79d
/lab/bin/good.morning: line 8: 5610 Segmentation fault git pull
...
$ git pull
Updating f57e916..33af79d
fatal: unable to create '.git/index.lock': File exists
[lenb@d975xbx2 linus (master)]$ rm .git/index.lock
git status
shows no local changes, just a few untracked files i have left around.
clues?
thanks,
-Len
ps.
$ cat /lab/bin/good.morning
#!/bin/bash -x
cd ~/src/git
git checkout master
git pull
make -j4 install
cd ~/src/linus
git checkout master
git pull
...
^ permalink raw reply
* Re: [PATCH] Documentation/git-merge.txt: Expand the How Merge Works section
From: Petr Baudis @ 2008-07-17 16:42 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <20080717162922.12081.96582.stgit@localhost>
On Thu, Jul 17, 2008 at 06:29:32PM +0200, Petr Baudis wrote:
> foo | 1
> 2 files changed, 59 insertions(+), 35 deletions(-)
> create mode 100644 foo
*Cough* Sorry about this. I think there is currently no need to merge
the 'foo' bit. ;-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Junio C Hamano @ 2008-07-17 16:38 UTC (permalink / raw)
To: Theodore Tso; +Cc: Peter Valdemar Mørch (Lists), git
In-Reply-To: <20080717125536.GO2167@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> Have you taken a look at the intro-level materials such as "Everyday
> Git in 20 commands or so"[1], the git tutorial[2], the official "Git's
> User Manual"[3], or the "Git-SVN crash course"[4]? Those are probably
> the best place to begin --- and to basically treat the git man pages
> as reference materials with a huge number of controls that you won't
> use or need to use for a long time --- if ever.
Good advice.
One caution is that I wrote the Everyday quite a while ago, certainly way
before 1.5.0, and I suspect the set of best commands and best ways to do
what these sections demonstrate to do may have changed. I do not think
old ways stopped working (that would be a regression), but there would be
better ways invented after the document was last updated.
^ permalink raw reply
* [PATCH] Documentation/gitignore.txt: Clarify gitignore vs tracked files
From: Petr Baudis @ 2008-07-17 16:36 UTC (permalink / raw)
To: gitster; +Cc: git
Explain more carefully that `.gitignore` concerns only untracked files
and there is no way to make git ignore local changes in already tracked
files.
This is currently probably one of the top FAQs at #git and the documentation
could be more explicit about this.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/gitignore.txt | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index fc0efd8..ac3c776 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -13,9 +13,12 @@ DESCRIPTION
-----------
A `gitignore` file specifies intentionally untracked files that
-git should ignore. Each line in a `gitignore` file specifies a
-pattern.
+git should ignore.
+Note that all the `gitignore` files really concern only files
+that are not already tracked by git; there is no direct mechanism
+to make git ignore your local modifications in already tracked files.
+Each line in a `gitignore` file specifies a pattern.
When deciding whether to ignore a path, git normally checks
`gitignore` patterns from multiple sources, with the following
order of precedence, from highest to lowest (within one level of
^ permalink raw reply related
* [PATCH] Documentation/git-merge.txt: Expand the How Merge Works section
From: Petr Baudis @ 2008-07-17 16:29 UTC (permalink / raw)
To: gitster; +Cc: git
The git-merge documentation's "HOW MERGE WORKS" section is confusingly
composed and actually omits the most interesting part, the merging of
the arguments into HEAD itself, surprisingly not actually mentioning
the fast-forward merge anywhere.
This patch moves the "[NOTE]" screenful of highly technical details
to a dedicated subsection at the end of the section, and instead
explains how are the arguments compard with HEAD and the three possible
inclusion states. When discussing merges, some term that describes the
situation when fast-forwarding did _not_ happen is frequently useful;
this patch proposes "true merge" for that. It also makes it clear that
the rest of the section talks only about the true merge situation.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-merge.txt | 93 +++++++++++++++++++++++++++----------------
foo | 1
2 files changed, 59 insertions(+), 35 deletions(-)
create mode 100644 foo
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 019e4ca..396f3ec 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -61,46 +61,28 @@ exactly match the
tree of `HEAD` commit (i.e. the contents of the last commit) when
it happens. In other words, `git diff --cached HEAD` must
report no changes.
+(However, see the "Pre-flight requirements" subsection.)
-[NOTE]
-This is a bit of a lie. In certain special cases, your index is
-allowed to be different from the tree of the `HEAD` commit. The most
-notable case is when your `HEAD` commit is already ahead of what
-is being merged, in which case your index can have arbitrary
-differences from your `HEAD` commit. Also, your index entries
-may have differences from your `HEAD` commit that match
-the result of a trivial merge (e.g. you received the same patch
-from an external source to produce the same result as what you are
-merging). For example, if a path did not exist in the common
-ancestor and your head commit but exists in the tree you are
-merging into your repository, and if you already happen to have
-that path exactly in your index, the merge does not have to
-fail.
+Three kinds of merge can happen:
-Otherwise, merge will refuse to do any harm to your repository
-(that is, it may fetch the objects from remote, and it may even
-update the local branch used to keep track of the remote branch
-with `git pull remote rbranch:lbranch`, but your working tree,
-`.git/HEAD` pointer and index file are left intact). In addition,
-merge always sets `.git/ORIG_HEAD` to the original state of HEAD so
-a problematic merge can be removed by using `git reset ORIG_HEAD`.
+* The merged commit is already contained in `HEAD`. This is the
+ simplest case and only "Already up-to-date" is printed.
-You may have local modifications in the working tree files. In
-other words, 'git-diff' is allowed to report changes.
-However, the merge uses your working tree as the working area,
-and in order to prevent the merge operation from losing such
-changes, it makes sure that they do not interfere with the
-merge. Those complex tables in read-tree documentation define
-what it means for a path to "interfere with the merge". And if
-your local modifications interfere with the merge, again, it
-stops before touching anything.
+* `HEAD` is already contained in the merged commit. This is the
+ most common case especially when involved through 'git pull':
+ you are tracking an upstream repository, committed no local
+ changes and now you want to update to a newer upstream revision.
+ So-called "fast-forward merge" is performed, simply repointing
+ your `HEAD` (and index) to the merged commit; no extra merge
+ commit is created.
-So in the above two "failed merge" case, you do not have to
-worry about loss of data --- you simply were not ready to do
-a merge, so no merge happened at all. You may want to finish
-whatever you were in the middle of doing, and retry the same
-pull after you are done and ready.
+* Both merged commit and `HEAD` are independent and must be
+ "tied together" by a merge commit, having them both as its parents;
+ this might be called a "true merge" and is described in the rest
+ of this section.
+The chosen merge strategy merges the two commits into a single
+new source tree.
When things cleanly merge, these things happen:
1. The results are updated both in the index file and in your
@@ -152,6 +134,47 @@ After seeing a conflict, you can do two things:
should be, and run 'git-commit' to commit the result.
+Pre-flight requirements note
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+In certain special cases, your index is
+allowed to be different from the tree of the `HEAD` commit. The most
+notable case is when your `HEAD` commit is already ahead of what
+is being merged, in which case your index can have arbitrary
+differences from your `HEAD` commit. Also, your index entries
+may have differences from your `HEAD` commit that match
+the result of a trivial merge (e.g. you received the same patch
+from an external source to produce the same result as what you are
+merging). For example, if a path did not exist in the common
+ancestor and your head commit but exists in the tree you are
+merging into your repository, and if you already happen to have
+that path exactly in your index, the merge does not have to
+fail.
+
+Other than that, merge will refuse to do any harm to your repository
+(that is, it may fetch the objects from remote, and it may even
+update the local branch used to keep track of the remote branch
+with `git pull remote rbranch:lbranch`, but your working tree,
+`.git/HEAD` pointer and index file are left intact). In addition,
+merge always sets `.git/ORIG_HEAD` to the original state of HEAD so
+a problematic merge can be removed by using `git reset ORIG_HEAD`.
+
+You may have local modifications in the working tree files. In
+other words, 'git-diff' is allowed to report changes.
+However, the merge uses your working tree as the working area,
+and in order to prevent the merge operation from losing such
+changes, it makes sure that they do not interfere with the
+merge. Those complex tables in read-tree documentation define
+what it means for a path to "interfere with the merge". And if
+your local modifications interfere with the merge, again, it
+stops before touching anything.
+
+So in the above two "failed merge" case, you do not have to
+worry about loss of data --- you simply were not ready to do
+a merge, so no merge happened at all. You may want to finish
+whatever you were in the middle of doing, and retry the same
+pull after you are done and ready.
+
+
SEE ALSO
--------
linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],
diff --git a/foo b/foo
new file mode 100644
index 0000000..b4e94ec
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+Thu Jul 17 17:30:53 CEST 2008
^ permalink raw reply related
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Nicolas Pitre @ 2008-07-17 16:25 UTC (permalink / raw)
To: Stephan Hennig
Cc: Shawn O. Pearce, Andreas Ericsson, Johannes Schindelin,
Jakub Narebski, Junio C Hamano, git
In-Reply-To: <487F6E04.9050106@arcor.de>
On Thu, 17 Jul 2008, Stephan Hennig wrote:
> Shawn O. Pearce schrieb:
>
> > We're better off keeping our memory usage low and recomputing
> > the delta base when we need to return to it to process a sibling.
>
> Thanks to all who have had a look at this issue! From a user's
> perspective I have one more suggestions and a question:
>
> First, it would have helped me to bring this issue onto the list if I
> had earlier known that this was no misconfiguration, but a memory
> problem.
Well, if we had known before that this could be a problem, we'd have
fixed it earlier. In other words, sh*t happens.
> Even though Git now makes some efforts to substitute runtime
> for memory to be able to operate with low(er) memory, I think it would
> still be informative for a user that repository and hardware, resp.
> core.deltaBaseCacheLimit, are, say, incompatible. If valuable objects
> have to be discarded due to memory restrictions a warning could be
> issued to make the user aware of this fact, e.g.,
>
> Warning! Low memory. Git might be slowing down.
Well, I disagree. First we don't know how slow git would effectively be
since all (my) concerns so far were totally theoretical. It will still
work better than, say, 'git verify-pack' nevertheless. And git should
just do its best regardless and avoid being needlessly verbose.
> Second, while there have been some changes to Git now, as a poor user,
> how can I make use of that changes? I think, updating my client should
> only help with pushing. For pulling, I have to wait for repo.or.cz to
> update to Git 1.6.0, right?
Actually that's the other way around. This change will help the
receiving side of a transfer. So it should help you when pulling.
Nicolas
^ permalink raw reply
* Re: Contributors, please check your names
From: Junio C Hamano @ 2008-07-17 16:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3sku8sh01.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> What about if some authors use different _email_ address, instead?
> Is there any way for shortlog to consider them the same?
Read the first part of the message you are responding to again please.
^ permalink raw reply
* Subversion's do-everything-via-copying paradigm ( was RE: Re: Considering teaching plumbing to users harmful)
From: Craig L. Ching @ 2008-07-17 16:18 UTC (permalink / raw)
To: David Kastrup, git
In-Reply-To: <86k5fk1ooq.fsf@lola.quinscape.zz>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of David Kastrup
> Sent: Thursday, July 17, 2008 11:05 AM
> To: git@vger.kernel.org
> Subject: Re: Considering teaching plumbing to users harmful
>
> How much have you worked with Subversion so far? I am doing
> quite a bit of work with it, and the
> do-everything-via-copying paradigm does not get in my hair.
> It actually means that I have to remember fewer commands.
> And it is pretty easy to understand.
>
Does it not bother you that renaming a file is a copy + delete [1].
Have they fixed that yet? That was one of the biggest reasons we never
moved to subversion.
Ok, I'm done picking on Subversion for now :-P
[1] -- http://subversion.tigris.org/issues/show_bug.cgi?id=898
> --
> David Kastrup
>
Cheers,
Craig
^ permalink raw reply
* Subversion is actually not so simple (was RE: Considering teaching plumbing to users harmful)
From: Craig L. Ching @ 2008-07-17 16:11 UTC (permalink / raw)
To: Jakub Narebski, David Kastrup; +Cc: git
In-Reply-To: <m3od4wse30.fsf@localhost.localdomain>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Jakub Narebski
> Sent: Thursday, July 17, 2008 10:52 AM
> To: David Kastrup
> Cc: git@vger.kernel.org
> Subject: Re: Considering teaching plumbing to users harmful
>
> Subversion is simple if you are limited to simple things; but
> the same is true with Git. I find for example the whole 'properties'
> mechanism and its use seriously not simple.
>
Yes, that's exactly right. Because SVN's underlying repository is
complex, it sometimes falls out in the UI. If you stick with the way
SVN wants you to do things, you can get along with it fairly well. But
that's the problem, it's just not flexible. On the other hand, Git's
concept of the repository is so simple and clean, it's a DAG and you can
actually do a lot more with fewer commands. But then you can do so much
more as well and work the way *you* want to.
For instance, SVN has a history of having to invent concepts that just
shouldn't need to be invented. Their latest release includes something
they call "merge tracking", but it falls on the floor in the face of
what they call "reflective merging." [1] I don't find "merge tracking"
and "reflective merges" concepts that I should *have* to understand when
it comes to working with a VCS, the VCS should just *do* those things.
Those concepts just don't exist in Git. Frankly, I don't find
Subversion to be easier to use than Git at all and this is coming from a
very long-time CVS user. I do find, however, that Git has a very large
vocabulary and that does take some time to learn, but I'd argue that
this is due to it's inherent flexibility than it is due to any inherent
flaws.
[1] -- http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
> --
Cheers,
Craig
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Stephan Hennig @ 2008-07-17 16:06 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Nicolas Pitre, Andreas Ericsson,
Johannes Schindelin, Jakub Narebski, Junio C Hamano
In-Reply-To: <20080715024741.GB1700@spearce.org>
Shawn O. Pearce schrieb:
> We're better off keeping our memory usage low and recomputing
> the delta base when we need to return to it to process a sibling.
Thanks to all who have had a look at this issue! From a user's
perspective I have one more suggestions and a question:
First, it would have helped me to bring this issue onto the list if I
had earlier known that this was no misconfiguration, but a memory
problem. Even though Git now makes some efforts to substitute runtime
for memory to be able to operate with low(er) memory, I think it would
still be informative for a user that repository and hardware, resp.
core.deltaBaseCacheLimit, are, say, incompatible. If valuable objects
have to be discarded due to memory restrictions a warning could be
issued to make the user aware of this fact, e.g.,
Warning! Low memory. Git might be slowing down.
Second, while there have been some changes to Git now, as a poor user,
how can I make use of that changes? I think, updating my client should
only help with pushing. For pulling, I have to wait for repo.or.cz to
update to Git 1.6.0, right?
Best regards,
Stephan Hennig
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: David Kastrup @ 2008-07-17 16:05 UTC (permalink / raw)
To: git
In-Reply-To: <m3od4wse30.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>> > SVN branches are incredible confusing because they fail to
>> > distinguish the directory structure of the project's source tree
>> > from the arrangement of available latest versions.
>>
>> That is because there _is_ no difference. You just store different
>> versions in different places. What they are named is a convention,
>> nothing more, nothing less.
>
> Branching by copying (!) and tagging by copying (!!!) is abuse
> of the fact that copying in Subversion is cheap.
Uh, no. A lot of work has been invested into ensuring that copying in
Subversion in cheap _exactly_ because of the design decision to
implement branching and tagging via copying.
It is not an accident that copying is cheap.
> Distinguishing between branch part of directory name by _convention_
> is design mistake; the fact that the tool doesn't help to ensure that
> (a) tags lie on branch (b) tags _doesn't change_ is an example of this
> stupidity.
How much have you worked with Subversion so far? I am doing quite a bit
of work with it, and the do-everything-via-copying paradigm does not get
in my hair. It actually means that I have to remember fewer commands.
And it is pretty easy to understand.
>> Really, Subversion is rather simple to understand. But it is not a
>> DVCS. Moving a history from one repository to another is not really
>> feasible unless you are doing straight mirroring.
>
> Subversion is simple if you are limited to simple things; but the
> same is true with Git. I find for example the whole 'properties'
> mechanism and its use seriously not simple.
Granted, particularly concerning the external property. OTOH, it makes
the equivalent of git submodules rather cheap (and I actually still have
no idea how git submodules properly work and what implications they
have).
--
David Kastrup
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Karl Hasselström @ 2008-07-17 16:03 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20080717155538.GE11759@fieldses.org>
On 2008-07-17 11:55:38 -0400, J. Bruce Fields wrote:
> Is there a way to commit the contents of a tarball without using
> plumbing?
contrib/fast-import/import-tars.perl
It currently lacks a bit in flexibility, IIRC, but it does its job
well.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: J. Bruce Fields @ 2008-07-17 15:57 UTC (permalink / raw)
To: Petr Baudis
Cc: Craig L. Ching, Johannes Schindelin, Avery Pennarun,
Junio C Hamano, git
In-Reply-To: <20080717145120.GW32184@machine.or.cz>
On Thu, Jul 17, 2008 at 04:51:20PM +0200, Petr Baudis wrote:
> On Thu, Jul 17, 2008 at 09:21:58AM -0500, Craig L. Ching wrote:
> > Maybe if Git had a few different workflows
> > documented that might help. I know we have a "Git for SVN Users"
> > workflow, but if you want to move beyond that, it might be good to have
> > some of the more complex workflows documented. I think some people have
> > hinted at that suggestion but that maybe it just hasn't been explicitly
> > said.
>
> Yes, very recently, someone on #git asked about existing documented
> workflows, and there is very little. It would be interesting project for
> someone to build a 'Garden of Git Workflows' (or a Labyrinth) -
That's been requested for a long time, but nobody's gotten around to it.
It might be nice if it could be made a superset of everyday.txt.
--b.
> for each
> workflow, detailed self-contained documentation ranging from lone developer
> with topic branches over repo.or.cz/github forks workflow, the workflows
> of "leaf contributors", lieutenants and main integrators of the mail-oriented
> kernel/git workflow, up to the single-central-repository workflows.
>
> There are bits here and there, but the main problem is that they are not
> self-contained. It might be nice to have something like a set of military
> manuals, appropriate for the roles of the particular developers.
>
> --
> Petr "Pasky" Baudis
> GNU, n. An animal of South Africa, which in its domesticated state
> resembles a horse, a buffalo and a stag. In its wild condition it is
> something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: J. Bruce Fields @ 2008-07-17 15:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vmykhpn6z.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 16, 2008 at 01:51:31PM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Am I the only one who deems teaching plumbing to users ("I like it raw!
> > So I teach it the same way!") harmful?
>
> I think that justification is harmful.
>
> More productive way to think about it is to identify cases where we _need_
> to go down to combination of the plumbing commands in our daily workflow,
> with today's command set. That would give us a good indication that some
> Porcelain may need to be enhanced.
Is there a way to commit the contents of a tarball without using
plumbing? I occasionally want to track an upstream that I know only as
a series of tarballs, so I do something like:
cd repo/
git checkout upstream
rm -rf *
tar -xzvf ../new-version.tar.gz
Then I spend some time mucking around with git-add and git-rm and
eventually end up having to do some sort of git ls-files | git
update-index pipeline.
--b.
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Jakub Narebski @ 2008-07-17 15:52 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <861w1sn4id.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Daniel Barkalow <barkalow@iabervon.org> writes:
> > You're simply wrong. A ref isn't a name for a commit (the point of
> > having a ref is that it doesn't persist in naming the same commit). A
> > commit isn't a blob. If you start telling people complicated and wrong
> > things, they're surely going to be confused.
A ref is a pointer. In the case of branches it is named pointer
to a commit, "tip of growth" of a branch (to stay with analogy from
biology).
> > Git maintains history as a directed graph, with each commit pointing
> > back at its history. Refs are the what holds the newest commits that
> > nothing else points back to. If directed graphs aren't in your users'
> > experience, you can put it this way: git maintains history like
> > knitting, where each new stitch holds on to one or more previous
> > stitches, and refs are the knitting needles that hold the ends where
> > you're working (except that knitting is a lot wider than software
> > development). gitk --all even provides the diagram you want to explain
> > it.
>
> Complicated and right things are not much less confusing...
For me the idea that commits contain pointers to state of repository
(state of project) at given "time" and pointers to its parents, and
those make history simple yet powerfull one.
Nevertheless simple ideas not always are easily to explain...
> > SVN branches are incredible confusing because they fail to distinguish
> > the directory structure of the project's source tree from the
> > arrangement of available latest versions.
>
> That is because there _is_ no difference. You just store different
> versions in different places. What they are named is a convention,
> nothing more, nothing less.
Branching by copying (!) and tagging by copying (!!!) is abuse
of the fact that copying in Subversion is cheap. Distinguishing
between branch part of directory name by _convention_ is design
mistake; the fact that the tool doesn't help to ensure that
(a) tags lie on branch (b) tags _doesn't change_ is an example
of this stupidity.
> > And the version numbers for your branch increase when changes are made
> > to other branches.
>
> You are confusing "version numbers" which are assigned by humans with
> "revision numbers" which are just an administrational timeline for the
> whole repository.
>
> Really, Subversion is rather simple to understand. But it is not a
> DVCS. Moving a history from one repository to another is not really
> feasible unless you are doing straight mirroring.
Subversion is simple if you are limited to simple things; but the
same is true with Git. I find for example the whole 'properties'
mechanism and its use seriously not simple.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git submodules and commit
From: Avery Pennarun @ 2008-07-17 15:12 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git Mailing List
In-Reply-To: <320075ff0807170247g7bb18252ma50b202e1d762296@mail.gmail.com>
On 7/17/08, Nigel Magnay <nigel.magnay@gmail.com> wrote:
> Yeah - this happens a lot. If someone else commits to the
> super-project before you, it's always a conflict. What's annoying is
> there's no way around it (though resolution is easy - force to current
> - but it this is a big bit of what confuses my users. They say 'but I
> already resolved the merges in the submodule itself'. I'm not sure
> there's an easy way around it though - and this is part of my worry
> that there's hidden complexity with trying to make it 'look like 1 big
> repo').
This might not be as hard as it sounds. We probably just need to
teach the supermodule how to merge gitlinks safely. So basically, if
I moved the gitlink from A to B, and he moved it from A to C, then it
needs to check whether a fast forward merge already exists for the
submodule to combine B and C. This is easier than it sounds, because
if I *already* ran my newest-git-modules script in the inner module,
then I've already manually resolved the merge in question, so that B
*does* actually contain C.
Right now, such a thing results in a conflict. It isn't really a
conflict though, it's a fast forward, and the supermodule's merge
should ideally just notice that and run with it.
Sadly I know very little about the merge code. But I would be happy
to help you test a patch that implemented this :)
A slightly more advanced version of the same would automatically walk
into the submodule and ask it to merge B and C. I suspect that is way
more complicated than it sounds at first glance, though (particularly
if the new B or C gitlink doesn't have A as a parent at all, which
couldn't happen in a unified git repo, but is perfectly allowable with
submodules).
With anything like this, there's always the question of what happens
if you haven't done a "fetch" in the submodule yet; I think reverting
to the current behaviour is fine in that case, because I can make
newest-git-modules to always fetch before trying anything anyway.
> Yeah. I have an additional usecase, which is around pulling from
> another user. If they've made changes in their tree(s) that they want
> to get reviewed, normally I could do something like
>
> git fetch ssh://joebloggs.computer/blah +refs/heads/*:refs/remotes/joebloggs/*
>
> But if they've made cross-module changes, I'm SOL, as fetching their
> super-project will have references to commits that aren't in the repo
> mentioned in .gitmodules (only in joebloggs's tree) - so doing git
> submodule update doesn't help. I have to go into each submodule and
> explicitly fetch. It feels wierdly centralised for this otherwise
> distributed tool.
One slightly non-obvious option here is to actually use the *same*
repo for all your supermodules and submodules, then use "." as the
repo path in your .gitmodules. The original clone is huge that way,
but it makes it obvious how to get any objects that you're missing.
Then you could construct your submodules using --reference the
supermodule. Thus, doing a "fetch" of your user's supermodule, you'll
also get all the objects it references.
Note that I've only basically tried out this technique. I think it's
the one for me, but I haven't experimented with it enough to know any
pitfalls. When I've brought it up on the list, it's been shot down
because it wouldn't work for gigantic mega-repositories like KDE where
the whole point of submodules is to *not* download all the modules
every time. It works for me, though, because my software doesn't even
*build* unless I have all the modules.
(And before anyone asks, yes, it still makes sense to use submodules
because some of the modules are shared with other projects.)
> What's bugging me is I'm not sure that it's the right place. It seems
> (to me) that having the only place that knows about submodules being
> the 'git submodules' script isn't right. What users want is 'git fetch
> <blah>' to do the lot - that, for the most, it ought to do the
> submodule init, update and clever stuff automatically. That if 'git
> fetch' is porcelain, then the porcelain needs to call the
> git-submodule stuff.
There is some architectural elegance to the fact that the gitlink
stuff is almost completely abstract (just a number, really) in the
core of git, and is only made "real" by running git-submodule, which
actually extracts files and makes .git dirs and fetches submodules and
whatnot.
However, it's architectural elegance, not UI elegance. As a user, I
mostly don't want to have to care whether a particular directory is a
"submodule" or not, so the extra push and commit and fetch steps
become tedious. From the point of view of UI, I agree with you.
Perhaps this is a plumbing vs. porcelain issue. I don't think
git-submodule has made an attempt to separate the two, since it seems
to be porcelain, but there's no "submodule plumbing" underneath
(AFAICS) that things like git-fetch and git-commit and git-push can
plug into.
> But - perhaps it's best to approach it as scripts for now :)
I suspect so :)
> Hm - I'd be happy with the same commt message in all modules. What I
> want is to be able to do (from the top) 'git commit -a' or the same
> with the GUI, and see all the files to be committed regardless of
> whether they're in a submodule or not.
That actually wouldn't work very well for me. I do need the commits
separated, because that's why I'm using submodules in the first place
instead of the "subtree" merge strategy.
Basically, I'm still planning on contributing patches to my class
library upstream, and the patches need to talk about how they affect
the *library*, not what I changed in my application. So I *would*
want to write separate commit messages in all cases. I can see how
other people might not, though.
> This is what the users want - something that mirrors 'svn ci' at the
> top level - "Please Check All My stuff in".
Note that submodules are more like svn:externals, which also require
you to commit each module separately. One big difference there is
that you don't need to commit to the supermodule each time you commit
to the submodule, but that's only because svn:externals by default
links to a branch, not to a particular revision. The
revision-specific linking is very worthwhile, I think, so requiring an
extra commit is mostly okay here.
Perhaps automating the extra commit would be nice in some cases, but
for me, for example, I tend to combine my "update to newest version of
submodule" commit with some changes to the supermodule, since the
reason I updated was to implement this new feature.
Have fun,
Avery
^ 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