* [GITK PATCH v2] Add menu accelerators
From: Robin Rosenberg @ 2008-10-19 22:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18681.53866.855255.688290@cargo.ozlabs.ibm.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
gitk | 80 +++++++++++++++++++++++++++++++++---------------------------------
1 files changed, 40 insertions(+), 40 deletions(-)
This one is slightly better than the first one. Works with gitk id...id too.
-- robin
diff --git a/gitk b/gitk
index 3678de1..df039b9 100755
--- a/gitk
+++ b/gitk
@@ -1817,26 +1817,26 @@ proc makewindow {} {
# The "mc" arguments here are purely so that xgettext
# sees the following string as needing to be translated
makemenu .bar {
- {mc "File" cascade {
- {mc "Update" command updatecommits -accelerator F5}
- {mc "Reload" command reloadcommits}
- {mc "Reread references" command rereadrefs}
- {mc "List references" command showrefs}
- {mc "Quit" command doquit}
+ {mc "&File" cascade {
+ {mc "&Update" command updatecommits -accelerator F5}
+ {mc "&Reload" command reloadcommits}
+ {mc "R&eread references" command rereadrefs}
+ {mc "&List references" command showrefs}
+ {mc "&Quit" command doquit}
}}
- {mc "Edit" cascade {
- {mc "Preferences" command doprefs}
+ {mc "&Edit" cascade {
+ {mc "&Preferences" command doprefs}
}}
- {mc "View" cascade {
- {mc "New view..." command {newview 0}}
- {mc "Edit view..." command editview -state disabled}
- {mc "Delete view" command delview -state disabled}
+ {mc "&View" cascade {
+ {mc "&New view..." command {newview 0}}
+ {mc "&Edit view..." command editview -state disabled}
+ {mc "&Delete view" command delview -state disabled}
{xx "" separator}
- {mc "All files" radiobutton {selectedview 0} -command {showview 0}}
+ {mc "&All files" radiobutton {selectedview 0} -command {showview 0}}
}}
- {mc "Help" cascade {
- {mc "About gitk" command about}
- {mc "Key bindings" command keys}
+ {mc "&Help" cascade {
+ {mc "&About gitk" command about}
+ {mc "&Key bindings" command keys}
}}
}
. configure -menu .bar
@@ -2220,39 +2220,39 @@ proc makewindow {} {
set rowctxmenu .rowctxmenu
makemenu $rowctxmenu {
- {mc "Diff this -> selected" command {diffvssel 0}}
- {mc "Diff selected -> this" command {diffvssel 1}}
- {mc "Make patch" command mkpatch}
- {mc "Create tag" command mktag}
- {mc "Write commit to file" command writecommit}
- {mc "Create new branch" command mkbranch}
- {mc "Cherry-pick this commit" command cherrypick}
- {mc "Reset HEAD branch to here" command resethead}
+ {mc "Diff &this -> selected" command {diffvssel 0}}
+ {mc "Diff &selected -> this" command {diffvssel 1}}
+ {mc "Make &patch" command mkpatch}
+ {mc "Create ta&g" command mktag}
+ {mc "&Write commit to file" command writecommit}
+ {mc "Create new &branch" command mkbranch}
+ {mc "&Cherry-pick this commit" command cherrypick}
+ {mc "&Reset HEAD branch to here" command resethead}
}
$rowctxmenu configure -tearoff 0
set fakerowmenu .fakerowmenu
makemenu $fakerowmenu {
- {mc "Diff this -> selected" command {diffvssel 0}}
- {mc "Diff selected -> this" command {diffvssel 1}}
- {mc "Make patch" command mkpatch}
+ {mc "Diff &this -> selected" command {diffvssel 0}}
+ {mc "Diff &selected -> this" command {diffvssel 1}}
+ {mc "Make &patch" command mkpatch}
}
$fakerowmenu configure -tearoff 0
set headctxmenu .headctxmenu
makemenu $headctxmenu {
- {mc "Check out this branch" command cobranch}
- {mc "Remove this branch" command rmbranch}
+ {mc "&Check out this branch" command cobranch}
+ {mc "&Remove this branch" command rmbranch}
}
$headctxmenu configure -tearoff 0
global flist_menu
set flist_menu .flistctxmenu
makemenu $flist_menu {
- {mc "Highlight this too" command {flist_hl 0}}
- {mc "Highlight this only" command {flist_hl 1}}
- {mc "External diff" command {external_diff}}
- {mc "Blame parent commit" command {external_blame 1}}
+ {mc "Highlight this &too" command {flist_hl 0}}
+ {mc "Highlight this &only" command {flist_hl 1}}
+ {mc "E&xternal diff" command {external_diff}}
+ {mc "&Blame parent commit" command {external_blame 1}}
}
$flist_menu configure -tearoff 0
}
@@ -3414,8 +3414,8 @@ proc showview {n} {
set curview $n
set selectedview $n
- .bar.view entryconf [mca "Edit view..."] -state [expr {$n == 0? "disabled": "normal"}]
- .bar.view entryconf [mca "Delete view"] -state [expr {$n == 0? "disabled": "normal"}]
+ .bar.view entryconf [mca "&Edit view..."] -state [expr {$n == 0? "disabled": "normal"}]
+ .bar.view entryconf [mca "&Delete view"] -state [expr {$n == 0? "disabled": "normal"}]
run refill_reflist
if {![info exists viewcomplete($n)]} {
@@ -7361,9 +7361,9 @@ proc rowmenu {x y id} {
} else {
set menu $fakerowmenu
}
- $menu entryconfigure [mca "Diff this -> selected"] -state $state
- $menu entryconfigure [mca "Diff selected -> this"] -state $state
- $menu entryconfigure [mca "Make patch"] -state $state
+ $menu entryconfigure [mca "Diff &this -> selected"] -state $state
+ $menu entryconfigure [mca "Diff &selected -> this"] -state $state
+ $menu entryconfigure [mca "Make &patch"] -state $state
tk_popup $menu $x $y
}
@@ -10184,8 +10184,8 @@ if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd ne {}} {
set viewperm(1) 0
set vdatemode(1) 0
addviewmenu 1
- .bar.view entryconf [mca "Edit view..."] -state normal
- .bar.view entryconf [mca "Delete view"] -state normal
+ .bar.view entryconf [mca "&Edit view..."] -state normal
+ .bar.view entryconf [mca "&Delete view"] -state normal
}
if {[info exists permviews]} {
--
1.6.0.2.308.gef4a
^ permalink raw reply related
* Re: "git checkout: --track and --no-track require -b" check accidentally resurrected?
From: Junio C Hamano @ 2008-10-19 22:15 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1224377652.19061.12.camel@mattlaptop2.local>
Matt McCutchen <matt@mattmccutchen.net> writes:
> Merge commit 9ba929ed resurrected the following two-line check, which
> was removed in the first parent and unchanged in the second:
>
> if (!opts.new_branch && (opts.track != git_branch_track))
> die("git checkout: --track and --no-track require -b");
>
> Is this intentional? Does it make a difference?
>
> (I noticed this while carefully examining 9ba929ed to find out why "git
> merge" stopped honoring merge.conflictstyle. Ironically, I hit this bug
> again during the examination.)
Again, good eyes. I think the two lines should go; my fault at cdb22c4
(Merge branch 'jc/better-conflict-resolution' into next, 2008-09-02).
Thanks.
^ permalink raw reply
* Is XDL_MERGE_ZEALOUS too zealous (or maybe not zealous enough)?
From: Junio C Hamano @ 2008-10-19 22:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Matt McCutchen
In-Reply-To: <7vhc785izq.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Again, good eyes. I think the two lines should go; my fault at cdb22c4
> (Merge branch 'jc/better-conflict-resolution' into next, 2008-09-02).
Hmm, I am somewhat unhappy. If you run:
$ git checkout cdb22c4^
$ git merge cdb22c4^2
$ git checkout --conflict=diff3 builtin-checkout.c
and look at builtin-checkout.c. You will find this:
<<<<<<< ours
/* --track without -b should DWIM */
if (0 < opts.track && !opts.new_branch) {
const char *argv0 = argv[0];
...
opts.new_branch = argv0 + 1;
}
if (opts.track == BRANCH_TRACK_UNSPECIFIED)
opts.track = git_branch_track;
|||||||
if (!opts.new_branch && (opts.track != git_branch_track))
die("git checkout: --track and --no-track require -b");
=======
if (conflict_style) {
opts.merge = 1; /* implied */
git_xmerge_config("merge.conflictstyle", conflict_style, NULL);
}
if (!opts.new_branch && (opts.track != git_branch_track))
die("git checkout: --track and --no-track require -b");
>>>>>>> theirs
The two lines in the middle was from the common ancestor, which was not
touched by the merged branch (that added the "if (conflict_style) {}"
block) and was lost by a rewrite in "ours".
However, the usual simplified merge shows this (run "git checkout --merge
builtin-checkout.c" if you have done the above):
<<<<<<< ours
/* --track without -b should DWIM */
if (0 < opts.track && !opts.new_branch) {
const char *argv0 = argv[0];
...
opts.new_branch = argv0 + 1;
}
if (opts.track == BRANCH_TRACK_UNSPECIFIED)
opts.track = git_branch_track;
=======
if (conflict_style) {
opts.merge = 1; /* implied */
git_xmerge_config("merge.conflictstyle", conflict_style, NULL);
}
if (!opts.new_branch && (opts.track != git_branch_track))
die("git checkout: --track and --no-track require -b");
>>>>>>> theirs
Removing the two lines from the simplified "theirs" is not what I would
suggest (it would be actively wrong), but I wonder if we can do something
clever to help users with a merge like this.
^ permalink raw reply
* Re: Usability of git stash
From: Stephan Beyer @ 2008-10-19 23:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Anders Melchiorsen, Brandon Casey, David Kastrup, git
In-Reply-To: <20081019184029.GF14786@spearce.org>
Hi,
Shawn O. Pearce wrote:
> Personally I wish git-stash wasn't invented the way it is. I would
> have rather seen it as macros to do a quick:
>
> git commit -m wip-index-state
> git commit -A -m wip-worktree-state
>
> and unwind it with essentially:
>
> git reset --mixed HEAD^
> git reset --soft HEAD^
>
> then its a lot less black magic to users, as they can see it in the
> DAG, and its more explicitly tied to the branch they were on at the
> time they ran the stash. I think its rare you'd stash something
> then switch to another branch to apply it. But that could easily
> be done with cherry-pick.
Just a side note:
I, for example, have a stash in which some "valgrind ..." string is
prepended to some lines in some test scripts. I apply the stash on
different branches and after testing I reset the file (or checkout -f
another branch). I never really want to commit these changes.
So, the alternative for this use case (if there was no git-stash) is
to have a "valgrind" branch somewhere and do some "cherry-pick -n" of
those commits, right?
Hmm, it seems that this is the better way in the long run. But
"git-stash" seemed to be the natural way at first.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH v2] Add command line option --chdir/-C to allow setting git process work directory.
From: Maciej Pasternacki @ 2008-10-19 23:13 UTC (permalink / raw)
To: git
In-Reply-To: <0B4A1BD5-5FC3-4B29-B0BB-77A85AEDF5B2@pasternacki.net>
On 2008-10-19, at 23:02, Jeff King wrote:
> I took a closer look at this. I'm not sure that there is actually a
> problem with moving the cd_to_toplevel before require_work_tree.
> cd_to_toplevel makes sure there is actually something to cdup to. In
> my
> test without a work-tree, "git rev-parse --show-cdup" simply printed
> nothing, causing no "cd" to occur.
I won't speculate on whether moving cd_to_toplevel up will introduce
problem or not. I am not familiar with git internals, and I just
repeat an opinion gathered on #git. However, -C seem to be better
suited for simple cases, conceptually cleaner, and may make the
learning curve a bit less steep. There is no need for consdering all
possible --work-tree/--git-dir combinations and their implications, it
is possible just to say "cd there, and act as usual".
> So:
>
> 1. I think we can fix this breakage by swapping the two.
I can prepare a patch if that's expected, but probably I won't
understand what it exactly does and what are implications of this
change.
> 2. There is still breakage in other scripts, some of which may need
> quite in-depth fixes (e.g., git-bisect requires a work tree but
> does not chdir at all. For the require_work_tree test to work, it
> needs to be inside the work tree, and the script will need a
> careful looking over to see what ramifications that has).
I really don't think I'm competent enough to fix more complex cases
without breaking twice as many things; I don't feel confident even
with a simple swap in git-pull at the moment
> 3. I think your -C option has some merit independent of this, since
> it allows you to chdir and still use the usual lookup rules (e.g.,
> see if it is bare vs a regular repository). But I don't feel
> strongly about it one way or the other.
In my use case, it definitely has merits as it makes git behave
exactly as if user himself wrote "git pull" inside the work tree, and
I am still not sure wheter expected --work-tree/--git-dir combinations
would behave the same. Probably I'll need to add more commands and
more complex use cases as I develop cl-librarian, and -C would make
this job way easier.
Regards,
Maciej.
--
-><- Maciej Pasternacki -><- http://www.pasternacki.net/ -><-
^ permalink raw reply
* Re: [PATCH v2] Fix testcase failure when extended attributes are in use
From: Deskin Miller @ 2008-10-19 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, heikki.orsila
In-Reply-To: <7viqro73w5.fsf@gitster.siamese.dyndns.org>
On Sun, Oct 19, 2008 at 12:59:06PM -0700, Junio C Hamano wrote:
> Deskin Miller <deskinm@umich.edu> writes:
>
> > My patch, on the other hand, is to deal with 'ls' output in case a file has
> > certain filesystem extended attributes. These could be e.g. POSIX ACLs, or a
> > SELinux security context, or perhaps others. If such an extended attribute is
> > present, 'ls -l' will print permissions with a '+' appended, e.g.
> > -rw-r--r--+
> > Instead of
> > -rw-r--r--
> > ...
> > For what it's worth, I've experienced this failure on my Ubuntu 8.04 laptop
> > with SELinux permissive mode, so it's possible ls behaves slightly differently
> > on other systems; I've not been able to determine this one way or another.
>
> Is there way to explicitly tell "ls -l" not to do this, I have to wonder?
I looked through all the options to ls several times, and there wasn't anything
which stood out to me. The output format of ls is rather rigid.
> POSIX.1 says that the file mode written under the -l option is
> "%c%s%s%s%c" (where the first %c is for type, three %s are for owner,
> group and other perm, and the last %c is "optional alternate access method
> flag"). If there is no alternate or additional access control method
> associated with the file, the "optional alternate access method flag"
> would be a single SP, otherwise it would be a printable character.
My fault for not reading up more carefully. In that case, yes, I agree that we
should be able to deal with any such flag character, which my patch does not
do.
> If we drop the default ACL from the trash directory like Matt's patch
> does, does a file created in there (i.e. the ones we check with /bin/ls)
> still have "alternate or additional access control method associated with"
> it?
Yes. SELinux, in particular, associates a 'security context' with *every*
file, which is used in SELinux access control checks. This is stored as a
filesystem extended attribute in the 'security.selinux' namespace, and one will
exist from the moment the file is created.
One could dream up other access control methods, such as a kernel module which
would deny access to any files with the string 'frob' in the filename, and
suppose that ls could be extended to recognise the presence of this module and
alter its display accordingly. There is clearly no way to ensure that no
'alternate or additional access control method' is associated with a file,
since the POSIX.1 language is sufficiently general to allow for almost
anything.
> Somehow it feels wrong that you need your patch, but if you do, stripping
> only the trailing '+' as your patch does not look sufficient, either.
> Shouldn't we be stripping the last letter if the length of actual is
> longer than strlen("-rwxrwxrwx"), as any printable can come there?
I hope I've made the case for the necessity of a patch (if nothing else, t1301
fails 10/16 tests on my system without some sort of patch), and I'll happily
agree that stripping any printable is a better choice. Thanks for the
feedback; FWIW, your suggested patch here is
Tested-by: Deskin Miller <deskinm@umich.edu>
> t/t1301-shared-repo.sh | 10 ++++++----
> 1 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git c/t/t1301-shared-repo.sh i/t/t1301-shared-repo.sh
> index 2275caa..653362b 100755
> --- c/t/t1301-shared-repo.sh
> +++ i/t/t1301-shared-repo.sh
> @@ -20,6 +20,10 @@ test_expect_success 'shared = 0400 (faulty permission u-w)' '
> test $ret != "0"
> '
>
> +modebits () {
> + ls -l "$1" | sed -e 's|^\(..........\).*|\1|'
> +}
> +
> for u in 002 022
> do
> test_expect_success "shared=1 does not clear bits preset by umask $u" '
> @@ -85,8 +89,7 @@ do
>
> rm -f .git/info/refs &&
> git update-server-info &&
> - actual="$(ls -l .git/info/refs)" &&
> - actual=${actual%% *} &&
> + actual="$(modebits .git/info/refs)" &&
> test "x$actual" = "x-$y" || {
> ls -lt .git/info
> false
> @@ -98,8 +101,7 @@ do
>
> rm -f .git/info/refs &&
> git update-server-info &&
> - actual="$(ls -l .git/info/refs)" &&
> - actual=${actual%% *} &&
> + actual="$(modebits .git/info/refs)" &&
> test "x$actual" = "x-$x" || {
> ls -lt .git/info
> false
^ permalink raw reply
* Re: Usability of git stash
From: Jeff King @ 2008-10-20 0:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Anders Melchiorsen, Brandon Casey, David Kastrup, git
In-Reply-To: <20081019184029.GF14786@spearce.org>
On Sun, Oct 19, 2008 at 11:40:30AM -0700, Shawn O. Pearce wrote:
> Ditto. I never use "git stash". Its command line usage is too
> unfriendly for me, so I tend to prefer making WIP commits. If I
> need to stash something I'll do:
>
> git commit -a -m wip
> ... some time later ..
> git checkout branch
> git reset --soft HEAD^
That's what I do, too, except when I want to move changes from one
branch to another, or split some changes from their history. So
something like:
git checkout next ;# which is where I usually am anyway
hack hack hack
# oops, I have been building this directly on top of next and it
# really needs to be a feature-branch on maint
git stash
git checkout -b jk/maint-fix-whatever origin/maint
git stash apply
The equivalent non-stash commands would be "commit -m wip" and
"cherry-pick". But the stash saves me the trouble later of having to
delete the wip cruft on top of next.
Side note: obviously this uses the stash only as a push/pop stack. I
have never personally had a situation where I wanted a named stash or
multiple stashes over a wip commit.
> Personally I wish git-stash wasn't invented the way it is. I would
> have rather seen it as macros to do a quick:
>
> git commit -m wip-index-state
> git commit -A -m wip-worktree-state
>
> and unwind it with essentially:
>
> git reset --mixed HEAD^
> git reset --soft HEAD^
I disagree. I think the strength of stash is that it is divorced from
the history. So it is more like a cherry-pick (or diff | apply, which is
what it was intended to replace).
> time they ran the stash. I think its rare you'd stash something
> then switch to another branch to apply it. But that could easily
> be done with cherry-pick.
I guess we are viewing the tool oppositely. :)
-Peff
^ permalink raw reply
* Re: Is XDL_MERGE_ZEALOUS too zealous (or maybe not zealous enough)?
From: Matt McCutchen @ 2008-10-20 3:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v3ais5hb3.fsf_-_@gitster.siamese.dyndns.org>
On Sun, 2008-10-19 at 15:52 -0700, Junio C Hamano wrote:
> However, the usual simplified merge shows this (run "git checkout --merge
> builtin-checkout.c" if you have done the above):
>
> <<<<<<< ours
> /* --track without -b should DWIM */
> if (0 < opts.track && !opts.new_branch) {
> const char *argv0 = argv[0];
> ...
> opts.new_branch = argv0 + 1;
> }
>
> if (opts.track == BRANCH_TRACK_UNSPECIFIED)
> opts.track = git_branch_track;
> =======
> if (conflict_style) {
> opts.merge = 1; /* implied */
> git_xmerge_config("merge.conflictstyle", conflict_style, NULL);
> }
>
> if (!opts.new_branch && (opts.track != git_branch_track))
> die("git checkout: --track and --no-track require -b");
> >>>>>>> theirs
>
> Removing the two lines from the simplified "theirs" is not what I would
> suggest (it would be actively wrong), but I wonder if we can do something
> clever to help users with a merge like this.
IMHO, the solution is just to use diff3 style. I never understood how I
was supposed to intuit the correct result of a merge from the two sides
without seeing the common ancestor, so I am glad to have the diff3 style
working now.
Matt
^ permalink raw reply
* Re: [PATCH] -C/--chdir command line option
From: Junio C Hamano @ 2008-10-20 4:55 UTC (permalink / raw)
To: Jeff King; +Cc: Maciej Pasternacki, git
In-Reply-To: <20081019141634.GA8997@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Oct 19, 2008 at 03:47:04PM +0200, Maciej Pasternacki wrote:
>
>> As for -C being superfluous: --git-dir and --work-tree seem to support
>> weird usage patterns (like work tree separate from git-dir), but it seems
>
> Hmm. Yeah, thinking about it more, -C is not really superfluous with
> respect to those options. You don't want to say "here is the work-tree,
> and here is the git-dir". You want to say "find the work-tree and
> git-dir for me using the usual rules, as if I were in this directory."
I think that interpretation of -C, if the option existed, makes sense, but
I do not understand why the tool that drives git refuses to chdir to the
repository for itself in the first place.
The only excuse I remember seeing in the thread was that "make has '-C'
option, so let's have it, because it is similar", which does not justfiy
addition of that option to git at all to me.
With "make", the -C option can be justified as a necessary tool to write a
recursive Makefile that can be sanely and easily processed without
actually executing any commands (iow, imaging implementing "make" that
allows you to write "cd there && $(MAKE)" in the toplevel Makefile and
tells the users what would happen in "there" when run as "make -n").
And even in "make" context, not all implementations have it. I think it
is only GNU and fairly recent BSDs.
^ permalink raw reply
* Re: Usability of git stash
From: Miles Bader @ 2008-10-20 5:23 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: Brandon Casey, David Kastrup, git
In-Reply-To: <87prly5k5r.fsf@cup.kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> I wonder whether experienced users even use stash a lot. Personally,
> after getting my head around the DAG, and thus getting more
> comfortable with git reset, I tend to make "WIP" commits instead.
I certainly do, and my impression is that some of the biggest boosters
of stash have always been the git heavy hitters (it's certainly not one
of these "implemented due to nagging by newbies" features)...
-Miles
--
Liberty, n. One of imagination's most precious possessions.
^ permalink raw reply
* Re: Usability of git stash
From: Junio C Hamano @ 2008-10-20 5:29 UTC (permalink / raw)
To: Jeff King
Cc: Shawn O. Pearce, Anders Melchiorsen, Brandon Casey, David Kastrup,
git
In-Reply-To: <20081020003644.GA10412@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> git checkout next ;# which is where I usually am anyway
> hack hack hack
> # oops, I have been building this directly on top of next and it
> # really needs to be a feature-branch on maint
> git stash
> git checkout -b jk/maint-fix-whatever origin/maint
> git stash apply
>
> The equivalent non-stash commands would be "commit -m wip" and
> "cherry-pick". But the stash saves me the trouble later of having to
> delete the wip cruft on top of next.
The equivalent would be:
git checkout -m -b jk/maint-fix-whatever origin/maint
no need for stash, wip-commit, nor cherry-pick.
The advantage of using "stash then stash apply" (not "stash pop") or
"wip-commit with cherry-pick" is that you can reset, take a deep breath,
and redo it, when the resulting merge conflict gets too hairy.
> I disagree. I think the strength of stash is that it is divorced from
> the history. So it is more like a cherry-pick (or diff | apply, which is
> what it was intended to replace).
I agree with you; it really is the "diff saved somewhere, later applied".
^ permalink raw reply
* Re: [PATCH] -C/--chdir command line option
From: Junio C Hamano @ 2008-10-20 5:41 UTC (permalink / raw)
To: Jeff King; +Cc: Maciej Pasternacki, git
In-Reply-To: <7vr66b50gy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The only excuse I remember seeing in the thread was that "make has '-C'
> option, so let's have it, because it is similar", which does not justfiy
> addition of that option to git at all to me.
Just after having said that "make has it, so let's have it ourselves, too"
is a non-excuse to any feature bloat, one thing I could accept a patch to
imitate what "make" does, especially if we are going to actually clean up
the startup sequence like we have discussed sometime ago to fix breakage
around --work-tree, is to have VAR=VAL (e.g. "make CFLAGS=-O2") on the
command line. We could use that syntax to allow configuration variables
to be overridden, like so:
$ git core.whitespace=cr-at-eol log -p master..next
I wouldn't however suggest allowing the syntax to set environment
variables, like:
$ git GIT_AUTHOR_NAME="A U Thor" commit
as this is something your shell lets you do easily, i.e:
$ GIT_AUTHOR_NAME="A U Thor" git commit
But overriding some configuration variables for a single command
invocation is not something you can do without actually editing the
configuration file for some variables, so the former would be justified.
^ permalink raw reply
* Re: [PATCH v2] Fix testcase failure when extended attributes are in use
From: Junio C Hamano @ 2008-10-20 5:52 UTC (permalink / raw)
To: Deskin Miller; +Cc: git, heikki.orsila
In-Reply-To: <20081019234723.GB2015@riemann.deskinm.fdns.net>
Deskin Miller <deskinm@umich.edu> writes:
> I hope I've made the case for the necessity of a patch (if nothing else, t1301
> fails 10/16 tests on my system without some sort of patch), and I'll happily
> agree that stripping any printable is a better choice. Thanks for the
> feedback; FWIW, your suggested patch here is
>
> Tested-by: Deskin Miller <deskinm@umich.edu>
Thanks. Applied to 'maint' and will appear in the next pushout (but not
tonight).
^ permalink raw reply
* Re: Archiving tags/branches?
From: Pete Harlan @ 2008-10-20 6:14 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20810171950j9ab85bfi6eddca167f86fda2@mail.gmail.com>
David Symonds wrote:
> On Sat, Oct 18, 2008 at 12:43 PM, Pete Harlan <pgit@pcharlan.com>
> wrote:
>> Hi,
>>
>> I'm looking for a way to manage an ever-growing list of tags. I've
>> read some git docs, but am new to git and wonder if the below
>> method doesn't work or if there's a standard practice I haven't run
>> into.
>>
>> Most of the tags in my repo are uninteresting to look at, but can't
>> be deleted. (Code releases for the most part, or stalled topic
>> branches.) If I wanted to archive those, it looks like this would
>> work:
>
> Is it really true that they can't be deleted? The only reason to
> avoid it might be for preventing Git's GC from cleaning them up, but
> if all your branches/tags are reachable via "interesting"
> branches/tags then you could just slap the tag name and SHA1 in a
> text file somewhere.
>
>
> Dave.
Thank you for your response. The tags aren't reachable; they're
dead-end branches.
Our development history looks like this:
o---o---o---o---o---o---o---o---o---o---o---o---o---o master
\ \ \
o---o---o r1.0 o---o---o r1.1 o---o---o r1.2
with releases branched off the development line and stabilized during
QA. Fixes into the release branches are cherry-picked out of master,
with no merges.
With a new release every few weeks, the tags pile up.
(There are workflows, such as git.git's, where the release tags form one
long line of development, and when we start using git we may use a
different workflow, but the above was our svn workflow, for the
obvious reason that svn doesn't understand merges. We're going to
import hundreds of such branches in the conversion to git; most such
names are noise, but we don't want to lose the history.)
I would think a built-in feature for archiving refs would be useful to
other projects, even when the tags/branches are reachable and therefore
one could manually stash them in a file. Getting the design right is
tricky because there are a lot of different ways to approach it, but the
idea seems generally useful to me.
One direction would be to support directory commands for tags, using
refs/tags and refs/branches as the root directories of trees. (This was
the solution in svn, which naturally supports a hierarchy of branches.)
Another would be to have a regexp for hiding tags/branches with a
certain pattern (e.g., leading '.'). What I'll probably do in the short
term is write an alias that lists the most recent 10 tags and use that
most of the time.
--Pete
^ permalink raw reply
* Re: [PATCH] -C/--chdir command line option
From: Alex Riesen @ 2008-10-20 6:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Maciej Pasternacki, git
In-Reply-To: <7vhc774ydr.fsf@gitster.siamese.dyndns.org>
2008/10/20 Junio C Hamano <gitster@pobox.com>:
> Junio C Hamano <gitster@pobox.com> writes:
> I wouldn't however suggest allowing the syntax to set environment
> variables, like:
>
> $ git GIT_AUTHOR_NAME="A U Thor" commit
>
> as this is something your shell lets you do easily, i.e:
>
> $ GIT_AUTHOR_NAME="A U Thor" git commit
>
No, someplace else it doesn't (yes, windows again).
It is mostly hard to do there, because the system shell is so
primitive, and installation of something sane (sh or env) is
an additional (and hard to explain to windows zealots) hassle.
And even in something like Perl it is hard: you cannot
change the environment just for the child process, you
have to change your own, run the process and change
it back.
So, yes, I like your suggestion, but I'd like to _include_
setting all the Git's environment.
^ permalink raw reply
* Re: Archiving tags/branches?
From: Pete Harlan @ 2008-10-20 6:36 UTC (permalink / raw)
To: Johan Herland; +Cc: git, SZEDER Gábor
In-Reply-To: <200810181532.59883.johan@herland.net>
Johan Herland wrote:
> BTW, the best way IMHO to archive old refs is to clone your repo (with all
> tags/branches) to a backup disk, and then regularly push (git push --all &&
> git push --tags) your new tags/branches to this backup. You are now free to
> delete these tags/branches from your work repo (they will not be deleted
> from the backup unless you use "git push --mirror"). And if you ever need
> to retrieve an old tag/branch, it's just a matter of pulling it from the
> backup repo. Nice, clean, flexible, and requires no changes to git.
>
>
> Have fun! :)
>
> ...Johan
Hi,
Thank you; that indeed seems to work and solves the problem of managing
refs/archived-tags manually.
Using a secondary repo solely to overcome a flat tag/branch namespace
feels hackish. Perhaps git will benefit someday from work in this area,
but until I come up with a patch your suggestion should work fine. Just
knowing I didn't overlook an existing feature helps a lot.
--Pete
^ permalink raw reply
* Re: [PATCH] -C/--chdir command line option
From: Maciej Pasternacki @ 2008-10-20 7:28 UTC (permalink / raw)
To: git
In-Reply-To: <DDFCD680-C477-4BE5-AB71-3F26048E26D1@pasternacki.net>
On 2008-10-20, at 06:55, Junio C Hamano wrote:
>>> As for -C being superfluous: --git-dir and --work-tree seem to
>>> support
>>> weird usage patterns (like work tree separate from git-dir), but
>>> it seems
>>
>> Hmm. Yeah, thinking about it more, -C is not really superfluous with
>> respect to those options. You don't want to say "here is the work-
>> tree,
>> and here is the git-dir". You want to say "find the work-tree and
>> git-dir for me using the usual rules, as if I were in this
>> directory."
>
> I think that interpretation of -C, if the option existed, makes
> sense, but
> I do not understand why the tool that drives git refuses to chdir to
> the
> repository for itself in the first place.
The tool (a) manages many repositories, and I don't want to chdir()
back and forth, (b) should be able to manage those repositories not
disturbing anything other. It comes as a Common Lisp library, which
will usually be called by end user, but can also be called
programmatically, and I wouldn't want any library to change my cwd; it
could chdir() back, of course, but this would still be a race
condition if other threads were running at the same time.
And there is the Lisp-specific thing, that the language comes from
before Unix domination, and things as simple as changing the process'
cwd are actually nontrivial to do portably (there is equivalent of cwd
inside Lisp world, which is used by Lisp-level file access routines,
but chdir() is not in ANSI standard, is done differently by every
implementation, and would require some kind of compatibility layer).
For me, -C would make life much easier, and I gave other arguments for
it before. It would suffice if --work-tree worked with "git pull", if
-C doesn't pass, but it seems to me that -C has some merits.
Regards,
Maciej.
--
-><- Maciej Pasternacki -><- http://www.pasternacki.net/ -><-
^ permalink raw reply
* Re: Archiving tags/branches?
From: Johan Herland @ 2008-10-20 7:53 UTC (permalink / raw)
To: git; +Cc: Pete Harlan, SZEDER Gábor
In-Reply-To: <48FC26DA.10508@pcharlan.com>
On Monday 20 October 2008, Pete Harlan wrote:
> Johan Herland wrote:
> > BTW, the best way IMHO to archive old refs is to clone your repo (with
> > all tags/branches) to a backup disk, and then regularly push (git push
> > --all && git push --tags) your new tags/branches to this backup. You
> > are now free to delete these tags/branches from your work repo (they
> > will not be deleted from the backup unless you use "git push
> > --mirror"). And if you ever need to retrieve an old tag/branch, it's
> > just a matter of pulling it from the backup repo. Nice, clean,
> > flexible, and requires no changes to git.
> >
> >
> > Have fun! :)
> >
> > ...Johan
>
> Hi,
>
> Thank you; that indeed seems to work and solves the problem of managing
> refs/archived-tags manually.
>
> Using a secondary repo solely to overcome a flat tag/branch namespace
> feels hackish. Perhaps git will benefit someday from work in this area,
> but until I come up with a patch your suggestion should work fine. Just
> knowing I didn't overlook an existing feature helps a lot.
>From reading your other emails, I get the feeling that I'm in a similar
situation at $dayjob (i.e. converting ~9 years of development history from
CVS to Git). We have literally tens of thousands of tags (mostly build and
release tags) in some of our repos, and keeping all these tags in our daily
work repos is simply unwieldy and impractical. We therefore plan to have
official reps which only contain the most important tags, and
have "archive" repos in a different location that contain all the other
tags.
You seem to want to keep all your tags in the work repo, but in a
separate/hidden namespace, so that they don't clutter the default tag
listings. IMHO, once you get into thousands of tags, cloning and other
operations where all refs are synchronized become annoyingly slow (although
things are certainly somewhat better in v1.6). At that point, my only
advice is to keep the lesser-used tags in separate repos, and pull each ref
into your work repos on-demand, especially when most of these tags will
probably never be referenced.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [BUG?] Fail to pull from kernel.org: pack has bad object
From: Johan Herland @ 2008-10-20 8:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Hi,
Currently I get the following error when trying to pull from git.git at
kernel.org:
$ git pull
remote: Counting objects: 279, done.
remote: Compressing objects: 100% (78/78), done.
remote: Total 177 (delta 136), reused 135 (delta 99)
Receiving objects: 100% (177/177), 66.59 KiB | 59 KiB/s, done.
fatal: pack has bad object at offset 53487: failed to apply delta
fatal: index-pack failed
For reference, here's the relevant part of .git/config:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/origin/*
I using a recent "next" version: 1.6.0.2.767.g8f0e
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [BUG?] Fail to pull from kernel.org: pack has bad object
From: Thomas Rast @ 2008-10-20 8:26 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200810201010.29173.johan@herland.net>
[-- Attachment #1: Type: text/plain, Size: 746 bytes --]
Jonathan Herland wrote:
>
> Currently I get the following error when trying to pull from git.git at
> kernel.org:
>
> $ git pull
> remote: Counting objects: 279, done.
> remote: Compressing objects: 100% (78/78), done.
> remote: Total 177 (delta 136), reused 135 (delta 99)
> Receiving objects: 100% (177/177), 66.59 KiB | 59 KiB/s, done.
> fatal: pack has bad object at offset 53487: failed to apply delta
> fatal: index-pack failed
I just had the same, panicked, then compiled 'maint' and the fetch
worked. Unfortunately I wasn't awake enough to make a copy of the
repo. Maybe you can make one, then use it to bisect the problem
between maint and next...
- Thomas
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* bug: git-stash save and symbolic links
From: Simon Strandgaard @ 2008-10-20 8:34 UTC (permalink / raw)
To: git
git-stash cannot find the repository when the path is a symbolic link.
solution for me was to cd to the absolute path and then do git-stash.
FAILURE: git-stash with symbolic link.
prompt> pwd
/Users/neoneye/st
prompt> ls -la ~/st
lrwxr-xr-x 1 neoneye neoneye 38 10 Okt 07:40 /Users/neoneye/st ->
/Users/neoneye/git/code/source_toolbox
prompt> git-stash
fatal: Not a git repository
fatal: Not a git repository
fatal: Not a git repository
You do not have the initial commit yet
prompt>
SUCCESS: git-stash without symbolic link.
prompt> pwd
/Users/neoneye/git/code
prompt> ls -la
drwxr-xr-x 16 neoneye neoneye 544 20 Okt 10:18 .git
drwxr-xr-x 29 neoneye neoneye 986 16 Okt 13:04 source_toolbox
prompt> git stash save "did I mess up"
Saved working directory and index state "On master: did I mess up"
HEAD is now at 90ac45d we can now seek through a WAV file.. finally.
prompt>
I think the problem is located in the save_stash() function, but
im not good at sh scripting to make a patch.
Thank you very much for git!
--
Simon Strandgaard
http://toolboxapp.com/
^ permalink raw reply
* Re: Usability of git stash
From: Miles Bader @ 2008-10-20 9:36 UTC (permalink / raw)
To: Stephan Beyer
Cc: Shawn O. Pearce, Anders Melchiorsen, Brandon Casey, David Kastrup,
git
In-Reply-To: <20081019231239.GA23692@leksak.fem-net>
Stephan Beyer <s-beyer@gmx.net> writes:
> I, for example, have a stash in which some "valgrind ..." string is
> prepended to some lines in some test scripts. I apply the stash on
> different branches and after testing I reset the file (or checkout -f
> another branch). I never really want to commit these changes.
I'd just use an appropriate patch file kept around in a parent dir or
something... :-)
-Miles
--
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like. Otherwise the
programs they write will be pretty weird. -- Donald Knuth
^ permalink raw reply
* Re: Usability of git stash
From: Andreas Ericsson @ 2008-10-20 9:49 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: Brandon Casey, David Kastrup, git
In-Reply-To: <87prly5k5r.fsf@cup.kalibalik.dk>
Anders Melchiorsen wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> In exchange for allowing new users to stub their toe on new commands, the
>> work flow of more experienced users is made a little easier.
>
> I wonder whether experienced users even use stash a lot. Personally,
> after getting my head around the DAG, and thus getting more
> comfortable with git reset, I tend to make "WIP" commits instead.
>
I use stash quite a lot. It's useful for me because my co-workers
sometimes pull from me so I cannot use 'wip' commits (without annoying
my co-workers anyway).
> After having used "git stash clear" at a bad time once, I am wary of
> stashing work that I actually want to keep. I prefer workflows where
> my mistakes can be (easily) corrected.
>
I never use "stash clear", but always do "stash pop", so my stash-stack
is hardly ever deeper than one. It would be a lot worse for us to get a
"wip" commit accidentally propagated and built on further. It's happened
and it's no fun what so ever as it requires team coordination and rewrite
of published history to get it back to a good state.
>
> The primary thing that stash does for me is preserve the index state.
> Unfortunately, --index is not default for stash apply, so I often
> forget it.
>
I commit regularly enough that it doesn't take me long at all to re-do
the index changes.
> Sometimes, I also want stash to store away changes to untracked files
> (to get a clean working directory), but that is not possible.
>
git add .
git stash --index
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Andreas Ericsson @ 2008-10-20 9:57 UTC (permalink / raw)
To: Christian Jaeger; +Cc: Garry Dolley, Richard Hartmann, git
In-Reply-To: <48F9EC2B.2010200@jaeger.mine.nu>
Christian Jaeger wrote:
> Garry Dolley wrote:
>> On Thu, Oct 16, 2008 at 10:32:56PM +0200, Christian Jaeger wrote:
>>
>>> Hm, I don't see a fundamental technical problem which would prevent
>>> one from implementing the ability to checkout only a subdirectory
>>> into the working directory (i.e. to add options to Git to make it
>>> reflect the working directory as being a subdirectory of what is in
>>> Git's database). At this level I don't see anything inherently
>>> different from SVN--except maybe for directory renames: if someone
>>> else is renaming the directory you've checked out, what should
>>> happend with your checkout? Git's filebased rename tracking would
>>> just lead to everything vanishing from your checkout. I don't know
>>> what happens in SVN, maybe it keeps track of the directory rename and
>>> still sends you the changes of the directory you've checked out even
>>> if it has now a different name on the server?
>>>
>>> Anyway, an unavoidable difference is that you have to always clone
>>> the whole Git *database*. With SVN the database stays on the server,
>>> with Git it is being cloned. Just as I expect SVN to need the whole
>>> database to be [...]
>>>
>>
>> Right, but I think cloning the entire git database just to get a
>> subdir is a fundamental technical problem. It's no different than
>> git-clone + checkout + rm -rf <what I don't want in working tree>
>>
>
> We're in "violent agreement" here.
>
>> In that sense, git already has support for cloning subdirectories,
>> which is why I don't think this method applies to what the original
>> post author meant when they referred to "support for cloning sub
>> directories".
>>
>
> I just think it's worth pointing out the difference between the working
> dir and the database. It should be as easy to implement checking out
> subdirectories in Git as it was in SVN (except, again, that, iff
> directory renames should be tracked, some code would have to be written
> to find out about directory renames, which SVN solves in a simpler way
> by just requiring that the user specifies renames explicitely). It's
> worth pointing out that working directory checkouts and database cloning
> are separate operatoins and it's only the database cloning which is, per
> definition (as it is a distributed VCS) different from SVN.
>
>> :)
>>
>
> If you really wanted, I suppose you could additionally look into
> implementing a kind of shallow cloning that only copies objects over the
> wire which are necessary for representing the subdirectory you're
> interested in.
>
So what do you do when one such commit also affects something outside
the subdirectory?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 1/3] add alloc_ref_with_prefix()
From: Andreas Ericsson @ 2008-10-20 10:34 UTC (permalink / raw)
To: Bert Wesarg; +Cc: René Scharfe, Git Mailing List, Junio C Hamano
In-Reply-To: <36ca99e90810180507q2dedf4ck7262239ae91d892f@mail.gmail.com>
Bert Wesarg wrote:
> On Sat, Oct 18, 2008 at 11:39, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>>>> +static struct ref *alloc_ref_with_prefix(const char *prefix, size_t prefixlen,
>>>> + const char *name)
>>>> +{
>>>> + size_t len = strlen(name);
>>>> + struct ref *ref = xcalloc(1, sizeof(struct ref) + prefixlen + len + 1);
>>>> + memcpy(ref->name, prefix, prefixlen);
>>>> + memcpy(ref->name + prefixlen, name, len);
>>> Where does you \0-terminate the string?
>> xcalloc() calls calloc(), which zeroes the memory.
> So, you write the memory range twice, just for the last \0?
>
calloc() doesn't do the zeroing pass if it gets memory from the kernel,
which guarantees that the memory is already zeroed out. In reality,
calloc() usually saves on both readability and performance over
explicitly nul-terminating strings.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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