"gitx ." in terminal startup with a history tree, where no tree should be
Reported by ronin-45124 (at lighthouseapp) | January 27th, 2009 @ 01:11 PM
as a textmate user i often start gitx like textmate in terminal ("mate ." which load the current directory as project). since gitx doesn't need this, my "failure" load the branch ".", which result in an strange history view. maybe a path parameter for gitx terminal usage is possible as default and the branch load move to a -b parameter.
Comments and changes to this ticket
-
Johannes Gilger January 27th, 2009 @ 02:01 PM
Hm, although I've never used . as a ref-spec I tried it now, and using git, gitk and gitx gives me the same output (i.e. the same ref). So, since . seems to be a perfectly valid ref I see no reason to change the behaviour of gitx.
The introduction of a path parameter might be an idea nevertheless. Let's wait what Pieter responds to this ticket ;)
-
ronin-45124 (at lighthouseapp) January 27th, 2009 @ 02:25 PM
thanks for your fast comment :)
did you check a large project each with "gitx" and "gitx ."? the first i not this behavior was when scrolling down to an imported svn project without any branches down to the first commit. the history tree run out of view. i'm not sure what resource (branch) the "." represent...
another usability problem with this is that you must allways first change to your project folder to start gitx from terminal. a simple "gitx ./project/path" isn't available. it's not a no go, but a little nice to have ;)
waiting, tom ;)
-
Johannes Gilger January 27th, 2009 @ 02:52 PM
Well, I was talking bull-schlache. The dot . of course does not represent a ref-spec but a path (meaning "the current directory"), just like you can run "git log " on a path to see which commits touched that path.
So, to come back to your proposal: Adopting your approach would mean that neither a ref-spec nor a path inside the work-tree could be passed without some stupid flag (and at the same time making it hard for people who are used to git and gitk to adopt to GitX).
-
Pieter de Bie January 27th, 2009 @ 09:45 PM
- State changed from “new” to “open”
'gitx .' should do the same as 'git log .', so if it doesn't display anything, that's a bug :)
-
Johannes Gilger January 27th, 2009 @ 10:01 PM
Well, it does display the same thing as git log, thats my point. As for trying it with a big repository: Used the git repo itself.
The only thing that can be considered a bug is that "." is displayed as a branch/ref in the selector on top, though it is a path.
-
Dave Grijalva January 28th, 2009 @ 12:25 AM
git diff uses the format: git diff branch(es) -- path
This seems like it would be a good fit.
gitx branch_foo or gitx -- ../stuff/and/things or even gitx branch_foo -- ../things
That said, if the branch '.' doesn't exist, i would expect gitx to open to either all branches or the current branch.
-
Dave Grijalva January 28th, 2009 @ 12:26 AM
Looks like my formatting was swallowed up:
gitx branch_foo # or gitx -- ../stuff/and/things # or even gitx branch_foo -- ../things -
Pieter de Bie January 28th, 2009 @ 12:29 AM
you can use -- in git to disambiguate, but you don't need to. For example,
git log Documentation/shows all commits that touch the Documentation path. GitX fails in this case. I'm not sure why, but I'd guess that looking at the debug output will give an easy clue. I'm a bit tight in time right now, but I'll try to look into it later this week, unless someone beats me to it. -
ronin-45124 (at lighthouseapp) January 28th, 2009 @ 08:09 AM
ok, my point of view is:
gitx.app = desktop gui for git. if someone need git inside the terminal he should use plain git
gitx (terminal) = startup script for gitx.app from terminal. parameters ok, but what also need is a "gitx /Users//Projects/". the terminal gitx should work like the "mate" command for textmate (editor).
understand me right: its nice that the gitx command exist, but it could be more usefull and an easy path access would be a good idea.
i made to an image of my "problem": 1.png used "gitx", 2.png used "gitx .". why is on 2.png the color tree?
-
3.png
71.9 KB
-
-
Pieter de Bie January 28th, 2009 @ 09:39 PM
I'm not going to add something like "gitx path/to/project", as that could mean a wrongly typed ref or a wrongly typed path specifier within the current document.
It might be possible to add something like 'gitx -o path/to/project' as an alternative, but I'm not sure what the added value of that is.
That said, I can't reproduce your results with 'gitx' vs 'gitx .' Can you give a link to the repository? Can you try with other repositories? What version of git (and GitX) are you using?
-
ronin-45124 (at lighthouseapp) January 29th, 2009 @ 09:58 AM
i used gitx 0.6 and git 1.6.1 on macosx 10.5.6. the project was imported from an svn repository internaly. after the import i removed the svn connection. maybe the svn import is the key to reproduce this behavior. can't reproduce this for now with a git only started project.
-
Pieter de Bie March 24th, 2009 @ 01:08 AM
- State changed from “open” to “hold”
I'm going to put this on hold then until someone can provide a good testcase. There probably is a bug somewhere, but I don't have the time right now to go hunting for it myself.
-
-
-
yogi12 May 30th, 2018 @ 02:33 AM
hi there https://clashservers.net/clash-of-magic/ use this for amazing free game of clash of clans
-
-
-
-
-
3.png
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
GitX is the nice-looking gitk clone for OS X
People watching this ticket
Johannes Gilger
Pieter de Bie
Attachments
-
3.png
71.9 KB