Archer git account inquiry

[Pierre Muller]

Hi all,

I have currently a very big patch that
solves several windows limitations:
- multi-inferior
- mutualization of some Ascii/Unicode variant
into a common/windows-hdep.[ch]
- start of support of 32-bit debugging within the 64-bit mingw64 debugger.
- support for non cygwin shells: msys shell /Windows COMSPEC variable
- translation of environment variables for Cygwin

But the total is a really big patch that I cannot
expect to get accepted as a whole,
thus I was wondering if I could get a account
with write access on the archer git to be able to more easily
separate out this huge patch into smaller
bits.

Do you know who I should
ask for this account?
I still don't really know git, but
I will try to read GitSvnCrashCourse
to get a first impression.

Pierre Muller
GDB pascal language maintainer

[Joel Brobecker]

thus I was wondering if I could get a account with write access on
the archer git to be able to more easily separate out this huge patch
into smaller bits.

Independently of this, you may want to investigate the possibility
of publishing your branch using your own git repository. Publishing
means that you need to put it somewhere accessible, so it might not
be possible for you, but it might also be a useful option, either
now or later.

That being said, this is something I remember us talking about
at the GCC Summit - opening the git mirror up for development
branches, rather than using the Archer repository. I don't think
anyone had any problems with that idea back then.

One of the issues (not sure) with using Archer, might be the frequency
at which the "master" branch is updated in the Archer repo. With the
official git mirror, it's updated every 30mins.

I still don't really know git, but I will try to read
GitSvnCrashCourse to get a first impression.

To me, the best book has been "Pro Git". You can even read it online,
but I bought a copy, because the author deserved a little something
back for his contribution.

[Tom Tromey]

Joel> That being said, this is something I remember us talking about
Joel> at the GCC Summit - opening the git mirror up for development
Joel> branches, rather than using the Archer repository. I don't think
Joel> anyone had any problems with that idea back then.

It would be fine with me as long as writing to gdb.git does not mess
with the automatic cvs importer, or somehow interfere with our ability
to move to git in the future.

I don't really know anything about how the cvs->git import works, so
maybe this is a needless concern.

Joel> One of the issues (not sure) with using Archer, might be the frequency
Joel> at which the "master" branch is updated in the Archer repo. With the
Joel> official git mirror, it's updated every 30mins.

We don't update automatically at all.

We used to have this idea of having an archer integration branch, but we
pretty much gave up on it. We didn't need it.

What I do now is clone from both archer and gdb.git. I generally make
new feature branches based on gdb/master, but then push them to archer.

We should probably update our wiki instructions to remove the old gunk.
And, I've been thinking of finally taking Jan's advice from 2 years ago
and deleting some of the dead branches.

Tom

[Joel Brobecker]

Post by Tom Tromey
It would be fine with me as long as writing to gdb.git does not mess
with the automatic cvs importer, or somehow interfere with our ability
to move to git in the future.
I don't really know anything about how the cvs->git import works, so
maybe this is a needless concern.

I will ask Jim.

[Joel Brobecker]

Post by Joel Brobecker

Post by Tom Tromey
It would be fine with me as long as writing to gdb.git does not mess
with the automatic cvs importer, or somehow interfere with our ability
to move to git in the future.
I don't really know anything about how the cvs->git import works, so
maybe this is a needless concern.

I will ask Jim.

Jim confirmed that, as long as we don't write to the "master" branch,
everything should be fine. I think it would be fairly straightforward
to install a hook that prevents updates to that branch except for one
user.

So we have 3 alternatives. Pierre publishes his own gdb.git repo (could
be using some of the git hosting sites???), uses Archer, or uses gdb.git.

[Pierre Muller]

I don't really care about where I put my modifications,
if nobody is against it, archer repository is fine with me.

Related question: should I change the wiki page
to add my branch? Do I need to logon somewhere for this?

Coming back to the primary reason of my request for git account:
I am mainly interested in an easier way to split
larges patches into several sub-patches like many of you
are doing.

So my main question is:
what do you use to create your email series with sub-patches?
-- git alone?
or stgit, guilt or Quilt?

How do you handle ChangeLog entries for instance?
do you really put them into the commits, but then
they would appear formatted as a diff in the patch also
or do you have special scripts for this?

Thanks in advance,

Pierre

-----Message d'origine-----
Joel Brobecker
Envoyé : mercredi 23 février 2011 04:30
À : Tom Tromey
Objet : Re: [Archer] Re: [Archer] Archer git account inquiry

Post by Joel Brobecker

Post by Tom Tromey
It would be fine with me as long as writing to gdb.git does not

mess

Post by Joel Brobecker

Post by Tom Tromey
with the automatic cvs importer, or somehow interfere with our

