* Re: [GSoC] Git projects for Google Summer of Code 2008 final evaluation
From: Jakub Narebski @ 2008-09-15 12:13 UTC (permalink / raw)
To: git
Cc: Sam Vilain, Joshua Roys, Sverre Rabbelier, Sverre Rabbelier,
David Symonds, Lea Wiemann, John Hawley, Marek Zawirski,
Shawn O. Pearce, Miklos Vajna, Johannes Schindelin, Stephan Beyer,
Christian Couder, Daniel Barkalow, Junio Hamano
In-Reply-To: <200809042315.58898.jnareb@gmail.com>
On Thu, 4 Sep 2008, Jakub Narebski wrote:
> Mentors, could you tell us your side about how it was working as a
> mentor for Google Summer of Code? Perhaps some tricks of trade?
By the way, I have found via LWN that Perl has written nice summary
of theirs Google Summer of Code projects[1]. Among other they very much
praise that students did blogging about their progress:
"use Perl | Summer of Code recap"
http://use.perl.org/articles/08/08/29/1224242.shtml
Most of the students did a great job of blogging their progress, which
I think is an important part of Summer of Code for the rest of the
community.
What do you think about it (for example about doing it in a future
if our informal Git Development Community would participate in next
Google Summer of Code programs)?
[1] I plan to add quick summary of final results to GSoC2008 wiki page,
http://git.or.cz/gitwiki/SoC2008Projects, of course if GSoC manager(s),
mentors, or students don't do it first...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH FYI] t9700/test.pl: backwards compatibility improvements
From: Tom G. Christensen @ 2008-09-15 11:54 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <iZMIxnwnUBIGAGz2GMS0uwCvMMo9aaYd2Arx4fbxk9NusvUC5LUNVg@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> Some versions of perl complain when 'STDERR' is used as the third argument
> in the 3-argument form of open(). Convert to the 2-argument form which is
> described for duping STDERR in my second edition camel book.
>
> The object oriented version of File::Temp is a rather new incarnation it
> seems. The File::Temp man page for v5.8.0 says "(NOT YET IMPLEMENTED)" in
> the 'Objects' section. These can be converted to use File::Temp::tempfile().
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
>
Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
Without this patch the testsuite will fail with perl 5.8.0:
t9700$ ./test.pl
ok 1 - use Git;
Bareword "STDERR" not allowed while "strict subs" in use at ./test.pl
line 41.
Execution of ./test.pl aborted due to compilation errors.
1..1
# Looks like your test died just after 1.
Could we please get this patch in?
-tgc
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: dhruva @ 2008-09-15 11:46 UTC (permalink / raw)
To: Tor Arvid Lund, Junio C Hamano; +Cc: David Brown, GIT SCM, Simon Hausmann
Hi,
I am going to use the patched version for sometime to see if the problem (RCS hunk) arises again. From a pure SCM interconnect perspective, it might still be good to have keyword expansion as an option. With this being an option, the data in git and p4 are same.
----- Original Message ----
> From: Tor Arvid Lund <torarvid@gmail.com>
> To: Junio C Hamano <gitster@pobox.com>
> Cc: David Brown <git@davidb.org>; dhruva <dhruva@ymail.com>; GIT SCM <git@vger.kernel.org>; Simon Hausmann <simon@lst.de>
> Sent: Monday, 15 September, 2008 4:32:32 PM
> Subject: Re: [PATCH] Optional shrinking of RCS keywords in git-p4
>
> On Mon, Sep 15, 2008 at 9:43 AM, Junio C Hamano wrote:
> > David Brown writes:
> >
> >> ... As far as I can tell, P4 completely
> >> ignores whatever the $Id: ...$ headers happen to be expanded to at the
> >> time of checking. You can put garbage there, and it check in fine.
> >> ...
> >> I guess it isn't a problem to make this optional in git-p4, but I
> >> don't think this patch is solving the right problem.
> >
> > Hmm. I do not do p4, but what I am guessing is that there probably is a
> > configuration switch on the p4 side that lets you check in files with
> > "$Id: garbage $" in them, while dhruva hasn't turned that switch on.
>
> Hmm.. I thought this was not a p4 problem. I think however, that
> "git-p4 submit" tries to do git format-patch and then git apply that
> patch to the p4 directory. In other words, I believe that git apply
> fails since the file in the p4 dir has the keywords expanded, while
> the patch does not. I haven't done any careful investigation, but If
> my assumption is true, it sounds like dhruvas patch should work...
Your assumption is true (from my understanding of the code). My doubt is, even the files in p4 folder will be from git with no RCS keyword expanded. The patch application must ideally be clean! I am confused here.
-dhruva
Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here http://in.promos.yahoo.com/address
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: Tor Arvid Lund @ 2008-09-15 11:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Brown, dhruva, GIT SCM, Simon Hausmann
In-Reply-To: <7vy71tetvt.fsf@gitster.siamese.dyndns.org>
On Mon, Sep 15, 2008 at 9:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
> David Brown <git@davidb.org> writes:
>
>> ... As far as I can tell, P4 completely
>> ignores whatever the $Id: ...$ headers happen to be expanded to at the
>> time of checking. You can put garbage there, and it check in fine.
>> ...
>> I guess it isn't a problem to make this optional in git-p4, but I
>> don't think this patch is solving the right problem.
>
> Hmm. I do not do p4, but what I am guessing is that there probably is a
> configuration switch on the p4 side that lets you check in files with
> "$Id: garbage $" in them, while dhruva hasn't turned that switch on.
Hmm.. I thought this was not a p4 problem. I think however, that
"git-p4 submit" tries to do git format-patch and then git apply that
patch to the p4 directory. In other words, I believe that git apply
fails since the file in the p4 dir has the keywords expanded, while
the patch does not. I haven't done any careful investigation, but If
my assumption is true, it sounds like dhruvas patch should work...
-Tor Arvid Lund-
^ permalink raw reply
* Re: [PATCH 15/16] checkout: add new options to support narrow checkout
From: Jakub Narebski @ 2008-09-15 10:40 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <48cdde2837b2d_12d73fc6eb2c355c27876@app02.zenbe.com.tmail>
[I don't see mails I am replying to on GMane interface to git mailing
list, so threads might be broken. Strange... Perhaps too long lines
were cause of rejection by anti-SPAM vger filter?]
On Mon, 15 Sep 2008, Duy Nguyen wrote:
> On 09/15/2008 "Jakub Narebski" <jnareb@gmail.com> wrote:
> > > +Narrow works by applying your rules to the index, marking which
> > > +file you need and which file you need not. Modified/Unmerged
> > > +files cannot be marked unneeded. Unnecessary files will be
> > > +removed from working directory. Note that after this step,
> > > +removed files can still be added to working directory when they
> > > +are needed by any git command. For example, when you have a merge
> > > +conflict, conflicted files will be checked out on working
> > > +directory and will no longer be marked "unneeded".
> >
> > This paragraph I think need some more love...
> >
> > So the "checkout rules" are meant to mark which paths are "wanted"
> > or "needed", and we would like to have in the checkout, and which
> > files are "unwanted" or "not needed" ("unneeded"?) and we want to
> > not have them present in working directory; something akin to accept
> > and deny rules, isn't it?
>
> Yes. But rules will be gone, only the results remain. I don't
> save/reuse rules.
Ah. I understand. The options are only to select which files to check-out
(which are "wanted"), and which we do not want and mark with "no-checkout"
bit ("unwanted").
> > What are the rules, does all files except those marked explicitely
> > as needed are unneeded, or do you have to first mark all files as
> > unneeded?
> >
> > How would the following table look like:
> >
> > working directory || needed | not needed |
> > ----------------------------------------------------
> > file is absent || checkout | no change |
> > file is present || no change | removed |
> > file is modified || conflict | conflict? |
>
> Looks better than my description. Though it would be "no change" for
> "file is modified/needed" case. There should be another line for
> unmerged entries.
Now I am not sure about the line with 'file is modified', because even
in simple full checkout case there are different situations dealing with
checking out of index (and '-f' option), and switching to other branch
(and '-m' option).
Doesn't unmerged simply mean ignore "no-checkout" bit?
> > > +
> > > +New files after merges will always be "needed". You can also
> > > +apply rules when switching branches to avoid unwanted new files.
> >
> > Does it mean that if merge brings some new files, then those
> > files would be "needed" (without "no checkout" bit)?
And as far as I understand the same for simple checkout, and for "2-way
merge" checkout.
> Yes.
Perhaps: new entries appearing in index have "no-checkout" bit unset
(cleared). Or perhaps in addition, as clarification.
> > What does it mean this sentence about switching branches:
> > how does partial/sparse/narrow checkout rules change when
> > switching to other branch (which, like 'html' and 'todo'
> > branches in git repository, can be completely unrelated)?
>
> Recall above I say rules are not saved. When you switch branches,
> files that are needed will still be and stay in workdir. New files
> will always appear in workdir ("needed"). If two branches are
> completely unrelated, all files will be new so you get full workdir.
Thanks. Now I understand: new entries in index are always with
"no-checkout" bit unset, regardless how they got there.
> > > +Narrow spec will be used to specify how you want to narrow your
> > > +checkout. It is a list of pathspecs separated by colons. Each
> > > +patchspec specifies what files should be checked out on working
> > > +directory. Pathspec can contain wildcards and is relative to
> > > +current working directory. Usually asterisk (*) does not match
> > > +slashes. If a pathspec is prefixed by a plus sign (+), then
> > > +any asterisk will match anything, even slashes.
> >
> > First, does this mean that you can specify paths containing colons
> > (':') only using --add-path and --remove-path, or does it mean that
> > you cannot specify paths containg colon ':' (which should be rare)
> > at all as checkout limiter / checkout narrowing rule?
>
> You cannot do othat explicitly unfortunately. You can work-around using
> wildcard though.
Couldn't you simply escape ':', i.e. write for example Git\:\:Tag.3pm,
or Eichten_PRD21\:313,1980_erratum.tex, or \:0.log, or perhaps
kmail/jnareb@gmail.com\:@pop.gmail.com\:995, or even something like
Mail/inbox/cur/1194202360.32296.mprnq\:2,S, in the same way like you
can escape other special characters, for example wildcard characters
like '\*' for '*' and '\?' for '?', and of course '\\' for '\'?
> > Second, wouldn't it be better to use '**' to match also '/'?
> > Changing meaning of '*' using per-path flag seems a bit bad.
>
> It would be better. But I don't see any way but duplicating fnmatch()
> implementation and modify it to support '**' so I made a compromise.
> Will make another patch for '**' support and see how bloat the code
> will be.
Well, the alternative would be to tell in commit message _why_ you
choose that (for implementation reasons), and perhaps give an example.
BTW. does '+' prefixed pathspec means that '?' can match '/', directory
separator?
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Documentation: replace [^~] with escapes everywhere
From: Thomas Rast @ 2008-09-15 9:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1221470398-8698-2-git-send-email-trast@student.ethz.ch>
Replaces all ^ and ~ that are not part of a "literal" paragraph with
{caret} and {tilde}.
Tildes and carets are ordinarily used for ~sub~ and ^super^scripts.
This only triggers if a suitable chunk of text is found within the
current paragraph, so in most cases nothing happens (and the
tilde/caret is taken literally). However, it is a pitfall for anyone
who later adds more text to the same paragraph, so we might as well do
it right.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-bundle.txt | 10 +++++-----
Documentation/git-check-ref-format.txt | 4 ++--
Documentation/git-commit-tree.txt | 2 +-
Documentation/git-config.txt | 6 +++---
Documentation/git-daemon.txt | 4 ++--
Documentation/git-fast-export.txt | 2 +-
Documentation/git-fast-import.txt | 2 +-
Documentation/git-push.txt | 2 +-
Documentation/git-rebase.txt | 2 +-
Documentation/git-reset.txt | 2 +-
Documentation/git-rev-parse.txt | 2 +-
Documentation/git-show-branch.txt | 2 +-
Documentation/git-show.txt | 2 +-
Documentation/git-tools.txt | 2 +-
Documentation/gitcore-tutorial.txt | 2 +-
Documentation/gitignore.txt | 2 +-
Documentation/rev-list-options.txt | 2 +-
Documentation/user-manual.txt | 8 ++++----
18 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 1b66ab7..5b255af 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -60,7 +60,7 @@ unbundle <file>::
[git-rev-list-args...]::
A list of arguments, acceptable to 'git-rev-parse' and
'git-rev-list', that specify the specific objects and references
- to transport. For example, "master~10..master" causes the
+ to transport. For example, "master{tilde}10..master" causes the
current master reference to be packaged along with all objects
added since its 10th ancestor commit. There is no explicit
limit to the number of references and objects that may be
@@ -79,12 +79,12 @@ SPECIFYING REFERENCES
'git-bundle' will only package references that are shown by
'git-show-ref': this includes heads, tags, and remote heads. References
-such as master~1 cannot be packaged, but are perfectly suitable for
+such as master{tilde}1 cannot be packaged, but are perfectly suitable for
defining the basis. More than one reference may be packaged, and more
than one basis can be specified. The objects packaged are those not
contained in the union of the given bases. Each basis can be
-specified explicitly (e.g., ^master~10), or implicitly (e.g.,
-master~10..master, master --since=10.days.ago).
+specified explicitly (e.g., {caret}master{tilde}10), or implicitly (e.g.,
+master{tilde}10..master, master --since=10.days.ago).
It is very important that the basis used be held by the destination.
It is okay to err on the side of conservatism, causing the bundle file
@@ -152,7 +152,7 @@ With something like this in the config in R2:
fetch = refs/heads/*:refs/remotes/origin/*
------------------------
-You can first sneakernet the bundle file to ~/tmp/file.bdl and
+You can first sneakernet the bundle file to {tilde}/tmp/file.bdl and
then these commands on machine B:
------------
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 034223c..cbc8507 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -26,7 +26,7 @@ imposes the following rules on how refs are named:
. It cannot have two consecutive dots `..` anywhere;
. It cannot have ASCII control character (i.e. bytes whose
- values are lower than \040, or \177 `DEL`), space, tilde `~`,
+ values are lower than \040, or \177 `DEL`), space, tilde `{tilde}`,
caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
or open bracket `[` anywhere;
@@ -41,7 +41,7 @@ refname expressions (see linkgit:git-rev-parse[1]). Namely:
context this notation means `{caret}ref1 ref2` (i.e. not in
ref1 and in ref2).
-. tilde `~` and caret `{caret}` are used to introduce postfix
+. tilde `{tilde}` and caret `{caret}` are used to introduce postfix
'nth parent' and 'peel onion' operation.
. colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
index b8834ba..351a2d2 100644
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -71,7 +71,7 @@ present, system user name and fully qualified hostname.
A commit comment is read from stdin. If a changelog
entry is not provided via "<" redirection, 'git-commit-tree' will just wait
-for one to be entered and terminated with ^D.
+for one to be entered and terminated with {caret}D.
Diagnostics
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 28e1861..8dc5c28 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -84,10 +84,10 @@ OPTIONS
Also outputs the key names.
--global::
- For writing options: write to global ~/.gitconfig file rather than
+ For writing options: write to global {tilde}/.gitconfig file rather than
the repository .git/config.
+
-For reading options: read only from global ~/.gitconfig rather than
+For reading options: read only from global {tilde}/.gitconfig rather than
from all available files.
+
See also <<FILES>>.
@@ -197,7 +197,7 @@ ENVIRONMENT
GIT_CONFIG::
Take the configuration from the given file instead of .git/config.
- Using the "--global" option forces this to ~/.gitconfig. Using the
+ Using the "--global" option forces this to {tilde}/.gitconfig. Using the
"--system" option forces this to $(prefix)/etc/gitconfig.
See also <<FILES>>.
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index b08a08c..5c64647 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -110,9 +110,9 @@ OPTIONS
--user-path::
--user-path=path::
- Allow ~user notation to be used in requests. When
+ Allow {tilde}user notation to be used in requests. When
specified with no parameter, requests to
- git://host/~alice/foo is taken as a request to access
+ git://host/{tilde}alice/foo is taken as a request to access
'foo' repository in the home directory of user `alice`.
If `--user-path=path` is specified, the same request is
taken as a request to access `path/foo` repository in
diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
index b974e21..8f92545 100644
--- a/Documentation/git-fast-export.txt
+++ b/Documentation/git-fast-export.txt
@@ -83,7 +83,7 @@ $ git fast-export master~5..master |
git fast-import
-----------------------------------------------------
-This makes a new branch called 'other' from 'master~5..master'
+This makes a new branch called 'other' from 'master{tilde}5..master'
(i.e. if 'master' has linear history, it will take the last 5 commits).
Note that this assumes that none of the blobs and commit messages
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index c2f483a..39494e3 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -103,7 +103,7 @@ amount of memory usage and processing time. Assuming the frontend
is able to keep up with fast-import and feed it a constant stream of data,
import times for projects holding 10+ years of history and containing
100,000+ individual commits are generally completed in just 1-2
-hours on quite modest (~$2,000 USD) hardware.
+hours on quite modest ({tilde}$2,000 USD) hardware.
Most bottlenecks appear to be in foreign source data access (the
source just cannot extract revisions fast enough) or disk IO (fast-import
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 45c9643..89fbc3d 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -37,7 +37,7 @@ OPTIONS
the destination ref.
+
The <src> side represents the source branch (or arbitrary
-"SHA1 expression", such as `master~4` (four parents before the
+"SHA1 expression", such as `master{tilde}4` (four parents before the
tip of `master` branch); see linkgit:git-rev-parse[1]) that you
want to push. The <dst> side represents the destination location.
+
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 59c1b02..9cf9940 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -334,7 +334,7 @@ errors), the loop will stop to let you fix things, and you can continue
the loop with `git rebase --continue`.
For example, if you want to reorder the last 5 commits, such that what
-was HEAD~4 becomes the new HEAD. To achieve that, you would call
+was HEAD{tilde}4 becomes the new HEAD. To achieve that, you would call
'git-rebase' like this:
----------------------
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 6abaeac..c25ff2a 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -80,7 +80,7 @@ $ git commit ...
$ git reset --hard HEAD~3 <1>
------------
+
-<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
+<1> The last three commits (HEAD, HEAD{caret}, and HEAD{tilde}2) were bad
and you do not want to ever see them again. Do *not* do this if
you have already given these commits to somebody else.
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 2921da3..823ff52 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -221,7 +221,7 @@ when you run 'git-merge'.
* A suffix '{tilde}<n>' to a revision parameter means the commit
object that is the <n>th generation grand-parent of the named
- commit object, following only the first parent. I.e. rev~3 is
+ commit object, following only the first parent. I.e. rev{tilde}3 is
equivalent to rev{caret}{caret}{caret} which is equivalent to
rev{caret}1{caret}1{caret}1. See below for a illustration of
the usage of this form.
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index d3f2588..853eec4 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -87,7 +87,7 @@ OPTIONS
--sha1-name::
Instead of naming the commits using the path to reach
- them from heads (e.g. "master~2" to mean the grandparent
+ them from heads (e.g. "master{tilde}2" to mean the grandparent
of "master"), name them with the unique prefix of their
object names.
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index 48b612e..2ec3e88 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -54,7 +54,7 @@ git show v1.0.0::
git show v1.0.0^\{tree\}::
Shows the tree pointed to by the tag `v1.0.0`.
-git show next~10:Documentation/README::
+git show next{tilde}10:Documentation/README::
Shows the contents of the file `Documentation/README` as
they were current in the 10th last commit of the branch
`next`.
diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
index a96403c..0592e56 100644
--- a/Documentation/git-tools.txt
+++ b/Documentation/git-tools.txt
@@ -100,7 +100,7 @@ Foreign SCM interface
Others
------
- - *(h)gct* (http://www.cyd.liu.se/users/~freku045/gct/)
+ - *(h)gct* (http://www.cyd.liu.se/users/{tilde}freku045/gct/)
Commit Tool or (h)gct is a GUI enabled commit tool for git and
Mercurial (hg). It allows the user to view diffs, select which files
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index a417e59..1ba1188 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1650,7 +1650,7 @@ independent changes (if the order mattered, then they are not
independent by definition). You could instead merge those two
branches into the current branch at once. First let's undo what
we just did and start over. We would want to get the master
-branch before these two merges by resetting it to 'master~2':
+branch before these two merges by resetting it to 'master{tilde}2':
------------
$ git reset --hard master~2
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 59321a2..a10f2e4 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -53,7 +53,7 @@ the repository but are specific to one user's workflow) should go into
the `$GIT_DIR/info/exclude` file. Patterns which a user wants git to
ignore in all situations (e.g., backup or temporary files generated by
the user's editor of choice) generally go into a file specified by
-`core.excludesfile` in the user's `~/.gitconfig`.
+`core.excludesfile` in the user's `{tilde}/.gitconfig`.
The underlying git plumbing tools, such as
'git-ls-files' and 'git-read-tree', read
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 0ce916a..c917237 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -535,7 +535,7 @@ These options are mostly targeted for packing of git repositories.
--objects::
Print the object IDs of any object referenced by the listed
- commits. '--objects foo ^bar' thus means "send me
+ commits. '--objects foo {caret}bar' thus means "send me
all object IDs which I need to download if I have the commit
object 'bar', but not 'foo'".
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 08d1310..7e25b69 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -570,7 +570,7 @@ $ git show HEAD~4 # the great-great-grandparent
-------------------------------------------------
Recall that merge commits may have more than one parent; by default,
-^ and ~ follow the first parent listed in the commit, but you can
+{caret} and {tilde} follow the first parent listed in the commit, but you can
also choose:
-------------------------------------------------
@@ -1836,7 +1836,7 @@ We explain how to do this in the following sections.
Setting up a public repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Assume your personal repository is in the directory ~/proj. We
+Assume your personal repository is in the directory {tilde}/proj. We
first create a new clone of the repository and tell git-daemon that it
is meant to be public:
@@ -3200,7 +3200,7 @@ Usually, dangling blobs and trees aren't very interesting. They're
almost always the result of either being a half-way mergebase (the blob
will often even have the conflict markers from a merge in it, if you
have had conflicting merges that you fixed up by hand), or simply
-because you interrupted a "git-fetch" with ^C or something like that,
+because you interrupted a "git-fetch" with {caret}C or something like that,
leaving _some_ of the new objects in the object database, but just
dangling and useless.
@@ -3991,7 +3991,7 @@ $ git cat-file blob cc44c73... >hello.c~3
$ git merge-file hello.c~2 hello.c~1 hello.c~3
------------------------------------------------
-This would leave the merge result in `hello.c~2` file, along
+This would leave the merge result in `hello.c{tilde}2` file, along
with conflict markers if there are conflicts. After verifying
the merge result makes sense, you can tell git what the final
merge result for this file is by:
--
1.6.0.2.451.ga9ffc
^ permalink raw reply related
* [PATCH] Documenation: git-bundle: quote tildes that cause subscript
From: Thomas Rast @ 2008-09-15 9:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1221470398-8698-1-git-send-email-trast@student.ethz.ch>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-bundle.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 1b66ab7..fc229f6 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -79,11 +79,11 @@ SPECIFYING REFERENCES
'git-bundle' will only package references that are shown by
'git-show-ref': this includes heads, tags, and remote heads. References
-such as master~1 cannot be packaged, but are perfectly suitable for
+such as master{tilde}1 cannot be packaged, but are perfectly suitable for
defining the basis. More than one reference may be packaged, and more
than one basis can be specified. The objects packaged are those not
contained in the union of the given bases. Each basis can be
-specified explicitly (e.g., ^master~10), or implicitly (e.g.,
+specified explicitly (e.g., ^master{tilde}10), or implicitly (e.g.,
master~10..master, master --since=10.days.ago).
It is very important that the basis used be held by the destination.
--
1.6.0.2.451.ga9ffc
^ permalink raw reply related
* [PATCH] Documentation: Quote ~(s) causing subscript
From: Thomas Rast @ 2008-09-15 9:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This is actually not a series, but a choice. I noticed that
git-bundle.html has a stray subscript in the first paragraph of
'Specifying References', so here are two options:
* Documenation: git-bundle: quote tildes that cause subscript
The minimal-impact change. Quotes just enough tildes in that
paragraph to avoid the subscript.
* Documentation: replace [^~] with escapes everywhere
The global change. Quotes all tildes and carets to avoid any future
confusion.
I like the global change better, because any tilde or caret is a
possible future pitfall: it will trigger a sub/superscript as soon as
a matching delimiter is added within the same paragraph. But of
course it makes the ascii non-markup less readable as plain text.
Searching through history and list archives didn't exactly help: as
early as babfaba (Fix usage of carets in git-rev-parse(1),
2005-10-05), the {caret} was established. However, in a thread on
precisely the paragraph in git-bundle.txt I'm trying to fix,
http://thread.gmane.org/gmane.comp.version-control.git/50761
the discussion turned to trying to figure out a consistent asciidoc
behaviour -- and from there, style guide -- but died. The patch
apparently never made it into git.git in either the \~ or the {tilde}
form.
- Thomas
^ permalink raw reply
* Re: [Monotone-devel] Re: [ANN] mtn2git v0.1
From: Markus Wanner @ 2008-09-15 9:07 UTC (permalink / raw)
To: Felipe Contreras
Cc: devel, openembedded-devel, monotone-devel, git, Jakub Narebski
In-Reply-To: <94a0d4530809130821h6f424695xe09386243c3213c3@mail.gmail.com>
Hi,
Felipe Contreras wrote:
> Monotone can have multiple heads in one single branch, but from what I
> understand that mostly happens locally (not on the published repo).
Uh.. no, I'd say quite the opposite: if multiple developers work on the
same branch and do their commits, the first time both heads appear in
the same branch on the same machine will be the public repository.
> Anyway, If that happens the commits are still there, just dangling
> temporarily in no branch.
..for the mtn repo imported into git that is, right?
Regards
Markus Wanner (ne Schiltknecht)
^ permalink raw reply
* git-clone: path or ssh problem with git-upload-pack in 1.6.0?
From: Paul Johnston @ 2008-09-15 8:30 UTC (permalink / raw)
To: git
In-Reply-To: <d3a045300809091929h18c3c447gb3d4e79131f66986@mail.gmail.com>
I'm having trouble with git-clone and I'm wondering if there's
something I'm doing wrong or something wrong with git. Probably the
former, hopefully someone can set me straight.
I'm an admittedly novice git user. I'm trying to clone a repository
over ssh. The host machine 'imac' is my mac osx 10.4 with git 1.6.0
installed from a macports package. This installs into /opt/local/bin.
I also cloned git from HEAD and 'make; make install'ed into ~/bin,
this is the version shown below. Either way, these are
nonstandard/non-system-wide installation locations, and it requires
that my shell PATH reflect this, obviously.
----------------------------------------------
# About my installation
imac:~ paul$ which git
/Users/paul/bin/git
imac:~ paul$ git --version
git version 1.6.0.1.285.g1070
imac:~ paul$ ls /opt/local/bin/git*
/opt/local/bin/git
/opt/local/bin/git-upload-archive /opt/local/bin/gitk
/opt/local/bin/git-receive-pack /opt/local/bin/git-upload-pack
imac:~ paul$ ls ~/bin/git*
/Users/paul/bin/git
/Users/paul/bin/git-shell
/Users/paul/bin/git-upload-pack
/Users/paul/bin/git-receive-pack
/Users/paul/bin/git-upload-archive
# Make a simple reposirtory /tmp/test/.git
imac:~ paul$ cd /tmp
imac:/tmp paul$ mkdir test; cd test; echo 'Hello World' > README; git
init; git add README; git commit -a -m'Initial import'; cd ..
Initialized empty Git repository in /private/tmp/test/.git/
Created initial commit 49c10e6: Initial import
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 README
# OK, this fails expectedly
imac:/tmp paul$ cd ~
imac:~ paul$ git clone ssh://localhost/tmp/test/.git
Initialized empty Git repository in /Users/paul/test/.git/
Password:
bash: line 1: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly
# This has been killing me... Have tried numerous variants of the
same with similar results...
imac:~ paul$ git clone --upload-pack /opt/local/bin/git-upload-pack
ssh://localhost/tmp/test/.git
Initialized empty Git repository in /Users/paul/test/.git/
Password:
remote: fatal: exec pack-objects failed.
error: git-upload-pack: git-pack-objects died with error.
fatal: git-upload-pack: aborting due to possible repository corruption
on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
# Fix it with symlinks in /usr/bin
imac:~ paul$ cd /usr/bin/
imac:/usr/bin paul$ sudo ln -s /opt/local/bin/git* .
imac:/usr/bin paul$ ls -al git*
lrwxr-xr-x 1 root wheel 18 Sep 9 19:18 git -> /opt/local/bin/git
lrwxr-xr-x 1 root wheel 31 Sep 9 19:18 git-receive-pack ->
/opt/local/bin/git-receive-pack
lrwxr-xr-x 1 root wheel 33 Sep 9 19:18 git-upload-archive ->
/opt/local/bin/git-upload-archive
lrwxr-xr-x 1 root wheel 30 Sep 9 19:18 git-upload-pack ->
/opt/local/bin/git-upload-pack
lrwxr-xr-x 1 root wheel 19 Sep 9 19:18 gitk -> /opt/local/bin/gitk
# And now git-clone works as expected...
imac:/usr/bin paul$ cd
imac:~ paul$ git clone ssh://localhost/tmp/test/.git
Initialized empty Git repository in /Users/paul/test/.git/
Password:
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.
imac:~ paul$ find test/
test/
test//.git
{ file listing removed for brevity... }
test//README
-------------------------------------------
OK, great, now it works. I suspect I'm not using the --upload-pack
option correctly or my ssh installation is suboptimal, but as I could
find no existing documentation on the subject, I am posting this
message. Any thoughts?
Paul Johnston
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Michael Radziej @ 2008-09-15 8:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080909231009.GD10544@machine.or.cz>
Hi!
I'm just starting to toy around with TopGit. Please excuse if I am simply
too naive :-)
I wonder about the .topmsg and .topdeps files. Why is this information
within the topic branch? It tends to get into the way even though a special
merge driver is provided. For example, you cannot do octopus merges (which I
found very confusing as first-time user). And it might also confuse people
cloning a TopGit repository and want to use a topgit branch. They might not
be aware of these special TopGit things.
I'd rather have a dedicated branched named e.g. 'TopGit' which includes the
information that is currently in .topmsg and .topdeps, but for all branches
in a repository.
Cheers,
Michael Radziej
--
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk -
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689
^ permalink raw reply
* Re: [PATCH 10/16] grep: skip files that have not been checked out
From: Jakub Narebski @ 2008-09-15 7:48 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <48cdd6cb7415e_3c273fa85e999d2827466@app01.zenbe.com.tmail>
Duy Nguyen wrote:
> On 09/15/2008 "Jakub Narebski" <jnareb@gmail.com> wrote:
> >Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> >
> > > Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> > > ---
> > > builtin-grep.c | 7 ++++++-
> > > 1 files changed, 6 insertions(+), 1 deletions(-)
> >
> > No changes to Documentation/git-grep.txt?
>
> No, "git grep" should only grep files in working directories. In
> narrow checkout mode, some files may be missing but current "git grep"
> does not know about that, hence this fix.
Perhaps that should be stated explicitly, that git-grep searches only
[intentionally] checked-out files when searching working directory,
and only files without no-checkout bit set when searching index with
"git grep --cached".
P.S. I think it should be [--cached|<tree>...] in git-grep synopsis,
and not [--cached] ... [<tree>...], but that is unrelated thing, and
doesn't matter to you.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 14/16] clone: support narrow checkout with --path option
From: Jakub Narebski @ 2008-09-15 7:40 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <48cdd598c6cd9_12e03ff42d900428232ec@app02.zenbe.com.tmail>
Duy Nguyen wrote:
> On 09/15/2008 "Jakub Narebski" <jnareb@gmail.com> wrote:
> >
> > Second, how `--path=<narrow_spec>` interacts with `-n' (no checkout).
> > Does it even have any sense? Perhaps those options should be mutually
> > incompatibile (and --bare and this option too)?
>
> Yes they are incompatible and won't work if either -n or --bare is provided with --path.
Perhaps that should be stated explicitly? It is quite obvious, but...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: Junio C Hamano @ 2008-09-15 7:43 UTC (permalink / raw)
To: David Brown; +Cc: dhruva, GIT SCM, Simon Hausmann
In-Reply-To: <20080915063521.GA1533@linode.davidb.org>
David Brown <git@davidb.org> writes:
> ... As far as I can tell, P4 completely
> ignores whatever the $Id: ...$ headers happen to be expanded to at the
> time of checking. You can put garbage there, and it check in fine.
> ...
> I guess it isn't a problem to make this optional in git-p4, but I
> don't think this patch is solving the right problem.
Hmm. I do not do p4, but what I am guessing is that there probably is a
configuration switch on the p4 side that lets you check in files with
"$Id: garbage $" in them, while dhruva hasn't turned that switch on.
It could be (1) not flipping the switch on is a user mistake and dhruva
can just flip it to fix his problem, or (2) the policy of dhruva's project
mandates the switch to stay off, and he needs the patch to work around the
issue.
I cannot judge which is the case myself, but if the situation is the
former, we would need a documentation to suggest that magic p4 switch as a
workaround that would work for everybody without hurting anybody. On the
other hadn, if the situation is the latter, we would need this patch in
addition to the suggestion of the magic p4 switch that the user _may_ be
able to flip depending on the project policy on the p4 side.
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Karl Hasselström @ 2008-09-15 7:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0809141419q6facb21at627e658805f1d223@mail.gmail.com>
On 2008-09-14 22:19:41 +0100, Catalin Marinas wrote:
> I wasn't used to reading documentation in StGit files :-). Thanks
> for the info, I'll repost.
It was you who asked for in-code docs. :-) The new-infrastructure code
actually looks half decent in epydoc nowadays.
> I'll make the default behaviour to cancel the transaction and revert
> to the original state unless an option is given to allow conflicts.
What I've always wanted is "sink this patch as far as it will go
without conflicting". This comes awfully close.
BTW, this kind of flag might potentially be useful in many commands
(with default value on or off depending on the command). Maybe
--conflicts=roll-back|stop-before|allow
to indicate if the command should roll back the whole operation, stop
just before the conflicting push, or allow conflicts.
> I can see calls to pop_patches(lambda pn: pn in patch_list). I think
> we could have a helper for this.
Indeed.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: dhruva @ 2008-09-15 7:21 UTC (permalink / raw)
To: David Brown; +Cc: GIT SCM, Junio C Hamano, Simon Hausmann
Hello,
----- Original Message ----
> From: David Brown <git@davidb.org>
> To: dhruva <dhruva@ymail.com>
> Cc: GIT SCM <git@vger.kernel.org>; Junio C Hamano <gitster@pobox.com>; Simon Hausmann <simon@lst.de>
> Sent: Monday, 15 September, 2008 12:05:21 PM
> Subject: Re: [PATCH] Optional shrinking of RCS keywords in git-p4
>
> On Mon, Sep 15, 2008 at 11:56:22AM +0530, dhruva wrote:
>
> >8. The git diffs is now not aware of the change in RCS keyword
> >9. You try to submit your local changes back to p4
> >10. Applying your local changes as patch sets will fail with missing hunks
> tracking RCS keyword changes
>
> It sounds like you are trying to apply these as patches to a tree
> which doesn't have RCS headers. As far as I can tell, P4 completely
> ignores whatever the $Id: ...$ headers happen to be expanded to at the
> time of checking. You can put garbage there, and it check in fine.
I think I now understand this better. If git-p4 is always collapsing the RCS keywords, it should not see it even while it is applying a patch. What bugs me is I got repeated hunk failures during 'git-p4 submit'. It always pointed to RCS keyword. I see it trying 'git-p4' trying to apply the patch and it fails. In the .rej file, I see the expanded RCS keyword (even without my patch that makes it optional). I then started doubting if I had done a 'p4 sync -f' which will bring in files with RCS keywords expanded. If that was the case, git would have found changed files that I have not committed.
I am a bit lost here, I will try to use this for some more time and see if I see such issues (with and without my git-p4 changes).
Thanks for making me look deeper!
-dhruva
Download prohibited? No problem. CHAT from any browser, without download. Go to http://in.webmessenger.yahoo.com/
^ permalink raw reply
* Re: [StGit PATCH] Autosign newly created patches
From: Karl Hasselström @ 2008-09-15 7:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0809141405u6e309f11q80edcfd59eb942dd@mail.gmail.com>
On 2008-09-14 22:05:04 +0100, Catalin Marinas wrote:
> There isn't a test but the command description suggests that
> patchdesr.tmpl file will be used if present.
>
> Should we keep this feature? The only case where I was using it was
> for automatic signed-off-by line.
I don't really have an opinion, as I don't use it.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Git Gui does not want to work on chunk level
From: Johannes Sixt @ 2008-09-15 7:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Alexander Gladysh, git-users, git
In-Reply-To: <20080905045327.GA31166@spearce.org>
Shawn O. Pearce schrieb:
> git-gui: Fix diff parsing for lines starting with "--" or "++"
>
> Languages like Lua and SQL use "--" to mark a line as commented out.
> If this appears at column 0 and is part of the pre-image we may see
> "--- foo" in the diff, indicating that the line whose content is
> "-- foo" has been removed from the new version.
>
> git-gui was incorrectly parsing "--- foo" as the old file name
> in the file header, causing it to generate a bad patch file when
> the user tried to stage or unstage a hunk or the selected line.
> We need to keep track of where we are in the parsing so that we do
> not misread a deletion or addition record as part of the header.
This (slightly) breaks parsing of new files and removed files that are
staged by showing the file names in the diff header:
new file mode 100644
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+foo
-- Hannes
^ permalink raw reply
* Re: Git User's Survey 2008 partial summary, part 5 - other SCM
From: Andreas Ericsson @ 2008-09-15 7:00 UTC (permalink / raw)
To: david; +Cc: Nguyen Thai Ngoc Duy, Jakub Narebski, git
In-Reply-To: <alpine.DEB.1.10.0809142038190.19489@asgard.lang.hm>
david@lang.hm wrote:
> On Sun, 14 Sep 2008, Nguyen Thai Ngoc Duy wrote:
>
>> On 9/12/08, Jakub Narebski <jnareb@gmail.com> wrote:
>>> 15) Do you miss features in git that you know from other SCMs?
>>> If yes, what features are these (and from which SCM)?
>>> (Open ended text - Essay)
>>>
>>> Total respondents 1046 (some/many of them wrote 'no')
>>> skipped this question 1249
>>>
>>> This is just a very quick summary, based on a first few pages of
>>> responses, Full analysis is I think best left for after closing the
>>> survey, because I think this would be a lot of work...
>>>
>>> So here is preliminary list, or rather beginning of one:
>>> * sparse/partial checkout and clone (e.g. Perforce)
>>
>> Have not read the survey result, but do you recall what is the most
>> used term for sparse/partial checkout? What SCMs do sparse/partial
>> checkout? I think it could be usable as it is now in my
>> will-be-sent-again series, but I don't really know how people want it
>> to from that.
>
> the most common use-case is people who want to follow a project but (at
> least think that they) don't need the history. so they want to save
> time/bandwideth/disk space by not downloading things they don't need.
>
I disagree, and this would be a thin or shallow checkout to me (although
I realize the nomenclature is unfortunately similar here). What I've
heard is normally documentation writers that don't want to be able to
even accidentally modify any code, so they just want Documentation/
subdirectory. Shallow clones are already supported (albeit with a lot
of limitations).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: David Brown @ 2008-09-15 6:35 UTC (permalink / raw)
To: dhruva; +Cc: GIT SCM, Junio C Hamano, Simon Hausmann
In-Reply-To: <16219.81556.qm@web95005.mail.in2.yahoo.com>
On Mon, Sep 15, 2008 at 11:56:22AM +0530, dhruva wrote:
>8. The git diffs is now not aware of the change in RCS keyword
>9. You try to submit your local changes back to p4
>10. Applying your local changes as patch sets will fail with missing hunks tracking RCS keyword changes
It sounds like you are trying to apply these as patches to a tree
which doesn't have RCS headers. As far as I can tell, P4 completely
ignores whatever the $Id: ...$ headers happen to be expanded to at the
time of checking. You can put garbage there, and it check in fine.
I've been checking in files for many years with stripped headers. I
wrote a python script years ago to strip the P4 headers after Perforce
was unwilling to implement this as an option.
I guess it isn't a problem to make this optional in git-p4, but I
don't think this patch is solving the right problem.
David
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: dhruva @ 2008-09-15 6:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT SCM
Hello,
----- Original Message ----
> From: Junio C Hamano <gitster@pobox.com>
> To: Dhruva Krishnamurthy <dhruva@ymail.com>
> Cc: GIT SCM <git@vger.kernel.org>
> Sent: Monday, 15 September, 2008 11:47:19 AM
> Subject: Re: [PATCH] Optional shrinking of RCS keywords in git-p4
>
> Dhruva Krishnamurthy writes:
>
> > Modifying RCS keywords prevents submitting to p4 from git due to missing
> hunks.
>
> Hmm. How are "missing hunks" caused? Do you mean:
>
> - the substituted values from the expanded keywords are stripped out by
> default (with kwstrip=True) when you check out from p4;
>
> - when you submit your changes back, p4 side expects you to send the file
> with keywords just as it originally expanded;
>
> and this causes the contents mismatch, leading p4 to reject your change?
Yes (you got my point ;), I have quite often stumbled in conveying things in a crisp manner (on going learning process)
> The patch itself looks fine; I just wanted to make sure commit log
> explains what was fixed.
-dhruva
Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: dhruva @ 2008-09-15 6:26 UTC (permalink / raw)
To: David Brown; +Cc: GIT SCM, Junio C Hamano, Simon Hausmann
Hi,
If you have p4 files with 'ktext' enabled, it will expand RCS keywords. Here is how it goes wrong.
1. Clone from p4 with files of 'ktext' type
2. git-p4, converts "$Id:........" to "$Id$"
3. So, the file in p4 and git are different as RCS keywords are modified
4. You locally edit and commit into git a p4 file of type 'ktext'
5. The change history in your local git commit will not have any hunks to track the RCS keyword as they are not modified locally
6. Someone edits the same file on p4 and submits
7. you do a git rebase (which pulls in the new modifications and strips the RCS keyword change, p4 submit would have incremented the $Id:....$)
8. The git diffs is now not aware of the change in RCS keyword
9. You try to submit your local changes back to p4
10. Applying your local changes as patch sets will fail with missing hunks tracking RCS keyword changes
I have personally experienced more often and hence decided to dig into git-p4 and fix it. All C/C++ source code is created in our p4 repo as 'ktext' and I keep stumbling on this very often. Ideally, if they were just 'text' type in p4, I would never have seen this problem.
-dhruva
PS: Simon Hausmann, I missed adding you in CC of the patch as my .gitconfig was still under stablizing. I apologize for that. I have finally set up my ..gitconfig with 'git-p4' identity to add you in loop when I submit.
----- Original Message ----
> From: David Brown <git@davidb.org>
> To: Dhruva Krishnamurthy <dhruva@ymail.com>
> Cc: GIT SCM <git@vger.kernel..org>; Junio C Hamano <gitster@pobox.com>
> Sent: Monday, 15 September, 2008 11:39:55 AM
> Subject: Re: [PATCH] Optional shrinking of RCS keywords in git-p4
>
> On Mon, Sep 15, 2008 at 11:28:51AM +0530, Dhruva Krishnamurthy wrote:
>
> >Modifying RCS keywords prevents submitting to p4 from git due to missing hunks.
> >New option git-p4.kwstrip set to true or false controls the behavior.
>
> I'm a little curious about what the problem here is. I've been
> stripping keywords out of P4 and submitting changes for many years,
> and never had a problem.
>
> I'm just wondering if we're not fixing the wrong problem here.
>
> David
> --
> 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
Connect with friends all over the world. Get Yahoo! India Messenger at http://in.messenger.yahoo.com/?wm=n/
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: Junio C Hamano @ 2008-09-15 6:17 UTC (permalink / raw)
To: Dhruva Krishnamurthy; +Cc: GIT SCM
In-Reply-To: <1221458331-8804-1-git-send-email-dhruva@ymail.com>
Dhruva Krishnamurthy <dhruva@ymail.com> writes:
> Modifying RCS keywords prevents submitting to p4 from git due to missing hunks.
Hmm. How are "missing hunks" caused? Do you mean:
- the substituted values from the expanded keywords are stripped out by
default (with kwstrip=True) when you check out from p4;
- when you submit your changes back, p4 side expects you to send the file
with keywords just as it originally expanded;
and this causes the contents mismatch, leading p4 to reject your change?
The patch itself looks fine; I just wanted to make sure commit log
explains what was fixed.
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: David Brown @ 2008-09-15 6:09 UTC (permalink / raw)
To: Dhruva Krishnamurthy; +Cc: GIT SCM, Junio C Hamano
In-Reply-To: <1221458331-8804-1-git-send-email-dhruva@ymail.com>
On Mon, Sep 15, 2008 at 11:28:51AM +0530, Dhruva Krishnamurthy wrote:
>Modifying RCS keywords prevents submitting to p4 from git due to missing hunks.
>New option git-p4.kwstrip set to true or false controls the behavior.
I'm a little curious about what the problem here is. I've been
stripping keywords out of P4 and submitting changes for many years,
and never had a problem.
I'm just wondering if we're not fixing the wrong problem here.
David
^ permalink raw reply
* Re: [PATCH] Modifying RCS keywords prevents submitting to p4 from git due to missing hunks. Optional shrinking of RCS keywords in git-p4. New option git-p4.kwstrip set to true or false controls the behavior
From: dhruva @ 2008-09-15 6:02 UTC (permalink / raw)
To: sverre; +Cc: GIT SCM, Junio C Hamano
I had a real tough time configuring 'git send-email'. Looks like I finally have something working... I am still finding it tough to handle identity. I am figuring it out now by trial and error (with more errors) basis
-dhruva
----- Original Message ----
> From: Sverre Rabbelier <alturin@gmail.com>
> To: Dhruva Krishnamurthy <dhruva@ymail.com>
> Cc: "GIT SCM <git@vger.kernel.org>, Junio C Hamano" <gitster@pobox.com>
> Sent: Monday, 15 September, 2008 10:24:37 AM
> Subject: Re: [PATCH] Modifying RCS keywords prevents submitting to p4 from git due to missing hunks. Optional shrinking of RCS keywords in git-p4. New option git-p4.kwstrip set to true or false controls the behavior
>
> On Mon, Sep 15, 2008 at 06:16, Dhruva Krishnamurthy wrote:
> >
> > Signed-off-by: Dhruva Krishnamurthy
>
> I think something went wrong here, yes? The current title is way too
> long, and there is no commit message, perhaps you meant to put (part
> of) the title in the message instead?
>
> "[PATCH] Modifying RCS keywords prevents submitting to p4 from git due
> to missing hunks. Optional shrinking of RCS keywords in git-p4. New
> option git-p4.kwstrip set to true or false controls the behavior"
>
> --
> Cheers,
>
> Sverre Rabbelier
Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08..html/
^ 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