* Re: [PATCH/RFC] Convenient support of remote branches in git-checkout
From: Josef Weidendorfer @ 2006-11-07 17:04 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, git
In-Reply-To: <20061107135609.GA32376@diana.vm.bytemark.co.uk>
On Tuesday 07 November 2006 14:56, you wrote:
> But what happens when an unexperienced user gets this conflict for the
> first time (having for the first time used two different remotes)?
> Your scheme forces her to learn two new things instead of one,
> creating the artificial barrier I mentioned above.
I give the user a warning that she has to specify a branch
name herself. This does not force her to rename all her branches
and go with the new naming <remote>/<remote branch>, but probably
makes her do
repo developer1, branch next => next (magic behavior)
repo developer2, branch next => next2 (manual specification)
and perhaps rename next to next1 afterwards.
At least I do not want to type long branch names; most of the
cloned repos I have do have only one remote. So I would rename
the branches names created with the complex magic scheme.
Of course, another way is to be more smart with branch name parsing.
Currently, a given name is searched in
.git/
.git/refs/
.git/refs/tags/
.git/refs/heads/
.git/refs/remotes/
.git/refs/remotes/*/HEAD
What about adding before remotes
.git/refs/heads/<first-part-of-current-branchname>/
and at the end
.git/refs/remotes/<first-part-of-current-branchname>/
Ie. when on branch "origin/next", a given name "master" is
parsed as "refs/heads/origin/master" when existing?
So the parsing rule is: "With current branch X and given name Y,
search for a branch as near as possible to X which has Y as
last name component".
This would match current UI, where you have simple branch names
like "master" or "next".
With above rule, you can use "master" to refer
to "refs/heads/origin/master" in the complex model,
and for a read-only remote head "refs/heads/remotes/origin/next",
it is enough to say
git-checkout next
to get a new local branch "refs/heads/origin/next" created
to work on.
You keep the simple UI and still get the perfect overview with
eg. with "gitk --all" even in the case where you work on
10s of remote branches from multiple repository.
^ permalink raw reply
* Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]
From: Linus Torvalds @ 2006-11-07 17:23 UTC (permalink / raw)
To: Liu Yubao; +Cc: Junio C Hamano, git
In-Reply-To: <45503CFC.7000403@gmail.com>
On Tue, 7 Nov 2006, Liu Yubao wrote:
>
> Fake commit is only for digging branch scope history, I can *outline* what has
> been merged to a branch and don't care about how these good work are done on
> earth.
The thing is, I think you see a good thing ("outlining"), and miss all the
downsides ("extra noise", "incorrect outlining").
Yes, I can see it being useful for reading logs in a perfect world.
However, in real life, more than half of my fast-forwards are just me
tracking another branch. An "outline" would be _wrong_. I _want_ to
fast-forward, because I'm moving the trees from one machine to another,
and the reason it's a fast-forward is exactly the fact that absolutely
zero work had been done on the machine I'm pulling from - I'm pulling just
to keep up-to-date.
So now, just to keep things sane, your scheme would require that people
AHEAD OF TIME tell the system whether they want to fast-forward or whether
they want to create a magic merge commit as a "outlining" marker.
See? Fast-forwarding is absolutely the right thing to do in 99% of all
cases. For me, it's perhaps only half, because I do several true merges
every day, but that's really quite unusual - I'm the top-level maintainer.
Nobody else should EVER do it.
And the thing is, I refuse to work with a system that makes one person
special. I _know_ I'm special, I'm the smartest, most beautiful, and just
simply the best person on the planet. I don't need a tool that tells me
so.
So deep down, what you're really suggesting that there be a special mode
that is ONLY ever used for the top-level maintainer, so that he can create
an "outline" in the history.
Put that way, it almost makes sense, until you realize that 99.9% of all
people aren't top-level maintainers, and you don't want them creating crap
like that. And that "outlining" is likely most easily done with
( git log lastversion.. | git shortlog ;
git diff --stat --summary lastversion.. ) | less -S
instead.
But more importantly, I don't personally like the "top-level maintainer"
model. Yes, it's how people do end up working a lot, but quite frankly,
I'd rather not have the tool support it, especially if there is ever a
schism in a development process. I want to support _forking_, which very
much implies having somebody pulling the "wrong way".
Time for some purely philosophical arguments on why it's wrong to have
"special people" encoded in the tools:
I think that "forking" is what keeps people honest. The _biggest_ downside
with CVS is actually that a central repository gets so much _political_
clout, that it's effectively impossible to fork the project: the
maintainers of a central repo have huge powers over everybody else, and
it's practically impossible for anybody else to say "you're wrong, and
I'll show how wrong you are by competing fairly and being better".
For example, gcc (and other tools) have gone through this phase. You've
had splinter groups (eg pgcc) that did a hell of a lot better work than
the main group, and the tools really made it really hard for them to make
progress. I think the most important part of a distributed SCM is not even
to support the "main trunk", but to support the notion that anybody can
just take the thing and compete fairly.
With the kernel as an example, any group could literally just start their
own kernel git tree, and git should make it as easy as humanly possible
for them to track my tree WHILE _THEY_ STILL REMAIN IN CHARGE of their own
tree. That doesn't mean that forking is easy - over the years people have
simply grown so _used_ to me that they mostly trust me and they are comfy
working with me, because even if I've got my quirks (or "major personality
disorders" as some people might say), people mostly know how to work with
them.
But the point is, there should be no _tool_ issues. As far as git is
concerned, every single developer can feel like he is the top-level
maintainer - it doesn't have to be a hierarchy, it really can be a
"network of equal developers". I want the _tool_ to have that world-view,
even if most projects in the end tend to organize more hierarcically than
that. Because the "everybody is equal" worldview actually matters in the
only case that _really_ matters: when problems happen.
For example: I use git to maintain a few other projects I've started too.
I use git to maintain git itself, but I'm no longer the maintainer, simply
because I think it's a lot better to step down than stand in the way of
somebody better, and because I think it's hard to be the "lead person" on
multiple projects.
The same thing is happening to "sparse", which was dormant for a while (it
worked, and I fixed problems as people reported them, but it did
everything I had set out to do, so my motivation to develop it further had
just gone down a lot). What happened? Somebody else came along, showed
interest, started sending me patches, and I just suggested he start his
own tree and start maintaining it.
Now, both of those transitions were very peaceful, but it should work that
way even if the maintainer were to fight tooth and nail to hold on to his
"top dog" status. And that's where it's important that the tool not
separate out "top maintainers" from "other people".
> I want to separate a branch, not to separate commits by some author, for
> example, many authors can contribute to git's master branch, I want to
> know what happened in the master branch like this:
> good work from A;
> good work from C;
> merge from next; -----> I don't care how this feature is realized.
> good work from A;
Really, "git log | git shortlog" will come quite close. I use it all the
time for the kernel, and it's powerful.
Try it with the kernel archive, just for fun. Do
git log v2.6.19-rc4.. | git shortlog | less -S
with the current kernel, and see how easy it is to get a kind of feel for
what is going on. We do it by two means:
- sorting by author.
This sounds silly, but it's actually very powerful. It's not so much
that it credits people better (it does) or that it makes the logs
shorter by mentioning the person just once (it does that too), it's
really nice because people tend to automatically do certain things. One
person does "random cleanups". Another one works on "networking". A
third one maintains one particular architecture, and so on..
- encourage people to have a "topic: explanation" kind of top line of the
commit (and encourage people to have that "summary line" in the first
place: not every SCM does that, and everybody else is strictly much
worse than git)
In fact, when I do this, I usually _remove_ the merges, because they end
up being just noise. Really: go and look at the current kernel repo, and
do the above one-liner, and realize that I have a hunking big set of
commits credited to me right now (it says 30 commits), and in fact I think
I'm the #1 author right now on that list.
But when I send out the description, I actually use the "--no-merges" flag
to "git log", because those merge messages are _useless_. They really
don't do anything at all for me, or for anybody else. Re-run the above
one-liner that way, and suddenly I drop to just 5 commits (and quite
often, I'm much less - sometimes the _only_ commit I have for an -rc
release is the commit that changes the version number). But it's actually
more readable.
So I can kind of see what you want, but I'm 100% convinced that the
information you _really_ want is better done totally differently.
So if you want to get the "big picture" thing, git does actually support
you in several ways. That "git shortlog" is very useful, but so is the
"drill down by subsystem". For example, you could do
git log --no-merges v2.6.19-rc4.. arch/ | git shortlog | less -S
and you'd get the "summary view" of what happened in architecture-
specific code. It's not the same thing as the "merge log", but it's
actually very useful.
(You can do the same with git. Something like
git log --no-merges v1.4.3.4.. | git shortlog | less -S
shows quite clearly that a lot of new stuff is gitweb-related, for
example.
Could we do better "reporting" tools? I'm absolutely sure we could. It
might be interesting to be able to ignore not just commits, but "trivial
patches" too. For example, if you're looking for what changed on a high
level, you're not likely to care about patches that change just a few
lines. You might want to see only the commits that change an appreciable
fraction of code, and so it might be very interesting to have a "git
shortlog" that would take patch size into account, for example.
So I'm not saying that git is perfect. I'm just saying that there are
better ways (with much fewer downsides) to get what you want, than the way
you _think_ you want.
^ permalink raw reply
* Did anyone have trouble learning the idea of local vs. remote branches?
From: Shawn Pearce @ 2006-11-07 17:24 UTC (permalink / raw)
To: git
Today I was talking with someone that I collaborate with through
Git and they still seemed to not get the idea that all branches
in their repository are local, and that at least a 'git fetch'
is needed to update the local tracking branches to the version
in the central repository that we collaborate through. And this
isn't the first time we've had such discussions.
It dawned on me that this person still hasn't grasped the idea
behind fetch. A few other users that I know also have commented on
how difficult fetch is to learn.
Most seemed to think that fetch would update their working directory,
or their current branch, as there is no other way to "download
changes from origin". They also seem to expect their local tracking
branch to automatically update, especially when invoking
`git checkout -b foo tracking-branch`.
Clearly there is a gap in communicating these ideas in a way that
they can be understood by users. Of course in at least one case
the users just isn't reading any Git documentation and plows ahead
as though it were CVS ('cause everything's "just like CVS") *sigh*.
--
^ permalink raw reply
* Re: win2k/cygwin cannot handle even moderately sized packs
From: Alex Riesen @ 2006-11-07 17:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eiq9vm$l7c$1@sea.gmane.org>
> Perhaps planned mmapping only parts of packs would help there.
^ permalink raw reply
* Re: win2k/cygwin cannot handle even moderately sized packs
From: Shawn Pearce @ 2006-11-07 17:48 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jakub Narebski, git
In-Reply-To: <81b0412b0611070928l7be83e08kbfc9657937fe7c92@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> >Perhaps planned mmapping only parts of packs would help there.
>
> BTW, can I find this code somewhere to try it out?
The patches are on the mailing list archives somewhere around
Sept. 5th timeframe from me; as I recall we dropped them as they
didn't apply on top of Junio's 64 bit index changes (which were
reverted out of next anyway).
I was going to push my branch to a public mirror but it turns
out I deleted that branch. :-(
--
^ permalink raw reply
* Re: Did anyone have trouble learning the idea of local vs. remote branches?
From: Salikh Zakirov @ 2006-11-07 18:08 UTC (permalink / raw)
To: git
In-Reply-To: <20061107172450.GA26591@spearce.org>
Shawn Pearce wrote:
> Clearly there is a gap in communicating these ideas in a way that
> they can be understood by users. Of course in at least one case
> the users just isn't reading any Git documentation and plows ahead
> as though it were CVS ('cause everything's "just like CVS") *sigh*.
I've went through persuading my colleagues (~30 engineers) to use Git and tutoring on it
through the three summer months, and my experience is very similar to Shawn's.
(i.e. confusing local and remote branches, not reading documentation,
and "just like CVS" attitude)
Below is the one git feature that I think was stumbled upon most often:
* people were often anaware of *multiple* branches created by git-clone,
as the operation they wanted was analog of "cvs checkout".
* git-fetch / git-pull tries to download all of the branches that were
preset at git-clone time, and subsequently gives errors if some topic
branches were rewound or dropped, while most of the time my colleagues
were interested in just one "mainline" branch.
I think that the particular issue with the workflow in my organization
could have been solved by the git-checkout and git-clone hybrid
git-checkout ssh://path.to/repo.git#branch [work_dir]
which would clone repository with just one branch and setup the remotes
file accordingly (The syntax is completely made up, of course)
P.S. a few words on the workflow we use:
- there is a "mainline" branch of development, kept as ssh-shared git repository
- mainline commits require some pre-commit testing, which takes ~1.5 hours,
so people tend not to commit to mainline too often. On average, a given
person commits to mainline once or twice a week.
- mainlines commits also require a fellow developer review, that's where
topic branches come in handy. Topic branches are also useful for testing,
as pre-commit testing should be run on several different platforms, thus
on a different machines. Topic branches are kept on the same shared server.
^ permalink raw reply
* [PATCH] Return non-zero status from pull if merge fails.
From: Shawn O. Pearce @ 2006-11-07 18:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If the merge operation fails during git-pull it usually exits with a
non-zero exit status to let the caller know it failed. But git-pull
tossed that status away and always returned 0 (success), leading to
confusing output in any higher level interface which supplied both
the console output (showing the merge failure) and the exit status
(showing success).
So now git-pull just exec's git-merge, allowing its exit status to
be reported directly to the caller.
There were also a number of cases within git-merge which terminated
with a success (0) exit status despite having been caused by failure
to merge. This is equally misleading and should return 1 instead.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-merge.sh | 10 +++++-----
git-pull.sh | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index cb09438..7725908 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -203,7 +203,7 @@ f,*)
git-update-index --refresh 2>/dev/null
new_head=$(git-rev-parse --verify "$1^0") &&
git-read-tree -u -v -m $head "$new_head" &&
- finish "$new_head" "Fast forward"
+ finish "$new_head" "Fast forward" || exit 1
dropsave
exit 0
;;
@@ -214,7 +214,7 @@ f,*)
?,1,*,)
# We are not doing octopus, not fast forward, and have only
# one common. See if it is really trivial.
- git var GIT_COMMITTER_IDENT >/dev/null || exit
+ git var GIT_COMMITTER_IDENT >/dev/null || exit 1
echo "Trying really trivial in-index merge..."
git-update-index --refresh 2>/dev/null
@@ -225,7 +225,7 @@ f,*)
result_commit=$(
echo "$merge_msg" |
git-commit-tree $result_tree -p HEAD -p "$1"
- ) || exit
+ ) || exit 1
finish "$result_commit" "In-index merge"
dropsave
exit 0
@@ -253,7 +253,7 @@ f,*)
esac
# We are going to make a new commit.
-git var GIT_COMMITTER_IDENT >/dev/null || exit
+git var GIT_COMMITTER_IDENT >/dev/null || exit 1
# At this point, we need a real merge. No matter what strategy
# we use, it would operate on the index, possibly affecting the
@@ -327,7 +327,7 @@ done
if test '' != "$result_tree"
then
parents=$(git-show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
- result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree $parents) || exit
+ result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree $parents) || exit 1
finish "$result_commit" "Merge made by $wt_strategy."
dropsave
exit 0
diff --git a/git-pull.sh b/git-pull.sh
index ed04e7d..d10fcdd 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -102,6 +102,6 @@ case "$strategy_args" in
esac
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
-git-merge "--reflog-action=pull $*" \
+exec git-merge "--reflog-action=pull $*" \
$no_summary $no_commit $squash $strategy_args \
"$merge_name" HEAD $merge_head
--
^ permalink raw reply related
* Re: win2k/cygwin cannot handle even moderately sized packs
From: Alex Riesen @ 2006-11-07 18:13 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20061107174859.GB26591@spearce.org>
> The patches are on the mailing list archives somewhere around
> Sept. 5th timeframe from me; as I recall we dropped them as they
> didn't apply on top of Junio's 64 bit index changes (which were
> reverted out of next anyway).
I seem to be unable to find them. Does anyone still has the
patches/branch please? Junio, you did sound interested?
^ permalink raw reply
* Re: win2k/cygwin cannot handle even moderately sized packs
From: Shawn Pearce @ 2006-11-07 18:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <81b0412b0611071013j51254a40s749fb6cba65e6873@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> >The patches are on the mailing list archives somewhere around
> >Sept. 5th timeframe from me; as I recall we dropped them as they
> >didn't apply on top of Junio's 64 bit index changes (which were
> >reverted out of next anyway).
>
> I seem to be unable to find them. Does anyone still has the
> patches/branch please? Junio, you did sound interested?
> (God, I wish I have paid attention then...)
Junio definately wants to implement at least something similar
to what I did; I just happened to do it at the wrong time. :-)
I keep saying I'll get back around to rewriting the patch (as the
affected regions of git have been heavily modified recently by Nico
and thus it doesn't apply) but I keep not finding the time.
Maybe that's because I was working on git-gui...
--
^ permalink raw reply
* Re: If merging that is really fast forwarding creates new commit
From: Junio C Hamano @ 2006-11-07 18:23 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <45503CFC.7000403@gmail.com>
Liu Yubao <yubao.liu@gmail.com> writes:
> I want to separate a branch, not to separate commits by some author,
> for example, many authors can contribute to git's master branch, I
> want to
> know what happened in the master branch like this:
> good work from A;
> good work from C;
> merge from next; -----> I don't care how this feature is realized.
> good work from A;
> ....
So you want to see list of commits that happened to be at the
tip of my 'master' branch. I would not say that view does not
exist, but it is probably not very useful. And the uselessness
of it depends majorly on the reason why you say "I don't care
how this feature is realized" in the above picture. Care to
elaborate why not?
side note: I do not merge next to master so "from next" above in
reality would be "from a topic branch" or "from maint", but it
is otherwise a good example.
What appeared in 'master' recently are three kinds of changes:
- Many fixes that still apply to 1.4.3 codebase were sent from
the list (thanks, everybody!), which were applied to 'maint',
and merged into 'master'.
- Some other obviously correct fixes and changes that address
issues on features added after the 1.4.3 release (hence
missing from 1.4.3 codebase and 'maint' but in 'master') were
applied directly on 'master'.
- Yet some other fixes and changes that concern post-1.4.3
codebase (i.e. 'master only' changes) were forked off of the
tip of 'master' when the patches were received, cooked in
their own topic branches (which were merged in 'next'), and
then merged into 'master'.
So, we have two kinds of obviously correct changes to 'master'
that come both from merges and direct applications. Things that
happen to address older issues come as merges because they
equally apply to 'maint' and merged into 'master', things that
address newer issues are applied directly. Put it another way,
things that come as merges to 'master' are also of two kinds.
Obviously correct one that came through 'maint', and the ones
that might have looked slightly wrong in the initial version and
later perfected while in its own topic branch and then merged
into 'master'.
The decision between cooking in a topic branch and immediately
applying to 'master' is not based on the size but more on
perceived usefulness of the change (something that is correct in
the sense that it does not break the system may not deserve to
be merged if it does not do useful things) and quality of the
design and implementation. The size of the series obviously
affect the perception by me but that is secondary.
Even when a patch is something that I should be able to judge as
obviously correct when I am relaxed and sane, I might lack time
and concentration to follow it fully, and instead decide to drop
it into its own topic branch and later merge it into 'master'
without need for much cooking. That kind of patch _could_ have
(and should have) been applied directly to 'master' but comes as
a merge.
Sometimes I apply a patch to 'master' and then later realize
that change is needed and applicable to 'maint' as well. That
is cherry-picked to 'maint', resulting in two independent
commits. They _could_ have (and should have) come through a
merge from 'maint' to 'master'.
So the change a patch introduces itself may not even have
relevance to the difference between direct application and merge
at all. In other words, the avenue a particular patch took,
difference between direct application and merge, should not
concern you. I hope this would illustrate why a view that tries
to summarize what merges brought in and to give full description
of what were applied directly does not make much sense.
By the way, there are two reasons why you cannot have my
ref-logs. First of all, I do not have one on 'master' nor
'next' myself. More importantly, I rewind and rebuild these
branches before pushing out (of course I have some safety valve
to prevent me from rewinding beyond what I have already pushed
out), and the ref-log entries for those tips that were rewound
are not useful to you, and something I would rather not have
people to even know about (think of it as giving me some
privacy).
If you really care about the branch tip history of my
repository, you can set up ref-log yourself on your remote
tracking branch.
Strictly speaking, that is the history of fetches by you, not
the history of merges and commits by me, but that is what
matters more to you. If I pushed my changes out twice a day but
you were away for two days, you would have seen the state of my
repository four rounds back before you left and when you fetched
from me today you would have the latest; three states in between
were not something you can know. But it does not matter -- your
repository did not have those three states, so not knowing
exactly which commit they were would not hurt you when
bisecting. "It worked before I pulled yesterday morning but now
it is broken when I pulled this afternoon" would help your
bisect get started, but multiple state changes between the times
you fetched cannot matter.
^ permalink raw reply
* Re: win2k/cygwin cannot handle even moderately sized packs
From: Shawn Pearce @ 2006-11-07 18:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20061107181808.GC26591@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Alex Riesen <raa.lkml@gmail.com> wrote:
> > >The patches are on the mailing list archives somewhere around
> > >Sept. 5th timeframe from me; as I recall we dropped them as they
> > >didn't apply on top of Junio's 64 bit index changes (which were
> > >reverted out of next anyway).
> >
> > I seem to be unable to find them. Does anyone still has the
> > patches/branch please? Junio, you did sound interested?
> > (God, I wish I have paid attention then...)
You can't find them because I never sent them. *sigh*
Too f'ing bad this .patch I created with format-patch doesn't say
what commits it was based on, 'cause I can't find anything it will
apply too. Or better, too f'ing bad I deleted that branch. *sigh*
--
^ permalink raw reply
* Re: win2k/cygwin cannot handle even moderately sized packs
From: Shawn Pearce @ 2006-11-07 18:56 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20061107182636.GD26591@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Shawn Pearce <spearce@spearce.org> wrote:
> > Alex Riesen <raa.lkml@gmail.com> wrote:
> > > >The patches are on the mailing list archives somewhere around
> > > >Sept. 5th timeframe from me; as I recall we dropped them as they
> > > >didn't apply on top of Junio's 64 bit index changes (which were
> > > >reverted out of next anyway).
> > >
> > > I seem to be unable to find them. Does anyone still has the
> > > patches/branch please? Junio, you did sound interested?
> > > (God, I wish I have paid attention then...)
>
> You can't find them because I never sent them. *sigh*
>
> Too f'ing bad this .patch I created with format-patch doesn't say
> what commits it was based on, 'cause I can't find anything it will
> apply too. Or better, too f'ing bad I deleted that branch. *sigh*
This thread has now proven without any shadow of a doubt that I can
be an idiot sometimes.
In this case my patch didn't apply because it was 3rd in a series;
I had two of those patches but lacked the third (a simple cleanup
patch). Redoing that simple cleanup let everything apply.
I've pushed the changes out to repo.or.cz:
http://repo.or.cz/w/git/fastimport.git
in the window-mapping branch. Note that this is based on a slightly
older version of Git (v1.4.2). There are two "tuneables" on line 376
of sha1_file.c, this is the maximum amount of memory (in bytes) to
denote to packs and the maximum chunk size of each pack (in bytes).
I planned on making these configuration options but didn't get to
that yet.
--
^ permalink raw reply
* Re: [PATCH] Add a MIME-Version header to e-mails
From: Catalin Marinas @ 2006-11-07 19:09 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <b0943d9e0611070153s2a52f65k6ed4643e60a144b3@mail.gmail.com>
On 07/11/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> I'll include these patches (maybe modified) and I'll try to fix
> "import" as well.
I re-implemented parts of the mail and import commands (inspiring from
your patches). They now use the email Python package. The mail command
encodes the body to 7 or 8bit depending on non-ascii characters. The
headers are QP-encoded. The import command can decode messages
properly and can also handle multipart e-mails.
I still have to write a test script but my simple tests showed that it
works. Please let me know if there is anything wrong (especially with
the QP-encoding of the mail headers).
Thanks.
--
^ permalink raw reply
* Re: win2k/cygwin cannot handle even moderately sized packs
From: Alex Riesen @ 2006-11-07 19:27 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20061107182636.GD26591@spearce.org>
Shawn Pearce, Tue, Nov 07, 2006 19:26:36 +0100:
> Too f'ing bad this .patch I created with format-patch doesn't say
> what commits it was based on, 'cause I can't find anything it will
> apply too. Or better, too f'ing bad I deleted that branch. *sigh*
Maybe you just send the patch anyway? It could give someone an idea
where to start, or what not to do...
^ permalink raw reply
* Re: If merging that is really fast forwarding creates new commit
From: Junio C Hamano @ 2006-11-07 21:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Liu Yubao
In-Reply-To: <Pine.LNX.4.64.0611070729370.3667@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Git doesn't even have that concept. There is the concept of a _default_
> branch ("master"), and yes, the git repository has it. But at the same
> time, it really is just a default. There are three "main" branches that
> Junio maintains, and they only really differ in the degree of development.
> And "master" isn't even the most stable one - it's just the default one,
> because it's smack dab in the middle: recent enough to be interesting, but
> still stable enough to be worth tracking for just about anybody.
>
> But really, "maint" is the stable branch, and in many ways you could say
> that "maint" is the trunk branch, since that's what Junio still cuts
> releases from.
The branch 'maint' is meant to be the moral equivalent of the
efforts of your -stable team, so it shouldn't be "the trunk",
but you caught me.
We haven't seen a new release from 'master' for about a month.
I think the dust has settled already after two big topics
(packed-refs, delta-offset-base) were merged into 'master' since
v1.4.3, and it is now time to decide which topics that have been
cooking in 'next' are the ones I want in v1.4.4. Perhaps by the
end of the week, I'll cut a v1.4.4-rc1 to start the pre-release
stabilization process. No new features nor enhancements on
'master' after that until v1.4.4 final.
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Jakub Narebski @ 2006-11-07 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xiochw0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Here is example code for this:
>
> Ok. The issues I raised in the previous round seem to have been
> addressed. Maybe you would want not to use nested 'sub' and it
> is good to go, I think.
Should I understand this as a statement that you prefer backslash
sequences aka. Character Escape Codes (CEC) than "Unicode" escaping
aka. Unicode Printable Representation (PR)?
Should I send better quoting/unquoting work as two patches: unquote
correction plus '?' using esc_path + esc_path which uses backslash
sequences and span.cntrl element, or should it be send as one,
admittedly quite large patch.
I don't think it would be good idea to separate unquote correction with
esc_path work, because havin unquote which unquotes fully means that we
can have filenames which have for exampl newline characters in them,
hence the need of separate quoting subroutine, esc_path, and using it
for filename escaping.
--
Jakub Narebski
^ permalink raw reply
* Planned new release of git [was: Re: If merging that is really fast forwarding creates new commit]
From: Jakub Narebski @ 2006-11-07 22:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vhcxb2b15.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> We haven't seen a new release from 'master' for about a month.
> I think the dust has settled already after two big topics
> (packed-refs, delta-offset-base) were merged into 'master' since
> v1.4.3, and it is now time to decide which topics that have been
> cooking in 'next' are the ones I want in v1.4.4. Perhaps by the
> end of the week, I'll cut a v1.4.4-rc1 to start the pre-release
> stabilization process. No new features nor enhancements on
> 'master' after that until v1.4.4 final.
Do I understand correctly that the work on not exploding downloaded
pack on fetch, but making it non-thin, and related work on archival
packs (not to be considered for repacking) is not considered ready
(and tested)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: gitk feature request..
From: Paul Mackerras @ 2006-11-07 22:12 UTC (permalink / raw)
To: Pierre Marc Dumuid; +Cc: git, Junio C Hamano
In-Reply-To: <452A37FB.60507@adelaide.edu.au>
Pierre Marc Dumuid writes:
> I was adviced on the IRC channel to send my feature requests here...
Best to cc me as well on gitk feature requests, since I don't always
keep up with the git mailing list very well.
> I have two feature requests:
> 1. a bugzilla to place feature requests.
> 2. All the stored "views" that can be created and placed under the
> "view" menu should be unique for each repository.
Good idea. Junio, is there a canonical place under .git where gitk
should put such things?
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Junio C Hamano @ 2006-11-07 22:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611072253.34291.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> I don't think it would be good idea to separate unquote correction with
> esc_path work, because havin unquote which unquotes fully means that we
> can have filenames which have for exampl newline characters in them,
> hence the need of separate quoting subroutine, esc_path, and using it
> for filename escaping.
Yeah, I think that makes sense.
No matter what escaping we would end up picking in the second
part, we should do the unquote plus esc_path anyway, so I think
a two patch series to replace to '?' first and then pretty-print
that '?' with whatever encoding and span.cntrl is a very
sensible way to go.
As to backslash, cute control pictures and just plain '?', I do
not have a strong preference among them. Especially if you have
the span.cntrl around them, we can tell even a plain '?' from
the substitution of funny byte values, so it probably is just a
matter of taste and I'd leave that up to you and gitweb cabal on
the list ;-).
^ permalink raw reply
* Re: gitk feature request..
From: Junio C Hamano @ 2006-11-07 22:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Pierre Marc Dumuid
In-Reply-To: <17745.1213.22769.420355@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Good idea. Junio, is there a canonical place under .git where gitk
> should put such things?
Well, we do not design things in advance but tend to let things
evolve, which probably is a bad habit but I am not sure how else
we can avoid overdesigning before knowing the needs.
The existing state-keeping programs seem to keep their stuff
immediately under $GIT_DIR. Examples are:
.git/description (gitweb)
.git/cvs-authors (cvsimport)
.git/gitcvs.<branch>.sqlite (cvsserver)
So, .git/gitk-<foo> (or .git/gitk/<bar>) would be in line with
others. We _might_ want to have a standard plan to keep
Porcelains stepping on each other's toes, and probably migrating
everybody to .git/aux/{common,gitcvs,gitk,...}/<foo> would be a
sane thing to do. description and cvs-authors could probably be
shared across Porcelains, so I do not think we mind leaving them
in the current place or throw them in .git/aux/common/
Having said that, is the gitk view supposed to be shared across
users of a single repository?
If you imagine yourself logging into kernel.org (perhaps X
forwarded over ssh to your local machine) and browsing
/pub/scm/git/git.git/, the repository itself would not be
writable by you. Even if it were, I do not think you would want
me to reuse the view you used from there next time I did the
same on the same repository.
It might make sense to give --state=dir/ parameter to gitk and
tell it to use that directory to keep persistent data. Also I
seem to recall you already have one file under $HOME/ to make
window geometry or something persistent.
^ permalink raw reply
* Re: [RFC] git-gui: A commit / fetch / push interface
From: Paul Mackerras @ 2006-11-07 22:46 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061107083603.GB9622@spearce.org>
Shawn Pearce writes:
> I liked it and wanted to start making it available to some folks I
> work with who are more comfortable with the mouse than they are with
> the keyboard. At first I tried fixing a few of the outstanding bugs
> in gitool but I eventually wound up rewriting the thing from scratch.
Cool!
> I have posted a repository with the source on pasky's service:
>
> http://repo.or.cz/w/git-gui.git
Shouldn't the "w" be "r" there? It gave me an error "Can't lock ref"
with the "w".
> My goal is to have enough operations available through git-gui that
> the average user won't need to leave it, unless he/she needs to do a
> cherry-pick, am, etc. type of operation. Or they want to browse the
> history, in which case they can just start gitk from within git-gui.
> I'm hoping to have most of it done this week. :-)
One thing I have been meaning to do is to integrate gitool into gitk,
now that gitk can display a fake commit showing the local changes. I
intend to add a menu item to gitk saying "Commit local changes" or
something, which would invoke gitool, or maybe now git-gui instead. :)
The nice thing is that then gitk could update the graph to show the
new commit once it was created.
My current version of gitool also has menus that let you revert
modified files, and delete or ignore untracked files. Have you
considered adding that to git-gui?
Regards,
^ permalink raw reply
* Re: Planned new release of git [was: Re: If merging that is really fast forwarding creates new commit]
From: Linus Torvalds @ 2006-11-07 23:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <eiqvoh$ebd$1@sea.gmane.org>
On Tue, 7 Nov 2006, Jakub Narebski wrote:
>
> Do I understand correctly that the work on not exploding downloaded
> pack on fetch, but making it non-thin, and related work on archival
> packs (not to be considered for repacking) is not considered ready
> (and tested)?
I'd like to see a new version with both the packed refs and the
non-exploading download on by default. Maybe time for a git-1.5.0 release
from master?
^ permalink raw reply
* Re: win2k/cygwin cannot handle even moderately sized packs
From: Alex Riesen @ 2006-11-07 23:11 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20061107185648.GE26591@spearce.org>
Shawn Pearce, Tue, Nov 07, 2006 19:56:48 +0100:
> I've pushed the changes out to repo.or.cz:
>
> http://repo.or.cz/w/git/fastimport.git
>
> in the window-mapping branch. Note that this is based on a slightly
> older version of Git (v1.4.2). There are two "tuneables" on line 376
> of sha1_file.c, this is the maximum amount of memory (in bytes) to
> denote to packs and the maximum chunk size of each pack (in bytes).
Thanks.
I couldn't help noticing that the interface to the packs data is
a bit complex:
unsigned char *use_pack(struct packed_git *p,
struct pack_window **window,
unsigned long offset,
unsigned int *left);
void unuse_pack(struct pack_window **w);
Can I suggest something like below?
unsigned char *use_pack(struct packed_git *p,
off_t offset, size_t size, size_t *mapped);
void unuse_pack(struct packed_git *p, off_t offset, size_t size);
or
void unuse_pack(struct packed_git *p, unsigned char *data);
(where size/maxsize is the amount of bytes at the offset in the
pack file the caller was asking for. use_pack would fail if offset
or size do not pass sanity checks (offset past end of file, size
is 0). The mapped argument would get the length of the data
actually mapped, and can be less than requested, subject to end of
data). The window sliding code seem to have all information it
needs with this set of arguments.
Or am I missing something very obvious, and something like this
is just not feasible for some reasons?
I'm asking because I tried to slowly rebase the window-mapping up and
merge the newer branches into it (to get it working with more recent
code). At some point I came over conflicts and one of them got me
thinking about the interface. That's the part:
<<<<<<< HEAD/sha1_file.c
c = *use_pack(p, w, offset++, NULL);
*type = (c >> 4) & 7;
size = c & 15;
shift = 4;
while (c & 0x80) {
c = *use_pack(p, w, offset++, NULL);
size += (c & 0x7f) << shift;
shift += 7;
}
*sizep = size;
return offset;
=======
used = unpack_object_header_gently((unsigned char *)p->pack_base +
offset,
p->pack_size - offset, type, sizep);
if (!used)
die("object offset outside of pack file");
return offset + used;
>>>>>>> f685d07de045423a69045e42e72d2efc22a541ca/sha1_file.c
I was almost about to move your code into unpack_object_header_gently,
but ... The header isn't that big, is it? It is variable in the pack,
but the implementation of the parser is at the moment restricted by
the type we use for object size (unsigned long for the particular
platform). For example:
/* Object size is in the first 4 bits, and in the low 7 bits
* of the subsequent bytes which have high bit set */
#define MAX_LOCAL_HDRSIZE ((sizeof(long) * 8 - 4) / 7 + 1)
unsigned long size;
unsigned char *header = use_pack(p, offset, MAX_LOCAL_HDRSIZE, &size);
if (!header)
die("object header offset out of range");
/* unpack_object_header_gently takes care about truncated
* headers, by returning 0 if it encounters one */
used = unpack_object_header_gently(header, size, type, sizep);
Wouldn't have to change unpack_object_header_gently at all.
(BTW, current unpack_object_header_gently does not use it's len
argument to check if there actually is enough data to hold at least
minimal header. Is the size of mapped data checked for correctness
somewhere before?)
^ permalink raw reply
* Re: Planned new release of git
From: Junio C Hamano @ 2006-11-07 23:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: jnareb
In-Reply-To: <eiqvoh$ebd$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> We haven't seen a new release from 'master' for about a month.
>> I think the dust has settled already after two big topics
>> (packed-refs, delta-offset-base) were merged into 'master' since
>> v1.4.3, and it is now time to decide which topics that have been
>> cooking in 'next' are the ones I want in v1.4.4. Perhaps by the
>> end of the week, I'll cut a v1.4.4-rc1 to start the pre-release
>> stabilization process. No new features nor enhancements on
>> 'master' after that until v1.4.4 final.
>
> Do I understand correctly that the work on not exploding downloaded
> pack on fetch, but making it non-thin, and related work on archival
> packs (not to be considered for repacking) is not considered ready
> (and tested)?
Perhaps I phrased it badly, but I doubt it.
In the above I am only saying that it probably is time for me to
decide which ones to further merge into 'master', without saying
which ones I think is ready right now. That is because I
haven't started thinking about it.
^ permalink raw reply
* Re: Planned new release of git
From: Junio C Hamano @ 2006-11-07 23:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611071504200.3667@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 7 Nov 2006, Jakub Narebski wrote:
>>
>> Do I understand correctly that the work on not exploding downloaded
>> pack on fetch, but making it non-thin, and related work on archival
>> packs (not to be considered for repacking) is not considered ready
>> (and tested)?
>
> I'd like to see a new version with both the packed refs and the
> non-exploading download on by default. Maybe time for a git-1.5.0 release
> from master?
Don't worry, packed refs is already part of 'master' so whatever
the next feature release is called it will be part of it ;-).
^ 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