ability

Post by Joel Brobecker

Post by Tom Tromey
to move to git in the future.
I don't really know anything about how the cvs->git import works,

so

Post by Joel Brobecker

Post by Tom Tromey
maybe this is a needless concern.

I will ask Jim.

Jim confirmed that, as long as we don't write to the "master" branch,
everything should be fine. I think it would be fairly straightforward
to install a hook that prevents updates to that branch except for one
user.
So we have 3 alternatives. Pierre publishes his own gdb.git repo (could
be using some of the git hosting sites???), uses Archer, or uses gdb.git.
--
Joel

[Joel Brobecker]

So my main question is: what do you use to create your email series
with sub-patches? -- git alone? or stgit, guilt or Quilt?

I use git alone (in particular "git rebase -i").

How do you handle ChangeLog entries for instance?
do you really put them into the commits, but then
they would appear formatted as a diff in the patch also
or do you have special scripts for this?

I write the CL entry in the revision history only until the time when
I push the change to CVS. That's when I edit the commit again (using
"git rebase -i"), adding the ChangeLog entries. I do it at the very
last second, because otherwise you have a higher chance of having
a conflict when you export to CVS.

Note also a super-useful command: git cvsexportcommit. It automates
the pushing of a given patch to CVS.

[Tom Tromey]

Pierre> I don't really care about where I put my modifications,
Pierre> if nobody is against it, archer repository is fine with me.

It is perfectly ok.

Pierre> Related question: should I change the wiki page
Pierre> to add my branch? Do I need to logon somewhere for this?

Yes, please document new branches on the wiki.
You need an account on the wiki, you can make one there somehow.

Pierre> Coming back to the primary reason of my request for git account:
Pierre> I am mainly interested in an easier way to split
Pierre> larges patches into several sub-patches like many of you
Pierre> are doing.

Pierre> So my main question is:
Pierre> what do you use to create your email series with sub-patches?
Pierre> -- git alone?
Pierre> or stgit, guilt or Quilt?

I write my patches willy-nilly, in the craziest style imaginable.

This is usually what I push to the public repository as well.

For submissions, I make a new private branch and extract bits from the
development branch in various ways -- sometimes cherry-picking,
sometimes patches -- and use git rebase to make a patch series. For
this, the "Perfect Patch Series" instructions in the git manual are
ideal, I just follow them exactly.

After this, if I need to rework the patches, I just do it on my local
branch, this time rebasing, etc, to keep the patches clean.

Pierre> How do you handle ChangeLog entries for instance?
Pierre> do you really put them into the commits, but then
Pierre> they would appear formatted as a diff in the patch also
Pierre> or do you have special scripts for this?

Usually I ignore them until the point of patch submission, because they
are such a pain to deal with.

On occasion I have written my ChangeLog entries during the rebase
process, then just used them as the commit messages in git. Then if I
need to rework the patch series, I also update the commit messages as I
go.

