* Re: Stupid quoting...
From: Johannes Schindelin @ 2007-06-14 1:12 UTC (permalink / raw)
To: Steven Grimm; +Cc: David Kastrup, git
In-Reply-To: <4670948B.7070407@midwinter.com>
Hi,
On Wed, 13 Jun 2007, Steven Grimm wrote:
> Johannes Schindelin wrote:
> > The recommended way is not using spaces to begin with. I mean, does "David"
> > contain spaces? People seem not to see the problem, and fail to blame
> > Microsoft for all the damage they have done, introducing that stupid,
> > stupid concept of filenames containing spaces, and _enforcing_ it.
> >
>
> To be fair, Microsoft did not invent the concept of filenames with spaces.
I didn't say that, did I?
They _forced_ the use onto the world. That's what I was complaining about.
> Even UNIX has, I believe, always allowed them, though you risked running
> into buggy scripts misbehaving if you used them. And really, filenames
> with spaces are only a nuisance in a text-based command line scripting
> environment, and only then because someone early on decided to use space
> rather than some other metacharacter as the only available delimiter
> between command arguments in scripts.
Okay, Steven Grimm. How do you think _I_ can tell that Steven is your name
from looking at your _full_ name "Steven Grimm"? Huh?
Exactly. I split at the space.
Ciao,
Dscho
^ permalink raw reply
* Re: tags and patches
From: Johannes Schindelin @ 2007-06-14 1:03 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0706131715oa84eff7kc0b477a3b80e9d66@mail.gmail.com>
Hi,
On Thu, 14 Jun 2007, Geoff Russell wrote:
> On 6/13/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Wed, 13 Jun 2007, Geoff Russell wrote:
> >
> > > Dear gits,
> >
> > ;-)
> >
> > > [...]
> > >
> > > git tag v1.1
> > > git format-patch v1.0
> > > cd /tmp/newmyrepo
> > > git am ~/myrepo/THEPATCHNAME
> > >
> > > Where is tag v1.1 ?
> >
> > Tags are not propagated with patches. Sorry.
>
> Is this considered to be a bug to be eventually fixed or a feature?
AFAIK patches are not supposed to _contain_ patches.
What you want is probably a bundle. You don't want a collection of diffs
with comments on them, but you want a collection to reacreate the history
the other side has.
Ciao,
Dscho
^ permalink raw reply
* Re: Stupid quoting...
From: Steven Grimm @ 2007-06-14 1:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Kastrup, git
In-Reply-To: <Pine.LNX.4.64.0706131316390.4059@racer.site>
Johannes Schindelin wrote:
> The recommended way is not using spaces to begin with. I mean, does
> "David" contain spaces? People seem not to see the problem, and fail to
> blame Microsoft for all the damage they have done, introducing that
> stupid, stupid concept of filenames containing spaces, and _enforcing_ it.
>
To be fair, Microsoft did not invent the concept of filenames with
spaces. Even UNIX has, I believe, always allowed them, though you risked
running into buggy scripts misbehaving if you used them. And really,
filenames with spaces are only a nuisance in a text-based command line
scripting environment, and only then because someone early on decided to
use space rather than some other metacharacter as the only available
delimiter between command arguments in scripts.
For regular users who aren't writing shell scripts, long-form filenames
mean a document's name is the same as its title, which is hugely helpful
from a user interface point of view: "February Marketing Budget" is much
more self-documenting as a filename than "febmkbgt" or whatever they
would have had to choose in the old days (and remember, UNIX had a
14-character filename size limit in the early days; long filenames
weren't introduced until BSD.)
I view filenames as primarily for human consumption, so they should act
the way humans expect names to act. Computers can just use inode numbers
or file IDs to refer to files (like, say, SHA1 hashes) -- the pretty
names are all for the benefit of us meat-brained entities.
Then again, that means I also think case sensitivity in filenames was a
bad design choice. To use your "people's names" analogy, if you ask any
random person whether "Billy-bob Thornton" and "Billy-Bob Thornton" are
the same name, they'll almost always say yes; most people don't consider
capital letters and lower-case letters to be different letters, just
different forms of the same letters. And I know how popular *that*
opinion is around here...
-Steve
^ permalink raw reply
* Re: Stupid quoting...
From: Johannes Schindelin @ 2007-06-14 0:51 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86ejkgvxmb.fsf@lola.quinscape.zz>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3113 bytes --]
Hi,
[somehow I got the impression your mail did not make it to the list]
On Wed, 13 Jun 2007, David Kastrup wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 13 Jun 2007, David Kastrup wrote:
> >
> >> what is the point in quoting file names and their characters in
> >> git-diff's output? And what is the recommended way of undoing the
> >> damage?
> >
> > The recommended way is not using spaces to begin with.
>
> Who is talking about spaces?
That is the common reason for quoting. I mean, really, how many files do
you have which contain newlines or backslashes or tabs? Huh?
> > I mean, does "David" contain spaces?
>
> "Günter" contains non-ASCII characters.
And "Guenther" (sorry, have problems with my mailer, so I simulate it in
plain ASCII" does not need quotes, _even_ if containing non-ASCII
characters.
So what exactly was your point again?
> > People seem not to see the problem, and fail to blame Microsoft for
> > all the damage they have done, introducing that stupid, stupid concept
> > of filenames containing spaces, and _enforcing_ it.
>
> The concept of UNIX file names is _any_ byte sequence not containing "/"
> or an ASCII NUL. Microsoft actually prohibits quite a few more
> characters. Filenames with spaces first came into serious use under
> MacOS, the first graphical user interface where no shell and
> metacharacters interfered with the choice of file names.
>
> Blaming Microsoft here is completely ridiculous.
It is completely unridiculous. Before Microsoft -- in its infinite wisdom
-- decided to create folders like "Program Files", and "Documents and
Settings", and made it the _default_ (of all things) to save its
ridiculous Word documents as "New Document", _nobody_ on this planet even
_thought_ about including stupid whitespace in a filename.
You can tell that this is true by looking at now-ancient Unix scripts.
> >> I have something like
> >>
> >> git-diff -M -C --name-status -r master^ master | {
> >> while read -r flag name
> >> do
> >> case "$name" in *\\[0-3][0-7][0-7]*)
> >> name=$(echo -e $(echo "$name"|sed 's/\\\([0-3][0-7][0-7]\)/\\0\1/g;s/\\\([^0]\)/\\\\\1/g'))
> >> esac
> >> [...]
> >>
> >> in order to get through the worst with utf-8 file names, and it is a
> >> complete nuisance (double quotemarks are treated later).
> >
> > Please understand that the quotes are not there for you, but for
> > processing by other programs.
> >
> > However, I _suspect_ that you want to do something like
> >
> > name="$(echo $name)"
> >
> > because "echo" is exactly one of the programs this quoting was invented
> > for.
>
> Only that it does not work with echo. echo requires \0NNN for octal
> escapes, not \NNN, and then only when "echo -e" is used.
Um. How does that apply here? Git only does quoting so that programs like
echo get it right, when passed the name? No funny \0NNN or \NNN or
whatever?
> You are really haphazard in distributing your blame.
>
> Can you actually name a program that would work with the default
> output of git here?
echo.
Ciao,
Dscho
^ permalink raw reply
* Re: tags and patches
From: Geoff Russell @ 2007-06-14 0:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706131313550.4059@racer.site>
On 6/13/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 13 Jun 2007, Geoff Russell wrote:
>
> > Dear gits,
>
> ;-)
>
> > [...]
> >
> > git tag v1.1
> > git format-patch v1.0
> > cd /tmp/newmyrepo
> > git am ~/myrepo/THEPATCHNAME
> >
> > Where is tag v1.1 ?
>
> Tags are not propagated with patches. Sorry.
Is this considered to be a bug to be eventually fixed or a feature?
Geoff
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: pull into dirty working tree
From: Johannes Schindelin @ 2007-06-13 23:32 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Bill Lear, Michael Dressel, git
In-Reply-To: <200706132217.57075.robin.rosenberg.lists@dewire.com>
Ho,
On Wed, 13 Jun 2007, Robin Rosenberg wrote:
> A typical case I recognize is a few printfs or disabling a feature that
> makes it harder to debug with no intentions whatsoever to commit them.
> What we see when the tools more or less forces people to "temporarily"
> commit stuff is that that stuff is often left there. "Oh, I forgot".
> Gah.
>
> Git has this ability when checking out, so why not on pull or merge?
You should hold your breath for git-stash. Now that Junio declared he'd
work on it.
> With stacked git I typically create a new patch, then I can push it
> whenever I want to have some more tracing.
My evil plan is to work git-stash into sort of a lightweight StGit. I
never liked that dependency to Python, and I always felt that it must be
simpler than that.
Ciao,
Dscho
^ permalink raw reply
* [BUG] "git checkout branch" on full disk doesn't recover from errors
From: Jakub Narebski @ 2007-06-13 23:33 UTC (permalink / raw)
To: git
I have accidentally (errorneous program running in parallel) run
"git checkout gitweb/web" (where 'gitweb/web' is a branch) on a full
disk. Git correctly notices error, but doesn't recover fully from it.
$ git checkout gitweb/web
fatal: unable to write new index file
It would be nice if git has shown also the error message from filesystem
(from OS), for example if it was full disk, read-only filesystem (for
example wrong mount options, or running from CD), or incorrect
permissions.
$ <free disk space>
$ git checkout gitweb/web
fatal: Entry '.gitignore' not uptodate. Cannot merge.
The '.gitignore' was last file changed in last commit on the page I was
on (namely 'master'). It looks like git didn't recover fully from
attempted branch change. "git diff" and "git status" shows many
modified files, not only '.gitignore'.
What is a bit strange that mixed reset ("git reset HEAD") is not enough
$ git reset HEAD
<multitude of "needs update" messages>
Fortunately, it is easy to recover using "git reset --hard HEAD",
although beginner user could have some problems with this.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Jakub Narebski @ 2007-06-13 23:20 UTC (permalink / raw)
To: git
In-Reply-To: <7v645thto7.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> Marco Costalba <mcostalba@gmail.com> wrote:
>>> On 6/12/07, Junio C Hamano <gitster@pobox.com> wrote:
>>> >
>>> > (1) Are you emulating CVS-like "a file has an identity, and we
>>> > follow its changes" model? How does it handle file split,
>>> > merge, and code movement in general?
>>> >
>>>
>>> It uses 'git rev-list HEAD -- <path>' to get the list of revisions
>>> that modified a path,
>>
>> So apparently yes, qgit is emulating CVS. And yet much better things
>> exist (git-blame).
>
> I would not use the word "better", as it depends on what you are
> looking for.
[...]
> The way Marco describes is a perfectly valid way to satisfy
> expectations of people migrating from CVS. It's more faithful
> reproduction of CVS annotate behaviour. In a sense, git-blame
> does too much, but that is exactly why these "accurate and
> interesting" behaviours are optional.
Perhaps the qgit annotating would find it's way in core git as git-annotate
(which currently is alias to git-blame + some compatibility options), or
as an option (--bottom-up) to git-blame?
On the other hand side, blaming multiple files in parallel has sense I think
only for graphical viewer, not for command line command.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-svn: allow dcommit to retain local merge information
From: Joakim Tjernlund @ 2007-06-13 23:17 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, Steven Grimm, git
In-Reply-To: <1181754781.30670.323.camel@gentoo-jocke.transmode.se>
On Wed, 2007-06-13 at 19:13 +0200, Joakim Tjernlund wrote:
> On Wed, 2007-06-13 at 02:23 -0700, Eric Wong wrote:
> > dcommit will still rewrite the HEAD commit and the history of the first
> > parents of each HEAD~1, HEAD~2, HEAD~3 as it always has.
> >
> > However, any merge parents (HEAD^2, HEAD^^2, HEAD~2^2) will now be
> > preserved when the new HEAD and HEAD~[0-9]+ commits are rewritten to SVN
> > with dcommit. Commits written to SVN will still not have any merge
> > information besides anything in the commit message.
> >
> > Thanks to Joakim Tjernlund, Junio C Hamano and Steven Grimm
> > for explanations, feedback, examples and test case.
> >
> > Signed-off-by: Eric Wong <normalperson@yhbt.net>
> > ---
> >
> > This is a better patch that replaces the previous one.
> >
> > Junio:
> > This one is a big change and should probably sit in pu or next
> > for a bit. Double-checking the logic in linearize_history()
> > would be greatly appreciated, too.
> >
> > I don't think there are any regressions for the
> > already-linear-history case besides slightly reduced performance for
> > new calls to cat-file.
> >
> > Joakim/Steven:
> > Any further testing and test cases would be appreciated. Be very
> > careful with real-world repositories, and run dcommit with the
> > '-n' flag before actually committing to verify the diffs are sane.
> >
> > Thanks
> >
>
> Did a little testing and so far it looks good :)
>
> Sidenote:
> Doing this
> git-svn init -t tags -T trunk -b branches file:///usr/local/src/tst-git-svn/svn-uboot-repo
> git-svn fetch --quiet
> makes git svn fetch stop for rather long periods in do_update:
> Found possible branch point: file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk => file:///usr/local/src/tst-git-svn/svn-uboot-repo/tags/snap-uboot-1.1.4, 2
> Found branch parent: (tags/snap-uboot-1.1.4) 81eef14963597cc99ba375f52e6d0b3bc09e25f8
> Following parent with do_update
> Successfully followed parent
>
> Is it possible to speed up do_update?
>
>
> Lastly, when adding the above u-boot svn repo into a fresh u-boot clone from WD,
> can I attach the svn tree to git u-boot tree without using a graft?
>
> I want to be able to recreate my own git repo by cloning the orginal u-boot
> repo and the svn repo.
>
> Jocke
Tried using --no-metadata(git svn clone --no-metadata) in my little test
script I sent earlier and got
"Unable to determine upstream SVN information from HEAD history"
when dcommiting, -i trunk didn't help either.
It is not entierly clear to me what --no-metadata means to me.
Does git-svn still rewrite commits?
I can't rebuild rev_db file, if lost, but I guess I could still
do a new git-svn clone and restore my repo? I guess I lose something
if I do that but what?
Also don't really understand why git-svn log doesn't work, can't it get
that info from the svn repo?
Jocke
^ permalink raw reply
* Re: clarify git clone --local --shared --reference
From: Brandon Casey @ 2007-06-13 23:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070608053750.GB18521@spearce.org>
Shawn O. Pearce wrote:
> Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> The docs (git-repack.txt) seem to suggest that git-repack (without -d)
>> does not delete any objects. And if -d is used, then at most objects
>> already referenced in other packs will be deleted. This makes me think
>> that repack is safe on the source repository.
>
> You are correct that leaving off the '-d' won't delete objects.
> But a pack is created by listing the objects we need, and if we don't
> need the object in source, we don't include it into the new pack.
>
> -a -d implies delete all packs that existed when we started the
> repack. So if an object was in the old packfile, and we didn't
> copy it to the new packfile, it gets deleted. ;-)
Ok. There is the connection I did not make. repack -d is NOT harmless,
since a pack that contains only objects referenced in other packs and
dangling unreferenced objects, will be deleted. Which will be all of the
preexisting packs in the case of git-gc since as you mentioned it
repacks using -a -d -l.
Thanks for taking the time.
-brandon
^ permalink raw reply
* Re: git-svn "cannot lock ref" error during fetch
From: James Peach @ 2007-06-13 23:07 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20070609200650.GD32225@muzzle>
On Jun 9, 2007, at 1:06 PM, Eric Wong wrote:
> James Peach <jamespeach@mac.com> wrote:
>> On Jun 6, 2007, at 11:31 PM, Eric Wong wrote:
>>
>>> James Peach <jamespeach@mac.com> wrote:
>>>> Hi all,
>>>>
>>>> I'm new to git, and I'm experimenting with using git-svn to
>>>> interact
>>>> with a large SVN repository with lots of branches.
>>>>
>>>> I initially did an init like this:
>>>>
>>>> git-svn init -t tags -b branches -T trunk svn+ssh://server/svn/
>>>> project
>>>>
>>>> Then I did a git-svn fetch, which started pulling all the branches.
>>>> After a while, however, it hit a branch that it couldn't pull:
>>>>
>>>> Found branch parent: (tags/project-92~9)
>>>> 767f1f1601a4deae459c99ea6c1d1b9ba8f57a65
>>>> Following parent with do_update
>>>> ...
>>>> Successfully followed parent
>>>> fatal: refs/remotes/tags/project-92~9: cannot lock the ref
>>>> update-ref -m r13726 refs/remotes/tags/project-92~9
>>>> 950638ff72acc278156a0d55baafbabb43f2b772: command returned error:
>>>> 128
>>>>
>>>> Some amount of searching failed to turn up any hints on what this
>>>> error means or how I can work around it. I'd appreciate any
>>>> advice ...
>>>
>>> Is there a tag actually named "project-92~9"?
>>
>> unfortunately, there's more than one tag with this naming
>> convention :(
>>
>>> If so, it's
>>> an invalid branch name for git. I started working on a way
>>> around it by mapping new names to it, but haven't gotten around to
>>> finishing it....
>>
>> Aha! I don't really need 90% of the tags - is there a way I can tell
>> the "git-svn fetch" not to bother with particular tags?
>
> You can manually add fetch = foo:bar lines in the [svn-remote "svn"]
> section of your .git/config file. See the one for trunk. Then
> remove the tags= wildcard config line.
that worked really well, thanks a lot!
^ permalink raw reply
* [PATCH] Generated spec file to be ignored is named git.spec and not git-core.spec
From: Jakub Narebski @ 2007-06-13 23:12 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
.gitignore | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index bd49cd4..e8b060c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -157,7 +157,7 @@ common-cmds.h
*.tar.gz
*.dsc
*.deb
-git-core.spec
+git.spec
*.exe
*.[aos]
*.py[co]
--
1.5.2
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-06-13 22:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtztbbnsq.fsf@assigned-by-dhcp.pobox.com>
Hi,
On Wed, 13 Jun 2007, Junio C Hamano wrote:
> * js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits
Isn't that convenient? That's already the second project the two JS'es are
working together...
> * jc/oneline (Mon Jun 11 22:10:55 2007 -0700) 2 commits
> + Extend --pretty=oneline to cover the first paragraph,
> + Lift 16kB limit of log message output
>
> Hoping to be able to merge them to 'master', but haven't
> convinced myself that these changes are correct. Help is
> appreciated.
I haven't had a chance to look at the patch yet, but the intention is
sound.
> * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200)
> - filter-branch: always export GIT_DIR if it is set
> * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
> - make git barf when an alias changes environment variables
> - setup_git_directory: fix segfault if repository is found in cwd
> - test GIT_WORK_TREE
> - extend rev-parse test for --is-inside-work-tree
> - Use new semantics of is_bare/inside_git_dir/inside_work_tree
> - introduce GIT_WORK_TREE to specify the work tree
> - test git rev-parse
> - rev-parse: introduce --is-bare-repository
> - rev-parse: document --is-inside-git-dir
>
> Undecided. Some people would want to have a way to have GIT_DIR
> point at somewhere unusual and still want to work from within a
> subdirectory, which is probably a valid thing to support. This
> is not something I would use myself, so I am mostly worried
> about the impact these changes may have on people who do not use
> this feature.
Yeah, it is something to worry about. As far as I am concerned, these
changes are too deep for too obscure a feature.
But then, I see that people need it.
And I can't think of a better way to implement it. So unless somebody
comes up with a nice solution, I think we should live with it, rather than
let it simmer in pu.
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git (stable)
From: Johannes Schindelin @ 2007-06-13 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5u7d38h.fsf@assigned-by-dhcp.pobox.com>
Hi,
On Wed, 13 Jun 2007, Junio C Hamano wrote:
> I would want to start the 1.5.3-rc cycle, after merging
> at least the submodule Porcelain (Lars) and filter-tree
> (Johannes and Pasky).
Isn't that Johannesses (and filter-branch)? :-)
FWIW I think that there lies a long road in front of us with
filter-branch, after submodule is merged in. I have no preference on what
should go in first, but filter-branch If My Plan Succeeds (TM) will help
transition from huge imports to subprojects.
So, even if I am not _that_ interested in subprojects myself, I _do_ want
to enhance filter-branch. IMHO filter-branch is yet another proof that
cogito -- even if it is now set to die -- was well worth it. Thanks Pasky.
Next plans are: make filter-branch a misnomer: actually be able to rewrite
more than one branch in one go, writing the outcome to the refs/rewritten/
namespace. IIRC that was Hannes' project, but I'll gladly step in there if
need be.
After that, I imagine automatic subprojects disentangling (maybe somewhat
related to Alex' suggestion), so you can say "this big project is actually
a subproject: directories a/, b/ and c/ are self-contained subprojects).
Of course, the nearest future from my POV is to actually implement the
missing tests :-)
Ciao,
Dscho
P.S.: Junio, wherever you are right now, have a nice time. Hopefully not
too stressful.
^ permalink raw reply
* Re: git-p4import.py robustness changes
From: Simon Hausmann @ 2007-06-13 22:34 UTC (permalink / raw)
To: Scott Lamb; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <46705C69.8000500@slamb.org>
[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]
On Wednesday 13 June 2007 23:06:49 Scott Lamb wrote:
> Simon Hausmann wrote:
> > _If_ one of you decides to pull then my plan is to discontinue the git-p4
> > branch in the fast-export repository and instead work in a git.git fork
> > on repo.or.cz (similar to the fastimport repository).
>
> So you'll continue maintain this code and others should submit changes
> through you? What is the best way to do so? (Not sure what it was
> before, or if it would change under this plan.) Email a format-patch To:
> you? Cc: this list? some other list? no list?
I would say whichever you prefer :)
For the fast-export repository multiple people have access and for example
after Han-Wen made a lot of patches I asked Chris Lee (owner of the module on
repo.or.cz) to add Han-Wen to the list of people with push access and he
pushed his changes directly. I actually like working that way for a project
that is as simple as that, I don't mind if somebody pushes simple changes
directly as much as I like discussing bigger plans if they potentially clash
with somebody else's work or use-case.
So if git-p4 continues to live in fast-export I'll continue to encourage Chris
Lee to give git-p4 contributors push access, if it's in a git.git fork I'd be
happy to do so myself (give access).
If git-p4 also ends up in git/contrib/fastimport and somebody likes to send
patches to Junio or somebody else and CC this list that's fine with me, too.
It's just a few lines of python code after all ;-)
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: pull into dirty working tree
From: Alex Riesen @ 2007-06-13 22:27 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Bill Lear, git
In-Reply-To: <86k5u7zf7x.fsf@blue.stonehenge.com>
Randal L. Schwartz, Thu, Jun 14, 2007 00:01:22 +0200:
> In which case, it's even simpler:
>
> git-add . # add *everything* that's not .gitignored
> git-commit -a -m WIP # save for replay (H above)
> git-fetch origin # get upstream (P Q R)
> git-rebase origin # creates E' F' G' H'
> git-reset --soft HEAD^ # back up to G'
> git-reset # mark everything un-added as of G'
>
> Yeah, this is far easier.
>
It is also wrong. You either add a lot of junk (because it is not
ignored yet - who'll setup .gitignores just to check something?!) and
spend a millenium hashing it (ever tried to add 4.7 DVD?) or it does
not add really important files which just happen to be in .gitignore.
IOW, this recipe is dangerous. It'll only _mostly_ work.
^ permalink raw reply
* Re: [PATCH] Interpret :/<pattern> as a regular expression
From: Johannes Schindelin @ 2007-06-13 22:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070613200011.GA17360@coredump.intra.peff.net>
Hi,
On Wed, 13 Jun 2007, Jeff King wrote:
> On Wed, Jun 13, 2007 at 07:54:59PM +0100, Johannes Schindelin wrote:
>
> > :-) Since you seem comfortable with regular expressions, maybe you can
> > help me: I am looking for a pattern which matches _any_ character, and one
> > which matches only non-newlines, both with and without REG_NEWLINE. Hmm?
>
> Without REG_NEWLINE, any character is just '.', but I think you are
> stuck with '[^
> ]' for non-newlines, since POSIX makes no provisions for quoting the
> newline (I just skimmed through POSIX chapter 9, and I didn't see
> anything useful).
>
> With REG_NEWLINE, non-newlines is of course '.'. Matching both is tricky
> without using extended regular expressions (where you could just do '.|
> '). In fact, I have been playing with it for a few minutes and I can't
> seem to find a good way, since you really want to represent '.' _inside_
> a bracketed alternation sequence. But I don't think there's a character
> class for "everything".
>
> I think this would be much easier with pcre, but ISTR some opposition to
> that a few months back.
Actually, that's funny. Yesterday, I repeated my claim that pcre is
slow on IRC, and Sam Villain on IRC accused me of trolling. But as you can
see from my postings on this list ($gmane/41682), you can see that _I_ had
numbers to back up my claim.
So no, I think pcre is just not worth it.
> So that's probably not very helpful to you, but at least you have
> confirmation from one other person that the answer isn't totally
> obvious. :)
That confirmation is at least some consolation to me :-)
Ciao,
Dscho "who is not here to teach, but to learn"
^ permalink raw reply
* Re: pull into dirty working tree
From: Randal L. Schwartz @ 2007-06-13 22:01 UTC (permalink / raw)
To: Alex Riesen; +Cc: Bill Lear, git
In-Reply-To: <20070613213931.GD3412@steel.home>
>>>>> "Alex" == Alex Riesen <raa.lkml@gmail.com> writes:
Alex> You left the process of figuring out what files should be temporarily
Alex> added to the index. _Automatically_. Because that's what you need if
Alex> you want "git pull" to just work. Otherwise it just fails.
I'd just commit *all* of it in my scenerio. There won't be any *other* files.
And because of the final git-reset --soft and git-reset, it won't matter if I
commited more than I'd ever commit on the final hit.
The result of my sequence (I believe) is that my topic commits will appear
rebased on top of the new upstream, and that I'll have a dirty working
directory that represents things as they were, ready for the next commit.
I *lose* the idea of what files were partially added before the last commit,
but I can always reconstruct that by hand, because I should already be
thinking about that before the next commit.
Using those famous trees, if I start with:
A--B--C--D origin
--E--F--G my_topic
--(X) dirty tree
and upstream commits P Q R, the result will be:
A--B--C--D--P--Q--R origin
--E'--F'--G' (E, F, G rebased and merged) my_topic
--(X') dirty tree rebased
This works because I temporarily make H, which follows E, F, G
and then rebase E-F-G-H onto origin,
and then simply "uncommit" H'.
Oops. I see the problem. I don't need the "WIP" tag. I want to uncommit to
G' not to G. Is that what you were referencing?
In which case, it's even simpler:
git-add . # add *everything* that's not .gitignored
git-commit -a -m WIP # save for replay (H above)
git-fetch origin # get upstream (P Q R)
git-rebase origin # creates E' F' G' H'
git-reset --soft HEAD^ # back up to G'
git-reset # mark everything un-added as of G'
Yeah, this is far easier.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* [PATCH] gitmodules(5): remove leading period from synopsis
From: Lars Hjemli @ 2007-06-13 22:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Lederhofer, git
In-Reply-To: <7vd4zzg72i.fsf@assigned-by-dhcp.pobox.com>
Asciidoc treats a line starting with a period followed by a title as a
blocktitle element. My introduction of gitmodules(5) unfortunatly broke
the documentation build process due to this processing, since it made
asciidoc generate an illegal (empty) synopsis element. Removing the leading
period fixes the problem and also makes gitmodules(5) use the same synopsis
notation as gitattributes(5).
Noticed-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Sorry for the breakage, I'll try to get asciidoc working before submitting
any more patches to Documentation/.
Documentation/gitmodules.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 7814b6a..035294e 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -7,7 +7,7 @@ gitmodules - defining submodule properties
SYNOPSIS
--------
-.gitmodules
+gitmodules
DESCRIPTION
--
1.5.2.1.914.gbd3a7
^ permalink raw reply related
* Re: pull into dirty working tree
From: Alex Riesen @ 2007-06-13 21:39 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Bill Lear, git
In-Reply-To: <86odjjziek.fsf@blue.stonehenge.com>
Randal L. Schwartz, Wed, Jun 13, 2007 22:52:35 +0200:
> Alex> No, it wont. What files are you going to add?
>
> Whatever you are working on. Whatever you want tracked. It's a commit.
> I'm not sure why you're having trouble following me. What did I leave out?
You left the process of figuring out what files should be temporarily
added to the index. _Automatically_. Because that's what you need if
you want "git pull" to just work. Otherwise it just fails.
> >> git-rebase *will* do the merge. It must. :)
> Alex> It won't merge anything which isn't known to git.
>
> And that's irrelevant, because my first step *did* a commit so they are
> *known* to git.
It is not enough. It didn't add the "other" files to index, so the
files are _not_ known to git.
Imagine you added a file to Makefile (which was known to git), wrote
the file, put some code in it, played with it. Never called "git add"
on it yet (you were just playing, as original poster suggested).
Now someone from team calls and asks you to tests his changes (and
imagine he added a file with exactly the same name as yours). You do a
pull from his repo and it breaks. With your method it will break too,
"git commit -a" wont add your file to index.
> Alex> Now, I come to think
> Alex> about it, no existing merge method will help you here (and very likely
> Alex> it shouldn't).
>
> Yes, it should. You're merging your changes onto the upstream. This
> happens dozens of times a day with git repos all over the world. :)
Other way around. You merge upstream in your branch. And it conflicts
with work you haven't told git about just yet.
> Alex> It is actually much simplier doing things right: all this stashing
> Alex> people keep talking about.
>
> Yes, and that's what I said too.
>
You (and others) just keep forgetting about this small detail with
"other" files. Junio noticed it too. This "small" detail can make the
whole stashing bussiness impossible except for maybe a common case.
Which is not very helpful for a newbie who meets the uncommon, but his
case. He'll learn his way though, of course. After saying out loud:
"git sucks!"; which what they already do.
^ permalink raw reply
* Re: Mail after commit
From: Jan-Benedict Glaw @ 2007-06-13 21:26 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Claudio Scordino, git
In-Reply-To: <46a038f90706131419i66cf610flac4f3ca040a4355f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]
On Thu, 2007-06-14 09:19:57 +1200, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 6/14/07, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> > On Wed, 2007-06-13 08:35:57 +1200, Martin Langhoff > ><martin.langhoff@gmail.com> wrote:
> > > On 6/13/07, Claudio Scordino <cloud.of.andor@gmail.com> wrote:
> > > > Doesn't exist any way to make it simpler ?
> > >
> > > I think most people setup gitweb, and follow its rss feed. Not exacty
> > > the same, I know, but quite useful.
> >
> > Erm, no, not really. Emailing the patches is *quite* useful when
> > there's a dedicated review team.
>
> I'm sure the review team can read the RSS feed ;-) I've also seen
> RSS-to-IMAP gateways that make it easy to "reply" to the patch from
> your MUA.
Well, why import it to the mail platform via RSS when there's a direct
way:) Almost all interesting patches require review (and commenting),
and we're working with the email client all the day. So it's just
straight forward ;-)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: "really soon now": an unspecified period of time, likly to
the second : be greater than any reasonable definition
of "soon".
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Mail after commit
From: Martin Langhoff @ 2007-06-13 21:19 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Claudio Scordino, git
In-Reply-To: <20070613142516.GE22027@lug-owl.de>
On 6/14/07, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Wed, 2007-06-13 08:35:57 +1200, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > On 6/13/07, Claudio Scordino <cloud.of.andor@gmail.com> wrote:
> > > Doesn't exist any way to make it simpler ?
> >
> > I think most people setup gitweb, and follow its rss feed. Not exacty
> > the same, I know, but quite useful.
>
> Erm, no, not really. Emailing the patches is *quite* useful when
> there's a dedicated review team.
I'm sure the review team can read the RSS feed ;-) I've also seen
RSS-to-IMAP gateways that make it easy to "reply" to the patch from
your MUA.
Not _exactly_ the same, but quite useful.
martin
^ permalink raw reply
* Re: git-p4import.py robustness changes
From: Scott Lamb @ 2007-06-13 21:06 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <200706122347.00696.simon@lst.de>
Simon Hausmann wrote:
> _If_ one of you decides to pull then my plan is to discontinue the git-p4
> branch in the fast-export repository and instead work in a git.git fork on
> repo.or.cz (similar to the fastimport repository).
So you'll continue maintain this code and others should submit changes
through you? What is the best way to do so? (Not sure what it was
before, or if it would change under this plan.) Email a format-patch To:
you? Cc: this list? some other list? no list?
--
Scott Lamb <http://www.slamb.org/>
^ permalink raw reply
* Re: pull into dirty working tree
From: Randal L. Schwartz @ 2007-06-13 20:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: Bill Lear, git
In-Reply-To: <20070613204711.GC3412@steel.home>
>>>>> "Alex" == Alex Riesen <raa.lkml@gmail.com> writes:
Alex> No, it wont. What files are you going to add?
Whatever you are working on. Whatever you want tracked. It's a commit.
I'm not sure why you're having trouble following me. What did I leave out?
>> git-rebase *will* do the merge. It must. :)
Alex> It won't merge anything which isn't known to git.
And that's irrelevant, because my first step *did* a commit so they are
*known* to git.
Alex> Now, I come to think
Alex> about it, no existing merge method will help you here (and very likely
Alex> it shouldn't).
Yes, it should. You're merging your changes onto the upstream. This
happens dozens of times a day with git repos all over the world. :)
Alex> It is actually much simplier doing things right: all this stashing
Alex> people keep talking about.
Yes, and that's what I said too.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: pull into dirty working tree
From: Alex Riesen @ 2007-06-13 20:47 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Bill Lear, git
In-Reply-To: <86645r1wh8.fsf@blue.stonehenge.com>
Randal L. Schwartz, Wed, Jun 13, 2007 21:32:35 +0200:
> Alex> Wont work for new files (not yet known to git) which conflict with the
> Alex> same names from origin. Your method will not put them anywhere and
> Alex> their presence will break git-rebase. You _must_ do a merge.
>
> So I missed git-add for those. Then it'll work. I guess I implied that the
> git-commit initial step should capture all of the "interesting" state.
No, it wont. What files are you going to add? All, but *.o? All, but
*.log? What if user hasn't setup .gitignore yet? What if he meant to
add an ignored file anyway?
> git-rebase *will* do the merge. It must. :)
It won't merge anything which isn't known to git. Now, I come to think
about it, no existing merge method will help you here (and very likely
it shouldn't).
It is actually much simplier doing things right: all this stashing
people keep talking about.
^ 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