* Re: [RFC] Two conceptually distinct commit commands
From: Junio C Hamano @ 2006-12-06 1:13 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87d56z32e1.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> ... The case I would use it for is fairly common,
> (and something that I think will speak to Junio who often brings
> up a similar scenario).
>
> Here's where I would like this functionality:
>
> I receive a patch while I'm in the middle of doing other work,
> (but with a clean index compared to HEAD, which is what I've
> usually). The patch looks good, so I want to commit it right
> away, but I do want to separate it into two or more pieces,
> (commonly this is because I want to separate the "add a test
> case demonstrating a bug" part from the "fix the bug"
> part).
(This is offtopic)
I often faced situations like that during git.git history. One
patch to expose the bug in the existing code, and another to fix
it. And there are three ways to make that commit.
(1) one commit exposes, then another fixes.
(2) one commit fixes, then another verifies the bug is no more.
(3) one commit to include both.
In my experience, (1) is only useful during the time I am coming
up with the fix (if I am fixing it myself) or during the time I
am reviewing and committing the fix (if I am applying somebody
else's patch). Committing in that order lets me validate the
brokenness after making the first commit, and then lets me feel
good by not seeing that problem after the second commit. But
this means I deliberately record a state that is known not to
pass the test, which means it is a problem for somebody else in
the future when the history needs to be bisected to hunt for an
unrelated bug. If the "test" is just an optional test in the
test suite, then it is easy to work around (the person who is
bisecting can ignore that bug by not running that particular
test), but if it is an assert somewhere deep inside the code,
ignoring it is not very easy, especially if the person who is
bisecting is not familiar with that part of the code.
What I recommend people to do these days is either (2) or (3),
but do so _after_ verifying the fix in the reverse order. The
criteria to choose between (2) or (3) is fairly simple: if the
"test" is easily separable (e.g. changes to a test script file
that does not overlap with the "fix" patch), roll both in one
commit. Then it would not later cause problems for bisection.
Enough of offtopic.
The sequence to split a patch in place would be (I'll speak in
the present tense and pretend Nico's "git add" does not exist
yet):
git apply
git update-index <files for the first batch>
git commit
git commit -a ;# the remainder
so you do not necessarily need a new "concept". It is
inconvenient that you need to deal with new files, but that is a
minor detail compared to a bigger problem I'll mention in the
next paragraph.
I think the problem with your thinking is that you still are
talking from "file boundary matters" point of view. The above
sequence is only useful if the patch to be split is separable
cleanly at the file boundary, in which case, I would (and I've
done so often) split the patch file in my editor and run two
independent "git apply + git commit" sequences. That way, I
could test each in isolation (perhaps with some dirty working
tree state if I do not stash them away and do reset --hard).
Anything more realistic and practically useful would require
splitting of the patch in semantic ways regardless of file
boundaries.
As I have already said (and you seemed to share the same
discipline), I do not like people committing anything
non-trivial that is not tested. The patch you received might
not have been tested by the submitter, but there is a chance
that it might have been ;-). But with the way you said you want
to make the commits in the message I am responding to, the first
commit would never have been tested by anybody in isolation, not
by the original submitter even if he tested the patch before
giving it to you, nor you -- your working tree had either none
of his patch or all of it, and never was in the state with only
the first batch.
So while at the theoretical level I understand what you would
want to achieve with the "single patch that should have been
sent as two patch series" example, from the practical point of
view I do not see much value in it (because "file boundary
matters" is a minority case that is not very interesting), and
from the discipline point of view I would rather not want to
have such a too-convenient way to commit things that were
different in nontrivial ways from what you had in your working
tree (if we use something like Darcs record to update
hunk-by-hunk).
> The old behavior is still available with the --include option, but
> nobody has ever come out in favor of that being a useful command,
That is a slight overstatement. When committing with paths
argument to conclude a merge, --include semantics is the only
variant that makes sense (--only semantics is so wrong that
there is a safety valve that catches it). Most of the time,
however, if I need to resolve and record a complicated merge, I
would either do "update-index" to clear the deck of the paths
that I already dealt with, and by the time I would type "git
commit", I have an index that has exactly what I want in the
merge commit. That makes --include a less often used form. If
a merge is small and easy to resolve at only a few paths, it
still is handy to say "git commit -i resolved-path.c". It does
not add anything to the semantics -- it is only a typesaver.
^ permalink raw reply
* Re: git newbie problems
From: Jakub Narebski @ 2006-12-06 1:23 UTC (permalink / raw)
To: git
In-Reply-To: <457611B9.9020907@gmail.com>
Graham Percival wrote:
> Greetings,
>
> I'm posting these problems at Han-Wen and Dscho's insistence. I'm the
> documentation editor for GNU/LilyPond, so I'm reluctant to criticize
> other project's documentation unless I spend an hour or more seriously
> reading it. I'm quite willing to admit that I never seriously tried to
> read the docs on the overall theory of git (branches, repo, etc); I just
Branches are very useful concept. And I really like the idea of branches in
git (the underlying concept of branch as lineage) and its implementation.
But because CVS had seriously screwed implementation of branches, you
probably didn't use it.
> flailed around looking for magic commands to make things work. By "make
> things work", I mean imitating my work style with cvs:
Perhaps it would be better to at least read cvs-migration.txt
http://kernel.org/pub/software/scm/git/docs/cvs-migration.html
and all tutorials.
> cvs co blah blah (which I simply copy and paste from savannah)
> while (true) {
> cvs update // get changes that happened overnight
"git pull", or "git fetch". "git pull" is more like in CVS, because it
merges the changes that happened overninght with your work.
> vi foo/bar/baz.txt // or whatever editing commands you do
> make; make web // or whatever testing commands you do
Those steps do not depend on version control used.
> cvs update // get latest changes to prepare for
> // uploading my changes.
> cvs ci foo/bar/baz.txt // upload changes
With git you do this sequence not in braindead CVS "update then commit"
which leads to rare commits (because you don't have time to resolve merge
conflicts for example), but commit then upload changes.
"git commit -a" to commit changes (the standard format of commit message
describing the change expected by history viewers is to write short
one-line description of changes, separate by empty line from longer
description if it is needed (it usually is): see
http://git.or.cz/gitwiki/CommitMessageConventions
(and also other pages on GitDocumentation page at GitWiki as well)).
Then "git push" to propagate your changes (or if you don't have permissions
to push into repository, "git format-patch HEAD^.." and "git send-mail" to
propagate your changes via email).
> }
>
> Once or twice a year I'll do "cvs diff" or "cvs add", but all I really
> want are the above commands. I figured that this should be really easy
> to do, so I kept on skimming through the docs, trying to find the
> equivalent of these really easy commands. (note that I was reading the
> "tutorial introduction to git")
There are some commands which CVS didn't have, and which are very useful
with git: I'm talking here about "git show" (show latest change), "git
log" (show kind of changelog), and gitk (graphical history viewer) or qgit
(alternate graphical history viewer in Qt).
It is also of note that you can move and rename files, soemthing CVS had
much problems with.
> I should add that I've received help on the lilypond-devel list; I'm
> posting this in case it helps future development for git docs, not
> because I need more help to use git.
>
> This case was particularly difficult because the very first time I tried
> to commit... err... push... err... "make my doc changes available to
> everybody else" (whatever the right term is), there was this merge
> problem.
>
>
>
> MERGE PROBLEM
>
> Two people (me and another person) edited the same line on
> Documentation/user/advanced.itely at the same time. (note that this
> file has existed for over a year; it's not a new file) When I tried to
> get the most recent changes, I'm greeted with this:
> ...
> Trying really trivial in-index merge...
> Documentation/user/advanced-notation.itely: needs merge
> fatal: you need to resolve your current index first
> Nope.
> Merging HEAD with c21d3f3e1c77722e50d994763442e6f994b03ac2
> Merging:
> 038b7fc Misc small updates (trying to make git work).
> c21d3f3 Merge branch 'master' of
> ssh+git://hanwen@git.sv.gnu.org/srv/git/lilypond
> found 1 common ancestor(s):
> 84219bb don't have input/templates/ any longer.
> fatal: Entry '.gitignore' would be overwritten by merge. Cannot merge.
> No merge strategy handled the merge.
>
>
> As a git newbie, I'm quite confused. OK, there's no merge strategy...
> so what do I do now? With cvs, the changes would be dumped into the
> file. I look at the file, found the conflict, and tried it again. I
> got the same error message, and then it occurred to me that although I
> changed the files in my ~/usr/src/lilypond, git might be storing these
> files somewhere else.
Yes, the git error messages certainly needs to be made more user-friendly.
What git says here that one version has '.gitignore' file handled by version
control, and second has it outside version control. At least I think what
it does. "git ls-files --unmerged" or "git diff --merge --summary" should
show 'true conflicts'.
By the way, which version of git do you use? I think this particular check
(if it is the case of this error) was relaxed.
> So I tried
> $ git commit Documentation/user/advanced-notation.itely
> Cannot do a partial commit during a merge.
> You might have meant to say 'git commit -i paths...', perhaps?
Hint: usually "git reset" or even "git reset --hard" *warning: the latter
would overwrite your changes since last commit! use with care) is what you
want to do to 'clean up' after some interrupted command.
> ... eh? I'm trying to fix this so that you _can_ merge! Regardless,
> when I tried to update again, I get
>
> $ git pull gnu master
> ...
> Trying really trivial in-index merge...
> fatal: Entry '.gitignore' would be overwritten by merge. Cannot merge.
> Nope.
> Merging HEAD with c21d3f3e1c77722e50d994763442e6f994b03ac2
> Merging:
> 038b7fc Misc small updates (trying to make git work).
> c21d3f3 Merge branch 'master' of
> ssh+git://hanwen@git.sv.gnu.org/srv/git/lilypond
> found 1 common ancestor(s):
> 84219bb don't have input/templates/ any longer.
> fatal: Entry '.gitignore' would be overwritten by merge. Cannot merge.
> No merge strategy handled the merge.
>
>
> Now I'm totally confused, because I definitely haven't touched .gitignore.
I'm guessing that "git add .gitignore", "git commit -a -m
'Added .gitignore'" before retyring pull/push would help in such situation.
> SUGGESTIONS
>
> The "tutorial introduction to git" looks like a nice document, but it
> assumes that you are in control of the project. For users who aren't in
> control (ie me) this is a problem, because it starts me skimming.
> "Importing a project"... nah, that's not me. "Merging branches"... I
> don't care; I'm going to shove everything into the main branch. "Using
> git for collaboration"... hmm, maybe this is the stuff I need to read.
> But by this point, I've already skimmed through five screens of info, so
> I'm not reading very carefully.
>
> It would be nice to have an accompanying "tutorial introduction to
> contributing with git" for users (like me) who are not in control of a
> project.
>
> Finally, it would be really nice if there was some mention of "resolving
> merge problems" in the tutorial (both in the current one and any new
> docs).
Check out "[DRAFT] Branching and merging with git" thread
Message-ID: <20061116221701.4499.qmail@science.horizon.com>
http://permalink.gmane.org/gmane.comp.version-control.git/31625
http://thread.gmane.org/gmane.comp.version-control.git/31625/
which I hope would end as Documentation/tutorial-3.txt. Or you can read jdl
presentation from OLS; check out GitLinks / GitDocumentation at GitWiki:
http://git.or.cz/gitwiki/
> (please CC me as I am not subscribed to the mailist)
I also am not subsribed to the mailing list, but read the list via GMane
NNTP (news, Usenet) interface: see http://git.or.cz/gitwiki/GitCommunity
nntp://news.gmane.org/gmane.comp.version-control.git
P.S. For wuick answers to "what to do now" questions you might use #git
channel on FreeNode.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git newbie problems
From: Junio C Hamano @ 2006-12-06 1:35 UTC (permalink / raw)
To: Graham Percival; +Cc: git
In-Reply-To: <457611B9.9020907@gmail.com>
Graham Percival <gpermus@gmail.com> writes:
> Trying really trivial in-index merge...
> Documentation/user/advanced-notation.itely: needs merge
> fatal: you need to resolve your current index first
You got from a "git pull", which means you were already in
another merge (perhaps failed). That is a no-no.
The error messages need to be cleaned up and be more helpful.
There is no question about it.
> Nope.
> Merging HEAD with c21d3f3e1c77722e50d994763442e6f994b03ac2
> Merging:
> 038b7fc Misc small updates (trying to make git work).
> c21d3f3 Merge branch 'master' of
> ssh+git://hanwen@git.sv.gnu.org/srv/git/lilypond
> found 1 common ancestor(s):
> 84219bb don't have input/templates/ any longer.
> fatal: Entry '.gitignore' would be overwritten by merge. Cannot merge.
> No merge strategy handled the merge.
So the question is what you did _before_ initiating this "git pull".
For new people, we recommend to:
* make sure you were on a right branch (I think you are. You
are on your 'master' branch and may not even have any other
branches, which is fine.)
* make sure all your changes are committed.
before initiating a "git pull". And after a conflicted "git
pull", if you choose to punt,
$ git reset --hard
would take you back to the state before you started the pull.
> SUGGESTIONS
>
> The "tutorial introduction to git" looks like a nice document, but it
> assumes that you are in control of the project. For users who aren't in
> control (ie me) this is a problem, because it starts me skimming.
> "Importing a project"... nah, that's not me. "Merging branches"... I
> don't care; I'm going to shove everything into the main branch. "Using
> git for collaboration"... hmm, maybe this is the stuff I need to read.
> But by this point, I've already skimmed through five screens of info, so
> I'm not reading very carefully.
Yes, git caters to too many classes of people.
I've heard people talk about "everyday" document as a good
table-of-contents, primarily because it first breaks down the
userbase into roles and talks about common commands for each
role of the user. I am not in the position to judge the quality
of the document, though.
^ permalink raw reply
* Re: [PATCH] git-explain
From: Nicolas Pitre @ 2006-12-06 1:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612060125320.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Wed, 6 Dec 2006, Johannes Schindelin wrote:
> In this spirit, maybe it is time to enable reflog per default?
Definitely.
^ permalink raw reply
* Re: git newbie problems
From: Tom Prince @ 2006-12-06 1:52 UTC (permalink / raw)
To: Graham Percival; +Cc: git
In-Reply-To: <457611B9.9020907@gmail.com>
On Tue, Dec 05, 2006 at 04:41:29PM -0800, Graham Percival wrote:
> Greetings,
>
> I'm posting these problems at Han-Wen and Dscho's insistence. I'm the
> documentation editor for GNU/LilyPond, so I'm reluctant to criticize
> other project's documentation unless I spend an hour or more seriously
> reading it.
It is generally accepted that much of git documentation sucks in various ways,
and people have stepped up to help fix this. The problem is that most
people are already well-versed in git, which makes it harder to identify
the problem areas in the documentation, and that few people unfamiliar
with git post to report their problems with the documentation, or UI so
that, at least on the mailinglist itself, we get little direct feedback on the
documentation or UI.
Thank you from the list for your contribution.
^ permalink raw reply
* git pull and merging.
From: Aneesh Kumar @ 2006-12-06 4:51 UTC (permalink / raw)
To: Git Mailing List
I have a git.git clone using --use-separate-remote. That means i have
the master branch created by default. Now i need to build git from the
pu branch too. So i created git branch pu remotes/origin/pu.
How how do i track the pu branch using git pull. What i mean is the
master local branch is tracked by default using git pull. Is there a
way to track the local pu branch too.
I looked at git-repo-config and branch.<name>. config variable usage
is confusing. After initial try i concluded that it is to replace
.git/remotes/origin not the requirement i had.
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Carl Worth @ 2006-12-06 4:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejrdbzdb.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 5685 bytes --]
On Tue, 05 Dec 2006 17:13:20 -0800, Junio C Hamano wrote:
> (This is offtopic)
It's an interesting topic nonetheless, so I'll comment anyway.
> (1) one commit exposes, then another fixes.
> (2) one commit fixes, then another verifies the bug is no more.
> (3) one commit to include both.
I feel very strongly that I want (1) in the history.
> unrelated bug. If the "test" is just an optional test in the
> test suite, then it is easy to work around (the person who is
> bisecting can ignore that bug by not running that particular
> test), but if it is an assert somewhere deep inside the code,
> ignoring it is not very easy, especially if the person who is
> bisecting is not familiar with that part of the code.
Granted, something like an assert that breaks the library would not be
a useful thing to have in the history. I'm certainly not in favor of
something like that.
I'm talking about tests that demonstrate pre-existing broken-ness in
the code. In the case of cairo, our test suite is entirely optional,
and each test is out-of-process, so even if a test totally crashes the
suite continues and it's easy to ignore that.
But it's not just the correctness test suite. We also have a
performance test suite, and I encourage the same "add test case, then
performance fix" pattern there. This shows an even more obvious
example of why it's useful to have separate commits in the history,
(since someone may want to verify the performance impact on a separate
system at any point in the future, and the two commits makes it easy
to get "before" and "after" for the performance fix results from the
new test case).
> The sequence to split a patch in place would be (I'll speak in
> the present tense and pretend Nico's "git add" does not exist
> yet):
>
> git apply
> git update-index <files for the first batch>
> git commit
> git commit -a ;# the remainder
Yes, I can use this today, and I do, (as I mentioned in my mail). The
only requirement is that I start with a non-dirty working tree. I can
arrange that, but it would be just a bit less inconvenient if I didn't
have to.
> so you do not necessarily need a new "concept".
No, I don't need it. And this "commit-index-content [paths...]" was
the least significant part of my proposal. As I said, originally I was
just going to say this "might be useful in some cases", but then
someone just happened to request this feature on the list at the same
time I was considering the proposal.
Anyway, it spite of this being an accidental feature of y proposal, it
seems to be the only part you commented on. Even if this functionality
weren't made available at all, I'd still be interested in your
comments on the main thrust of my proposal. I think that consists of:
1. Unifying the two current commands that provide
commit-working-tree-content semantics into a single,
use-oriented description.
2. Avoiding a change of semantics triggered by merely applying
pathname arguments without any command-line option or
alternate command name.
> As I have already said (and you seemed to share the same
> discipline), I do not like people committing anything
> non-trivial that is not tested.
Indeed. I like that discipline very much. And in fact, that's an
important reason that I split a patch that I receive like this, (or
just bounce it, which I often do, and would definitely do if it's not
easy to split)
> But with the way you said you want
> to make the commits in the message I am responding to, the first
> commit would never have been tested by anybody in isolation, not
> by the original submitter even if he tested the patch before
> giving it to you, nor you -- your working tree had either none
> of his patch or all of it, and never was in the state with only
> the first batch.
Who said I wouldn't test it? I do split commits like this precisely so
that I _can_ test it this way---and git helps a lot here. I do the
split commit, then easily back up to the revision that adds the test
case, verify the test fails before the bug fix, (which is something
the maintainer doesn't get a chance to do with your (2) approach),
then move forward and verify that the test passes after the fix.
So, sure, I haven't ever had that working tree before the commit. But
git makes it easy to get that working tree after I commit and test
everything before I push anything out.
[Incidentally, that's yet _another_ thing people can mention to
friends who come from cvs and think that the separation of commit and
push is annoying. And that's in addition to all of the performance
advantages, the ability to work entirely offline, etc. etc.]
> > The old behavior is still available with the --include option, but
> > nobody has ever come out in favor of that being a useful command,
>
> That is a slight overstatement.
OK. I should have worded that as "I wasn't aware of any arguments...".
> That makes --include a less often used form. If
> a merge is small and easy to resolve at only a few paths, it
> still is handy to say "git commit -i resolved-path.c". It does
> not add anything to the semantics -- it is only a typesaver.
Oh, OK. I see it now. That's for combining the update-index, (or
"resolve/resolved"---is there any consensus on that being a useful
synonym for update-index here?) and the commit into a single
command. I guess that's just a shortcut I've never used.
So, yes, that shortcut would not fit cleanly into either of my
proposed commit-working-tree-content nor commit-index-content. That
would still require a two-stage:
git update-index resolved-path.c
git commit-index-content
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git pull and merging.
From: Junio C Hamano @ 2006-12-06 5:02 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: git
In-Reply-To: <cc723f590612052051r62111c4cgfd7ee893cb00f84a@mail.gmail.com>
"Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
> I have a git.git clone using --use-separate-remote. That means i have
> the master branch created by default. Now i need to build git from the
> pu branch too. So i created git branch pu remotes/origin/pu.
>
>
> How how do i track the pu branch using git pull. What i mean is the
> master local branch is tracked by default using git pull. Is there a
> way to track the local pu branch too.
$ cat >.git/remotes/origin <<\EOF
URL: ...kernel.org/pub/scm/git/git.git
Pull: refs/heads/master:refs/remotes/origin/master
Pull: refs/heads/next:refs/remotes/origin/next
Pull: +refs/heads/pu:refs/remotes/origin/pu
EOF
Then you would checkout 'pu' by having a matching local branch:
$ git branch pu remotes/origin/pu
$ git checkout pu ;# this is your refs/heads/pu
$ make
Hacking on it can be done in this branch as usual. When you are
interested in the latest 'pu' from me:
$ git checkout pu ;# this is your refs/heads/pu
$ git fetch ;# most of the time git pull would also be fine...
and then:
$ git rebase remotes/origin/pu
The 'rebase' in the last step is because my 'pu' rewinds freely;
otherwise you would do "git merge remotes/origin/pu" instead.
^ permalink raw reply
* Re: git pull and merging.
From: Aneesh Kumar @ 2006-12-06 5:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodqhaa7o.fsf@assigned-by-dhcp.cox.net>
On 12/6/06, Junio C Hamano <junkio@cox.net> wrote:
> "Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
>
> > I have a git.git clone using --use-separate-remote. That means i have
> > the master branch created by default. Now i need to build git from the
> > pu branch too. So i created git branch pu remotes/origin/pu.
> >
> >
> > How how do i track the pu branch using git pull. What i mean is the
> > master local branch is tracked by default using git pull. Is there a
> > way to track the local pu branch too.
>
> $ cat >.git/remotes/origin <<\EOF
> URL: ...kernel.org/pub/scm/git/git.git
> Pull: refs/heads/master:refs/remotes/origin/master
> Pull: refs/heads/next:refs/remotes/origin/next
> Pull: +refs/heads/pu:refs/remotes/origin/pu
> EOF
>
> Then you would checkout 'pu' by having a matching local branch:
>
> $ git branch pu remotes/origin/pu
> $ git checkout pu ;# this is your refs/heads/pu
> $ make
>
> Hacking on it can be done in this branch as usual. When you are
> interested in the latest 'pu' from me:
>
> $ git checkout pu ;# this is your refs/heads/pu
> $ git fetch ;# most of the time git pull would also be fine...
>
> and then:
>
> $ git rebase remotes/origin/pu
>
> The 'rebase' in the last step is because my 'pu' rewinds freely;
> otherwise you would do "git merge remotes/origin/pu" instead.
>
Okey what i was looking for was a .git/config that will imply as a
part of git pull origin that local
master is to track remotes/origin/master
pu should track remotes/origin/pu.
I almost felt the branch.<name>.merge was for that.
What is this git-repo-config used for. I am trying to understand
branch.<name>.remote and branch.<name>.merge usage.
^ permalink raw reply
* how to revert changes in working tree?
From: Liu Yubao @ 2006-12-06 6:49 UTC (permalink / raw)
To: git
I'm confused how to revert changes in working tree:
$ git fetch
$ git merge "sync with origin" HEAD origin
....conflict....
$ git branch
* master
origin
$ git status
# .....: needs update
# .....: needs update
(In fact I never modified anything in this tree, and "git diff"
showed many difference indeed, very strange).
I tried "git update-index --refresh", "git reset --hard",
"git reset --hard master", "git checkout master",
"git checkout -f master", but "git status" still said same
as above.
At last, I deleted all files that were reported to be updated
with "rm -rf", ran "git checkout master" and "git status", then
git reported:
# deleted: ....
# deleted: ....
^ permalink raw reply
* Re: git newbie problems
From: Graham Percival @ 2006-12-06 8:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el5608$952$2@sea.gmane.org>
Jakub Narebski wrote:
> Graham Percival wrote:
>
>> flailed around looking for magic commands to make things work. By "make
>> things work", I mean imitating my work style with cvs:
>
> Perhaps it would be better to at least read cvs-migration.txt
> http://kernel.org/pub/software/scm/git/docs/cvs-migration.html
> and all tutorials.
I skimmed through the cvs-migration, the tutorial (part 1 and 2), and
the "everyday git". I didn't notice any "how to deal with merges
problems"... it was unfortunate that the merge problems arose the very
first time I tried to upload my changes. If I had used git for a few
days before it happened, I would have had more confidence to track down
the problem (or email for help earlier!).
> There are some commands which CVS didn't have, and which are very useful
> with git: I'm talking here about "git show" (show latest change), "git
> log" (show kind of changelog), and gitk (graphical history viewer) or qgit
> (alternate graphical history viewer in Qt).
Yes, I don't doubt that git has many improvements -- the main developers
of my project must have had some reason for moving away from cvs! I'm
speaking as a new user who wants to get very simple work done. All I
wanted to do was to fix a few typos in the lilypond documentation; the
information about importing cvs projects or changing branches obscured
the stuff I really wanted.
> Yes, the git error messages certainly needs to be made more user-friendly.
> What git says here that one version has '.gitignore' file handled by version
> control, and second has it outside version control. At least I think what
> it does. "git ls-files --unmerged" or "git diff --merge --summary" should
> show 'true conflicts'.
Thanks for the suggestions!
> By the way, which version of git do you use? I think this particular check
> (if it is the case of this error) was relaxed.
git version 1.4.4.1
I installed it via fink/unstable on OSX.
Cheers,
^ permalink raw reply
* Re: how to revert changes in working tree?
From: Alex Riesen @ 2006-12-06 8:43 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <4576680B.7030500@gmail.com>
On 12/6/06, Liu Yubao <yubao.liu@gmail.com> wrote:
> I'm confused how to revert changes in working tree:
>
> $ git fetch
> $ git merge "sync with origin" HEAD origin
> ....conflict....
You may want to consider git pull. It'd do exactly the same
> $ git branch
> * master
> origin
>
> $ git status
> # .....: needs update
> # .....: needs update
> (In fact I never modified anything in this tree, and "git diff"
> showed many difference indeed, very strange).
That's windows and cygwin for you. They work together
and may someday even figure how to commit the changes.
They problem is the exec-bit which windows does not
have and cygwin failed to correctly workaround the
limitation.
Do a "git repo-config core.filemode false" to almost
disable the checks for exec bit.
> I tried "git update-index --refresh", "git reset --hard",
> "git reset --hard master", "git checkout master",
> "git checkout -f master", but "git status" still said same
> as above.
After git update-index --refresh you shouldn't have had
the diffs (unless you actually had textual changes).
> At last, I deleted all files that were reported to be updated
> with "rm -rf", ran "git checkout master" and "git status", then
> git reported:
> # deleted: ....
> # deleted: ....
Now do a git reset --hard and you should be set,
unless you're unlucky enough to work on FAT,
where probably nothing will save you.
And avoid using any "special" characters (8bit, utf/unicode)
in filenames, while you're on windows: you'll never be able
to share the repository (unless others agree to use your
^ permalink raw reply
* Re: git pull and merging.
From: Johannes Schindelin @ 2006-12-06 9:26 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Junio C Hamano, git
In-Reply-To: <cc723f590612052121u1f6e3c9lc7329f40ee1c9e5a@mail.gmail.com>
Hi,
On Wed, 6 Dec 2006, Aneesh Kumar wrote:
> On 12/6/06, Junio C Hamano <junkio@cox.net> wrote:
>
> > $ cat >.git/remotes/origin <<\EOF
> > URL: ...kernel.org/pub/scm/git/git.git
> > Pull: refs/heads/master:refs/remotes/origin/master
> > Pull: refs/heads/next:refs/remotes/origin/next
> > Pull: +refs/heads/pu:refs/remotes/origin/pu
> > EOF
>
> Okey what i was looking for was a .git/config that will imply as a
> part of git pull origin that local
>
> master is to track remotes/origin/master
> pu should track remotes/origin/pu.
You can have the same effect as what Junio wrote with the config:
$ git repo-config remote.origin.url git://git.kernel.org/pub/scm/git/git.git
$ git repo-config remote.origin.fetch \
refs/heads/master:refs/remotes/origin/master
$ git repo-config remote.origin.fetch \
refs/heads/next:refs/remotes/origin/next ^$
$ git repo-config remote.origin.fetch \
+refs/heads/pu:refs/remotes/origin/pu ^$
But if you clone with recent git, that will already be set up for you
(well, except that the "+" is missing in front of the "pu" thing, which
says that it is okay if that particular ref is not fast-forwarding).
> I almost felt the branch.<name>.merge was for that.
No. This tells git which _default_ branch to merge with. I.e.
$ git repo-config branch.master.remote origin
$ git repo-config branch.master.merge next
means that if your current branch is "master", a "git pull" _without_
parameters will default to the branch "next" of the remote "origin" you
just set up like above.
Hth,
Dscho
^ permalink raw reply
* Re: git pull and merging.
From: Jakub Narebski @ 2006-12-06 9:31 UTC (permalink / raw)
To: git
In-Reply-To: <cc723f590612052121u1f6e3c9lc7329f40ee1c9e5a@mail.gmail.com>
Aneesh Kumar wrote:
> On 12/6/06, Junio C Hamano <junkio@cox.net> wrote:
>> "Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
>>
>>> I have a git.git clone using --use-separate-remote. That means i have
>>> the master branch created by default. Now i need to build git from the
>>> pu branch too. So i created git branch pu remotes/origin/pu.
>>>
>>>
>>> How how do i track the pu branch using git pull. What i mean is the
>>> master local branch is tracked by default using git pull. Is there a
>>> way to track the local pu branch too.
>>
>> $ cat>.git/remotes/origin <<\EOF
>> URL: ...kernel.org/pub/scm/git/git.git
>> Pull: refs/heads/master:refs/remotes/origin/master
>> Pull: refs/heads/next:refs/remotes/origin/next
>> Pull: +refs/heads/pu:refs/remotes/origin/pu
>> EOF
Or you can do .git/config equivalent:
$ git repo-config remote.origin.url ...kernel.org/pub/scm/git/git.git
$ git repo-config remote.origin.fetch refs/heads/master:refs/remotes/origin/master
$ git repo-config remote.origin.fetch refs/heads/next:refs/remotes/origin/next
$ git repo-config remote.origin.fetch +refs/heads/pu:refs/remotes/origin/pu
>> Then you would checkout 'pu' by having a matching local branch:
>>
>> $ git branch pu remotes/origin/pu
>> $ git checkout pu ;# this is your refs/heads/pu
>> $ make
>>
>> Hacking on it can be done in this branch as usual. When you are
>> interested in the latest 'pu' from me:
>>
>> $ git checkout pu ;# this is your refs/heads/pu
>> $ git fetch ;# most of the time git pull would also be fine...
>>
>> and then:
>>
>> $ git rebase remotes/origin/pu
>>
>> The 'rebase' in the last step is because my 'pu' rewinds freely;
>> otherwise you would do "git merge remotes/origin/pu" instead.
>>
>
> Okey what i was looking for was a .git/config that will imply as a
> part of git pull origin that local
>
> master is to track remotes/origin/master
> pu should track remotes/origin/pu.
>
> I almost felt the branch.<name>.merge was for that.
>
> What is this git-repo-config used for. I am trying to understand
>
> branch.<name>.remote and branch.<name>.merge usage.
Yes it is what branch.<name>.merge is for... and it would work for
any branch _except_ pu, which rewinds frequently, and you should
rebase your changes on top of current version instead of merging.
Still it is useful to add branch.<branch>.remote for pu:
$ git repo-config branch.refs/heads/pu.remote origin
so you can do just "git fetch" on pu to fetch from origin (well,
"git fetch" would fetch from origin as it is the default even in
absence of branch.<branch>.remote).
If it were any other branch, for example next, you could add
$ git repo-config branch.refs/heads/next.remote origin
$ git repo-config branch.refs/heads/next.merge refs/remotes/origin/next
for "git pull" on next branch fo fetch from origin and merge
next branch from origin.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git newbie problems
From: Han-Wen Nienhuys @ 2006-12-06 9:39 UTC (permalink / raw)
To: git
In-Reply-To: <el55to$952$1@sea.gmane.org>
Jakub Narebski escreveu:
>> 84219bb don't have input/templates/ any longer.
>> fatal: Entry '.gitignore' would be overwritten by merge. Cannot merge.
>> No merge strategy handled the merge.
>>
>> As a git newbie, I'm quite confused. OK, there's no merge strategy...
>> so what do I do now? With cvs, the changes would be dumped into the
>> file. I look at the file, found the conflict, and tried it again. I
>> got the same error message, and then it occurred to me that although I
>> changed the files in my ~/usr/src/lilypond, git might be storing these
>> files somewhere else.
>
> Yes, the git error messages certainly needs to be made more user-friendly.
> What git says here that one version has '.gitignore' file handled by version
> control, and second has it outside version control. At least I think what
> it does.
Which is actually not true. .gitignore has been in the repo since we
started using git. I have also seen this message pop up a few times
in the beginning, but I can't recall why they happened.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: using xdl_merge(), was Re: Resolving conflicts
From: Junio C Hamano @ 2006-12-06 9:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Ramsay Jones, git
In-Reply-To: <7vac22glzz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Tue, 5 Dec 2006, Linus Torvalds wrote:
>>
>>> - take every single merge in git (or the kernel, if you want even more)
>
> The attached is the script I am using. The test checks the
> output from 'master' (merge from RCS) and 'next' (with xdl-merge)
> and also tries to see how different the conflicts look like.
>
> In the git.git archive, there is no "clean" merge on which
> 'master' and 'next' did not agree. It is not a proof of
> correctness at all but it gives a sense of assurance.
And all merges in linux-2.6.git archive either result in
conflict with both 'merge' implementations, or cleanly resolves
the same way with both 'merge' implementations. I have not
compared the conflicted cases yet, but at least it gives me a
warm fuzzy feeling to see that autocommitted stuff are sensible.
^ permalink raw reply
* Commit order in git.git, was Re: [RFC] Two conceptually distinct commit commands
From: Johannes Schindelin @ 2006-12-06 9:54 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, git
In-Reply-To: <874ps91v79.wl%cworth@cworth.org>
Hi,
On Tue, 5 Dec 2006, Carl Worth wrote:
> On Tue, 05 Dec 2006 17:13:20 -0800, Junio C Hamano wrote:
> > (This is offtopic)
>
> It's an interesting topic nonetheless, so I'll comment anyway.
>
> > (1) one commit exposes, then another fixes.
> > (2) one commit fixes, then another verifies the bug is no more.
> > (3) one commit to include both.
>
> I feel very strongly that I want (1) in the history.
Note that (1) maybe would reflect history better, but (2) and (3) are way
nicer to bisecting.
I fell very strongly that I want (3) in the history.
(Though I am guilty of many instances of (2)...)
Ciao,
Dscho
^ permalink raw reply
* Re: git patch
From: Han-Wen Nienhuys @ 2006-12-06 9:55 UTC (permalink / raw)
To: git; +Cc: lily-devel
In-Reply-To: <Pine.LNX.4.63.0612060157020.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin escreveu:
> The nice thing for me about Git: you never lose anything. Unless you say
> "git prune" (in which case you really should know what you are doing), you
> do not lose (committed) data.
>
> Now, I promised to tell you what to do if all the files seem modified. Did
> you look through "git -p diff"? (BTW with recent Git you only need "git
> diff" and it will pipe the result into your pager automatically.)
This actually bothers me as well from a UI point of view. Git-diff is
used both for generating diffs between versions that come from git and
the working tree/index.
I think it would be more logical to show those diffs as part of
git-status and perhaps git-commit, eg.
git-commit --dry-run <commitoptions>
shows the diff of what would be committed
git-status --diff
shows diffs of modified files in the working tree.
This makes it more clear what each diff means.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: git pull and merging.
From: Johannes Schindelin @ 2006-12-06 9:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el62hi$esu$1@sea.gmane.org>
Hi,
On Wed, 6 Dec 2006, Jakub Narebski wrote:
> $ git repo-config remote.origin.fetch refs/heads/master:refs/remotes/origin/master
> $ git repo-config remote.origin.fetch refs/heads/next:refs/remotes/origin/next
Oops. You want to append "^$" at the end (otherwise the "master" entry is
overwritten; remote.origin.fetch is a multivalued key). Same for "pu".
Ciao,
^ permalink raw reply
* Re: how to revert changes in working tree?
From: Liu Yubao @ 2006-12-06 9:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0612060043t488d356du8f5fcdd164a45eb5@mail.gmail.com>
Alex Riesen wrote:
> On 12/6/06, Liu Yubao <yubao.liu@gmail.com> wrote:
>> I'm confused how to revert changes in working tree:
>>
>> $ git fetch
>> $ git merge "sync with origin" HEAD origin
>> ....conflict....
>
> You may want to consider git pull. It'd do exactly the same
It's said somewhere "git pull" has strange behaviour and fetch+pull
is recommended.
>
>> $ git branch
>> * master
>> origin
>>
>> $ git status
>> # .....: needs update
>> # .....: needs update
sorry, I made a mistake, that should come from "git merge",
here is the message from "git status":
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# modified: include/linux/netfilter/xt_CONNMARK.h
# modified: include/linux/netfilter/xt_DSCP.h
# modified: include/linux/netfilter/xt_MARK.h
# modified: include/linux/netfilter_ipv4/ipt_CONNMARK.h
# modified: include/linux/netfilter_ipv4/ipt_DSCP.h
# modified: include/linux/netfilter_ipv4/ipt_ECN.h
# modified: include/linux/netfilter_ipv4/ipt_MARK.h
# modified: include/linux/netfilter_ipv4/ipt_TCPMSS.h
# modified: include/linux/netfilter_ipv4/ipt_TOS.h
# modified: include/linux/netfilter_ipv4/ipt_TTL.h
# modified: include/linux/netfilter_ipv6/ip6t_HL.h
# modified: include/linux/netfilter_ipv6/ip6t_MARK.h
# modified: net/ipv4/netfilter/ipt_ECN.c
# modified: net/ipv4/netfilter/ipt_TOS.c
# modified: net/ipv4/netfilter/ipt_TTL.c
# modified: net/ipv6/netfilter/ip6t_HL.c
# modified: net/netfilter/xt_CONNMARK.c
# modified: net/netfilter/xt_DSCP.c
# modified: net/netfilter/xt_MARK.c
#
nothing to commit
>> (In fact I never modified anything in this tree, and "git diff"
>> showed many difference indeed, very strange).
>
> That's windows and cygwin for you. They work together
> and may someday even figure how to commit the changes.
Yes, I am using cygwin :-(
>
> They problem is the exec-bit which windows does not
> have and cygwin failed to correctly workaround the
> limitation.
>
> Do a "git repo-config core.filemode false" to almost
> disable the checks for exec bit.
>
It has been set. I guess the cause is a interrupted merge
operation that leads to textual difference.
>> I tried "git update-index --refresh", "git reset --hard",
>> "git reset --hard master", "git checkout master",
>> "git checkout -f master", but "git status" still said same
>> as above.
>
> After git update-index --refresh you shouldn't have had
> the diffs (unless you actually had textual changes).
>
>> At last, I deleted all files that were reported to be updated
>> with "rm -rf", ran "git checkout master" and "git status", then
>> git reported:
>> # deleted: ....
>> # deleted: ....
>
> Now do a git reset --hard and you should be set,
> unless you're unlucky enough to work on FAT,
> where probably nothing will save you.
>
After run "git reset --hard", all deleted files come back, but I reach
the old state:
$ git status
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# modified: include/linux/netfilter/xt_CONNMARK.h
# modified: include/linux/netfilter/xt_DSCP.h
...
# modified: net/netfilter/xt_MARK.c
#
nothing to commit
> And avoid using any "special" characters (8bit, utf/unicode)
> in filenames, while you're on windows: you'll never be able
> to share the repository (unless others agree to use your
> rules for language and filesystem encoding).
>
In fact, I'm operating the linux-2.6 tree, so no special characters.
HEAD: commit 088406bcf66d6c7fd8a5c04c00aa410ae9077403
master: commit 088406bcf66d6c7fd8a5c04c00aa410ae9077403
origin: commit ff51a98799931256b555446b2f5675db08de6229
"git diff --cached" shows nothing;
"git diff" shows many diffs:
diff --git a/include/linux/netfilter/xt_CONNMARK.h b/include/linux/netfilter/xt_CONNMARK.h
index 9f74468..c592f6a 100644
--- a/include/linux/netfilter/xt_CONNMARK.h
+++ b/include/linux/netfilter/xt_CONNMARK.h
@@ -1,5 +1,5 @@
-#ifndef _XT_CONNMARK_H_target
-#define _XT_CONNMARK_H_target
+#ifndef _XT_CONNMARK_H
+#define _XT_CONNMARK_H
/* Copyright (C) 2002,2004 MARA Systems AB <http://www.marasystems.com>
* by Henrik Nordstrom <hno@marasystems.com>
@@ -10,16 +10,9 @@
* (at your option) any later version.
*/
-enum {
- XT_CONNMARK_SET = 0,
- XT_CONNMARK_SAVE,
- XT_CONNMARK_RESTORE
+struct xt_connmark_info {
+ unsigned long mark, mask;
+ u_int8_t invert;
};
.....
^ permalink raw reply related
* Re: git pull and merging.
From: Peter Baumann @ 2006-12-06 10:00 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612061019350.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On 2006-12-06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> You can have the same effect as what Junio wrote with the config:
>
> $ git repo-config remote.origin.url git://git.kernel.org/pub/scm/git/git.git
> $ git repo-config remote.origin.fetch \
> refs/heads/master:refs/remotes/origin/master
> $ git repo-config remote.origin.fetch \
> refs/heads/next:refs/remotes/origin/next ^$
> $ git repo-config remote.origin.fetch \
> +refs/heads/pu:refs/remotes/origin/pu ^$
>
What's that ^$ for?
-Peter
^ permalink raw reply
* Re: using xdl_merge(), was Re: Resolving conflicts
From: Johannes Schindelin @ 2006-12-06 10:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Ramsay Jones, git
In-Reply-To: <7vwt5573sy.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 6 Dec 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> On Tue, 5 Dec 2006, Linus Torvalds wrote:
> >>
> >>> - take every single merge in git (or the kernel, if you want even more)
> >
> > The attached is the script I am using. The test checks the
> > output from 'master' (merge from RCS) and 'next' (with xdl-merge)
> > and also tries to see how different the conflicts look like.
> >
> > In the git.git archive, there is no "clean" merge on which
> > 'master' and 'next' did not agree. It is not a proof of
> > correctness at all but it gives a sense of assurance.
>
> And all merges in linux-2.6.git archive either result in
> conflict with both 'merge' implementations, or cleanly resolves
> the same way with both 'merge' implementations. I have not
> compared the conflicted cases yet, but at least it gives me a
> warm fuzzy feeling to see that autocommitted stuff are sensible.
Thank you! Slowly I also get a warm fuzzy feeling...
My idea, to have an inbuilt work-alike to RCS merge, was not only
instigated by my liking the zealous option, but also to be able to add
relatively fast tests.
Originally, I thought that building in git-merge-one-file, and enhancing
it to recognize by the parameters if it should act as a merge replacement,
would be the way to go. Should I do this, or rather add
builtin-merge-file?
Ciao,
Dscho
^ permalink raw reply
* Re: git patch
From: Junio C Hamano @ 2006-12-06 10:00 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <4576937D.1070402@xs4all.nl>
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> I think it would be more logical to show those diffs as part of
> git-status and perhaps git-commit, eg.
>
> git-commit --dry-run <commitoptions>
>
> shows the diff of what would be committed
>
> git-status --diff
>
> shows diffs of modified files in the working tree.
>
> This makes it more clear what each diff means.
Just in case people did not know, "git status" is pronounced as
"git commit --dry-run".
It takes exactly the same set of parameters as "git commit", and
shows what would have been in the commit log message editor as
the status comments.
And it even takes the "-v" option that "git commit" takes.
^ permalink raw reply
* Re: git pull and merging.
From: Aneesh Kumar @ 2006-12-06 10:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612061019350.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On 12/6/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > I almost felt the branch.<name>.merge was for that.
>
> No. This tells git which _default_ branch to merge with. I.e.
>
> $ git repo-config branch.master.remote origin
> $ git repo-config branch.master.merge next
>
> means that if your current branch is "master", a "git pull" _without_
> parameters will default to the branch "next" of the remote "origin" you
> just set up like above.
This doesn't work. So this is what i tried
test repository with master and devel branch
cloned it to test.devel
.git/config have
[branch "devel"]
remote = origin
merge = devel
Now IIUC this should be when i am in branch devel when i do a git pull
pull from origin remote and merge with the local branch devel the
remote branch devel.
But git pull says already up to date.
Now i thought merge should be local reference. So i changed it to
merge = remotes/origin/devel.
That also didn't work.
Then i tried the name of the branch should be indicated as
"refs/heads/devel" . That also didn't work.
So i guess i am missing something.
^ permalink raw reply
* Re: Diffs from CVS keyword expansion
From: Uwe Kleine-Koenig @ 2006-12-06 10:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Randal L. Schwartz, Jon Smirl, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0612052048230.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Johannes Schindelin wrote:
> On Tue, 5 Dec 2006, Randal L. Schwartz wrote:
>
> > >>>>> "Uwe" == Uwe Kleine-Koenig <zeisberg@informatik.uni-freiburg.de> writes:
> >
> > Uwe> #! /bin/sh
> > Uwe> exec perl -i -p -e 's/\$(Id|Revision):.*?\$/\$$1: \$/' "$@";
> >
> > Ow. My eyes hurt from that. How about we rewrite that as a native Perl
> > script:
I don't like that either, just because it's Perl :-)
> > #!/usr/bin/perl
> > $^I = ""; # this is -i
> > while (<>) {
> > s/\$(Id|Revision):.*?\$/\$$1: \$/;
> > print;
> > }
>
> Hey, that's better! All of a sudden, I understand everything!
I'm not fluent in Perl, and didn't know $^I. Actually, that's better,
yes. (And my script is already rewritten.)
One thing I don't like about both scripts is, that the timestamp of
a file changes with that, even if there are no changes. Anyone knows
another predefined variable/trick that doesn't hurt performance (and
readability) too much?
timtowtdi
Uwe
--
Uwe Kleine-Koenig
^ 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