* Re: pull/push inconsistencies
From: Martin Langhoff @ 2007-05-16 22:35 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46a038f90705151851i9027e01x993300b1b50d0285@mail.gmail.com>
On 5/16/07, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> I'm probably in a bad-communication day :-/
Ok - I just repro'd the problem -- maybe this helps clarify...
I have a checkout of http://git.catalyst.net.nz/git/moodle-r2.git (
see http://git.catalyst.net.nz/gitweb ) where I have the following
tracking branches:
$ git branch
mdl17-polhn
* mdl18-local
I know that I am "all pushed out" - no local commits to push here. So
I start my day and do
$ git-pull
# brings some commits, but nothing to mdl18-local
$ git-merge origin/MOODLE_18_STABLE
# messy merge from the upstream branch I track...
$ git-commit
$ git-push
$ git-push
updating 'refs/heads/mdl18-local'
from f3f1ae5c9f73fe6e0872dfe0e072521b6fe26463
to 3af93dafbd9162423e5f0a720d4d2081313789e2
updating 'refs/remotes/origin/MOODLE_18_STABLE'
from 52abd5d7c4f0ac54cfc0463d5276c159a02a76c0
to 4cfaa3c85ee54ec8c0891157a6becdd8db34eb52
updating 'refs/remotes/origin/cvshead'
from 7bf579b243717c470770b1457a7d1c50f6a8dff6
to e835361626c5cd27cabdc046fc0e23a2c6ff98db
updating 'refs/remotes/origin/mdl18-ldc'
from eb91f220ccbbeb1e8b43496d0172e6cd1b6549ea
to af4c6ee952057d11b2dbf55103a5c3134640b70f
updating 'refs/remotes/origin/mdl18-topnz'
from a08fdb4decfa7b92c3030801c08378ee629c038d
to 347bc44adbfdf7b800334cbb532d436fa73e87ac
(removed some tag-related noise)
Generating pack...
Done counting 212 objects.
Result has 72 objects.
Deltifying 72 objects...
100% (72/72) done
Writing 72 objects...
Unpacking 72 objects
100% (72/72) done
Total 72 (delta 65), reused 0 (delta 0)
refs/heads/mdl18-local: f3f1ae5c9f73fe6e0872dfe0e072521b6fe26463 ->
3af93dafbd9162423e5f0a720d4d2081313789e2
refs/remotes/origin/MOODLE_18_STABLE:
52abd5d7c4f0ac54cfc0463d5276c159a02a76c0 ->
4cfaa3c85ee54ec8c0891157a6becdd8db34eb52
refs/remotes/origin/cvshead:
7bf579b243717c470770b1457a7d1c50f6a8dff6 ->
e835361626c5cd27cabdc046fc0e23a2c6ff98db
refs/remotes/origin/mdl18-ldc:
eb91f220ccbbeb1e8b43496d0172e6cd1b6549ea ->
af4c6ee952057d11b2dbf55103a5c3134640b70f
refs/remotes/origin/mdl18-topnz:
a08fdb4decfa7b92c3030801c08378ee629c038d ->
347bc44adbfdf7b800334cbb532d436fa73e87ac
As you can see, it talks about updating lots of refs. Nonsense -- I
think it's a bug. The only ref being updated is origin/mdl18-local on
the remote repo, and it should update the local
refs/remotes/origin/mdl18-local.
cheers,
m
^ permalink raw reply
* Re: [PATCH 7/6] gitweb: Empty patch for merge means trivial merge, not no differences
From: Junio C Hamano @ 2007-05-16 22:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11793531552023-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Earlier commit 4280cde95fa4e3fb012eb6d0c239a7777baaf60c made gitweb
> show "No differences found" message for empty diff, for the HTML
> output. But for merge commits, either -c format we use or --cc format,
> empty diff doesn't mean no differences, but trivial merge.
>
> Show "Trivial merge" message instead of "No differences found" for
> merges.
Sounds good. Some people might want to treat "-s ours" merge
specially (in real life, when two branches fix the same bug
differently the result of the hand-resolution may end up being
the same as "-s ours" merge), although I do not think it is such
a big deal.
^ permalink raw reply
* [PATCH 7/6] gitweb: Empty patch for merge means trivial merge, not no differences
From: Jakub Narebski @ 2007-05-16 22:05 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11784930091585-git-send-email-jnareb@gmail.com>
Earlier commit 4280cde95fa4e3fb012eb6d0c239a7777baaf60c made gitweb
show "No differences found" message for empty diff, for the HTML
output. But for merge commits, either -c format we use or --cc format,
empty diff doesn't mean no differences, but trivial merge.
Show "Trivial merge" message instead of "No differences found" for
merges.
While at it reword conditional in the code for easier reading.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 549e027..8c688be 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2877,7 +2877,14 @@ sub git_patchset_body {
} continue {
print "</div>\n"; # class="patch"
}
- print "<div class=\"diff nodifferences\">No differences found</div>\n" if (!$patch_number);
+
+ if ($patch_number == 0) {
+ if (@hash_parents > 1) {
+ print "<div class=\"diff nodifferences\">Trivial merge</div>\n";
+ } else {
+ print "<div class=\"diff nodifferences\">No differences found</div>\n";
+ }
+ }
print "</div>\n"; # class="patchset"
}
--
1.5.1.4
^ permalink raw reply related
* Re: Opinions on bug fix organisation
From: Martin Langhoff @ 2007-05-16 21:51 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200705161138.30134.andyparkins@gmail.com>
On 5/16/07, Andy Parkins <andyparkins@gmail.com> wrote:
> I quite like option 2 because it records intent - i.e. "I wish I could have
> gone back and changed this revision, but I can't", but it makes a more
> complicated history.
I prefer just letting history show what happened, rather than try to
get too smart about it ;-) -- and use branches and merges for
experimental or feature work. Once a feature or experimental branch is
merged into master, further work happens on master (unless there are
other reasons for it to be maintained).
Bugfixes are part of the life of the maint and master branches.
Imagine your "option 2" being used to maintain git's maint branch.
Some bugs live in the code for 6 months. The merge graph would be
unreadable... and generally the project history would be really hard
to make sense of.
Most "special" practices around branches kind-of work in the
minimalistic case, but break down badly in real-life sized projects...
cheers,
martin
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Jakub Narebski @ 2007-05-16 21:54 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90705161426n3b928086t2d3e68749557f866@mail.gmail.com>
Martin Langhoff wrote:
> On 5/16/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Wed, 16 May 2007, Martin Langhoff wrote:
>> > Do the indexes have enough info to use them with http ranges? It'd be
>> > chunkier than a smart protocol, but it'd still work with dumb servers.
>> It would not be really performant, would it? Besides, not all Web servers
>> speak HTTP/1.1...
>
> Performant compared to downloading a huge packfile to get 10% of it?
> Sure! It'd probably take a few trips, and you'd end up fetching 20% of
> the file, still better than 100%.
That's why you should have something akin to backup policy for pack files,
like daily packs, weekly packs, ..., and the rest, just for the dumb
protocols.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: Change base font size to "small"
From: Jakub Narebski @ 2007-05-16 10:51 UTC (permalink / raw)
To: git; +Cc: Jan Hudec, David Kågedal, Petr Baudis
In-Reply-To: <20070515150912.GA3653@efreet.light.src>
Commit 63fcbe00a66d7cb7d8bce9a36120a19a809a33b8 by Peter "Pasky" Baudis
"gitweb: Do not use absolute font sizes"
made gitweb use default font size, the font size you have configured
your browser to use, as a basis; other font sizes are given as
percentage.
David Kågedal noticed problem with this approach: too many web sites
explicitly select extra small font sizes, which means that you have to
select a "standard" font size in your browser that is a bit larger
than one would actually like.
Additionally, as Jan Hudec noticed, gitweb should explicitely request
being somewhat smaller than normal, because it has good use for long
lines. Normally one would usually want to set font so large, that
more than ~120 characters won't fit on the screen, since otherwise
pages that don't use margins are simply unreadable. However gitweb
presents a table with several columns, so having wider line is OK for
it.
Jan Hudec proposed to use 'font-size: small' to take above issues into
account. This avoid using "brain-damaged" explicit-pixel sizes, while
taking into account nature of gitweb output.
Thanks to mentioned commit by Pasky we need to add 'font-size: small'
in only one place, for BODY element.
See the original messages:
Message-ID: <87odkmgaj5.fsf@morpheus.local>
Message-ID: <20070515150912.GA3653@efreet.light.src>
Proposed-by: Jan Hudec <bulb@ucw.cz>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is commit wich has commit message larger than patch itself, but
I think the explanation is as important as patch itself, perhaps even
more important.
gitweb/gitweb.css | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index b57c8be..02623cb 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -1,5 +1,6 @@
body {
font-family: sans-serif;
+ font-size: small;
border: solid #d9d8d1;
border-width: 1px;
margin: 10px;
--
1.5.1.4
^ permalink raw reply related
* Re: Opinions on bug fix organisation
From: Shawn O. Pearce @ 2007-05-16 21:38 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano
In-Reply-To: <200705162220.15417.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> What is your preference when, for example, you have already merged a
> topic to next but then a bug fix appears?
>
> * -- * -- * -- M -- F * -- * -- * -- M -- m (next)
> / or / /
> B -- * -- * B -- * -- * -- F (topic)
>
> F is certainly most appropriate to be on the topic branch, but we create
> a perhaps excessively verbose extra merge, m.
Look at the history of the next branch; the diagram on the right is
exactly what Junio does. When topic finally graduates to master,
only F is merged to master, making master's own history not show
that "verbose extra merge" m. Or M really for that matter, as
master gets its own M'.
--
Shawn.
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Martin Langhoff @ 2007-05-16 21:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jan Hudec, git
In-Reply-To: <Pine.LNX.4.64.0705161232120.6410@racer.site>
On 5/16/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 16 May 2007, Martin Langhoff wrote:
> > Do the indexes have enough info to use them with http ranges? It'd be
> > chunkier than a smart protocol, but it'd still work with dumb servers.
> It would not be really performant, would it? Besides, not all Web servers
> speak HTTP/1.1...
Performant compared to downloading a huge packfile to get 10% of it?
Sure! It'd probably take a few trips, and you'd end up fetching 20% of
the file, still better than 100%.
> Besides, not all Web servers speak HTTP/1.1...
Are there any interesting webservers out there that don't? Hand-rolled
purpose-built webservers often don't but those don't serve files, they
serve web apps. When it comes to serving files, any webserver that is
supported (security-wise) these days is HTTP/1.1.
And for services like SF.net it'd be a safe low-cpu way of serving git
files. 'cause the git protocol is quite expensive server-side (io+cpu)
as we've seen with kernel.org. Being really smart with a cgi is
probably going to be expensive too.
cheers,
m
^ permalink raw reply
* Re: Opinions on bug fix organisation
From: Andy Parkins @ 2007-05-16 21:20 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v1whgfybe.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2007, May 16, Junio C Hamano wrote:
> I think that largely depends on your taste and what other things
> you have between B and the tip when you contemplate on the fix.
As always, thank you for the detailed response. I appreciate the
thought that goes into answering these questions that flit into my
mind :-)
> is fixed as close to the introduction of bug as practical (so I
> would _not_ fork a fix on top of B itself, but apply fix to the
> tip of 'maint'), and then all newer development track that
> contain breakage B merges the fix from that branch (i.e. 'maint'
> is then merged into 'master' to propagate the fix forward).
The above method is almost a necessity when using git. If the bug fix
is committed to master, there is no way to apply that same commit to
the maint branch without also grabbing commits you don't want in maint.
> The way 'next' and 'master' works in git.git looks a bit
> different from it, but you will realize that the idea is the
> same if you look at individual topic branches. Each topic is
> forked from 'master', gain its own commits and merged to 'next'.
I've noticed flows like that when looking at git history. I always
think that it demonstrates the power of git's strong-on-branches stance
because you can almost feel the story of the development without having
to read any of the commits themselves. I wonder if other DVCSs
encourage creation of such a strong narrative?
> Its bugs may be discovered later while it still hasn't been
> merged to 'master'. I'd _never_ commit a fix to 'next'
> directly, but a fix goes to the tip of the topic branch that
> introduces the bug, and then merged to 'next'. When the topic
> is reasonably bug-free, it then is merged to 'master' -- at that
> point, the history of the topic has all the relevant fixes.
What is your preference when, for example, you have already merged a
topic to next but then a bug fix appears?
* -- * -- * -- M -- F * -- * -- * -- M -- m (next)
/ or / /
B -- * -- * B -- * -- * -- F (topic)
F is certainly most appropriate to be on the topic branch, but we create
a perhaps excessively verbose extra merge, m.
> just a random set of development), I think your latter approach
> to have only the fix as a separate (temporary) topic and merge
> that to the tip is inconsistent with your current practice to
> begin with, and I do not see much merit in it by itself. If you
> prefer the latter solution (and I obviously do, as that is the
I'm not sure I've understood what you mean here. Which "latter" are you
talking about - you've said that you find the latter inconsistent but
also that you prefer the latter solution. I'm lost :-)
> way git.git repository is maintained), you would also want to
> have topic branches, where all the enhancements, advances _and_
> fixes related to a single theme go to and then merged to the
> mainline. That's the history of a theme. Having branch and
> merge only for fixes but not for advancement may be "the history
> of a bug", but it probably would not buy you much by itself.
It's not so much a matter of it buying you something, it is more that
when you find that bug fix commit in history you can see, by following
the fix-branch back to its source, all the revisions that contained
that bug at a glance; if you just commit on the end, you have to do the
digging yourself, and hope that someone mentioned in the commit message
which commit introduced the bug that that commit fixes.
The fact that git makes it so easy to branch and merge from a previous
point is the thing that even makes this a possibility. Perhaps I'm
spoilt now :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Karl Hasselström @ 2007-05-16 20:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070516194002.GA17805@diana.vm.bytemark.co.uk>
On 2007-05-16 21:40:02 +0200, Karl Hasselström wrote:
> On 2007-05-16 13:07:14 +0100, Catalin Marinas wrote:
>
> > I did a quick test of 'stg series' with the DAG patches applied,
> > on a Linux kernel repository ('du -sh .git' is 285M) with 42
> > patches (only 25 applied). It constantly takes over 2 seconds to
> > complete (compared to < 200ms without the DAG patches). The
> > problem is that this delay will happen for bash completion as
> > well.
>
> This is more than ten times as expensive as in my measurement.
> Curious. And the algorithm is designed so that it shouldn't take
> time proportional to the repository size, just proportional to the
> number of patches.
I set up a kernel repository with 100 applied and 100 unapplied
patches:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
$ cd linux-2.6/
$ stg init
$ for ((i=0;i<200;i++)); do stg new p$(printf '%03d' $i) -m "Patch $i"; done
$ stg goto p099
Then repeatedly:
$ time stg series >/dev/null
This gives times such as
real 0m0.247s
user 0m0.156s
sys 0m0.060s
real 0m0.147s
user 0m0.088s
sys 0m0.036s
real 0m0.153s
user 0m0.088s
sys 0m0.032s
real 0m0.144s
user 0m0.104s
sys 0m0.024s
Tab completion also feels like it takes 0.1-0.2 seconds -- which it
should, since it's implemented with series, applied, and unapplied,
allow which do the same amount of work.
But my kernel repository is _much_ smaller than yours:
$ du -sh .git
183M .git
Do you perchance have a bunch of loose objects in there?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: MinGW port: some questions
From: Alon Ziv @ 2007-05-16 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejlgegb9.fsf@assigned-by-dhcp.cox.net>
On Wed, 2007-05-16 at 12:09 -0700, Junio C Hamano wrote:
> I do not know if you mistyped dc380d6 (I do not find it there),
I did; it was dc3806d. I don't know how it slipped... I usually
cut'n'paste commit IDs :-/
> but reverting 4493e36 (merge of jc/3way) was intentional. The
> work in that commit that deviates from the mainline is the
> jc/3way topic, which turned out to be incomplete and not very
> usable.
I know it was intentional; but the revert happened on Feb 13, and the
MinGW port is supposed to be merged up to v1.5.1. The revert of dc3806d
("in_merge_bases(): optimization") and 40e0e66 ("merge_base(): move
traversal into a separate function.") also happened on Feb 13, and both
of there commits are still present in the MinGW master branch.
Maybe I'll just try cherry-picking the port's commits on top of the
latest master, and see if anything breaks :)
-az
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Karl Hasselström @ 2007-05-16 19:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0705160507h2b3c4a34xe9895d007c41d91a@mail.gmail.com>
On 2007-05-16 13:07:14 +0100, Catalin Marinas wrote:
> I did a quick test of 'stg series' with the DAG patches applied, on
> a Linux kernel repository ('du -sh .git' is 285M) with 42 patches
> (only 25 applied). It constantly takes over 2 seconds to complete
> (compared to < 200ms without the DAG patches). The problem is that
> this delay will happen for bash completion as well.
This is more than ten times as expensive as in my measurement.
Curious. And the algorithm is designed so that it shouldn't take time
proportional to the repository size, just proportional to the number
of patches.
There are three git calls involved:
* List the references. There can't be more than a few hundred of
them.
* rev-list all patches, subtracting everything that's reachable from
the branch head. This set of commits should not be much larger
than the number of unapplied patches.
* rev-list the branch head, but stop walking as soon as all applied
patches have been seen. This set of commits should not be much
larger than the number of applied patches.
None of the calls should be expensive.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: newby question about merge.
From: Christian MICHON @ 2007-05-16 19:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705161542540.6410@racer.site>
On 5/16/07, Johannes Schindelin wrote:
> [please, Christian, do not cut the Cc: list. In particular, do _not_ cut
> the person you are _responding_ to from the Cc: list]
[ oops. I thought some of us sometimes receive doublets of emails,
being in reply_to and cc of git@vger.kernel.org. point *taken* ]
> > I could be wrong, but git-show works in this way only after version 1.5,
> > right ?
>
> Yes. So what?
I also sometimes use old git versions (I still consider 1.4.4.4 as a reference).
I know the API changes frequently. But engineers don't like too many changes
usually, and like to carry a portable/stable way. "git cat-file" at
least behaves
as it was in 1.4.x :)
> > As far as I can tell, using git-1.4.4.4 or ealier, you would still need
> > git-cat-file -p... to fix this merge conflict.
>
> If you are using pre-1.5 Git, you should really, really upgrade.
While in principle I'd agree, in practice I do not. Git API changes
increased learning curve for people who actually started with git a
year ago.
Note this is a git user feedback, not a git developer feedback.
>
> If you do not want to do that, then _at least_ you should not confuse
> newbies, who _should_ use Git 1.5+.
hey, I'm not a newbie anymore! :)
it's just that today, on a machine I only had git-1.4.4.4 to play with,
I had to do a merge of 2 private branches ( aufs and squashfs) on
linux-2.6.21... I had 3 smalls conflicts to fix and I saw this thread...
and decided to stick with git-cat-file on this fix.
> And most importantly: if you suggest a change in the man pages, it should
> reflect the new Git versions, _not_ the old ones.
nope, I would not dare to suggest. I'm not a git developer: just a git user :)
> Okay?
yep
--
Christian
^ permalink raw reply
* Re: MinGW port: some questions
From: Junio C Hamano @ 2007-05-16 19:09 UTC (permalink / raw)
To: Alon Ziv; +Cc: git
In-Reply-To: <1179341520.31213.38.camel@bruno.nolaviz.org>
Alon Ziv <alonz@nolaviz.org> writes:
> I am referring, for example, to the changes from commit dc380d6, which
> were reverted in Git mainline (actually in "next", they never reached
> Git's "master"). Or to the changes from 4493e36, which had the same
> fate.
MinGW repository bases its work on my 'next', so it will not be
pulled wholesale to my 'master'. The plan is to trickle down
the platform independent bits of fixes and refactoring to the
mainline, as well as #ifdef __MINGW32__ and $(findstring MINGW)
parts, but that will most likely happen as a series of bite
sized patch series to the list with public reviews.
I do not know if you mistyped dc380d6 (I do not find it there),
but reverting 4493e36 (merge of jc/3way) was intentional. The
work in that commit that deviates from the mainline is the
jc/3way topic, which turned out to be incomplete and not very
usable. MinGW tree might not have synchronized with the latest
from the mainline in which case it might not have merged the
revert from me yet, and that may be why you are seeing the
differences.
^ permalink raw reply
* MinGW port: some questions
From: Alon Ziv @ 2007-05-16 18:52 UTC (permalink / raw)
To: git
Hi,
I am looking at the MinGW port, and I see some rather strange changes
included in the port; "strange" in the sense that they do not appear to
have anything to do with MinGW.
I am referring, for example, to the changes from commit dc380d6, which
were reverted in Git mainline (actually in "next", they never reached
Git's "master"). Or to the changes from 4493e36, which had the same
fate.
Are these intentional? Or are they the result of some strange mismerge?
-az
^ permalink raw reply
* Re: [PATCH] import-tars: Use the "Link indicator" to identify directories
From: Junio C Hamano @ 2007-05-16 18:49 UTC (permalink / raw)
To: spearce; +Cc: Chris Riddoch, git, Johannes Schindelin
In-Reply-To: <7vsl9weie0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> Earlier, we used the mode to determine if a name was associated with
>> a directory. This fails, since some tar programs do not set the mode
>> correctly. However, the link indicator _has_ to be set correctly.
Nah, what was I smoking. Even gtar seems to give mode="0000775"
(with NUL termination) for directories, so there is no way there
were regressions. Patch looks good.
Acked-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* MinGW port status
From: Alon Ziv @ 2007-05-16 18:24 UTC (permalink / raw)
To: git
Hi all,
What is the current status of the MinGW port? Are there any plans to
marge it into the Git main repository anytime soon?
Regards,
-az
^ permalink raw reply
* Re: [PATCH] import-tars: Use the "Link indicator" to identify directories
From: Junio C Hamano @ 2007-05-16 18:24 UTC (permalink / raw)
To: spearce; +Cc: Chris Riddoch, git, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0705161659530.6410@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Earlier, we used the mode to determine if a name was associated with
> a directory. This fails, since some tar programs do not set the mode
> correctly. However, the link indicator _has_ to be set correctly.
> The problem is -- again -- that a directory is overwritten, since
> it is not recognized as a directory. Earlier, I tried to use the
> trailing "/" for that. Which fails with your example.
>
> I actually took the time to research in Wikipedia what should be
> the correct way to find out if the current item is a directory...
This matches my reading of GNU tar as well. The patch would not
break a correctly made tar archive, would fix importing archives
created by a broken tar that does not do mode right (but uses the
correct typeflag), _and_ would _break_ archives created by tar
that is broken in a different way, sets the mode right but uses
a wrong typeflag.
I do not know which breakages are more common, and this one
being in contrib/ I do not think it really matters in practice,
but as a principle, I think we should try to adhere to the same
"no regression" policy the kernel folks try to adhere to. If
something used to work, even if its was by accident or a bug, we
had better have a pretty good reason to break it by a change
that fixes things for other people, _even_ when that other
people outnumber the people who are affected by the regression.
I'd first ask GNU tar maintainer if he knows of existing
implementations of tar that are broken in the latter sense (iow,
sets modes correctly but typeflag incorrectly), as the tarball
extraction codepath would have the exact same issue.
^ permalink raw reply
* Re: [PATCHv3] connect: display connection progress
From: Junio C Hamano @ 2007-05-16 18:00 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git, Linus Torvalds, Alex Riesen
In-Reply-To: <20070516170941.GA19449@mellanox.co.il>
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> Make git notify the user about host resolution/connection attempts.
> This is useful both as a progress indicator on slow links, and helps
> reassure the user there are no firewall problems.
Nicely done. Thanks.
^ permalink raw reply
* Re: Opinions on bug fix organisation
From: Junio C Hamano @ 2007-05-16 17:55 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200705161138.30134.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> I quite like option 2 because it records intent - i.e. "I wish I could have
> gone back and changed this revision, but I can't", but it makes a more
> complicated history.
>
> What do people think?
I think that largely depends on your taste and what other things
you have between B and the tip when you contemplate on the fix.
If you ever have a forkpoint (e.g. maybe soon after B you had a
tagged release, and maintenance track for that forked from it),
then the latter is much more manageable in the long run. That
is how 'master' and 'maint' in git.git are managed. An old bug
is fixed as close to the introduction of bug as practical (so I
would _not_ fork a fix on top of B itself, but apply fix to the
tip of 'maint'), and then all newer development track that
contain breakage B merges the fix from that branch (i.e. 'maint'
is then merged into 'master' to propagate the fix forward).
The way 'next' and 'master' works in git.git looks a bit
different from it, but you will realize that the idea is the
same if you look at individual topic branches. Each topic is
forked from 'master', gain its own commits and merged to 'next'.
Its bugs may be discovered later while it still hasn't been
merged to 'master'. I'd _never_ commit a fix to 'next'
directly, but a fix goes to the tip of the topic branch that
introduces the bug, and then merged to 'next'. When the topic
is reasonably bug-free, it then is merged to 'master' -- at that
point, the history of the topic has all the relevant fixes.
If you think of your straight single strand of pearls (the first
picture) as a degenerated case that has a topic that includes B
and ends with the tip, "merged" to 'master' in a fast forward
fashion (i.e. the rightmost commit in the picture is the tip of
the topic and at the same time the tip of the 'master'), then
having a fix on top of the 'master' like in your first solution
is perfectly fine -- it is in line with how topic branches in my
repository gets fixed and how the fix is propagated to 'next'
and then eventually to 'master'.
On the other hand, if your commits between B and the tip of your
master contain enhancements and fixes to random issues (iow, it
is not a degenerated merge of a single topic into 'master', but
just a random set of development), I think your latter approach
to have only the fix as a separate (temporary) topic and merge
that to the tip is inconsistent with your current practice to
begin with, and I do not see much merit in it by itself. If you
prefer the latter solution (and I obviously do, as that is the
way git.git repository is maintained), you would also want to
have topic branches, where all the enhancements, advances _and_
fixes related to a single theme go to and then merged to the
mainline. That's the history of a theme. Having branch and
merge only for fixes but not for advancement may be "the history
of a bug", but it probably would not buy you much by itself.
^ permalink raw reply
* Re: [PATCHv3] connect: display connection progress
From: Linus Torvalds @ 2007-05-16 17:19 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git, Alex Riesen
In-Reply-To: <20070516170941.GA19449@mellanox.co.il>
On Wed, 16 May 2007, Michael S. Tsirkin wrote:
>
> Make git notify the user about host resolution/connection attempts.
> This is useful both as a progress indicator on slow links, and helps
> reassure the user there are no firewall problems.
Looks fine to me. Ack.
Linus
^ permalink raw reply
* [PATCHv3] connect: display connection progress
From: Michael S. Tsirkin @ 2007-05-16 17:09 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git, Linus Torvalds, Alex Riesen
Make git notify the user about host resolution/connection attempts.
This is useful both as a progress indicator on slow links, and helps
reassure the user there are no firewall problems.
Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
---
Tried to incorporate most of the feedback on v2.
Once some commands get -vv flag, we'll be able to add
CONNECT_EXTRA_VERBOSE and print out address information etc,
but this is outside the scope of this patch.
diff --git a/builtin-archive.c b/builtin-archive.c
index 7f4e409..187491b 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -45,7 +45,7 @@ static int run_remote_archiver(const char *remote, int argc,
}
url = xstrdup(remote);
- pid = git_connect(fd, url, exec);
+ pid = git_connect(fd, url, exec, 0);
if (pid < 0)
return pid;
diff --git a/cache.h b/cache.h
index aaeb04a..206bbe4 100644
--- a/cache.h
+++ b/cache.h
@@ -463,7 +463,8 @@ struct ref {
#define REF_HEADS (1u << 1)
#define REF_TAGS (1u << 2)
-extern pid_t git_connect(int fd[2], char *url, const char *prog);
+#define CONNECT_VERBOSE (1u << 0)
+extern pid_t git_connect(int fd[2], char *url, const char *prog, int flags);
extern int finish_connect(pid_t pid);
extern int path_match(const char *path, int nr, char **match);
extern int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
diff --git a/connect.c b/connect.c
index da89c9c..2a26fdb 100644
--- a/connect.c
+++ b/connect.c
@@ -394,7 +394,7 @@ static enum protocol get_protocol(const char *name)
/*
* Returns a connected socket() fd, or else die()s.
*/
-static int git_tcp_connect_sock(char *host)
+static int git_tcp_connect_sock(char *host, int flags)
{
int sockfd = -1, saved_errno = 0;
char *colon, *end;
@@ -425,10 +425,16 @@ static int git_tcp_connect_sock(char *host)
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
+ if (flags & CONNECT_VERBOSE)
+ fprintf(stderr, "Looking up %s ... ", host);
+
gai = getaddrinfo(host, port, &hints, &ai);
if (gai)
die("Unable to look up %s (port %s) (%s)", host, port, gai_strerror(gai));
+ if (flags & CONNECT_VERBOSE)
+ fprintf(stderr, "done.\nConnecting to %s (port %s) ... ", host, port);
+
for (ai0 = ai; ai; ai = ai->ai_next) {
sockfd = socket(ai->ai_family,
ai->ai_socktype, ai->ai_protocol);
@@ -450,6 +456,9 @@ static int git_tcp_connect_sock(char *host)
if (sockfd < 0)
die("unable to connect a socket (%s)", strerror(saved_errno));
+ if (flags & CONNECT_VERBOSE)
+ fprintf(stderr, "done.\n");
+
return sockfd;
}
@@ -458,7 +467,7 @@ static int git_tcp_connect_sock(char *host)
/*
* Returns a connected socket() fd, or else die()s.
*/
-static int git_tcp_connect_sock(char *host)
+static int git_tcp_connect_sock(char *host, int flags)
{
int sockfd = -1, saved_errno = 0;
char *colon, *end;
@@ -485,6 +494,9 @@ static int git_tcp_connect_sock(char *host)
port = colon + 1;
}
+ if (flags & CONNECT_VERBOSE)
+ fprintf(stderr, "Looking up %s ... ", host);
+
he = gethostbyname(host);
if (!he)
die("Unable to look up %s (%s)", host, hstrerror(h_errno));
@@ -497,6 +509,9 @@ static int git_tcp_connect_sock(char *host)
nport = se->s_port;
}
+ if (flags & CONNECT_VERBOSE)
+ fprintf(stderr, "done.\nConnecting to %s (port %s) ... ", host, port);
+
for (ap = he->h_addr_list; *ap; ap++) {
sockfd = socket(he->h_addrtype, SOCK_STREAM, 0);
if (sockfd < 0) {
@@ -521,15 +536,18 @@ static int git_tcp_connect_sock(char *host)
if (sockfd < 0)
die("unable to connect a socket (%s)", strerror(saved_errno));
+ if (flags & CONNECT_VERBOSE)
+ fprintf(stderr, "done.\n");
+
return sockfd;
}
#endif /* NO_IPV6 */
-static void git_tcp_connect(int fd[2], char *host)
+static void git_tcp_connect(int fd[2], char *host, int flags)
{
- int sockfd = git_tcp_connect_sock(host);
+ int sockfd = git_tcp_connect_sock(host, flags);
fd[0] = sockfd;
fd[1] = dup(sockfd);
@@ -646,7 +664,7 @@ static void git_proxy_connect(int fd[2], char *host)
*
* Does not return a negative value on error; it just dies.
*/
-pid_t git_connect(int fd[2], char *url, const char *prog)
+pid_t git_connect(int fd[2], char *url, const char *prog, int flags)
{
char *host, *path = url;
char *end;
@@ -719,7 +737,7 @@ pid_t git_connect(int fd[2], char *url, const char *prog)
if (git_use_proxy(host))
git_proxy_connect(fd, host);
else
- git_tcp_connect(fd, host);
+ git_tcp_connect(fd, host, flags);
/*
* Separate original protocol components prog and path
* from extended components with a NUL byte.
diff --git a/fetch-pack.c b/fetch-pack.c
index 06f4aec..aa59043 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -733,7 +733,7 @@ int main(int argc, char **argv)
}
if (!dest)
usage(fetch_pack_usage);
- pid = git_connect(fd, dest, uploadpack);
+ pid = git_connect(fd, dest, uploadpack, verbose ? CONNECT_VERBOSE : 0);
if (pid < 0)
return 1;
if (heads && nr_heads)
diff --git a/peek-remote.c b/peek-remote.c
index 96bfac4..ceb7871 100644
--- a/peek-remote.c
+++ b/peek-remote.c
@@ -64,7 +64,7 @@ int main(int argc, char **argv)
if (!dest || i != argc - 1)
usage(peek_remote_usage);
- pid = git_connect(fd, dest, uploadpack);
+ pid = git_connect(fd, dest, uploadpack, 0);
if (pid < 0)
return 1;
ret = peek_remote(fd, flags);
diff --git a/send-pack.c b/send-pack.c
index d5b5162..83ee87d 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -393,7 +393,7 @@ int main(int argc, char **argv)
usage(send_pack_usage);
verify_remote_names(nr_heads, heads);
- pid = git_connect(fd, dest, receivepack);
+ pid = git_connect(fd, dest, receivepack, verbose ? CONNECT_VERBOSE : 0);
if (pid < 0)
return 1;
ret = send_pack(fd[0], fd[1], nr_heads, heads);
--
MST
^ permalink raw reply related
* [PATCH] import-tars: Use the "Link indicator" to identify directories
From: Johannes Schindelin @ 2007-05-16 16:22 UTC (permalink / raw)
To: Chris Riddoch; +Cc: git, spearce
In-Reply-To: <6efbd9b70705111308v47a76b04n9328ebf393a209e6@mail.gmail.com>
Earlier, we used the mode to determine if a name was associated with
a directory. This fails, since some tar programs do not set the mode
correctly. However, the link indicator _has_ to be set correctly.
Noticed by Chris Riddoch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Fri, 11 May 2007, Chris Riddoch wrote:
> I believe I've uncovered an issue in fast-import, but I don't
> know the code well enough yet to debug it. So, I'll produce my
> evidence and let others work on finding the solution. It should
> be pretty easy to reproduce.
It was easy. Thanks.
The problem is -- again -- that a directory is overwritten, since
it is not recognized as a directory. Earlier, I tried to use the
trailing "/" for that. Which fails with your example.
I actually took the time to research in Wikipedia what should be
the correct way to find out if the current item is a directory...
contrib/fast-import/import-tars.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/import-tars.perl b/contrib/fast-import/import-tars.perl
index 1e6fa5a..23aeb25 100755
--- a/contrib/fast-import/import-tars.perl
+++ b/contrib/fast-import/import-tars.perl
@@ -75,7 +75,7 @@ foreach my $tar_file (@ARGV)
$mode = oct $mode;
$size = oct $size;
$mtime = oct $mtime;
- next if $mode & 0040000;
+ next if $typeflag == 5; # directory
print FI "blob\n", "mark :$next_mark\n", "data $size\n";
while ($size > 0 && read(I, $_, 512) == 512) {
--
1.5.2.rc3.2506.ge455
^ permalink raw reply related
* Re: Opinions on bug fix organisation
From: Brian Gernhardt @ 2007-05-16 14:46 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200705161138.30134.andyparkins@gmail.com>
On May 16, 2007, at 6:38 AM, Andy Parkins wrote:
> That is - just commit a fix or, commit the fix, "F", directly on
> "B" then
> merge that fix back to HEAD with "M".
>
> I quite like option 2 because it records intent - i.e. "I wish I
> could have
> gone back and changed this revision, but I can't", but it makes a more
> complicated history.
>
> What do people think?
I just encountered this myself with one of my repos. I'm developing
solo so I could just rebase if I felt like it, but don't like
developing that habit, so I'm probably going with the second one.
But that's because of how I'm developing it. My master has undergone
serious changes recently (since the bug commit), so I'm going back
and checking out the bug commit to focus on that issue without
anything else that's been changed since then.
My personal feeling is that the commit should reflect how the fix was
developed. If it's simple fix that you simply wrote on top of the
full branch, commit it that way. If you had to (or wanted to) go
back and develop on top of the original commit, commit it that way.
Usually I'll just commit on top of master, but if either I need to
remove other complications from the fix or need to introduce the fix
(but not everything else) into multiple branches, I'll do the merge.
~~ Brian
^ permalink raw reply
* Re: newby question about merge.
From: Johannes Schindelin @ 2007-05-16 14:45 UTC (permalink / raw)
To: Christian MICHON; +Cc: git
In-Reply-To: <46d6db660705160721u24e43f7bmb5171555158089fb@mail.gmail.com>
Hi,
[please, Christian, do not cut the Cc: list. In particular, do _not_ cut
the person you are _responding_ to from the Cc: list]
On Wed, 16 May 2007, Christian MICHON wrote:
> On 5/16/07, Johannes Schindelin wrote:
> > > You can just do "git cat-file -p :2:filename > filename", then "git
> > > add filename" (or "git update-index filename") to resolve conflict.
> >
> > Do we really want to advertise this obscure-looking plumbing? Wouldn't
> > it be better to teach people to use "git show" instead?
> >
> > I mean, people can get intimidated by that...
>
> I could be wrong, but git-show works in this way only after version 1.5,
> right ?
Yes. So what?
> As far as I can tell, using git-1.4.4.4 or ealier, you would still need
> git-cat-file -p... to fix this merge conflict.
If you are using pre-1.5 Git, you should really, really upgrade.
If you do not want to do that, then _at least_ you should not confuse
newbies, who _should_ use Git 1.5+.
And most importantly: if you suggest a change in the man pages, it should
reflect the new Git versions, _not_ the old ones.
Okay?
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox