* Re: [DRAFT 2] Branching and merging with git
From: J. Bruce Fields @ 2006-12-15 21:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <elv4f5$kcj$1@sea.gmane.org>
On Fri, Dec 15, 2006 at 10:38:05PM +0100, Jakub Narebski wrote:
> linux@horizon.com wrote:
>
> > I tried to incorporate all the suggestions. There are still a few things
> > I have to research, and now I'm worried it's getting too long. Sigh.
>
> Tutorials can (and usually are) be long, don't worry.
>
>
> Could you resend this as patch creating Documentation/tutorial-3.txt
> This way it would be in the repository, and people would be able to correct
> this (I guess that it at first would appear in 'next' branch)...
Yes please. Even if it has some problems or isn't really a perfect fit
in the current tutorial sequence, we can fix that later.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Josef Weidendorfer @ 2006-12-15 21:42 UTC (permalink / raw)
To: Torgil Svensson; +Cc: R. Steve McKown, Linus Torvalds, git
In-Reply-To: <e7bda7770612150943j71a7362bmb509cea3b7756003@mail.gmail.com>
On Friday 15 December 2006 18:43, Torgil Svensson wrote:
> On 12/15/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > However, there is nothing wrong with it. Yet, you perhaps want
> > the 2 Lib submodules not to go out of sync. This easily
> > can be done with symlinking the Lib checkouts. As they are submodules,
> > everything should work fine.
>
> This is interesting. In my notation:
>
> /path/to/link/name -> <commit>/path/to/subtree
>
> means that there is a link named "name" in the tree object for
> "path/to/link". The link points to a "link object" specifying a
> subtree or blob of the tree that is pointed to in a submodule commit.
Ah, now I understand. I somehow missed this notation.
> This is not currently implemented but has at least the following
> advantages:
>
> 1. You can access files in a submodule without fetching the whole
> submodule (which may be very large). (App1 is only interested in
> lib1.h, the rest is toally irrelevant)
> 2. Superproject can access referenced (linked) files in it's own
> folder-structure without being forced a structure by the subproject.
That all sounds fine, but how do you create such symlinks in practice?
Do you want to introduce special porcelain commands to create them?
Especially, what is the SCM user supposed to do to change the link
target, ie. from
<commit>/path/to/subtree
to
<commit>/path2/to2/subtree2
?
Should this do a re-checkout at the other point?
By linking a file from a submodule, such a link seems to force that
this file has to be at a fixed position in the submodule. Otherwise,
some magic has to happen when the file is moved in the submodule,
possibly leading to a dangling link, eg. if the whole subdirectory
specified in the link is removed.
IMHO this is getting way to complex.
Much simpler is to include the full submodule at some path in
the supermodule, and create normal symlinks from the supermodule
into the submodule.
If you only want to check out part of a submodule, this should be
done with path-limiting checkouts, which should be a feature totally
independent from submodules.
And if you want to limit the number of objects transferred in cloning
of a subproject, it is better to further split this subproject into
multiple subprojects itself.
> If you do a symlink instead, doesn't you loose versioning information?
Of course, you need the submodule fully checked out somewhere in the
supermodule, and the link goes into the submodule directory. The
versioning is given by the supermodule/submodule link.
> What happens with the symlinks if someone clones the superproject?
As already said: the link has to go into a submodule directory, which
will be checked out automatically with the clone of the supermodule.
> > Perhaps an option you want to have is to force a checkout
> > of AppBuild to make these symlinking itself when it detects
> > identical submodules links.
> >
> > Hmmm... the only problem with a symlink is that it can go wrong
> > when moved. Unfortunately, I do not have a good solution for
> > this. We can not make UNIX symlinks smart in any way.
> > Hardlinking directories would be a solution, but that is not
> > possible.
> >
>
> Wouldn't specifying the submodule path in the link object fit in well
> here? Then each "link object" can represent a checked out tree from
> the subproject in the superproject directory-structure.
The problem is not the representation in the git repository, but the
checked out module/submodule, where you need to use normal UNIX file semantics.
To move submodules around, the user should be able to just use
the normal UNIX "mv" commands, and git should be able to detect move
actions after the fact.
The simple thing here is that currently, git does not have this problem
as it tracks content, and does not even try to detect any moves at
commit time. This is different with submodules, as there, you want to
be able to track moves of any submodule root directories.
This now becomes a problem if you use symlinks to "unify" multiple checkouts
of the same submodule at multiple places in the supermodule, and move
the symlink around, as it easily can get dangling this way. Thus, you would
not have a way to see what submodule this link was talking about.
And for this thing, I do not see how your link object could help.
So it is better to use a simple submodule concept, and for this corner
cases, we perhaps could expect the user to fix e.g. a dangling symlink
to a previous submodule checkout himself, using a meaningful error message.
> > BTW, build project commits probably should not depend on any
> > history of other build commits.
>
> Why? Can you give an example here.
If you have a source commit chain A => B => C => D, you want
to make any build commits totally independent: you first only
are interested in a build commit for source versions A and D,
and later find out that a build commit for B and C would be nice,
too. If you force build commits into some history order, this
order now would be A => D => B => C, which makes no sense.
Build commit independence can easily be achieved by making every commit
parentless, without further history. You still have the link
to the source version via the submodule link in the tree.
But to not loose any such build commits, they have to appear
as tags or refs (unless integrated in another superproject
build commit).
> > > Link: /headers/lib1.h -> <lib1-commit3>/src/lib1.h
> > > Link: /bin/lib1.so -> <build1-commit>/i386/lib1/lib1.so
> > > Link: /bin/app1 -> <build1-commit>/i386/app1/app1
> > >
> > >
> > > <lib1-commit1>, <lib1-commit2> and <lib1-commit3> should be the same,
> > > dictated by the app1 project.
> >
> > I do not see any problem here. Symlinks are stored in the git repository.
> > As the AppBuild commit depends on App and LibBuild submodule commits, the
> > symlinks always should be correct.
>
> The main reason for these "links" are for versioning purposes: the
> uniqe SHA1 of the "link" representing a tree/blob in a version of the
> submodule should be "included" in the supermodules commit. Symlinks
> won't give that at all.
The version coupling will be there if the whole submodule is available
at some path in the supermodule checkout, as said above.
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Pazu @ 2006-12-15 21:49 UTC (permalink / raw)
To: git
In-Reply-To: <20061214223813.GC26202@spearce.org>
Shawn Pearce <spearce <at> spearce.org> writes:
> identical class file given the same input. I've seen times where
> it doesn't thanks to the automatic serialVersionUID field being
> somewhat randomly generated.
Probably offline, but… serialVersionUID isn't randomly generated. It's
calculated using the types of fields in the class, recursively. The actual
algorithm is quite arbitrary, but not random. The automatically generated
serialVersionUID should change only if you add/remove class fields (either on
the class itself, or to the class of nested objects).
*sigh* Java chases me. 8+ hours of java work everyday, and when I finally get
home… there it is, looking at me again. *sob*
-- Pazu
^ permalink raw reply
* Re: git-fetch fails with error code 128
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Nicolas Pitre
In-Reply-To: <200612150946.14439.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> I hadn't realised it was quite a serious as these responses
> are making it sound. I'll gather more precise data upon my
> return home.
> ...
> Clearly it is version-specific. I'll do a bit of bisection
> later and see if I can nail the problem down.
Thanks --- very much appreciated. When it comes to
inter-repository object transfer, we take compatibility very
seriously.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4581C83A.10907@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Shawn Pearce wrote:
>>
>> About the only trouble that can cause is a failed push when
>> git-receive-pack needs to generate the reflog entry but cannot
>> get the user's committer data because their gecos information
>> doesn't exist.
>
> In that case, it would be best if it let the commit go through using
> only the username. Reflogs are fixable afterwards, so there's no real
> harm done.
This sounds sensible, regardless of the current discussion on
the default 'logallrefupdates' setting.
Volunteers?
^ permalink raw reply
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
To: Jerome Lovy; +Cc: git, Johannes Schindelin, Andy Parkins
In-Reply-To: <458179B4.7020408@brefemail.com>
Jerome Lovy <t2a2e9z8ncbs9qg@brefemail.com> writes:
> Johannes Schindelin wrote:
>> On Thu, 14 Dec 2006, Andy Parkins wrote:
>>
>>> "master" shouldn't get special treatment; making different log
>>> messages based on the name of the branch is bad form. What if a
>>> user likes "my/master" or "my/head" as their master branch?
>>
>> I do not agree. There is usually a principal branch, where you
>> collect the topics, and you do want to treat that special. As for
>> the name: better have a convention here than configurability. You
>> would not want "git" to be called "guitar" for some users, just
>> because they happen to like that name more, either, right?
>
> because I like the pattern framework described in the book "Software
> Configuration Management Patterns", I like to use "mainline" instead
> of "master", for example.
Tough. Like it or not, 'master' has been the name of the
default branch since very early days of git (May 30, 2005).
I think you guys are barking up the wrong tree. I do not agree
it is wrong to treat the principal branch (or branches, such as
my 'master' and 'maint', or Jeff's 'ALL' and 'upstream') in a
different way from other branches.
Quite the opposite. It is a wonderful thing for something like
fmt-merge-message.
The recommended workflow when you have topic branches is to cook
new things in the topics and merge them into principal branches,
and never merge the other way or across topics unless you
absolutely need to (i.e. the topic's evolution depends on
something new in your principal branches or another topic). So
merging into your principal branch is a normal event and giving
short message makes tons of sense, while merging into a topic is
an abnormal situation that warrants "into this-topic" along with
an explanation why that unusual cross merge was needed.
What we could improve is to allow people to use different names
other than 'master' for their principal branches, to help use of
words like 'mainline' and 'upstream'. We can have a new
configuration under "branch.*" namespace to mark branches that
tells fmt-merge-msg to drop "into branch" part from its output.
When you have more than one principal branches, it may be useful
be able to tell which principal branch was merged into with a
particular merge, and in such a situation, you may want your
config to tell fmt-merge-msg not to drop "into branch" for any
branch.
On this "master is not special" topic, I would accept the
'status' patch that always makes it to say "on this branch" for
all branches, but this is not because 'master' is not special.
Committing on principal branches and committing on topic
branches both happen as a normal event, and I think it is not
unusual to have more than one principal branches in an advanced
usage scenario. It is very prudent thing to remind the user
what branch he is on, so that he can tell he is about to make a
commit on a wrong branch.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
To: Shawn Pearce; +Cc: jnareb, Andy Parkins, git
In-Reply-To: <eluhk3$pv7$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Shawn Pearce wrote:
>
>> Andy Parkins <andyparkins@gmail.com> wrote:
>>> * git-show-branch output is cryptic.
>>
>> Agreed. I still don't know how to read its output. So I just
>> don't use it. Ever. :-)
>
> And the way it uses it's options is even more cryptic, and differs from
> other similar commands.
(Jakub, please do not drop people from cc: list; you were asked
more than once).
Ok, so what's the action you guys are proposing?
(1) show-branch output is cryptic and it does not do anything
useful. Drop it.
(2) show-branch output is cryptic and I do not understand what
it is trying to do. Document it better.
(3) While I agree what show-branch is trying to do is useful,
its output is useless. Instead of showing an example
situation like this:
[ picture here ]
It should show the same situation like this:
[ improved picture here ]
(4) None of the above.
The same question goes for its input branch specification.
Personally, I find its input branch globbing very handy, and
often wish that 'git branch' had a '--list' option that lists
branches that match the glob pattern given on the command line,
not just listing everything when no parameter is given.
^ permalink raw reply
* Re: git fetch slow as molasses due to tag downloading
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612141701440.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> IMHO this should be solved as a filter: "git-show-ref --stdin
> --show-invalid". Thus, git does not have to traverse _every_ ref for
> _every_ incoming tag.
That sounds like a too specialized hack to me. We should first
speed up the general "--verify $ref" case; as you corrected me
earlier it still has a useless loop.
If it is still too slow (which I suspect it could be the case,
with fork+exec overhead), we should _also_ pursue the filter
approach, but even then I think "filter out the valid ones" is a
specialized hack, if you mean "show only the invalid one's
names" by --show-invalid.
It would make sense to do
$ git show-ref --show-invalid v1.0.0 v2.6.18
f665776185ad074b236c00751d666da7d1977dbe refs/tags/v1.0.0
- refs/tags/v2.6.18
(and its equivalent to take refs from --stdin) though.
^ permalink raw reply
* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Johannes Schindelin
In-Reply-To: <20061215002015.GI26202@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>>
>> On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
>>
>> > +int is_bare_git_dir (const char *dir)
>> > +{
>> > + if (!strcmp(dir, DEFAULT_GIT_DIR_ENVIRONMENT))
>> > + return 0;
>> > + const char *s = strrchr(dir, '/');
>> > + return !s || strcmp(s + 1, DEFAULT_GIT_DIR_ENVIRONMENT);
>> > }
>>
>> This function does not really determine if the repo is bare. I have no
>> better name for it, though.
>
> guess_if_bare_git_dir ?
>
> I struggled to name that thing because it can't really tell, its just
> guessing... but it is going to be right most of the time. Of course
> I'm sure there's some Git user somewhere who will confuse it.
I think the name is fine, but probably a comment in front would
help unconfuse people.
/* Does it look like a repository without a working tree? */
Unfortunately there currently are public bare repositories that
have index under them because they were primed by rsync from
developers' working repositories. I do not think it is
unreasonable to persuade owners of them to drop index -- then we
could use absence of $GIT_DIR/index as a strong clue that the
repository is bare.
^ permalink raw reply
* Re: [RFC] A unique way to express "all" (vs "add vs "update") ?
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, t2a2e9z8ncbs9qg
In-Reply-To: <4582906A.7020204@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Jerome Lovy wrote:
> ...
> But this isn't "commit" at all. It's "git add".
>
>> (This would allow the typical usage "git commit -u ." which is
>> barely longer than the current "git commit -a")
>>
>> For interface completeness, "git commit -u|--update <files>" could also
>> exist but would probably be of no use.
>>
>> To sum up, "all" would be consistently expressed with the <dir> syntax.
>> "git commit -a" would not mean "--all" anymore. Lastly, a distinction
>> would be made between "--add" and "--update":
>> - "git commit -add" would have the same semantics as "git add"
>
> This is bollocks. git commit should commit things. We'll be in some
> serious trouble if "git commit -a" stops working the way it has and
> starts just adding things to index.
I agree everything you said in your response to Jerome, except
for one thing.
We might want to allow:
$ git commit untracked.c tracked.c
to internally 'git add' untracked files while making the commit.
Currently you would get:
$ git commit untracked.c tracked.c
error: pathspec 'untracked.c' did not match any file(s) known to git.
Did you forget to 'git add'?
which is usable, safe, and helpful, so changing it to
automatically including it would not help the end user that
much and one could argue that it removes the safety which is a
bad idea.
So, let's not do this; sorry for the noise.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612150858.25988.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Thursday 2006 December 14 23:46, Junio C Hamano wrote:
> ...
>> I said "commit -b <newbranch>" and deliberately avoided saying
>> "commit -b <anybranch>", because I did not want to open another
>> can of worms while we are discussing so many good things
>> already, and my head can hold only a handful topics at once.
>
> Absolutely. I'd agree that only <newbranch> is worth even considering.
Just for the record, I do not necessarily agree. Committing a
small and obvious change out of context to an existing branch
makes just as much sense.
After all, with the example workflow in my message you responded
to, after running the "commit -b typofix" (which creates a new
branch) to record the first typo fix, I am sure that I would
want to record the second typofix I would find while on my topic
to go to the same typofix branch I previously created.
The 'can of worms' is that switching to an existing branch could
fail with conflicts. Although "git checkout -m" can help
sometimes, that is not something we would want to do in the
middle of doing something else on a topic. That's why I do not
think "commit -b <anybranch>" is a good idea.
Allowing the form for only a new branch makes an inconsistency
that is hard to explain to new people, and that is why I am not
in favor of having "commit -b <newbranch>" either.
^ permalink raw reply
* Re: svn versus git
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Nguyen Thai Ngoc Duy
In-Reply-To: <Pine.LNX.4.63.0612152117390.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Fri, 15 Dec 2006, Johannes Schindelin wrote:
>
>> On Fri, 15 Dec 2006, Nguyen Thai Ngoc Duy wrote:
>>
>> > About adding index support to git-show, yes it's really messy. index
>> > doesn't have tree objects.
>>
>> Insofar, it is not messy: git-show only shows _objects_. For example, "git
>> show :README" works as expected if you have a file called "README" in the
>> index...
>
> Note: this is not completely true. The index contains cache_trees...
Let's not go there.
I was reviewing the list of plumbing in Documentation/git.txt
last night, and I think ls-files is the only command that user
may still want to use from the command line every day.
I originally thought that it would only be after a conflicted
merge, always with -u option, but some people seem to find that
"ls-files --others" and friends are useful (I never use that
myself) and if so what it does really in the realm of Porcelain.
I haven't formed a firm opinion on this yet, but possibilities
are:
* we reclassify ls-files as a Porcelain-ish (but do not change
its UI nor defaults at all); we might want to give a shorter
alias to the command, though, if we go this route.
* we give '--list' option to 'git show' and in such a case,
lack of objects does not default to HEAD -- when no object is
given it internally diverts to cmd_ls_files() instead;
* we add 'git ls' command to give Porcelain-ish access to
ls-tree and ls-files.
^ permalink raw reply
* Re: git-fetch fails with error code 128
From: Nicolas Pitre @ 2006-12-15 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vy7p8omdh.fsf@assigned-by-dhcp.cox.net>
On Fri, 15 Dec 2006, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
>
> > I hadn't realised it was quite a serious as these responses
> > are making it sound. I'll gather more precise data upon my
> > return home.
> > ...
> > Clearly it is version-specific. I'll do a bit of bisection
> > later and see if I can nail the problem down.
>
> Thanks --- very much appreciated. When it comes to
> inter-repository object transfer, we take compatibility very
> seriously.
I really doubt it is a compatibility problem. The provided error
message may only result from the fact that patch_delta() has returned
NULL.
And since patch-delta is really simple, it doesn't have many reasons for
returning NULL: either the object store on either the remote or local
side is corrupted in which case a git-fsck-objects --full should catch
that, or the system ran out of memory.
^ permalink raw reply
* Re: git fetch slow as molasses due to tag downloading
From: Jakub Narebski @ 2006-12-15 22:27 UTC (permalink / raw)
To: git
In-Reply-To: <7vtzzwn7su.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> IMHO this should be solved as a filter: "git-show-ref --stdin
>> --show-invalid". Thus, git does not have to traverse _every_ ref for
>> _every_ incoming tag.
>
> That sounds like a too specialized hack to me. We should first
> speed up the general "--verify $ref" case; as you corrected me
> earlier it still has a useless loop.
>
> If it is still too slow (which I suspect it could be the case,
> with fork+exec overhead), we should _also_ pursue the filter
> approach, but even then I think "filter out the valid ones" is a
> specialized hack, if you mean "show only the invalid one's
> names" by --show-invalid.
>
> It would make sense to do
>
> $ git show-ref --show-invalid v1.0.0 v2.6.18
> f665776185ad074b236c00751d666da7d1977dbe refs/tags/v1.0.0
> - refs/tags/v2.6.18
>
> (and its equivalent to take refs from --stdin) though.
Nice idea. And having '-' is probably better than using
00000000000000000000000000000000000000000 as for non-existing objects.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: svn versus git
From: Nicolas Pitre @ 2006-12-15 22:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Nguyen Thai Ngoc Duy
In-Reply-To: <7v64ccomdc.fsf@assigned-by-dhcp.cox.net>
On Fri, 15 Dec 2006, Junio C Hamano wrote:
> * we add 'git ls' command to give Porcelain-ish access to
> ls-tree and ls-files.
That seems the most sensible to me.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Jakub Narebski @ 2006-12-15 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, Andy Parkins, git
In-Reply-To: <7vhcvwomde.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Shawn Pearce wrote:
>>
>>> Andy Parkins <andyparkins@gmail.com> wrote:
>>>> * git-show-branch output is cryptic.
>>>
>>> Agreed. I still don't know how to read its output. So I just
>>> don't use it. Ever. :-)
>>
>> And the way it uses it's options is even more cryptic, and differs from
>> other similar commands.
>
> (Jakub, please do not drop people from cc: list; you were asked
> more than once).
The problem is that I'm not subscribed to git mailing list; I usually
read it via GMane news<->mail interface, at
nntp://news.gmane.org/gmane.comp.version-control.git
First, in this interface I have only the last author and not the full
Cc: list. Second, when I reply _both_ via email (adding authors if
necessary) and to news, people receiving my reply don't have (I guess)
git@vger.kernel.org in Cc: list, so sometimes the discussion drops off
the list. Third, if I add git mailing list address when replying via
mail, vger server blocks email from gmane stating
Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 9): 501 5.1.3 Path data: Had characters unsuitable for an rfc821-string
When email is sent _directly_ to me (i.e. I'm on Cc: list) I try
to preserve Cc: list.
> Ok, so what's the action you guys are proposing?
>
> (1) show-branch input is cryptic and it does not do anything
> useful. Drop it.
>
> (2) show-branch input is cryptic and I do not understand what
> it is trying to do. Document it better.
[...]
I'm just used to the way revisions are specified to other history
viewers: git-log (via git-rev-list), gitk, qgit. git-show-branch
is a bit odd man out here. "git-show-branch ref1 ref2 ref3"
is (without --more=n) like
git rev-list ref1 ref2 ref3 --not $(git merge-base ref1 ref2 ref3)
Which is handy for git-show-branch, but odd. Perhaps we should add
--xor option to git rev list for the above, i.e.
git rev-list A...B ==
== git rev-list A B --not $(git merge-base A B)
git rev-list --xor A B C ==
== git rev-list A B C --not $(git merge-base A B C)
> Personally, I find its input branch globbing very handy, and
> often wish that 'git branch' had a '--list' option that lists
> branches that match the glob pattern given on the command line,
> not just listing everything when no parameter is given.
It is odd (git branch not having --list with globbing) also because
'git tag' has globbing support.
--
Jakub Narebski
^ permalink raw reply
* [PATCH] gitweb: Add title attribute to ref marker with full ref name
From: Jakub Narebski @ 2006-12-15 22:49 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Add title attribute, which will be shown as popup on mouseover in
graphical web browsers, with full name of ref, including part (type)
removed from the name of ref itself. This is useful to see that this
strange ref is StGIT ref, or it is remote branch, or it is lightweigh
tag (with branch-like name).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5ea3fda..5eaab05 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -856,7 +856,8 @@ sub format_ref_marker {
$name = $ref;
}
- $markers .= " <span class=\"$type\">" . esc_html($name) . "</span>";
+ $markers .= " <span class=\"$type\" title=\"$ref\">" .
+ esc_html($name) . "</span>";
}
}
--
1.4.4.1
^ permalink raw reply related
* Re: What's in git.git (stable)
From: Carl Worth @ 2006-12-15 22:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vmz5oomdf.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]
> The 'can of worms' is that switching to an existing branch could
> fail with conflicts.
One fix for this would be the idea I've proposed to have a new flag
for "git checkout" to 'stash' the dirty state in the current branch
before switching.
Then, there wouldn't be a problem to implement "commit -b <anybranch>"
on top of the stashing checkout.
I think the only real problem with the idea of having dirty changes
stashed in a branch is that git already allows dirty changes to be
carried while switching to a branch, (with or without -m). And doing
both of those at once would lead to an ugly new conflict situation,
(where _neither_ of the conflicted states exist as exposed tree
objects). Even if there were no conflict, it would mingle two
different sets of local modifications, and that could be unkind as it
might be hard for the user to separate them if they didn't want them
mingled.
If someone were to pursue this idea, I think it would be reasonable to
just make that case an error, "Cannot carry local modifications when
checking out a branch with stashed modifications." That message could
even suggest the user use the stash option to leave the local
modifications behind when doing the checkout.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] A unique way to express "all" (vs "add vs "update") ?
From: Carl Worth @ 2006-12-15 23:07 UTC (permalink / raw)
To: t2a2e9z8ncbs9qg; +Cc: git
In-Reply-To: <elu1cn$k3$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
On Fri, 15 Dec 2006 12:38:51 +0100, Jerome Lovy wrote:
> While I am very happy with the refactorings undertaken with regard to
> "git add/git commit" (both for UI and documentation), I am still a
> little confused by the different ways I seem to find to express the idea
> "I want to add (sort of) all file contents".
I agree that there have been huge improvements---particularly in
documentation. So thanks to everybody!
Here's a simpler idea that might add the unification you're looking
for. How about a new option:
git add -a|--all
This would allow "git commit -a|--all" to be understood as a simple
helper for:
git add -a|--all
git commit
That kind of unification seems like it could be helpful while learning
things. And I believe I've even wanted to do the "git add -a"
operation before, so I think it might be useful in its own right at
times, (though I can't think of a good example of why at the moment,
so perhaps its not that important).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's in git.git (stable)
From: Johannes Schindelin @ 2006-12-15 23:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0612151029080.18171@xanadu.home>
Hi,
On Fri, 15 Dec 2006, Nicolas Pitre wrote:
> On Fri, 15 Dec 2006, Jakub Narebski wrote:
>
> > It would be nice to have some generic place in git config to specify
> > default options to git commands (at least for interactive shell). It
> > cannot be done using aliases. Perhaps defaults.<command> config variable?
>
> I would say the alias facility has to be fixed then.
>
> In bash you can alias "ls" to "ls -l" and it just works.
So, why not use bash aliases?
Frankly, what git aliases try to achieve is a little bit different from
bash aliases. Bash knows exactly when a command is interactive, and has a
clear advantage there. Git _cannot_ know.
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git (stable)
From: Johannes Schindelin @ 2006-12-15 23:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200612152348.17997.jnareb@gmail.com>
Hi,
On Fri, 15 Dec 2006, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > (Jakub, please do not drop people from cc: list; you were asked
> > more than once).
>
> The problem is that I'm not subscribed to git mailing list;
So subscribe. I am sure I lost quite some of your responses to my emails,
_just_ because you happen to kill me from the Cc: list.
IOW if you expect answers, _please_ adher to net standards.
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-15 23:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shawn Pearce, Andy Parkins, git
In-Reply-To: <200612152348.17997.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> I'm just used to the way revisions are specified to other history
> viewers: git-log (via git-rev-list), gitk, qgit. git-show-branch
> is a bit odd man out here. "git-show-branch ref1 ref2 ref3"
> is (without --more=n) like
>
> git rev-list ref1 ref2 ref3 --not $(git merge-base ref1 ref2 ref3)
>
> Which is handy for git-show-branch, but odd.
I hate to sound harsh, but...
Then you do not understand show-branch at all. Not having to
say the "--not merge-base" part is NOT about being handy, but is
the central part of what show-branch does. The command is about
showing the commits that are on only some of the branches but
not on others.
Other commands you listed above are all based on rev-list logic
of painting commits in two colors (either UNINTERESTING or
~UNINTERESTING) and being able to combine the set using "A..B",
"^A B", and "A B --not C" notations all make sense. All
combinations work as set operation -- start from union of
commits reachable from positive (i.e. not prefixed with ^) refs,
and subtract set of commits reachable from any negative ref.
What show-branch does cannot be expressed with that two-color
logic; it needs to use N colors for N input refs. After digging
from the tips deep enough, you would find the common merge-base
and after that point it is not interesting to show anything
anymore, and that is how it stops output.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Torgil Svensson @ 2006-12-15 23:43 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: R. Steve McKown, Linus Torvalds, git
In-Reply-To: <200612152242.50472.Josef.Weidendorfer@gmx.de>
On 12/15/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> That all sounds fine, but how do you create such symlinks in practice?
I'm very open to suggestions here, but the concept growing in my head
is based around Linus 'module'-file and keep things simple. A git
configuration file that specifies:
* link name for reference
* local path to link
* submodule source
* submodule path to tree/blob
* submodule commit / HEAD / branch
* options (depth-limit , ...)
I'm reconsidering having the path-name in the link, it should be
sufficient to have two SHA1's, one for the commit and one for the
tree/blob. Super-module should have the tree/blob in it's database so
that the link part only is there for version information and reference
(checking dirty state or history on the submodule). This way it easy
to clone the super-project and use it without having to map up all
sub-project sources. Sub-project sources is not important for version
information and could always be specified in the project in a
README-type of file.
> Especially, what is the SCM user supposed to do to change the link
> target, ie. from
> <commit>/path/to/subtree
> to
> <commit>/path2/to2/subtree2
> ?
> Should this do a re-checkout at the other point?
That would be a change in the modules file, maybe through a command
that also fixes the link. The link will have to be updated in the
index and commited as normal.
> By linking a file from a submodule, such a link seems to force that
> this file has to be at a fixed position in the submodule. Otherwise,
> some magic has to happen when the file is moved in the submodule,
> possibly leading to a dangling link, eg. if the whole subdirectory
> specified in the link is removed.
Since we have the SHA1 (this is what we're using) and tree/blob
information in the super-modules database the change itself is not a
problem. The problem is to track renames/moves and your remove case in
the submodule. The tool that tracks the submodule should probably
warn/exit here and we would fix up the modules file manually.
> IMHO this is getting way to complex.
One of complex situation here as I see it is the ability to handle to
track/checkout only a subset (tree/blob) of the submodule. This is
also quite an important feature - in my example it means the
difference of tracking one header file versus the whole source.
> If you only want to check out part of a submodule, this should be
> done with path-limiting checkouts, which should be a feature totally
> independent from submodules.
If we can do path-limiting checkouts on a repo (module) we also can do
it on a sub-module since they are exactly the same. This is a very
powerful feature and it'd be a huge waste if it wasn't allowed for a
super-module to do on submodules.
> And if you want to limit the number of objects transferred in cloning
> of a subproject, it is better to further split this subproject into
> multiple subprojects itself.
What if we have no control of the submodule? This can be tracked from
upstream, sourceforge, another company, etc. The submodule will often
live their own life and could be X, kernel, gcc, cairo, whatever, ...
> The problem is not the representation in the git repository, but the
> checked out module/submodule, where you need to use normal UNIX file semantics.
> To move submodules around, the user should be able to just use
> the normal UNIX "mv" commands, and git should be able to detect move
> actions after the fact.
If we disregard the commit info, the link will act exactly as a normal
tree/blob. Git can know we're moving a subproject by watching the
module file. The main problem is to keep modules file up-to-date with
reality. We could enforce module file validity by disallowing such
operations and let the user do a "force" operation which also alters
the modules file.
> This now becomes a problem if you use symlinks to "unify" multiple checkouts
> of the same submodule at multiple places in the supermodule, and move
> the symlink around, as it easily can get dangling this way. Thus, you would
> not have a way to see what submodule this link was talking about.
The symlink only exists in the modules file. We only have the SHA1's
at the tree-level and there we have everything underneath the
tree/blob SHA1 in our database. We will only know if the modules
symlink file is dangling next time we fetch from the submodule - here
we would notify the user but our database is still consistent.
> If you have a source commit chain A => B => C => D, you want
> to make any build commits totally independent: you first only
> are interested in a build commit for source versions A and D,
> and later find out that a build commit for B and C would be nice,
> too. If you force build commits into some history order, this
> order now would be A => D => B => C, which makes no sense.
It makes no sense because the user seem to have act irrationally. The
commit-chain is completely valid as it has tracked the correct history
of the builds. I can't see any problems here, the build-project is
independent of the source-project with it's own history. We can hope
the user has given good explanations for his/her actions in the commit
messages though.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-15 23:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Jakub Narebski
In-Reply-To: <Pine.LNX.4.63.0612160023340.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 15 Dec 2006, Jakub Narebski wrote:
>
>> Junio C Hamano wrote:
>>
>> > (Jakub, please do not drop people from cc: list; you were asked
>> > more than once).
>>
>> The problem is that I'm not subscribed to git mailing list;
>
> So subscribe. I am sure I lost quite some of your responses to my emails,
> _just_ because you happen to kill me from the Cc: list.
>
> IOW if you expect answers, _please_ adher to net standards.
FWIW, I also read the list traffic through gmane news gateway.
I am subscribed and my mail filter drops the mails from the list
into a dedicated mailbox, but that is purely for my own backup
and I usually do not look at it otherwise.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Johannes Schindelin @ 2006-12-16 0:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vac1on2oh.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 15 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 15 Dec 2006, Jakub Narebski wrote:
> >
> >> Junio C Hamano wrote:
> >>
> >> > (Jakub, please do not drop people from cc: list; you were asked
> >> > more than once).
> >>
> >> The problem is that I'm not subscribed to git mailing list;
> >
> > So subscribe. I am sure I lost quite some of your responses to my emails,
> > _just_ because you happen to kill me from the Cc: list.
> >
> > IOW if you expect answers, _please_ adher to net standards.
>
> FWIW, I also read the list traffic through gmane news gateway.
So, how do you tackle the problem Jakub evidently has, namely to reply to
all the people who your reply refers to?
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