* Re: Cleaning up git user-interface warts
From: Johannes Schindelin @ 2006-11-17 10:11 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Michael K. Edwards, git
In-Reply-To: <87ejs2qvmb.wl%cworth@cworth.org>
Hi,
On Fri, 17 Nov 2006, Carl Worth wrote:
> 1. Making clone do the --use-separate-remotes behavior by default
Fully agree.
> 2. Taking advantage of that consistently for all branches instead of a
> special master:origin mapping in clone
Fully agree, too.
> 3. Enhancing git-fetch (or other) to modify .git/remotes, (or was
> there a desire for some other branch-specific section in the config
> file?)
I introduced the remote.<nick>.{url,fetch,push} entries into the config
with the goal to enhance -fetch to remember the current command line with
a setting. I was the only one to find that useful.
BTW I still would argue that it is better to write the remote information
into the config, because you have a saner way to manipulate that from
scripts than .git/remotes/<nick>.
> 4. Making git-fetch handle the disappearance of a remote branch
> gracefully
I think a message like "This remote branch no longer exists. Maybe you
want to use 'git branch -d <branch>' to remove it locally?" should
suffice.
> 5. Adding something like git-fetch --all to allow it to pick up all new
> branches
IIRC this idea was rejected, but I would find it useful. Especially with
what Han-Wen said: you can store the branches you fetch with "git fetch
--all <nick>" under .git/refs/remotes/<nick>/<branchname>.
> 6. Adding a "git update" that does a fetch for all appropriately
> marked remotes.
>
> On this last point, maybe we do something like:
>
> update=no|yes|all
>
> in .git/remotes. Then git-clone would set this up with update=all for
> origin so git-update would do a "fetch --all" on the origin
> repository. Then step 3 above would have to provide for setting this
> update option as appropriate.
First thought was: it is only useful if you want to track multiple
repositories. But next thought: if you mark the correct remotes in every
of your local repositories, you don't have to remember which nick your
upstream has. Yeah, I like it. But maybe do it as "git fetch --update" to
avoid more cluttering of the bindir?
Ciao,
Dscho
^ permalink raw reply
* Re: multi-project repos (was Re: Cleaning up git user-interface
From: Johannes Schindelin @ 2006-11-17 10:02 UTC (permalink / raw)
To: linux; +Cc: hanwen, git
In-Reply-To: <20061117051157.27896.qmail@science.horizon.com>
Hi,
On Fri, 17 Nov 2006, linux@horizon.com wrote:
> How do you explain the point of an electric screwdriver to someone who's
> never seen a screw? He'll think it's a silly way to wind up yarn.
I show him how to use it. And that's actually a fine analogy: While the
principle of a screw is quite clever, working with it -- even with an
electric screwdriver -- is easy. And the most important part: I never read
instructions on how to use it. I saw somebody use it and -- voila! -- I
can use it myself.
> I'll be the first to explain that the git docs have some major problems.
> "git show" is a really useful command. It has a zillion options to do
> cool things. Have you read the man page?
I think that the importance of documentation is overrated. Users have come
to expect to use programs without reading a manual. DWIM comes to mind.
Ciao,
^ permalink raw reply
* Re: [PATCH 4/5] allow deepening of a shallow repository
From: Johannes Schindelin @ 2006-11-17 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7qaqw12.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 17 Nov 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Yes. Somehow, an important part of unregister_shallow() went missing (yet
> > another proof that my poor-man's-StGit does not always work). I think that
> > the "object->parsed = 0;" should go into unregister_shallow() like this:
>
> That does not fly so well. Your fetch-pack.c does this in
> find_common() and dropping the parsed flag inside unregister
> causes it to be parsed again later with its true parents, which
> defeats what the commented part of the code wanted to do.
>
> if (!lookup_object(sha1))
> die("object not found: %s", line);
> /* make sure that it is parsed as shallow */
> parse_object(sha1);
> if (unregister_shallow(sha1))
> die("no shallow found: %s", line);
> continue;
Ah! _That_ was the reason I removed it from unregister_shallow().
> Although I am reasonably sure we can eventually make it work, it
> is very subtle and fragile -- somebody touching this code can
> easily break it.
I fully agree. Even the OA did not understand the code fully ;-)
How about adding "int force_reparse" to the signature of
unregister_shallow()? (Just like we added "int cleanup" to
get_merge_bases() to avoid pilot errors.)
Ciao,
Dscho
^ permalink raw reply
* Re: git-PS1 bash prompt setting
From: Nicolas Vilz @ 2006-11-17 9:52 UTC (permalink / raw)
To: Sean; +Cc: git, Theodore Tso
In-Reply-To: <20061117042051.d2fbddb6.seanlkml@sympatico.ca>
On Fri, Nov 17, 2006 at 04:20:51AM -0500, Sean wrote:
> On Fri, 17 Nov 2006 09:38:02 +0100
> Nicolas Vilz <niv@iaglans.de> wrote:
>
> > Just a note:
> >
> > this doesn't work with bash 3.2. I think they altered the way of
> > trimming variables in this version.
> >
> > on systems with bash 3.2 installed, i get
> > [master!linus-2.6/vm/vm]$
> > with the example above.
> >
> > on systems with bash 3.1, it works properly.
>
> Sorry bout that, I knew it was a bit fragile. Was rather
> comical reading Junio's recent message about all the things not
> to do if you want portable shell code and noticing my 6 line script
> did 90% of them ;o) Strange though, I downloaded Bash 3.2
> and gave it a try and didn't see the problem here..
>
> Wanna try this small change, to see if it helps? :
>
> #!/bin/bash
> BR=$(git symbolic-ref HEAD 2>/dev/null) || { echo "$@" ; exit ; }
> BR=${BR#refs/heads/}
> REL=$(git rev-parse --show-prefix)
> REL="${REL%\/}"
> LOC="${PWD%/$REL}"
> echo "[$BR!${LOC/*\/}${REL:+/$REL}]$ "
>
That one did the job... funny, removing these two // did the job, for
both versions,
GNU bash, version 3.1.17(1)-release (powerpc-unknown-linux-gnu) and
GNU bash, version 3.2.5(1)-release (x86_64-pc-linux-gnu).
Thx for fixing that script. It really helps me.
Sincerly
Nicolas
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Jakub Narebski @ 2006-11-17 9:41 UTC (permalink / raw)
To: git
In-Reply-To: <20061116221701.4499.qmail@science.horizon.com>
linux@horizon.com wrote:
> There is always a current head, known as HEAD. (This is actually a
> symbolic link, .git/HEAD, to a file like refs/heads/master.)
Usually this is symref, not symlink, i.e. .git/HEAD (or rather
$GIT_DIR/HEAD) is a file which contains single line like this:
ref: refs/heads/master
There is a talk about relaxing HEAD restriction to allow it to contain ref
to tag, or bare SHA1 id for "seeking"; you are forbidden to commit to such
state.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Jakub Narebski @ 2006-11-17 9:37 UTC (permalink / raw)
To: git
In-Reply-To: <20061116221701.4499.qmail@science.horizon.com>
linux@horizon.com wrote:
> Either way, they're just a 41-byte file that contains a 40-byte hex
> object ID, plus a newline. Tags are stored in .git/refs/tags, and heads
> are stored in .git/refs/heads. Creating a new branch is literally just
> picking a file name and writing the ID of an existing commit into it.
This is an implementation detail, and is not true in repository with
packed refs. Although usually (by default) only tags are packed.
But it remains true that ref (be it branch or tag) is just name and ID.
> The git programs enforce the immutability of tags, but that's a safety
> feature, not something fundamental. You can rename a tag to the heads
> directory and go wild.
You can have only refs to commit objects in heads directory (and I hope
this is verified by fsck-objects), you can have refs to tag objects
(heavyweight tags), to commits (lightweight tags), to blobs (for example
public PGP key used for signing tags), to trees (I guess unused).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-PS1 bash prompt setting
From: Sean @ 2006-11-17 9:20 UTC (permalink / raw)
To: Nicolas Vilz; +Cc: git, Theodore Tso
In-Reply-To: <20061117083801.GB11468@fry.bender.fht>
On Fri, 17 Nov 2006 09:38:02 +0100
Nicolas Vilz <niv@iaglans.de> wrote:
> Just a note:
>
> this doesn't work with bash 3.2. I think they altered the way of
> trimming variables in this version.
>
> on systems with bash 3.2 installed, i get
> [master!linus-2.6/vm/vm]$
> with the example above.
>
> on systems with bash 3.1, it works properly.
Sorry bout that, I knew it was a bit fragile. Was rather
comical reading Junio's recent message about all the things not
to do if you want portable shell code and noticing my 6 line script
did 90% of them ;o) Strange though, I downloaded Bash 3.2
and gave it a try and didn't see the problem here..
Wanna try this small change, to see if it helps? :
#!/bin/bash
BR=$(git symbolic-ref HEAD 2>/dev/null) || { echo "$@" ; exit ; }
BR=${BR#refs/heads/}
REL=$(git rev-parse --show-prefix)
REL="${REL%\/}"
LOC="${PWD%/$REL}"
echo "[$BR!${LOC/*\/}${REL:+/$REL}]$ "
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-17 9:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael K. Edwards, git
In-Reply-To: <7vu00ysbwi.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 4101 bytes --]
On Fri, 17 Nov 2006 00:41:33 -0800, Junio C Hamano wrote:
> I have no objection to this if it is done in a controlled way
> that does not make life more difficult for people who work with
> multiple remote repositories.
That's fine with me. Maybe I didn't explain this well before, but my
desire is exactly for this to work with multiple repositories.
Specifically, what we have in cairo is a "central" shared tree that
many people push to. But we only have two branches there, (one for
bug-fixes only for our stable releases, and one for ongoing
development of new features, and that only of stuff that's well
cooked).
So that tree looks and acts an awful lot like our cvs tree back in the
past. It's often very linear and often fairly boring to look at in gitk.
Meanwhile, all the really interesting stuff happens in personal
repositories where people have their own branches for stuff that is
still getting cooked. This is what's a lot more fun to watch, and
there's a lot more distributed back-and-forth that goes on here as
people collaborate on things. And it's all this kind of collaboration
that cvs never helped with at all, but git has been great.
So, what I want is both "git update" for the central tree. I said we
only have two branches, but that's really only two that are
active---the "stable" branch is actually a new branch after every
major release. It was 1.0 for a while, is 1.2 now, and will be 1.4
later. So I want "git update" to automatically pick those new branches
up as they get created.
Meanwhile, I also want to use "git update" to track everything that
people are working on in the more wild personal trees. So, yes, I do
want "git update" to be able to track lots of remote repositories in a
sane way.
What I have been doing up to this point is a little script I wrote
that does git-ls-remote on the repository I want to track and writes a
.git/remotes file to bring in all their branches. So if I want to see
what behdad is up to, I first refresh his .git/remotes file with my:
cairo-git-setup-remotes behdad
then:
git fetch behdad
And I end up with a bunch of branch names with "behdad-" prefixes that
I can explore or blow away if I'm no longer interested, (could have
used a "behdad/" prefix as well).
The first problem we ran into when doing that months ago was that I
don't want any tracking branches to come across this way. Or else I
end up with behdad-origin, he then gets cworth-behdad-origin, ad
nauseum. So we filtered "origin" out, but it will be nice to revisit
this if there's a sane distinction in git now to separate tracking
branches from heads.
> And I think "git fetch" is the tool for what you want if
> enhanced properly; see Linus's message that explaind that we
> already have that support in "manually configurable" form but
> initializing and maintaining the configuration is currently all
> manual and can be improved.
Yes, git-fetch is lovely, and it's the need for manual configuration
that's a problem, (and the mixing up of heads and remote tracking
branches that has been in git historically).
So, yes, I'll definitely look into improving this. I think the details
will involve:
1. Making clone do the --use-separate-remotes behavior by default
2. Taking advantage of that consistently for all branches instead of a
special master:origin mapping in clone
3. Enhancing git-fetch (or other) to modify .git/remotes, (or was
there a desire for some other branch-specific section in the config
file?)
4. Making git-fetch handle the disappearance of a remote branch
gracefully
5. Adding something like git-fetch --all to allow it to pick up all new
branches
6. Adding a "git update" that does a fetch for all appropriately
marked remotes.
On this last point, maybe we do something like:
update=no|yes|all
in .git/remotes. Then git-clone would set this up with update=all for
origin so git-update would do a "fetch --all" on the origin
repository. Then step 3 above would have to provide for setting this
update option as appropriate.
Anyway, something along those lines perhaps. Any feedback?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] allow deepening of a shallow repository
From: Junio C Hamano @ 2006-11-17 9:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611141150010.13772@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Yes. Somehow, an important part of unregister_shallow() went missing (yet
> another proof that my poor-man's-StGit does not always work). I think that
> the "object->parsed = 0;" should go into unregister_shallow() like this:
That does not fly so well. Your fetch-pack.c does this in
find_common() and dropping the parsed flag inside unregister
causes it to be parsed again later with its true parents, which
defeats what the commented part of the code wanted to do.
if (!lookup_object(sha1))
die("object not found: %s", line);
/* make sure that it is parsed as shallow */
parse_object(sha1);
if (unregister_shallow(sha1))
die("no shallow found: %s", line);
continue;
Although I am reasonably sure we can eventually make it work, it
is very subtle and fragile -- somebody touching this code can
easily break it.
.
^ permalink raw reply
* Re: [PATCH] gitweb: Atom feeds
From: Junio C Hamano @ 2006-11-17 9:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Andreas Fuchs, Petr Baudis
In-Reply-To: <ejim5q$31b$1@sea.gmane.org>
Andreas Fuchs <asf@boinkor.net> writes:
> Jakub Narebski wrote:
>> Andreas Fuchs <asf@boinkor.net> wrote:
>>
>>> * Wrap the commit message in <pre>
>> We use <div class="pre"> in "commit" view if I remember correctly.
>
> That's ok for rendered HTML output, but in my experience, the way feed
> readers interpret that ranges from "badly" to "not at all"; it's better
> to stick to explicit structure hints only in feeds. /-:
>
> So, this is the only thing I haven't fixed in the attached patch (:
> ...
> In addition to the above points, the attached patch emits a
> Last-Changed: HTTP response header field, and doesn't compute the feed
> body if the HTTP request type was HEAD. This helps keep the web server
> load down for well-behaved feed readers that check if the feed needs
> updating.
>
> Hope you like it,
Seems sane to me. Jakub, how do you like this one? If it looks
Ok to you, please arrange to include your one-liner that this
depends on and forward a readily applicable patch with
appropriate commit log message.
^ permalink raw reply
* Re: git-svn bug?
From: Eric Wong @ 2006-11-17 8:55 UTC (permalink / raw)
To: Troy Telford; +Cc: Junio C Hamano, git
In-Reply-To: <op.ti2xykijzidtg1@rygel.lnxi.com>
Sorry for the late replies, I've been caught up with other things.
Troy Telford <ttelford.groups@gmail.com> wrote:
> On Wed, 15 Nov 2006 14:43:30 -0700, Junio C Hamano <junkio@cox.net> wrote:
>
> >"Troy Telford" <ttelford.groups@gmail.com> writes:
> >
> >>(using git 1.4.4, svn 1.3.1 on a SLES 10 box)
> >>fatal: Not a valid object name
> >>92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
> >>32768 at /usr/lib/perl5/5.8.8/Memoize.pm line 269
> >>...
> >>I couldn't find an object named
> >>"92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1" in .git/
> >
> >Troy, do you have object 92e2e0c5? Is it a root commit (i.e. a
> >commit that does not have a parent)?
dcommit expects to be run on a git-svn fetch-ed HEAD that is linear
superset of remotes/git-svn. That is: remotes/git-svn..HEAD should
(ideally) contain no merges, and no root commits. git-svn currently
does no checking for root commits, but it should.
> I'll have to admit I'm stabbing in the dark on how to get the correct
> answer this, but here goes:
>
> * `git cat-file -t 92e2e0...` returns 'commit'
> * 'git cat-file -p 92e2e0...` returns: (minus the header/footer asterisks)
> *********************************************
> tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
> author unknown <unknown> 961088898 +0000
> committer unknown <unknown> 961088898 +0000
>
> New repository initialized by cvs2svn.
> *********************************************
This commit is missing the git-svn-id: line at the bottom. If you
simply left it out (private svn repository info), can you check that the
URL in this line is actually for the SVN repository you want to commit
to?
It seems like your usage of dcommit would actually cause the issue
you're experiencing to be triggered on the dummy repository, and not the
real one. My other guess would be that you somehow merged commits from
your dummy svn repo into your master branch.
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-17 8:41 UTC (permalink / raw)
To: Carl Worth; +Cc: Michael K. Edwards, git
In-Reply-To: <87r6w3b68p.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> On Thu, 16 Nov 2006 09:57:00 -0800, "Michael K. Edwards" wrote:
>> What do you want all of those branches for? They haven't been
>> published to you (that's a human interaction that doesn't go through
>> git), so for all you know they're just upstream experiments, and doing
>> things with them is probably shooting yourself in the foot.
>
> The same "what do you want them all for" question could be asked of
> git-clone which also fetches all available branches. I really just
> want to be able to easily watch what's going on in multiple
> repositories.
>
> I want to be able to just say "git update" (or whatever) and then be
> able to list and browse and explore the stuff locally.
>...
I have no objection to this if it is done in a controlled way
that does not make life more difficult for people who work with
multiple remote repositories.
And I think "git fetch" is the tool for what you want if
enhanced properly; see Linus's message that explaind that we
already have that support in "manually configurable" form but
initializing and maintaining the configuration is currently all
manual and can be improved.
^ permalink raw reply
* Re: git-PS1 bash prompt setting
From: Nicolas Vilz @ 2006-11-17 8:38 UTC (permalink / raw)
To: Sean; +Cc: git, Theodore Tso
In-Reply-To: <20061116130111.921396df.seanlkml@sympatico.ca>
On Thu, Nov 16, 2006 at 01:01:11PM -0500, Sean wrote:
> [branch!repo/relative/path]$
>
> Where "repo" is the basename of the path to the root of your repo.
> An example would look like this:
>
> [master!linus-2.6/Documentation/vm]$
>
> Cheers,
> Sean
>
>
> #!/bin/bash
> BR=$(git symbolic-ref HEAD 2>/dev/null) || { echo "$@" ; exit ; }
> BR=${BR#refs/heads/}
> REL=$(git rev-parse --show-prefix)
> REL="${REL//%\/}"
> LOC="${PWD%/$REL}"
> echo "[$BR!${LOC/*\/}${REL:+/$REL}]$ "
Just a note:
this doesn't work with bash 3.2. I think they altered the way of
trimming variables in this version.
on systems with bash 3.2 installed, i get
[master!linus-2.6/vm/vm]$
with the example above.
on systems with bash 3.1, it works properly.
unfortunatelly, i am not so good in bash scripting, so it will take some
time for me to fix it.
Sincerly
^ permalink raw reply
* Re: [PATCH] Make "git checkout <branch> <path>" work when <path> is a directory.
From: Junio C Hamano @ 2006-11-17 8:15 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: Junio C Hamano, git
In-Reply-To: <f2b55d220611162218t3a752829hf922613c17fe326d@mail.gmail.com>
"Michael K. Edwards" <medwards.linux@gmail.com> writes:
> Ah. Missed that patch, which is indeed a superset of mine. Looks
> like you committed it on branch "next"; is that a personal
> experimental branch, or the integration branch against which patches
> should be generated?
Actually it is not pushed out anywhere yet but will appear on
both 'maint' and 'master' along with other post 1.4.4 fixes and
will be contained in the 1.4.4.1 maintenance release.
The role of each branch at my public repository is desribed in
this message:
Message-ID: <7vk62qhy4k.fsf@assigned-by-dhcp.cox.net>
http://article.gmane.org/gmane.comp.version-control.git/29951
In general, if your changes and fixes are applicable in
isolation to "master", it is most appropriate to send patches
against "master". If you are following up a topic that is
cooking in "next" (or "pu"), then basing your patch on "master"
is obviously a bad idea and a patch that applies on "next" (or
"pu") would be more appropriate. If you can make the patch
against the tip of the specific topic that would be even better
but it generally is more work for you, so I usually do not ask
that to contributors.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-17 7:32 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: git
In-Reply-To: <f2b55d220611162242s48dc42d6g4cbfd9173e712ff8@mail.gmail.com>
"Michael K. Edwards" <medwards.linux@gmail.com> writes:
> Presumably "git branch -D" should inspect everything under
> .git/remotes to see whether one or more Pull: lines need to be
> deleted along with the branch.
I am not sure what you mean. .git/remotes files do not describe
any relationship between local branches (and that is where one
of the problem raised in recent thread -- pull does not notice
on which branch you are on and change its behaviour depending on
it), so I do not think there is anything gained for "git branch
-D" by going through them.
> Currently, it looks like "remotes" entries are
> created only by "git clone" or by hand. Junio, are there any plans to
> manage the contents of "remotes" through the tool instead of by hand?
I muttered something in a near-by thread
Message-ID: <7vr6w78b4x.fsf@assigned-by-dhcp.cox.net>
I am reasonably sure a separate tool (what I tentatively called
"maint-remote" in the message) is necessary, because, while it
would be relatively easy to make "git fetch" and friends to add
new mappings in the default way under a new option, people with
different workflows would want differnt "default mappings", and
adding new mappings for _all_ remote branches is useful only for
people who work in one particular way (namely, the CVS-style
"the central distribution point is where everybody meet" model).
The tool, under "interactive" mode, would probably take one
parameter, the short name of a remote ($name), and would give
you a form to update its URL:, shows ls-remote output against
that repository and would let you:
- update the URL: which would probably cause the ls-remote to
be re-run;
- remove existing mappings;
- add mappings for a remote branch for which you do not have a
corresponding tracking branch, with a straightforward default
mapping:
refs/heads/$branch:refs/remotes/$name/$branch
But I haven't thought things through yet.
^ permalink raw reply
* "git fmt-merge-msg" SIGSEGV
From: Linus Torvalds @ 2006-11-17 6:57 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Ok, this is a _really_ stupid case, and I don't think it matters, but hey,
we should never SIGSEGV.
Steps to reproduce:
mkdir duh
cd duh
git init-db
git-fmt-merge-msg < /dev/null
will cause a SIGSEGV in cmd_fmt_merge_msg(), because we're doing a
strncmp() with a NULL current_branch.
And yeah, it's an insane schenario, and no, it doesn't really matter. The
only reason I noticed was that a broken version of my "git pull" into an
empty directory would cause this.
This silly patch just replaces the SIGSEGV with a controlled exit with an
error message.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index 3d3097d..87d3d63 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -278,6 +278,8 @@ int cmd_fmt_merge_msg(int argc, const ch
/* get current branch */
current_branch = resolve_ref("HEAD", head_sha1, 1, NULL);
+ if (!current_branch)
+ die("No current branch");
if (!strncmp(current_branch, "refs/heads/", 11))
current_branch += 11;
^ permalink raw reply related
* Re: Cleaning up git user-interface warts
From: Michael K. Edwards @ 2006-11-17 6:42 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <f2b55d220611161734m49136e6fneda5b002eb67618b@mail.gmail.com>
On 11/16/06, Michael K. Edwards <medwards.linux@gmail.com> wrote
> The only entry placed in .git/remotes is the
> "origin" of the new clone, which is the "master" of the remote
> repository. That's for the user's convenience, and is about the only
> thing in the new clone that _isn't_ a copy of something in the remote
> tree.
Actually, this "origin" entry does contain "Pull:" lines for all of
the branches that were cloned, so that "git pull" fetches and merges
updates to all of these branches. (If upstream is in the habit of
reverting things, you may need "git pull -f"; I just did that on the
git repo to handle a failure to fast-forward on the "pu" branch.)
Presumably "git branch -D" should inspect everything under
.git/remotes to see whether one or more Pull: lines need to be deleted
along with the branch. Currently, it looks like "remotes" entries are
created only by "git clone" or by hand. Junio, are there any plans to
manage the contents of "remotes" through the tool instead of by hand?
Cheers,
^ permalink raw reply
* Re: [PATCH] Make "git checkout <branch> <path>" work when <path> is a directory.
From: Michael K. Edwards @ 2006-11-17 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkmavcai.fsf@assigned-by-dhcp.cox.net>
Ah. Missed that patch, which is indeed a superset of mine. Looks
like you committed it on branch "next"; is that a personal
experimental branch, or the integration branch against which patches
should be generated?
Cheers,
^ permalink raw reply
* Re: [PATCH] Make "git checkout <branch> <path>" work when <path> is a directory.
From: Junio C Hamano @ 2006-11-17 6:04 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: git
In-Reply-To: <f2b55d220611162149m719079f3ubdaeac43fe9798cb@mail.gmail.com>
Thanks.
I think I sent out the same yesterday morning, though.
Message-ID: <7vbqn8msuw.fsf@assigned-by-dhcp.cox.net>
The difference is that the one tries to catch misspelled <path>.
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Junio C Hamano @ 2006-11-17 5:55 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20061117031747.30672.qmail@science.horizon.com>
linux@horizon.com writes:
>>> * When merging goes wrong
>
>> Another tool to help the user decide how the mess should be
>> sorted out is "git log --merge -- $path". It gives the logs of
>> commits that touched the path while the two branches were forked.
>
> The things I never knew about...
Of course "git log -p --merge -- $path" would give the patch
text as well.
>> If you are using this particular commit as an example, you might
>> also want to tell your readers about:
>>
>> git show -M 3f69d405
>>
>> (-M is there to make the output more readable, because this
>> merge involved a few renames).
>
> I'm wondering what the heck that does! I get a super-short diff with
> no mention of any renames at all. Is this passed on to git-diff-tree?
> What does "detect renames" mean if it doesn't tell me about them?
> I'm actually confused.
"show $merge" is really "diff-tree --cc -p $merge". So first I
should (not necessarily "you should to the readers of this
document") talk about three ways to describe a merge commit with
textual diffs.
(1) N independent diffs between each of the parents and the child.
We could get this with
git diff-tree -m -p $merge
but it is mostly useless, because very often many paths in a
merge are truly trivial and the version from one of the
parents is taken verbatim, whole file. When looking at the
development history, the real reason of the change is found
in earlier log for that parent, and not in the merge in
question.
The diff between the child and its first parent is somewhat
useful, because it represents the damage inflicted on his
branch the person saw when he made the merge. For this
reason, "--stat" gives the graph for the first-parent diff
for a merge. But otherwise "diff-tree -p" by default stays
silent about merges because it is not that useful, and that
is why the above asks for the "useless output ;-)" with an
explicit "-m".
(2) Uncompressed "combined diff" between all parents and the child.
We can get this with:
git diff-tree -c -p $merge
This gives a combined diff that shows all the files parents
and child disagreed (in other words, if the resulting file
matches verbatim with one of the parents, it is not shown).
This is already useful by reducing the clutter of truly
trivial merges, compared to (1) above, but most clean merges
take either first or second parent's version verbatim for
each hunk (but not necessarily taking all hunks from the
same parent) and these hunks are not very interesting.
Because "-c" explicitly tells something special to be done
for a merge, you do not need to say "-m" for the above
command (giving -m does not hurt, but is not necessary).
Uncompressed combined diff is a still per-file affair, so by
default the above gives the output in the "raw" format, and
that is why the above command still says "-p".
(3) Compressed "combined diff". This is what "show" gives by
default, and we can get this with:
git diff-tree --cc $merge
The difference from "-c -p" output is that this reduces the
clutter further by dropping uninteresting hunks from the
output. If all the changes in a hunk is from only one
parent, or the changes are the same from all but one parent,
the hunk is dropped from the output (looking at dodecapus
with --cc is interesting for this reason).
Like "-c", this explicitly asks a magic to be done on a
merge, so "-m" is implied. Unlike "-c", this operation is
per-hunk and "raw" format (which is inherently per file)
does not make any sense. Because "raw" is impossible, "-p"
is also implied.
Both (2) and (3) are "combined". It combines the diffs with
each parent; for N-parent merge, it combines N diffs into one.
What -M/-C does is to see which path in each parent is used to
diff against a path in the child. For example, the stat part
of:
git diff-tree --stat --cc -p -M 3f69d405
shows us that builtin-apply.c had a few insertion and deletion
(remember, this is the diff between the first parent and the
child -- "damage given to the first parent due to this merge").
If you run the above without -M, you will see a huge combined
diff for builtin-apply.c because the second parent (i.e. the
branch that was merged) did not have builtin-apply.c -- it still
had the file under its old name, apply.c.
So what ends up getting combined without -M is diff between
builtin-apply.c of the first parent and the child, and diff
between /dev/null and builtin-apply.c of the child.
But with -M, what it combines is diff between builtin-apply.c of
the first parent and the child, and diff between apply.c of the
second parent and builtin-apply.c of the child. This obviously
produces a lot more reasonable output -- actually the merge for
this particular path is texually trivial that it does not even
show in the --cc output. You can still view what it was by
looking at:
git diff-tree -c -p -M 3f69d405
Side note: I am not sure if the --cc hunk droppage logic is
doing the right thing for the first hunk for builtin-apply.c
case. I think it is an "interesting" hunk but somehow --cc
output does not show it. The second and later hunks are
definitely uninteresting, though.
^ permalink raw reply
* [PATCH] Make "git checkout <branch> <path>" work when <path> is a directory.
From: Michael K. Edwards @ 2006-11-17 5:49 UTC (permalink / raw)
To: git
This improves the workflow for, say, kernel subsystem backporting.
Signed-off-by: Michael K. Edwards <medwards-linux@gmail.com>
---
git-checkout.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index dd47724..5866604 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -106,7 +106,8 @@ Did you intend to checkout '$@' which ca
git-ls-tree --full-name -r "$new" "$@" |
git-update-index --index-info || exit $?
fi
- git-checkout-index -f -u -- "$@"
+ git-ls-files "$@" |
+ git-checkout-index -f -u --stdin
exit $?
else
# Make sure we did not fall back on $arg^{tree} codepath
--
^ permalink raw reply related
* Re: multi-project repos (was Re: Cleaning up git user-interface
From: Sean @ 2006-11-17 5:42 UTC (permalink / raw)
To: linux; +Cc: hanwen, git
In-Reply-To: <20061117051157.27896.qmail@science.horizon.com>
On 17 Nov 2006 00:11:57 -0500
linux@horizon.com wrote:
> "The only intuitive user interface is the nipple; all else is learned."
The thing is that other SCM's like hg look a lot more like a nipple than
Git. And they have the same conceptual models, more or less, to deal with
as Git.
So why is it so many people think Git has a UI problem where the same
complaint isn't levelled at Mercurial? The thing is, the focus of
Git has been different, it's been about creating great plumbing. It's
had great success at doing that, and anyone who warms up to Git is well
rewarded with a tool that gives them a lot of power and flexibility.
But Junio and others that have done most of the work have gone so far
as to say Git is basically now feature complete.. the plumbing is more
or less done.
So now it's time to make that plumbing more accessible and less
intimidating to the uninitiated. And blaming them for having the wrong
mental model is just fundamentally the wrong approach. No amount of
documentation is going to replace having tools that are the least
surprising they can be and Just Work more often than not. Other
modern SCM's have managed to do a better job of this than Git, and
there's no reason Git can't do better than it has.
As long as no damage is done to the underlying architecture and
principles of Git there really shouldn't be _any harm_ in trying
to do a better job of the porcelain layer.
^ permalink raw reply
* Re: multi-project repos (was Re: Cleaning up git user-interface
From: linux @ 2006-11-17 5:11 UTC (permalink / raw)
To: hanwen; +Cc: git, linux
>> A lot of the complaints seem to not be about the interfaces, but about
>> people not _understanding_ and knowing what the interfaces do. If you were
> From the point of view of a user, there is not really a difference
> between the two. As a user, you form a mental model of how things
> work by looking at the interface. If the interface is bad, the user
> creates a faulty model in his head, and starts doing things that
> are perfectly logical in the faulty model, but stupid and silly when
> you consider the actual internals.
"The only intuitive user interface is the nipple; all else is learned."
As Linus is explaining, the fundamental *problem* is the mental model.
Once you know how to break your goals apart into the right kind of pieces,
little things like terminology are truly little.
I'm not sure that git is sufficiently like anything else that a few
well-chosen command names can bring a good analogy to mind. There just
isn't a simple analogy that won't lead you astray; you have to understand
the thing on its own terms.
How do you explain the point of an electric screwdriver to someone who's
never seen a screw? He'll think it's a silly way to wind up yarn.
I'll be the first to explain that the git docs have some major problems.
"git show" is a really useful command. It has a zillion options to do
cool things. Have you read the man page?
Didn't take long, did it? "git log" is even more powerful, and almost
as bad. The information is all available, it's just on the plumbing
man pages.
And I even understand *why* it's there. Because writing the plumbing is
when the coders were thinking about the problem. And writing good docs
is very simple: when you learn something, write it down. Not later,
or next week, but right now, when you still remember how confused you
were before and what led you to the revelation.
The only problem, for a person looking at it top-down, is that git was
written bottom-up, so the bottom is very well documented, and once you
understand that, the top is pretty obvious and trivial.
But if you want to improve the situation for someone like yourself,
the solution is the same: when you learn something non-trivial, write
it down. Not later, after you've finished learning, but right now when
you still remember the process of learning.
Now, when you show people what you wrote, one of two things will
happen:
1) They'll say "thank you, that's a good way of looking at it", or
2) They'll say, "that's not quite right; the truth is actually...".
The second case means that you have a bit more to learn.
But by taking the first step, you've given the learning process
some momentum. It gets easier after that.
I hope my recent postings ([DRAFT] Branching and merging with git)
form a reasonable example of that.
There are a few key concepts in the git tools. I don't care if
"git-rev-list" is an ugly name; the name isn't learly as important as
realizing that *every* command that works on a list of commits uses
the same primitive, and what you learn about one command in that family
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: linux @ 2006-11-17 3:17 UTC (permalink / raw)
To: junkio, linux; +Cc: git
In-Reply-To: <7vac2q281q.fsf@assigned-by-dhcp.cox.net>
Overall, thank you. I'm trying to merge all your comments
into the document to make it better, but there are enough that
it's taking me a while.
>> One outstanding problem with git's man pages is that often the most detail
>> is in the command page that was written first, not the user-friendly
>> one that you should use.
>
> This is a very important point to remember not for users but for
> us in git community. Thanks for writing it down.
There's a great example coming up, in the git-show
example you gave me. That's a very sparse man page...
> Dodecapus would find a few, no hits on doedecapus ;-).
Wups, thanks.
>> * Deleting branches
>>
>> "git branch -d <head>" is safe. It deletes the given <head>, but first
>> it checks that the commit is reachable some other way. That is, you
>> merged the branch in somewhere, or you never did any edits on that branch.
>
> It is not "somewhere" but "in the current branch", so in a sense
> it is a bit stricter than that. While on 'master' "branch -d
> topic" would not remove the topic branch head if it is not fully
> merged to my 'master' so that is a reasonable safety measure,
> but when I am on 'next' it will happily remove it. It is
> recoverable because it is reachable from 'next', though.
Oh! Thanks for the info. The limitation makes a certain
amount of sense, and as I'd never run into it, I'm not going to
complain.
> The reason is because 'git pull $url $branch' (typical Linus's
> use) and 'git pull' (defaulting to 'origin' and using the
> tracking branch mapping stored in .git/remotes/origin prepared
> by git-clone) are sign of very different workflows. The former
> tends to be a one-shot event while the latter is most often
> synchronizing with either an upstream or a common distribution
> point (i.e. shared central repostiory). When you are fetching
> from somebody in a one-shot manner, most likely as a part of
> 'pull', you do not want to get the tag the other person has made
> to mark his private work in progress. But in the latter case,
> the other end is where everybody who works in the same area
> fetches from, and sharing the tags found there among the
> developers by default is desirable, and more importantly there
> is no risk of accidentally getting private tags, since the other
> end is a public distribution point and by definition should not
> have private tags that would clutter your refs/tags hierarchy.
I'll work this in somehow, thanks.
> Here you _might_ want to mention an alternative workflow that
> uses rebase, which seems to be the way Wine folks run their
> project. Talking about all the different possibilities tends to
> cloud things and may not add value to the document, so I am just
> mentioning it as a possibility but I do not know if talking
> about rebase is useful in the context of this document.
Done, thanks.
>> The primitive that does the merging is called (guess what?) git-merge.
>> And you can use that if you want. If you want to create a so-called
>> octopus merge, with more than two parents, you have to.
>
> This is not true; "git pull . topicA topicB topicC" works as
> expected. But we probably would not want to even talk about
> Octopus in a document like this. It is a curosity, and
> sometimes tends to make histories even less cluttered, but
> otherwise it does not add much value.
Sorry; the SYNOPSIS line for git-pull had me fooled.
>> However, it's usually easier to use the git-pull wrapper. This merges
>> the changes from some other branch into the current HEAD and generates
>> a commit message automatically.
>>
>> git-merge lets you specify the commit message (rather than generating it
>> automatically) and use a non-HEAD destination branch, but those options
>> are usually more annoying than useful.
>
> I haven't tried for a long time, but I do not think non-HEAD
> destination even works at all. It might be better not to even
> mention git-merge at this point of the document.
Well, I want to at least say "you think so, wouldn't you?"
>> * How merging operates
>
> You might also want to mention that recursive first 3-way merges
> the renames. If O->A renames a path while O->B keeps it, the
> resulting stages are written under the new name.
Thanks! I wondered how that happened!
>> * When merging goes wrong
> Another tool to help the user decide how the mess should be
> sorted out is "git log --merge -- $path". It gives the logs of
> commits that touched the path while the two branches were forked.
The things I never knew about...
>> Git-rebase can also help you divide up work. Suppose you've mixed up
>> development of two features in the current HEAD, a branch called "dev".
>
> Ancestry graph before and after this procedure would help the
> reader a lot here.
I figured the (excellent) pictures in git-rebase would save me the
trouble, but yeah, I suppose so.
> They were conflicts during the virtual ancestor computation by
> recursive (the merge between 'a' and 'b' commits in your earlier
> example). When a virtual ancestor is created, it can textually
> have conflicted merge, but that is recorded along with conflict
> markers without manual resolving for obvious reasons. If two
> branches that use the virtual ancestor modifies the conflicted
> region the same way (because they needed to resolve that
> conflict in their branch), the final 3-way merge that uses the
> virtual ancestor as the merge-base will replace that conflicted
> region with their changes. This "even conflict markers can be
> eliminated by a merge resolution" behaviour is what inspired
> git-rerere, by the way.
Cool, thanks! I added mention of this.
> If you are using this particular commit as an example, you might
> also want to tell your readers about:
>
> git show -M 3f69d405
>
> (-M is there to make the output more readable, because this
> merge involved a few renames).
I'm wondering what the heck that does! I get a super-short diff with
no mention of any renames at all. Is this passed on to git-diff-tree?
What does "detect renames" mean if it doesn't tell me about them?
I'm actually confused.
diff --cc builtin-read-tree.c
index ec40d01,99e7c75..716f792
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@@ -9,9 -9,9 +9,10 @@@
#include "object.h"
#include "tree.h"
+ #include "cache-tree.h"
#include <sys/time.h>
#include <signal.h>
+#include "builtin.h"
static int reset = 0;
^ permalink raw reply
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
From: Johannes Schindelin @ 2006-11-17 2:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Han-Wen Nienhuys, Junio C Hamano, git
In-Reply-To: <20061117015238.GD7201@pasky.or.cz>
Hi,
On Fri, 17 Nov 2006, Petr Baudis wrote:
> On Fri, Nov 17, 2006 at 02:22:35AM CET, Johannes Schindelin wrote:
> > On Thu, 16 Nov 2006, Linus Torvalds wrote:
> > > For example, if you used one of the old-fashioned commit walkers, maybe we
> > > got the initial commit, but we may not have gotten the whole _chain_. See?
> >
> > Huh? I am quite certain that FETCH_HEAD is not updated in that case. If it
> > is, that's a bug.
>
> It may be updated and then things may break _afterwards_. git-prune will
> happily blow anything referenced by FETCH_HEAD, it's not considered by
> the fsck-objects reachability analysis.
This actually underlines my point: FETCH_HEAD is no _real_ branch, not
even a temporary one. If it was, git-prune would not lose the related
objects.
Ciao,
Dscho
^ 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