I don't usually modify my branch ChangeLog files since it is just a
pain. It makes random conflicts if I rebase (there are some tools to
help with this, but I haven't bothered yet), and on the development
branch I often rework things, so just accumulating the ChangeLog entries
would yield the wrong result for the upstream submission anyhow.

Tom

[Tom Tromey]

Joel> Jim confirmed that, as long as we don't write to the "master" branch,
Joel> everything should be fine. I think it would be fairly straightforward
Joel> to install a hook that prevents updates to that branch except for one
Joel> user.

Joel> So we have 3 alternatives. Pierre publishes his own gdb.git repo (could
Joel> be using some of the git hosting sites???), uses Archer, or uses gdb.git.

I think it would be great to open gdb.git this way.

At the very least this should probably be discussed on the gdb list
first.

Also, I think we've benefited in Archer from documenting all the
branches as we make them. So, there should probably be some things like
this for gdb.git as well.

Tom

[Joel Brobecker]

Post by Tom Tromey
Also, I think we've benefited in Archer from documenting all the
branches as we make them. So, there should probably be some things like
this for gdb.git as well.

Agreed!

[Jan Kratochvil]

Related question: should I change the wiki page to add my branch?

When you make a Wiki change:
http://sourceware.org/gdb/wiki/ArcherBranchManagement?action=diff&rev1=117&rev2=118

please provide a commit comment. Other people (usually...) do so:
http://sourceware.org/gdb/wiki/ArcherBranchManagement?action=info

And as you probably used the GUI editor the whole text got reformatted and the
change is not visible there. In such case please do a first commit just for
the reformatting and then add the real change.

Please undo the merged reformat + change commit 118 before its split.
(At least I assume it has been also changed besides the reformatting.)


Thanks,
Jan

[Pierre Muller]

Post by Jan Kratochvil

Related question: should I change the wiki page to add my branch?

http://sourceware.org/gdb/wiki/ArcherBranchManagement?action=diff
&rev1=117&rev2=118

Whow, that was fast, I didn't even have time to send my email that you
already found out
I changed the Wiki page :) and made mistakes :( ...

Post by Jan Kratochvil
http://sourceware.org/gdb/wiki/ArcherBranchManagement?action=info

Can I edit this directly to add the comment?

Post by Jan Kratochvil
And as you probably used the GUI editor the whole text got reformatted and the
change is not visible there. In such case please do a first commit just for
the reformatting and then add the real change.

No I used the Text mode editor,

Post by Jan Kratochvil
Please undo the merged reformat + change commit 118 before its split.
(At least I assume it has been also changed besides the reformatting.)

As I said in my previous email, I added a line to the branch list
for my new branch indeed, but I must confess that I don't know
what you mean by undoing the reformat, sorry :(

Pierre

[Pierre Muller]

Post by Jan Kratochvil

Post by Jan Kratochvil
And as you probably used the GUI editor the whole text got

reformatted
and the

Post by Jan Kratochvil
change is not visible there. In such case please do a first commit

just
for

Post by Jan Kratochvil
the reformatting and then add the real change.

No I used the Text mode editor,

Post by Jan Kratochvil
Please undo the merged reformat + change commit 118 before its split.
(At least I assume it has been also changed besides the

reformatting.)
As I said in my previous email, I added a line to the branch list
for my new branch indeed, but I must confess that I don't know
what you mean by undoing the reformat, sorry :(

I hope I fixed it correctly:

http://sourceware.org/gdb/wiki/ArcherBranchManagement?action=diff&rev2=120&r
ev1=117

I started by trying to use the graphic mode, but as
I didn't find any way to add a line to the table, I switch to
text mode, so I supposed that the Graphics mode would have been
canceled.. I only try to change the size of the table by stretching the
lower right
corner... This is probably what triggered the unwanted reformatting of
the text.

Sorry about this.

Pierre

[Tom Tromey]

Pierre> Do you know who I should
Pierre> ask for this account?

This is the right place to ask.
I will set you up and send you a note off-list.

Pierre> I still don't really know git, but
Pierre> I will try to read GitSvnCrashCourse
Pierre> to get a first impression.

We also ask that you follow some basic rules here:

http://sourceware.org/gdb/wiki/ArcherBranchManagement

Mostly this means naming your branches nicely, documenting them on the
wiki, and not messing with other people's branches without permission.

Tom

[Pierre Muller]

Hi everyone,

I just edited
http://sourceware.org/gdb/wiki/ArcherBranchManagement#Existing_Branches
to add my new branch, which contains a
unique commit containing all the changes I currently have
about Windows OS improvements.

Could someone please try to checkout
the archer-muller-windows-multi branch
just to be sure that I did the things correctly...
Using this beanch, you should be able:
1) To debug multiple inferiors with Windows (Cygwin or mingw)
You need to enable it by using
(gdb) set children on
probably not the best name possible.

2) To compile GDB using Ascii or Unicode versions of the Windows API
Define macro USE_WIDE_WINAPI to force use of wide version,
USE_ASCII_WINAPI to force ascii version
New Cygwin vers 1.7.X defaults to Wide
older version only works with Ascii (which is then of course the default)
Mingw 32 and 64-bit should compilable both for Ascii and Wide API.
(Not regularly checked ...)

3) Debug a win32 executable using the 64-bit mingw64 GDB debugger...
Still experimental ...
4) Use msys or COMSPEC shells
instead of only Cygwin shell support in GDB HEAD.
Use of shell with multiple inferior is still not really
stable, sometimes the created executable count gets corrupted,
leading to errors, or the temporary breakpoint
on 'start' command does get set to the correct inferior timely,
which results in executable not stopping correctly a main.
This happens for instance when I try
(gdb) r `echo 8`
because more than one shell is created...

I will have to try out the
git rebase commands now...

Thanks for the account!

Pierre

[Jan Kratochvil]

Post by Pierre Muller

Post by Jan Kratochvil
http://sourceware.org/gdb/wiki/ArcherBranchManagement?action=info

Can I edit this directly to add the comment?

I do not know / think so. I do not find it so strict, it is just a Wiki, just
the big (formatting) change without any comment did not look right to me.

Post by Pierre Muller
http://sourceware.org/gdb/wiki/ArcherBranchManagement?action=diff&rev2=120&rev1=117

Yes, it seems correctly reverted + modified, thanks.

Post by Pierre Muller
Sorry about this.

np


Regards,
Jan