* 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
* 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
* [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
* [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
* 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
* 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
* 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
* [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
* [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 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
* 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] 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
* [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] 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
* 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
* 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: Subversion is actually not so simple (was RE: Considering teaching plumbing to users harmful)
From: Jakub Narebski @ 2008-07-17 17:37 UTC (permalink / raw)
To: Craig L. Ching; +Cc: David Kastrup, git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F79430238A167@emailmn.mqsoftware.com>
On Thu, 17 July 2008, Craig L. Ching wrote:
> 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
WTF!?!
Without merge tracking (which at minimum means that commits which are
result of [true] merging contain information about which commits were
merged) you can't really display and reconstruct history. Without new
svn:mergeinfo one had to rely on third party extensions (SVK or svnmerge)
or on information contained in commit message to get this info. It is
very good that at last Subversion 1.5 finally does include merge
information.
But, if I understand correctly, and if information in mentioned blog
is correct, then Subversion _fails_ to use this information fully.
Instead of finding merge bases (see http://revctrl.org ... errr, it
is now full of spam, and there is no easy way to revert to some older
version, so you would have to browse history), and doing 3-way merge[1],
it requires of user to explicitly request automatical merge:
$ svn merge --reintegrate url://feature-branch .
and from the blog it looks like Subversion just generates patch and
applies it. Or do I understand it incorrectly?
[1] CVS did it, even Bram Cohen of Codeville agrees now[2] that 3-way
merge is a correct way to go
[2] http://bramcohen.livejournal.com/52148.html
"3. Use 3-way merge"
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Documentation/RelNotes-1.6.0.txt: Expand on the incompatible packfiles
From: Jakub Narebski @ 2008-07-17 17:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080717172051.GY32184@machine.or.cz>
Petr Baudis wrote:
> 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.
Sorry, I have forgot that "respectively" might refer to the context
which I don't see in a patch.
> I'm unclear about the 'or'-'and' question, though.
If you want to be backwards compatibile with pre v1.4.4.5 clients,
do you have to set either option, or both options, or what? The
same with pre v1.5.2 client...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Documentation/RelNotes-1.6.0.txt: Expand on the incompatible packfiles
From: Petr Baudis @ 2008-07-17 17:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200807171940.06288.jnareb@gmail.com>
On Thu, Jul 17, 2008 at 07:40:06PM +0200, Jakub Narebski wrote:
> Petr Baudis wrote:
> > I'm unclear about the 'or'-'and' question, though.
>
> If you want to be backwards compatibile with pre v1.4.4.5 clients,
> do you have to set either option, or both options, or what? The
> same with pre v1.5.2 client...
If you want to be backwards compatible with _either_ pre-v1.4.4 or
pre-v1.5.2, you will set _either_ (a) or (b). Setting (a) implies you
want to set (b) too, though. :-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] Testsuite: Unset CVS_SERVER
From: Jeff King @ 2008-07-17 17:53 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git, fabian.emmes
In-Reply-To: <1216288877-12140-2-git-send-email-lars@public.noschinski.de>
On Thu, Jul 17, 2008 at 12:01:13PM +0200, Lars Noschinski wrote:
> The CVS_SERVER environment variable cane cause some of the cvsimport tests
> to fail. So unset this variable at the beginning of the test script.
This is definitely an improvement. However, the cvs manual lists a
number of CVS* variables. Perhaps it would be better to simply scrub the
environment of any variable matching that pattern? I don't know how
commonly used some of the other ones are.
-Peff
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Johannes Schindelin @ 2008-07-17 18:16 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20080717155538.GE11759@fieldses.org>
Hi,
On Thu, 17 Jul 2008, J. Bruce Fields wrote:
> 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
How about "git add -u" and "git add ."?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation/gitignore.txt: Clarify gitignore vs tracked files
From: Junio C Hamano @ 2008-07-17 18:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080717163622.12592.29919.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> -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.
Thanks.
I'd suggest dropping everything after ';'.
- If you want to keep local changes without ever checking in, you can do
so by making partial commits.
- You could mark these paths "assume unchanged".
^ permalink raw reply
* Re: [PATCH] Documentation/git-merge.txt: Expand the How Merge Works section
From: Junio C Hamano @ 2008-07-17 18:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080717162922.12081.96582.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> 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.
Thanks.
> +Three kinds of merge can happen:
>
> +* The merged commit is already contained in `HEAD`. This is the
> + simplest case and only "Already up-to-date" is printed.
Let's introduce and define terms here, because I think the readers will be
harmed by being given a weak "this _might_ be called" in later paragraph.
I.e.:
... This is the simplest case and called "Already up-to-date".
> +* `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.
I'd suggest rewording the last three lines:
Your `HEAD` (and the index) is updated to point the merged
commit, without creating an extra merge commit. This is
called "Fast-forward".
> +* 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.
And this becomes:
... both as its parents. The rest of this section describes this
"True merge" case.
> +Pre-flight requirements note
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +In certain special cases, your index is
> +allowed to be different from the tree of the `HEAD` commit.
Now this paragraph is moved far away from the original context that said
"your index must be clean before you start your merge", you would need to
re-introduce that in this sentenece:
... tree of the `HEAD` before you run 'git-merge'.
> +... 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.
Thanks to your re-organization, we now have established terminology when
the reader reads this part, so we can just say:
When the merge will be "Already-up-to-date", your index can have
...
> +... 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.
I originally wrote the above paragraph purely for completeness, but I
wonder if this happens a lot in practice. This is not something the user
can easily anticipate anyway, so we might want to drop this.
> +Other than that, merge will refuse to do any harm to your repository
My initial reaction to this "Other than that" was "Huh? so the special
case we just saw allows merge to do harm to my repository?". The original
"Otherwise" wasn't any better, either.
In all other cases, your index must match the `HEAD` commit, even
though you can have local changes in your working tree, as
described below. Merge will avoid doing any harm to your working
tree state and your repository by refusing to work if such local
changes conflict with the merged result, though.
> +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.
I am not sure what two cases we were describing. It could be that this
paragraph was taken from a mailing list message responding to a question
(e.g. "I got this merge failure message and my tree is screwed up. Please
help me get back to a good state, I am lost...") without copying the
original sample failure scenario.
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Petr Baudis @ 2008-07-17 18:22 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <320075ff0807170807l1537e34ev510deda537e4d11e@mail.gmail.com>
On Thu, Jul 17, 2008 at 04:07:11PM +0100, Nigel Magnay wrote:
> And it works, but
>
> $ git pull fred
> $ git submodule update
>
> Can leave you with problems, because if a submodule wasn't pushed to
> origin, you won't have it available. This is because the commands are
> equivalent to
>
> $ git pull fred
> for each submodule()
> cd submodule
> git fetch origin
> git checkout <sha1>
Oh! So, only after replying to most of your mail, I have realized what
are you talking about all the time - _just_ this particular failure
mode:
"Someone pushed out a repository repointing submodules to
invalid commits, and instead of waiting for the person to fix
this breakage, we want to do a one-off fetch of all submodules
from a different repository."
There's nothing else you're trying to solve by this, right?
Now, I think that this is a completely wrong problem to solve. Your
gitweb is going to be broken, everyone has to jump through hoops because
of this, and that all just because of a single mistake. It shouldn't
have _happenned_ in the first place.
So the proper solution for this should be to make an update hook that
will simply not _let_ you push out a tree that's broken like this.
Something like this (completely untested):
die() { echo "$@"; exit 1; }
git rev-list ^$2 $3 | while read commit; do
git show $commit:.gitmodules >/tmp/gm$$
git config -f /tmp/gm$$ --get-regexp 'submodule\..*\.path' |
cut -d ' ' -f 1 |
sed 's/^.*\.//; s/\..*$//;' |
while read submodule; do
path=$(git config -f /tmp/gm$$ "submodule.$submodule.path")
url=$(git config -f /tmp/gm$$ "submodule.$submodule.url")
entry=$(git ls-tree $commit "$path")
[ -n "$entry" ] || die "submodule $submodule points at a non-existing path"
[ "$(echo "$entry" | cut -d ' ' -f 1)" = "160000" ] || die "submodule $submodule does not point to a gitlink entry"
subcommit="$(echo "$entry" | cut -d ' ' -f 2)"
urlhash="$(echo "$url" | sha1sum | cut -d ' ' -f 1)"
# We keep local copies of submodule repositories
# for commit existence checking
echo "Please wait, updating $url cache..."
if [ -d /tmp/ucache/$urlhash ]; then
(cd /tmp/ucache/$urlhash && git fetch)
else
git clone --bare "$url" /tmp/ucache/$urlhash
fi
[ "$(git --git-dir=/tmp/ucache/$urlhash cat-file -t "$subcommit" 2>/dev/null)" = "commit" ] || die "submodule $submodule does not point at an existing commit"
done
done
Comments? If it seems good, it might be worth including in
contrib/hooks/. Maybe even in the default update hook, controlled by
a config option.
All the troubles here stem from the fact that normally, Git will not let
you push any invalid state to the server. This is not completely true in
this case, but we should prevent this behaviour instead of inventing
hacks to work it around.
> Unless each submodule had a [remote] specified for "fred", you'd be
> stuffed. But what you could do is either by passing the right URL, or
> looking at the superproject [remote] for "fred" - i.e: If in the
> superproject you have
>
> [remote "fred"]
> url = ssh://git@fred.local/pub/scm/git/workspace/thing/.git
> [submodule "module"]
> url = ssh://git@repo/pub/scm/git/module.git
>
> Then the submodule "module" on fred, if it's a working-copy, can be calculated
> ssh://git@fred.local/pub/scm/git/workspace/thing/module/.git
>
> If it isn't a WC then you'd have to have a [remote "fred"] in that
> submodule, but I'm thinking that'd be a rare case.
This is ultra-evil. I think assuming things like this is extremely dirty
and not reasonable for a universal code, _unless_ we explicitly decide
that this is a new convention you want to introduce as a recommendation.
But you should've been very clear about this upfront.
_If_ you still insist on the one-off fetches for some reason, I think
it's reasonable to provide your own simple script for your users that
will autogenerate these URLs appropriately for your particular setup.
I don't think there is any real need for a more generic solution.
> I'd assumed (possibly wrongly?) that there was resistance to putting
> any of the submodule logic in things other than git-submodules.
Are you following the thread about submodule support for git mv, git rm?
--
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
^ permalink raw reply
* Re: [PATCH] Documentation/gitignore.txt: Clarify gitignore vs tracked files
From: Petr Baudis @ 2008-07-17 18:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabgggyuc.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, Jul 17, 2008 at 11:16:59AM -0700, Junio C Hamano wrote:
> I'd suggest dropping everything after ';'.
I think the part after ';' is the main benefit of this patch,
actually. Without suggesting an alternative, the users are left puzzled
"so how do I do that?"
> - If you want to keep local changes without ever checking in, you can do
> so by making partial commits.
Yes, that's a rather obvious solution but the user probably wants
something nicer than that if he starts looking already.
> - You could mark these paths "assume unchanged".
I really think this is worth mentioning in the gitignore manpage;
it is not _directly_ on-topic, but there is no other obvious place where
to teach users about it and all the interested people will check the
gitignore manpage first. Perhaps a small section at the end might be
acceptable? ;-)
--
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
^ 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