Re: git branch help?
Richard W.M. Jones rjo...@redhat.com writes: I didn't know git could do this, but it sounds useful for other (non-fedpkg) things. Can you explain how, or where to start looking? Look for git-new-workdir, it is in the contrib directory of the git sources. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Sat, Aug 07, 2010 at 04:49:50PM +0100, Richard W.M. Jones wrote: On Tue, Aug 03, 2010 at 12:39:02AM -0700, Matt McCutchen wrote: On Tue, 2010-08-03 at 09:12 +0200, Kevin Kofler wrote: But I guess git will be storing a lot of redundant stuff and forcing extra pulls if you work that way. :-( It looks like the current implementation of fedpkg clone -B creates independent repositories that don't share anything except the initially downloaded pack. Changing to multiple working directories hanging off a single repository would solve the problems you mentioned. Someone could file a RFE. I didn't know git could do this, but it sounds useful for other (non-fedpkg) things. Can you explain how, or where to start looking? man git clone, option --shared ? Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On 08/02/2010 06:06 PM, Kevin Kofler wrote: Jesse Keating wrote: Here is where you should have done a fedpkg or git push [snip] There is nothing to commit, since all the changes are already committed. The joys of DVCSes. People are NOT used to commit and push being different operations. Git is highly confusing to people who aren't git experts. Somebody has changed master since you last touched it, and you had changes on your local master that are out of sync now. First, you should do: git config --add --global push.default tracking This will make git push only attempt to push to the branch you are tracking. Then you can git push your f13 changes. git checkout master to get back to master and do a git pull --rebase to pull in the latest upstream changes and re-play your unpushed changes on top of it. Then git log to see what has happened, push if necessary. Huh? Can it get any more complicated? Ingoring the tone, I had some of the same thoughts. This is a pretty basic operation, in good old broken CVS it was a single command, there must be an easier way to make git do this, or at least as a script in fedpkg that does this operation. I'm not for going back, the list of basic operations that CVS supported were finite, I would be highly surprised if git couldn't support those operations. We just need the bits to get the non-git fedora users over the hump. bob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, Aug 03, 2010 at 12:39:02AM -0700, Matt McCutchen wrote: On Tue, 2010-08-03 at 09:12 +0200, Kevin Kofler wrote: But I guess git will be storing a lot of redundant stuff and forcing extra pulls if you work that way. :-( It looks like the current implementation of fedpkg clone -B creates independent repositories that don't share anything except the initially downloaded pack. Changing to multiple working directories hanging off a single repository would solve the problems you mentioned. Someone could file a RFE. I didn't know git could do this, but it sounds useful for other (non-fedpkg) things. Can you explain how, or where to start looking? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2010 12:39 AM, Matt McCutchen wrote: On Tue, 2010-08-03 at 09:12 +0200, Kevin Kofler wrote: But I guess git will be storing a lot of redundant stuff and forcing extra pulls if you work that way. :-( It looks like the current implementation of fedpkg clone -B creates independent repositories that don't share anything except the initially downloaded pack. Changing to multiple working directories hanging off a single repository would solve the problems you mentioned. Someone could file a RFE. An RFE with patches would be better. Admittedly I didn't spend a lot of time on -B as I don't necessarily like there being two official ways of working with your git repos. It makes documentation and helping people harder. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxbo8cACgkQ4v2HLvE71NXiyQCgrtYa9FJZWtomFoa4HNQJG/8g jYEAnjkMTSamKGYmJQQCBUjfClHGObD3 =4O8w -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On 08/03/2010 11:49 PM, Ben Boeckel wrote:
Björn Perssonbj...@xn--rombobjrn-67a.se wrote:
Adam Williamson wrote:
Would it be nice to stick this customization into fedora-packager, or
would it just confuse/surprise people?
Is it fast enough to not delay the prompt noticeably even on old computers?
I use zsh's vcs_info and the only one I've found (out of git, hg, darcs,
svn, and cvs) that doesn't feel like a no-op is bzr support.
What's the worst thing that could happen if it were to break? If Git were to
enter an infinite loop for example, would it render my shell useless?
Yes, it would. The shell will wait until the process gets back (hence my
non-support of bzr in my zsh config).
That's somewhat misleading - the user can use ctrl-c to interrupt it and
get a shell immediately.
Björn Persson
--Ben
If you want this, you might be better off using a function like:
showgittree() {
tree=$(git symbolic-ref HEAD 2/dev/null)
echo ${tree:11}
}
But I agree - please don't make this the default.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 16:23 -0400, Matthew Miller wrote: On Tue, Aug 03, 2010 at 01:17:26PM -0700, Adam Williamson wrote: Would it be nice to stick this customization into fedora-packager, or would it just confuse/surprise people? If it's there as something that's easily enabled with an include, yes. But I think changing people's prompts globally isn't a good idea. Plus this fires up git, grep, and python every time you hit enter at the command line. That seems... not the best. Point. Is there a more efficient way to do it? Seems like you could drop the python. There seem to be some alternate proposals in the comments. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Wed, 2010-08-04 at 00:13 -0400, Todd Zullinger wrote: Adam Williamson wrote: http://blog.vagmim.com/2009/04/git-branch-on-command-prompt.html Would it be nice to stick this customization into fedora-packager, or would it just confuse/surprise people? Please no. In addition to being ugly to add directly to anyone's prompt, the method outlined above is not the best way to achieve this (as I mentioned elsewhere in this thread¹). It would be great if these half-baked blog entries on git in your prompt would all just go away. Hey look at this neat round thing I created. I'll call it the wheel! ;) I meant more the result than any particular implementation :). Indeed that's clearly a much better way of achieving the result. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 05:40 +0200, Kevin Kofler wrote: Neal Becker wrote: OK, got mercurial updated for devel, apparantly OK. Now try to update f13: [snip a bunch of git tribulations] It's quite telling that the git workflow is so arcane and exotic that even the maintainer of another DVCS cannot figure it out! This conclusion is way overstated. It looks to me that Neal was trying to get something done quickly based on previous experience with Fedora packaging tools and wasn't applying his full DVCS-fu, but he should speak for himself. Git just has to do everything in its own bizarre, confusing and broken way. :-( The only potentially confusing behavior was that git defaulted to pushing all branches. Given that, the push failed due to a concurrent change to a different branch on the destination, and it was necessary to switch to that branch in order to perform the merge (well, rebase, but the difference isn't important here). I see nothing arcane, exotic, bizarre, or broken about that. And I don't think I would change the default push behavior: I can envision forgetting to push a change to a non-current branch until someone complains about it. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: Broken in the past tense is inaccurate: no SHA-1 collision has been published yet. I would like to see DVCSes switch to a stronger hash algorithm sooner rather than later, but it's not enough of a concern that I would avoid using them. If it makes you feel any better, git will not allow a fetched object to replace a local one with the same hash, so you can only lose if you fetch from the attacker first. I'm not talking about intentional collisions, I'm talking about accidental collisions, which ALL hash algorithms are vulnerable to, no matter how strong. Hashes are inherently non-injective and mathematically CANNOT be otherwise. Now the probability of an accidental collision is very low, but it is not zero, so the algorithm is unreliable. And low probabilities add up the more projects use DVCSes. Sooner or later some project will be hit by a collision. And the shorter the hash, the more likely a collision (exponentially!), so the abbreviated hashes git uses are particularly collision-prone. For sequential commit numbering, try git describe. Nobody actually uses those numbers though (and in fact I doubt those numbers can be used in all the ways SVN revision IDs can be used). What everyone uses is hashes, leaving you to wonder whether deadbeef or c0cac01a is the newer revision (assuming that both are snapshots from master or at least from the same branch, which is usually the case when comparing 2 packaged snapshots). The problems with CVS were amply explained there, but it's less clear to me whether there were compelling reasons to choose git over (e.g.) SVN + git-svn or the people involved just happened to like distributed version control, as I do. Sure they do, but the problem is that they're FORCING their preference onto everyone, whereas using SVN would have allowed them to work their way (using SVK or git-svn) without breaking our workflow, and SVN has all the required features (e.g. atomic commits and thus repository-wide revision IDs). Sadly, more and more projects are getting infected by the git virus, KDE is also moving to git, several other upstream projects already did. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: The only potentially confusing behavior was that git defaulted to pushing all branches. Given that, the push failed due to a concurrent change to a different branch on the destination, and it was necessary to switch to that branch in order to perform the merge (well, rebase, but the difference isn't important here). I see nothing arcane, exotic, bizarre, or broken about that. And I don't think I would change the default push behavior: I can envision forgetting to push a change to a non-current branch until someone complains about it. The whole idea of having more than one branch in a checkout is confusing. I really don't see why I'd want to have a complete clone of the repository on my HDD rather than a working copy which contains all I actually work on (the current revision of one branch; if I work on multiple branches, that's what directories on my file system are for). (And this is another reason why I consider DVCSes to be broken by design.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, Aug 03, 2010 at 08:10:06AM +0200, Kevin Kofler wrote: For sequential commit numbering, try git describe. Nobody actually uses those numbers though statements with nobody or everybody can be easily disproven so you might want to reword or narrow down your definition of nobody. I've used git-describe quite a bit and it can be useful. (and in fact I doubt those numbers can be used in all the ways SVN revision IDs can be used). What everyone uses is hashes, leaving you to wonder whether deadbeef or c0cac01a is the newer revision (assuming that both are snapshots from master or at least from the same branch, which is usually the case when comparing 2 packaged snapshots). I think this may be the main issue here - there is no meaning of newer in git. Don't rely on it an you'll be fine. What matters is whether a change is in a repository or not. Which one is newer hardly ever matters. The problems with CVS were amply explained there, but it's less clear to me whether there were compelling reasons to choose git over (e.g.) SVN + git-svn or the people involved just happened to like distributed version control, as I do. Sure they do, but the problem is that they're FORCING their preference onto everyone, whereas using SVN would have allowed them to work their way (using SVK or git-svn) without breaking our workflow, and SVN has all the required features (e.g. atomic commits and thus repository-wide revision IDs). Sadly, more and more projects are getting infected by the git virus, KDE is also moving to git, several other upstream projects already did. :-( This sounds a bit like an everyone else is wrong argument which is usually quite hard to defend in public. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 08:10 +0200, Kevin Kofler wrote: I'm not talking about intentional collisions, I'm talking about accidental collisions, which ALL hash algorithms are vulnerable to, no matter how strong. Hashes are inherently non-injective and mathematically CANNOT be otherwise. Now the probability of an accidental collision is very low, but it is not zero, so the algorithm is unreliable. And low probabilities add up the more projects use DVCSes. Sooner or later some project will be hit by a collision. You might like this article: http://valerieaurora.org/review/hash.html I'm willing to accept the miniscule probability of a collision. If you aren't, I have some other windmills for you to tilt at. And the shorter the hash, the more likely a collision (exponentially!), so the abbreviated hashes git uses are particularly collision-prone. True; for that reason, I avoid using them for anything permanent. The problems with CVS were amply explained there, but it's less clear to me whether there were compelling reasons to choose git over (e.g.) SVN + git-svn or the people involved just happened to like distributed version control, as I do. Sure they do, but the problem is that they're FORCING their preference onto everyone That's not strictly true: you're welcome to write svn-git. But the point is taken, and that's why I invited clarification as to the reasons for choosing git. Sadly, more and more projects are getting infected by the git virus, KDE is also moving to git, several other upstream projects already did. :-( This is unsubstantiated flamebait. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 08:16 +0200, Kevin Kofler wrote: Matt McCutchen wrote: The only potentially confusing behavior was that git defaulted to pushing all branches. Given that, the push failed due to a concurrent change to a different branch on the destination, and it was necessary to switch to that branch in order to perform the merge (well, rebase, but the difference isn't important here). I see nothing arcane, exotic, bizarre, or broken about that. And I don't think I would change the default push behavior: I can envision forgetting to push a change to a non-current branch until someone complains about it. The whole idea of having more than one branch in a checkout is confusing. This may be a terminology issue. A personal repository may contain all the branches, but only one branch is checked out in a given working directory at any time. It would be the same if you had an entire SVN repository cached locally and could svn switch among the branches. Note that Neal only ran into trouble because he had an outgoing change in a non-checked-out branch. If you only ever have one branch checked out, you'll never get into that situation. I really don't see why I'd want to have a complete clone of the repository on my HDD rather than a working copy which contains all I actually work on (the current revision This is a valid point. git supports shallow clones, but I would like to see support for querying remote repositories. In the meantime, you may be able to use the gitweb (or similar) interface. of one branch; if I work on multiple branches, that's what directories on my file system are for). One can hang multiple working directories for different branches off the same git repository. I do it all the time. It's also possible to share only the object database without the branch namespace, but I find that the convenience of having all the branches readily accessible for queries is enormous. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Peter Hutterer wrote: I think this may be the main issue here - there is no meaning of newer in git. There is a partial order given by ancestry, and 2 revisions you want to compare WILL in general be ordered. (In fact, whenever it makes sense to numerically compare SVN revision IDs, the commits will also be ordered in a DVCS. Comparing revision IDs from different branches or even different repositories does not make sense in SVN either, but that's not what people are interested in anyway.) Don't rely on it an you'll be fine. What matters is whether a change is in a repository or not. Which one is newer hardly ever matters. Nonsense. If, say, Fedora ships foo-12345678 and Ubuntu ships foo-abcdef00, you'll want to know whether 12345678 or abcdef00 is the newer snapshot from the master of foo. (And if they're both snapshots from master, they WILL be ordered unless upstream rewrote their published history, which is just plain evil.) Or, another use case, if we have foo-3.14-0.17.12345678git.fc12 and foo-3.14-0.18.abcdef00git.fc13, how do you verify that the upgrade path is correct and does not in fact downgrade foo when upgrading to F13? The sequence number before (17 vs. 18) might have been incremented due to one or more plain rebuild(s), it doesn't necessarily reflect the sequence of upstream snapshots being packaged. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: That's not strictly true: you're welcome to write svn-git. But the point is taken, and that's why I invited clarification as to the reasons for choosing git. Bolting a distributed client onto a central server makes sense. A central client with a distributed server doesn't. Git doesn't (by design) support the required server-side operations. I'd have to set up an SVN gateway to the repository on some server. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: You might like this article: http://valerieaurora.org/review/hash.html That article makes my point pretty well. I'm willing to accept the miniscule probability of a collision. If you aren't, I have some other windmills for you to tilt at. I am not willing to silently accept anything with a nonzero probability of failure on perfect hardware. Any such algorithm is just incorrect. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Peter Hutterer wrote: this is imo superior to re-editing spec files, possibly forgetting to update sources/cvsignore in other branches (which has happened in the past). I know what the original commit did, so cherry-picking it to other branches will do the same. With the CVS workflow, I usually just copied the specfile, sources and .cvsignore from devel, no re-editing. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Oh, and I forgot: Peter Hutterer wrote: it's likely that one you get used to git you'll be using branches heavily. And once you start using several branches interchangably, directories don't cut it anymore compared to git. one example: updating to a new version of the wacom driver was a matter of fedpkg clone xorg-x11-drv-wacom update master branch fedpkg commit fedpkg push fedpkg build fedpkg switch-branch f14 git cherry-pick master fedpkg commit fedpkg push fedpkg build fedpkg switch-branch f13 git cherry-pick master fedpkg commit fedpkg push fedpkg build I don't see why I'd want to magically switch the branch of my directory to do this. This makes much more sense (assuming a fedpkg clone -B that actually works, I don't know whether they already fixed that, and I guess you need to do those extra git pull operations if you work that way due to git's ugly design): fedpkg clone -B xorg-x11-drv-wacom cd xorg-x11-drv-wacom/master update master branch fedpkg commit fedpkg push fedpkg build cd ../f14 git pull git cherry-pick master fedpkg commit fedpkg push fedpkg build cd ../f13 git pull git cherry-pick master fedpkg commit fedpkg push fedpkg build That way the contents of your directories always contain the same branch, so you don't end up accidentally committing to the wrong one. But I guess git will be storing a lot of redundant stuff and forcing extra pulls if you work that way. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, Aug 03, 2010 at 08:49:14AM +0200, Kevin Kofler wrote: Peter Hutterer wrote: I think this may be the main issue here - there is no meaning of newer in git. There is a partial order given by ancestry, and 2 revisions you want to compare WILL in general be ordered. there is an order provided one revision is an ancestor of the other revision. this is not always the case. (In fact, whenever it makes sense to numerically compare SVN revision IDs, the commits will also be ordered in a DVCS. Comparing revision IDs from different branches or even different repositories does not make sense in SVN either, but that's not what people are interested in anyway.) Don't rely on it an you'll be fine. What matters is whether a change is in a repository or not. Which one is newer hardly ever matters. Nonsense. If, say, Fedora ships foo-12345678 and Ubuntu ships foo-abcdef00, you'll want to know whether 12345678 or abcdef00 is the newer snapshot from the master of foo which one is newer: Fedora's packaged version of X server 1.8 + backports and distro-specific fixes or Ubuntu's packaged version of 1.8 + backports and distro-specific fixes? The concept of newer doesn't apply here because the branches diverge at the common ancestor (server 1.8). (And if they're both snapshots from master, they WILL be ordered unless upstream rewrote their published history, which is just plain evil.) if they're both snapshots from master without any distro-specific patches, git-describe will tell you exactly which one is newer. w...@barra:~/xorg/xserver git describe xorg-server-1.8.99.905-8-g09a0ad9 so I'm 8 commits past the 1.8.99.905 tag. But again, this is only a measurement for newer as long as one commit is a descendant of the other. Or, another use case, if we have foo-3.14-0.17.12345678git.fc12 and foo-3.14-0.18.abcdef00git.fc13, how do you verify that the upgrade path is correct and does not in fact downgrade foo when upgrading to F13? The sequence number before (17 vs. 18) might have been incremented due to one or more plain rebuild(s), it doesn't necessarily reflect the sequence of upstream snapshots being packaged. in the packages I co-maintain, we use the snapshot date as identifier, not the commit. so you get e.g. xorg-x11-drv-wacom-0.10.8-1.20100803.fc12 the exact git commit is also noted in the fedora repo. So the version number of the package only goes backwards if you freshly snapshot F12 but not F13. This is not the ideal solution, but it does the job, we only update every few days or weeks anyway (and even then mostly only in rawhide, not released versions). if you really want to get fancy, you can put the git-describe numbering in there which should never go backwards unless you rewrite history. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, Aug 03, 2010 at 09:03:47AM +0200, Kevin Kofler wrote: Peter Hutterer wrote: this is imo superior to re-editing spec files, possibly forgetting to update sources/cvsignore in other branches (which has happened in the past). I know what the original commit did, so cherry-picking it to other branches will do the same. With the CVS workflow, I usually just copied the specfile, sources and .cvsignore from devel, no re-editing. consider the use-case where the spec files aren't 100% identical because they have different changelog history, or build instructions, or any other reason a part of the spec file may be differnt to the ones being changed right now. by copying it over, you destroy that information. a hunk may still apply in this case though, reducing the amount of manual editing. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 09:02 +0200, Kevin Kofler wrote: Matt McCutchen wrote: You might like this article: http://valerieaurora.org/review/hash.html That article makes my point pretty well. I'm willing to accept the miniscule probability of a collision. If you aren't, I have some other windmills for you to tilt at. I am not willing to silently accept anything with a nonzero probability of failure on perfect hardware. Any such algorithm is just incorrect. If you want to talk about correctness of algorithms, there is a notion of negligible (less than inverse polynomial) probability of failure that can be used. In the real world, you are not doing yourself any measurable good by professing to go after this risk which is orders of magnitude smaller than all the others you face every day. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, Aug 03, 2010 at 09:12:48AM +0200, Kevin Kofler wrote: Oh, and I forgot: Peter Hutterer wrote: it's likely that one you get used to git you'll be using branches heavily. And once you start using several branches interchangably, directories don't cut it anymore compared to git. one example: updating to a new version of the wacom driver was a matter of fedpkg clone xorg-x11-drv-wacom update master branch fedpkg commit fedpkg push fedpkg build fedpkg switch-branch f14 git cherry-pick master fedpkg commit fedpkg push fedpkg build fedpkg switch-branch f13 git cherry-pick master fedpkg commit fedpkg push fedpkg build I don't see why I'd want to magically switch the branch of my directory to do this. This makes much more sense (assuming a fedpkg clone -B that actually works, I don't know whether they already fixed that, and I guess you need to do those extra git pull operations if you work that way due to git's ugly design): fedpkg clone -B xorg-x11-drv-wacom cd xorg-x11-drv-wacom/master update master branch fedpkg commit fedpkg push fedpkg build cd ../f14 git pull git cherry-pick master fedpkg commit fedpkg push fedpkg build cd ../f13 git pull git cherry-pick master fedpkg commit fedpkg push fedpkg build That way the contents of your directories always contain the same branch, so you don't end up accidentally committing to the wrong one. But I guess git will be storing a lot of redundant stuff and forcing extra pulls if you work that way. :-( correct, git will share objects between branches, so by storing in different directories you'll loose that advantage. I've got a shell prompt that shows me the branch name whenever I enter a git directory so I don't have to worry about committing to the wrong branch. other than that - your approach is as valid as the one I described above. which one you do depends on personal preference. And you can still to the spec-file copying as well. the end result is the same in all three cases. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 08:52 +0200, Kevin Kofler wrote: Matt McCutchen wrote: That's not strictly true: you're welcome to write svn-git. But the point is taken, and that's why I invited clarification as to the reasons for choosing git. Bolting a distributed client onto a central server makes sense. A central client with a distributed server doesn't. Git doesn't (by design) support the required server-side operations. I'd have to set up an SVN gateway to the repository on some server. And if you refuse to do that, then you are FORCING your preference onto Fedora. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Peter Hutterer wrote:
consider the use-case where the spec files aren't 100% identical because
they have different changelog history, or build instructions, or any other
reason a part of the spec file may be differnt to the ones being changed
right now. by copying it over, you destroy that information.
I always just lived with that. I'm rebuilding the Rawhide package as an
update for releases, so the changelog is the one which lead to the Rawhide
package, I don't care if the previous branch changelog gets trashed.
If there are functional differences between the releases (e.g.
BuildRequires), that's what 0%{?fedora} is for.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On 08/03/2010 12:53 PM, Peter Hutterer wrote: correct, git will share objects between branches, so by storing in different directories you'll loose that advantage. I've got a shell prompt that shows me the branch name whenever I enter a git directory so I don't have to worry about committing to the wrong branch. For those wondering how, http://blog.vagmim.com/2009/04/git-branch-on-command-prompt.html Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: If you want to talk about correctness of algorithms, there is a notion of negligible (less than inverse polynomial) probability of failure that can be used. In the real world, you are not doing yourself any measurable good by professing to go after this risk which is orders of magnitude smaller than all the others you face every day. I'm a mathematician, for me there's no such thing as a negligible failure probability. The probability of failure is either zero (i.e. the algorithm works) or not (i.e. the algorithm doesn't work). Using an algorithm which doesn't work is unacceptable. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 09:12 +0200, Kevin Kofler wrote: But I guess git will be storing a lot of redundant stuff and forcing extra pulls if you work that way. :-( It looks like the current implementation of fedpkg clone -B creates independent repositories that don't share anything except the initially downloaded pack. Changing to multiple working directories hanging off a single repository would solve the problems you mentioned. Someone could file a RFE. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 09:31 +0200, Kevin Kofler wrote: Matt McCutchen wrote: If you want to talk about correctness of algorithms, there is a notion of negligible (less than inverse polynomial) probability of failure that can be used. In the real world, you are not doing yourself any measurable good by professing to go after this risk which is orders of magnitude smaller than all the others you face every day. I'm a mathematician, for me there's no such thing as a negligible failure probability. The probability of failure is either zero (i.e. the algorithm works) or not (i.e. the algorithm doesn't work). Using an algorithm which doesn't work is unacceptable. OK, then don't. But let the rest of us get on with our work based on real-world risks and benefits. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tuesday, August 03, 2010 09:26:37 am Rahul Sundaram wrote: On 08/03/2010 12:53 PM, Peter Hutterer wrote: correct, git will share objects between branches, so by storing in different directories you'll loose that advantage. I've got a shell prompt that shows me the branch name whenever I enter a git directory so I don't have to worry about committing to the wrong branch. For those wondering how, http://blog.vagmim.com/2009/04/git-branch-on-command-prompt.html Thanks Rahul! It's really 1000% usability enhancement! Jaroslav Rahul -- Jaroslav Řezník jrez...@redhat.com Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, Aug 03, 2010 at 08:10:06AM +0200, Kevin Kofler wrote: Sadly, more and more projects are getting infected by the git virus, KDE is also moving to git, several other upstream projects already did. :-( Documentation/ManagementStyle: While it turns out that most people are idiots, the corollary to that is sadly that you are one too, and that while we can all bask in the secure knowledge that we're better than the average person (let's face it, nobody ever believes that they're average or below-average), we should also admit that we're not the sharpest knife around, and there will be other people that are less of an idiot that you are. -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, Aug 03, 2010 at 12:56:37PM +0530, Rahul Sundaram wrote: On 08/03/2010 12:53 PM, Peter Hutterer wrote: correct, git will share objects between branches, so by storing in different directories you'll loose that advantage. I've got a shell prompt that shows me the branch name whenever I enter a git directory so I don't have to worry about committing to the wrong branch. For those wondering how, http://blog.vagmim.com/2009/04/git-branch-on-command-prompt.html This is pretty primitive implementation (do you really want to call python from $PS1? ;-) The git package contains the /etc/bash_completion.d/git file where is defined function __git_ps1() which provides more usable strings (it's able to detect if you are rebasing, bisecting, merging, ...) and allows to use formatting for the string: $ echo $(__git_ps1 git PS1 is: %s) git PS1 is: master For example I use PS1='\h:\w\[\033[0;32m\]\$\[\033[0m\] ' PROMPT_COMMAND='printf %*s\r $(($COLUMNS + 11)) ^[[33m$(__git_ps1 :%s)^[(B^[[m' so I have hostname:dirname$ on left side and :branch on right (the branch name is yellow and '$' at the end of dirname is green:-) Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 11:44 +0200, Karel Zak wrote: The git package contains the /etc/bash_completion.d/git file where is defined function __git_ps1() which provides more usable strings (it's able to detect if you are rebasing, bisecting, merging, ...) and allows to use formatting for the string: This does not work out of the box though. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 05:40 +0200, Kevin Kofler wrote: Neal Becker wrote: OK, got mercurial updated for devel, apparantly OK. Now try to update f13: [snip a bunch of git tribulations] It's quite telling that the git workflow is so arcane and exotic that even the maintainer of another DVCS cannot figure it out! Git just has to do everything in its own bizarre, confusing and broken way. :-( I'm sorry that I'm getting emotional here, but this is getting too much for me. Kevin, this is totally off topic here. Furthermore, git is not bizarre, it's not confusing and it's not broken. I'm no VCS guru and I'm still able to work with it without issues and, I have to say, I learnt it faster than CVS (plus from the various VCS I had interaction with, which is CVS, SVN, mercurial and git this one feels best to me, by design). If you spent some of the time you have spent on bashing git on actually learning to use git you'd be much better off. If git was as that bad as you try to imply, I highly doubt gnome, kde and others would switch to it so happily. If you want to flame about git, please do it elsewhere. Thanks, Martin PS: repeating a lie thousand times does not make it true signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
1. I just want to update mercurial in whatever way is easiest. I don't know git. I was trying to follow the documented procedure, but I guess it's a bit early and docs are sketchy. 2. What I used to do with cvs is a) update devel b) clone this to stable releases. The devel and stable were always identical (I think). I found it annoying that with cvs I had to keep updating 3 separate things, even though they were identical, but I had learned how to do it. I hoped that git + branches would make it easier to do this. Just 1 update and then merge? 3. While it is ironic that I'm struggling with updating mercurial using git, the fact that I maintain mercurial for fedora does not make me any expert in git or even mercurial. I wish I had time to learn more, but I don't. 4. I did rm -rf and then a clean fedpkg clone. Then fedpkg switch-branch f13. Then fedpkg push. Now fedpkg build. Seems to be working so far -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Am Tue, 3 Aug 2010 11:44:02 +0200
schrieb Karel Zak k...@redhat.com:
On Tue, Aug 03, 2010 at 12:56:37PM +0530, Rahul Sundaram wrote:
On 08/03/2010 12:53 PM, Peter Hutterer wrote:
correct, git will share objects between branches, so by storing
in different directories you'll loose that advantage.
I've got a shell prompt that shows me the branch name whenever I
enter a git directory so I don't have to worry about committing
to the wrong branch.
For those wondering how,
http://blog.vagmim.com/2009/04/git-branch-on-command-prompt.html
This is pretty primitive implementation (do you really want to call
python from $PS1? ;-)
The git package contains the /etc/bash_completion.d/git file where
is defined function __git_ps1() which provides more usable strings
(it's able to detect if you are rebasing, bisecting, merging, ...) and
allows to use formatting for the string:
$ echo $(__git_ps1 git PS1 is: %s)
git PS1 is: master
Don't know why, but recently, that shows me master in any folder,
even when there is no git repository, so I switched my PS1 to something
similar from above:
function bash_git_branch
{
git branch 2 /dev/null | grep \* | awk '{print $2}'
}
export PS1='\[\033[01;32m\...@\h\[\033[01;34m\] \w\[\033[31m\]
$(bash_git_branch)\[\033[01;34m\]\$\[\033[00m\] '
So no need to call python, if awk is enought :)
Host and username are green, directory blue and branch red now.
Thomas
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, Aug 3, 2010 at 2:16 PM, Thomas Spura toms...@fedoraproject.org wrote:
function bash_git_branch
{
git branch 2 /dev/null | grep \* | awk '{print $2}'
}
export PS1='\[\033[01;32m\...@\h\[\033[01;34m\] \w\[\033[31m\]
$(bash_git_branch)\[\033[01;34m\]\$\[\033[00m\] '
So no need to call python, if awk is enought :)
No need to call grep either - awk is enough
git branch 2/dev/null | awk '/^\*/{print $2}'
--
Iain.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: I am not willing to silently accept anything with a nonzero probability of failure on perfect hardware. Any such algorithm is just incorrect. Still using Token Ring because that evil random Ethernet could fail? How do you verify RPMs (or any other signed data for that matter)? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Karel Zak wrote: On Tue, Aug 03, 2010 at 12:56:37PM +0530, Rahul Sundaram wrote: On 08/03/2010 12:53 PM, Peter Hutterer wrote: correct, git will share objects between branches, so by storing in different directories you'll loose that advantage. I've got a shell prompt that shows me the branch name whenever I enter a git directory so I don't have to worry about committing to the wrong branch. For those wondering how, http://blog.vagmim.com/2009/04/git-branch-on-command-prompt.html This is pretty primitive implementation (do you really want to call python from $PS1? ;-) This looks like a new version of the wheel many ruby folks re-invented when they started moving to git. Sadly, these poor substitutes for __git_ps1() are often pushed. The wiki has some info on configuring __git_ps1() here: https://fedoraproject.org/wiki/Git_Quickref#Display_current_branch_in_bash (This is linked from https://fedoraproject.org/wiki/Using_Fedora_GIT as well.) In addition to displaying the current branch, __git_ps1() will show you when you're in the middle of a merge or rebase operation. It can optionally show you when you have modified, staged, and/or untracked files in your work tree. These are things that the poor-man's alternatives don't generally do at all. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ There are no differences but differences of degree between different degrees of difference and no difference. -- William James, under nitrous oxide; 1882 pgpwCSSP95elx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Hi. On Tue, 03 Aug 2010 17:40:35 +0200, Kevin Kofler wrote No (we're basically all being forced to use Ethernet, it's everywhere), but Ethernet's design makes me feel extremely uncomfortable. Give it enough load and it WILL break down under the collisions. And yet it magically works to a degree considered acceptable by a huge majority of the people who use it (knowingly or unknowingly). Ethernet is certainly not the best we can do, network wise, but it is good enough, and thus the arch enemy of perfect. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 06:41 +0200, Kevin Kofler wrote: All this dist-git migration has brought us is chaos, a much higher barrier to entry and much harder work for existing packagers. (And yes, I've also I disagree. I'm not an expert on cvs or git. Being not an expert, to update packages, I simply follow the helpful Wiki instructions for monkeys. As long as these are accurate and don't require independent thought, it makes little difference which is which to an idiot monkey like me. The instructions for both CVS and git cover the typical operations an idiot package maintaining monkey needs to do, and hence everything is fine. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 12:56 +0530, Rahul Sundaram wrote: On 08/03/2010 12:53 PM, Peter Hutterer wrote: correct, git will share objects between branches, so by storing in different directories you'll loose that advantage. I've got a shell prompt that shows me the branch name whenever I enter a git directory so I don't have to worry about committing to the wrong branch. For those wondering how, http://blog.vagmim.com/2009/04/git-branch-on-command-prompt.html Would it be nice to stick this customization into fedora-packager, or would it just confuse/surprise people? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, Aug 03, 2010 at 01:17:26PM -0700, Adam Williamson wrote: Would it be nice to stick this customization into fedora-packager, or would it just confuse/surprise people? If it's there as something that's easily enabled with an include, yes. But I think changing people's prompts globally isn't a good idea. Plus this fires up git, grep, and python every time you hit enter at the command line. That seems... not the best. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Adam Williamson wrote: Would it be nice to stick this customization into fedora-packager, or would it just confuse/surprise people? Is it fast enough to not delay the prompt noticeably even on old computers? What's the worst thing that could happen if it were to break? If Git were to enter an infinite loop for example, would it render my shell useless? Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
2010/8/3 Björn Persson bj...@xn--rombobjrn-67a.se: Adam Williamson wrote: Would it be nice to stick this customization into fedora-packager, or would it just confuse/surprise people? Is it fast enough to not delay the prompt noticeably even on old computers? No. At least, not the first time that you cd into a reasonably large git tree after a boot (i.e., data isn't cached in memory yet). I've got a core 2 duo laptop w/this enabled, and the first time going into a kernel git tree, its a good bit of disk churn and a very noticeable wait before I get a prompt back. After that first hit though, its reasonably fast to return. What's the worst thing that could happen if it were to break? If Git were to enter an infinite loop for example, would it render my shell useless? No clue. But I'd have to say no, don't just go enable it by default on people's systems. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Kevin Kofler kevin.kof...@chello.at wrote: It's better to have 99.9% certainty of an untampered package than no certainty at all. With git, if I have the hash of master, I can also verify that the content in the repository matches the hash. I cannot do this with SVN at all. Looking through the DAG of a git repository, I can also verify the history. I cannot do this with SVN at all. Therefore, I must conclude that I trust git more than SVN to manage my code. --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Björn Persson bj...@xn--rombobjrn-67a.se wrote: Adam Williamson wrote: Would it be nice to stick this customization into fedora-packager, or would it just confuse/surprise people? Is it fast enough to not delay the prompt noticeably even on old computers? I use zsh's vcs_info and the only one I've found (out of git, hg, darcs, svn, and cvs) that doesn't feel like a no-op is bzr support. What's the worst thing that could happen if it were to break? If Git were to enter an infinite loop for example, would it render my shell useless? Yes, it would. The shell will wait until the process gets back (hence my non-support of bzr in my zsh config). Björn Persson --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/2/10 4:31 PM, Neal Becker wrote:
OK, got mercurial updated for devel, apparantly OK. Now try to update f13:
fedpkg switch-branch f13
Branch f13 set up to track remote branch f13/master from origin.
[nbec...@nbecker1 mercurial]$ git merge master
Updating f6a7cf0..33f33a6
Fast-forward
.gitignore |2 ++
mercurial.spec | 10 --
sources|2 +-
3 files changed, 11 insertions(+), 3 deletions(-)
Here is where you should have done a fedpkg or git push
[nbec...@nbecker1 mercurial]$ fedpkg build
Traceback (most recent call last):
File /usr/bin/fedpkg, line 959, in module
args.command(args)
File /usr/bin/fedpkg, line 319, in build
url, chain)
File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line 797, in
build
raise FedpkgError('There are unpushed changes in your repo')
pyfedpkg.FedpkgError: There are unpushed changes in your repo
This shouldn't traceback, rather just give you the error message. The
message is right, you have stuff you haven't pushed.
[nbec...@nbecker1 mercurial]$ git status
# On branch f13
# Your branch is ahead of 'origin/f13/master' by 31 commits.
#
nothing to commit (working directory clean)
The changes are already committed, that's how it knows you are ahead of
master by 31 commits.
[nbec...@nbecker1 mercurial]$ fedpkg commit -p
# On branch f13
# Your branch is ahead of 'origin/f13/master' by 31 commits.
#
nothing to commit (working directory clean)
Could not commit: Command '['git', 'commit', '-a']' returned non-zero exit
status 1
There is nothing to commit, since all the changes are already committed.
[nbec...@nbecker1 mercurial]$ git push
To ssh://nbec...@pkgs.fedoraproject.org/mercurial
! [rejected]master - master (non-fast-forward)
error: failed to push some refs to
'ssh://nbec...@pkgs.fedoraproject.org/mercurial'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'Note about
fast-forwards' section of 'git push --help' for details.
OK, I give up.
Somebody has changed master since you last touched it, and you had
changes on your local master that are out of sync now. First, you
should do:
git config --add --global push.default tracking
This will make git push only attempt to push to the branch you are
tracking. Then you can git push your f13 changes. git checkout master
to get back to master and do a git pull --rebase to pull in the latest
upstream changes and re-play your unpushed changes on top of it. Then
git log to see what has happened, push if necessary.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxXWWkACgkQ4v2HLvE71NV9SQCeKL50F3iibsquSlwDGJ595wM5
SmUAniE+6rf25VAF7KRub+V/Wz6WG1Mo
=i6bO
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Jesse Keating wrote: Here is where you should have done a fedpkg or git push [snip] There is nothing to commit, since all the changes are already committed. The joys of DVCSes. People are NOT used to commit and push being different operations. Git is highly confusing to people who aren't git experts. Somebody has changed master since you last touched it, and you had changes on your local master that are out of sync now. First, you should do: git config --add --global push.default tracking This will make git push only attempt to push to the branch you are tracking. Then you can git push your f13 changes. git checkout master to get back to master and do a git pull --rebase to pull in the latest upstream changes and re-play your unpushed changes on top of it. Then git log to see what has happened, push if necessary. Huh? Can it get any more complicated? Git is a royal PITA to use! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 03:06 +0200, Kevin Kofler wrote: Jesse Keating wrote: Here is where you should have done a fedpkg or git push [snip] There is nothing to commit, since all the changes are already committed. The joys of DVCSes. People are NOT used to commit and push being different operations. Git is highly confusing to people who aren't git experts. I suspect that was more of a try everything before complaining that it doesn't work than a specific expectation that the command would solve the problem. Somebody has changed master since you last touched it, and you had changes on your local master that are out of sync now. First, you should do: git config --add --global push.default tracking This will make git push only attempt to push to the branch you are tracking. Then you can git push your f13 changes. git checkout master to get back to master and do a git pull --rebase to pull in the latest upstream changes and re-play your unpushed changes on top of it. Then git log to see what has happened, push if necessary. Huh? Can it get any more complicated? Git is a royal PITA to use! Are you comparing git to Mercurial or to a centralized VCS? I suspect exactly the same steps would be needed with Mercurial, except it looks like the default may be to push only the current branch of the working directory. Some of the complexity is intrinsic to distributed VCS and has to be weighed against the significant benefits to people who build custom packages, like me. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: Are you comparing git to Mercurial or to a centralized VCS? Both. Git is just a PITA in its own league, but DVCSes as a whole are a broken (*) and unhelpful (inherently hard to use) concept. (*) e.g. because of the strong reliance on hashes, which can make the whole thing break down in the event of a hash collision, and which make commit IDs nonsequential and unpredictable Some of the complexity is intrinsic to distributed VCS and has to be weighed against the significant benefits to people who build custom packages, like me. I don't see how dist-git makes it any easier to build customized packages. If you really want a local git mirror of a centralized repository, you can also use git-cvs, git-svn or the like. For SVN, SVK is also a nice solution. All this dist-git migration has brought us is chaos, a much higher barrier to entry and much harder work for existing packagers. (And yes, I've also tried to make these points BEFORE the migration, but nobody listened.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 06:41 +0200, Kevin Kofler wrote: Matt McCutchen wrote: Are you comparing git to Mercurial or to a centralized VCS? Both. Git is just a PITA in its own league, but DVCSes as a whole are a broken (*) and unhelpful (inherently hard to use) concept. (*) e.g. because of the strong reliance on hashes, which can make the whole thing break down in the event of a hash collision [1], and which make commit IDs nonsequential and unpredictable This is nonsense and Kevin can you stop being such a ball of stop. Try and divert some of the major amounts of stop and no energy you have at yourself for a while. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, Aug 03, 2010 at 03:06:07AM +0200, Kevin Kofler wrote: Jesse Keating wrote: Here is where you should have done a fedpkg or git push [snip] There is nothing to commit, since all the changes are already committed. The joys of DVCSes. People are NOT used to commit and push being different operations. Git is highly confusing to people who aren't git experts. There was a time when I wasn't used to using cutting instruments and eating being two different operations. Alas, I learned (or rather my parents tought me). In fact, I daresay learning this fancy new process of using cutlery has made the eating experience much more enjoyable and given me a wider range of food stuff to sample from. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On Tue, 2010-08-03 at 06:41 +0200, Kevin Kofler wrote: Git is just a PITA in its own league, but DVCSes as a whole are a [...] unhelpful (inherently hard to use) concept. I can't reproduce either issue. :D broken (*) (*) e.g. because of the strong reliance on hashes, which can make the whole thing break down in the event of a hash collision, Broken in the past tense is inaccurate: no SHA-1 collision has been published yet. I would like to see DVCSes switch to a stronger hash algorithm sooner rather than later, but it's not enough of a concern that I would avoid using them. If it makes you feel any better, git will not allow a fetched object to replace a local one with the same hash, so you can only lose if you fetch from the attacker first. and which make commit IDs nonsequential and unpredictable For sequential commit numbering, try git describe. Some of the complexity is intrinsic to distributed VCS and has to be weighed against the significant benefits to people who build custom packages, like me. I don't see how dist-git makes it any easier to build customized packages. If you really want a local git mirror of a centralized repository, you can also use git-cvs, git-svn or the like. This is a valid point which I forgot about. All this dist-git migration has brought us is chaos, a much higher barrier to entry and much harder work for existing packagers. (And yes, I've also tried to make these points BEFORE the migration, but nobody listened.) I suppose you are referring to this: https://lists.fedoraproject.org/pipermail/devel/2010-June/137582.html The problems with CVS were amply explained there, but it's less clear to me whether there were compelling reasons to choose git over (e.g.) SVN + git-svn or the people involved just happened to like distributed version control, as I do. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
