* Re: Newbie problem
From: Insitu @ 2007-07-28 8:50 UTC (permalink / raw)
To: git
In-Reply-To: <7vmyxht0r6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
>
> [remote "origin"]
> url = satellite:.git/
> fetch = +refs/heads/*:refs/remotes/origin/*
> push = refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
> On satellite laptop, in .git/config:
>
> [remote "origin"]
> url = mothership:.git/
> fetch = +refs/heads/*:refs/remotes/origin/*
> push = refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
Thanks a lot for all these details !
Yes, I also find Git very well
documented (maybe too much docuemented :) ) and could have come to
the settings with info from the various man pages. But much less
quickly of course.
My question is: can I do this right now that my repositories are up
and running ?
Regards,
--
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-07-28 8:47 UTC (permalink / raw)
To: git
In-Reply-To: <7vd4zb3bid.fsf@assigned-by-dhcp.cox.net>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* bs/lock (Thu Jul 26 22:13:12 2007 -0700) 3 commits
+ Add test for symlinked configuration file updates.
+ use lockfile.c routines in git_commit_set_multivar()
+ fully resolve symlinks when creating lockfiles
I would like to have this in 1.5.3, as it appears to be
obviously and trivially correct, and resolves real issues we saw
reported on the list and #git channel.
* js/worktree (Thu Jul 26 07:32:49 2007 +0100) 5 commits
. With work-trees possibly inside git-dir, be more generous
. Add test for sanitized work-tree behaviour
. Clean up work-tree handling
. Add functions get_relative_cwd() and is_inside_dir()
. Add is_absolute_path(), make_absolute_path() and normalize_path()
Dscho is dead set fixing broken WORK_TREE series that is already
in 'master'. The series so far unfortunately has still been
untestable state, but the basic approach of cleaning up seems
sound, and knowing him I am reasonably confident that this will
be at least 'next' quality soon enough.
* cr/tag (Mon Jul 23 12:58:27 2007 +0100) 5 commits
+ Teach "git stripspace" the --strip-comments option
+ Make verify-tag a builtin.
+ builtin-tag.c: Fix two memory leaks and minor notation changes.
+ launch_editor(): Heed GIT_EDITOR and core.editor settings
+ Make git tag a builtin.
Carlos did a good job at very carefully crafting this series,
under Dscho's supervision. Judging from the quality of the
series, I would personally love to have this in 1.5.3. But as a
matter of principle, replacing an implementation with a totally
different one post -rc is not something I'd want to make a
precedent of. This will be merged early after 1.5.3.
* mc/logsize (Fri Jul 20 20:15:13 2007 +0200) 1 commit
- Add --log-size to git log to print message size
This adds a new option --log-size that is to primarily help
loading "git log --pretty=raw" output by qgit. It is probably
not useful with any other combination of options, with "-p",
"--stat", "--pretty={email,oneline}", etc., as the "length
indicator" is at the wrong place (it should be the first line of
each record, not on the second line), but it is good enough for
helping qgit. This (or improvement of it if one comes up) will
most likely to be in 'master' after 1.5.3.
* js/recursive-fix (Tue Jul 17 18:14:48 2007 +0100) 2 commits
. Add tests for cherry-pick d/f conflict which should be none
. merge-recursive: sometimes, d/f conflict is not an issue
This is to paper over a design bug in merge-recursive d/f
conflict checking code. I'd expect we would want to rethink the
whole merge datapath after 1.5.3 and prefer to leave this series
out of 1.5.3.
* jc/blame (Thu Jul 12 10:49:08 2007 -0700) 4 commits
- git-log --follow?
- git-blame: optimize get_origin() from linear search to hash-
lookup.
- git-blame: pass "struct scoreboard *" pointers around.
- blame: lift structure definitions up
The tip of this is Linus's "follow single file". I will
cherry-pick and put it in 'next' after 1.5.3.
* db/fetch-pack (Tue Jul 10 00:38:42 2007 -0400) 1 commit
. Make fetch-pack a builtin with an internal API
Daniel has a few more patches in this series we have already
seen on the list; I'll ask him to rebase/repost after 1.5.3.
* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
. rebase: allow starting from a dirty tree.
. stash: implement "stash create"
I did this just for fun, but come to think of it, the user can
run git-stash himself when git-rebase complains the working tree
is dirty anyway, so this may probably not so useful.
* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
. Enhance unpack-objects for live repo and large objects
This is to deliberately avoid placing large blob to packfile.
Nico had objections on this type of special purpose hacks, and I
agree with him.
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-07-28 8:47 UTC (permalink / raw)
To: git
In-Reply-To: <7vzm20q1l7.fsf_-_@assigned-by-dhcp.cox.net>
It's been a while since I sent this the last time.
We are nearing 1.5.3 final; I pulled gitk updates tonight, and
expect git-gui updates to 0.8.0 over the weekend. There are a
handful trivial fixes since 1.5.3-rc3.
I am hoping one topic (bs/lock) to graduate from 'next' and
another from nowhere (js/worktree) before 1.5.3-rc4, probably by
mid next-week.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Julian Phillips (1):
Force listingblocks to be monospaced in manpages
Junio C Hamano (1):
Do not expect unlink(2) to fail on a directory.
* The 'master' branch has these since the last announcement
in addition to the above.
Adam Roben (1):
Add GIT_EDITOR environment and core.editor configuration variables
Alex Riesen (1):
Fix git-rebase -i to allow squashing of fast-forwardable commits
Alexandre Julliard (2):
git.el: Support for incremental status updates.
git.el: Pass an explicit argument to enable smerge-mode.
Brian Gernhardt (1):
Document commit.template configuration variable.
Carlos Rica (1):
Rename read_pipe() with read_fd() and make its buffer
nul-terminated.
David Kastrup (2):
contrib/emacs/Makefile: Also install .el files.
Documentation/gitignore.txt: Fix the seriously misleading priority
explanation
Emil Medve (1):
Use $(RM) in Makefiles instead of 'rm -f'
Eric Wong (2):
git-svn: remove leading slashes from fetch lines in the generate
config
git-svn: fix commiting renames over DAV with funky file names
Francis Moreau (1):
Fix git-branch documentation when using remote refs
Greg KH (1):
make git-send-email.perl handle email addresses with no names when
Email::Valid is present
Jakub Narebski (3):
gitweb cleanup: Move @diff_opts declaration earlier
gitweb: Fix support for legacy gitweb config for snapshots
gitweb: More detailed error messages for snapshot format
Jim Meyering (2):
git-cvsserver: detect/diagnose write failure, etc.
pretty-options.txt: tiny doc fix
Johannes Schindelin (13):
filter-branch: get rid of "set -e"
rebase -i: call editor just once for a multi-squash
fsck --lost-found: write blob's contents, not their SHA-1
mailinfo: fix 'fatal: cannot convert from utf-8 to utf-8'
Shut "git rebase -i" up when no --verbose was given
rebase -i: exchange all "if [ .. ]" by "if test .."
filter-branch: Big syntax change; support rewriting multiple refs
Teach revision machinery about --no-walk
git log -g: Complain, but do not fail, when no reflogs are there
Teach approxidate() to understand "never"
git am: skip pine's internal folder data
rebase -i: fix overzealous output redirection
rebase -i: fix interrupted squashing
Josh Triplett (1):
Remove useless uses of cat, and replace with filename arguments
Junio C Hamano (24):
Make show_rfc2822_date() just another date output format.
Wire new date formats to --date=<format> parser.
Document new --date=<format>
Add contrib/stats/mailmap.pl script
Update .mailmap
Documentation/git-commit-tree: remove description of a nonexistent
limitation
GIT v1.5.3-rc2
Update INSTALL
Fix VISUAL/EDITOR preference order in Documentation/config.txt.
Synonyms: -i == --regexp-ignore-case, -E == --extended-regexp
Mark user-manual as UTF-8
user-manual: fix typolets.
t9200: Be careful when checking CVS/Entries
GIT 1.5.3-rc3
Make sure git-stash works from subdirectory.
gitweb: fix broken snapshot
git-submodule module_name: avoid using unwieldy "value_regexp"
feature.
git-submodule: remove redundant call to git-describe
When locking in a symlinked repository, try to lock the original.
git_mkstemp(): be careful not to overflow the path buffer.
Update description of -z option.
git-stash: do not remove a ref by hand.
Fix git-stash apply --index
git-stash apply --index: optimize postprocessing
Kumar Gala (1):
send-email: Update regex parsing for pine aliases
Linus Torvalds (2):
Do a better job at guessing unknown character sets
Fix up duplicate parents removal
Marco Costalba (1):
Avoid to duplicate commit message when is not encoded
Marius Storm-Olsen (1):
Fix git-p4 on Windows to not use the Posix sysconf function.
Mark Levedahl (1):
gitk: Ignore ctrl-z as EOF on windows
Matt McCutchen (1):
gitweb: snapshot cleanups & support for offering multiple formats
Matthieu Moy (1):
More permissive "git-rm --cached" behavior without -f.
Nanako Shiraishi (2):
Document "git stash message..."
git-stash: Make sure reflog is created for refs/stash
Nguyễn Thái Ngọc Duy (1):
git-write-tree should not crash if prefix does not exist
Paul Mackerras (5):
gitk: Fix bug introduced by previous commit
gitk: Show changes in index and changes in working directory
separately
gitk: Make the fake commit for the index changes green rather than
magenta
gitk: Wait for the window to become visible after creating it
gitk: Fix bugs in the Find function
Peter Hagervall (1):
Make every builtin-*.c file #include "builtin.h"
René Scharfe (2):
filter-branch: fix dash complaining about "Missing '))'"
cleanup unpack-trees.c: shrink struct tree_entry_list
Richard MUSIL (1):
git-svn: Minimalistic patch which allows svn usernames with
space(s).
Robin Rosenberg (3):
Support output ISO 8601 format dates
cvsexportcommit: avoid racy CVS problem.
Document --unified/-U option
Scott Lamb (2):
git-p4: use subprocess in p4CmdList
git-p4: input to "p4 files" by stdin instead of arguments
Sean Estabrooks (3):
Remove "WITH_P4IMPORT" knob from the Makefile
Remove p4 rpm from git.spec.in.
Demote git-p4import to contrib status.
Shawn O. Pearce (3):
Correct trivial typo in fast-import documentation
Teach fast-import to recursively copy files/directories
gitk: Bind keyboard actions to the command key on Mac OS
Simon Hausmann (4):
git-p4: Cleanup, make listExistingP4Branches a global function for
later use.
git-p4: Fix upstream branch detection for submit/rebase with
multiple branches.
git-p4: Cleanup, used common function for listing imported p4
branches
git-p4: Fix p4 user cache population on Windows.
Stephen Rothwell (1):
send-email: discard blank around address in extract_valid_address
as well.
Steven Grimm (2):
Document how to tell git to not launch a pager
Teach git-commit about commit message templates.
Sven Verdoolaege (2):
lockfile.c: schedule remove_lock_file only once.
unpack-trees.c: assume submodules are clean during check-out
^ permalink raw reply
* Re: suggestion for git rebase -i
From: Jeff King @ 2007-07-28 8:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Seth Falcon, git
In-Reply-To: <Pine.LNX.4.64.0707280941380.14781@racer.site>
On Sat, Jul 28, 2007 at 09:43:15AM +0100, Johannes Schindelin wrote:
> > a file in a pre-existing editor session. I realize this is a small
> > nit, but how about renaming the file to "git-rebase-todo"?
>
> Why? This is an implementation detail, and should not concern the user.
Because if you want to setup macros or syntax highlighting specific to
editing git-rebase tempfiles, then you have to figure out somehow that
you are editing one. Using a more informative name for the tempfile
means that you can guess based on the filename.
-Peff
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-28 8:44 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0707202154220.27249@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Why? Because my preliminary patches sort the index entries wrong. A
> directory should always sort *as*if* it had the '/' at the end.
>
> See base_name_compare() for details.
>
> And we've never done that for the index, because the index has never had
> this issue (since it never contained directories). So sit down and compare
> base_name_compare (for tree entries) with cache_name_compare() (for index
> entries), and see how the latter doesn't care about the type of names.
>
> This was actually something that I hit already with subproject support,
> and one of my very first patches even had some (aborted) code to start
> sorting subprojects in the index the way we sort directories.
>
> And I *should* have done it that way, but I never did. It now makes the
> S_ISDIR handling harder, because directories really do have to be sorted
> as if they had the '/' at the end, or "git-fsck" will complain about bad
> sorting.
>
> Sad, sad, sad. It effectively means that S_IFGITLINK is *not* quite the
> same as S_IFDIR, because they sort differently. Duh.
>
> Of course, it seldom matters, but basically, you should test a directory
> structure that has the files
>
> dir.c
> dir/test
>
> in it, and the "dir" directory should always sort _after_ "dir.c".
>
> And yes, having the index entry with a '/' at the end would handle that
> automatically.
Personally, I am not much in favor of using different names in index
and repository.
> As it is, with the "mode" difference, it instead needs to fix up
> "cache_name_compare()". Admittedly, that would actually be a cleanup
> (since it would now match base_name_compare() in logic, and could actually
> use that to do the name comparison!), but it's a damn painful cleanup
> because we don't even pass in the mode to "cache_name_compare()", since we
> never needed it.
>
> Gaah.
>
> cache_name_compare itself isn't used in that many places,
dir.c and readcache.c
> but it's used by "index_name_pos()/cache_name_pos()", which *is*
> used in many places.
cache_name_pos:
builtin-apply.c
builtin-blame.c
builtin-checkout-index.c
builtin-ls-files.c
builtin-mv.c
builtin-read-tree.c
builtin-rm.c
builtin-update-index.c
diff.c
diff-lib.c
dir.c
merge-index.c
sha1_name.c
unpack-trees.c
wt-status.c
index_name_pos:
read-cache.c
> And again, that one doesn't even have the mode, so it cannot pass it
> down.
> So it probably *is* easier to add the '/' at the end of the name
> instead, to make directories sort the right way in the index. I'd
> still suggest you *also* make the mode be S_IFDIR, though (and
> preferably make git-fsck actually verify that the mode and the last
> character of the name matches!).
Actually, pretty much all of the above files are likely to get touched
by directory support one way or another anyway. One really should aim
for the cleanest solution in the long run, and this for me more or
less means that it makes no sense to have different names in index and
repository. Putting that slash in always would probably simplify some
logic in the repository as well, but I don't really like something as
marker-like as "/" in the data structures. Putting a slash there
would involve a three-phase plan:
a) make fsck and the other code deal gracefully with either slash or
no slash.
Wait until everybody uses this code.
b) make the code actually _put_ slashes there.
Wait until everybody has used this code.
c) deal with it for all eternity, oops: since rewriting the
cryptographic history of existing repositories is pretty much out
as far as I understand (which might be insufficient), one has to
navigate around slash/noslash all the time when accessing
repositories, including the sorting. The index, however, can at
one point of time phase out the slash-specific sorting. There is
no such thing as prehistoric indexes we would need to mind.
I guess that looks like not being worth the pain. Double the code or
no money back.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: suggestion for git rebase -i
From: Johannes Schindelin @ 2007-07-28 8:43 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m26445t98z.fsf@ziti.fhcrc.org>
Hi,
On Fri, 27 Jul 2007, Seth Falcon wrote:
> The tempfile used by git rebase -i is called "todo". For those using
> something like emacsclient, this is a bit too generic for the name of
> a file in a pre-existing editor session. I realize this is a small
> nit, but how about renaming the file to "git-rebase-todo"?
Why? This is an implementation detail, and should not concern the user.
However, I was thinking about adding a "git rebase --status" to show where
you are, but that will have to be implemented by someone else, or it has
to wait a little.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: Andy Parkins @ 2007-07-28 8:02 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Paolo Ciarrocchi
In-Reply-To: <200707272107.16602.jnareb@gmail.com>
On Friday 2007, July 27, Jakub Narebski wrote:
> > Not using GIT
> Well, it is meant to be Git _USER'S_ Survey. The rest of questions
> wouldn't have much sense if responder is not familiar with Git.
Of course; the rest of the question would be left unanswered in that case.
I suggested it because if you are going to go to the effort of spreading a
survey as far and wide as you suggest (and you included some places that
aren't known users of git - like mozilla) it seems wasteful not to get some
information about the non-users of git - and more importantly what git
doesn't do and why they aren't using it (madness presumably).
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Newbie problem
From: Junio C Hamano @ 2007-07-28 8:01 UTC (permalink / raw)
To: Insitu; +Cc: git
In-Reply-To: <87vec5vvt5.fsf@osquare.oqube.com>
Insitu <abailly@oqube.com> writes:
> Now, I want to be able to do:
> lap> git push
> or
> lap> git pull
>
> instead of
> lap> git push ssh://pc/~/.git
>
> I think I need to reconfigure my remote branches/origin on laptop but
> don't want ot break everything.
The necessary syntax and configuration files are all documented
fairly detailed in the manual pages, but it is a tad hard to
know where to look:
http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html
http://www.kernel.org/pub/software/scm/git/docs/git-push.html
http://www.kernel.org/pub/software/scm/git/docs/git-config.html
If you use recent enough git (post 1.5.0), the recommended way
to keep two boxes in sync is:
On mothership box, in .git/config:
[remote "origin"]
url = satellite:.git/
fetch = +refs/heads/*:refs/remotes/origin/*
push = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
On satellite laptop, in .git/config:
[remote "origin"]
url = mothership:.git/
fetch = +refs/heads/*:refs/remotes/origin/*
push = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Then, whenever you start working on the satellite:
$ git pull
which, while you are on "master" branch, would use 'origin' as
the default remote (thanks to branch.master.remote configuration),
store the copy of mothership's branches in refs/remotes/origin/,
and merges the "master" branch obtained from the mothership to
your "master" branch on the satellite [*1*].
When you are done working on the satellite:
$ git push
will push to "origin" by default, which would push all your
branches (thanks to remote.origin.push configuration) to
mothership's refs/remotes/origin/.
When you go back to the mothership, your work done on the
satellite are already pushed into the refs/remote/origin/
tracking branches, so you can merge them in (you can do this
after shutting down your satellite laptop, which is the beauty
of this setup):
$ git merge origin/master
to merge in the changes you did on the satellite.
[Footnote]
*1* If you prefer to keep a straight history, you may want to
fetch+rebase instead of pull which is a fetch+merge, in
which case this step will be:
$ git fetch
$ git rebase origin/master
^ permalink raw reply
* Re: [PATCH] translate bad characters in refnames during git-svn fetch
From: David Kastrup @ 2007-07-28 7:33 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <loom.20070728T091909-416@post.gmane.org>
Mike Hommey <mh@glandium.org> writes:
> Eric Wong <normalperson <at> yhbt.net> writes:
>>
>> Somebody naming directories on the SVN side with the path component
>> ":refs/remotes" in them could screw things up for us.
>
> Why not "simply" allow some form of escaping in refs, such that special
> characters CAN be used anywhere. Then git-svn would just have to escape these
> characters.
>
> Something like:
> git update-ref "refs/remotes/tags/sometag\~1" $sha1
>
> I'm pretty sure that could help fix a lot of other similar issues.
Well, having had to do my fair level of porting shell-scripts and
installation stuff and so on to Windows/MacOSX whatsoever where spaces
(and other characters) in file names are considered business as usual:
it is a bottomless pit. You'll always find one more place in your
software that does not get this right.
It may be a more confined problem to make the interoperation utility
responsible for quoting/renaming.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Newbie problem
From: Insitu @ 2007-07-28 7:20 UTC (permalink / raw)
To: git
Hello,
I am new to git and gave it a try to version my home dir and
synchronize it between two machines. It works but I think I did some
mistakes in my setup which make its usability non optimal:
- push/pull operations need remote address
- I didn't set up any branch
Here is what I did (lap is for operations on laptop, pc on desktop):
lap> git init
lap> git add ...
lap> git commit ...
lap> scp .git pc:
lap> mv .git git-init
pc> git checkout .
pc> git commit ...
lap> git clone -n --bare --reference git-init/ ssh://pc/~/.git
lap> git checkout .
lap> git add ...
lap> git commit
Now, I want to be able to do:
lap> git push
or
lap> git pull
instead of
lap> git push ssh://pc/~/.git
I think I need to reconfigure my remote branches/origin on laptop but
don't want ot break everything.
Help appreciated,
--
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com
^ permalink raw reply
* Re: [PATCH 1/2] gitk: Import msgcat for translation support
From: Brett Schwarz @ 2007-07-28 7:28 UTC (permalink / raw)
To: Paul Mackerras, Christian Stimming; +Cc: git
>
> ----- Original Message ----
> From: Paul Mackerras <paulus@samba.org>
> To: Christian Stimming <stimming@tuhh.de>
> Cc: git@vger.kernel.org
> Sent: Friday, July 27, 2007 4:53:28 PM
> Subject: Re: [PATCH 1/2] gitk: Import msgcat for translation support
>
> Christian Stimming writes:
>
> > Import tcl's msgcat package to have the [mc...] procedure for
> > translation available.
>
> I would prefer
>
> if {[catch {
> package require msgcat
> # rest of your new stuff
> }]} {
> proc mc {str} {
> return $str
> }
> }
>
> so that everything still works if msgcat isn't available. In other
> words I don't want to introduce a possible regression by increasing
> gitk's requirements.
Junio already replied to this, and he was correct. However, this made me think
of something (that probably should be in git-gui as well) to make it a little
more robust. We should check that the msg directory is where we think it is,
and either give a warning, or exit the app (I would vote for the former).
So, something like:
set msgdir [file join . msgs] ;# or whatever this turns out to be
if {[file exists $msgdir]} {
::msgcat::mcload $msgdir
} else {
puts stderr "WTF: can't find message catalog directory"
}
Or you could just use [catch] around the ::msgcat::mcload too.
Regards,
--brett
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/
^ permalink raw reply
* Re: [PATCH] translate bad characters in refnames during git-svn fetch
From: Mike Hommey @ 2007-07-28 7:23 UTC (permalink / raw)
To: git
In-Reply-To: <20070717122852.GA21372@mayonaise>
Eric Wong <normalperson <at> yhbt.net> writes:
> martin f krafft <madduck <at> madduck.net> wrote:
> > also sprach Eric Wong <normalperson <at> yhbt.net> [2007.07.16.0530 +0200]:
> > > The major issue with this is that it doesn't handle odd cases
> > > where a refname is sanitized into something (say "1234~2"
> > > sanitizes to "1234=2"), and then another branch is created named
> > > "1234=2".
> >
> > Well, we can't please everyone, can we? :)
> >
> > I like Jan's proposal about using the % escape, even though it
> > doesn't make pretty branch names.
>
> I like it, too. How about something like the two functions below? This
> will break things a bit for people currently using % in refnames,
> however.
>
> I think this will work rather nicely once I've figured out how the path
> globbing code works[1] and where to sanitize/desanitize the refnames
> properly.
>
> It would be far easier to take your approach and sanitize them only
> for the command-line, but storing unsanitized git refnames into the
> .git/config is something I want to avoid:
>
> Somebody naming directories on the SVN side with the path component
> ":refs/remotes" in them could screw things up for us.
Why not "simply" allow some form of escaping in refs, such that special
characters CAN be used anywhere. Then git-svn would just have to escape these
characters.
Something like:
git update-ref "refs/remotes/tags/sometag\~1" $sha1
I'm pretty sure that could help fix a lot of other similar issues.
Mike
^ permalink raw reply
* Re: [PATCH 2/2] gitk: Markup many strings for translation.
From: Brett Schwarz @ 2007-07-28 7:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Christian Stimming, git
>
>
> ----- Original Message ----
> From: Paul Mackerras <paulus@samba.org>
> To: Brett Schwarz <brett_schwarz@yahoo.com>
> Cc: Christian Stimming <stimming@tuhh.de>; git@vger.kernel.org
> Sent: Friday, July 27, 2007 7:40:20 PM
> Subject: Re: [PATCH 2/2] gitk: Markup many strings for translation.
>
> Brett Schwarz writes:
>
> > > - set commitinfo($id) {"No commit information available"}
> > > + set commitinfo($id) {[mc "No commit information available"]}
> >
> > I think this is probably a typo (on the original), and carrying that
> > forward will probably result in what was not intended.
> >
> > The original has the {} and "". I don't know if this was intended
> > (it will keep the quotes).
>
> Yes it is what was intended - it is a list with one element, which is
> a string.
Ah, ok. Then the patch probably should look like this then:
set commitinfo($id) [list [mc "No commit information available"]]
Regards,
--brett
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/
^ permalink raw reply
* [PATCH 2/2] git-stash apply --index: optimize postprocessing
From: Junio C Hamano @ 2007-07-28 7:02 UTC (permalink / raw)
To: git
Cc: しらいしななこ,
Johannes Schindelin
In-Reply-To: <7vbqdxui72.fsf@assigned-by-dhcp.cox.net>
Originally, "apply --index" codepath was bolted on to the
"update working tree files and index, but then revert the
changes we make to the index except for added files so that we
do not forget about them" codepath, almost as an afterthought.
Because "apply --index" first prepares the final index state
upfront, "revert except the added paths" postprocessing does not
have to be done.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-stash.sh | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 873e7be..30425ce 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -157,15 +157,16 @@ apply_stash () {
if git-merge-recursive $b_tree -- $c_tree $w_tree
then
# No conflict
- a="$TMP-added" &&
- git diff --cached --name-only --diff-filter=A $c_tree >"$a" &&
- git read-tree --reset $c_tree &&
- git update-index --add --stdin <"$a" ||
- die "Cannot unstage modified files"
- rm -f "$a"
if test -n "$unstashed_index_tree"
then
git read-tree "$unstashed_index_tree"
+ else
+ a="$TMP-added" &&
+ git diff --cached --name-only --diff-filter=A $c_tree >"$a" &&
+ git read-tree --reset $c_tree &&
+ git update-index --add --stdin <"$a" ||
+ die "Cannot unstage modified files"
+ rm -f "$a"
fi
git status || :
else
--
1.5.3.rc3.16.g9f04-dirty
^ permalink raw reply related
* [PATCH 1/2] Fix git-stash apply --index
From: Junio C Hamano @ 2007-07-28 7:02 UTC (permalink / raw)
To: git
Cc: しらいしななこ,
Johannes Schindelin
In-Reply-To: <7vbqdxui72.fsf@assigned-by-dhcp.cox.net>
Two bugs that made the command practically unusable were fixed
with this.
- A stash created with a clean index does not have any
difference between the base tree and the index tree.
Trying to apply the diff between them to the index would
error out with "No changes". Even when the user asked to
unstash with --index, do not bother with --index action if
the base tree and the index tree match.
- After successfully performing the working tree merge, the
index was reloaded from an earlier state of unstashed index
with "read-tree"; this left all the paths cache dirty. By
moving the call to git-status after this read-tree, match the
cached stat information in the index.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-stash.sh | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 0073e9d..873e7be 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -128,19 +128,24 @@ apply_stash () {
c_tree=$(git write-tree) ||
die 'Cannot apply a stash in the middle of a merge'
+ # stash records the work tree, and is a merge between the
+ # base commit (first parent) and the index tree (second parent).
s=$(git rev-parse --revs-only --no-flags --default $ref_stash "$@") &&
w_tree=$(git rev-parse --verify "$s:") &&
- b_tree=$(git rev-parse --verify "$s^:") ||
+ b_tree=$(git rev-parse --verify "$s^1:") &&
+ i_tree=$(git rev-parse --verify "$s^2:") ||
die "$*: no valid stashed state found"
- test -z "$unstash_index" || {
+ unstashed_index_tree=
+ if test -n "$unstash_index" && test "$b_tree" != "$i_tree"
+ then
git diff --binary $s^2^..$s^2 | git apply --cached
test $? -ne 0 &&
die 'Conflicts in index. Try without --index.'
unstashed_index_tree=$(git-write-tree) ||
die 'Could not save index tree'
git reset
- }
+ fi
eval "
GITHEAD_$w_tree='Stashed changes' &&
@@ -157,13 +162,19 @@ apply_stash () {
git read-tree --reset $c_tree &&
git update-index --add --stdin <"$a" ||
die "Cannot unstage modified files"
- git-status
rm -f "$a"
- test -z "$unstash_index" || git read-tree $unstashed_index_tree
+ if test -n "$unstashed_index_tree"
+ then
+ git read-tree "$unstashed_index_tree"
+ fi
+ git status || :
else
# Merge conflict; keep the exit status from merge-recursive
status=$?
- test -z "$unstash_index" || echo 'Index was not unstashed.' >&2
+ if test -n "$unstash_index"
+ then
+ echo >&2 'Index was not unstashed.'
+ fi
exit $status
fi
}
--
1.5.3.rc3.16.g9f04-dirty
^ permalink raw reply related
* Re: [PATCH 2/2] gitk: Markup many strings for translation.
From: Junio C Hamano @ 2007-07-28 7:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Christian Stimming, git
In-Reply-To: <18090.57453.466507.354727@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> By the way, could you do a pull from gitk.git? There are some
> bug-fixes plus the change to show the index and working directory as
> separate fake commits, as requested by Linus.
My pleasure. I should have polled people earlier.
Thanks.
^ permalink raw reply
* [PATCH 0/2] git-stash last-minute fixes
From: Junio C Hamano @ 2007-07-28 6:59 UTC (permalink / raw)
To: git
Cc: しらいしななこ,
Johannes Schindelin
Here are a small patch series to git-stash.
[1/2] Fix git-stash apply --index
This fixes two rather embarrasing bugs in "apply --index".
[2/2] git-stash apply --index: optimize postprocessing
This builds on top of the previous one to avoid unnecessary
index manipulations that is later wiped by a read-tree.
There also is a bugfix I received privately from Nana for the
breakage I introduced with 7ab3cc70. I've already queued it for
'master'.
-- >8 --
From: しらいしななこ <nanako3@bluebottle.com>
Date: Sat, 28 Jul 2007 10:44:48 +0900
Subject: [PATCH] git-stash: Make sure reflog is created for refs/stash
Earlier commit 7ab3cc70 fixed "stash clear" but broke save_stash,
because it forgot to make sure the reflog file exists before saving.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/git-stash.sh b/git-stash.sh
index f90dffd..0073e9d 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -36,6 +36,9 @@ save_stash () {
test -f "$GIT_DIR/logs/$ref_stash" ||
clear_stash || die "Cannot initialize stash"
+ # Make sure the reflog for stash is kept.
+ : >>"$GIT_DIR/logs/$ref_stash"
+
# state of the base commit
if b_commit=$(git rev-parse --verify HEAD)
then
^ permalink raw reply related
* Re: [PATCH 2/2] gitk: Markup many strings for translation.
From: Paul Mackerras @ 2007-07-28 6:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Stimming, git
In-Reply-To: <7vvec5uo01.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> My preference is 1.b, as the longer term plan (when everybody
> has git 1.5.2 or newer) is to eject git-gui.git project from
> git.git proper, and use the subproject feature to have
> git-gui.git in git.git; it would be good if gitk.git can be
> handled the same way, and the layout 1.b would make it the
> easiest, as it matches how we treat git-gui.git project now.
1.b sounds fine to me too.
> You also expressed in a separate message about "catching package
> require msgcat to avoid breakage". I think msgcat package is
> part of the standard Tcl distribution since 8.1; how old a
> tcl/tk do you support?
Gitk requires 8.4, so that sounds OK then. I didn't realize it had
been part of the standard distribution for so long.
> In any case, I would very much appreciate if any of these will
> *NOT* happen before 1.5.3. git-gui 0.8.0 which is scheduled to
> be in 1.5.3 will not have i18n.
No problem. :)
By the way, could you do a pull from gitk.git? There are some
bug-fixes plus the change to show the index and working directory as
separate fake commits, as requested by Linus.
Paul.
^ permalink raw reply
* suggestion for git rebase -i
From: Seth Falcon @ 2007-07-28 4:58 UTC (permalink / raw)
To: git
The tempfile used by git rebase -i is called "todo". For those using
something like emacsclient, this is a bit too generic for the name of
a file in a pre-existing editor session. I realize this is a small
nit, but how about renaming the file to "git-rebase-todo"?
+ seth
--
Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
BioC: http://bioconductor.org/
Blog: http://userprimary.net/user/
^ permalink raw reply
* Re: [PATCH 3/8] Clean up work-tree handling
From: Junio C Hamano @ 2007-07-28 5:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, matled
In-Reply-To: <Pine.LNX.4.64.0707280152120.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Well, one of the conditions to accept the worktree stuff was not
>> to break anybody who never ever uses worktree. So if we can
>> keep the UP-ness of cdup, it would be much better.
>
> One could record if the work tree was changed from the default one, and
> do the old thing in that case.
This really should not be something you have to bend over with
special code to support. One thing I think people's scripts
expect is that cdup is what the name suggests, "how much do I go
*up* in order to go to the top of the working tree", and if the
answer is "nothing", they can tell that they are already at the
top of the tree.
Now, I think it is fair to say that if your worktree is
somewhere totally unrelated to your cwd, no amount of going up
will take you to the top. IOW, you have to come down after
going up some levels. In such a case, it is easier to code the
implementation of --show-cdup to give an absolute path.
But in that case you are not even in the working tree to begin
with, aren't you? Does git need to support that? What should
"prefix = setup_git_dir()" do and return, in order to come up
with the string to prepend to paths relative to the current
directory the users give us? I would say if your cwd is not
inside your working tree, then --show-cdup and --show-prefix
should error out, saying "Not in the working tree". These
options are about translating paths relative to your cwd to
relative to the top of the working tree, so if you are outside a
working tree, they do not make much sense.
Also I think the implementation of --show-prefix needs to work
in terms of relative relationship between cwd and the top
already, so I am not sure where your aversion of keeping the
current cdup behaviour is coming from.
I was hoping that --show-cdup is rarely used, but unfortunately
cd_to_toplevel() in git-sh-setup.sh is not even the only in-tree
user of --show-cdup; it checks if it is empty to avoid chdir()
unnecessarily. There are others:
- emacs/git.el uses it as part of expand-file-name, so I think
giving an absolute path back is Ok.
- contrib/fast-import/git-p4 gives it to os.chdir() after
checking if the length is positive; this should be Ok
although it would involve an unnecessary chdir() if the
process is already at the top with this change.
- contrib/p4import/git-p4import.py: the same story as git-p4.
- git-svn.perl: the same story as above.
^ permalink raw reply
* Re: [PATCH 2/2] gitk: Markup many strings for translation.
From: Junio C Hamano @ 2007-07-28 4:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Christian Stimming, git
In-Reply-To: <18090.44123.905869.974967@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Christian Stimming writes:
>
>> Similar to the discussion in git-gui, all user-visible strings are
>> passed through the [mc ...] procedure to have them translated by msgcat.
>>
>> Signed-off-by: Christian Stimming <stimming@tuhh.de>
>> ---
>> @Paul: Are you interested in applying this? If yes, I'd happily
>
> Yes, it doesn't look too bad. The patch seemed to be line-wrapped and
> whitespace-damaged, though.
>
>> provide the Makefile rules for string extraction and translation
>> catalog updates, but I'd like to hear a proposal or decision on where
>> to place them. Should the po files for translation go into the po/
>> subdirectory? And then a proposal/decision of where to install the
>> compiled .msg catalogs will be necessary.
>
> Yes indeed. Junio?
Before talking about installation location, let me worry a bit
about integration.
This is a bit tricky because of the way gitk.git project was
absorbed in git.git repository. Historically we have assumed
that gitk would always stay a single file project, but with
po/*.{po,msg} and gettext toolchain we would also need a
Makefile target or two for maintaining i18n infrastructure for
gitk.
I think we could do one of three things.
1. In git.git, move the location gitk.git is absorbed one level
down, to gitk/ subdirectory. This can have two variants.
1.a Your gitk.git repository could match this move; from being
a single file project, it would become a single directory,
gitk/, initially with a single file under it
(i.e. gitk/gitk), and then i18n coordinator (Christian?)
and i18n group would provide you with gitk/Makefile and
gitk/po/*.po files. I could just merge the result of such
move without any trick if this happens;
1.b Your gitk.git repository can stay in the current shape of
having a single file gitk in it, with Makefile and po/*.po
files supplied by the i18n group. I would have to merge
such a repository with subtree strategy just like I handle
the absorption of git-gui.git project.
2. Your gitk.git could stay without the actual i18n except the
[mc ...] changes, and po/*.po and gettext toolchain calls
can be directly be in git.git project. In git.git, gitk
would continue to be merged from you at the toplevel.
My preference is 1.b, as the longer term plan (when everybody
has git 1.5.2 or newer) is to eject git-gui.git project from
git.git proper, and use the subproject feature to have
git-gui.git in git.git; it would be good if gitk.git can be
handled the same way, and the layout 1.b would make it the
easiest, as it matches how we treat git-gui.git project now.
About the installation location, I would say we can mimick what
git-gui i18n team does and use $(sharedir)/gitk/lib/msgs to
install the message files.
> Is it possible to include the translations, or at least the more
> common translations, in the Tcl code itself? So far I have managed to
> have gitk be self-contained, in that it doesn't need any external data
> files, which simplifies installation and is a useful attribute in some
> situations.
Anything is possible, but I think that is cumbersome to arrange
and probably wasteful at runtime. You will end up carrying
lines of form:
::msgcat::mcset xx "Origial" "Translation in language xx"
for all languages in the same gitk script. Worse, these mcset
lines are not something translators directly work on; rather,
they are output of msgfmt program.
> Also I would want to be sure that gitk wouldn't crash or fail to
> function if it can't find its message catalogs.
You also expressed in a separate message about "catching package
require msgcat to avoid breakage". I think msgcat package is
part of the standard Tcl distribution since 8.1; how old a
tcl/tk do you support?
In any case, I would very much appreciate if any of these will
*NOT* happen before 1.5.3. git-gui 0.8.0 which is scheduled to
be in 1.5.3 will not have i18n.
^ permalink raw reply
* Re: git diff with add/modified codes
From: Jeff King @ 2007-07-28 4:39 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910707271717q5ea33b55r227d8dbb1023de47@mail.gmail.com>
On Fri, Jul 27, 2007 at 08:17:54PM -0400, Jon Smirl wrote:
> That's not what I want. I'm looking a report that indicates new files
> vs modified ones in a single list. These old patches I am working with
> often create 100 files and modify another 200.
>
> Adding a code like (Added (A), Copied (C), Deleted (D), Modified (M),
> Renamed (R)) to --stat would be perfect.
How about --name-status?
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] gitk: Markup many strings for translation.
From: Paul Mackerras @ 2007-07-28 2:40 UTC (permalink / raw)
To: Brett Schwarz; +Cc: Christian Stimming, git
In-Reply-To: <959247.27950.qm@web38905.mail.mud.yahoo.com>
Brett Schwarz writes:
> > - set commitinfo($id) {"No commit information available"}
> > + set commitinfo($id) {[mc "No commit information available"]}
>
> I think this is probably a typo (on the original), and carrying that
> forward will probably result in what was not intended.
>
> The original has the {} and "". I don't know if this was intended
> (it will keep the quotes).
Yes it is what was intended - it is a list with one element, which is
a string.
Paul.
^ permalink raw reply
* Re: [PATCH 2/2] gitk: Markup many strings for translation.
From: Paul Mackerras @ 2007-07-28 2:39 UTC (permalink / raw)
To: Christian Stimming; +Cc: git
In-Reply-To: <20070727170300.t01ku4u2sg04sgsk@webmail.tu-harburg.de>
Christian Stimming writes:
> Similar to the discussion in git-gui, all user-visible strings are
> passed through the [mc ...] procedure to have them translated by msgcat.
>
> Signed-off-by: Christian Stimming <stimming@tuhh.de>
> ---
> @Paul: Are you interested in applying this? If yes, I'd happily
Yes, it doesn't look too bad. The patch seemed to be line-wrapped and
whitespace-damaged, though.
> provide the Makefile rules for string extraction and translation
> catalog updates, but I'd like to hear a proposal or decision on where
> to place them. Should the po files for translation go into the po/
> subdirectory? And then a proposal/decision of where to install the
> compiled .msg catalogs will be necessary.
Yes indeed. Junio?
Is it possible to include the translations, or at least the more
common translations, in the Tcl code itself? So far I have managed to
have gitk be self-contained, in that it doesn't need any external data
files, which simplifies installation and is a useful attribute in some
situations.
Also I would want to be sure that gitk wouldn't crash or fail to
function if it can't find its message catalogs.
Paul.
^ permalink raw reply
* Re: [PATCH 1/2] gitk: Import msgcat for translation support
From: Paul Mackerras @ 2007-07-27 23:53 UTC (permalink / raw)
To: Christian Stimming; +Cc: git
In-Reply-To: <20070727165318.e96b1yxxwsooo884@webmail.tu-harburg.de>
Christian Stimming writes:
> Import tcl's msgcat package to have the [mc...] procedure for
> translation available.
I would prefer
if {[catch {
package require msgcat
# rest of your new stuff
}]} {
proc mc {str} {
return $str
}
}
so that everything still works if msgcat isn't available. In other
words I don't want to introduce a possible regression by increasing
gitk's requirements.
Paul.
^ 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