* Re: [PATCH 4/5] commit: allow --pretty= args to be abbreviated
From: Junio C Hamano @ 2006-05-14 23:47 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <1147619963765-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> commit.c | 42 +++++++++++++++++++++++++++++-------------
> 1 files changed, 29 insertions(+), 13 deletions(-)
This is applicable without the gitopt changes, but I have a
feeling that when we think about abbreviations the users would
expect the leading substring abbreviation, not strstr().
While "git log --pretty=lle" or "git log --pretty=or" might be
unambiguous, I think that is trying to be too cute and
confusing, especially if somebody picks up that habit by
watching others type such a cute abbreviations.
That comment probably incidentally applies to your bigger
patches.
^ permalink raw reply
* Re: [PATCH 5/5] diff: parse U/u/unified options with an optional integer arg
From: Eric Wong @ 2006-05-14 23:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605140931410.3866@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Sun, 14 May 2006, Eric Wong wrote:
> >
> > -u (lowercase) now accepts an optional arg, like -U (GNU diff
> > -u also has this behavior).
>
> Actually, modern GNU "diff -u5" will say
>
> diff: `-5' option is obsolete; use `-U 5'
> diff: Try `diff --help' for more information.
>
> and exit.
>
> I'm not entirely sure why, but I think it's because "u" can be mixed (ie
> with something like "-urN"), while "U" cannot. The GNU diff rule seems to
> be that simple arguments can be mixed together, but arguments with
> parameters cannot. Which sounds sane.
Interesting. With _POSIX2_VERSION < 200112, diff is happy to accept
-u5. Setting _POSIX2_VERSION >= 200112 causes it to burp, however.
It turns out -u5 is actually short for -u -5, but I (and apparently some
other people) have always assumed -u5 worked like -U5. POSIX doesn't
like -<num> switches, however, but we support it regardless in rev-list.
I prefer that it works the -u5 way, of course :)
Also, I find integer arguments being bundled with other parameters to be
pretty nice feature, but it's easy to disable if users don't like it:
diff --git a/gitopt.c b/gitopt.c
index 9e85247..139cd2d 100644
--- a/gitopt.c
+++ b/gitopt.c
@@ -270,17 +270,9 @@ static const char * parse_bundled(struct
} else if (s->arg_fl) {
if (*cur) {
/* no space between the arg and opt switch: */
- if (s->arg_fl & ARG_IS_INT) {
- /* we know to handle stuff like:
- * -h24w80 => -h=24 -w=80 */
- char *endptr = (char *)cur;
- strtol(cur, &endptr, 10);
-
- while (cur < endptr)
- *c++ = *cur++;
- } else if (s->arg_fl & ARG_ONE) {
- /* unfortunately, other args are less
- * clear-cut */
+ if (s->arg_fl & ARG_ONE) {
+ /* don't attempt further unbundling, extra
+ * chars are arguments */
while (*cur)
*c++ = *cur++;
}
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH] gitk: Display commit messages with word wrap
From: Paul Mackerras @ 2006-05-14 23:34 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git
In-Reply-To: <20060514151456.GA18012@procyon.home>
Sergey Vlasov writes:
> Some people put very long strings into commit messages, which then
> become invisible in gitk (word wrapping in the commit details window is
> turned off, and there is no horizontal scroll bar). Enabling word wrap
> for just the commit message looks much better.
Well... you can scroll in any direction with mouse button 2, but ok...
> + $ctext insert end "\n" {}
Why are you adding the superfluous {} ?
> - set comment {}
> + set headers {}
Why are you changing the name here? Your commit description doesn't
address either of these points.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: Display commit messages with word wrap
From: Junio C Hamano @ 2006-05-14 23:30 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git
In-Reply-To: <20060514151456.GA18012@procyon.home>
Sergey Vlasov <vsu@altlinux.ru> writes:
> Some people put very long strings into commit messages, which then
> become invisible in gitk (word wrapping in the commit details window is
> turned off, and there is no horizontal scroll bar). Enabling word wrap
> for just the commit message looks much better.
I do not mind it myself but IIRC gitk's "no wrapping" was made
because people found wrapping annoying; maybe a runtime
configuration option?
^ permalink raw reply
* Re: [PATCH] Add "--branches", "--tags" and "--remotes" options to git-rev-parse.
From: Junio C Hamano @ 2006-05-14 23:24 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP043948149786B7EE06DED3AEA20@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> On a related note, would it be okay to change "git tag -l" to
> produce a list of tags without the "tags/" prefix in front of
> every tag as it does now? Wanted to use the new "git
> rev-parse --tags" instead of "find" to produce the list but am
> not sure how important backward compatibility is in that case.
I do not have problem with that, but somebody else's script
might; Cogito seems not to mind.
Something like this perhaps?
-- >8 --
diff --git a/git-tag.sh b/git-tag.sh
index dc6aa95..2286ad5 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -28,11 +28,10 @@ do
cd "$GIT_DIR/refs" &&
case "$#" in
1)
- find tags -type f -print ;;
- *)
- shift
- find tags -type f -print | grep "$@" ;;
+ set x . ;;
esac
+ shift
+ find tags -type f -print | sed -e 's|^tags/||' | grep "$@"
exit $?
;;
-m)
^ permalink raw reply related
* Re: Tracking branch history
From: Junio C Hamano @ 2006-05-14 23:16 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20060513T140528-554@post.gmane.org>
Elrond <elrond+kernel.org@samba-tng.org> writes:
> Daniel Barkalow <barkalow <at> iabervon.org> writes:
>
>>
>> One feature that might make git more intuitive to people is if we were to
>> additionally track the history of what commit was the head of each branch
>> over time. This is only vaguely related to the history of the content, but
>> it's well-defined and sometimes significant.
>>
>> E.g., if you know that two weeks ago, what you had worked, but it doesn't
>> work now, you can use git-bisect to figure out what happened, but first
>> you have to figure out what commit it was that you were using two weeks
>> ago. Two weeks ago, we had that information, but we didn't keep it.
>
> On a related issue:
>
> Looking at a commit:
> commit id-commit
> parent id-1
> parent id-2
> parent id-3
>
> Merge branch 'branch-2', 'branch-3'
>
> One can tell the name of the branches for id-2 and id-3 (branch-2, 3),
> but one can't tell the name of id-1.
That's deliberate. If you are merging into a branch other than
"master", the message would say:
commit ea892b27b15fbc46a3bb3ad2ddce737dc6590ae5
Merge: 7278a29... 8d48ad6...
Author: Junio C Hamano <junkio@cox.net>
Date: Sat May 13 18:49:54 2006 -0700
Merge branch 'lt/config' into next
* lt/config:
git config syntax updates
Another config file parsing fix.
checkout: use --aggressive when running a 3-way merge (-m).
Fix git-pack-objects for 64-bit platforms
fix diff-delta bad memory access
The point is to keep the punch line as short and meaningful for
the most common case.
^ permalink raw reply
* Re: Tracking branch history
From: Junio C Hamano @ 2006-05-14 23:14 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060513181816.GA12475@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Log ref updates to logs/refs/<ref>
>
> If config parameter core.logRefUpdates is true then append a line
> to .git/logs/refs/<ref> whenever git-update-ref <ref> is executed.
I cannot decide if a parameter makes more sense, or just making
the existence of such a file a cue is better. For example, I do
not much care about when I updated each of my topic branch head,
while I do care about master, next, and pu branches. A global
parameter would make this black-or-white choice, while opening
the log without O_CREAT and write things out only when the log
file exists might make things as easy and controllable.
I could "touch" the ones I care about to prime the process.
Hmm?
^ permalink raw reply
* Re: Branch relationships
From: Josef Weidendorfer @ 2006-05-14 23:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xp4ntbf.fsf@assigned-by-dhcp.cox.net>
On Monday 15 May 2006 00:19, you wrote:
> > I suppose "branch.<branch name>.origin" is still the way to go for
> > specifying the upstream?
>
> Probably "origin" is a better name for it; I was assuming
> "branch.<branch name>.remote = foo" refers to a [remote "foo"]
> section and means "when on this branch, pull from foo and merge
> from it".
Maybe.
But there is a misunderstanding. I wanted the branch attribute "origin"
to specify the upstream _branch_, not a remote.
After a "git clone", we would have
[remote "origin"]
url = ...
fetch = master:origin
[branch "master"]
origin = "origin" ; upstream of master is local branch "origin"
[branch "origin"]
tracksremote ; bool
Now adding a further development branch for remote branch "topic", we would add
[remote "origin"]
...
fetch = topic:tracking-topic
[branch "local-topic"]
origin = "tracking-topic"
[branch "tracking-topic"]
tracksremote
Now, a "git pull" on branch "local-topic" does the right thing: it fetches
from remote "origin", as "tracking-topic" is given in a refspec there, and merges
"tracking-topic" to the current branch "local-topic", as given by the origin
attribute.
This also extends to local upstreams: a "git checkout -b topic2 master" would
append
[branch "topic2"]
origin = "master"
and a "git pull" on topic2 would merge the upstream "master".
Josef
^ permalink raw reply
* Re: Branch relationships
From: Junio C Hamano @ 2006-05-14 22:19 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200605150001.48548.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>> Exactly. I would _want_ to push to both with single action when
>> I say "git push ko-private". Actually I have _never_ felt need
>> to, but Linus wanted it first and I think it makes sense.
>
> Hmmm. Isn't this a solution for a very special use-case?
> You even can not specify different push lines for the 2 URLs.
> I think you want an alias name for a group of remotes here?
Perhaps.
The "push to multiple places" is mostly for Linus backing things
up, and I tend to agree that your "alias" notation makes things
appear to be more general. However, I do not think you would
want to push to two different places with different branch
mappings, so I suspect that generality is not buying you much
while making things more easily misconfigured.
> I suppose "branch.<branch name>.origin" is still the way to go for
> specifying the upstream?
Probably "origin" is a better name for it; I was assuming
"branch.<branch name>.remote = foo" refers to a [remote "foo"]
section and means "when on this branch, pull from foo and merge
from it".
^ permalink raw reply
* Re: The git newbie experience
From: Junio C Hamano @ 2006-05-14 22:09 UTC (permalink / raw)
To: Tommi Virtanen; +Cc: git
In-Reply-To: <446778B8.7080201@inoi.fi>
Tommi Virtanen <tv@inoi.fi> writes:
> My best idea so far is to add a "git commit -A" option, that
> essentially does the "update-index --refresh". Whenever index
> has a file state != HEAD, update-index it. The modified unrelated
> files will have index state == HEAD. Or altering "git commit -a"
> to do that.
I am not sure what you are trying to achieve by --refresh. It
does not update the object names in the index. Maybe you are
thinking about --again, but that is when you did something to
the index yourself, so it would not buy you much in the "novice
faced with merge" case.
Anyway, I think the time to commit is too late to save somebody
who does not understand the index. How would you explain why
you sometimes need to use -A and sometimes -a? That is why I
suggested to make "git pull" and "git merge" refuse to work if
there are local changes for novice users, where the definition
of novice is "git commit -a" is the only way to make a commit.
We can have [core] novice = yes in .git/config for that.
If somebody does not understand the index, if the merge is
prevented because the local change does conflict with it, how
would you explain why sometimes you can merge and sometimes you
cannot?
But if you insist going that route, I would say we could make
"git commit -a" on a merge commit to do a bit more magic.
For example, we could make -a do something special for a merge
by looking at the presense of .git/MERGE_HEAD.
- if "commit -a", and without .git/MERGE_HEAD, just grab
all the local modifications that are not in index yet,
and commit it.
- upon "commit -a", and when .git/MERGE_HEAD exists,
grab the paths that ls-files -u reports, update-index
them. Other automerged paths are already registered
in the index.
> Except, trying to solve usability problems by _adding_ options
> is just insane.
I am not sure if it is "usability" but additional option to
simplify things does not sound right, I'd agree.
> For example, we had a case where we absolutely _had_ to keep
> an ugly workaround in the tree, in a file not otherwise
> edited, but we definitely did not want to commit the kludge,
> at least not to the branch that was really being worked on. So
> such restricted mode would just have meant either people could
> not merge, or they had to use index anyway.
Your example is a very ill-thought out one.
If you are leaving the uncommitable kludge around, you cannot be
using "commit -a" with the normal non-merge workflow. Why
would you worry about not being able to do "commit -a" on a
merge then?
For the beginning user without index, I would rewrite your
scenario like this.
- Jack is a beginning user of git and does not (want to) understand
the index (right now).
- Jack works on branch X, say his HEAD points to X1. He has an edited,
uncommitted files with the names A, B and C.
- Jack wants to pull new changes made by others to his branch.
But "git merge" invoked from "git pull" says he needs to stash
away the local changes to do the merge.
- Jack stashes away what he has been working on and cleans up
his mess.
git diff >P.diff
git checkout HEAD A B C
- Jack then pulls. There are merge conflicts in files D, E, ..., Z.
- Jack resolves the merge conflicts and is ready to commit the resulting
merge. Note files A, B and C do not have his unfinished work.
There is no "if Jack does this or that" problem; he says "git
commit -a" because that is the only "commit" command he knows
about.
- Jack then reapplies what he stashed away with "git apply P.diff"
and keeps working.
Maybe "git stash" command that does "git diff --full-index" with
some frills, and "git unstash" command which does an equivalent
of "git am -3" would help this workflow (bare "git apply" does
not do the three-way merge like am does).
^ permalink raw reply
* Re: Branch relationships
From: Josef Weidendorfer @ 2006-05-14 22:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr72w2thu.fsf@assigned-by-dhcp.cox.net>
On Sunday 14 May 2006 23:20, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> >> ; my private build areas on the kernel.org machines
> >> [remote "ko-private"]
> >> url = "x86-64-build.kernel.org:git"
> >> url = "i386-build.kernel.org:git"
> >> push = master:origin
> >> ...
> >
> > specifies that "git push" should push to both URLs?
>
> Exactly. I would _want_ to push to both with single action when
> I say "git push ko-private". Actually I have _never_ felt need
> to, but Linus wanted it first and I think it makes sense.
Hmmm. Isn't this a solution for a very special use-case?
You even can not specify different push lines for the 2 URLs.
I think you want an alias name for a group of remotes here?
Why not
[remotealias "ko-private"]
remote = "ko-private-x86-64"
remote = "ko-private-i386"
Neverless, this wasn't the thing I was after.
> That is what "branch.foo.remote = this-remote" is about.
OK. Sorry, I somehow missed this.
> When
> working on foo branch, use what is described in
> remote."this-remote" section for "git pull".
> remote."this-remote" would have url and one or more fetch lines,
> and as usual the first fetch line would say "merge this thing".
> This gives the continuity in semantics while migrating from
> .git/remotes/foo to [remote "foo"] section of the config file.
The only thing I wanted to discuss in this thread is exactly the
limitation of "as usual the first fetch line..." by the branch
attribute "origin", which lead me to the alternative "tracksremote"
attribute. Sorry about any confusion.
I suppose "branch.<branch name>.origin" is still the way to go for
specifying the upstream?
Josef
^ permalink raw reply
* Re: The git newbie experience
From: Junio C Hamano @ 2006-05-14 21:26 UTC (permalink / raw)
To: Tommi Virtanen; +Cc: git
In-Reply-To: <446778B8.7080201@inoi.fi>
Tommi Virtanen <tv@inoi.fi> writes:
> (21:08:34) ***gitster personally considers getting more users a very
> high priority but agrees that from usability point of view, having a
> mode to expose "stripped down" set of features for simple needs would be
> beneficial.
>
> That I can 100% agree with.
Sorry, I personally consider it is not a very high priority; the
above is a typo (otherwise "but agrees" does not make _any_
sense).
The rest of the message I'll find a time to comment on
separately, but I am in the middle of migrating the development
environment, so it might take some time.
Oh, and please send patches cc'ed to the list at least for a few
days, because I am fighting with fetchmail/getmail configuration
right now and might lose a few mails while doing so.
^ permalink raw reply
* Re: Branch relationships
From: Junio C Hamano @ 2006-05-14 21:20 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200605142249.17508.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Sunday 14 May 2006 19:36, Junio C Hamano wrote:
>> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>>
>> > On Saturday 13 May 2006 23:22, you wrote:
>> >> * remotes/ information from .git/config (js/fetchconfig)
>> >> ...
>> >> [branch "master"]
>> >> remote = "ko-private"
>
> I still do not understand the semantic of this line.
> Is this supposed to do "git pull ko-private" as default pull
> action and "git push ko-private" as default push?
>
> So using
>
>> ; my private build areas on the kernel.org machines
>> [remote "ko-private"]
>> url = "x86-64-build.kernel.org:git"
>> url = "i386-build.kernel.org:git"
>> push = master:origin
>> ...
>
> specifies that "git push" should push to both URLs?
Exactly. I would _want_ to push to both with single action when
I say "git push ko-private". Actually I have _never_ felt need
to, but Linus wanted it first and I think it makes sense.
> This is really confusing: Is the remote "ko-private" now at
> "x86-64-build.kernel.org:git" or at "i386-build.kernel.org:git" ?
Neither.
Perhaps reading my comment on #git log from yesterday or so,
where I talk about ".git/branches is about configuration
per-local branches, and .git/remotes is about giving a
short-hand to remote repositories that are used often",
might be helpful.
> Neverless, I missed the info "Which branch should be merged in a default
> pull after fetching the given branches from remote". I understand that
> this is not needed in your workflow, as you have no upstream.
Not with git but in other projects I do.
That is what "branch.foo.remote = this-remote" is about. When
working on foo branch, use what is described in
remote."this-remote" section for "git pull".
remote."this-remote" would have url and one or more fetch lines,
and as usual the first fetch line would say "merge this thing".
This gives the continuity in semantics while migrating from
.git/remotes/foo to [remote "foo"] section of the config file.
>> > [branch "ko-master"]
>> > tracksremote = "master of ko-private"
>> >
>> > This also would specify that we are not allowed to commit on "ko-master".
>>
>> For my workflow, it is "master of ko"; your notation expresses
>> the same constraints more explicitly by being more special
>> purpose
>
> Why is this more special purpose?
It is more special purpose than just saying "do not touch this
myself". You are saying "do not touch this myself because it
tracks a remote". I do not think it is necessary to state the
reason.
> Perhaps an option "when pulling into this branch from a remote, also fetch
> all branches tracked from this remote", or another one "when fetching/pulling
> into this branch, update all other branches, too".
You already have "when fetching from this remote, fetch all
these branches and store them in the tracking branches", and
that is what .git/remotes/ is about. The [remote] section in
the configuration file has the same semantics. What problem are
you trying to fix by doing things differently?
^ permalink raw reply
* [PATCH] include header to define uint32_t, necessary on Mac OS X
From: Ben Clifford @ 2006-05-14 20:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Dennis Stosberg, git
In-Reply-To: <Pine.LNX.4.64.0605142056320.3038@mundungus.clifford.ac>
From: Ben Clifford <benc@hawaga.org.uk>
Date: Sun, 14 May 2006 21:34:56 +0100
Subject: [PATCH] include header to define uint32_t, necessary on Mac OS X
---
pack-objects.c | 1 +
sha1_file.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
2ee926ab9da67ef2a6ca28bb70954a33d65ba466
diff --git a/pack-objects.c b/pack-objects.c
index 1b9e7a1..5466b15 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -10,6 +10,7 @@ #include "csum-file.h"
#include "tree-walk.h"
#include <sys/time.h>
#include <signal.h>
+#include <stdint.h>
static const char pack_usage[] = "git-pack-objects [-q] [--no-reuse-delta] [--non-empty] [--local] [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list";
diff --git a/sha1_file.c b/sha1_file.c
index 631a605..3372ebc 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -13,6 +13,7 @@ #include "blob.h"
#include "commit.h"
#include "tag.h"
#include "tree.h"
+#include <stdint.h>
#ifndef O_NOATIME
#if defined(__linux__) && (defined(__i386__) || defined(__PPC__))
--
1.3.2.g5f7f2-dirty
^ permalink raw reply related
* Re: [PATCH] Fix git-pack-objects for 64-bit platforms
From: Ben Clifford @ 2006-05-14 20:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Dennis Stosberg, git
In-Reply-To: <7viroav534.fsf@assigned-by-dhcp.cox.net>
> It takes the uint32_t version but matches another place to use
> that type instead of "int" (which would not matter in next 10
> years perhaps).
This use of uint32_t breaks the build for me on Mac OS X. Including
<stdint.h> seems to make it work again. See following patch.
--
^ permalink raw reply
* Branch relationships (was:Re: git diff: support "-U" and "--unified" options properly)
From: Josef Weidendorfer @ 2006-05-14 20:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j4o33wc.fsf@assigned-by-dhcp.cox.net>
On Sunday 14 May 2006 19:36, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
> > On Saturday 13 May 2006 23:22, you wrote:
> >> * remotes/ information from .git/config (js/fetchconfig)
> >> ...
> >> [branch "master"]
> >> remote = "ko-private"
I still do not understand the semantic of this line.
Is this supposed to do "git pull ko-private" as default pull
action and "git push ko-private" as default push?
So using
> ; my private build areas on the kernel.org machines
> [remote "ko-private"]
> url = "x86-64-build.kernel.org:git"
> url = "i386-build.kernel.org:git"
> push = master:origin
> ...
specifies that "git push" should push to both URLs?
This is really confusing: Is the remote "ko-private" now at
"x86-64-build.kernel.org:git" or at "i386-build.kernel.org:git" ?
Probably its better to have
[branch "master"]
push-remote = "ko-private-x86-64 ko-private-i386"
and entries for 2 remotes.
Neverless, I missed the info "Which branch should be merged in a default
pull after fetching the given branches from remote". I understand that
this is not needed in your workflow, as you have no upstream.
> > [branch "ko-master"]
> > tracksremote = "master of ko-private"
> >
> > This also would specify that we are not allowed to commit on "ko-master".
>
> For my workflow, it is "master of ko"; your notation expresses
> the same constraints more explicitly by being more special
> purpose
Why is this more special purpose?
IMHO the only difference is that your proposal puts this information into
the remote, and I am putting it to the branch as attribute.
I chose it this way because I always thought that the Pull-lines in .git/remotes
where only about giving a default fetch action, ie. they are optionally. But
even if I do not want to have a remote branch fetched on default, I want to put
the information "XXX of remote RRR is the upstream of local YYY" into some place
to be able to do a pull when on that branch.
> : "This tracks that one so never touch it any way other
> than fetching into it" (we may not even allow checking out
> "ko-master" -- I dunno).
>
> One issue you might want to think about is it is far more
> efficient to fetch multiple branches from the same git://... URL
> is than fetching them one by one. The push has exactly the same
> property.
Perhaps an option "when pulling into this branch from a remote, also fetch
all branches tracked from this remote", or another one "when fetching/pulling
into this branch, update all other branches, too".
> Another thing is the above talks only about constraints, and the
> user has to go all over the config file to find "xxx to
> ko-private" in order to figure out what happens when he says
> "pull ko-private".
I wasn't intending to change the current semantics of the remote section,
which specifies what to do when pulling/fetching/pushing from/into this
remote.
But you are right; this could get inconsistent. Better find a way to
not be able to specify an inconsistent config in the first place.
However, such an inconsistent config is already possible today:
[remote "r1"]
fetch = master:master
[remote "r2"]
fetch = master:master
This is not really better than
[branch "master"]
tracksremote "master of r1"
[remote "r1"]
fetch = "notmaster:master"
We already print out a warning when updating a branch tracking a remote
is not a fast-forward.
So I would leave it as it is, and allow both ways.
This all would be mood if we use refs/remotes consequently: existance of
a branch "refs/remotes/r1/master" implicitly specifies that this is
a branch tracking a remote, where the remote is named "r1" and the
remote branch is "master".
With
[core]
useSeparateRemote ; bool
[r1]
url = ...
fetch = master branch2 branch3
a "git fetch r1" would track given remote branches in "remotes/r1/<branch>",
and a
[branch "master"]
origin = "remotes/r1/master"
would work even without the "fetch" line in the remote section.
Here, we can allow both ways without getting inconsistent, as we implicitly
have
[branch "remotes/r1/master"]
tracksremote = "master of r1"
Regarding syntax: Instead of the "... of ..." values I would prefer two keys
"remotebranch"/"remote".
Josef
^ permalink raw reply
* Re: Howto get the merge-base ?
From: Linus Torvalds @ 2006-05-14 18:40 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: Git Mailing List
In-Reply-To: <4fb292fa0605141021r20cefaa0he592b9c713ede333@mail.gmail.com>
On Sun, 14 May 2006, Bertrand Jacquin wrote:
>
> I'm trying to know which commit it the parent of a merge.
> For exemple if I do that :
>
> o Merge
> / \
> / \
> | |
> | o Commit D
> | |
> | o Commit C
> | |
> o | Commit B
> \ /
> \/
> o Commit A
> |
> o Init
>
> How could I know that ``Commit A'' is the merge-base of ``Merge'' ?
Well, Junio already answered, but I'd like to comment a bit further.
There may not be "one" merge-base. There can be several:
Merge
|
A
/ \
B C
|\ /|
| X |
|/ \|
D E
\ /
F
|
Here the merge (A) has two equally good merge bases: D and E.
If you want all of these merge-bases, you need to add the "--all" flag to
git-merge-base.
On the git archive, try this trivia shell pipeline:
git-rev-list --parents HEAD |
sed -n '/^[0-9a-f]* [0-9a-f]* [0-9a-f]*$/ p' |
while read a b c
do
echo $a: $(git merge-base --all $b $c)
done | less -S
and you'll be able to easily pick up examples of where there are real
multiple merge bases. For example, commit 4da8cbc2.. has that.
If you want to examine _why_ it has multiple merge-bases, do:
gitk 4da8cbc2 --not 5910e997 52b70d56
(where the two "not" commits are the merge bases for it) which shows that
merge and the criss-crossing nature of the history leading up to it.
NOTE! Most of the time, multiple merge bases do not really matter all that
much, and you'd get the same merge regardless of which one you would
choose as the base. Still, they _can_ matter.
Linus
^ permalink raw reply
* The git newbie experience
From: Tommi Virtanen @ 2006-05-14 18:36 UTC (permalink / raw)
To: git
Here's my thoughts from teaching half a dozen people git recently:
Minimal newbie command set
--------------------------
The complete set of "newbie commands" for useful development work should
be as small as possible, for fast learning.
People can always look up new things when they want to, but if they
don't get the simple things going quickly they will forever see git
as "that overcomplex thing I tried to use once".
Concretely: explain the indexless "git commit -a" case first,
so people don't need update-index right away. Most new docs are
pretty good at this, already.
Fix the cases where "git commit -a" is not enough. Here's a case I
ran into:
- Jack is a beginning user of git and does not (want to) understand
the index (right now).
- Jack works on branch X, say his HEAD points to X1. He has an edited,
uncommitted files with the names A, B and C.
- Jack wants to pull new changes made by others to his branch.
There are merge conflicts in files D, E, ..., Z.
- Jack resolves the merge conflicts and is ready to commit the resulting
merge. Note files A, B and C should not be committed.
1. if Jack says "git commit -a", then A, B and C will be committed
also.
2. if Jack says "git commit", then the current state of the index will
be committed. That is, the commit will not contain the proper
merged state of files D, E, ..., Z.
3. if Jack says "git commit D E ... Z", things work correctly. But
Jack does not want to type or copy-paste that much, and that's
horribly error-prone anyway. If the leaves one file out, or
accidentally adds B there too, the merge goes wrong.
4. if Jack says "git update-index --refresh" and then "git commit",
things work correctly. But Jack doesn't (want to) know about the
index.
My best idea so far is to add a "git commit -A" option, that
essentially does the "update-index --refresh". Whenever index
has a file state != HEAD, update-index it. The modified unrelated
files will have index state == HEAD. Or altering "git commit -a"
to do that.
Except, trying to solve usability problems by _adding_ options
is just insane.
I'd really like to see a way to use git without caring about the
index, and just having things work. I can appreciate the index
is useful, and possibly even necessary to work on projects the size
of the Linux kernel, but I really wish it would default to being
_only_ an optimization, not the central bit of user interface to
prepare commits.
Basic git use _should_ be as easy as basic svn/bzr/hg use. Anything
else will just mean git is not used outside of what codebases Linus
has dictatorship over. (At least not after bzr is more done or hg
more well known; right now git has a very nice feature set, but the
others are catching up fast.)
This is a part that Subversion got right. Basic use needs to be simple.
(If you catch me in agitated mood, I'd claim it's the _only_ part
Subversion got right;-)
And to reply to a comment on IRC I missed at the time:
(21:05:35) gitster: as gittus said much earlier, refusing index is like
refusing git. We might be able to implement "index-less" mode in which
things like merge and am refuse to operate when you have any change from
HEAD in the working tree. Then new users can always do "commit -a".
(21:06:04) gitster: "git-repo-config core.newuser yes" perhaps?
If you do it that way, you only make git unnecessarily hard to use for
newbies. For example, we had a case where we absolutely _had_ to keep
an ugly workaround in the tree, in a file not otherwise edited, but
we definitely did not want to commit the kludge, at least not to the
branch that was really being worked on. So such restricted mode would
just have meant either people could not merge, or they had to use index
anyway. That's a point where people who have a choice make on, and stop
trying to use git.
(21:08:34) ***gitster personally considers getting more users a very
high priority but agrees that from usability point of view, having a
mode to expose "stripped down" set of features for simple needs would be
beneficial.
That I can 100% agree with.
Branch management
-----------------
"master" and "origin" are good enough for the really simple use, but
that starts to fail fast when you add in more branches.
The remotes/* branch support is really nice, but should be used better.
Here's a bunch of wild ideas:
- When cloning a repository, just clone all the non-remote heads to
local remotes/* heads. See what name the remote HEAD points to, store
that locally also as a refs/heads/master, set local HEAD to it. Note,
origin is gone, and is now called remotes/master.
- Alternatively (and I think I like this more): When cloning a
repository, just clone all the non-remote heads to local remotes/*
heads. See what the remote HEAD points to, store that locally
also as a refs/heads/* head, set local HEAD to it. Note, origin and
master are both gone, and accessible via remotes/X and refs/heads/X
(where X is the name remote HEAD pointed to).
- Currently, when people start tracking a new remote branch, they end
up editing .git/remotes/origin and adding new Pull: lines. If they
intend to work on the branch, they also clone the branch locally, and
add a Push: line. Make this simpler. Here's a rough sketch:
"git track [--read-only] REMOTE [BRANCH | --all]"
Without --all, git track would:
- abort if refs/remotes/foo exists
- add "Pull: foo:remotes/foo" to .git/remotes/origin (or the
equivalent config file)
- if --read-only is not given:
- add "Push: foo:foo" to .git/remotes/origin
- fetch foo from origin to remotes/foo
- if --read-only is not given:
- run "git branch foo remotes/foo"
With --all, it would do the same, but for everything the REMOTE has
in refs/remotes/. Exactly when to abort is a bit harder to define,
but still..
- Or, if that's too much, at least make peek-remote understand
.git/remotes/* shortcuts, so finding out what branches exist is a bit
simpler.
^ permalink raw reply
* Simplify "git reset --hard"
From: Linus Torvalds @ 2006-05-14 18:20 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605141040210.3866@g5.osdl.org>
Now that the one-way merge strategy does the right thing wrt files that do
not exist in the result, just remove all the random crud we did in "git
reset" to do this all by hand.
Instead, just pass in "-u" to git-read-tree when we do a hard reset, and
depend on git-read-tree to update the working tree appropriately.
This basically means that git reset turns into
# Always update the HEAD ref
git update-ref HEAD "$rev"
case "--soft"
# do nothing to index/working tree
case "--hard"
# read index _and_ update working tree
git-read-tree --reset -u "$rev"
case "--mixed"
# update just index, report on working tree differences
git-read-tree --reset "$rev"
git-update-index --refresh
which is what it was always semantically doing, it just did it in a
rather strange way because it was written to not expect git-read-tree to
do anything to the working tree.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
NOTE! The switch to use "git-read-tree -u" does actually result in a real
change: we will now remove files that were in the index but not in HEAD
before (ie files added with "git add"). I'd argue that this is a bug-fix.
git-reset.sh | 50 ++++----------------------------------------------
1 files changed, 4 insertions(+), 46 deletions(-)
diff --git a/git-reset.sh b/git-reset.sh
index 6cb073c..0ee3e3e 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -6,6 +6,7 @@ USAGE='[--mixed | --soft | --hard] [<co
tmp=${GIT_DIR}/reset.$$
trap 'rm -f $tmp-*' 0 1 2 3 15
+update=
reset_type=--mixed
case "$1" in
--mixed | --soft | --hard)
@@ -23,24 +24,7 @@ # We need to remember the set of paths t
# behind before a hard reset, so that we can remove them.
if test "$reset_type" = "--hard"
then
- {
- git-ls-files --stage -z
- git-rev-parse --verify HEAD 2>/dev/null &&
- git-ls-tree -r -z HEAD
- } | perl -e '
- use strict;
- my %seen;
- $/ = "\0";
- while (<>) {
- chomp;
- my ($info, $path) = split(/\t/, $_);
- next if ($info =~ / tree /);
- if (!$seen{$path}) {
- $seen{$path} = 1;
- print "$path\0";
- }
- }
- ' >$tmp-exists
+ update=-u
fi
# Soft reset does not touch the index file nor the working tree
@@ -54,7 +38,7 @@ then
die "Cannot do a soft reset in the middle of a merge."
fi
else
- git-read-tree --reset "$rev" || exit
+ git-read-tree --reset $update "$rev" || exit
fi
# Any resets update HEAD to the head being switched to.
@@ -68,33 +52,7 @@ git-update-ref HEAD "$rev"
case "$reset_type" in
--hard )
- # Hard reset matches the working tree to that of the tree
- # being switched to.
- git-checkout-index -f -u -q -a
- git-ls-files --cached -z |
- perl -e '
- use strict;
- my (%keep, $fh);
- $/ = "\0";
- while (<STDIN>) {
- chomp;
- $keep{$_} = 1;
- }
- open $fh, "<", $ARGV[0]
- or die "cannot open $ARGV[0]";
- while (<$fh>) {
- chomp;
- if (! exists $keep{$_}) {
- # it is ok if this fails -- it may already
- # have been culled by checkout-index.
- unlink $_;
- while (s|/[^/]*$||) {
- rmdir($_) or last;
- }
- }
- }
- ' $tmp-exists
- ;;
+ ;; # Nothing else to do
--soft )
;; # Nothing else to do
--mixed )
^ permalink raw reply related
* Re: Howto get the merge-base ?
From: Junio C Hamano @ 2006-05-14 18:12 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: git
In-Reply-To: <4fb292fa0605141104j6c73c1eao5a8eeea9ad1b6282@mail.gmail.com>
"Bertrand Jacquin" <beber.mailing@gmail.com> writes:
> On 5/14/06, Junio C Hamano <junkio@cox.net> wrote:
>> "Bertrand Jacquin" <beber.mailing@gmail.com> writes:
>>
>> > I'm trying to know which commit it the parent of a merge.
>> > For exemple if I do that :
>> >
>> > o Merge
>> > / \
>> > / \
>> > | |
>> > | o Commit D
>> > | |
>> > | o Commit C
>> > | |
>> > o | Commit B
>> > \ /
>> > \/
>> > o Commit A
>> > |
>> > o Init
>> >
> No, that's just on the following of git-send-mail-commit.sh thread (or
> something near). To make a readable merge mail with diffstat and
> summury.
For that you do not want merge-base. If your mainline was A-B
and you merged a side branch B-C-D with the merge, then to
people who tracked your head (that's the audience of "merge
mail", I presume) they just need to see:
git diff --stat M^1..M
git rev-list --no-merges --pretty M^1..M | git shortlog
The diffstat is "what damage was inflicted on the branch you
have been following with this merge", so the diff between the
trees before and after the merge is what you want. And the
rev-list piped to shortlog is to show "what commits were _not_
present on this branch before the merge, but are present after
the merge" (it could be spelled M^1..M^2 but the above would
handle octopus as well).
^ permalink raw reply
* Re: Howto get the merge-base ?
From: Bertrand Jacquin @ 2006-05-14 18:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bfc33hm.fsf@assigned-by-dhcp.cox.net>
On 5/14/06, Junio C Hamano <junkio@cox.net> wrote:
> "Bertrand Jacquin" <beber.mailing@gmail.com> writes:
>
> > I'm trying to know which commit it the parent of a merge.
> > For exemple if I do that :
> >
> > o Merge
> > / \
> > / \
> > | |
> > | o Commit D
> > | |
> > | o Commit C
> > | |
> > o | Commit B
> > \ /
> > \/
> > o Commit A
> > |
> > o Init
> >
> > How could I know that ``Commit A'' is the merge-base of ``Merge'' ?
>
> > I try to get this git-merge-base but result is strange and quiet
> > mysterious as he return me always second args I passed to.
>
> It is mysterious to me because you did not say what you gave as
> arguments ;-).
I was using git-merge-base ``merge-ish'' ``comit-ish''. Docs about it
is atrocious so was trying many but not the one good. Blam me.
> If I am reading you correctly, you already have a "Merge"
> commit, made by you or somebody else, and are trying to figure
> out where the merge base was. If that is the case:
>
> git-merge-base Merge^1 Merge^2
>
> in other words
>
> git-merge-base CommitB CommitD
That's ok :)
> is what you are looking for?
Yes ! Thanks :)
> But what do you need that information for? To reproduce
> somebody else's merge?
No, that's just on the following of git-send-mail-commit.sh thread (or
something near). To make a readable merge mail with diffstat and
summury.
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: Allow one-way tree merge to remove old files
From: Junio C Hamano @ 2006-05-14 17:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605141040210.3866@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> For some random reason (probably just because nobody noticed), the one-way
> merge strategy didn't mark deleted files as deleted, so if you used
>
> git-read-tree -m -u <newtree>
>
> it would update the files that got changed in the index, but it would not
> delete the files that got deleted.
Good catch. I think it is a leftover from the days we did not
have -u there; returning 0 was a way to say "there is no cache
entry resulting from this round of path-merge".
^ permalink raw reply
* Re: Howto get the merge-base ?
From: Junio C Hamano @ 2006-05-14 17:44 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: git
In-Reply-To: <4fb292fa0605141021r20cefaa0he592b9c713ede333@mail.gmail.com>
"Bertrand Jacquin" <beber.mailing@gmail.com> writes:
> I'm trying to know which commit it the parent of a merge.
> For exemple if I do that :
>
> o Merge
> / \
> / \
> | |
> | o Commit D
> | |
> | o Commit C
> | |
> o | Commit B
> \ /
> \/
> o Commit A
> |
> o Init
>
> How could I know that ``Commit A'' is the merge-base of ``Merge'' ?
> I try to get this git-merge-base but result is strange and quiet
> mysterious as he return me always second args I passed to.
It is mysterious to me because you did not say what you gave as
arguments ;-).
If I am reading you correctly, you already have a "Merge"
commit, made by you or somebody else, and are trying to figure
out where the merge base was. If that is the case:
git-merge-base Merge^1 Merge^2
in other words
git-merge-base CommitB CommitD
is what you are looking for?
But what do you need that information for? To reproduce
somebody else's merge?
^ permalink raw reply
* Allow one-way tree merge to remove old files
From: Linus Torvalds @ 2006-05-14 17:43 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
For some random reason (probably just because nobody noticed), the one-way
merge strategy didn't mark deleted files as deleted, so if you used
git-read-tree -m -u <newtree>
it would update the files that got changed in the index, but it would not
delete the files that got deleted.
This should fix it, and I can't imagine that anybody depends on the old
strange "update only existing files" behaviour.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/read-tree.c b/read-tree.c
index e926e4c..11157f4 100644
--- a/read-tree.c
+++ b/read-tree.c
@@ -684,7 +684,7 @@ static int oneway_merge(struct cache_ent
merge_size);
if (!a)
- return 0;
+ return deleted_entry(old, NULL);
if (old && same(old, a)) {
return keep_entry(old);
}
^ permalink raw reply related
* Re: git diff: support "-U" and "--unified" options properly
From: Junio C Hamano @ 2006-05-14 17:36 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200605141457.17314.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Saturday 13 May 2006 23:22, you wrote:
>> * remotes/ information from .git/config (js/fetchconfig)
>> ...
>> [branch "master"]
>> remote = "ko-private"
>
> Why is this line needed? In this example, what is the relationship
> of local "master" with the remote? I think it is enough to specify
> the local upstream branch:
>
> [branch "master"]
> origin = "ko-master"
I confused you by not describing the flow.
There are four repositories involved:
a. siamese:/git (my local development repo)
b. x86-64.kernel.org:~/git (my kernel.org build repo)
c. i386.kernel.org:~/git (ditto but for i386)
d. kernel.org:/pub/scm/git/git.git (public distribution point)
The workflow is:
1. maint/master/next/pu are prepared on a.
2. maint/master/next/pu are pushed to b. and c. as
maint/origin/next/pu. b. and c. always have their "master"
checked out.
3. I go to b. and c., and "pull . origin" to start my build
there on all four branches.
4. When things go well, I come back to a.
5. Then maint/master/next/pu are pushed to d. without renaming.
6. To keep track of what have been pushed, maint/master/next/pu
from d. are fetched to a., with ko- prefixed. There is no
"when on this branch" involved in this step. Regardless of
which branch I currently on, the fetch goes fine. I never
check out ko-* branches on a, nor merge from ko-* branches.
7. Go back to step 1 and start the next cycle. ko-maint, ko-master
and ko-next reminds me not to rewind maint/master/next while I
shuffle the changes to discard botched commits beyond them.
> So we need
>
> [branch "ko-master"]
> tracksremote = "master of ko-private"
>
> This also would specify that we are not allowed to commit on "ko-master".
For my workflow, it is "master of ko"; your notation expresses
the same constraints more explicitly by being more special
purpose: "This tracks that one so never touch it any way other
than fetching into it" (we may not even allow checking out
"ko-master" -- I dunno).
One issue you might want to think about is it is far more
efficient to fetch multiple branches from the same git://... URL
is than fetching them one by one. The push has exactly the same
property.
Another thing is the above talks only about constraints, and the
user has to go all over the config file to find "xxx to
ko-private" in order to figure out what happens when he says
"pull ko-private".
>> ...
>> [remote "ko"]
>> url = "kernel.org:/pub/scm/git/git.git"
>> push = master:master
>> ...
>> fetch = master:ko-master
>
> These specifications more or less are independent from the above,
> as it specifies the defaults when fetching/pushing to the specified remote.
Not really; and what you introduced can conflict with [remote]
specification. If you have [branch "ko-master"] that says it
tracks remote "master" from "ko" repository, your [remote "ko"]
should have not say "fetch = foobla:ko-master", so in that sense
it is redundant and inviting later inconsistency. The only
information you added with "tracksremote" is the branch is used
to track what is on remote (implying we'd better not touch it
ourselves), so I'd say this would make sense
[branch "ko-master"]
tracksremote ; bool!
[remote "ko"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = master:ko-master
or alternatively this would:
[branch "ko-master"]
tracksremote = "master of ko"
[remote "ko"]
url = git://git.kernel.org/pub/scm/git/git.git
^ 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