* Re: should git download missing objects?
From: Petr Baudis @ 2006-11-14 20:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac2v6qru.fsf@assigned-by-dhcp.cox.net>
On Mon, Nov 13, 2006 at 09:22:13PM CET, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > ... Junio, what's its life
> > expectancy? I guess this usage scenario is something to take into
> > account when thinking about removing it, I know that I wanted to get rid
> > of it in the past but now my opinion is changing.
>
> It uses the same commit walker semantics and mechanism so I do
> not think it is too much burden to carry it, but I'd rather have
> something that works over git native protocol if we really care
> about this. People without ssh access needs to be able to
> recover over git:// protocol.
Even though I obviously agree with the above, it would be useful to have
the flag even though git:// (which is apparently harder to get right
than the others) is not supported. After all, most repositories I've
seen that are available over git:// are available over HTTP as well.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: when is a remote a branch?
From: Petr Baudis @ 2006-11-14 20:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Anand Kumria, git
In-Reply-To: <200611121831.18851.jnareb@gmail.com>
On Sun, Nov 12, 2006 at 06:31:18PM CET, Jakub Narebski wrote:
> Petr "Pasky" Baudis wrote:
> > Git and Cogito share the same models of branches. These branches are
> > 'heads' with commit pointers stored in refs/heads/, etc.
>
> Not exactly. "Live" branches (i.e. branches you can commit to) are head
> refs stored in refs/heads/. But in repository cloned with git-clone
> --use-separate-remotes tracking heads (tracking branches) would be at
> refs/remotes/<remotename>/. You can fetch to such a ref, but you can't
> checkout it, nor commit to it.
That was meant to be the "etc". ;-))
> > The branches/
> > directory says that some branches do not correspond to local development
> > (and should never be used for that) but instead they correspond to a
> Does that _should_ is enforced in Cogito? Is it enforced in Git?
Yes (you cannot switch to it). No (AFAIK).
> > particular branch in some remote repository. Such branches are called
> > "REMOTE BRANCHES".
>
> I'd rather call them "tracking branches", at least in git. So if there
> is branch 'localbranch' in refs/heads/ (?), and there is corresponding
> branches file branches/localbranch, which contains a single URL
> git://host.domain/path/to/repository#remotebranch
> it is AFAICU equivalent to having some remotes file, named e.g. 'repo',
> with the following contents:
> URL: git://host.domain/path/to/repository
> Pull: remotebranch:localbranch
> Push: remotebranch:localbranch
> or equivalent entry in git config.
Yes, except that the remote must be named 'localbranch'.
> > So it's "if branch X has corresponding .git/branch/X file, it's not a
> > local branch but instead a REMOTE BRANCH corresponding to the URL stored
> > in that file". That simple. The URL is address of the repository plus
> > optionally a '#branchname' if the branch name in the remote repository
> > should not default to remote HEAD or master.
>
> The whole concept of branches file (and marking some branches as "remote"
> branches) is IMHO from the times where there were most common to have one
> live branch per repository, and we fetched and pushed single branches.
> This simple picture changed with more widespread use of multiple heads,
> and with the introduction of tags (I think).
I completely agree. The original remotes implementation was messy, but
with refs/remotes/ it's simple again. Only lack of time (or laziness) on
my side is why Cogito didn't move to this yet.
> By the way, with introduction of branches and remotes in config file,
> you can say:
> [branch "localbranch"]
> remote = someremote
> [remote "someremote"]
> fetch = remotebranch:localbranch
> push = remotebranch:localbranch
>
> and that would be equivalent to example branches file from the beginning
> of this email.
According to the documentation, this is not really useful since this
just tells what should git fetch default to when on branch
"localbranch". But "localbranch" is still just a branch representing a
state in a remote repository, so you should never be _on_ it in a sane
setup, but instead on a different branch which tracks it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: when is a remote a branch?
From: Jakub Narebski @ 2006-11-14 20:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Anand Kumria, git
In-Reply-To: <20061114202835.GJ7201@pasky.or.cz>
Petr "Pasky" Baudis wrote:
> On Sun, Nov 12, 2006 at 06:31:18PM CET, Jakub Narebski wrote:
>>
>> By the way, with introduction of branches and remotes in config file,
>> you can say:
>> [branch "localbranch"]
>> remote = someremote
>> [remote "someremote"]
>> fetch = remotebranch:localbranch
>> push = remotebranch:localbranch
>>
>> and that would be equivalent to example branches file from
>> the beginning of this email.
>
> According to the documentation, this is not really useful since this
> just tells what should git fetch default to when on branch
> "localbranch". But "localbranch" is still just a branch representing a
> state in a remote repository, so you should never be _on_ it in a sane
> setup, but instead on a different branch which tracks it.
Oh. Can you "git fetch Localbranch" _without_ repository named
"localbranch" in above case?
--
Jakub Narebski
^ permalink raw reply
* Re: when is a remote a branch?
From: Petr Baudis @ 2006-11-14 20:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Anand Kumria, git
In-Reply-To: <200611142136.17517.jnareb@gmail.com>
On Tue, Nov 14, 2006 at 09:36:16PM CET, Jakub Narebski wrote:
> Petr "Pasky" Baudis wrote:
> > On Sun, Nov 12, 2006 at 06:31:18PM CET, Jakub Narebski wrote:
> >>
> >> By the way, with introduction of branches and remotes in config file,
> >> you can say:
> >> [branch "localbranch"]
> >> remote = someremote
> >> [remote "someremote"]
> >> fetch = remotebranch:localbranch
> >> push = remotebranch:localbranch
> >>
> >> and that would be equivalent to example branches file from
> >> the beginning of this email.
> >
> > According to the documentation, this is not really useful since this
> > just tells what should git fetch default to when on branch
> > "localbranch". But "localbranch" is still just a branch representing a
> > state in a remote repository, so you should never be _on_ it in a sane
> > setup, but instead on a different branch which tracks it.
>
> Oh. Can you "git fetch Localbranch" _without_ repository named
> "localbranch" in above case?
So that it would be equivalent to git fetch someremote, and also fetch
any other branches associated with that remote?
I would hope not. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Karl Hasselström @ 2006-11-14 20:46 UTC (permalink / raw)
To: Carl Worth; +Cc: Andy Whitcroft, Junio C Hamano, git
In-Reply-To: <87hcx1u934.wl%cworth@cworth.org>
On 2006-11-14 11:22:39 -0800, Carl Worth wrote:
> So, the fact that conflict resolution still requires the use of
> update-index would just be the next thing to fix. A name for a
> replacement to use there could be "git resolve <paths>", (since the
> old git-resolve is now officially deprecated). That's a name that
> matches what hg uses in this situation, (another option is
> "resolved" which is what stg uses, but I think verbs for commands
> work better in general).
Yes, "resolve" sounds better than "resolved". The latter is arguably
more correct, since you're telling git that you have already resolved
the file and not asking it to resolve it for you, but I still prefer
"resolve".
> And then, the next phase of my evil plan would be to introduce a -i
> option for git-commit making it commit the state in the index. Then
> git-commit with no options could work like "git-commit -a" does now,
> (with the additional protection of not committing any unmerged
> files---that is the new "git resolve" would be required before "git
> commit" would work after a conflict). Users who really, really like
> the current behavior of git-commit could use the new alias support
> to pass the new -i option in order to maintain compatible behavior.
Seems very sane. Default to simple behavior, and provide a switch to
get more complicated behavior.
> Then, the last thing I'd really like to fix is to allow a usage of
> "git merge <branch>" instead of the awkward "git pull . <branch>".
This should reduce newbie confusion a lot.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-14 20:52 UTC (permalink / raw)
To: Carl Worth; +Cc: Andy Whitcroft, Junio C Hamano, git
In-Reply-To: <87hcx1u934.wl%cworth@cworth.org>
On Tue, 14 Nov 2006, Carl Worth wrote:
> Anyway, now I've just gone and blown all my secret plans for changing
> git in ways to make it less intimidating for new users.
I just cannot do otherwise than cheer this with applause.
Even if I have a clear preference for GIT's _technology_, I still think
that the HG user interface is more convivial. I even been thinking
about writing something like an hg-like frontend to GIT from time to
time just so that GIT could then be better compared to (and actually
just used like) HG.
I still think that the GIT user interface sucks in many ways. The
confusion between pull, fetch and push is still my favorite, along with
the locale vs remote branch issue. Maybe we'll better handle the branch
issue eventually, but it would be so much intuitive to split branch
merging out of git-pull, and make git-pull be the same as git-fetch
(maybe deprecating git-fetch in the process) so push and pull are really
_only_ opposite of each other.
If the fetch+merge behavior (which I think should really be refered as
pull+merge) is still desirable, then it should be called git-update and
be no more than a single shell script line such as
git_pull && git_merge"
This is really what most people expect from such a command name based
on obvious historical reasons. The lack of any branch argument to
git-pull and git-merge could be defined as using the first defined
remote branch by default. But having git-pull performing merges is IMHO
overloading the word and goes against most people's expectations.
^ permalink raw reply
* [GIT PATCH] Makefile missing git-runstatus in PROGRAMS list
From: Bhavesh Davda @ 2006-11-14 20:55 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
Noticed this when trying to use qgit on Linus's kernel git repository. The
script git-status depends on git-runstatus being in the path.
Adding git-runstatus to the PROGRAMS list in the Makefile, so that it gets
installed along with the other git executables.
After a "sudo make install", qgit is now happy, since git-status is now able
to find git-runstatus in /usr/bin.
Thanks
- Bhavesh
Bhavesh P. Davda
[-- Attachment #2: git-makefile.patch --]
[-- Type: application/octet-stream, Size: 355 bytes --]
diff --git a/Makefile b/Makefile
index 36ce8cd..24a0dc7 100644
--- a/Makefile
+++ b/Makefile
@@ -202,7 +202,7 @@ PROGRAMS = \
git-upload-pack$X git-verify-pack$X \
git-pack-redundant$X git-var$X \
git-describe$X git-merge-tree$X git-imap-send$X \
- git-merge-recursive$X \
+ git-merge-recursive$X git-runstatus$X \
$(EXTRA_PROGRAMS)
# Empty...
^ permalink raw reply related
* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-14 20:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: Andy Whitcroft, Junio C Hamano, git
In-Reply-To: <20061114194707.GH7201@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]
On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:
> Hmm, did they (not) consider Cogito? They wouldn't have those issues.
I didn't ask.
Frankly, I don't see a lot of value in the git/cogito split right now.
When I first learned git and cogito (January 2006) and switched cairo
from cvs to git (the repository storage), I recommended cogito to
cairo programmers as a "more cvs-like" way to work with the new
repository.
Since then, having worked with git (the command-line program)
exclusively for my own work, and having introduced it to dozens of new
users, I don't bother recommending cogito anymore. It's just not that
hard to learn git itself, so there's not that much value in learning
cogito instead.
And this is particularly true since there's quite a large cost to
having to learn cogito _in addition to_ git. And I think that's what
most people would have to do anyway. For example, cogito doesn't wrap
all git commands. So users have to dip down into git for things like
git-bisect or else miss out an important functionality.
And for something like the Fedora transition, where I'm working with
the people who will be training the community in the new tools, the
trainers would have to learn both if they want to support a community
using both git and cogito. These trainers are already complaining
about the ~140 git commands, so adding 40 more cogito commands as well
doesn't make the story better.
It's great that git is written in a script-friendly way so that new
interfaces can be built on top of it. And I think the benefits of new
user interfaces are clear when they work in fundamentally different
ways, (say, being operated through a GUI). But where git and cogito
are both command-line utilities and have the same basic functionality,
I don't see how its helpful to maintain both tools. (Certainly some of
my attitude here is due to the timing of my introduction to git
contrasted with the timing of the inception of cogito. I'm sure git
improved a lot between those two events.)
There are some things that cogito does that git does not that I would
like to have in git. One is having a "commit" command that commits
everything by default without an extra command-line option. Another
(that I _think_ cogito has) is a way to switch away from a branch with
dirty changes to a clean branch, do work there, and come back to the
original branch with the dirty stuff still there.
I don't see any defining difference that justifies cogito's
existence ("hide the index" maybe? let's just hide it a tiny bit more
in git). And I would like to help work to get the remaining good
stuff that has been proven in cogito---to get it pushed down into git
itself.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-14 21:01 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611141518590.2591@xanadu.home>
Nicolas Pitre wrote:
> If the fetch+merge behavior (which I think should really be refered as
> pull+merge) is still desirable, then it should be called git-update and
> be no more than a single shell script line such as
>
> git_pull && git_merge"
>
> This is really what most people expect from such a command name based
> on obvious historical reasons. The lack of any branch argument to
> git-pull and git-merge could be defined as using the first defined
> remote branch by default. But having git-pull performing merges is IMHO
> overloading the word and goes against most people's expectations.
By the way, is anyone doing _remote_ octopus pull (true pull, not with . as
repository)?
We can always have --merge arguments to git-pull, and --fetch argument to
git-merge.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-14 21:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Andy Whitcroft, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611141518590.2591@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]
On Tue, 14 Nov 2006 15:52:47 -0500 (EST), Nicolas Pitre wrote:
> Even if I have a clear preference for GIT's _technology_, I still think
> that the HG user interface is more convivial. I even been thinking
> about writing something like an hg-like frontend to GIT from time to
> time just so that GIT could then be better compared to (and actually
> just used like) HG.
I've actually been tempted to do the same myself. I really think that
the technology is a more important criterion than the UI so the
imagined hg-on-git interface would be an attempt to get people to look
past the interface differences and look at the technology when
deciding.
But, then, I'd be guilty of creating another cogito, and I just argued
against its existence in a separate thread. So I think we're better
off just fixing the git interface.
> I still think that the GIT user interface sucks in many ways. The
> confusion between pull, fetch and push is still my favorite, along with
> the locale vs remote branch issue. Maybe we'll better handle the branch
> issue eventually,
The --use-separate-remotes thing is technology in the right direction
here. But I think it's another example of very useful stuff being
improperly hidden behind another command-line option. Getting rid of
the "remote-tracking branches" as user-visible branches possible for
committing should be a priority. And that should be the default for
everyone, not just people who happen to clone with this obscure
option.
Similarly, the reflog stuff was often trumpeted in the recent git
vs. bzr debate. Why is that very useful functionality buried in a
config file option and not just stored by default?
> This is really what most people expect from such a command name based
> on obvious historical reasons. The lack of any branch argument to
> git-pull and git-merge could be defined as using the first defined
> remote branch by default.
Once again, there's lots of useful work on "branch configuration" that
allows for commands to be able to get the "right" default repository
for push and pull. I hope that that stuff can be enabled by default
and not require --use-separate-remotes or manual configuration for
people to benefit from it.
I apologize if I sound like I'm ranting here. I love to see the many
good improvements being made to git. It's just that there seems to be
a sort of shyness about new features, (perhaps a fear of changing
existing behavior?). When it improves the user experience, let's make
the improvement the default and not add any more
--make-this-command-do-what-it-really-should-have-always-done
options.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-14 21:30 UTC (permalink / raw)
To: git
In-Reply-To: <87bqn9u43s.wl%cworth@cworth.org>
The git interface refactoring should be I think the cause for git 2.0.0
release...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-14 21:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejdapj$vc0$1@sea.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1241 bytes --]
On Tue, 14 Nov 2006, Jakub Narebski wrote:
> Nicolas Pitre wrote:
>
> > If the fetch+merge behavior (which I think should really be refered as
> > pull+merge) is still desirable, then it should be called git-update and
> > be no more than a single shell script line such as
> >
> > git_pull && git_merge"
> >
> > This is really what most people expect from such a command name based
> > on obvious historical reasons. The lack of any branch argument to
> > git-pull and git-merge could be defined as using the first defined
> > remote branch by default. But having git-pull performing merges is IMHO
> > overloading the word and goes against most people's expectations.
>
> By the way, is anyone doing _remote_ octopus pull (true pull, not with . as
> repository)?
>
> We can always have --merge arguments to git-pull, and --fetch argument to
> git-merge.
That would be a complete abomination if you want my opinion.
Please let git-pull actually pull stuff from a remote place, and
git-merge actually merge stuff only. Let's keep simple concepts mapped
to simple commands please. Nothing prevents _you_ from scripting more
involved operations with a single command of your liking afterwards.
Nicolas
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-14 21:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejdcg5$4fl$1@sea.gmane.org>
On Tue, 14 Nov 2006, Jakub Narebski wrote:
> The git interface refactoring should be I think the cause for git 2.0.0
> release...
Good idea indeed.
^ permalink raw reply
* Re: Missing features in git
From: linux @ 2006-11-14 21:38 UTC (permalink / raw)
To: git, torvalds; +Cc: linux
In-Reply-To: <20061114195559.40967ee4.froese@gmx.de>
>>> Another solution would be to be able to put non-head ref in HEAD,
>>> but allow to commit only if the prefix is refs/heads/
>>
>> That's not a bad idea. Then you can checkout a tag and have
>> 'ref: refs/tags/v1.11' in HEAD, which means anyone who puts
>> $(git-symbolic-ref) calls into their PS1 will see "refs/tags/v1.11"
>> as their current branch, reminding them they are looking at the past.
> I agree. This would probably be a good way to do "read-only branches".
>
> Allowing people to do a "git checkout" on anything committish, but then
> not allowing them to commit to that, is probably the right thing to do.
>
> Together with a nice readable error message from "git commit" (and merge,
> and pull - although you might well allow "fetch" to update the thing that
> current HEAD points to, though), this would be a lot easier to use for
> people who just follow somebody elses branch.
This certainly seems like a popular idea. I think the vote is to symlink
(symref) to a non-refs/heads/ object if possible, but allow an arbitrary
object ID as well. In either case, commits would be forbidden.
The only reason I had avoided symlinking before was in case the tag was
deleted, but that can be fixed easily enough. (Either make git-tag -d/-f
fail, or have it replace the HEAD symref with a raw hex object.
Actually, you could do the same with git branch -d. Any opinions?)
I can try to write the patch if there are no better volunteers, although
it'll take me a lot longer that someone more comfortable with the code.
Um.. for example, I'm not sure what the git fetch problem could
possibly be. It only updates heads, no? Or are you thinking
of the new refs/remotes thing that I'm not familiar with?
I'll have to examine the callers of git-symbolic-ref to see what
it should do. Return the hex object ID and fail are the obvious
possibilities.
Note that NOT having any sort of bisect label (and just using HEAD
itself as a raw pointer) solves the "git reset --hard" problem; I can
"git checkout HEAD^" and have debug hacks preserved.
It also removes a paragraph of excuses from some "using git" docs
I'm writing. It's a lot easier to explain why you can't commit
if you're not on a branch than to explain why you can't not be
on a branch.
Oh, and as I mentioned, not that "git checkout -b <newbranch>" is
exactly painful, but I think a "-b <newbranch>" option to git-commit
would be a convenience. (An interesting question is whether it should
create the new branch even if there is nothing to. I'm thinking "yes"
^ permalink raw reply
* git-svn and rebase causes duplicate log entries in svn
From: Joakim Tjernlund @ 2006-11-14 21:49 UTC (permalink / raw)
To: git
I have my own u-boot tree with a local branch where I do my own development.
This this branch(called svn) is connected to a svn repo using git-svn.
Now I want to rebase my svn branch against latest u-boot and commit
my rebased svn branch to svn.
I use git-svn commit -b svn -q remotes/git-svn..svn to commit my latest
changes and when I do so I see my local changes once more in the svn log:
------------------------------------------------------------------------
r321 | jocke | 2006-11-14 09:45:14 +0100 (Tue, 14 Nov 2006) | 2 lines
Add install of HRCW into I2C EEPROM.
and here:
------------------------------------------------------------------------
r46 | jocke | 2006-11-13 19:09:19 +0100 (Mon, 13 Nov 2006) | 2 lines
Add install of HRCW into I2C EEPROM.
Any way to avoid that?
Question, I found that
git-svn fetch && git-rebase remotes/git-svn^2 svn
leaves the svn branch at the tip of my latest commit in the
svn branch which makes better sense to me then
git-svn fetch && git-rebase remotes/git-svn svn
which puts svn at HEAD of remotes/git-svn.
Any reason I should not do the ...-svn^2 variant?
I am using git 1.4.3.5 and subversion 1.4.0
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-14 22:04 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611141627200.2591@xanadu.home>
Nicolas Pitre wrote:
> On Tue, 14 Nov 2006, Jakub Narebski wrote:
>> We can always have --merge arguments to git-pull, and --fetch argument to
>> git-merge.
>
> That would be a complete abomination if you want my opinion.
>
> Please let git-pull actually pull stuff from a remote place, and
> git-merge actually merge stuff only. Let's keep simple concepts mapped
> to simple commands please. Nothing prevents _you_ from scripting more
> involved operations with a single command of your liking afterwards.
Do we want to abandon completely "single-branch" workflow, where you
don't use tracking branch, only merge directly into your working branch?
That is the cause to (unused by most) future git-merge (replacement for
git-pull .) --fetch=<remote>[#<branch>] option.
I'm not that sure about --merge option, but it could be useful, at least
to have current automatic "Merge branch '<branch>' of <URL>" commit message.
--
Jakub Narebski
^ permalink raw reply
* Re: Missing features in git
From: Junio C Hamano @ 2006-11-14 22:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611141037120.3327@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 14 Nov 2006, Shawn Pearce wrote:
>> That's not a bad idea. Then you can checkout a tag and have
>> 'ref: refs/tags/v1.11' in HEAD, which means anyone who puts
>> $(git-symbolic-ref) calls into their PS1 will see "refs/tags/v1.11"
>> as their current branch, reminding them they are looking at the past.
>
> I agree. This would probably be a good way to do "read-only branches".
> ...
> Junio, what do you think? It wouldn't even be backwards incompatible,
> because we're strictly allowing a superset of what we used to..
(late reply -- just came back from a clinic)
I do not see any fundamental reason not to allow HEAD to be a
commit that you cannot commit on top of because you are not on
any branch, and I agree it is the right way to go.
I am not sure how much pain we are talking about yet though.
^ permalink raw reply
* Re: Missing features in git
From: Junio C Hamano @ 2006-11-14 22:13 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20061114134958.5326.qmail@science.horizon.com>
linux@horizon.com writes:
> One thing I noticed is that with ref logs, you've just re-invented the
> CVS problem of associating history with a name. If you want to rename
> a branch (say, from "mischacks" to something suitable for publication),
> do you rename the log or not? It's a less virulent form, but it seems
> like the same disease.
I do not think we currently rename the log but it is probably a
bug. Renaming tag should also be made easier.
> Another minor quibble: AFAICT, "git checkout -f -m" is meaningless (-f
> overrides -m), but doesn't complain.
It should be made to complain.
> An example of when you'd want to do this is performing a "git bisect"
> with a local "#define DEBUG 1" change. Particularly if you
> hit a non-compiling version and need to back up.
> or the way git-bisect does it
>
> echo "$rev" > "$GIT_DIR/refs/heads/new-bisect"
> git checkout new-bisect || exit
> mv "$GIT_DIR/refs/heads/new-bisect" "$GIT_DIR/refs/heads/bisect" &&
> GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD refs/heads/bisect
The name new-bisect is really temporary the code just shows it
punts on a situation it does not expect (it essentially expects
a clean tree and working with a local change is by accident) and
being ony half helpful to the user while recovering from that
unexpected situation. In other words, that's a room for
improvement. We should be rewrite the above with something like
what we have in the else clause in git-checkout around line 150.
It might make sense to make it a shell function and sharable
between checkout and bisect (perhaps there are other uses).
Then we do not need the temporary branch.
> Either way, it reserves a second branch name, and seems like a bit of
> a hack.
You are correct to call it a hack. git-bisect started as a
technology demonstration of the underlying rev-list --bisect
feature. The thing is that the technology was so nice and
useful that we started using it before cleaning up these
implementation details. I think instead of documenting the duct
tape that holds git-bisect together ("rev-list --bisect" is
great, and what "git-bisect" does is basically great but with
minor glitches like you noticed and with hacky implementation
details; I am calling the latter "duct tape"), we should redo
the hackish part.
Enough with bisect. And jumping the head while forward/back
porting the local change would also involve the same kind of
change, so "git reset --merge-local-change" might be a good
addition, but I am not sure about the details yet.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-14 22:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611142304.33673.jnareb@gmail.com>
On Tue, 14 Nov 2006, Jakub Narebski wrote:
> Nicolas Pitre wrote:
> > On Tue, 14 Nov 2006, Jakub Narebski wrote:
>
> >> We can always have --merge arguments to git-pull, and --fetch argument to
> >> git-merge.
> >
> > That would be a complete abomination if you want my opinion.
> >
> > Please let git-pull actually pull stuff from a remote place, and
> > git-merge actually merge stuff only. Let's keep simple concepts mapped
> > to simple commands please. Nothing prevents _you_ from scripting more
> > involved operations with a single command of your liking afterwards.
>
> Do we want to abandon completely "single-branch" workflow, where you
> don't use tracking branch, only merge directly into your working branch?
I really think we should. Let's admit it: such a work flow has nothing
to do with the tool. It would certainly be much easier to teach new
users about "this is a read-only view of the remote content that you can
merge into your working branch" than trying to explain why the tool is
so weird for the sake of supporting different work flows directly.
Again I think it is easier to grasp two simple commands than a single
but complex one with multiple ramifications.
> That is the cause to (unused by most) future git-merge (replacement for
> git-pull .) --fetch=<remote>[#<branch>] option.
>
> I'm not that sure about --merge option, but it could be useful, at least
> to have current automatic "Merge branch '<branch>' of <URL>" commit message.
A "remote" branch should obviously have a corresponding URL. So if you
do "git-merge remote" then you may as well prepare a commit message with
that URL given the local name for that branch if you want.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-14 22:36 UTC (permalink / raw)
To: Carl Worth; +Cc: git, Andy Whitcroft, Nicolas Pitre
In-Reply-To: <87bqn9u43s.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> On Tue, 14 Nov 2006 15:52:47 -0500 (EST), Nicolas Pitre wrote:
>> Even if I have a clear preference for GIT's _technology_, I still think
>> that the HG user interface is more convivial. I even been thinking
>> about writing something like an hg-like frontend to GIT from time to
>> time just so that GIT could then be better compared to (and actually
>> just used like) HG.
>
> I've actually been tempted to do the same myself. I really think that
> the technology is a more important criterion than the UI so the
> imagined hg-on-git interface would be an attempt to get people to look
> past the interface differences and look at the technology when
> deciding.
>...
>> I still think that the GIT user interface sucks in many ways. The
>...
I've actually been tempted to do that too, and my earlier "if I
were to redo git from scratch" message was the beginning of it
to summarize my preference about some of the issues raised in
this thread.
Commenting on the messages in this thread:
- "resolve / resolved" are both confusing, when you are talking
about "mark-resolved" operation.
- "pull/push/fetch" have undesired confusion depending on where
people learned the term. I'd perhaps vote for replacing
fetch with download and push with upload.
- I think it would be sensible to make remote tracking branches
less visible. For example:
git diff origin
where origin is the shorthand for your upstream (e.g. you
have .git/remotes/origin that records the URL and the branch
you are tracking) should be easier to understand than
git diff remotes/origin/HEAD
The latter is an implementation detail. I could imagine we
might even want to allow
git diff origin#next
to name the branch of the remote repository. The notion of
"where the tips of remote repository's branches are" is
probably be updated by "git download" (in other words, the
above "git diff" does not automatically initiate network
transfer).
- "git merge" to merge another branch into the current would
make sense. "git pull . remotes/origin/next" is showing too
much implementation detail. It should just be:
git merge origin#next
And I agree with Pasky that fixing UI is hard unless you are
willing to get rid of historical warts. Syntax of the command
line arguments the current set of Porcelain-ish takes are
sometimes just horrible. It may not be a bad idea to start
building the fixed UI from scratch, using different prefix than
"git" (say "gu" that stands for "git UI" or "gh" that stands for
"git for humans").
Of course, it could even be "cg" ;-).
^ permalink raw reply
* Re: [GIT PATCH] Makefile missing git-runstatus in PROGRAMS list
From: Junio C Hamano @ 2006-11-14 22:40 UTC (permalink / raw)
To: Bhavesh Davda; +Cc: git
In-Reply-To: <FE74AC4E0A23124DA52B99F17F44159701A11D63@PA-EXCH03.vmware.com>
"Bhavesh Davda" <bhavesh@vmware.com> writes:
> Noticed this when trying to use qgit on Linus's kernel git repository. The
> script git-status depends on git-runstatus being in the path.
>
> Adding git-runstatus to the PROGRAMS list in the Makefile, so that it gets
> installed along with the other git executables.
>
> After a "sudo make install", qgit is now happy, since git-status is now able
> to find git-runstatus in /usr/bin.
>
> Thanks
>
> - Bhavesh
>
> Bhavesh P. Davda
>
>
>
> diff --git a/Makefile b/Makefile
> index 36ce8cd..24a0dc7 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -202,7 +202,7 @@ PROGRAMS = \
> git-upload-pack$X git-verify-pack$X \
> git-pack-redundant$X git-var$X \
> git-describe$X git-merge-tree$X git-imap-send$X \
> - git-merge-recursive$X \
> + git-merge-recursive$X git-runstatus$X \
> $(EXTRA_PROGRAMS)
>
> # Empty...
This cannot be right. There is builtin-runstatus.o defined as
part of BUILTIN_OBJS so you already should have git-runstatus as
a hardlink to other binaries such as git-add, git-apply
etc. in the same directory as you have them.
I seem to have 55 hardlinks to that file under my ~/bin/.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-14 22:50 UTC (permalink / raw)
To: git, Andy Whitcroft, Nicolas Pitre, Carl Worth
In-Reply-To: <7vr6w5y7to.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> - I think it would be sensible to make remote tracking branches
> less visible. For example:
>...
> - "git merge" to merge another branch into the current would
> make sense. "git pull . remotes/origin/next" is showing too
> much implementation detail. It should just be:
>
> git merge origin#next
This and other examples in "making remote tracking branches less
visible" are hard to read because I used the word "origin" in
two different sense. So here is a needed clarification.
If you have remotes/upstream that says:
URL: git://git.xz/repo.git
Pull: refs/heads/master:remotes/origin/master
Pull: refs/heads/next:remotes/origin/next
Then, currently the users need to say:
git diff remotes/origin/master
git merge remotes/origin/next
By "making tracking branches less visible", what I mean is to
let the users say this instead:
git diff upstream
git merge upstream#next
^ permalink raw reply
* Re: git-svn and rebase causes duplicate log entries in svn
From: Seth Falcon @ 2006-11-14 22:55 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <00ff01c70836$ba7e3d00$1e67a8c0@Jocke>
Hi Joakim,
"Joakim Tjernlund" <joakim.tjernlund@transmode.se> writes:
> Now I want to rebase my svn branch against latest u-boot and commit
> my rebased svn branch to svn.
>
> I use git-svn commit -b svn -q remotes/git-svn..svn to commit my latest
> changes and when I do so I see my local changes once more in the svn
> log:
> Any way to avoid that?
I think you want to use git-svn dcommit, and not commit. See the
notes in the git-svn man page. The basic workflow
that I've been using is:
git-svn fetch
git rebase remotes/git-svn ## on mybranch
## make commits on mybranch
git-svn dcommit remotes/git-svn..mybranch
This results in each commit that I made on mybranch being sent to svn
as a separate commit.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-14 22:56 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611141633430.2591@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 14 Nov 2006, Jakub Narebski wrote:
>
>> The git interface refactoring should be I think the cause for git 2.0.0
>> release...
>
> Good idea indeed.
We need to avoid user confusion, so making a command that used
to do one thing to suddenly do something completely different is
a no-no. However, I do not think it needs to wait for 2.0.0.
We can start with a separate namespace (or even a separate
"Improved git UI project") and introduce the "improved UI set"
in 1.5.0 timeframe.
If managed properly, the "improved git UI" can coexist with the
current set of tools and over time we can give an option not to
even install the older Porcelain-ish commands.
^ permalink raw reply
* Re: [PATCH] commit: Steer new users toward "git commit -a" rather than update-index
From: Junio C Hamano @ 2006-11-14 23:30 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git, Carl Worth
In-Reply-To: <455A1137.8030301@shadowen.org>
Andy Whitcroft <apw@shadowen.org> writes:
> Are we sure this isn't porcelain-ish? We need to use it in merge
> conflict correction and the like? You can't use git-commit there as a
> replacement. I'd expect it to be 'git update-index' rather than
> 'git-update-index' of course.
I think status should be taken as Porcelain-ish so it should
notice more about the environment to see why the user has
changed but not updated files and recommend the possible action
depending on the context.
For that, you would need to enumerate what kind of 'context'
there could be with the current set of tools. Here is a
strawman.
1. None of the below.
2. A merge was attempted and resulted in a conflict.
3. An am or rebase without --merge was attempted and
resulted in a conflict or patch rejection.
4. A "rebase --merge was attempted and resulted in a conflict.
In the normal case, the next user action would be:
1-1. The user wants that change in the next commit, and should
run "git update-index $that_path" to prepare the index for
partial commit, or "git commit -a" to commit all the
changes made to the working tree so far. Carl's patch
helps the user in this case.
1-2. The user realizes that the some of the changes in the
working tree were not desirable, and "git checkout --
$that_path" to revert them before continuing. Before
deciding to revert, the user may want to check what the
difference is by running "git diff -- $that_path" so
suggesting these two might also be helpful.
1-3. The user wants to keep that change a strictly local change
in the working tree (this is often very useful and making
"commit -a" the default will not be acceptable unless
there is a very compelling reason to do so). This means
the suggestion we would make should clearly be
_suggestion_.
The earlier wording was bad in that it suggested to use a
Plumbing command update-index, but was attempting to convey that
it was merely a conditional suggestion by saying "use it TO MARK
FOR COMMIT", implying that if the user does not want to mark
them for commit, it is Ok not to use update-index.
When a merge is in progress, we would have .git/MERGE_HEAD and
that would be the way to tell case 2. In that case, the next
user action would be:
2-1. The user resolves conflicts and marks them as resolved,
with update-index (or "git mark-resolved"), to prepare the
index for the merge commit. But this is not done for
"Changed but not updated" files but "unmerged" files. We
should strongly suggest not to do _anything_ to "Changed
but not updated" files here.
2-2. The user decides this conflict is too much to handle right
now, and abandones the change by "git reset --hard". This
would lose the local changes ("Changed but not updated"),
so we should suggest to save the change before doing so.
If you are going to abandone this merge with "reset
--hard", your changes to these files will be lost. You
can save them with "git diff HEAD -- $this_path
$that_path..."
which is probably too long for that part of the output but
that is what we would want to say if we want to be
helpful.
When either rebase without --merge or am is in progress, there
would be .dotest/ directory (whose name could be changed but I
think this was a mistake and we would be better off using fixed
names for this kind of application) for git-status to notice.
The next user action would be:
3-1. The user resolves the conflict or manually apply the
patch, update-index the paths involved and proceeds with
"rebase --continue" or "am --resolved". "Changed but not
updated" paths should not be touched in this case,
similarly to 2-1.
3-2. The user gives up. Same as 2-2.
Designing for the "rebase --merge" case and coming up with other
cases are left as exercise to the list for further discussion.
^ 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