* Help designing work flow
From: John Dlugosz @ 2009-03-05 20:17 UTC (permalink / raw)
To: git
I know we (my group) should use "topic" branches and apply them back to
the dev branch when done. There is concern that the commit history gets
too full of detailed stuff, especially with several developers, that you
can't tell what "really changed". So, our dev branch should appear to
contain only commit nodes representing completed assignments; not every
day's checkpoint and trying to keep one's own stuff on top to avoid
merging later.
I guess that's how it is on these Open Source projects where patches are
submitted by email and applied by the maintainer. We don't see the
details, just the final patch. But, my situation will be developers
gathered around an in-house master repo, and everyone should be able to
push their own changes as assignments are completed.
What is the best procedure to achieve that? Or what are some good
alternatives with trade-offs?
I see that if a topic branch is merged (disabling FF if applicable), the
main line (leftmost parent) will be a history of completed topics. But,
we don't need to keep the detailed side-branches forever, and even if
gitk and other visualization tools can be told to just show the main
line, advanced use such as git log this..that will forever be packed
with the micro-details.
So, unless someone has more input along that line, I'm assuming that we
want to apply the completed topic as a single-parent commit. That is
the natural result if preparing patches and then applying them, but is
there a simpler, direct way to do that in git?
The detailed topic branches can be kept around for a while, for the
original author to extend if it needs to be returned to, and to examine
if the gestalt change in the single commit is too overwhelming to
understand, or to help figure out what might have broken. But after a
while they can be deleted and then gc will free up the disk space.
Anything else I should look into?
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* [ANNOUNCE] TopGit 0.7
From: Uwe Kleine-König @ 2009-03-05 20:27 UTC (permalink / raw)
To: git
Hello *,
I'm happy to announce that TopGit 0.7 was released today.
This release brings you several bug fixes and a few new features.
The most useful new feature (in my opinon) is a new export method that
provides your patches as a linear history in a regular git branch for
pulling by your upstream.
TopGit aims to make handling of large amount of interdependent topic
branches easier. In fact, it is designed especially for the case when
you maintain a queue of third-party patches on top of another (perhaps
Git-controlled) project and want to easily organize, maintain and submit
them - TopGit achieves that by keeping a separate topic branch for each
patch and providing few tools to maintain the branches
You can get TopGit at
http://repo.or.cz/w/topgit.git
or if you run Debian you can install the version from the
unstable distribution[*1*].
If you want to read more about TopGit's design, usage and
implementation, let me point you to TopGit's README at
http://repo.or.cz/w/topgit.git?a=blob;f=README
The full shortlog since version TopGit 0.5[*2*] can be found below.
I would be happy if you gave it a try and reported your impressions,
suggestions and bugs.
Best regards
Uwe
[*1*] Up to now it didn't hit unstable, but if you cannot wait for a few
hours you have to install from source :-)
[*2*] Version 0.6 was skipped, because a change bumping the version
number was accidently pushed to a public repo. As the latest
version get some more changes, we decided to skip to 0.7.
Bert Wesarg (1):
tg-summary: -t and --graphviz are mutual exclusive
Jonas Fonseca (1):
README: spelling fixes
Kirill Smelkov (5):
tg-completion: complete options for `tg summary`
tg-completion: complete options for `tg remote`
Implement setup_pager just like in git
tg-patch: fix pagination
tg-patch: add support for generating patches against worktree and index
Marc Weber (1):
Pass -- to rev-list for branch/filename disambiguation
Uwe Kleine-König (15):
tg-export: implement skipping empty patches for quilt mode
tg export (collapse): implement skipping empty patches
tg export (quilt): Implement flattening patch paths
tg export (quilt): Implement numbering the patches
make tg remote idempotent
[TOPGIT] limit rev-list in branch_contains to a single rev
[TOPGIT] allow working with annihilated branches
[TOPGIT] make tg remote idempotent
[TOPGIT] make creating a commit from a topgit branch a function
[TOPGIT] implement linearize export method
Don't throw away already started base on resumed create.
Add documentation for tg export --linearize
Merge branch 'upstream' of git.debian.org:/git/collab-maint/topgit
Fix typo s/emmail/email/
bump version number to 0.7
martin f. krafft (14):
ignore tg-depend build files
remove +x bit from tg-depend
Make sure gitignore patterns are not recursive
add ignore patterns for quilt and debian build
Change tg help exit code to 0
Check for cmddir earlier
Print help output when no command is given
Require an argument to tg -r
Print help message when command is not proper
Note that do_help is used when short messages might be wanted
Add Vim modelines for consistent spacing
Check for git-send-email and die if not found
put tg version into a variable at the top
bump version number to 0.6
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [ANNOUNCE] TopGit 0.7
From: Uwe Kleine-König @ 2009-03-05 20:31 UTC (permalink / raw)
To: git
In-Reply-To: <20090305202709.GB15486@pengutronix.de>
Hello again,
something I forgot to mention in the previous mail: We installed a
channel #topgit on freenode's irc network.
If you're interested in TopGit, have questions, problems or suggestions,
join us there.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [ANNOUNCE] TopGit 0.7
From: Mark Wilden @ 2009-03-05 20:45 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20090305202709.GB15486@pengutronix.de>
On Thu, Mar 5, 2009 at 12:27 PM, Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> I'm happy to announce that TopGit 0.7 was released today.
>
> This release brings you several bug fixes and a few new features.
When announcing a release, you might consider including a few words
about what the project does. There will be people (like me) who were
not familiar with it before seeing the release announcement, and this
would help them to quickly find out whether it should be investigated.
Just a suggestion - ignore at will. :)
///ark
^ permalink raw reply
* Re: How to ignore a modified file?
From: Robin Rosenberg @ 2009-03-05 20:45 UTC (permalink / raw)
To: dealmaker; +Cc: git
In-Reply-To: <1236242659559-2428157.post@n2.nabble.com>
torsdag 05 mars 2009 09:44:19 skrev dealmaker <vinkhc@gmail.com>:
>
> Hi,
> I run "git status", and I saw the a modified file in a directory. I want
> to ignore all files in that directory. I put the directory name into
> .gitignore, but it still shows as modified file. Why? How do I ignore the
> directory?
> Thanks.
git update-index --assume-unchanged <files...>
-- robin
^ permalink raw reply
* bug in checkout/status ?
From: Shawn O. Pearce @ 2009-03-05 20:48 UTC (permalink / raw)
To: git
WTF. This shows up in git 1.6.0.2 through current 'next':
$ git clone git://android.git.kernel.org/platform/external/elfutils std_git
$ cd std_git/
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: libelf-po/ChangeLog
# modified: libelf-po/Makefile
# modified: libelf-po/Makefile.in
# modified: libelf-po/Makefile.in.in
# modified: libelf-po/Makevars
# modified: libelf-po/POTFILES
# modified: libelf-po/POTFILES.in
# modified: libelf-po/Rules-quot
# modified: libelf-po/boldquot.sed
# modified: libelf-po/insert-header.sin
# modified: libelf-po/libelf.pot
# modified: libelf-po/quot.sed
#
$ git diff-index HEAD
:000000 100644 0000000000000000000000000000000000000000 78eb2ff1b7e79d00e827c97a7d4f52ca7d129155 A libelf-po/ChangeLog
:000000 100644 0000000000000000000000000000000000000000 afd56475e1ae3a51ed30124a7671821581fbf833 A libelf-po/Makefile
:000000 100644 0000000000000000000000000000000000000000 21eb20d30794c6d9151c89a3b35c4365902221fc A libelf-po/Makefile.in
:000000 100644 0000000000000000000000000000000000000000 4a7a26885ff4ed63205538741a45950b10b8cf95 A libelf-po/Makefile.in.in
:000000 100644 0000000000000000000000000000000000000000 0accb70a14c5808668bdf7a21668767f0fa2e608 A libelf-po/Makevars
:000000 100644 0000000000000000000000000000000000000000 f17f924d6f5748e15c238d1006e568abb4c3240e A libelf-po/POTFILES
:000000 100644 0000000000000000000000000000000000000000 b25620fba0f1b74f351909d525a3e41101396260 A libelf-po/POTFILES.in
:000000 100644 0000000000000000000000000000000000000000 5f46d237d2593c674ab34518cf342553fe0f6aef A libelf-po/Rules-quot
:000000 100644 0000000000000000000000000000000000000000 4b937aa517bcff9f5adfc2a01d6d780445999297 A libelf-po/boldquot.sed
:000000 100644 0000000000000000000000000000000000000000 b26de01f6c88c7b15bb4815a8fcd5120d479300d A libelf-po/insert-header.sin
:000000 100644 0000000000000000000000000000000000000000 dfcd7704b3b16f040158b435acb9244a6d6cfa6a A libelf-po/libelf.pot
:000000 100644 0000000000000000000000000000000000000000 0122c46318dc8bc115167fa2c259f8456668f861 A libelf-po/quot.sed
:100644 000000 78eb2ff1b7e79d00e827c97a7d4f52ca7d129155 0000000000000000000000000000000000000000 D libelf-po/ChangeLog
:100644 000000 afd56475e1ae3a51ed30124a7671821581fbf833 0000000000000000000000000000000000000000 D libelf-po/Makefile
:100644 000000 21eb20d30794c6d9151c89a3b35c4365902221fc 0000000000000000000000000000000000000000 D libelf-po/Makefile.in
:100644 000000 4a7a26885ff4ed63205538741a45950b10b8cf95 0000000000000000000000000000000000000000 D libelf-po/Makefile.in.in
:100644 000000 0accb70a14c5808668bdf7a21668767f0fa2e608 0000000000000000000000000000000000000000 D libelf-po/Makevars
:100644 000000 f17f924d6f5748e15c238d1006e568abb4c3240e 0000000000000000000000000000000000000000 D libelf-po/POTFILES
:100644 000000 b25620fba0f1b74f351909d525a3e41101396260 0000000000000000000000000000000000000000 D libelf-po/POTFILES.in
:100644 000000 5f46d237d2593c674ab34518cf342553fe0f6aef 0000000000000000000000000000000000000000 D libelf-po/Rules-quot
:100644 000000 4b937aa517bcff9f5adfc2a01d6d780445999297 0000000000000000000000000000000000000000 D libelf-po/boldquot.sed
:100644 000000 b26de01f6c88c7b15bb4815a8fcd5120d479300d 0000000000000000000000000000000000000000 D libelf-po/insert-header.sin
:100644 000000 dfcd7704b3b16f040158b435acb9244a6d6cfa6a 0000000000000000000000000000000000000000 D libelf-po/libelf.pot
:100644 000000 0122c46318dc8bc115167fa2c259f8456668f861 0000000000000000000000000000000000000000 D libelf-po/quot.sed
WTF. Add -M and it sees modifies:
$ git diff-index -M HEAD
:100644 100644 78eb2ff1b7e79d00e827c97a7d4f52ca7d129155 78eb2ff1b7e79d00e827c97a7d4f52ca7d129155 M libelf-po/ChangeLog
:100644 100644 afd56475e1ae3a51ed30124a7671821581fbf833 afd56475e1ae3a51ed30124a7671821581fbf833 M libelf-po/Makefile
:100644 100644 21eb20d30794c6d9151c89a3b35c4365902221fc 21eb20d30794c6d9151c89a3b35c4365902221fc M libelf-po/Makefile.in
:100644 100644 4a7a26885ff4ed63205538741a45950b10b8cf95 4a7a26885ff4ed63205538741a45950b10b8cf95 M libelf-po/Makefile.in.in
:100644 100644 0accb70a14c5808668bdf7a21668767f0fa2e608 0accb70a14c5808668bdf7a21668767f0fa2e608 M libelf-po/Makevars
:100644 100644 f17f924d6f5748e15c238d1006e568abb4c3240e f17f924d6f5748e15c238d1006e568abb4c3240e M libelf-po/POTFILES
:100644 100644 b25620fba0f1b74f351909d525a3e41101396260 b25620fba0f1b74f351909d525a3e41101396260 M libelf-po/POTFILES.in
:100644 100644 5f46d237d2593c674ab34518cf342553fe0f6aef 5f46d237d2593c674ab34518cf342553fe0f6aef M libelf-po/Rules-quot
:100644 100644 4b937aa517bcff9f5adfc2a01d6d780445999297 4b937aa517bcff9f5adfc2a01d6d780445999297 M libelf-po/boldquot.sed
:100644 100644 b26de01f6c88c7b15bb4815a8fcd5120d479300d b26de01f6c88c7b15bb4815a8fcd5120d479300d M libelf-po/insert-header.sin
:100644 100644 dfcd7704b3b16f040158b435acb9244a6d6cfa6a dfcd7704b3b16f040158b435acb9244a6d6cfa6a M libelf-po/libelf.pot
:100644 100644 0122c46318dc8bc115167fa2c259f8456668f861 0122c46318dc8bc115167fa2c259f8456668f861 M libelf-po/quot.sed
I'm trying to debug it now, but I'd appreciate any help from
those that know more about this part of diffcore and the working
tree code..
--
Shawn.
^ permalink raw reply
* Re: bug in checkout/status ?
From: Jeff King @ 2009-03-05 20:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090305204801.GA16213@spearce.org>
On Thu, Mar 05, 2009 at 12:48:01PM -0800, Shawn O. Pearce wrote:
> WTF. This shows up in git 1.6.0.2 through current 'next':
>
> $ git clone git://android.git.kernel.org/platform/external/elfutils std_git
> $ cd std_git/
> $ git status
> # On branch master
>
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # modified: libelf-po/ChangeLog
> # modified: libelf-po/Makefile
> # modified: libelf-po/Makefile.in
> # modified: libelf-po/Makefile.in.in
> # modified: libelf-po/Makevars
> # modified: libelf-po/POTFILES
> # modified: libelf-po/POTFILES.in
> # modified: libelf-po/Rules-quot
> # modified: libelf-po/boldquot.sed
> # modified: libelf-po/insert-header.sin
> # modified: libelf-po/libelf.pot
> # modified: libelf-po/quot.sed
> #
Hmm. I get the same behavior here. I notice there is a "libelf" subtree
before "libelf-po"; maybe it's a sorting bug? I'll try to investigate
more.
-Peff
^ permalink raw reply
* Re: bug in checkout/status ?
From: Shawn O. Pearce @ 2009-03-05 20:53 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090305205126.GA19800@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Thu, Mar 05, 2009 at 12:48:01PM -0800, Shawn O. Pearce wrote:
>
> Hmm. I get the same behavior here. I notice there is a "libelf" subtree
> before "libelf-po"; maybe it's a sorting bug? I'll try to investigate
> more.
Yup, that must be it.
JGit created the resulting tree during a merge.
It sorted "libelf/" before "libelf-po/". Wrong. Bad JGit. Bad!
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] MinGW: 64-bit file offsets
From: Johannes Sixt @ 2009-03-05 20:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, Sickboy
In-Reply-To: <ae01b6dfcd430694dad008bbf201ee1490b071a1.1236268730u.git.johannes.schindelin@gmx.de>
On Donnerstag, 5. März 2009, Johannes Schindelin wrote:
> The type 'off_t' should be used everywhere so that the bit-depth of that
> type can be adjusted in the standard C library, and you just need to
> recompile your program to benefit from the extended precision.
>
> Only that it was not done that way in the MS runtime library.
>
> This patch reroutes off_t to off64_t and provides the other necessary
> changes so that finally, clones larger than 2 gigabyte work on Windows
> (provided you are on a file system that allows files larger than 2gb).
>
> Initial patch by Sickboy <sb@dev-heaven.net>.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Johannes Sixt <j6t@kdbg.org>
-- Hannes
^ permalink raw reply
* Re: More git bisect modes
From: Christian Couder @ 2009-03-05 20:53 UTC (permalink / raw)
To: John Tapsell; +Cc: Git Mailing List
In-Reply-To: <43d8ce650903050149u4ca98444w28efceb9084efa68@mail.gmail.com>
Le jeudi 5 mars 2009, John Tapsell a écrit :
> Hi,
>
> Although "git bisect" is called, well, bisect, it would be nice to
> have other modes.
>
> * A completely linear version - check every version. Particularly
> useful after rebasing to make sure all the commits still compile.
I will answer this one bellow along with the exponential back-off.
> * An allow-for-mistakes-bisect. This would use a bisection technique
> that would allow for a minimum of 1 mistake when marking a commit good
> or bad. This point isn't particularly to help those with fat fingers,
> but for bugs that are subtle and for bugs that are caused by multiple
> commits. (I can go into the details of how to do such a bisect
> later).
Yeah, Ingo Molnar also asked for something like this. But I think it is
quite complex. I hope it will be easier after the improvements I am
currently working on. I hope to send something early next week.
> * An exponential back-off. Typically I know that HEAD is broken, and
> I don't know when it used to work. It would be nice to exponentially
> go back through the commits to find the first working commit, then
> bisect from there.
I think your first idea above and this one could be implemented in a new
command called for example "git check".
It could be used it like this:
$ git check COMMAND $(git rev-list HEAD~10..)
that would check out each of the 10 last revisions and run COMMAND on each
one after check out, and at the end it could report about the exit code of
command for each of these revisions.
It could be used also with tags like that:
$ git check COMMAND $(git tag | tail -10)
After that a --bisect flag could be implemented. That would automatically
call "git bisect" to bisect if the exit code changed from "bad" to "good"
at one point.
Then if one adds a --expo flag to "git rev-list" that could be used for the
exponential back off you want.
> Before I start working on the code for any of these, do people like
> this? Would this fit into the 'git bisect' command?
I think it would be usefull, but I don't think the first and last one would
fit well into the "git bisect" command.
Best regards,
Christian.
^ permalink raw reply
* Re: More git bisect modes
From: Christian Couder @ 2009-03-05 20:59 UTC (permalink / raw)
To: John Tapsell; +Cc: Nanako Shiraishi, Git Mailing List
In-Reply-To: <43d8ce650903050217m2885692dkcef08ab2a5f60082@mail.gmail.com>
Le jeudi 5 mars 2009, John Tapsell a écrit :
> 2009/3/5 Nanako Shiraishi <nanako3@lavabit.com>:
> > Quoting John Tapsell <johnflux@gmail.com>:
> >> * An exponential back-off. Typically I know that HEAD is broken, and
> >> I don't know when it used to work.
> >
> > I thought 'git bisect' already worked with only bad commit(s) without
> > any good commit for a long time?
>
> I believe this makes it start from the very first commit. This
> probably much further back than most people would actually want to
> start from.
> (Also there seems to be a bug here, in that 'git bisect run' requires
> you to have both a good and a bad commit. Also the man page doesn't
> document this)
Yeah you are right. Do you want to try to fix this bug ?
Thanks in advance,
Christian.
^ permalink raw reply
* Re: orthogonal cases of log --date option
From: Jay Soffian @ 2009-03-05 21:04 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Miles Bader, git
In-Reply-To: <20090305104304.GA17760@coredump.intra.peff.net>
On Thu, Mar 5, 2009 at 5:43 AM, Jeff King <peff@peff.net> wrote:
>> But this patch may help you get started.
>
> FWIW, I think this is the wrong direction. You are working around the
> lack of orthogonality in the interface by tweaking things in the
> implementation. I think you are better to fix the interface, but support
> --date=local for historical reasons. IOW,
>
> git log --local-dates --date=short
>
> with
>
> git log --date=local
>
> as a historical synonym for
>
> git log --local-dates --date=default
>
> This makes the interface simpler to understand: --date remains a
> selector, and --date=local is a special case that new people don't need
> to think about or understand.
I started to pick this up and I want to clarify what you meant by
interface. Was it the CLI you had an issue with? Because that I
understand and it's easy to support the CLI changes you outline above.
Or did you have a problem with how Junio was going about passing along
both bits (i.e. 1. date format; 2. local or not) in an enum? Because I
have to tell you, I started looking at what it would take to switch
the enum to something like:
struct date_mode {
enum {
DATE_NORMAL = 0,
DATE_RELATIVE,
DATE_SHORT,
DATE_ISO8601,
DATE_RFC2822,
DATE_RAW
} format;
unsigned int local;
};
It's a significantly more invasive change.
j.
^ permalink raw reply
* Re: bug in checkout/status ?
From: Jeff King @ 2009-03-05 21:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090305205313.GB16213@spearce.org>
On Thu, Mar 05, 2009 at 12:53:13PM -0800, Shawn O. Pearce wrote:
> > Hmm. I get the same behavior here. I notice there is a "libelf" subtree
> > before "libelf-po"; maybe it's a sorting bug? I'll try to investigate
> > more.
>
> Yup, that must be it.
>
> JGit created the resulting tree during a merge.
>
> It sorted "libelf/" before "libelf-po/". Wrong. Bad JGit. Bad!
OK. I was just sort of guessing based on the similarity of the names and
the fact that sorting is confusing (as evidenced by the fact that I had
no idea if it was wrong or not). But that is definitely it:
$ git clone git://android.git.kernel.org/platform/external/elfutils std_git
$ cd std_git
$ git ls-tree HEAD >jgit
$ git commit -a -m 'git tree'
$ git ls-tree HEAD >git
$ diff -u jgit git
reveal(ed) the difference. But it looks like you have already re-pushed
a fixed version.
-Peff
^ permalink raw reply
* Re: orthogonal cases of log --date option
From: Jeff King @ 2009-03-05 21:11 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, Miles Bader, git
In-Reply-To: <76718490903051304j6d8138f7qa5492ac15edd6460@mail.gmail.com>
On Thu, Mar 05, 2009 at 04:04:44PM -0500, Jay Soffian wrote:
> > This makes the interface simpler to understand: --date remains a
> > selector, and --date=local is a special case that new people don't need
> > to think about or understand.
>
> I started to pick this up and I want to clarify what you meant by
> interface. Was it the CLI you had an issue with? Because that I
> understand and it's easy to support the CLI changes you outline above.
I meant the CLI.
> Or did you have a problem with how Junio was going about passing along
> both bits (i.e. 1. date format; 2. local or not) in an enum? Because I
> have to tell you, I started looking at what it would take to switch
> the enum to something like:
I find that a bit confusing, too, but at least it is not something users
see. So I don't feel as strongly about it.
> struct date_mode {
> enum {
> DATE_NORMAL = 0,
> DATE_RELATIVE,
> DATE_SHORT,
> DATE_ISO8601,
> DATE_RFC2822,
> DATE_RAW
> } format;
> unsigned int local;
> };
>
> It's a significantly more invasive change.
Yep, it is more invasive. But I consider it more maintainable in the
long run.
-Peff
^ permalink raw reply
* Re: bug in checkout/status ?
From: Shawn O. Pearce @ 2009-03-05 21:13 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090305210757.GA20157@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Thu, Mar 05, 2009 at 12:53:13PM -0800, Shawn O. Pearce wrote:
>
> OK. I was just sort of guessing based on the similarity of the names and
> the fact that sorting is confusing (as evidenced by the fact that I had
> no idea if it was wrong or not). But that is definitely it:
I never would have guessed the sorting was wrong. But once you
said something, it was immediately obvious to me that JGit f'd up
the tree.
> reveal(ed) the difference. But it looks like you have already re-pushed
> a fixed version.
Well, I rewound the repository. We're rebasing the change onto the
current tip and pushing a fast-forward instead of letting JGit make
a merge commit here.
But JGit still has a bug that causes it to corrupt the tree sorting
here. I have yet to understand why it produced that bad sort for
this particular merge, let alone propose a patch for it.
Thanks for the help Peff.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Documentation - More examples for git bisect
From: Christian Couder @ 2009-03-05 21:44 UTC (permalink / raw)
To: John Tapsell; +Cc: Git Mailing List
In-Reply-To: <1236256574-24764-1-git-send-email-johnflux@gmail.com>
Le jeudi 5 mars 2009, John Tapsell a écrit :
> Including passing parameters to the programs, and running more
> complicated checks without requiring a seperate shell script.
>
> Signed-off-by: John Tapsell
That looks good to me, except perhaps that your signed-off-by has no email
address, but I don't know if it's a problem or not.
Acked-by: Christian Couder <chriscool@tuxfamily.org>
Thanks,
Christian.
^ permalink raw reply
* [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Finn Arne Gangstad @ 2009-03-05 22:15 UTC (permalink / raw)
To: git; +Cc: John Tapsell, Andreas Ericsson
Previously, git push [remote] with no arguments would behave like
"git push <remote> :" if no push refspecs were configured for the remote.
It may be too easy for novice users to write "git push" or
"git push origin" by accident, so git will now push nothing, and give an
error message in such cases.
Teach git push a new option "--matching" that keeps the old behavior of
pushing all matching branches when none are configured.
Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
Documentation/git-push.txt | 10 ++++++++--
builtin-push.c | 32 +++++++++++++++++++++++---------
transport.h | 1 +
3 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 4e7e5a7..77a4792 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
SYNOPSIS
--------
[verse]
-'git push' [--all | --mirror | --tags] [--dry-run] [--receive-pack=<git-receive-pack>]
+'git push' [--all | --mirror | --matching | --tags] [--dry-run] [--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [-v | --verbose]
[<repository> <refspec>...]
@@ -63,10 +63,11 @@ the remote repository.
The special refspec `:` (or `{plus}:` to allow non-fast forward updates)
directs git to push "matching" branches: for every branch that exists on
the local side, the remote side is updated if a branch of the same name
-already exists on the remote side. This is the default operation mode
+already exists on the remote side. Nothing will be pushed
if no explicit refspec is found (that is neither on the command line
nor in any Push line of the corresponding remotes file---see below).
+
--all::
Instead of naming each ref to push, specifies that all
refs under `$GIT_DIR/refs/heads/` be pushed.
@@ -82,6 +83,11 @@ nor in any Push line of the corresponding remotes file---see below).
if the configuration option `remote.<remote>.mirror` is
set.
+--matching::
+ If no explicit refspecs are given, and no push refspecs are
+ configured for the remote, push all matching branches
+ (branches that exist in both ends) instead of nothing.
+
--dry-run::
Do everything except actually send the updates.
diff --git a/builtin-push.c b/builtin-push.c
index 122fdcf..ffc648d 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git push [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git push [--all | --mirror | --matching] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
@@ -48,6 +48,12 @@ static void set_refspecs(const char **refs, int nr)
}
}
+
+static int has_multiple_bits(unsigned int x)
+{
+ return (x & (x - 1)) != 0;
+}
+
static int do_push(const char *repo, int flags)
{
int i, errs;
@@ -71,17 +77,24 @@ static int do_push(const char *repo, int flags)
return error("--mirror can't be combined with refspecs");
}
- if ((flags & (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) ==
- (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) {
- return error("--all and --mirror are incompatible");
+ if (has_multiple_bits(flags & (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR | TRANSPORT_PUSH_MATCHING))) {
+ return error("--all, --mirror and --matching are incompatible");
}
- if (!refspec
- && !(flags & TRANSPORT_PUSH_ALL)
- && remote->push_refspec_nr) {
- refspec = remote->push_refspec;
- refspec_nr = remote->push_refspec_nr;
+ if ((flags & TRANSPORT_PUSH_MATCHING) && refspec) {
+ return error("--matching cannot be combined with refspecs");
}
+
+
+ if (!refspec && !(flags & TRANSPORT_PUSH_ALL)) {
+ if (remote->push_refspec_nr) {
+ refspec = remote->push_refspec;
+ refspec_nr = remote->push_refspec_nr;
+ } else if (!(flags & TRANSPORT_PUSH_MATCHING)) {
+ return error("No refspecs given and none configured for %s, nothing to push.", remote->name);
+ }
+ }
+
errs = 0;
for (i = 0; i < remote->url_nr; i++) {
struct transport *transport =
@@ -120,6 +133,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
+ OPT_BIT( 0, "matching", &flags, "push all matching refs", TRANSPORT_PUSH_MATCHING),
OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
OPT_BIT( 0 , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
OPT_BIT('f', "force", &flags, "force updates", TRANSPORT_PUSH_FORCE),
diff --git a/transport.h b/transport.h
index 6bbc1a8..fb98128 100644
--- a/transport.h
+++ b/transport.h
@@ -34,6 +34,7 @@ struct transport {
#define TRANSPORT_PUSH_DRY_RUN 4
#define TRANSPORT_PUSH_MIRROR 8
#define TRANSPORT_PUSH_VERBOSE 16
+#define TRANSPORT_PUSH_MATCHING 32
/* Returns a transport suitable for the url */
struct transport *transport_get(struct remote *, const char *);
--
1.6.2.12.g83676.dirty
^ permalink raw reply related
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Sverre Rabbelier @ 2009-03-05 22:18 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git, John Tapsell, Andreas Ericsson
In-Reply-To: <20090305221529.GA25871@pvv.org>
Heya,
On Thu, Mar 5, 2009 at 23:15, Finn Arne Gangstad <finnag@pvv.org> wrote:
> Previously, git push [remote] with no arguments would behave like
> "git push <remote> :" if no push refspecs were configured for the remote.
> It may be too easy for novice users to write "git push" or
> "git push origin" by accident, so git will now push nothing, and give an
> error message in such cases.
Config option please, I very much like the current behavior.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Markus Heidelberg @ 2009-03-05 22:22 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Finn Arne Gangstad, git, John Tapsell, Andreas Ericsson
In-Reply-To: <fabb9a1e0903051418k3fb6c8baqd0189c772893844e@mail.gmail.com>
Sverre Rabbelier, 05.03.2009:
> Heya,
>
> On Thu, Mar 5, 2009 at 23:15, Finn Arne Gangstad <finnag@pvv.org> wrote:
> > Previously, git push [remote] with no arguments would behave like
> > "git push <remote> :" if no push refspecs were configured for the remote.
> > It may be too easy for novice users to write "git push" or
> > "git push origin" by accident, so git will now push nothing, and give an
> > error message in such cases.
>
> Config option please, I very much like the current behavior.
git push --nothing ? :)
Markus
^ permalink raw reply
* Re: orthogonal cases of log --date option
From: Junio C Hamano @ 2009-03-05 22:21 UTC (permalink / raw)
To: Jeff King; +Cc: Jay Soffian, Miles Bader, git
In-Reply-To: <20090305211120.GB20157@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Yep, it is more invasive. But I consider it more maintainable in the
> long run.
Why do you think it is more confusing to ask "--date=local --date=iso"
than asking "--local-time --date=iso"? If the patch under discussion were
not mine, I would have said that --date=local that flips the "lie about
timezone" bit and tells us to use the "default" format is a brilliant and
elegant solution.
I honestly do not see the point of what you are proposing to make
"selector" and "format" independent; unless you are shooting for
"--use-tz=Indian/Christmas --date=iso", that is.
The "--use-tz=zonename" might make some sense. The required change would
look more like:
(1) Introduce:
const char *force_output_tz;
that defaults to NULL;
(2) Option parser for --use-tz=Indian/Christmas would store
arg+9 to force_output_tz;
(3) Option parser for --date=local would set the date format to
"default", and store "localtime" to force_output_tz. We discard
DATE_LOCAL enum.
(4) In show_date(), instead of
if (mode == DATE_LOCAL)
tz = local_tzoffset(time);
you'd do:
if (forced_output_tz)
tz = zonename_to_tzoffset(time, force_output_tz);
zonename_to_tzoffset() would look up the zoneinfo database and
compute the offset in our internal (hour*100+min) format.
But I do not think that is what you were proposing.
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Markus Heidelberg @ 2009-03-05 22:25 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Finn Arne Gangstad, git, John Tapsell, Andreas Ericsson
In-Reply-To: <200903052322.02098.markus.heidelberg@web.de>
Markus Heidelberg, 05.03.2009:
> Sverre Rabbelier, 05.03.2009:
> > Heya,
> >
> > On Thu, Mar 5, 2009 at 23:15, Finn Arne Gangstad <finnag@pvv.org> wrote:
> > > Previously, git push [remote] with no arguments would behave like
> > > "git push <remote> :" if no push refspecs were configured for the remote.
> > > It may be too easy for novice users to write "git push" or
> > > "git push origin" by accident, so git will now push nothing, and give an
> > > error message in such cases.
> >
> > Config option please, I very much like the current behavior.
>
> git push --nothing ? :)
Oh, I confused "config option" with "command line argument"...
Markus
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Sverre Rabbelier @ 2009-03-05 22:26 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Finn Arne Gangstad, git, John Tapsell, Andreas Ericsson
In-Reply-To: <200903052325.44648.markus.heidelberg@web.de>
Heya,
On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
<markus.heidelberg@web.de> wrote:
> Oh, I confused "config option" with "command line argument"...
Right, I'd like to be able to do:
$ git config push.iamnotretarded true
$ git push
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* git push bash completion
From: Sverre Rabbelier @ 2009-03-05 22:30 UTC (permalink / raw)
To: Git Mailing List
Heya,
Observe:
$ git push ori<tab>
git push origin
$ git push -f ori<tab>
git push -f origin/
Something weird going on there, or is this intentional and am I
missing something?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Junio C Hamano @ 2009-03-05 22:43 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git, John Tapsell, Andreas Ericsson
In-Reply-To: <20090305221529.GA25871@pvv.org>
If you want to pursue this, you at least need three patches, preferably
four:
(1) Add a configuration option the existing users can use to ask for
"with nothing else, please continue to default to matching refs".
Add a logic to tell "nothing is configured, hence we default to
matching refs" and "the user explicitly told us either via the
command line, or in the configuration file to use matching refs"
cases. Use the logic to issue a *warning* upon the former case that
tells the users the following, very loudly:
- "default to push matching" may be changed in a future version of
git to "default to push nothing";
- The user can squelch the warning by various ways:
- If you want to keep the "matching refs" behaviour, do $this...
- If you want to have $this behaviour, do $that...
- ...
Keep the default for the unconfigured case, after issuing the
warning, to the matching refs.
(2) Add a deprecation notice to Documentation/RelNotes-1.6.3.txt similar
to the way denyCurrentBranch was announced in 1.6.2 release notes (I
need to carry that part forward to the draft release notes to 1.6.3).
Mention that these two patches are proposed to be applied immediately.
(3) Flip the default for unconfigured case to "nothing". Update the
warning message you wrote in (1) to explain that:
- The default used to be "matching refs", but it now is "nothing".
This message is given loudly because a silent change of default
is dangerous to users.
- The user can squelch the warning by doing ... (I expect the
instructions will stay the same as in (1)).
Mention that this patch is proposed to be applied in the next major
update (perhaps 1.7.0).
(4) Remove the warning but keep the default to "nothing". Mention that
this is to be applied long after (3).
I won't comment on code quality other than hinting that you do not want to
reinvent has_multiple_bits().
^ permalink raw reply
* Re: [PATCH 1/2] Add an (optional, since expensive) test for >2g clones
From: Junio C Hamano @ 2009-03-05 23:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, Johannes Sixt
In-Reply-To: <96a26f3a883890b3e56c867e8183618784837d4d.1236268730u.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> +test_expect_success 'setup' '
> +
> + git config pack.compression 0 &&
> + git config pack.depth 0 &&
> + blobsize=$((20*1024*1024))
> + blobcount=$((2*1024*1024*1024/$blobsize+1))
> + i=1
What happened to the && chain?
^ 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